User talk:Dinoguy1000/Assessment category RfC

Capitalization

The most sane position seems to me to be that the capitalisation of "class" and "importance" should match the capitalisation of the |class= and |importance= parameters in the banner: that is, they should both be lowercase. Equally, "class" should be used instead of "quality" or whatever. Projects that use |priority= instead of |importance= tend to use Top-priority Foobar snorkels, which is 'correct' under this schema. Does this seem reasonable? Happy‑melon 16:42, 18 July 2009 (UTC)

Hmm... I hadn't considered that line of reasoning for capitalization, but it definitely makes sense. As for "class" vs. "quality", I added that mostly because it was covered in the link WOS provided below; I don't really have a preference one way or the other (but the "importance" vs. "priority" discrepancy helps to highlight why it shouldn't change, I guess). 「ダイノガイ千？！」^{? · Talk⇒Dinoguy1000} 16:58, 18 July 2009 (UTC)

[Category/Template/Image/File]-Class

While I agree with most of the RfC, I'm not so sure about the "WikiProject X types" categories. I think those types of categories should contain the items directly rather than the talk pages. See Category:WikiProject Films templates for an example, it just contains templates, not template_talk pages. Another disadvantage is that you can't always just add an s to the end of the type. (category -> categories). I'd rather it was something similar to what is already done, probably with pages rather than articles. Template-Class X pages -- WOSlinker (talk) 19:27, 17 July 2009 (UTC)

Those are all very good points. In addition, think about the technical aspects. We have to create a template ({{class}}), which can accept both 'standard' assessment categories, and 'nonstandard' ones. So we know that it's going to have to accommodate FA, A, GA, B, C, Start, Stub, List, NA, Unknown, etc. We also 'know' that it's going to have to accommodate ones like Redirect, Future, Template, Portal, Project, Category. But we also have unknown unknowns; things that come out of the woodwork like SL-Class (WPPlants), B+ (WPMaths), AfD-Class (historical, but you get the picture). And those unknowns fall into both categories: both articles and non-articles. How is this template going to know which 'subschema' to put them in? A separate parameter? Ugh. Happy‑melon 20:37, 17 July 2009 (UTC)

The "type" parameter is sooooooooo needed it's crazy. It goes more than simply images/template/categories/etc, although that alone is sufficient to warrant the change. It would allow for so much improvement were it around. For examples, lists have two degrees "list" and "featured-list". Well some lists are stubs, and some are B-class, and some are feature quality. Currently, you can't monitor list improvement over time, or identify sub-par lists. By creating the "X-type" you can finally have a more fine-grain view of the content-oriented pages in a WikiProject's scope without sacrificing quality control (such as lists, timelines, wikipedia books, portals, topics, ... ), some on a per-project basis, others on a wider basis. Yes to types! Headbomb {^ταλκ_{κοντριβς} – WP Physics} 10:25, 30 September 2009 (UTC)

A type parameter would have a number of problems, though - how many FX-class redirects could possibly exist? In addition, there are a token few projects which actually do assess at least some lists as articles *cue personal experience at WP:ANIME* - the call for a type parameter has happened many times before, and these same issues always get brought up, but I'm not sure that anyone has presented satisfactory solutions for them. In any case, this proposal isn't about adding new trinkets to the assessment scheme, but about standardizing and squaring away all the little trinkets that are already in it. 「ダイノガイ千？！」^{? · Talk⇒Dinoguy1000} 18:30, 30 September 2009 (UTC)

The answer obviously that you would place |class=NA for |type=redirect in the exact same fashion that you place |importance=NA... Headbomb {^ταλκ_{κοντριβς} – WP Physics} 02:28, 2 October 2009 (UTC)

So, how would you see a typical usage of this in practice? Something like the table below? I follow your reasoning for lists and images, but most of the types would only have one class (NA) so it does seem like a lot of added complication for little benefit. — Martin (MSGJ · talk) 05:01, 2 October 2009 (UTC)

Details below. (Reformatted/expanded your table). Headbomb {^ταλκ_{κοντριβς} – WP Physics} 07:54, 2 October 2009 (UTC)

Type/Class/Importance status/overhaul

Today the situation is this:

Current (equivalent) table

class	type
	article	list	topic	book	image	portal	dab	redirect	template	category	project
Featured	Y	Y	Y	—	N	N
Good	Y	—	Y	—	—	—
A/.../Stub	Y	—	—	—	—	—
NA					Y	Y	Y	Y	Y	Y	Y
Importance	Yes	Yes	Varies	—	No	No	No	No	No	No	No

Legend

• Y: Exist and is implement
• —: Doesn't exist, but could/should
• N: Exist but is not implemented

Aka there are things that could logically be assessed, but cannot be due to limitations. For instance, if a project would like to keep track of the quality of its lists, they would have to either implement things like FL, GL, AL, BL, CL, Start-L, Stub-L – or sacrifice the "list" identifier, and use the regular A, B, C, Start, Stub. Some portals are featured, but there's no keeping track of them through the banner. Topics have featured and good, but nothing else. So you would need to add AT, BT, CT, Start-T, Stub-T and so on.

But doing these bunch of custom classes is a dodge of the real issue: Wikiprojects want to be able to keep track of both the type of pages and quality of their pages. This also harms the expansion of the scope of the banner. For example books are currently given little attention, and I want to kickstart that. I can fathom books being assessed, reviewed and so on, and these are of interest to projects. You could create a custom "book-class", but that wont allow you to track quality, so you need FB, GB, AB, BB, CB, Start-B, Stub-B...

Now, not all projects would be interested in a banner this fine-grained, the default behaviour would simply be |type=article when nothing is specified, so class and importance would work as usual. The banners can be coded to handle |class=redirect to mean |type=redirect |class=NA |importance=NA. So having the "type" parameter around would not cause them any problems.

The endgoal of a project using the full power of the overhauled banner would be something like:

Assessement \w type

class	type
	article	list	topic	book	image	portal	dab	redirect	template	category	project
Featured	Y	Y	Y	Y	Y	Y
Good	Y	Y	Y	Y	?	?
A/.../Stub	Y	Y	Y	Y	?	?
NA					?	?	Y	Y	Y	Y	Y
Importance	Yes	Yes	?	?	?	No	No	No	No	No	No

This would also have the advantage of WikiProjects being able to create their own non-mainstream types of article if they so wished (such as timelines, outlines, users, and so on). Headbomb {^ταλκ_{κοντριβς} – WP Physics} 07:54, 2 October 2009 (UTC)

I actually disagree with much of this - most projects are going to have only one or two portals within their scope, so it's probably not worth the bother creating a new class specifically for them. Featured/good topics are a more likely possibility, with the number mostly only limited by creativity and effort, but it's probably better to use a separate flag for them, similar to how taskforce/work group tagging is done (e.g. |featured-topic=Foo and |good-topic=Foo, where "Foo" is the name of the main article of the topic or a link to the discussion). I don't have any experience working with books, but I'd imagine they'd be much the same as topics. Featured images would also be better off denoted by a separate flag. As for lists, it depends on the project's outlook, goals, and practices - in WP:ANIME's case, we have large numbers of article-type lists (character lists come the closest to articles, but we also have chapter, episode, soundtrack/album, film, and video game lists within our scope, just to name the major types), so we find it's better to just assess them as articles up to B-class (without bothering to track them as lists via the banner), after which they go to FLC. Other projects may want to track their lists while assessing them as articles, in which case I'd again recommend a separate flag. And the possibility of good lists has been raised many times before AFAIK but rejected.

One last, almost-unrelated point, is that I would quite seriously like to see a featured template process set up, to help raise awareness of some of the templates we have on Wikipedia - I would have started on a draft of the actual page long ago if I had the motivation time. 「ダイノガイ千？！」^{? · Talk⇒Dinoguy1000} 18:43, 2 October 2009 (UTC)

Well for portals, the point is not really for internal-wikiproject tracking, but rather for inter-wikiproject tracking. It's also a rather minor aspect of it compared to the impacts that would really matter (F/A/G/B/C/Start/Stub Books, F/A/G/B/C/Start/Stub Topics, F/A/G/B/C/Start/Stub Lists, possibility of custom-types for projects...). Featured Portal vs Portal would simply be along for the ride.

Concerning the "seperate flag" that's duplicating work that really shouldn't be duplicated, ... especially since that "separate" flag would basicaly be a stripped-down "type" parameter. The whole point of the metabanner is to streamline things. It could easily keep track of all this if we implement the full-fledged "type" parameter. And as I said early, if you don't want to use it, then don't use it (The banner can easily be kept backwards compatible). But the physics project would definitaly use it, and its taskforces would as well, and I know of a few other projects that would like such an upgrade on the banner's flexibility. The rejected "good" lists and so on is not very problematic either. If there are no "good lists", then "class=Good |type=List" simply won't be used. Headbomb {^ταλκ_{κοντριβς} – WP Physics} 16:34, 3 October 2009 (UTC)

articles vs. pages

Same issue as above applies: when {{class}} gets given a rating of "Cheesecake", which suffix does it get? Is a cheesecake an article or a page? Happy‑melon 20:38, 17 July 2009 (UTC)

Another way to do it would be to call everything a page rather than all articles or a split into articles and pages. -- WOSlinker (talk) 21:09, 17 July 2009 (UTC)

That would be preferable, IMO, to calling half one and half the other. Happy‑melon 16:46, 18 July 2009 (UTC)

One approach would be to call a very specific subset "articles" and everything else "pages" (even nonsense classes like "cheesecake"). If a custom class actually does assess articles, then, it could be added to the subset that are named "articles". However, I think I also would prefer the far simpler method of just calling everything "pages" (which means that, yes, I just wasted a lot of ... words, since I felt like pointing out one possible solution that would keep the articles/pages distinction). 「ダイノガイ千？！」^{? · Talk⇒Dinoguy1000} 17:05, 18 July 2009 (UTC)

other comments

It's possible to argue that the middle bit of the category should be the full title of the WikiProject itself. So a project located at Wikipedia:WikiProject Lock, stock & Two smoking Barrels should use Category:FA-snorkel Lock, stock & Two smoking Barrels humbugs; duplicating whatever silly capitalisation and punctuation is used in the project title. There are an awful lot more categories out-of-schema on this basis, though, than the other issues, as WPBM hasn't made any effort to standardise this. Is this feasible? Happy‑melon 20:30, 17 July 2009 (UTC)

I actually agree with this now that I think about it; it saves us having to justify some custom method we come up with ourselves. 「ダイノガイ千？！」^{? · Talk⇒Dinoguy1000} 17:06, 18 July 2009 (UTC)

Comment: Not directly related to this, but if you haven't seen Wikipedia:WikiProject/Naming convention then it might be worth a read. -- WOSlinker (talk) 21:24, 17 July 2009 (UTC)

That's pretty interesting, thanks for the link! 「ダイノガイ千？！」^{? · Talk⇒Dinoguy1000} 17:06, 18 July 2009 (UTC)