Template talk:WPBannerMeta

From Wikipedia, the free encyclopedia
Jump to: navigation, search
WikiProject Council
WikiProject icon This template relates to the WikiProject Council, a collaborative effort regarding WikiProjects in general. If you would like to participate, please visit the project discussion page.

Removing the "importance" parameter[edit]

Following the discussion at WP:Village pump (technical)/Archive 155#Removing the "importance" parameter from a WikiProject banner, I followed the advice given by Redrose64 and have done the required edit to {{WikiProject Disability}}. In the same discussion Iridescent mentioned that a bot could go around to all the existing banners to remove the Importance parameter. What do I need to do to get such a bot task done? If there's anything else I've missed or done wrong please let me know. Roger (Dodger67) (talk) 11:18, 9 June 2017 (UTC)

AnomieBOT is the bot you want (Anomie I assume it falls under WikiProjectWorker and wouldn't need a separate BRFA?). I'd strongly advise leaving the assessments in situ but invisible for at least a couple of months before a bot run to remove them—if people object to the removal it's a lot easier to just make the existing assessments visible again, than to re-add an assessment to every page. ‑ Iridescent 11:31, 9 June 2017 (UTC)
Yes, leaving |importance=low etc. on every talk page is harmless - nothing is displayed, no categorisation is performed. --Redrose64 🌹 (talk) 11:41, 9 June 2017 (UTC)
Does anyone know where the discussions on removing priority/importance ratings are for {{WikiProject Disability}} and {{WikiProject Visual arts}}. I would like to summarise typical reasons in Wikipedia:Assessing articles. Is there an easy way to find other projects that skip the ratings? Aymatth2 (talk) 12:06, 9 June 2017 (UTC)
Aymatth2 See WT:WikiProject Disability#Proposal to remove the Importance parameter from the project banner and the article assessment system where I proposed the removal a month ago, nobody responded at all so per "silence = agreement" I've gone ahead. "Importance" is often a subjective personal opinion and subject to dispute. It's also of little to no actual value in the project's article improvement system - the Stub/C/B/GA/FA says everything we need to know about the article's quality, regardless of what it is about or how "important" anyone thinks it is. Roger (Dodger67) (talk) 13:18, 9 June 2017 (UTC)
Some projects follow one the two "standard" schemes, which give reasonably objective criteria, and some follow tailored schemes, like {{WikiProject Iran}}. Most effort should be given to improving articles on the most central aspects of the project's subject area. But with some areas it may be unavoidably subjective, like the difference between low- and mid-importance visual artists. I hoping for ideas on when importance ratings don't work to use in the Wikipedia:Assessing articles essay. Aymatth2 (talk) 14:42, 9 June 2017 (UTC)
You might consider taking a look at WP:VG/A#Importance scale. I don't think anything there is out-of-step with your essay--I think it might be good to point out that breaking down a field into subsections and then providing assessments for those subsections can help with good assessment. --Izno (talk) 15:54, 9 June 2017 (UTC)
@Izno: Thanks for pointing that out. I have added a note on it to the essay. An interesting approach that others might want to follow. Aymatth2 (talk) 16:50, 9 June 2017 (UTC)
As regards Visual Arts, a conscious decision was made not to include "importance" when the template was originally created a decade ago, so there's never been a "decision to remove it" as such. Occasionally people will suggest adding one, but it never finds any support. "Importance" really doesn't work on arts topics; someone interested in 19th century English history painting, someone interested in traditional Chinese porcelain, and someone interested in pre-Colombian architecture will each have a completely different idea of what "high importance" means.
As I often point out, what editors feel ought to be the important topics rarely correlate with what the readers consider important topics; in terms of what the readers are actually reading, Darth Vader consistently gets more pageviews than United States and World War II combined. To take the disability project as an example, if you look at what the readers are actually looking for there's not actually a very strong correlation between pageviews and "importance"—ultra-core topics like Speech and language impairment get fewer views than trivia like I've fallen, and I can't get up!. ‑ Iridescent 17:14, 9 June 2017 (UTC)
@Iridescent: Good points. I have added them to the essay. The pageviews difference makes sense: Darth Vader has galactic importance while the other two articles just cover minor details about one species on a small green planet. Aymatth2 (talk) 11:55, 10 June 2017 (UTC)

And old idea, revisited, part 2[edit]

This is a follow up to Template_talk:WPBannerMeta/Archive_10#An old idea, revisited, related to discussions with Nihiltres (talk · contribs) and Dispenser (talk · contribs) at Wikimania 2017.

  • Mockup 1 was the original idea. Tried to include "vital" articles in there, but for 10,000 articles, this is really flagging this at the completely collapsed level.
  • Mockup 2 effectively treats vital articles as another Wikiproject, with vitality replacing importance. It's quite neat, but discussions at Wikimania led me to a third mockup
  • Mockup 3 the main thing is we separate type (article, list, category, media) from assessment, and can offer all levels of assessments for things that require assessments. I've also re-designed the issue-flagging so it's actually clear what the icons mean. Some of the links would have to be updated / some pages created, but you get the general idea.

Now of course, there is currently no B-class topics, or C-class media, so if consensus is against having those, we could easily restrict assessments to partial lists depending on type. I don't see support for anything but featured media, but on topics or lists? I absolutely see a demand for those. Headbomb {t · c · p · b} 14:27, 15 August 2017 (UTC)

There have been several proposals for a Good List class. They failed (see for instance Wikipedia talk:Good article nominations/Archive 22#Request for comment on stand-alone lists being nominated as Good Articles or Wikipedia:Village pump (proposals)/Archive 123#Good Lists - others exist as well); so any other graduations for lists are not likely to succeed either. That's with the exception of MILHIST which already has AL, BL and CL, see WP:MHA#SCALE. --Redrose64 🌹 (talk) 22:18, 15 August 2017 (UTC)
I know for a fact that WP:PHYS would make use of B/C/Start/etc... lists. I suspect most projects would too, were it actually easy to set up. I'm not proposing we extend this systematically and create new reviewing process when there's no demand for such (e.g. Good lists, Good media, Good portals, etc...), just that we extend the scheme to support such assessment when needed. Projects that have no desire to assess lists could easily continue not doing so, but from my experience there is an appetite to keep track of how lists perform. Reading from the RFC, it seems most people objected because no solid criteria for a good list have been put forward. Headbomb {t · c · p · b} 22:35, 15 August 2017 (UTC)
As I noted above, that RfC was not the only proposal. But we already have the mechanism for any WikiProject to add AL/BL/CL if it wants to, it is {{class mask}}, see for example Template:WikiProject Plants/class. --Redrose64 🌹 (talk) 07:37, 16 August 2017 (UTC)
The class mask is a real pain in the ass to setup, and most don't want to bother dealing with that. Nihiltres (talk · contribs) is working on externalizing the classes to a json file however, it looked real promising from what I saw of it. Headbomb {t · c · p · b} 10:47, 16 August 2017 (UTC)
@Redrose64 and Headbomb: I've written up a little of my plans in the section below. Specifically, {{class mask}} would be replaced with WikiProject-specific JSON files that extended or overwrote parts of the "default" class set. This would help implement "type" separation from assessments. I do think, though, that we'd be better off implementing the design improvements first before we tackle the headache of disentangling "type" assessments from quality assessments. I'm going to start writing up code to reimplement most of WPBannerMeta in Lua, so the most helpful thing at this point would be to get the main design improvements solidified so that I can get them out. {{Nihiltres |talk |edits}} 00:02, 29 August 2017 (UTC)

To keep this discussion going: I've been eyeing the implementation details here and it looks like a lot of the functionality of the redesign is applicable to {{WikiProject banner shell}}; it'd be really helpful if someone could itemize the features of this redesign as they'd be applicable to each template. Some support will happen in this template—or Lua reconstruction thereof—but some major features, like including a "master" rating, would have to happen in the banner shell. {{Nihiltres |talk |edits}} 20:52, 7 September 2017 (UTC)

  • Would this make sense to wrap into {{article history}}? It already covers the status rating of the article (GA/FA, could extend down to Start for unified/"master" rating), and the template could also house a condensed listing of the relevant WikiProjects (I would go multi-column with shorter line heights, compared to the mockups). My gut tells me that WikiProjects create a lot of needless work for themselves (esp. relative to their editor capacities) by tagging talk pages rather than generating, say for WP:VG, database readouts of all articles of "instance: video game, video game developer, etc." These templates are supposed to improve editor productivity, so wouldn't it better to generate readouts for any grouping of WP articles, e.g., topics related to Ursula Le Guin or financial companies in Iceland without necessitating a separate Ursula Le Guin (etc.) WikiProject with infrastructure and all? (Again, let the projects who actually use their custom features keep them—Milhist, Chem, anyone who actually uses their "importance" ratings—I'm thinking more of the vast majority of WikiProjects that have simple needs or are altogether dormant, where we should try to reduce editor maintenance costs while refining this template, if possible. czar 06:18, 10 September 2017 (UTC)

Overhaul: moving to Lua & JSON[edit]

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)

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)
Would the format used by the parameters in {{ReleaseVersionParameters}} be a good starting point for the schema? Titoxd(?!?) 00:45, 29 August 2017 (UTC)
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)
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)
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)
  • 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)
    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)
    Couldn't a Lua version possibly auto-generate the documentation page as well? -- WOSlinker (talk) 07:57, 30 August 2017 (UTC)
    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 – set |small=yes to display a small version of the template aligned along the right side of the page (as opposed to at the top). This parameter does not work as expected if the banner template is enclosed in {{WikiProject banner shell}} or any of its redirects.
  • 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)
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)
@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)
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)
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)
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)
() 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)
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)
  • 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)
    • 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)

      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)
      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)