Wikipedia talk:WikiProject Council

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

WikiProject X Newsletter • Issue 9[edit]

WikiProject X icon.svg
Newsletter • May / June 2016

Check out this month's issue of the WikiProject X newsletter, featuring the first screenshot of our new CollaborationKit software!

Harej (talk) 00:23, 25 June 2016 (UTC)

@Harej: It is not clear from your newletter(Technical improvements to Reports Bot) which reports are accurate and which ones are work-in-progress. For example: Wikipedia:Database reports/WikiProjects by changes? please ping me — Preceding unsigned comment added by Ottawahitech (talkcontribs) 16:06, 10 July 2016 (UTC)
Ottawahitech, all the reports should be accurate. Are there reports that are not accurate? Harej (talk) 18:55, 11 July 2016 (UTC)
@Harej: The numbers just do not seem plausible. Take for example wp: WikiProject Canada, a project with 130,878 articles which shows only 719 edits for the last 365 days in Wikipedia:Database reports/WikiProjects by changes. Ottawahitech (talk) 00:54, 12 July 2016 (UTC)please ping me
@Ottawahitech: Based on the report code, it is counting changes to the WikiProjects main and sub pages, for example Article alerts, and not changes to the WikiProjects articles. --Bamyers99 (talk) 02:53, 12 July 2016 (UTC)
@Bamyers99: Thanks for digging up this information. So I guess what you are saying is that Wikipedia:Database reports/WikiProjects by changes does not track edits to the articles belonging to a w-project but merely edits to the w-project pages themselves? Even so I still believe the # of edits to wp: WikiProject Canada seems too low. If you check Wikipedia:WikiProject Canada/List of Canadian WikiProjects, portals and main articles you will see how large this w-project is. Just the Article alerts of all the child w-projects should generate thousands of edits every year (wp:Article alerts are updated daily)? Ottawahitech (talk) 14:34, 15 July 2016 (UTC)please ping me
@Ottawahitech: It doesn't count sub-project edits, only edits to pages prefixed with WikiProject Canada/. Sub-projects have their own edit counts if the project name is prefixed with WikiProject. --Bamyers99 (talk) 14:49, 15 July 2016 (UTC)

Overhaul of article assessments[edit]

I think we should overhaul the way that article quality is assessed. I believe the current system is outdated and flawed for several reasons. Some ideas to explore would be:

  1. Implement a Wikipedia-wide assessment criteria, rather than each WikiProject using their own scale. This would mean that WikiProjects would have to agree on an article's quality, although in 99% of cases they do agree now anyway.
  2. Separate type from quality. The current interplay between the type of a page (e.g. article, file, template, list, portal, etc.) and its quality (e.g. start, c, b, a, featured, etc.) is confusing and does not allow for many valid quality assessments. For example why shouldn't we have a C-class list, an A-class portal or a beta-rated module?
  3. Move quality assessments out of WikiProject banners. If there is one quality assessment for the article, it would make more sense to put it in a redesigned {{article history}} template and remove it from the project banners.

I propose that each project should continue to tag articles within their scope and assess the article's importance to their project (but that we use the superior term of "priority"). I realise this is a massive task and this is my first post on the issue, but any initial comments would be helpful. Regards — Martin (MSGJ · talk) 11:40, 20 July 2016 (UTC)

You might want to consider pinging the active WikiProjects to this discussion. (Re-numbered bullets for ease of reference.)
  1. In 99% of cases, this would be fine. I suspect however that there will be some projects who want their own control, or where the WikiProjects will differ on rating, or where some projects have deprecated certain quality rating (A-class being a prime example). What exception do they have in such a world?
  2. Yes, please. Edge case question: are drafts a quality or a type?
  3. What does an implementation of this look like given the present category scheme of "WP:VG B-class articles"?
  4. Is some of this superfluous to the WP:FLOW work (yet to begin) which was to help with workflows (and not just the infamous talk page refactor)?
--Izno (talk) 12:10, 20 July 2016 (UTC)
Thanks for your comments.
  1. In the proposed world there would be one common assessment framework (which would be arrived at by detailed discussion and consensus). A starting point would likely be Wikipedia:Version 1.0 Editorial Team/Assessment#Grades. I imagine that for articles, Stub/Start/C/B/GA/FA would be uncontentious. Whether A-class (traditionally a WikiProject specific process) and the B-class checklist would be used is less certain. There would be nothing to stop WikiProjects maintaining guidelines on how the assessment criteria should be interpreted for articles in their scope, but in the event of disagreement, grading would be determined by discussion among any involved editors on the article's talk page.
  2. Interesting question, to be determined later. (My instinct would be that drafts are a type, because you can have all sorts of quality of draft article.)
  3. To preserve the current category tree it would probably be necessary to keep the parameter, but the display could be suppressed. (It's just not necessary for 13 separate banners to proclaim that Barack Obama is FA-class. Alternatively we could probably replicate the functionality by using category intersection tools.
  4. Sorry I am not familiar with much of the Flow work. Will do some reading.
— Martin (MSGJ · talk) 14:31, 20 July 2016 (UTC)
  1. I think keeping the B-class checklist would be a good thing (it's referenced at #Grades). A seems less valuable, but maybe the articles where an A-class assessment has been arrived at are under only a few domains (maybe we should sample the A-class list to see if there are any which are not already FA-quality, which is clearly the superior ranking; GA's relation to A-class is a bit more murky, as it has always been).
  2. Certainly something that can be sorted later.
  3. How does one keep the parameter and also keep the page-wide assessment? Category intersection is the answer I expected, but I can see people calling foul...
  4. Sure. It may be the case that this is a stepping stone to a workFlow world, since I suspect we would need to make many of the same changes for Flow.
--Izno (talk) 14:44, 20 July 2016 (UTC)
  • Support Yes, this is useful. The current grading system was introduced in 2003 and has not been developed since 2008. See Wikipedia:Version 1.0 Editorial Team for context. This entire awful system was only intended to be used as a tool for selecting Wikipedia articles to burn to physical CDs, and not for community management as quickly became its use. English Wikipedia has suffered from the legacy of the founding proposal ever since. There was never any time when this system was thoughtfully proposed to be used as it is now. It would be worthwhile to draft a proposal for change then seek support for implementing it. Any WikiProject which wanted to opt-in to the change could, and any WikiProject which wanted to continue with the old ways might. Overall, I think that one grading system for all WikiProjects is best. There has never been sufficient labor from enough WikiProjects to justify maintaining so many independent grading systems, and the current system has never worked as it was designed.
Yes, any sort of page could be graded in the same way, or not graded. Yes, importance and priority could be similarly reassessed.
There needs to be a new grading system. "stub, start, C, B, A (never use A!), GA, and FA" is nonsense jargon. Blue Rasberry (talk) 16:04, 20 July 2016 (UTC)

My general feeling is that any attempt at radical overhaul is just going to be met with opposition, it might be more productive to try some smaller, piecemeal reforms. I do agree that there's a lot of room for improvement in the current system, though. To address the points you raise:

  1. As you already note, we more or less have this already with Wikipedia:Version 1.0 Editorial Team/Assessment#Grades. Very few WikiProjects deviate from this scale in practice.
  2. Yes and no. Yes in the sense that all of this non-article, namespace-based crap that's latched itself onto the assessment scale (Category-Class, etc) really ought to go. But I don't think it needs to be replaced with anything, the idea of giving quality ratings to portals and templates just seems like it would be a waste of everyones time.
  3. Agree in principle, when you see half a dozen or more banners lined up each with the same assessment, you have to wonder if this is really the best way of doing things. I don't use {{article history}} much but it doesn't seem at all user friendly and is probably not ideal for this purpose. Perhaps displaying an assessment in {{WikiProject banner shell}} would be an idea? The point Izno raised about the current "X-Class Foo article" category scheme is probably the best argument for maintaining the status quo. Category intersection looks like a feature request that isn't going to happen anytime soon, so I'm not sure what the best solution would be.

--PC78 (talk) 11:01, 21 July 2016 (UTC)

PC78 I could be mistaken but I do not anticipate resistance. Just so long as a new grading system was only optional and was rolled out to individual WikiProjects, I think many WikiProjects would voluntarily adopt it. There used to be info about the number of active participants at any given WikiProject but for privacy reasons, it is no longer available. Still, a general rule is that any WikiProject has not more than 10% of the number of watchers as listed at Wikipedia:Database reports/WikiProject watchers (usually closer to 5%). I think many WikiProjects actually could have a thoughtful discussion and choose a change. Also, I do not anticipate many people having loyalty to the old system. So far as I know, most users think it fails to communicate clearly. I have heard lots of complaints but never heard anyone talk about it being clever, easy to understand, and easy to use. Blue Rasberry (talk) 11:33, 21 July 2016 (UTC)
Bluerasberry, I think you underestimate the degree of resistance—not to the idea of improving the assessment system, which is something that I think everyone can get behind (although people will doubtless have their own ideas about what that looks like), but to the proposal to remove individual WikiProjects' ability to customize the system to meet their particular needs.
So that we have a specific example to consider, WP:MILHIST has implemented a number of "unique" assessment features over the years, including:
  1. A dual assessment hierarchy, with parallel tracks for lists versus "prose" articles (WP:MHA#SCALE).
  2. Automatic assignment of all assessments between Start-Class to B-Class based on a checklist in the template (WP:MHA#CRIT).
  3. Automatic tracking of articles based on improvement needs identified in the assessment checklist (Category:Military history articles needing attention).
  4. A formal review process for A-Class status, complete with assessment tags and bot support (WP:MHR).
  5. Automatic inheritance of both assessments and task tracking across 50+ task forces (Category:Military history articles by task force).
All of these are potentially open to discussion and improvement, but we're certainly going to object to a proposal that simply gets rid of our entire assessment system in favor of a one-size-fits-all shared rating. Kirill Lokshin (talk) 12:06, 21 July 2016 (UTC)
Kirill Lokshin I fail to recognize a proposal here to forbid customization, so I think I agree with you. I must have made myself misunderstood. I am not imagining a future in which any WikiProject is compelled to use any system. I just want another system on the table for any WikiProject to have another option. Blue Rasberry (talk) 13:01, 21 July 2016 (UTC)
Bluerasberry, my interpretation of the original proposal ("Implement a Wikipedia-wide assessment criteria, rather than each WikiProject using their own scale", "Move quality assessments out of WikiProject banners") was that we were indeed talking about prohibiting WikiProjects from using customized/project-specific assessment systems, not just offering an alternative to the current model. MSGJ, is that what you have in mind, or am I misunderstanding? Kirill Lokshin (talk) 13:43, 21 July 2016 (UTC)
@Kirill Lokshin: I think you're right, at least that's how I read Martin's proposal. I don't think the basic idea is too problematic though, WP:MILHIST is very much the exception rather than the rule, and even you guys don't appear to be doing anything radically different. There should be enough common ground for some constructive debate, at the very least. PC78 (talk) 00:19, 22 July 2016 (UTC)
With reference to the proposal regarding assessment. There is definitely an appetite for universal assessment - see User:BU RoBOT/autoassess. The bot is taking requests from Wikiprojects and then bringing their unassesed articles in line with other wikiprojects. Personally I don't see difference between doing that and pulling out all assessments from opted-in wikiprojects into a universal rating, whether that's part of {{article history}} or otherwise. Jamesmcmahon0 (talk) 11:31, 22 July 2016 (UTC)
@Kirill Lokshin and PC78: MSGJ still has not commented but I see the base concept as usable for a proposal making things optional. I agree that nothing can be forced on WikiProjects, and if everyone agrees on that point, then let's drop forced changes as a potential direction for development.
Most or all of the criteria at WP:MHA#CRIT have nothing to do with military, and it has always been the case that any WikiProject could adapt that or any other assessment criteria for their own needs. The way that I interpret the proposal is to strip a criteria sheet like the military one into something with no WikiProject focus. Then, those criteria are presented as a recommendation for a default for any WikiProject without specialized needs. I would like to reconsider the scale of grading and the nature of criteria, because I think it is already well known that grading and interpreting grades is very difficult for non-Wikipedians. Also I would like for bot projects like the one Jamesmcmahon0 mentioned to be able to do automatic grading in the same scheme. I do not immediately see potential for conflict because I do not anticipate much love for the current system. Making other schemes optional seems like a reasonable thing to discuss now or soon. The controversial part of this is that multiple grading systems would circulate simultaneously, and in the longer term, they would compete for broader uptake. Blue Rasberry (talk) 14:05, 25 July 2016 (UTC)
Bluerasberry, I believe that {{WPBannerMeta}}, which virtually all projects use, already provides a "common" set of criteria; see, for example, {{WPBannerMeta/hooks/bchecklist}}. As far as changing the actual grading system (by which I assume you mean the assessment "classes") is concerned, I'm open to discussion, but please keep in mind the significant amount of volunteer time that would be required to switch to a different system; any entirely new system would need to offer enough benefits to justify that implementation cost. Kirill Lokshin (talk) 15:04, 25 July 2016 (UTC)
I am open-minded to assessment improvements coming from a fairly reached consensus. However, I don't think we should be telling projects whether to use 'importance' or 'priority', as 1) I think it's unnecessarily butting in; and 2) these terms can have different meanings within a project (e.g., 'importance' meaning how key the article/subject is to the larger subject the project covers, and 'priority' implying some kind of near-term workflow that could be based on importance and other factors). As for quality assessments, I generally concur that in most cases, this determination should be consistent, and that the type of a page isn't a quality. Stevie is the man! TalkWork 15:21, 21 July 2016 (UTC)
  1. Support I think that would be a good idea (maybe there need to be some exceptions). Also all WikiProjects using the same quality-scale allows for better analysis of Wikipedia's overall content. Note that the participants of WikiProjects need to be actively made aware of the scale instead of it being hidden away in some obscure Wikipedia:Version 1.0 Editorial Team/Assessment#Grades (e.g. a description of the quality should display when hovering over the quality-class in the WikiProject banner with the mouse and the WikiProject pages should all feature this table).
  2. Support (with reservations: some types simply can't be properly rated by quality) Very much agree! Even categories could be rated by the state of their completion. It's most evident for list-class articles: those can also have differing qualities (e.g. by state of completion or e.g. the content in the "description" columns of tables etc) - I intend to make a separate post about that later if this discussion doesn't resolve it.
  3. Oppose An article could have differing quality ratings per WikiProject e.g. if it's perfectly informing about one aspect but missing crucial information about another the WikiProject of the first aspect could have a B rating while the second just has a start rating. This is useful so that members of the 2nd WikiProject can become aware of the state of the article's info on their subject and improve it etc.
--Fixuture (talk) 20:10, 3 August 2016 (UTC)
  • BHG's thoughts, if this discussion hasn't already gone stale. (And congrats to [[User:MSGJ|MSGJ] for starting this discussion).
  1. Support a project-wide grading scale. Different projects will bring their own tests for each level of grading, depending on the needs of the subject matter, but the principle of a common scale is sound, and long overdue.
  2. Limited support for extending the quality rating to other content types. I agree with Fixuture that quality-rating is much needed for lists, but I am not sure that it would be helpful for templates, and I think that it would be next-to-useless for categories. That's because the two main quality issues with categories are a) the selection of articles in them, and b) their parenting in other categories. The selection of articles will constantly vary as new articles are created and then diffused to sub-cats, and all of that happens without any edit to the category page, so watching categories for such changes would be a maintenance headache. As to parenting of categories, that again depends on the state of other categories, so a static assessment is useless. If anyone wants to pursue this idea of quality-rating categories, please start a discussion at WT:CAT.
  3. Support (in principle) taking quality assessments out of project banners (maybe with projects free to decide to retain their own rating, but I'd prefer not). I broadly support the idea of a single quality assessment, and am unpersuaded by the objections. Where projects disagree on the grading (e.g. a biography of someone with a notable career in more than one discipline), the article should simply be given the lowest relevant grade. A single grading which works this way will force more collaboration and create an incentive to build well-rounded articles.
    My caveat is a technical one. AFAICS, projects are the main users of the quality assessments, and there are bots which compile very valuable lists and counts of articles by quality and by quality-vs-priority. If the quality assessments are no longer in the project banners, this must be done in such a way that these bots can still create these listings. Other tools may depend on the current setup, and those tools must not just be broken by the changes.
--BrownHairedGirl (talk) • (contribs) 15:30, 30 August 2016 (UTC)
Why would {{article history}} be "not ideal"? It already indicates whether an article is a GA or an FA, so why not extend it to the other classes if we're replacing the class parameter on WikiProject banners? Graham (talk) 05:29, 31 August 2016 (UTC)

Some relevant technical changes in the pipeline[edit]

I've been following this discussion because I'd like to see how potential changes to the assessment would align with planned improvements to the software. For starters, there is the upcoming PageAssessments database table, which will store WikiProject–article pairings in a database table so that they can be queried through the API (and through the database replicas on Labs). Note that the table is designed to work with whatever assessment setup we have—it's very flexible and not designed to change editorial workflows. But I am also planning on including a new feature as part of a MediaWiki extension to allow WikiProjects to define their scopes directly through the WikiProject page, rather than use the current banner/category system. (They can continue to use those if they want, but they won't have to.) And in the long term, I would like to get assessments off of the talk page and into the aforementioned PageAssessments table, with a special page assessment interface.

In terms of how soon all this will happen: the PageAssessments database table will happen soon, but with no visible changes to the interface (Kaldari could speak more to this), the MediaWiki extension will be ready in a few months but will be optional, and the idea to take assessments off of talk pages and into an assessment interface is a very long-term idea that is not even close to started yet.

If people are talking about changes to article assessments, I am interested in hearing what people want to change and what people want to see kept the same. I think there is general agreement that non-articles should not have to be assessed like articles, and we should differentiate page type from page quality. I think while people generally support the idea of a "universal" article rating, there are also particular projects that take their own assessment process very seriously. So I think WikiProjects should be able to either (a) inherit a universal rating or (b) use their own system. This way, projects don't have to be burdened with the chore of assessment if they don't want to, while projects that do want their own assessments would be able to choose so.

What do people think of this approach? Kirill, would this be satisfactory to the military history project, in your opinion? Harej (talk) 20:44, 8 August 2016 (UTC)

Oooh, I like it. Great news.
The next phase would ideally be to get rid of Project Banners, and allow some central table technique for recording whether a page is within a project's scope. --BrownHairedGirl (talk) • (contribs) 18:34, 30 August 2016 (UTC)
What if some projects don't agree to getting rid of project banners with nothing to replace them? What if these projects want to maintain this "connective tissue" (cynically speaking, advertising) to their projects? My thought is even if we got rid of banners, projects would still need some form of communications outpost on the pages in their scope -- and I would prefer something that shows on the article page rather than talk, similar to how we show links to an article in other languages. Perhaps it could work out similarly to how "Related pages" (beta) is being done: Have an optional "In scope for these WikiProjects" section somewhere. Stevie is the man! TalkWork 19:06, 30 August 2016 (UTC)
@Stevietheman: I would oppose getting rid of project banners with nothing to replace them. I suggested an alternative. --BrownHairedGirl (talk) • (contribs) 23:47, 30 August 2016 (UTC)
If being in a central table means some kind of reflection that a reader can see on the article page, that would be an acceptable alternative. If it just means its in the table and there's no connection from the article to the project, then it wouldn't be, IMHO. Stevie is the man! TalkWork 05:17, 31 August 2016 (UTC)
Stevietheman, BrownHairedGirl, having a central table automatically output WikiProject affiliations is doable. But without delving too much into the politics of talk page banners, at the very least I would like to get the ratings/project affiliations out of the banners and into a central table for the purposes of storage. This way, even if we keep the banners the way they are, they would simply broadcast what is stored in the central database. Harej (talk) 19:40, 1 September 2016 (UTC)
@Harej: thanks for the clarification. That's just the sort of approach I hoped for. If the banners aren't needed for recording assessment, then the community is free to consider a range of possibilities for advertising the relationship between project and article. My own preference would be for some sort of single list of relevant projects, conceptually similar to the banners collapsed inside {{WPBS}}, tho in a less bulky and repetitive format, but others may have other preferences.
Re-reading my earlier msg, I see that it was a bit clumsily worded, and appeared more sweeping than I intended. I think that the current banners are too crude and fragile a way of storing the metadata they contain. I also think that they are too visually intrusive, and that we can do much better. --BrownHairedGirl (talk) • (contribs) 21:08, 1 September 2016 (UTC)
As someone who was here when we started this talk page tagging mess: The entire reason we are using WikiProject templates for tagging is that it originally was the closest we could get to creating an assessment database without creating a table / assessment UI on the MediaWiki side of things. (Robchurch looked at how to get the assessments and other maintenance categories out of the talk pages an eternity ago but nothing came out of it.) Category memberships were used because they were easy to traverse, and acted as poor-man's key-value pairs. The {{Template-Class}}, {{NA-importance}} and other non-article siblings came out of the desire to tag pages with WikiProject templates without having the unassessed pages increase, but otherwise have no real reason to exist.
As for per-Wikiproject ratings: If I were to code this up, I would store multiple assessments for each assessed article. In each row of the table, I would store a tuple with the article, WikiProject, quality assessment, importance assessment, and a foreign key to a log id entry containing the current revision and username of the assessor. You could have multiple rows per article: a "default" row (with the WikiProject being set to blank or some sentinel value) and rows for unique WikiProjects. The WikiProject rows would have the quality/importance columns empty unless the WikiProject wants to override the default value (so that WP:MILHIST, WP:WPTC and the like can keep their A-Class assessments running if desired). We would then have three scenarios:
  1. The user would set the default quality/importance assessments (create the default row for the article, and populate the quality and importance fields in this row) and create WikiProject rows for each banner on the talk page. The WikiProject rows would only have the project field populated initially. This action would be logged as an initial assessment.
  2. A WikiProject participant would set the quality, importance or both assessments for the article (modify the WikiProject row for that particular WikiProject by setting the quality and/or importance field to a non-blank value.) This action would be logged as a WikiProject assessment
  3. A user could override all the quality assessments for an article in the case an article gets promoted at WP:GAC or WP:FAC. So the default row's quality column would be modified, and the quality column in the WikiProject rows would be emptied. This action would be logged as an assessment override. (Technically, you could/should also provide a way of overriding all WikiProject importance assessments, but I don't see a use case for this.)
The only part I'm not sure how to store would be things like B-Class checklists; those could be put in a binary blob field or a searchable JSON field. Titoxd(?!?) 19:45, 30 August 2016 (UTC)

WikiProject Jazz R.I.P.[edit]

Wikipedia:WikiProject Jazz is apparently defunct. I just clicked on its sole external link and deleted it: it was

*Wikiproject Watchlist - WikiProject Jazz

and leads to a page with the browser bar title "404— Not Found", saying

Leaving Wikimedia
Wikimedia Labs requires notification of when leaving the Foundation's sphere of influence. (BTW, they're total hypocrites)
Don't show this warning again

Before that, its last edit was on 8 September 2015‎.

--Thnidu (talk) 02:52, 14 August 2016 (UTC)


As that text implies, the target page has moved, and is now at:

-- Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:34, 22 August 2016 (UTC)

WikiProject directory X2[edit]

Was working on Wikipedia:WikiProject Council/Directory to make this directory like the other directories.... did it mainly because the template there was simply to hard to read on mobile devices and I wanted to add a search option (prefix = Wikipedia:WikiProject ). So all good i think the page looks good having a search option and more readable. All that self-praise said...was going to make a new shortcut called WP:WPDIR but to my surprise it was taken redirected to Wikipedia:WikiProject Directory. So basically we have 2 directories. User:Harej did a great job on the new directory as it seems to be automated (much better the the old system I think). However Wikipedia:WikiProject Directory is not viewed very often because Wikipedia:WikiProject Council/Directory has all the incoming links from nav template etc... What should we do here? merger? keep both a manual index and an auto-updating index? I do think the title Wikipedia:WikiProject Directory is better. So???? This would also bring up what to do with {{WikiProject Footer}} as of now it links to all sub page of Wikipedia:WikiProject Council/Directory not the sub pages of Wikipedia:WikiProject Directory. -- Moxy (talk) 18:45, 29 August 2016 (UTC)

Thanks for all your work on this, Moxy. I agree that Wikipedia:WikiProject Directory is probably the better title (provided that the first letter of "directory" is uncapitalized). Having an automated directory makes a lot more sense given how infrequently this one is updated, but if we are wanting to get rid of the Council one (which I think would be the best choice), I would prefer that a couple features be moved over:
  1. Indication of weather the WikiProject is listed as inactive: I imagine this could be done fairly easily by using Category:Inactive WikiProjects (which is added to WikiProject pages through {{WikiProject status}}). We could also potentially indicate which WikiProjects are semi-active (though that might be overkill) and perhaps exclude those WikiProjects that are defunct.
  2. Clear marking of task forces and work groups: We could detect task forces and work groups by using categories with a standard naming pattern (either "WikiProject Tulips task forces" or "WikiProject Tulips work groups"). They could be marked in the directory simply by listing them immediately after the parent project(s), indenting the title, and removing the prefix "WikiProject Tulips/".
Any thoughts? Graham (talk) 20:07, 29 August 2016 (UTC)
While ideally the automated directory would be best, Harej is not sure we can replace the Council one yet, and looking at the number of missing WikiProjects in that page, I can't say I disagree. Titoxd(?!?) 19:54, 30 August 2016 (UTC)
@Titoxd: While of course it can't be done overnight (and I don't think Moxy or I meant to suggest otherwise), it's certainly something we can work towards. Including the missing projects and changing the heading structures in the topic sub-directories is simply a matter of categorization. James, is it set up to automatically change the headings if subcategories are added or removed from the topic categories (e.g, Category:Art and culture WikiProjects)? And what do you think about the two items I raised above? Graham (talk) 21:00, 30 August 2016 (UTC)
Graham11, the headings (and even the subpages) are all automatic based on the category tree. So getting WikiProjects to show up in the right section/subsection/subpage is a matter of sorting into categories. Re. associating task forces with projects, my plan was to do that with Wikidata, since that is the "cleanest" approach (page titles do not easily distinguish between what is a task force and what is just a plain old subpage). Here is the entry for the World War II task force as an example. For marking WikiProjects as inactive, I would rather go with an objective measurement, since I do not think the active/inactive templates are used consistently. Would fewer than three active project participants (in the last 30 days) be a useful indicator of inactivity?
On a more general note, I was not planning to propose to the Council to replace the manually updated directory with the new one until the new one could do the same things as the manually updated directory; basically the reasons Titoxd brought up. Admittedly, I have not had time to work on the directory. I hope to find more time soon, but in the meantime, a simple way to help is by adding WikiProjects to categories; I would recommend checking against Wikipedia:WikiProject Council/Directory. Hopefully we can make progress on this sooner rather than later! Harej (talk) 20:16, 1 September 2016 (UTC)

WikiProject banner tags or stub templates?[edit]

As this subsection is currently written (first line = "WikiProject assessment banner tags and stub templates often seem to serve the same purpose, yet they have distinct functions.") it gives the impression that their differences are more nuanced than they are, and doesn't explicitly state that the presence of one shouldn't exclude the addition of the other. This subsection also shouldn't be the very first subsection in the section on article tagging. I'd like to go ahead and propose the following:

  • 1. Move this subsection to the bottom of the article section, making the "Purpose of WikiProject banner tags" subsection the first one.
  • 2. Add a WP:PROJSTUB short cut.
  • 3. Rewrite the text to the following:
WikiProject banner tags and stub templates
WikiProject banner tags and stub templates serve different functions, so the presence of one does not exclude the inclusion of the other. WikiProject banner tags typically remain on an article's talkpage indefinitely, and perform many functions for the relevant WikiProject. Stub templates, however, seek to categorize all small articles across Wikipedia (including those without any relevant WikiProject), and are removed once the article is expanded. As such, there is a large effort to coordinate stub usage across both articles that fall under the scope of a relevant WikiProject and those that don't (this is the main reason why there is a semi-formal proposal process for stub templates and categories). For more information see: Stub types, WikiProjects, and assessment templates.

Thoughts? M. A. Bruhn (talk) 03:44, 6 September 2016 (UTC)

Seems reasonable to me. It does seem odd that it currently immediately jumps into the stub vs. banner discussion without first talking about the purpose of banners. Stevie is the man! TalkWork 14:25, 6 September 2016 (UTC)

Why was this project’s page changed?[edit]

This project’s page has been changed recently with no discussion (I think?). I can’t find my way there anymore. Anyone? Ottawahitech (talk) 14:56, 13 September 2016 (UTC)please ping me

I was wondering the same thing, although the result of the restructuring/cleanup looked satisfying, so i kept mum. What info is hard to find? Stevie is the man! TalkWork 15:27, 13 September 2016 (UTC)
Was just a code change so people on mobile devices could see it (no real content change). What is the problem...what cant be found?-- Moxy (talk) 19:46, 13 September 2016 (UTC)
@Moxy: You have made 13 edits to the page between 5-12 September. Clearly more than "a code change so people on mobile devices could see it'. Would you please elaborate on your changes. Thanks. Ottawahitech (talk) 14:01, 18 September 2016 (UTC)please ping me
Uh, those changes are simply to the order of stuff on the page — so yeah they're pretty minor. What can't be found? Carl Fredrik 💌 📧 14:06, 18 September 2016 (UTC)
I removed column codes ( as they dont work on MB properly) - removed 2 dead links....added a link to FAQs and to Wikipedia:Orphaned articles by WikiProject. i also removed a parent cat that was not needed. I am done with the updates to the council pages in all related pages pls fell free and review. When we get the automated directory up and running i will take the time to fix all that is needed. -- Moxy (talk)

WikiProject class dispute[edit]

If there is a dispute about the class of a particular article, how can I get advice and assistance? Another editor says that an article should be class=disambig, and I made it class=C. Now it is a matter of dispute on my talk page.--Dthomsen8 (talk) 15:18, 19 September 2016 (UTC)

Usually, with any question about assessment where there is not immediate and obvious consensus, it's good to request comment from the users at the WikiProjects's talk pages to have a discussion on the talk page of the affected article. I have commented at your talk page about this specific matter. --Izno (talk) 15:40, 19 September 2016 (UTC)

Regarding Afghanistan[edit]

Afghanistan should be in South Asia according to this. — Preceding unsigned comment added by 14:46, 24 September 2016‎ PratyushSinha101 (talkcontribs)


When I look at Talk:Maryam Monsef I see the banner for WikiProject Canada appear on the right side of other project banners. Am I the only one? Ottawahitech (talk) 16:37, 1 October 2016 (UTC)please ping me

Fixed. WP Canada's banner was using small=yes. Stevie is the man! TalkWork 17:03, 1 October 2016 (UTC)