Council
This module relates to the WikiProject Council, a collaborative effort regarding WikiProjects in general. If you would like to participate, please visit the project discussion page.CouncilWikipedia:WikiProject CouncilTemplate:WikiProject CouncilCouncil articles

Archives

Index Archive 1 Archive 2 Archive 3 Archive 4 Archive 5 Archive 6 Archive 7 Archive 8 Archive 9 Archive 10 Archive 11 Archive 12 Archive 13 Archive 14 Archive 15

This page has archives. Sections older than 28 days may be automatically archived by Lowercase sigmabot III when more than 4 sections are present.

I'm planning to rewrite this template's functionality as a Lua module. As part of that, the plan will be to incorporate some design tweaks (as suggested earlier/above by Headbomb) and move class definitions and class masks to a JSON-file model. I've already prototyped a JSON file covering the "standard" set of classes over at Template:Class/definition.json, and there's Lua covering the functionality of {{class}} and related over at Module:Class. I never pushed those live because they are bad at supporting custom classes; this upgrade will get us around that problem. Individual WikiProjects will be able to define their own JSON files to extend or override the default set.

Besides Lua generally producing faster, cleaner, and more maintainable code, the upgrade to use JSON files in place of class masks has a very specific advantage: it'll be very easy for other tools to "discover" custom classes defined by individual projects. For example, I maintain the metadata gadget that brings assessments from the talk page to the title and tagline of the article namespace. That gadget currently must hardcode every custom class used by every WikiProject in order to support it, and that's not practical. By moving to JSON, both wiki-side Lua scripts and external (whether client-side gadgets in JavaScript or third-party code like bots) can access the same definitions without the need for one central file containing every custom definition used on the wiki. This will also make practical some future tools I'd like to develop, specifically focusing on exposing data about article quality over time and ORES.

I'm only human, so I'm probably missing some details here and there. Specifically, I'd appreciate input into the schema used for the JSON: for example, am I missing details that should be supplied in class definitions? More broadly, are there issues that this change would cause in places? I'd like to preempt problems as much as possible. {{Nihiltres |talk |edits}} 23:54, 28 August 2017 (UTC)[reply]

Highest support from me. This is a long term project, which will need a lot of testing and collaboration with other project/bots, but the goals are excellent and desirable. Headbomb {t · c · p · b} 00:29, 29 August 2017 (UTC)[reply]

Would the format used by the parameters in {{ReleaseVersionParameters}} be a good starting point for the schema? Titoxd^(?!?) 00:45, 29 August 2017 (UTC)[reply]

Indeed, ReleaseVersionParameters already had this goal in mind: the WP 1.0 bot does not hard code any custom quality or importance classes, but is able to parse them directly from the info in this "template". Really, it is not a template, just a way to format information in a way that can be parsed by a bot and hidden on the wiki. The main theoretical issues is if different projects have different custom classes on the same article, in which case there may be no easy way to tell the single "authoritative" rating for the article. It is necessary to have information on the relative position of each custom class with respect to the standard classes, which the template achieves with a numerical parameter. — Carl (CBM · talk) 01:24, 29 August 2017 (UTC)[reply]

My thought on "multiple custom classes" was that if there's more than one WikiProject involved in an article, the "authoritative", "standard" rating should be picked strictly from the standard set. We'd accomplish that not with numerical ratings—those are best for ranking qualities, rather than picking from them—but with a "maps to" property. For example, a WikiProject that implemented a "B+" rating could give it a property mapping that rating to the ordinary B-class rating for standardization purposes. If the mapping property wasn't provided, then by default we could map to the quality rating with the nearest lower numeric quality rating … which might mean having to be tricky about list-type ratings, but that's manageable. {{Nihiltres |talk |edits}} 14:04, 29 August 2017 (UTC)[reply]

That's great; I wasn't aware of that. Where bits overlap, it'd definitely be worth using the same patterns or values. For example, I've been thinking that a numerical value should be added to the class definition schema so that tools can insert custom classes into an overall order, and so that the "overall rating" of the page can be selected sanely—we can use the same scale as ReleaseVersionParameters. As mentioned, I started Template:Class/definition.json as the prototype schema; my current thinking is that it might make sense to expand the schema to use two inner objects ("quality" and "importance") or even three ("quality", "importance", and "WikiProject definition") so that we can put everything in the same place. {{Nihiltres |talk |edits}} 14:04, 29 August 2017 (UTC)[reply]

• Oppose Moving to Lua will make my long-term project (adding documentation to all WikiProject banners, ensuring that existing docs are accurate and up to date) much more difficult. It's OK when a banner uses one of the standard parameters in a standard way, but several use weird fiddles, and for these I need to trace through the code to see exactly what happens when a given permutation of parameters is in use. Lua code is untracable. --Redrose64 🌹 (talk) 20:10, 29 August 2017 (UTC)[reply]

  Could you be more specific with the problem, or give examples, please? I'd like to think that this project will help us smooth out "weird fiddles" somewhat, and I'm willing to write a variety of debug/testing tools into the code if that's something that you need. {{Nihiltres |talk |edits}} 03:41, 30 August 2017 (UTC)[reply]

  Couldn't a Lua version possibly auto-generate the documentation page as well? -- WOSlinker (talk) 07:57, 30 August 2017 (UTC)[reply]

  It may be possible to autogenerate some documentation in Lua, I don't know. Don't expect me to do it: Lua is a total enigma to me (when templates get converted to Lua, this is against the spirit of "the free encyclopedia that anyone can edit"). I have been documenting WikiProject banners since April 2010 and have developed a set of templates (see for example {{WPBannerDoc}}) that cope with most cases of standard parameters used in standard ways; examples include

• small – this parameter is no longer supported and can safely be removed from the template.

• category – set |category=no if, and only if, a banner is being used for demonstration or testing purposes, to prevent unnecessary or undesirable categorization. Otherwise, omit this parameter.

  and some cases of standard parameters used in non-standard ways, also some cases of non-standard parameters. My task is not complete: for example, I have not yet fully worked out the code for |A-Class= used by some banners (e.g. {{WikiProject Cricket}} used it until July 2016). --Redrose64 🌹 (talk) 09:43, 30 August 2017 (UTC)[reply]

I don't really see why LUA code in the background would prevent any of this working as is, or with small modifications. Not an expert on LUA, but to my understanding how you create specific instance of a banner like {{WP Physics}} should very much look the same as they do now, with a bit of streamlining for the class/importance code. Headbomb {t · c · p · b} 12:21, 30 August 2017 (UTC)[reply]

@Redrose64: There are (at least) two different ways we could roll this Lua/JSON update out:

1. Include a superset of existing functionality, move the new code into place in a single edit, then migrate deprecated functionality ("weird fiddles") to new functionality (i.e. the WikiProject-specific JSON file). Remove deprecated functionality as it's eliminated in the wild.
2. Write a new, cleaner template that significantly cleans things up but has a few breaking changes, then migrate project banners individually. Strictly speaking, we can write the JSON files that allow external-tool support for projects before migrating the project banners—just then we need to update things in two places any time a project wants to change its assessment system at all, with the risk that the two places become out of sync. This does have the advantage that it can be done even if the project members are cranky and don't want their project banner updated for whatever reason.

Either way, a focus will be on straightforward, single-document configuration for WikiProject assessment systems, and getting rid of complex multi-template systems (like A-class review hooks) in favour of integrated code that produces stuff that's more standard across WikiProjects. Either way, we'll have dozens of edge cases to resolve, and people that resist change for no good reason.

I understand the concern of Lua being opaque to you, but either way—multilevel-transclusion conditional wikitext or Lua—we've got complexity that's excluding someone. We should work on making it so that most people don't have to deal with the complicated stuff, of course, and I think that this project is in line with that through its design goal of moving "adding support for custom processes" (like A-class reviews) away from weird systems and so on into "just specify some extra properties for the class definition".

I think that our goals synergize well: we both want these systems to be easy to use and well-documented. My approach is just more dramatic, mostly by pushing things from "implement stuff yourself in wikitext" to "use the standard systems the banner module offers". My personal preference would be that we just force every WikiProject to use only a single standard set of classes and processes—that would give us site-wide consistency at a stroke—but I know that that's not politically feasible. As an alternative, I'm trying to make a system that offers support for custom classes and processes but makes them machine-readable so that we can deal with them (and yes, presumably document them) mostly automatically. {{Nihiltres |talk |edits}} 17:32, 30 August 2017 (UTC)[reply]

OK, here's an example. I've just improved Template:WikiProject Libraries/doc; whilst doing so, I found an unusual line in Template:WikiProject Libraries:

|INFOBOX             = yes

Wondering what the effect of that might be, I looked in the source of Template:WPBannerMeta for the sequence {{{INFOBOX and not finding it, I knew straightaway that the parameter was unrecognised, and I could safely ignore it. If Template:WPBannerMeta had been converted to a module, there would have been no way for me to find out whether that parameter is recognised or not, regardless of the difficulty in determining (if recognised) exactly what it does. --Redrose64 🌹 (talk) 08:47, 3 September 2017 (UTC)[reply]

If that's a desired feature, we could easily implement a parameter check like several templates do, and put out an error message when previewing the results. Headbomb {t · c · p · b} 12:20, 3 September 2017 (UTC)[reply]

Parameter checks which display error messages on preview - such as the one that I recently added to {{Infobox London station}} - are fine if the person adding that check knows what the valid parameters actually are. Once a template has become a module, you no longer know this. You are then dependent upon the module writer to keep the valid parameter list up to date, something which we cannot guarantee will be done, just as we cannot guarantee that those who amend templates will also amend the documentation. Any computer programmer will tell you that fully-documented functions are an ideal that is never achieved. --Redrose64 🌹 (talk) 12:48, 3 September 2017 (UTC)[reply]

(←) Module:Citation/CS1/Whitelist is updated each time a parameter is added or removed. You can also inspect Lua code in the same way as you inspected the template code for banner meta--it only seems opaque to you because you are unfamiliar with the language, not because it is impossible to do so. To any programmer, or anyone not versed in arcane template syntax programming language (and it is arcane, for a number of reasons), your use case is just as opaque. If you don't want to learn Lua, that's your prerogative. But right now, I personally find the current template completely opaque, and would much prefer a Lua representation. --Izno (talk) 14:09, 3 September 2017 (UTC)[reply]

Agreed. I've started in on the work of converting the module, but almost all of my work so far has been assembling personal notes on how the template works to make sure I match functionality reasonably well (for example, I need to look more into how the hook system is used in practice). The wikitext-vs.-Lua concerns are not a sufficient counterargument to my plan. That said, I do appreciate Redrose64's concern of documentation quality, and we can keep it in mind moving forward. {{Nihiltres |talk |edits}} 20:43, 7 September 2017 (UTC)[reply]

• The vast majority of WikiProjects use the simple/base banner, right? So I'd be less concerned about fitting the edge cases (let them continue to use the old banner innards, if necessary, if those projects even still actively use those extra features) than making the majority more efficient czar 05:58, 10 September 2017 (UTC)[reply]

  • Handling the edge cases is one of the goals of this change, though. I'm already maintaining a gadget that needs to be able to handle custom classes—that was a big inspiration for this—and right now it has to have extra styles, strings, etc. hardcoded into the gadget to support custom classes, which is untenable. I'm planning to make some tools that help surface progression of quality metrics over time and highlight ORES data for comparison, and for those tools it'll also be highly desirable to at minimum be able to automatically normalize custom classes to values from the standard set—let alone the portability and maintenance benefits of not hard-coding quality/importance classes in general. Handling edge cases well is one of the key benefits here. We can offer partial support by creating project configuration files for projects before they're properly updated, but that trick increases maintenance costs because it requires that any updates be mirrored in two places (the actual project banner, and the configuration file).

    The fact that most WikiProjects use "simple" options does offer us an easy migration path, though: once the code's in a usable state we can start migrating "simple" banners and whittle the problem down to the tricky projects. {{Nihiltres |talk |edits}} 19:55, 12 September 2017 (UTC)[reply]

    Sounds good. Just wanted to note that it's possible that some edge-case projects are no longer even active and therefore might not care if their edges are preserved. Perhaps someone can generate a list of edge cases and the rest of us can help by investigating czar 20:34, 12 September 2017 (UTC)[reply]

    Right, good call! I figure that we can proactively update most projects assuming there are no breaking changes. Few projects should have breaking changes; the nature of Lua means that it should be easy to cover most of the custom stuff with native functionality. Most of the edge cases should be easy to detect: they'll be using a class mask and/or the hook system, so they'll have non-empty values defined in relevant parameters. Many of those will be simple cases like "supporting extra parameters" that Lua can handle with negligible effort; a few might be more complicated. First things first, though: I've got to rewrite most of the core functionality. I'm planning to deprecate the hook system entirely: people who want that level of flexibility can instead just require() the main Lua module and reuse its functions in their own module. {{Nihiltres |talk |edits}} 21:31, 12 September 2017 (UTC)[reply]

• Support. WikiProject banners are a contentious area for many historical reasons, but I'm committed to moving the technology forward in a way which doesn't step on anyone's toes too much. @Nihiltres: Feel free to reach out if you'd like to collaborate. @Redrose64: Your documentation goals are extremely important, and we should make sure they are supported throughout this process as much as possible. TheDragonFire (talk) 10:45, 11 February 2018 (UTC)[reply]

I would like to add "class = Disambig" to Template:WikiProject Disambiguation so that all the tools that rely on PageAssessments data (XTools, CopyPatrol, Popular Pages Bot, etc.) will recognize these pages as disambiguation pages (as most of them don't have any other WikiProject banners). However, this would needlessly categorize all of these pages into a new NA-Class Disambiguation articles category, which would be silly. Is there any way to suppress the creation of class categories (besides not passing a class)? If not, could a way be added? Kaldari (talk) 20:27, 8 December 2017 (UTC)[reply]

I rather think that XTools etc. recognise pages as disambig-class by their being in a subcategory of Category:Disambig-Class articles, and not by the presence of parameters in WikiProject banners. That being the case, here is what I would do:

1. Modify {{WikiProject Disambiguation}} to have two new lines:

   |QUALITY_SCALE=inline
   |class={{class mask |dab|disambig=yes}}
   

2. Create Category:Disambig-Class Disambiguation articles with the following content:

   {{CategoryTOC}}
   [[Category:Disambig-Class articles]]
   

After a while, the category will populate. There should be no need to create any other categories. --Redrose64 🌹 (talk) 15:59, 9 December 2017 (UTC)[reply]

Or instead of step 1, you could add the category to the banner without displaying the class type. <includeonly>[[Category:Disambig-Class Disambiguation articles]]</includeonly> -- WOSlinker (talk) 20:13, 9 December 2017 (UTC)[reply]

You'd need to be careful how you did that, so that |category=no would still be honoured. --Redrose64 🌹 (talk) 23:39, 9 December 2017 (UTC)[reply]

True. <includeonly>{{#ifeq:{{lc:{{{category|}}}}}|no||[[Category:Disambig-Class Disambiguation articles]]}}</includeonly> -- WOSlinker (talk) 13:28, 10 December 2017 (UTC)[reply]

On many pages (for example Talk:Deterrence (legal)) the coloured blocks for class and importance come out ridiculously large on zooming in, or when the page width is reduced, like jumping from a width of 5 em to 45+ em. Can something be done to keep the size constrained?  --Lambiam 11:45, 4 May 2018 (UTC)[reply]

Can't see this myself. What browser are you using? Maybe post a screenshot to show the problem? — Martin (MSGJ · talk) 12:41, 4 May 2018 (UTC)[reply]

@MSGJ: I was able to repro on Windows 7 with Firefox 59.0.3 (on Timeless skin, if that matters). That said, it was at a zoom level that I think is generally not a workable one, but I suppose could be used by readers with poor or failing eyesight. --Izno (talk) 12:58, 4 May 2018 (UTC)[reply]

For me it happens with Firefox 59.0.2 on macOS (using MonoBook), already at relatively modest zoom levels (5 times command-+, corresponding to a magnification of about 171% compared to the default) – or by a window size reduction to 58% of the screen width (1/1.71 = 0.58) at the default zoom level.  --Lambiam 22:55, 4 May 2018 (UTC)[reply]

This is very odd, because a WikiProject banner is essentially a table having three rows of three columns (in this case the third column isn't used). In a table, columns are of constant width all the way down, and so the the first cell of every row in the same table should be the same width as all the other cells in that column.

In the WikiProject law banner displayed at Talk:Deterrence (legal), the first column comprises one image and two items of text (the two coloured blocks under discussion). The width of the column is determined by the widest cell, which is File:Scale of justice 2.svg displayed 55px wide, and the two others are widened to match that one.

When text is left-aligned within a cell, the second cells of each row should have their left edges aligned vertically; that is to say, the text "This article has been rated as Start-Class on the project's quality scale." and "This article has been rated as Top-importance on the project's importance scale." should not be displayed any further to the right than the text "This article is within the scope of WikiProject Law, ...". The screenshot shows that such vertical alignment is failing, which to me suggests a browser problem.

Looking at that column-two text beginning "This article is within the scope ..." shows that the text is flowing around the image - the words "encompassed by it." are below the image and left-aligned with the image's left edge. This cannot happen if they are in different cells, so to my mind, something is merging two cells that should be distinct.

Another odd feature in that screenshot is the "Law portal" box - the white background should entirely fill the border of that box, instead of stopping short of the bottom border. --Redrose64 🌹 (talk) 20:03, 4 May 2018 (UTC)[reply]

The portal box is probably an artifact of using Timeless--every portal box appears so in that skin, though I can confirm Vector and Monobook are fine. I suppose it's plausible that it's related and may indicate an error in the portal box module/metatemplate, but I am skeptical. I think Timeless is more likely missing some skin coloring or border manipulation that can be found in the vector/monobook themes. And it's that the border isn't shrinking to the background, not that the background needs to fill in the shape delineated by the border. --Izno (talk) 20:31, 4 May 2018 (UTC)[reply]

Request: Please change this template (or the other one; see below) so that the categories "Project-Class sociology articles" and "Top-importance sociology articles" are no longer invoked from every page transcluding it.

Background:

There is an error, either in this template, or in {{WikiProject Sociology}}, I'm not sure which. The undesired behavior is that pages including the latter template, get categorized into two article categories. One example is the Talk page for WikiProject Sociology at WT:SOCIO, which has two categories listed which are incorrect for a Talk page.

An example completely stripped of all excess cruft to make it easier to see the problem, and which also contains justification for the "undesirable" characterization, is here: User:Mathglot/sandbox/Test pages/Sociology Header noinclude thing. Thanks. Mathglot (talk) 03:00, 12 May 2018 (UTC)[reply]

What exactly is the problem here? You've tagged the Wikipedia talk:WikiProject Sociology page with {{WikiProject Sociology|class=Project|importance=Top}}. "Project-Class sociology articles" is simply an artefact of the underlying structure for the page categoriation. You could rename that to pages if that particularly annoys you, but nothing is broken here. Headbomb {t · c · p · b} 04:15, 12 May 2018 (UTC)[reply]

'Pages' or 'articles' is irrelevant, it's still wrong. A project page is not rated on a quality scale, and thus is not a 'Top-importance sociology articles' [or 'pages']. The talk page should be responsible for declaring its own categories, and not inherit them blindly, especially not if they aren't defining characteristics of the page. In any case, 'Top-importance sociology articles' [or 'pages'] is not a defining characteristic of a Project Talk page. I'm not a categorization honcho, I made need to page some folks that can explain this better than I can. Stand by... Mathglot (talk) 11:13, 12 May 2018 (UTC)[reply]

@Mathglot: If you do not want WT:SOCIO to appear as a top-level article, you need to remove the rating. Nothing was being inherited "blindly". --Izno (talk) 13:13, 12 May 2018 (UTC)[reply]

As for the class, that appears to be set correctly as it is indeed a project "article" (that it is called an article is an artifact more than anything--we don't care enough to change however many millions of project talk pages tagged as such just for article -> page). --Izno (talk) 13:15, 12 May 2018 (UTC)[reply]

If you object to the page being classified into top-importance aritcles, just don't set |importance=top in the banner. Headbomb {t · c · p · b} 13:20, 12 May 2018 (UTC)[reply]

In fact, you can safely remove the |class=Project as well as the |importance=Top since the class is detected automatically for all non-article talk namespaces (Category talk, File talk, Template talk, Wikipedia talk, etc.); the importance similarly defaults to NA (putting the page into Category:NA-importance sociology articles) in those namespaces. So all that you really need on Wikipedia talk:WikiProject Sociology is {{WikiProject Sociology}} with no parameters at all. --Redrose64 🌹 (talk) 21:12, 12 May 2018 (UTC)[reply]

Ah, I see now, I didn't realize it was coming from the parameters, and not directly from the template. You can mark this closed. Thank you one and all. 03:25, 13 May 2018 (UTC)

Either I'm really dense, or there's something I'm missing. I've removed both project class and quality scale params, leaving only {{WikiProject Sociology}} in both the project page, as well as on my test page. Both pages continue to show two categories at the bottom of the page, although not the same ones as before. In the case of the test page, the two categories shown are NA-Class sociology articles and NA-importance sociology articles. In the case of the actual project page (Wikipedia talk:WikiProject Sociology), it shows Project-Class sociology articles and |NA-importance sociology articles. What am I missing? Can I say, |class=none |importance=none or something? Mathglot (talk) 07:15, 13 May 2018 (UTC)[reply]

This is normal behaviour for all WikiProject banners that recognise |class= and |importance= parameters. When one or the other of these parameters is blank or absent, a default value is used. As noted at Template:WikiProject Sociology#Optional parameters:

• class – valid values are listed in the custom class mask. See the project's quality scale for details. Setting an explicit value of NA is rarely necessary; for this, either leave |class= blank or omit the parameter.

If you don't want Wikipedia talk:WikiProject Sociology to appear in Category:Project-Class sociology articles and Category:NA-importance sociology articles, remove {{WikiProject Sociology}} entirely. You cannot keep the banner and also suppress the categories other than by removing recognition for the parameters entirely, which would defeat the FA/A/GA/B/C/Start/Stub grading scheme as well. --Redrose64 🌹 (talk) 07:47, 13 May 2018 (UTC)[reply]