Wikipedia talk:WikiProject/Naming convention

Discussion

I think that this is a good idea for a number of reasons. As stated on the project page, having a standardized naming convention will ease collaboration and participation. Also, having a level of standardization makes it easier to write bots that can further improve productivity.
Quanticle (talk) 21:58, 28 August 2008 (UTC)[reply]

It will simplify existing bots as well. LA (T) @ 22:01, 28 August 2008 (UTC)[reply]

Obviously, I support this as well. My reasons are mostly outlined in the lede, so I won't elaborate here except to stamp my not-so-illustrious name on it. : ) L'Aquatique[talk] 22:52, 28 August 2008 (UTC)[reply]

I note that the proposed names do not allow for compliance with Wikipedia:Manual of Style (spelling) - projects related to England specifically may not like to use the -ize suffix. -Malkinann (talk) 22:57, 10 September 2008 (UTC)[reply]

Malkinann, there is only one item in this whole proposal that has the -ize suffix and that is the word sympathizers. And please note, WikiProject Doctor Who does not have a problem with the -ize suffix on theirs (WikiProject Doctor Who/Participants/Sympathizers). The American English "stardardize" is used as a section of the proposal; but not as a page, category, or template name. LA (T) @ 23:20, 10 September 2008 (UTC)[reply]

There may be other projects that take issue with the -ize suffix - like WP:ENGLAND. -Malkinann (talk) 23:29, 10 September 2008 (UTC)[reply]

-quality or -Class in categories

While I agree that it would be good to standardise the Project naming schemes, just wondering why there is a need to use -quality rather that -Class in the categories as that's going to be more things to change. Why not leave the -Class parts in the categories as is and just make all the other changes to start with. There would be quite a bit to do without all that as well. -- WOSlinker (talk) 22:32, 28 August 2008 (UTC)[reply]

It is a match up with what it is, in this case these are quality categories to match up with the Quality table, just like importance matches up to the Importance table. Importance categories use -importance, note the initial lower case letter. Class could be attached to quality or importance. LA (T) @ 22:48, 28 August 2008 (UTC)[reply]

PS. Thank you for catching my typo. LA (T) @ 22:50, 28 August 2008 (UTC)[reply]

The only thing is though that all the project banners use the class= and importance= parameters, so the categories currently match up with those parameter names. If changed to quality, in an ideal work, should all the banners be changed to match as well? -- WOSlinker (talk) 06:21, 29 August 2008 (UTC)[reply]

I really don't know. I was only thinking about the visible names, not the invisible ones. I would say, for now, no. However, if it would help keep confusion to a minimum, then yes, change that too. LA (T) @ 06:48, 29 August 2008 (UTC)[reply]

Harmful

To be quite honest, I can't see any substantively beneficial consequences from something of this sort, and quite a number of harmful ones:

This is harmful because it sharply limits the flexibility of WikiProjects to adopt page structures, categories, templates, and processes which make sense in the context of each individual WikiProject's means and inclinations. Instead, we are left with a lowest common denominator approach. What works for a project with a dozen members and a hundred articles quite often simply does not work for one with a thousand members and fifty thousand articles; forcing them to adhere to the same structure will almost certainly give neither one what they're actually looking for.
This is harmful because it seeks to destroy any marks of individuality or character that individual WikiProjects have acquired. WikiProjects are surprisingly fragile things; they will not react well to being manhandled so crudely. Creating a bureaucracy that will wander around WikiProjects insisting that "You must!" and "You may not!" isn't going to make anyone but the bureaucrats happy; and WikiProjects don't function well (if at all) when their members are feeling oppressed.
This is harmful because it will introduce a Byzantine set of regulations which editors involved in running WikiProjects will now have to contend with. Changing something is going to involve requested moves, polls, and month-long arguments on policy pages rather than simple discussion among the project members. This is nothing but more work added to what's already becoming a full-time job.

This is, in short, a proposal which favors bot writers and meta-template creators over the WikiProjects it professes to be concerned with. It will do nothing to help either the catatonic WikiProjects—those will stay inactive regardless of how much effort is expended on renaming their sub-pages—or the (unfortunately rare) functioning ones.

(Aside from all this, of course, the overwhelming preference for consistency over common sense has here produced names which are frankly absurd—"Current-quality" indeed!—but that's a minor issue in comparison.) Kirill ^(prof) 01:12, 29 August 2008 (UTC)[reply]

This proposal will not destroy projects' individuality. Wikiprojects will still be free to govern themselves as they wish. There will not be a bureaucracy telling Wikiprojects what they can and cannot do. All we are asking for is for there to be some consistency between projects, so that users on one project don't have to start from square-one when they transition to another.

As for the point about this reducing Wikiprojects to the "lowest common denominator", well, there is nothing stopping Wikiprojects from defining other categories above and beyond what is specified here. There are no regulations on anything other than page, category and template names, and even those regulations cover only a subset of all pages, categories and templates. We're not asking all Wikiprojects to use the same logo. We're not asking Wikiprojects to have the same organizational structure. What we're asking for is a very basic level of compatibility, so that Wikipedia is not balkanized into a warren of incompatible projects.

Think of it like POSIX compatibility for operating systems. The fact that Linux, Solaris, and Mac OSX are all POSIX compatible has not destroyed their individuality as operating systems, has it? By analogy, meeting this basic level of cross-compatibility will not destroy the individual characteristics of Wikiprojects.

Thank you for your feedback,

Quanticle (talk) 15:32, 29 August 2008 (UTC)[reply]

That's a poor analogy to what's being proposed here, in my opinion. POSIX is a fundamentally an API-level specification, not an internal implementation-level specification; so long as an OS provides the needed interface, it's free to implement the underlying mechanism in whatever way it desires.

The equivalent here would be a guideline mandating that all WikiProjects should have accessible page/template/category locations of a certain form—but leaving it up to the individual project whether that location is where the page in question actually resides, or whether it is merely a redirect to an alternate page of the project's choosing. As far as anyone outside the project would be concerned, they could point to the appropriate project pages by using the standard form (essentially, an API for WikiProjects); but it would not prevent the WikiProject itself from using different terminology internally.

Alternately, if you want to make this more sophisticated: create a translation template for each project which converts from the API form (or an equivalent standard representation) to the canonical form; so, say {{WikiProject Topic directory|C-Class category}} would output the actual name of the category. Anyone wishing to implement standardized interfaces to multiple projects could then simply make the needed calls to the underlying translation templates.

But my main point is that there is an unwarranted assumption here that presenting a standard interface for projects can be best (or at all) accomplished by forcing them to rename and restructure their existing setup, rather than by simply adding in the necessary wrappers to make things transparent to both the projects and to external users. Kirill ^(prof) 15:57, 29 August 2008 (UTC)[reply]

All the projects already have some consistency between them, for example they all use the same class and importance names (although not all projects use all classes) but they don't all use the same category naming schema. Also, it's not just bot writers & template creators that will gain advantages from this, users will to. If a user already participates in one project then when they decide to join another, it would be easier for them to find their way about as the layout will be similar. This naming schema is only asking for consistency in a few page names, not what goes on within the projects. There can always be redirects setup as well to accomodate shortcuts. -- WOSlinker (talk) 06:31, 29 August 2008 (UTC)[reply]

Really, the proper way of doing this is to create redirects to the existing pages to fill this (or any other) schema. That way, the rare person that absolutely needs a naming convention that's consistent at the word-substitution level can have it without everyone else needing to jump through hoops. Kirill ^(prof) 12:54, 29 August 2008 (UTC)[reply]

This convention has a limit of common pages, categories, and templates. Not all of the pages, categories, or templates may have been created by a WikiProject, but when a WikiProject does go to create it, the name will be there ready to go. There will be other pages, categories, and templates which are not on the list which are WikiProject specific and are not covered by this convention.
Wikipedia is not a place to express individuality or character of any person or organization within it. This convention is not manhandling, it is giving the WikiProjects a hair cut. Some will get buzz cuts, others will get a better looking hair style.
The list on the project page is about it. If this is adopted; there are bots, users with AWB, and other users with scripts which can do all of the switches. Requested moves is only for controversial moves, so if this is adopted, the move will not be controversial. Polls are not an issue. The name will be set by this naming convention, so no polling will be needed. The only arguments I can see happening is going to be here. Once adopted, there shouldn't be any arguments about the names of things since the naming convention will apply.

As an editor with a semi-wide range of interests, I like to keep track of all of my WikiProjects in one place. It is difficult to remember what the banner template names of those WikiProjects are. It would be so much easier to type {{WikiProject <project name>}} for each of the projects instead of having to remember that X project's template is a truncated name, another is just using the plural form, and another has a really weird name that makes almost no sense. If I wanted to add the user templates to my user page, it would be easy to remember the list of projects, but remembering the names of all of their user templates would be impossible. Some don't have the time to futz with those things, and the harder these things are to find, the less likely the editor will want to be part of a WikiProject.

As for Current-quality, well, it is Current-Class right now. I am thinking about it and may update the proposal when I come or someone else comes up with a better name for not only Current, but also Future and Needed. LA (T) @ 07:10, 29 August 2008 (UTC)[reply]

The pages/categories/templates may be common (or, more precisely, what you're expecting to be on said pages may be); but the names are not, and for good reason. Well-run WikiProjects don't decide on terminology by pulling words out of a hat; there is considerable thought that goes into choices of name and structure. You're basically arguing the position that you know what WikiProjects need better than the WikiProjects themselves.
The last time someone tried to impose the smallest part of what you propose—a single set of category renamings—we had several months of bitter fighting on CFD. Regardless of whether you think WikiProjects shouldn't have any character or autonomy, the fact is that they do, and trying to snuff it out will lead to predictably unproductive conflict all around.
The problem is that some of what's on this page is a bad idea for some (or all) WikiProjects; and thus there will be attempts to bypass the more harmful rules if they're imposed—except now they'll need to be overblown formal ones.

To be rather blunt: this proposals seems motivated primarily by a theoretical understanding of how WikiProjects might work, as opposed to any significant knowledge of how they actually work in practice. Kirill ^(prof) 12:54, 29 August 2008 (UTC)[reply]

A can of worms

First, I wholeheartedly agree that we are currently lacking comprehensive conventions regarding WikiProject structures. Indeed they would desperately be needed for technical reasons, i.e. for use by bots. Currently we're in a quite bad situation in that respect, since some de-facto standards have emerged, usually by each WikiProject imitating the others. But each bot operators needs to guess these "standards" on his own, and they typically break at some point. (I'm not so much convinced that naming standard as such enhance the collaboration of editors, though.)

However, the topic is a can of worms, as evidenced by the discussion above and also by previous discussions. I think that this proposal is the wrong way to address the problem, for a number of reasons.

It overregulates. We should only define standards not wherever they can be made, but where they are really necessary, for technical reasons. What is the point in defining a naming standard for userboxes?
On the other hand, at the points where standardization is really needed, the proposal is not comprehensive. Defining a naming standard is only half of the story (actually much less than 1/2 I think). For use by bots, we need to define what the objects we use are, not only what they are named. See example for banner templates below.
It fails to differentiate between recommended standard and current practice. Since there is no central "authority" which can define a mandatory standard, and due to the large number of WikiProjects, we will not be able to implement a standard (whatever we decide on) on the short term, if ever. So, for the use by bot operators, it is crucial to know to what extent the standards match current practice, and which different solutions are currently used in practice, maybe with some recommendations for workarounds.
It is too rigid. WikiProjects may have many individual requirements; they may or may not use assessments, may have task forces or not (some call them "work groups" or "subprojects" instead); they may have reasons to deviate from naming standards (see e.g. Category:B-Class River articles as opposed to Category:B-Class Rivers articles for Wikipedia:WikiProject Rivers). Also, there is a smooth transition between projects, subprojects, taskforces, etc., which the proposal does not honor.

Not to let this rant grow overly long, let me give an example. I support the idea to standardize the names of banner templates to be of the form {{WikiProject Tulips}}. However, there are many more things about banner templates that one needs to know to code a bot, such as:

Project banners are used on talk pages in order to assign the article to a project. (Actually, are they used on article talk pages only, or in any talk namespace? Or should different templates be used for categories? There was some recent confusion about that on the village pump.)
Project banners categorize the talk pages for assessment purposes, and also for purposes of assigning articles to workgroups. (Vital!)
Project banners should be listed in Category:WikiProject banners or its subcategories. (This is essential for finding a list of all banners!)
Not every project uses an own banner. Some share their banners with a "main" or "parent" project.
Projects can create redirects for the project banner, for ease of editing. For example, {{WPTulip}} could redirect to {{WikiProject Tulips}}. (Very widespread!)

Also, while I support the idea of calling the actual banner {{WikiProject Tulips}}, this is not current practice for all projects. Some would prefer to use, say, {{WPTulip}} as the main banner. (Actually this is the case for more than 50% of the projects.) We won't force anybody to change their preferences. So, one should document this practice, and should recommend to at least create a redirect from {{WikiProject Tulips}} → {{WPTulip}}.

Again, the above is only an example. I hope that we can reformulate the proposal in that way, focusing on what is really essential, documenting current practice, formulating recommendations, and describing them on the detail level required. However, the way the proposal is currently put, I see it going down the road of "no consensus, never implemented", as so many have been before. --B. Wolterding (talk) 16:44, 29 August 2008 (UTC)[reply]

Just these standards

I think that it needs to be made clear in the text on the page that this standard is only for those examples listed. As noted above, WikiProjects often have different needs, and so have a horde of variant pages.

So while this goal to standardise a few phrases is laudable (and I believe it should happen), it should only be those subpages which are pretty much "standard" throughout most WikiProjects. - jc37 20:58, 29 August 2008 (UTC)[reply]

This would to apply to all categories listed as first proposed. Please do not edit the proposal until it is completely discussed here. LA (T) @ 21:08, 29 August 2008 (UTC)[reply]

Editing an ongoing proposal is standard. But ok. If this truly is a walled garden, then Strong Oppose as written. Too much "fluff", and would affect things which are not "standard" throughout the projects. And would create a "standard" for creation of pages which are unnecessary to many, if not most projects. - jc37 21:13, 29 August 2008 (UTC)[reply]

Right. What I'm seeing is this. These pages will not be created unless someone needs them. It will only exist as a possibility for when its needed and will not be automatically created. So when someone wishes to create the page, the will have a standard format to refer to. Much like we have for portals I suppose (not everything is auto-created, and you can choose not to create certain subpages based on your portal, or in this case projects, needs). Synergy 09:34, 30 August 2008 (UTC)[reply]

Jc37, I apologize for the harshness of my first statement in this section. I thought that it was clear that these were to be created as needed by each individual WikiProject. If a WikiProject does not care that articles have navboxes, then the navbox category would not be created for that WikiProject. If the WikiProject has a custom article need, then of course they should create the custom category, such as WikiProject Films or WikiProject Television requiring a Cast section in the film and television program articles, so the categories could be named "Category:<Project> articles that need cast sections." If a WikiProject uses Work groups instead of Task forces, then of course they will have Wikipedia:WikiProject <Project>/Work groups instead of Wikipedia:WikiProject <Project>/Task forces. There may be WikiProjects with both for all I know. There might even be a project that uses Wikipedia:WikiProject <Project>/Committees.

So while there would be a convention in place for naming these items, they do not have to be created for every WikiProject, just the ones who want or need them. If there are a group of WikiProjects that want to get together and make bots or scripts to do create these, more power to them.

And again, I apologize for being so harsh. I hope that you continue to watch and participate in this discussion and can forgive me for acting badly. I have readded all of your additions. Since it seems that this proposal is unclear about the creation of the listed items, I would like to know how often this proposal should have the words "as needed" in regard to the creation of these items and that this is no the be-all-end-all list of items a WikiProject can create. The list was supposed to be some of the most common items found throughout the WikiProject I perused. There may be even more common items that I have not stumbled upon yet in my very narrowly focused area of interest (media). LA (T) @ 09:58, 30 August 2008 (UTC)[reply]

Concerns

I largely agree with Kirill that this level of prescription is harmful, as compelling projects to adopt standards dictated from above breeds only resentment. There is very little point in creating standards for their own sake: in many cases deviations from the common standard have very good justifications and should not be dismissed out of hand. Rather, we must separate out the areas where standardisation confers genuine technical advantages, and where it is just useful to be able to 'traverse' WikiProjects: that is, access pages or categories without going through the main WikiProject directory page.

No one denies, I hope, that there are many pages common to WikiProjects where it is useful to be able to 'traverse' in this fashion. But as Kirill says, there is absolutely no reason why redirects can't be used for this purpose. If a WikiProject's assessment department is located at Wikipedia:WikiProject Tulips/Article grading rather than Wikipedia:wikiProject Tulips/Assessment, then moving it will cause a quantity of disruption and hassle, and possibly unwanted dispute. Simply creating a redirect from one to the other, by contrast, causes no disruption whatsoever and can be implemented without prior approval for that reason. With some thought and preparation, and a tabbed browser, someone could go through and create all these links in a couple of hours at most. Ditto for the majority of other pages mentioned here. Having a schema such as this is valuable, and I would have no aversion to having some assurance that Wikipedia:WikiProject PROJECT/Assessment is guarranteed to take me to the Assessment department of any project. But since it makes no difference whether that page was accessed via a redirect, the hassle of actually moving the pages is entirely unnecessary.

The only time when it would be necessary to consider enforcing a schema rigidly is when flexible redirects are not sufficient to allow easy navigation. WikiProject banner templates are one example where it may be more beneficial in the long run to insist on rigid compliance with a standard. The need for a guarrantee that typing {{WikiProject Foo}} will obtain the banner template for WikiProject Foo is, of course, beyond question; this could be handled with redirects, but there is also an argument that handling these templates with bots and scripts would be significantly easier if they followed a common naming convention. Wikipedia:WikiProject Council/Banner standardisation has some pertinent material on this topic that I wrote a fair while ago, arguing that standardising this area of WikiProject syntax would be beneficial. This is also an area where there are few, if any, downsides to standardising in terms of loss of individuality (as the banners are all very much the same already).

The other area where redirects are inadequate is in category titles. But even here this proposal goes too far. I see no particular need to standardise things like attention categories, as there is rarely if ever a need to traverse these categories. Only the quality and importance categories, in my opinion, require prescription, and even then we must be careful. Projects like WPBiography have chosen to use -priority rather than -importance for very good, and very deep-seated, reasons, and no schema that requires them to change will gain their approval (and rightly so). Similarly, some projects have chosen to use "PROJECT" different in Category:FA-Class PROJECT articles to Wikipedia:WikiProject PROJECT, for very sensible reasons. The fact that many other projects have chosen to use diferent names for no discernable reason whatsoever, is no reason to be so sweeping in proscribing these. More important is to iron out the situations where one project out of a thousand uses a different syntax to everyone else ("FA-class" or "FA Class" instead of "FA-Class", for instance), which can so easily not be handled by bots just because no one thought they were there! Where there is considerable variation, as with Category:FA-Class foooo articles instead of Category:FA-Class Foo articles, we can and do code or work around it; it's when inconsistencies are not expected that there is a real problem.

Finally, and most importantly, the idea of changing the existing partial schema is utterly ludicrous. We currently have ~99.9% compliance with the "Category:FA-Class ASSESSMENT_CAT articles" standard; why would we want to change that? Of course, if we were discussing a new schema for a new system then the situation would be completely different, and using "-quality" would be emminently sensible. But we're not: we're discussing changes that will affect a system of 13,000 categories used by 900 projects with perhaps 5,000 users. The time when we could consider wholescale changes has long since passed.

In summary: this proposal is mainly prescription for prescription's sake, and dictates far more than is required to achieve the necessary outcome. While having a schema is valuable (although not basing it on the existing standards is crazy), redirects can be created to fill a schema with such ease as to make it pointless to fight the huge battles that would need to be won to actually implement such. For the few areas where pages must be moved to comply, or where moving has genuine technical advantages, yes, standardisation is valuable; but only where genuinely necessary. The organic, somewhat jumbled nature of Wikipedia's processes is one of its greatest charms: we shouldn't be attempting to fix what is not genuinely broken. (also)Happy‑melon 09:45, 1 September 2008 (UTC)[reply]

One part that could do with standardising is the name of the categories for non-article classes. For example if you look at Category:Template-Class articles, you will see that 519 end in articles, 46 end in pages and two others that don't end in either. -- WOSlinker (talk) 17:51, 1 September 2008 (UTC)[reply]

Yes, I fully agree. As I said (belaboured, probably :D) the schema should follow the existing conventions where they are reasonably standardised already, and be hesitant about prescribing anything that's not already largely standardised. The fact that "Template-Class articles" doesn't make a whole lot of sense is rather beside the point: if the system was reader-facing in any way, it would be a whole different ball game, but given that it's only exposed to a very small group of editors, let alone readers, it doesn't IMO justify the hassle involved in changing all those categories that do follow a coherent syntax, however unintuitive. Happy‑melon 06:39, 4 September 2008 (UTC)[reply]

Lady Aleena's response

Why not use redirects?: Redirects are just sloppy in areas other than article space unless it is an abbreviation for an oft used policy. Page moves take very little effort. I have moved a project from one name to another and did all of the redirect clean-up. As of right now, that project only has only a few redirects left to the main page, and I am considering getting them deleted too.
Banner standardization: I will cheer lead this effort across as many WikiProjects as I can, if you so desire. I would love to be able to type {{WikiProject Foo}}, {{WikiProject Bar}}, {{WikiProject Baz}}, and {{WikiProject Qux}} on a talk page and know that the right banners would show up. It takes so long to try to find the banners of WikiProjects. It took me four tries to remember the name of the banner for WikiProject Films on one talk page once.
Why standardize attention categories: Let's say that there is a person who is trying to keep track of all WikiProjects' articles that need copy editing, such as WikiProject Articles Needing Copy Edit. Now, with a standardized naming convention for all of the "articles that need copy editing" categories; a single user, with a list of all of the WikiProjects, could generate a list of all of the "<Project> articles that need copy editing" categories with one find and replace command in a text editor. You may notice the class of the outside div called check-icon. class="check-icon" will suppress red links, so only those WikiProjects with the "articles that need copy editing" categories would be listed. As WikiProjects create that category for themselves, the list will grow without the need to go back into this list to add the new category. A person in Wikipedia:WikiProject Templates could do the same thing for the templates' categories, or any other project that helps fix articles which have issues which cross WikiProject bounderies.

Board and table games
Books
Doctor Who
Dragonlance
Dungeons & Dragons
Fantasy
Films
Forgotten Realms
Games
Greyhawk
Highlander
Horror
Maryland
Media franchises
Museums
Novels
Role-playing games
Science fiction
Star Trek
Stargate
Television
Time
Video games

<div class="check-icon" style="-moz-column-count:3; column-count:3">
<div>[[:Category:Board and table games articles that need copy editing]]</div>
<div>[[:Category:Books articles that need copy editing]]</div>
<div>[[:Category:Doctor Who articles that need copy editing]]</div>
<div>[[:Category:Dragonlance articles that need copy editing]]</div>
<div>[[:Category:Dungeons & Dragons articles that need copy editing]]</div>
<div>[[:Category:Fantasy articles that need copy editing]]</div>
<div>[[:Category:Films articles that need copy editing]]</div>
<div>[[:Category:Forgotten Realms articles that need copy editing]]</div>
<div>[[:Category:Games articles that need copy editing]]</div>
<div>[[:Category:Greyhawk articles that need copy editing]]</div>
<div>[[:Category:Highlander articles that need copy editing]]</div>
<div>[[:Category:Horror articles that need copy editing]]</div>
<div>[[:Category:Maryland articles that need copy editing]]</div>
<div>[[:Category:Media franchises articles that need copy editing]]</div>
<div>[[:Category:Museums articles that need copy editing]]</div>
<div>[[:Category:Novels articles that need copy editing]]</div>
<div>[[:Category:Role-playing games articles that need copy editing]]</div>
<div>[[:Category:Science fiction articles that need copy editing]]</div>
<div>[[:Category:Star Trek articles that need copy editing]]</div>
<div>[[:Category:Stargate articles that need copy editing]]</div>
<div>[[:Category:Television articles that need copy editing]]</div>
<div>[[:Category:Time articles that need copy editing]]</div>
<div>[[:Category:Video games articles that need copy editing]]</div>
</div>

Why standard names for quality and importance: Here is a table that I whipped up in 5 minutes (4 of which were from a false start on the Excel spreadsheet and tinkering with the formatting).

	FA	FL	A	GA	B	C	List	Start	Stub
Media franchises	0	0	0	0	0	0	0	0	0
Books	0	0	0	0	0	0	0	0	0
Novels	0	0	0	0	0	0	0	0	0
Films	0	0	0	0	0	0	0	0	0
Television	0	0	0	0	0	0	0	0	0
Fantasy	0	0	0	0	0	0	0	0	0
Science fiction	0	0	0	0	0	0	0	0	0
Horror	0	0	0	0	0	0	0	0	0
Doctor Who	7	4	0	155	134	352	59	413	360
Highlander	0	0	0	0	0	0	0	0	0
Star Trek	20	6	0	158	87	382	57	953	182
Stargate	1	0	0	21	16	44	24	61	21
Games	0	0	0	0	0	0	0	0	0
Board and table games	0	0	0	0	0	0	0	0	0
Role-playing games	0	0	0	0	0	0	0	0	0
Dungeons & Dragons	10	6	6	30	43	299	44	633	834
Greyhawk	0	0	0	0	0	0	0	0	0
Dragonlance	0	0	0	0	0	0	0	0	0
Forgotten Realms	0	0	0	0	0	0	0	0	0
Video games	0	0	0	0	0	0	0	0	0
Maryland	41	17	1	166	507	1,357	268	5,021	4,889
Museums	29	5	1	128	504	2,277	733	8,437	7,408
Time	4	1	0	14	201	468	1,630	888	811

Now, you can see there are a lot of blanks in that table that shouldn't be there using the current semi-convention for naming quality class categories. Almost all of the blanks are because the project uses something that differs from the actual project name. These categories should be given the name of the project with an initial capital letter. There is no WikiProject film, WikiProject television, or WikiProject novel. There are WikiProject Films, WikiProject Television, and WikiProject Novels. Why aren't Films, Television, and Novels (all proper nouns in this context) used for those projects' categories?; Also, I suggested the change from -Class to -quality to match -importance. Top, High, Mid, Low, and NA are all -importance classes, so FA, FL, A, GA, B, C, Start, Stub, and List are all quality classes. It just makes more sense to me to have the quality class categories accurately reflect what they represent. Class could apply to quality or importance. I also suggested a change from Unknown-importance to Unassessed-importance to make those match as well.
Why, with so many in compliance, should there be a change?: There should be no difference between what one project names their assessment category and another. This convention would trim down the WPBannerMeta considerably. (Could that banner be renamed to something like WikiProject MetaBanner which is easier to remember?) It is also through that banner that most of the changes could be made with so very little effort on the part of the projects. With so many projects using the meta-banner, just a few changes to it would recategorize hundreds, more than likely thousands, of articles with one press of the "Save page" button. Two of the sub-pages of that banner would no longer be needed if this is accepted, meaning even less maintenance to it.
Is this a new schema?: This could be considered a new schema for WikiProjects pages, categories, and templates which would replace the current dysfunctional one.
Why do you Lady Aleena care?: I care because I would like to see a day when these categories are easy to find, easy to template, and just easy to use. I am only on dial-up which means that it takes a long time for most pages on Wikimedia to load on good days. I have to be very precious with what pages I try to load and wading through some WikiProject pages is time consuming when it takes on average 30 seconds to a minute to load each page. Some WikiProject pages are so busy that it boggles the mind. Redirects make navigation to pages even longer.
Conclusion: If this is accepted, and there is a large enough group of admins, users, and bots willing to do the page moves, category deletions, and template replacements, this would be a mostly painless process. LA (T) @ 08:56, 4 September 2008 (UTC)[reply]

Don't believe it will work

I have a job keeping up with the internal standards of one WikiProject. Although I can see some benefit in what you are proposing I doubt you will ever achieve it or maintain it. Redirects just mean that people can make plenty of mistakes currently proliferating the banners, page name etc. If the aim is not achieved it will just make things worse. The "only" way it will be better is if you manage the total renaming of the entire WikiProject world. Hmmmm.! :: Kevinalewis : ^{(Talk Page)}/_(Desk) 15:49, 9 September 2008 (UTC)[reply]

Kevinalewis, this could work if more people got on board with the concept. The convention could be slowly implemented in so many ways. It could start with just having all of the WikiProject banners renamed, the participant categories renamed, or having the whole article assessment scheme overhauled with the new names.

Why are there dozens of variations on the names of the assessment categories? Shouldn't they have all been named the same way from the beginning? Why is it such a big deal to rename a user category for the people in a WikiProject from member to participant (members need not do anything, while participants participate)? What is wrong with streamlining templates so that their code is small and compact instead of spread across half a dozen subtemplates? This convention would make things so much easier once implemented.

Instead of having...

we would have...

{{WPThis|class=|importance=}}
{{ThatProj|class=|importance=}}
{{TheOtherthing|class=|importance=}}

{{WikiProject This|class=|importance=}}
{{WikiProject That|class=|importance=}}
{{WikiProject The Other thing|class=|importance=}}

{{UserWPThis}}
{{Wikipedia:WikiProject That/Userbox}}
{{TheOtherthingUserbox}}

{{User WikiProject This}}
{{User WikiProject That}}
{{User WikiProject The Other thing}}

And the examples of how this convention could streamline things could continue. LA (T) @ 22:47, 10 September 2008 (UTC)[reply]