Below is an email response from myself to Wiki. It is regarding my first experience with a solicitation for a charitable contribution from Wiki. I think it could really help, and I hope that it does.

Hello,

Thank you!! I was on Wikipedia today, as most days, looking into the various definitions for "Dynamism" and how they applied to the research I recently have been conducting in the science of sound acoustics. I'm buying new speakers, and the information is readily available, so who wouldn't, right? LOL I saw that one discipline specific definition and explanation was not available, which is incredibly rare. I thought to myself, "I can finally start to repay my ""Wicked-Pedia"" friends for the endless free and instant access to a entire planets knowledge base". It was obvious that no one was jumping at the idea to contribute to the computer science related explanation of dynamism. Just at that moment, I was stunned by a pop up, and before I could read it, the gory demise of the last remnant of everything still good and pure about the internet flashed before my eyes. It was probably the first ever audible gasp of relief heard coming from someone when they were asked for money. I believe the message I read was tastefully crafted by Jimmy Wales. That impassioned plea is what has me writing you today. I don't have the means to have $3.00 coffee, which is why I usually contribute with acts like researching and writing about the exciting field of computer dynamism. I mainly donated my whopping 3 bucks as a last ditch effort to copy the exact message from Mr. Wales to paste and share in my Facebook posts. As you can probably tell, I was unsuccessful in that endeavor. I had a last hope that the message would be included in the pop up to share to Facebook through your link, but that wasn't to be the case either. The copy written there is inherently true and eloquent, however Mr. Wales' version will generate donations for you that, I sincerely believe, will be exponential comparatively. $3.00 in my budget will have to be reconciled, which may seem unbelievable to you, but the idea of helping a truly deserving recipient will easily trump an end of the month overdraft charge. I now have to graciously and respectfully ask for you to give me a bit of help so that I can help you greatly. I would please ask that you reply back with Mr. Wales message, so that I may rapidly get it out to my modern grass roots marketing militia for immediate distribution across the anti-social networking platforms. I know, anti-social networking is flippantly sarcastic, but I have to have a little fun along the road of life, right? I also have to implore you to consider taking his message and adding it to the share link as opposed to, or in addition to, the current copy. If there is a way to add sharing that link to Facebook, Twitter, etc. as a donation option in your payment gateway, along with Mr. Wales plea, the vast majority of "not now's" will share that link. That creates a potential for multiple donations from a "Not Now" share, which otherwise would be a definite "NO" contribution. Some potential is always better than NO potential. I hope this message finds you well and that my insights may contribute to keeping the beacon of light that is Wikipedia burning strong. I need to always be able to explain to my children about the struggles that inexorably come along with doing great things and continue to use Wikipedia as the principal example of that fact. I thank you in advance for taking the time to read this and I have earnest hopes that this will help. Again, many thanks for all that you do.

Sincerely,

Eric Steven Cook — Preceding unsigned comment added by EricStevenCook (talk • contribs) 21:00, 7 November 2017 (UTC)

Hi Eric, Maybe I misunderstand the gist of your message as it is well camouflaged by the surrounding verbiage, but are you asking for the facility to spam the social media with requests for donations to support WMF by a click? Cheers, · · · Peter (Southwood) ^(talk): 06:57, 8 November 2017 (UTC)

@EricStevenCook: - Well here you go, this is Jimbo's message, its hardly difficult to find by the way, it is permanently available on foundationwiki here. You can reuse it under this creative commons copyright license however if you want to engage in the worthy cause of fundraising for the MediaWiki Foundation you may need to familiarize yourself with the fundraising principles and applicable law, read the fundraising guidance and talk to the fundraising team about your idea if it goes beyond your immediate social group, friends and family. Generally speaking, fundraising is done by the foundation itself in relation to the general public. Dysklyver 12:41, 12 November 2017 (UTC)

An appeal from Wikipedia founder Jimmy Wales

I got a lot of funny looks ten years ago when I started talking to people about Wikipedia.
Let’s just say some people were skeptical of the notion that volunteers from all across the world could come together to create a remarkable pool of human knowledge – all for the simple purpose of sharing.
No ads. No agenda. No strings attached.
A decade after its founding, nearly 400 million people use Wikipedia and its sister sites every month – almost a third of the Internet-connected world.
It is the 5th most popular website in the world – but Wikipedia isn’t anything like a commercial website. It is a community creation, written by volunteers making one entry at a time. You are part of our community. And I’m writing today to ask you to protect and sustain Wikipedia.
Together, we can keep it free of charge and free of advertising. We can keep it open – you can use the information in Wikipedia any way you want. We can keep it growing – spreading knowledge everywhere, and inviting participation from everyone.
Each year at this time, we reach out to ask you and others all across the Wikimedia community to help sustain our joint enterprise with a modest donation of $20, $35, $50 or more.
If you value Wikipedia as a source of information – and a source of inspiration – I hope you’ll choose to act right now.

All the best,

Jimmy Wales
Founder, Wikipedia

P.S. Wikipedia is about the power of people like us to do extraordinary things. People like us write Wikipedia, one word at a time. People like us fund it, one donation at a time. It's proof of our collective potential to change the world.

Your thoughts on this are welcome here or at m:2017 Community Wishlist Survey/Reading. In the normal diff it is often difficult to see changes to the text of an article because of all the formatting, template and other code. (Flip between these two images a few times.) At the Wikimedia Wishlist, I’ve proposed WMF develops a simple diff so patrollers, editors and authors can see at a glance how the meaning of an article has been changed. This, obviously, isn’t meant to or going to replace the normal diff. It’s just an additional tool. —Anthonyhcole (talk · contribs · email) 07:49, 13 November 2017 (UTC)

Um, how is "Simple diff" easier than "Normal diff"? It fails to show the replacement of text with templates, the modification of citations, and more. Also, how does it handle transcluded templates? Apparently it displays the result of the template (look at the 40/104 item in the second line of each item); does this mean that the diff will change later if someone edits the template? And will it display changes to infoboxes, bottom-of-article navboxes, etc? Nyttend (talk) 00:40, 14 November 2017 (UTC)

An ongoing WMF project they call “visual diff” is reaching maturity now and, with little tweaking, I think it will fulfil my wish here. You can access the visual diff feature while using the visual editor by clicking “view your changes” and “visual (beta)”. If I can link to a visual diff from a page’s history, and that seems eminently doable, that will meet my needs. It looks like the visual diff will include template changes - not sure about transclusions, images, Wikidata infoboxes, Nyttend. —Anthonyhcole (talk · contribs · email) 04:46, 14 November 2017 (UTC)

Looking for some feedback here. Please do leave your comments. —TheDJ (talk • contribs) 07:54, 15 November 2017 (UTC)

I started a deletion discussion for Template:Authority control at Wikipedia:Templates for discussion/Log/2017 November 15#Template:Authority control. As this is a template that is in use on more than 500,000 pages, and at the same time the TfD is currently only visible to people watching the actual template or TfD, I thought dropping a note here would be good. Feel free to spread the word at other neutral boards as well (or WP:CENT if you think it is warranted). Fram (talk) 16:13, 15 November 2017 (UTC)

The community is invited to comment on the appeal lodged by Δ at Arbitration Requests for Clarification and Amendment.

For the arbitration committee - GoldenRing (talk) 11:13, 18 November 2017 (UTC)

We have a few Wikipedia articles that have passed peer- or expert-review. I think it would be a service to the reader to put a prominent self-explanatory button at the top of such articles, linking readers to the reviewed version. Also, I’d like to see a similar button (prominent, self-explanatory) linking the reader to a simple diff that clearly shows the reader how the article/topic has evolved since the review.

Review quality is everything here. Most of us would link the reader to a version that had been reviewed by the leading academic journal in the field. We’d probably all decline a review managed by big pharma. I’m inclined to hold the bar very, very high: only link to versions where the review was managed by an entity with a reputation for independent and rigorous review in the relevant field.

Thoughts? —Anthonyhcole (talk · contribs · email) 12:12, 19 November 2017 (UTC)

I could accept putting it in the "article milestones" section at the top of the article talkpage (in the same way that we link the versions that have passed/failed Wikipedia's internal review processes—see Talk:May Revolution for what's probably the canonical example of an article that's been through multiple review processes). I'd be opposed to making the link to the reviewed version prominent on the article itself. "Consensus can change" applies to reality just as much as it applies to Wikipedia, and if there were new developments subsequent to the reviewed version, we'd effectively be intentionally directing readers to an outdated article. To take an extreme example, if we treated the version of Barack Obama that passed FAC as the flagged revision, we'd be telling our readers that this was the version of his biography they should trust. (Besides, who decides what constitutes an "expert" for these purposes? For topics like civil engineering there's not much controversy and there are recognized and undisputed experts, but when you get into something like economics or politics you'd be lucky to find two experts who agree on anything, and when you start heading into fringier or more controversial stuff the experts are pretty much the last people who should be judging due weight. Would you want the leading experts in homeopathy deciding what the appropriate tone of [[Homeopathy]] should be? Are the Vatican or Richard Dawkins really the best-qualified people to assess Religion?) ‑ Iridescent 18:20, 19 November 2017 (UTC)

Regarding your Barack Obama example, I don’t think that’s the kind of topic that would fit this model. But to your point that reliable sources go stale: of course. I hope that an expert-reviewed article would be reviewed periodically, to keep the expert-reviewed version up to date. Meanwhile, I’m proposing two prominent links at the top of the article: one to the reviewed version and one to a simple diff, so the reader can see the difference between the reviewed and current versions. It would be clear to the reader that the linked, reviewed version was superceded by the current version

Entities with decades (or centuries, in some instances) of experience and an established reputation for quality review should decide what constitutes an expert for these purposes. I suggested above that we only endorse reviews performed by independent bodies with an existing good reputation for this kind of work. I have in mind, particularly, the editorial boards of highly esteemed journals that cover the topic. We would no more accept a review of Homeopathy managed by Multidisciplinary Respiratory Medicine (see [1]) than we would use an article peer-reviewed by them as a source. I, personally, wouldn’t accept anything less prestigious than JAMA, NEJM, Lancet, BMJ or the like for general medical topics, Movement Disorders or similar for movement disorders, Pain, Journal of Pain or similar for that, etc. I, personally, don’t think we should settle for anything but the editorial boards of the most highly-regarded journals in each relevant topic. Yes, there will be many topics - entire fields actually - where the scholarship is too flakey or nonexistant for this to work. So, we don’t do this on those topics.

The point of this exercise is to make one version of the Wikipedia article a WP:RS, something that can be cited in journal articles, school projects and even other Wikipedia articles. The point is for the reviewed version of a Wikipedia article to be the most trustworthy encyclopedia-style treatment of a topic, period.

Take a look at Parkinsons disease. BMJ selected a panel of reviewers to pick it apart. The panel included the person most responsible for the current worldwide standard diagnostic criteria for PD and another who is not only the most-published author of peer-reviewed articles on PD but also one of the main drafters of the proposed new diagnostic criteria. I wouldn’t, personally, want us to endorse anything less than that calibre of review, but when we do have such a version, I think we owe it to the reader to point them to it and show them how the current version differs.

Look at Dengue fever. This version passed peer review by a now-defunct open access Canadian journal. This is a simple diff showing how the article/topic has evolved since the review. For the record, I wouldn’t endorse linking our readers to that reviewed version. The journal doing the review isn’t nearly reliable enough. —Anthonyhcole (talk · contribs · email) 23:03, 19 November 2017 (UTC)

I think you've answered your own question then. (I.e. no). Wikipedia's reviewing power is spread out too thin as it is. Best practice is to reinforce the GA or FA process. Cas Liber (talk · contribs) 23:36, 19 November 2017 (UTC)

I’m talking about a process after an article has reached FA. Next time you bring a medical article to FA, I’ll arrange for the most highly-regarded relevant journal to review it for you, if you like/dare. 😏 —Anthonyhcole (talk · contribs · email) 23:50, 19 November 2017 (UTC)

There is nothing to stop anyone reviewing a Wikipedia article if they choose to do so, so go right ahead, It would be interesting to see how well it would be received. Particularly since FA is very much a group effort where any interested party can contribute. · · · Peter (Southwood) ^(talk): 06:07, 20 November 2017 (UTC)

Yes to all of that, Peter. —Anthonyhcole (talk · contribs · email) 18:09, 20 November 2017 (UTC)

It also occurs to me that outside of a few fields like medicine, there's nowhere near as much of a culture of peer review, and it's not going to necessarily be obvious what constitutes "expert review". I can cite that Russell Potter (who literally wrote the book on the Franklin Expedition) described my Halkett boat article as "far more detailed and better illustrated than anything I have seen in printed sources"—which in this admittedly niche field is literally the best endorsement possible—but there's no way I'd consider it a formal review. I'd worry that (as you allude to yourself above) by effectively creating a quality rating that can only ever be applied to articles on certain topics, in terms of public perception we're effectively saying "everything else is unreliable". (Readers can't be expected to understand Wikipedia's arcane internal rules; if they regularly see "quality assured" markers on medical articles but never see them on articles about music, the conclusion they'll quite reasonably draw is "Wikipedia's musical articles are consistently poorer quality than its medical articles".) ‑ Iridescent 19:06, 20 November 2017 (UTC)

Wikipedia is an unreliable source. FA and GA stars don’t confer an assurance of accuracy. Parkinsons disease was a featured article when it went to the BMJ and it was riddled with inaccuracies - some quite serious. Yes, if we point out to the reader that a version of a Wikipedia article is reliable, it may remind them that the rest of Wikipedia is not. I don’t, myself, see that as a sound reason to block this proposal.

It may be possible to devise a trustworthy expert-review process for topics like obscure history and some aspects of music, too. It won’t look exactly like this model (just appropriating the existing journal review process) but it may be doable. I’d like to start with this fairly simple medicine option and then see how other academic domains respond. I hope you’ll reconsider your opposition. —Anthonyhcole (talk · contribs · email) 01:59, 21 November 2017 (UTC)

Thank you for this conversation. I appreciate you hearing me and your very thoughtful responses. Can I ask you to allow this for articles reviewed under the terms I've outlined above - where the review is managed by a publisher with a good reputation to defend and conducted by the topic's leading researchers and thinkers, whose reputations, too, will be on the line? I realise a lot of thought needs to go into how/if this can work for topics outside medicine. But this model will work for medicine. This model will offer the reader an option they don't presently enjoy: a Wikipedia article they can trust. --Anthonyhcole (talk · contribs · email) 10:45, 21 November 2017 (UTC)

The WikiJournal of Science, in the process of being set up, and the already up-and-running WikiJournal of Medicine provide something like that - a peer-reviewed, journal-published version of a good article that is then available as a pdf permalink. No preferential linking is planned at this point though, as far as I know. --Elmidae (talk · contribs) 09:04, 20 November 2017 (UTC)

I'm aware of the Wiki Journal of Medicine. I wish them success but would not support linking to their endorsed versions from mainspace until we get a better measure of the quality of their reviewing. --Anthonyhcole (talk · contribs · email) 11:31, 20 November 2017 (UTC)

• Putting some type of indicator that an article has been peer-reviewed or expert-reviewed provides a good idea, providing that the article really has been peer- or expert-reviewed. One thing we would need to be careful about is protecting such indicators from vandalism. Vorbee (talk) 16:40, 20 November 2017 (UTC)
• I support Anthonyhcole's proposal to prominently identify those articles that have gone through an extensive review by recognized experts in the topic at the top of an article. The reviewing 'experts' and their affiliations would be helpful to see. At least let us try this on Medical/Health articles. Best Regards, Barbara (WVS) ✐ ✉ 01:36, 23 November 2017 (UTC)

Just to announce that for the last five days of Wikipedia:WikiProject Women in Red/The World Contest we're offering a bonus prize of $200 worth of books of the person's choice for whoever creates the most new (satisfactory) women biographies by the end of the month, minimum 1kb of readable prose and no sourcing issues. If you need a bunch of books to help you with editing I propose that people join in! ;-)♦ Dr. Blofeld 22:09, 25 November 2017 (UTC)

Some users cannot trust Wikipedia when for example want to disclose a economic law that public don't aware of it in some particular countries. I propose that Solution a. Wikipedia asks for bitcoin from open proxy editors so allow them to edit or Solution b. Shows their edits of articles on a different tab. — Preceding unsigned comment added by M-G (talk • contribs) 03:26, 23 November 2017 (UTC)

Wikipedia doesn't ask for money so that people can edit. Tor is blocked because it is easily abused by vandals. As I understand it, a user could still create an account and then apply for IP block exemption. — Insertcleverphrasehere ^{(or here)} 07:00, 23 November 2017 (UTC)

@Insertcleverphrasehere: Tor users cannot create accounts, and the error message – the standard "Your IP address is in a range which has been blocked on all wikis" (not specific to account creation) – doesn't make it clear that they can ask someone to create an account for them. Jc86035 (talk) 12:33, 25 November 2017 (UTC)

Ok... but presuming that they could briefly have access to a non-Tor IP, they could quickly create an account, and request IP block exemption. — Insertcleverphrasehere ^{(or here)} 19:40, 25 November 2017 (UTC)

@Insertcleverphrasehere: If they're using Tor and need IP block exemption they might not have access through a non-Tor IP anyway. The bitcoin thing is not particularly helpful because not everyone uses it, but it would be helpful to change the block message. I've asked on Wikipedia:Village pump (technical)#Account creation for Tor users. Jc86035 (talk) 05:13, 26 November 2017 (UTC)

@Insertcleverphrasehere: The problem is fear of evil trade between Wikipedia (or its staff) and some governments that don't like independent writers, When I create account with real IP what would be point of using proxy for future edits? Wikipedia still can identify me using IP log.

You can give users an option to see or hide proxy users edits.

Could you plase rename it like "Hyperloop UPV", please? I'm new here and I don't know if this matter should be even here.

Thanks--Manesmo1 (talk) 19:11, 27 November 2017 (UTC)

Manesmo1  Done - Next time consider asking at The Teahouse, our dedicated forum for new editors to seek help and feedback. GMG^talk 19:15, 27 November 2017 (UTC)

• I would have opposed the proposal, basically per what TonyBallioni said. But I'm glad to see there was a discussion, I've been wondering if we have ever discussed criteria by which we determine if an article should be full-create-protected versus ECP-create-protected. I always set create protection to sysop because I don't know when I'm supposed to use ECP. Ivanvector (^Talk/_Edits) 15:21, 28 November 2017 (UTC)

  EC protection was created mainly to allow for the enforcement of ArbCom and community decisions on specific high-controversy topic areas which are likely to attract armies of meatpuppets with little interest in abiding by Wikipedia policies and community principles. It was never meant as a general type of protection to be assigned willy-nilly just because we don't want to "deal with" problems proactively. While the community has since expanded EC protection as a part of the general suite of tools we use to combat disruptions, it should still not be a tool of first resort when less drastic methods can be tried. It's one of those "according to demonstrated need" tools that we shouldn't apply just because we're too lazy to monitor problems. --Jayron32 15:33, 28 November 2017 (UTC)

  It seems to me that extended-confirmed creation protection is itself a less drastic method than the full creation protection that administrators typically applied prior to the introduction of extended-confirmed. Because of this, I've also shared Ivanvector's uncertainty at times whether to apply full creation protection or extended-confirmed creation protection. If we follow the principle of "less drastic first" to conclusion, it seems that we should be applying extended-confirmed protection as a first resort for salting articles, and then, if EC is ineffective, full protection. (Currently, as Ivanvector notes, most admins jump straight to full protection.) Mz7 (talk) 04:40, 29 November 2017 (UTC)

I opened up an RFC on proposed changes to the Film:MOS regarding proposed guidelines for production sections. You can vote on it here, Thanks --Deathawk (talk) 06:05, 29 November 2017 (UTC)

Hi, Everybody. I want to make a proposal at Phabricator to slightly enhance the Search Wikipedia box that is at the top of every Wikipedia page. Before doing so, I need a consensus here, at the Village Pump. Please alert other interested parties to this proposal, but without canvassing or tooling the outcome

I use the search box constantly, but most times it would improve my workflow to have the search box open in a new tab, window, or popup (I do not care about that detail - any one will do). Most times I want to leave my active window intact, so having a new tab, etc. would allow that. This would also ensure that there is no loss of data during an edit session.

If my explanation is not clear or complete, please comment below. An alternative would be to have a radio button or such to give the option to opt-in/opt-out of having it open in a new tab or window.

I have searched the list of persistent proposals, and the FAQs, and I do not see a previous proposal for this. If there is one, please direct me to it. Having fun! Cheers! ((u|Checkingfax)) {Talk} 23:13, 21 November 2017 (UTC)

(note: !votes are not a traditonal vote. They are a discussion and poll to reach consensus. To that end, please give a rationale, policy, guideline, or citation to back up your !vote. An !vote without backup will be ignored)

Option #1: Open Search Wikipedia request in a new tab, window, or popup box

(please !vote Support, Oppose, or Neutral, along with your rationale)

Discussion for option #1

Option #2: Open Search Wikipedia request in a new tab, window, or popup box, but with a radio button or such

(please !vote Support, Oppose, or Neutral, along with your rationale)

1. Support – as nominator. ((u|Checkingfax)) {Talk} 23:13, 21 November 2017 (UTC)
2. Support. I don't think it's a good idea to have it automatically open a new tab, as sometimes I just want to leave a page. I could see the use case for such a button, however. ProgrammingGeek ^talktome 23:21, 21 November 2017 (UTC)

Discussion for option #2

Option #3: Put option in User preferences to enable open in new tab/window

(please !vote Support, Oppose, or Neutral, along with your rationale)

Discussion for option #3

Option #4: Oppose all options

(please !vote Oppose, along with your rationale)

• Oppose - AFAIK, all popular browsers provide an easy way to open a new tab. For me, it requires two mouse clicks and no keyboard input to open a new tab and show my watchlist, which, like all WP pages, contains a search box. The proposed enhancement would save me one or two clicks, assuming I actually want a separate tab. The downside is that it increases complexity, which is a detriment for less-tech-savvy users. Tab/window management should be at user's discretion and under their control. Any kind of new element such as a button increases visual clutter on the page, another form of complexity. Emphasis should not be on minor time-savers for power users, who are already quite productive. On balance and all things considered, cost exceeds benefit. ―Mandruss ☎ 05:56, 22 November 2017 (UTC) ADD: Also oppose new option #3 per my comments in the General discussion section below. ―Mandruss ☎ 12:07, 25 November 2017 (UTC)
• Oppose - What @Mandruss said. It's very easy to change a regular link into one which opens a new tab, just by holding the CTRL key when you click (at least when using a Chrome browser on Windows, YMMV). We don't need to add more stuff to the UI. Chuntuk (talk) 07:48, 22 November 2017 (UTC)
• Oppose - This would just add to the already heavy UI, and it would just confuse new users and be of no help to regular users, who have likely already figured out how to open a new tab from a link. RileyBugz^会話_投稿記録 12:10, 28 November 2017 (UTC)
• Oppose – per Izno and Deskana (WMF) in the discussion section below. Violates Technique G200 of the W3C Web Content Accessibility Guide 2.0. Mz7 (talk) 17:36, 29 November 2017 (UTC)

Discussion for option #4

General discussion

• This is bad web accessibility. --Izno (talk) 23:31, 21 November 2017 (UTC)

  Indeed; also some browsers, like Opera 36, do not switch to the new tab, so you may think that the link hasn't been followed. --Redrose64 🌹 (talk) 23:51, 21 November 2017 (UTC)

  How do those browsers react to a popup box instead of a browser window or tab? Having fun! Cheers! ((u|Checkingfax)) {Talk} 01:07, 22 November 2017 (UTC)

  Hi, Izno. Your link actually provides many cogent reasons why a new tab, window, or popup would be ideal. Thank you for that link. One of the times I want a new tab, etc. is when I am in an edit session. Another is when I want to copy/paste off the new window. Plus, a few more scenarios. Awesome! Having fun! Cheers! ((u|Checkingfax)) {Talk} 01:37, 22 November 2017 (UTC)

• @Checkingfax: Two points. First, the term is "!vote" (pronounced "not-vote") not "iVote"; more at WP:!VOTE. Second, having three identically-named yet different "Discussion" headings is not good, so please can we have unique headings? --Redrose64 🌹 (talk) 23:47, 21 November 2017 (UTC)

  Hi, Redrose64. You are a wise sage. Will do. My bad. If I botch it, feel free to edit it. Having fun! Cheers! ((u|Checkingfax)) {Talk} 00:56, 22 November 2017 (UTC)

• As noted above, I oppose the two options you've given us. I'll suggest a third which I'm neutral on: allow users to specify in their Preferences whether search results should open in a new tab/window or not. I don't personally think this would be worth the trouble of doing, but if someone has the time and ability to do it I don't mind. Chuntuk (talk) 07:48, 22 November 2017 (UTC)

  I like having a preference as well; maybe we could even write a gadget or something to make it less of a mediawiki dev issue. Enterprisey (talk!) 11:25, 22 November 2017 (UTC)

  Hi, Enterprisey. I have added an option above to make it a preference rather than a radio button for opt-in/opt-out. Can you please support or oppose that? Also, feel free to reword the proposal to align it with your thoughts. Thank you. Having fun! Cheers! ((u|Checkingfax)) {Talk} 10:38, 25 November 2017 (UTC)

  I'd like to see a significant degree of interest in that. We shouldn't be adding options on the desire of a few editors for a minor new "nice-to-have" feature. We probably have too much of that in Preferences already. It would be really interesting to see counts of active editors who have changed each option from its initial value. That would be something worth doing. ―Mandruss ☎ 12:12, 22 November 2017 (UTC)

  Something similar was done several years ago when there was a concerted effort to remove some preferences. Maybe it would be a good idea to take a second look. --Izno (talk) 15:47, 22 November 2017 (UTC)

• This proposal would cause the search box to violate Technique G200 of the W3C Web Content Accessibility Guide 2.0. Making Wikipedia less accessible is not a good idea. --Dan Garry, Wikimedia Foundation (talk) 13:02, 22 November 2017 (UTC)

Hi, Dan Garry. I believe you are misinterpreting G200. If using a search box would cause one to lose session, then G200 states that a new tab or window would be appropriate. Izno already mentioned this angle, and I thought I already pointed out the logic error.

2. "The user is logged into a secured area of a site, and following a link to a page outside of the secured area would terminate the user's logon. In this case opening external links in an external window allows the user to access such references while keeping their login active in the original window."

Requesting a search, while in an editing session, does result in a loss of session data. This is bad UX. LOL. Having fun! Cheers! ((u|Checkingfax)) {Talk} 23:33, 22 November 2017 (UTC)

No, it is you who is misinterpreting G200, which deliberately recommends avoidance of opening links in new tabs/windows unless necessary. Performing a search on Wikipedia is decidedly not following a link to "a page outside of the secured area", nor does it terminate one's login session. While there are indeed times when opening a search in a new tab or window would be preferred, in the vast majority of times, it actually isn't necessary. Think about searching from the Main Page. Why would I need to keep the Main Page open as a tab if I'm searching for something else? I suspect this change would cause more annoyance to readers than benefit, and Izno and Dan Garry are both spot on when they point out that this would reduce web accessibility. Mz7 (talk) 17:34, 29 November 2017 (UTC)

• I just love Safari sometimes. Command-enter or command-click and done :) —TheDJ (talk • contribs) 17:02, 22 November 2017 (UTC)

Hi, TheDJ. You have found a way to do that from within Search Wikipedia box? Having fun! Cheers! ((u|Checkingfax)) {Talk} 23:35, 22 November 2017 (UTC)

Isn't this standard on most browsers? Type something in the search box and hold Ctrl if you're on Windows or Command if you're on Mac, then click enter. Update: Works on Safari for sure. Google Chrome it looks like you might need to hold Shift. Mz7 (talk) 17:40, 29 November 2017 (UTC), 17:41, 29 November 2017 (UTC)

I propose that we automatically display the following template at the top of every page in the draft space ((Draft top)) Or something very similar, containing basic help, links to find sources, and a reminder to not copy-paste the page when it's ready for inclusion. This would guide newbies, and significantly cut down on WP:REPAIR requests, where roughly half of the requests are from the draft space. Headbomb {t · c · p · b} 17:31, 30 November 2017 (UTC)

• Support, but coupled to acceptance of the assumption that DraftSpace is *only* for new article drafts. DraftSpace is not the right namespace for notes and other resources. These can go in userspace, article talk subpages, WikiProjects, or other places in projectspace, whatever is appropriate. DraftSpace is not a good place to draft article spinouts. Preliminary drafting of a spinout belongs on the article talk page or a subpage of the article talk page, with discussion on the article talk page. Spinouts in draftspace are too easily unwatched POVFORKS.

A ((Find sources)) on every draft could only be helpful.

Basic information that would also be very helpful includes:

• Do not COPY-PASTE. Submit the draft, or WP:Move it, but do not copy-paste.
• Discuss this draft, ask questions, give feedback, on its talk page.
• Consider improving coverage of mentions of this topic in existing articles *before* asking for this page to go to mainspace.

--SmokeyJoe (talk) 22:00, 30 November 2017 (UTC)

Discussion (Draft Header Template)

• There is a preexisting ((Draft article)) template that could be merged with the one you created for this purpose. Mz7 (talk) 19:26, 30 November 2017 (UTC)
  • I prefer the ((Draft article)) template – if we're going to automate this, I'd rather that the ((Draft article)) template be used. --IJBall (contribs • talk) 01:35, 2 December 2017 (UTC)

At present many Wikipedia biographical articles have an infobox in the top right corner and a set of succession boxes near the foot of the article. In some cases, often for politicians, so many different offices are listed in the infobox that it becomes more of an info-column, stretching way down into the article. See Winston Churchill and Tony Blair for examples of this. This is not a neat way of summarizing information which is what the infobox is presumably supposed to do. The same information about offices held is then duplicated in the succession boxes at the foot of the article - in a more easily read format though. I suggest that the infobox for biographies should ordinarily be limited to the one appointment for which the subject is best known. In unusual cases where a person is known roughly equally for two different roles then these might both be listed in the infobox. In extreme cases we might run to three appointments but no more. Greenshed (talk) 00:02, 23 November 2017 (UTC)

I addressed this exact problem in a past Signpost article here and got an infobox that extended for a couple of miles into the planet's core. Best Regards, Barbara (WVS) ✐ ✉ 01:44, 23 November 2017 (UTC)

Thanks - I shall take a good look at your Signpost article. However, what I really want is to establish a WP guideline (or similar) that I can refer to when pruning infoboxes (of which I also am generally a fan). Greenshed (talk) 01:52, 23 November 2017 (UTC)

I'd have to say I'm opposed to making this policy or a guideline. If inflated infoboxes are a problem, I'd rather that be addressed with consensus on a case by case basis, considering sometimes its important to show that a person held multiple important infoboxes upfront (like Robert F. Kennedy, who served as US Attorney General and a US Senator, or Moise Tshombe, who served as President of the secessionist State of Katanga before becoming Prime Minister of the Congo [even if his infobox doesn't immediately reflect that, I think it probably should]). Heck, even the Churchill article you mentioned actually has most of the offices he served in collpased by default, which is actually a rather nifty way of handling things. Also it should be noted that infoboxes are not required to be present on office-holders' articles. -Indy beetle (talk) 21:13, 24 November 2017 (UTC)

Thanks for your comments. First off two subsidiary points. 1. I am not against listing two important offices - e.g. for Robert F. Kennedy, US Attorney General and being a US senator. 2. A guideline would still allow for the development of consensus in unusual cases. Anyway my main point is that while I grant that collapsed multiple offices in infoboxes are better than not, this still duplicates what is in the succession box. I suggest that I would be better to have a link in the infobox titled something like "more offices" which links to the succession boxes rather than expand out a huge column. It is much easier to follow at a glance what someone did year by year in the succession boxes than scroll and scroll down through a long and thin column. This sort of information is analogous to an annex to the main article and is better placed near the end. In any case, would you agree that, by default, the infobox should not extend below the lead and the contents table? Greenshed (talk) 20:19, 25 November 2017 (UTC)

I can appreciate the spirit of such a default but I could not accept the implementation of the letter of it (even "Guidelines" hold a lot of weight around here and you can bet somebody will do just that). An FA-class article I've written, Marcel Lihau, would already violate such a principle. It also makes the infobox contingent off of the size of the lede of an article and the size of the ToC, which is unfair as these parameters are bound to vary article to article (I also note that this may change depending on the size of the screen a page is viewed on). I mentioned the Lihau article because its an abnormally small FA bio with a slim lede that could be affected by such a change. I'm still putting my weight behind the collapsed method. I'd also like to point out to those below me that predecessor and successor parameters are often useful navigation tools for our users, who might not wish to scroll all the way to the bottom of an article to see whether or not succession boxes are present. In my experience, infoboxes are much more prevalent than succession boxes. -Indy beetle (talk) 05:50, 27 November 2017 (UTC)

You've clearly done some good work on the Marcel Lihau article and I do not wish to decry that. Personally, I would move "Secretary of State for Justice of the Republic of the Congo" and "Commissioner-General of Justice of the Republic of the Congo" sections in the infobox into a comprehensive set of succession boxes at the foot of the article, delete the fact that his successor as First President of the Supreme Court of Justice was Bayona Bameya from the infobox and move the fact of his resting place (Gombe, Kinshasa) from the infobox into the main body of the article. I would do all this to ensure that the lead and especially the infobox only convey the key facts. (see Choess's comments below to the effect that immediate predecessor and successor aren't [usually] very germane). The consequence of this would be to probably get the infobox down to a size whereby it did not extend below contents table on most standard screen resolutions. More generally, it's not the Marcel Lihau type of articles that I have in mind and going a bit below the contents table would perhaps be ok (although maybe not ideal). For years we have had quite a few GA+ biographies with infoboxes stretching down towards the core of the earth (to borrow an expression). Having this debate over and over again on every article's talk page would really be too much for me to take this problem on. Greenshed (talk) 01:05, 28 November 2017 (UTC)

To prove the point, I tried thinning out the infobox on Auxillia Mnangagwa. This was reverted (in good faith) pretty quickly (https://en.wikipedia.org/w/index.php?title=Auxillia_Mnangagwa&oldid=prev&diff=812716383). If editors think that there is a problem with over-sized infoboxes then something like a guideline will be needed.Greenshed (talk) 01:13, 30 November 2017 (UTC)

Tentatively support, at least in principle. This is a well-known failure mode for infoboxes; editors abdicate their responsibility to select the most important facts and simply fill in every parameter. It should be possible to endorse exceptions by local consensus, but if you're trying to jam in more than one or two "infobox officeholder" templates, you're probably doing it wrong. Also, there's a difference between saying someone held a particular office and giving the full information available in succession boxes (office, dates, predecessor, and successor); in the case of RFK, for instance, while it's noteworthy that he held the office of US Attorney General, his immediate predecessor and successor aren't very germane to summarizing his career. That said, has their been resistance to trimming these overlong infoboxes? I'd rather not write a formal rule about it unless it's necessary. Choess (talk) 14:06, 26 November 2017 (UTC)

• Infoboxes are intended to provide a bullet point summary, and should be succinct. Succession boxes provide a means to follow through successive holders of the same office. Here I am thinking of some UK politicians who have had a much longer list of appointments. Peterkingiron (talk) 16:17, 26 November 2017 (UTC)
• Also a tentative support, the devil is in the details. Infoboxes like that at Phil Taylor (darts player) are clearly excessive. power~enwiki (π, ν) 22:14, 30 November 2017 (UTC)
  • Well, that infobox is extraordinary. Greenshed (talk) 03:30, 1 December 2017 (UTC)
• I would support an option to collapse succession infoboxes over a certain length. bd2412 T 22:38, 30 November 2017 (UTC)

To summarize so far, we have several options:

• Option 1 - Produce a guideline to limit the number of offices in an infobox to a maximum of three (and use unlimited succession boxes as required).
• Option 2 - Produce a guideline to require infoboxes with more than three offices to be collapsed by default.
• Option 3 - Produce a guideline to limit the length of the infobox to the length of the lead and the contents table when viewed on a 1366 pixel-wide screen with default settings (and use unlimited succession boxes as required).
• Option 4 - No guideline and leave this question for discussion on a case-by-case basis.

If editors have ideas about any more options please add them above. Greenshed (talk) 03:15, 3 December 2017 (UTC)

I was trying to add my name to some categories on my userpage, but I could not do so. I later realized that my error was I typing in the name "categories" when I should just have used the word "category". My proposal is to make it possible for both the word category and the word categories to allow articles to be added to categories. The word "categories" at the base of articles may make things confusing for users. Vorbee (talk) 18:21, 4 December 2017 (UTC)

How widespread do you think this problem is? · · · Peter (Southwood) ^(talk): 20:42, 4 December 2017 (UTC)

I am not sure but I have found an article called Wikipedia: Category Help which might prove useful.Vorbee (talk) 07:46, 5 December 2017 (UTC)

On one hand, keep in mind we have an article called Categories: On the Beauty of Physics. On the other hand, I see the title Categories:Monasteries suppressed under the Icelandic Reformation was created on November 30 by Laurel Lodged, who subsequently moved it to Category:Monasteries suppressed under the Icelandic Reformation - an indication that at lease one user other than the OP made this mistake within the past week. עוד מישהו Od Mishehu 07:28, 5 December 2017 (UTC)

I spent hours setting up a table to make a list look better and be more accessible with in an hour I looked again and the table had been removed, the note on the removal edit was that the table was not necessary, I see no reason to support and little use in looking anything up here. — Preceding unsigned comment added by 69.144.253.150 (talk) 07:19, 7 December 2017 (UTC)

You must have done it under a different IP address. So I guess we'll never learn what you're referring to. Dicklyon (talk) 07:41, 7 December 2017 (UTC)

Can you tell us the name of the article? If so, the table is there in the history. We can discuss the issue on the talk page, to get a consensus - if people like the table, then it will stay, but of course if the consensus is against, then it doesn't. So what was the article? Walkerma (talk) 22:39, 7 December 2017 (UTC)

The wikipedia ratings for articles go (from highest to lowest): FA, Good, A, B, C. Start, and Stub. Seven ratings in all. I've created more than 120 articles which have been rated B, C, or Start -- and all of those 120 articles are of similar quality, covering in my opinion the subject as thoroughly as it need be covered in an encyclopedia and being comprehensible to the average reader. In other words the assessment of the articles I have written has been arbitrary depending more upon the reviewer than the quality of the work. Yeah, I know you can claim that the rating system is objective....but it isn't. Different people come to different conclusions about what they see and read.

Rather than expend the time of reviewers trying to decide whether an article is A, B, C, or Start, rather than undergoing the water-torture of trying to determine what is "Good" and what is "FA", the whole system should be imploded. I suggest there be only one rating for an article: "Good", a rating achieved only after a careful and continuing review of the article by experienced Wikipedians. All articles not judged as "Good" would be unrated. For inaccurate or misleading articles, the article could be tagged as they are at present as dubious or lacking references or whatever.

I would guess that 95 percent of wikipedia readers never go to the talk page to see how an article is rated, and thus the rating system is not very important. Why, therefore, complicate it with a plethora of ratings which nobody cares about -- except the article creator who is more likely to be insulted than complimented by the rating his beloved article receives (I speak from experience).

Moreover, I would propose that a "Good" article have a note to that effect at the top of the article -- and that the "Good" rating not be relegated to the talk page that nobody looks at. That would give credit and prominence to editors for their work and a "Good" rating would give confidence to the readers that what they are reading is accurate, neutral in tone, and complete.

Another reason for simplifying the rating system is that articles change in quality over time -- going from poor to good and from good to poor as different edits are added. Yet, articles are rarely reassessed -- or only after years. Thus, even if you are the rare reader who looks at the talk page to see how an article is rated, the rating is likely out of date.

Let's expend our efforts to try to increase the number of "Good" articles on wikipedia -- and keep them "Good", rather than worry about whether an article is an A or B or C or Start or Good or FA.

"Out of clutter find simplicity": Einstein. Smallchief (talk) 19:21, 30 November 2017 (UTC)

Wikipedia:WikiProject Council/Assessment FAQ. Article assessments aren't for readers, they're for helping Wikiprojects prioritize which articles are most in need of work. ("[T]hese ratings are meant primarily for the internal use of the project, and usually do not imply any official standing within Wikipedia as a whole.") "Good articles", however, do have their status shown at the top of the page, to the right of the title. --Yair rand (talk) 19:37, 30 November 2017 (UTC)

A minor point, but A-class is a higher rating that GA.

More significantly for your proposal, GA and FA ratings are already indicated on the main page of an article: you can see the little bronze star/green plus mark at the top right-hand corner of a Featured or Good article. (See Sappho or Emily Davison for examples of GA and FA respectively).

Start/B/C ratings are at best inconsistently applied, and I can see very little downside to scrapping them (in theory, they are useful for editors knowing which articles they are interested in are most in need of improvement; in practice they are inconsistently enough applied that they aren't actually that useful).

Any proposed system of ratings which scraps all of the current ratings and sets up a new standard for what is a "Good article", though, must propose a set of criteria for it to be judged by. Are we going to keep the current GA system? Because while not as fundamentally broken as the start/C/B rankings, that has its own problems. Caeciliusinhorto (talk) 19:50, 30 November 2017 (UTC)

Well, thanks for telling me. I've done 26,000 edits on Wikipedia and I never noticed that little star that tells you it's a Good or Fine article. I doubt that anybody else has either. Let's put a notice at the top of the article that everyone can see and read saying that Wikipedia considers this a "Good" article.

Maybe the first step in the simplification process would be to combine B, C, and Start reviews into a single category as they are arbitrary -- and it's not really very useful to distinguish among them. Smallchief (talk) 20:02, 30 November 2017 (UTC)

I've said this variously before, but I would totally be in favor of switching to something like Stub, Article, Good Article, Featured Article. GMG^talk 20:07, 30 November 2017 (UTC)

That sounds good to me. Smallchief (talk) 20:09, 30 November 2017 (UTC)

Having said that, even if this could get consensus, I have no idea how much work it would take to piece together a bot that could change the current rating conventions on 5.5 million article talk pages and lord only knows how many associated template. Ping... uh... User:Primefac. GMG^talk 20:18, 30 November 2017 (UTC)

Writing the bot is easy. Getting consensus for having that much spam in people's watchlists would be difficult. power~enwiki (π, ν) 20:20, 30 November 2017 (UTC)

Bots on a watchlist? Eww. GMG^talk 20:23, 30 November 2017 (UTC)

I'm sure you could just point the B and C parameters of those templates to point to a different categorization without needing to edit every talk page. Nihlus 20:25, 30 November 2017 (UTC)

• I'd support something like this. B and C class ratings mean absolutely nothing. In my mind there are four classes: Stub, Start, GA (writing roughly equivalent of a B+ on a Grade 8 book report), and FA. Also, pinging Iridescent, who has said sensible things on this in the past. TonyBallioni (talk) 20:22, 30 November 2017 (UTC)
  • The existing assessment scale is the result of long-abandoned WMF schemes to release print and CD-ROM versions of Wikipedia, and consequently the need to syphon off "only the best" and "only the adequate". I'd quite happily see it deprecated altogether with the exception of "stub" (which is a de facto maintenance template rather than an assessment as such) and some "this has been through a full review" equivalent of FA. (WP:GA is a complete trainwreck and I'd vehemently oppose any attempt to broaden its scope; it's second only to WP:DYK as the haunt of obsessives and cranks.) I find it extremely unlikely that you'll ever get consensus for such a change, as so many people have so much of their on-wiki identity invested in conducting this kind of "this article is currently listed as B class, I reclassify it as C class" timewasting that they'll fight any proposal; likewise, those projects like WP:MILHIST that still operate A-class reviews will turn up en masse to oppose, and consequently even with a couple of hundred people supporting deprecation you'll still end up with "no consensus". Incidentally, all GAs and FAs already note this fact at the top of the article—not relegated to the talk page that nobody looks at—and have done so for years. ‑ Iridescent 20:37, 30 November 2017 (UTC)
• I've long harboured a suspicion that most people who do WikiProject assessments haven't actually read the criteria. I've gotten used to my perfectly adequate B-classes being cruelly slandered as a "Start", but I've come across several new editors who have genuinely found it galling, and if you read how the quality scale describes start you can see why. A scale of Stub->Article->Good Article->Featured Article would be a better reflection of how assessments really work for all but a few very active WikiProjects (looking at you, WP:MILHIST). And I think you could achieve it without a bot: simply change the templates so that setting |quality= to B, C, or Start displays as the same thing and sets the same category. – Joe (talk) 21:33, 30 November 2017 (UTC)
• The great majority of graders do so entirely based on length, and perhaps basic English proficiency, often taking only a few seconds. Stub and start are useful to the tiny number of people who look at the top-views-per project lists (Category:Lists of popular pages by WikiProject) for poor but highly-viewed articles to improve. Of course C & B are pretty variable, but then so are GAs. Most grades are much too cautious, if the supposed standards are taken seriously. I'm not sure it's worth the effort of changing anything. I'm entirely unabashed in self-assessing up to B, though I say so in the edit summary. Johnbod (talk) 03:48, 1 December 2017 (UTC)
• Support some kind of compression. A 4-step rating as proposed by Tony and GMG is much more useful and cuts down on arbitrary ratings. B vs C is particularly pointless. ♠PMC♠ (talk) 04:40, 1 December 2017 (UTC)
• Support a scale of Stub→Medium→Good→Excellent with 'Excellent' replacing GA, A, and FA, Good replacing B, B+, and Cs without maintenance templates, Medium replacing Start, Non-stubby futures and currents, and Cs with templates, Stub stays the same. List stays the same and FL replaced with GL... That is a lot of changes that I want. J947 ^{(c · m)} 05:02, 1 December 2017 (UTC)

• Support the proposal by TonyBallioni and others to streamline the ratings by eliminating B and C. I disagree with Tony, though, about the difficulty of writing a GA as opposed to writing a school book report. I have spent vastly more time and effort writing my handful of GAs than on any routine school paper, most of which received A grades half a century ago. I also believe that the stub rating, though useful if used properly, is way over-used. I frequently see articles that are far beyond stubs in quality with stub ratings. Thanks to Smallchief for raising this issue. Cullen³²⁸ Let's discuss it 05:15, 1 December 2017 (UTC)
  • Some GAs are quite good and much higher quality writing than that, but the process as currently designed is meant to be a lightweight process that makes sure that the article has basic grammar and style down and covers the major aspects of a topic, without requiring it to be comprehensive. It really depends on who the reviewer is and who the primary author is. My remarks weren’t meant to be snarky, just trying to find an example of around what the low end of the GA standard was. TonyBallioni (talk) 05:26, 1 December 2017 (UTC)
• Support some kind of change. Personally I'd like to see A (for current FAs to remove the idea that it must be featured on the main page), B for current GAs (meaning there has been some kind of review), and start- or stub-class for everything else. But I'll go along with any proposal to streamline. SarahSV ^(talk) 05:27, 1 December 2017 (UTC)
  • Personally, I find the "B" rating useless (I still don't really know what makes a "B"-article a "B", and I've been here for years!) But I think we need a rating between "Start" and "GA" – something akin to the current "C"-grade... So I guess I'd support a 5-rating system: "Stub", "Start", some kind of "mid"/"C"-quality rating, and then GA and FA (the latter two of which I tend to be somewhat skeptical about, but that's me...). --IJBall (contribs • talk) 01:12, 2 December 2017 (UTC)

    What makes a B article a B is that it is fully referenced; covers the topic; has a defined structure, including a lead section and one or more sections of content; the grammar and spelling is acceptable; and has appropriate supporting materials, such as an infobox, images, or diagrams. Failure in any of these criteria results in a C rating. Failure of more than one will result in a Start rating. The GA rating is on the very same criteria, and is nominally slightly higher on each; but in practice the difference is the degree of detail the reviewer is being asked to check. For most purposes, B and GA are interchangeable. Similarly, starts and stubs are normally considered unacceptable at DYK and ITN. Hawkeye7 (discuss) 22:25, 2 December 2017 (UTC)

    My point was is that I find the distinction between "B" and "C" to effectively be negligible or meaningless – what you seems to be calling a "B" article I consider a "C"-class article. (Basically, as far as I can tell, "C" articles just tend to be "B" articles that are a little shorter in length...) However, the problem with "B" is that there is a fair amount of editor disagreement as to what constitutes "grammar and spelling is acceptable" (esp. the former). If we're going to simplify the ratings system, merging the "B" and "C" ratings would be a very good first step IMO... --IJBall (contribs • talk) 16:16, 3 December 2017 (UTC)

• Support So how do we move forward on a formal proposal to simplify the rating system? I don't have the technical ability nor the knowledge of Wikipedia procedures to advance a proposal. Smallchief (talk) 10:12, 1 December 2017 (UTC)
• Support a change to a three or four step system for articles (Stub, one or two "mid-quality", and "Excellent"). (Note that there are classes for redirects, SIAs, categories, templates, portals, etc. in at least some wikiprojects. I don't support changing these, which are simply descriptive.) However, I think it's a massive change to make: it's not only all the articles, but also the information about assessment at every wikiproject. Peter coxhead (talk) 10:35, 1 December 2017 (UTC)
• Comment--That the spirit of the changes have got broad local support from the VPP frequents, it's time that this disc. be converted into a RFC and widely advertised as the prelim. steps to gauge the gen. consensus.But, some fine-tuning of the options to be floated etc. may be necessary. Regards:)Winged Blades ^Godric 10:41, 1 December 2017 (UTC)
• I don't think the start/C distinction is useful to anyone. "B", however, at least (in theory) checks the article against a list of criteria that should be satisfied, and some assessment templates (I am aware of WP:MILHIST and WP:GER) contain the checklist in the template. But the main question is what we use the assessments for. I think many WikiProjects don't have the manpower to do anything useful with them whatsoever, and for them fine assessment levels are useless. It may be worth inviting someone from WP:MILHIST. A couple of years ago, when I last cared about assessments, they were the people with the best-run assessment program. —Kusma (t·c) 11:19, 1 December 2017 (UTC)
• Extended comments - First, it's probably better to discuss here rather than !vote, since as Godric points out above, this would need to be redone with probably a good deal more structure and likely totally restarted as an RfC. Second, I think messing fundamentally with the GA and FA processes is just a sure fire way to sink any kind of proposal. Those more or less "belong" to the users who are investing in keeping them going, and changes there, to be successful, need to come from the stake holders, and not from the sidelines.

On a more opinionated note, I don't really see a compelling reason to keep start class around. There are, I expect, a great many subjects for which a few paragraphs long article, what many would call a start class, can cover the topic comprehensively in a way that wouldn't stick out at all in Britannica or World Book, and there's nothing wrong with that. It doesn't necessarily need the de facto maintenance template that is a start class rating. C and B on the other hand can be positively counter productive, and anyone who's hung out enough at the Teahouse has come across a new user trying to get their article "promoted" into one of them only to find out that they're nearly totally disregarded by the community.

The up side of combining these three into an uncontroversial "article" class in my mind is that it would make users more likely to accurately rate their own articles for tracking purposes. "Article class" would mean simply that this one can stand on its own without the need for immediate attention, and would hopefully avoid it being more or less a type of badge of honor of any kind. Looking back at my own history, I would be perfectly comfortable rating something like this as "article class" rather than have it sit unassessed until the point where it passes GA, or have something like this, this, or this sit indefinitely as a start class, when I have no intention of further serious work on them in the near future, because they've reached a point where they can well stand on their own two feet, and be beneficial for readers without major attention.

As an added benefit, it may actually help make GA and FA more active in the long run, by emphasizing the point that the assessments aren't terribly useful until you get to the point where you meet some kind of structured peer review. GMG^talk 11:49, 1 December 2017 (UTC)

OTOH, I like your idea of a simple "article" class (which I like as a "non-judgemental" simple descriptor, like "template" or "redirect" class), that would combine "Start"/"C"/"B" – I could easily get behind that kind of idea. --IJBall (contribs • talk) 01:16, 2 December 2017 (UTC)

Oppose anything that overules any WikiProject's preferences If you don't like them, don't use them. I find the categorization in WP:PHYS/WP:JOURNALS/WP:ELEMENTS and elsewhere to be perfectly adequate. While individual assessments can always be called into question, there's quite a bit of a difference between a B-class article and a Start-class article. If you object to a rating, simply change it. It may simply have been given a while ago, and no longer reflect the current state of the article, or both you and the original assesser may not have seen the same qualities/deficiencies at the time of assessment. A discussion will resolve those differences, and identify those issues that need to be solves before going to the higher class, leading to article improvement. If projects decide they don't want the fine-tuning of Start/C/B classes, then they can customize their own Wikiproject banners accordingly.Headbomb {t · c · p · b} 13:25, 1 December 2017 (UTC)

• Strong oppose, even if this were an actual RFC, largely per Headbomb. If you have better things to do, go do them. Some people do use ratings for article improvement drives, and GA/FA are not the pinnacle for all Wikipedians (nor is B the same as C, nor start the same as stub). It's funny though, how C and start were added--they were added to address concerns by users who were not part of the original WP1.0 crew so that there was some fidelity in the lower-quality articles. GA/FA are additionally entirely distinct processes from the letter grades assigned, which are per-WikiProject (though in reality most WikiProjects do not differ much in the grade they assign). --Izno (talk) 13:37, 1 December 2017 (UTC)
• Did anyone experience the same complaint about the ratings that is mentioned here? Jo-Jo Eumerus (talk, contributions) 13:48, 1 December 2017 (UTC)

  That is great reading. Actually many WikiProjects were founded as part of the WP:1.0 assessment drive. (I was there when WikiProject Germany was founded by someone interested mainly in getting articles assessed, which meant that it quickly grew beyond what anyone could handle, and we have never had the manpower to do very much with the data we created). For the mostly dead WikiProjects, having their own ratings/rating systems is overkill, and instead having project-independent "universal" rating would work better. However, the active WikiProjects don't want anyone messing with their internal structure. In any case, the proposed simplification would mean re-assessing millions of articles, and it is not completely clear to me whether this will achieve anything at all unless we know what we actually want from this data. —Kusma (t·c) 14:29, 1 December 2017 (UTC)

  Something like User:GreenMeansGo's proposal could easily be done by a bot – any article with a "Start"/"C"/"B" rating would be replaced by an "article"-class rating. --IJBall (contribs • talk) 01:20, 2 December 2017 (UTC)

• Oppose: Not only does the proposal get the assessment hierarchy wrong (A-class is above Good), it also suggests things that are already implemented (Good articles do have "a note to that effect at the top of the article"). Sure, article assessment gets it wrong sometime, particularly because initial ratings are not promptly revisited even if the article undergoes substantial change. But the proposed process does not remedy this inherent flaw; we do have FA and GA delisting processes that indeed make reassessment even slower because they involve a mandatory discussion. Ratings are there primarily for us editors to keep track of our priorities, not so much for the readers. For the editor's purposes we need a scheme that is more nuanced than just Good and "bad" articles. No one wants to specifically read a half-finished C-class article (in comparison to a full-fledged FA or a miserable Stub). But many editorial tasks are ideal for that middle ground; most of our editing is neither complete rewrite of Stubs or extremely conservative tweaking of FAs that have consensus for each word in the article. – Finnusertop (talk ⋅ contribs) 16:54, 1 December 2017 (UTC)
  • Seven years and 26,000 edits later I just learned in this discussion that a little star on top of the page designates a "GA" or "FA" article. I suspect the same would be true of 99 percent of readers. Why not give a little more prominence to articles Wikipedia is proud of? Smallchief (talk) 21:11, 1 December 2017 (UTC)
• I'm not placing a bolded !vote here because I don't think that's what's being asked, but I support revising the system. I'd like to see: Stub -> [un]reviewed -> Good Article -> Featured Article, with all of the specific assessments between stub and GA tossed; they're so inconsistent as to be meaningless. For examples from my own contribs: compare debits and credits with double-entry bookkeeping system: both are complete messes about basically the same topic, but one is B-class while the other is Start-class. Why? I don't know. Maybe take Ashbridge Estate, a reasonably-complete Good Article, and compare that with Old Princetown Road, another reasonably-complete article rated Start-class. And how about Jian Ghomeshi? A pretty comprehensive article that has lots of eyes on it thanks to a scandal from a few years back, that's rated Start-class from an assessment that's over 10 years old now. You can't get any useful information out of these ratings, and it seems nobody has much interest in maintaining them. I would like to see something in the gap, but ideally that should be something like what we use maintenance templates for: general indications of what needs to be improved, not just a flat grade with no feedback. As issues are resolved, the article builds toward Good quality. Good and Featured are both useful peer reviews, as well as incentives for editors to contribute quality rather than quantity. And let's just get rid of A-class project-wide, it's clearly deprecated in favour of GA. Ivanvector (^Talk/_Edits) 19:00, 1 December 2017 (UTC)

  • For the record: Both debits and credits with double-entry bookkeeping system are both C class, because they are not fully referenced. Hawkeye7 (discuss) 22:44, 1 December 2017 (UTC)

  • I like your progression. Stub -- reviewed -- Good Article -- Featured Article. "Reviewed" would mean that a reviewer has seen the article and has tagged it, if necessary, for any serious deficiencies, i.e. "needs footnotes," "needs work," etc. Thus the reader could have some confidence that the article meets minimum standards -- or warned that it does not.
  • GA and FA would essentially remain as they now are -- with a decision needed whether A articles become GA or FA. Start, C, and B would cease to exist in new articles, and old articles bearing Start, C, and B designations would gradually be changed by editors to "Reviewed." Stubs would remain the same. That doesn't sound complicated to me, nor does it seem like much work. Smallchief (talk) 21:07, 1 December 2017 (UTC)

    There is no excuse for uncited material being added. Do not tag articles; template the editor who added the material with increasing warnings similar to those dished out for vandalism. Hawkeye7 (discuss) 22:44, 1 December 2017 (UTC)

• A point to remember, as we are (at least nominally) here to build an encyclopedia, is that most encyclopedias are much smaller than Wikipedia. Looking at the 2017 World Book, I see "articles" consisting of 1 paragraph on the Grand National, 4 on the Grand Ole Opry, 3 on Grand Portage National Monument, and 2 on Grand-Pré, Nova Scotia. There are also inline "redirect"s for Grand Old Party and Grand Prix, and a few index entries, including Grand Nain. By the standards of a print encyclopedia, Wikipedia has been complete for a very long time. (although, to hammer on a point I have made repeatedly, the 10.5 page World Book article on Government is still superior to the one here, so there is clearly some work left to be done)

While the pages at Category:All Wikipedia Start-Class vital articles are lower-quality in aggregate than those at Category:All Wikipedia B-Class vital articles, on an individual level it is definitely a crapshoot. This can largely be attributed to the lack of process, and the millions of hours of volunteer time it would take to execute any process. The WP:GAN list is horribly backlogged, and I see no reason to believe that will improve. A somewhat-accurate system is likely the best we will get. power~enwiki (π, ν) 20:22, 1 December 2017 (UTC)

• Oppose: I did oppose the creation of C class back in the day, as anything less than B class is of little use to the readers. But I can grade a hundred articles as Stub/Start/C/B in an hour or two. Unfortunately, the grading process cannot be done by a Bot. GA is a fairly low bar, little more than a B; but because it requires a review, there is a huge backlog at GAN. A class, which is way above GA, must be retrained, because worthy articles cannot be even nominated for FA because of the cap on nominations. Hawkeye7 (discuss) 22:14, 1 December 2017 (UTC)
  • Actually, there's now a pretty good tool for identifying article ratings. I've found that it's accurate >90% of the time. It tends to over-rate stubs with long bulleted lists or lots of citations as being start-class, but overall, I'm pretty happy with it. See m:Research:Screening WikiProject Medicine articles for quality for more information. I'd be very happy with having this tool assess stubs independently, and with it producing a list every ~month of articles whose ratings appear to be off by two classes. WhatamIdoing (talk) 19:18, 6 December 2017 (UTC)

    Thanks for that! I do remember when that project started, but had forgotten about it. I will give it a try. Hawkeye7 (discuss) 19:35, 6 December 2017 (UTC)

• Comment: If there is to be any change to the assessment process, I would make the following observations. There is some bias in the assessment process that is related to article size. It should be possible to recognise that an article is at the "zenith" of its development regardless of size - the scope, breadth and detail of the article is appropriate to the subject, and particularly, the coverage in source material. I would note variation in interpretation of "Verifiable with no original research" particularly wrt Likely to be challenged, WP:SYNTH and WP:SYNTHNOT. I see inconsistencies that arise wrt writing in Wikipedia:Summary style (see SYNTH is not summary) with various interpretation wrt verifiability and synthesis. There is considerable variation and creep wrt the assessment guidelines - what certain assessors might consider to be "required" to meet the individual assessment critera for a particular level of assessment. As a teacher, I would note the need for assessment criteria to be as objective and explicit as reasonably possible. I suggest the guidelines here fail. I suggest the following, which do not necessarily relate to the existing assessment levels. A stub is a short article of one main section/lead combined (excluding a reference and ancillary sections). some articles of this type will clearly require further development. Some may be developed to their zenith at this stage and are "Good Stubs". Developed articles may be assessed as: "acceptable" against all criteria but with scope for improvement (say present B Class); deficient against one or more criteria (C Class); or, good, in that they are at the zenith of their development. Per User:Hawkeye7 above, this would be a high bar but not unattainable (say, present A Class) There might be some acknowledgement based on size that acknowledges the effort in creating larger articles - a "LA" (large good article). This is not a distinction of quality. Of course, a camel is a horse designed by a committee. Regards, Cinderella157 (talk) 04:58, 2 December 2017 (UTC)
• Mostly support. There's a lot of "distinction without a difference" out there. Sure, you can maybe distinguish between B and C and Start, but who cares? Are there Wikipedia editors out there who will actually do something different if they see their favorite article classified as C rather than B? Very few. And it encourages time-wasting maintenance if nobody is USING the result.
  • That said, I disagree that GAs and FAs should get some huge blink / marquee notice of the fact on the main article page. Most readers want to read about (topic) no matter how good or bad the article is, so it won't change behavior.
  • I also disagree with deprecating A-class. Fine, some people think that A-class is silly, but it does represent a real-if-rarely-used process, so no need to break it for projects that like a more formalized peer-review pre-FAC. So we'd have a scale that is (Stub) - (Article) - (GA, A) - (FA).
  • Side note on importance: The "importance" rankings are also a bit suspect, and one of the smartest things WP:MILHIST did was to simply not rank importance - no arguments between editors over whether a major battle in a minor war is "more important" than a minor battle in a major war, or a general vs. a battle, or a class of ships vs. a specific ship. Any time spent on that is time wasted. Now, I'm not completely on board abolishing those entirely - I think the "Top" importance rank might be useful to immediately see the articles that "actually matter" to a Wikiproject and ignore the various subarticles. But Top / Everything else is probably the only useful distinction; people arguing whether a fictional character is "Low" or "Mid" importance isn't useful. I guess that, for a start, just combine Low and Mid importance into Mid (no need to "offend" some editors by ranking their favorite topic as "low importance"). But maybe this is too much scope creep. SnowFire (talk) 21:15, 2 December 2017 (UTC)
    • Are there Wikipedia editors out there who will actually do something different if they see their favourite article classified as C rather than B? Yes, there are many. See Wikipedia:WikiProject Military history/Assessment/Requests. Updating and reviewing articles is what we do. A critical point here is that a B class article is acceptable at DYK and ITN, whereas a Start is not. If you look at WP:ITN, the leading cause of articles being rejected is that they are Starts, with poor referencing and low quality. Hawkeye7 (discuss) 22:02, 2 December 2017 (UTC)

      Incorrect - all DYK requires is not being a stub. Large numbers of DYK articles are "starts", rightly or wrongly. Johnbod (talk) 06:05, 3 December 2017 (UTC)

      Yes, that's right, per Supplementary Rule D11; a DYK article cannot be classed as a stub. An artefact of a time when only stubs were excluded. However, Supplementary Rule D2 nowadays requires that the entire article be referenced with inline sources. Which requires the articles to meet the sine qua non of B class articles. Hawkeye7 (discuss) 06:35, 3 December 2017 (UTC)

      • #1, I would argue that is still "very few" compared to the vast sea of editors. MILHIST might be the only project that comes close on this. #2, I'd argue this is more a side-effect of MILHIST being an active and well-run project. You can already self-assess and mark any article you want as B; editors who come to that page are genuinely interested in real feedback. If assessment requests was replaced with an identical page called "requests for article feedback" as a low-bureacracy pre-GA review, I imagine the same kind of editors would show up. And good on them, and good on you for reviewing, to be clear! I just think the B-class part is totally incidental, and it'd work fine without it.
      • For ITN, I'm sure they'd manage. Replace "B class" with "is reasonably referenced", problem solved. The label isn't important, the article is. (I will grant that this is the closest to a reason to keep it... but... I don't think this value is enough to compensate for the wasted time maintaining rankings on the 99.9% of articles that never get close to ITN/C. And it still would argue for at least killing the C ranking.) SnowFire (talk) 22:18, 2 December 2017 (UTC)
  • I think I might be the one Kusma refers to above. FWIW, I was most interested in finding what relevant content existed, using assessment as the apparent pretext. I would definitely support some form of changes to the assessment scheme, maybe to a more clear cut system, perhaps detailing the particular weaknesses of articles at sub-GA class, like maybe too few references, too few sources, neutrality issues, etc. That might make both article improvement easier and provide a sense of accomplishment to the editor whose work clears away a tag. I myself would, by and large, favor keeping the importance rating for those WikiProjects whose topic area is more or less consistent with that of one or more recent, high quality, apparently comprehensive print or online broadly encyclopedic work. Basically, the longest articles in such works are probably the Top importance, shorter articles High, shortest articles Mid, and things not covered as separate entries in it Low. Depending on the size of the topic and a few other factors, some WikiProjects will have differing percentages of various importance grades, but I can't see any real problems with that. @Kirill Lokshin: might be a good person to hear from regarding what MILHIST might think of any proposed changes. John Carter (talk) 21:48, 2 December 2017 (UTC)
• Support, for the most part. It would still be useful to keep 'stub' as a separate class of articles. However, in my observations, under the current system the assignment of 'start', C and B ratings is essentially arbitrary, and I don't see anything of value being lost by amalgamating these three classes into a single one. Nsk92 (talk) 22:36, 2 December 2017 (UTC)
• Revising the article quality scale is a nice idea. There are two basic steps.
  1. Define the criteria for classifying the articles in a way that is intelligible to all and likely to be applied evenly by most. Until this is done the whole thing is a waste of time. Ensure that this classification system is in some way useful. Define how and why it is useful, as that should inform any efforts to interpret the criteria. Unless it will be more useful than the current system, don't bother, and unless it is more clear and easy to implement, also don't bother. One of the problems with the current system is arbitrarily applying personal preferences instead of following the criteria. This is particularly prevalent in GA reviews where a single reviewer can get away with applying requirements not specified in the GA criteria, because they think the know better. Maybe they do, but when the rules require X and the reviewer requires X+Y it skews the process. If X+Y is necessary, the criteria should be changed.
  2. Work out who is going to implement the revised system. Simply bundling B, C and start together presumes that the article is correctly classified as one of those already, otherwise it is pointless. A set of usefully classified articles is more helpful to a project than a set of arbitrarily classified articles, so unless there is some group who will actually do the work, more harm will be done than good. A change to the current system will be a mind-bogglingly enormous amount of work. No point unless it will be done and will be useful.
  • Importance should be left as an option and left to the projects. The same article could be top importance for one project and low importance for another, and unless one is an active participant in a project with some experience, one should not presume to decide an article's importance to that project. (making a suggestion is reasonable, but if a member changes it, assume that they know better until evidence suggests otherwise) Whether projects choose to use importance or not is also an internal matter for the active project members.
  • An approach that could be tried is to run a new system in parallel with the old. When and if the new system covers all the articles rated by the old system, the old ones can safely be deleted.
    • Alternatively, something similar could be done per project as a test run. set up criteria, and assess a project's full set of articles. Then come back and run an RfC for something that can be shown to be workable. Use different names for classes with different criteria to the existing ones otherwise the confusion will be increased.
  • I also point out for those who may not have noticed, that only FA, A and GA require the input of a second or more parties. Anyone can assess any article up to B-class. Just like anyone can edit Wikipedia. However, also just like like editing, anyone can assess badly, and some competence is required. It gets easier with practice, and some subject knowledge is recommended. Use one of the checklists provided, and when all the boxes have been ticked, set the class. Any replacement system should take this into account. · · · Peter (Southwood) ^(talk): 12:40, 3 December 2017 (UTC)
    • "A change to the current system will be a mind-bogglingly enormous amount of work." -- No, it'd be really easy actually. Templates already support "synonyms". Make it so that B, C, and Start all point to the same categorization (whether that be B-Class, or some other new term). Done. (Heck, it could even be REVERTED if there was a change of heart. And editors not in the know wouldn't be affected at all, they could use whichever classification they wanted in the template, and it'd work no matter what.) And... I agree that not all articles are "correctly classified" within those three, but there's no need for them to be if the categories are merged...? Anything REALLY wrong (e.g. B rather than Stub) is already wrong, and will merely still be wrong after merge. A parallel system of rankings, on the other hand, WOULD be an enormous amount of work, but I don't see the point. SnowFire (talk) 16:32, 3 December 2017 (UTC)

@SnowFire: the assessments populate categories (e.g. Category:C-Class plant articles). Categories can't be simply redirected (see WP:CATRED). The category redirection can't be fixed in the normal way by a bot changing the category statement in the article, because it's created by a template. It's clearly possible to achieve the desired effect, but not quite as simply as you said. Peter coxhead (talk) 17:44, 3 December 2017 (UTC)

All the C-Class categories would just be empty if the template interpreted "C" as "B". The goal would be to not have to change any Wikiproject templates in articles at all; whether they say class=b or class=c or class=start, they'll just count it as a B, and put it directly in Category:B-Class plant articles (rather than putting it in C-Class and having to "redirect" Categories, which I agree would not work, aside from being more labor to do anyway).

I guess, if this change stuck, there could be an exceedingly minor and automated clean-up that deleted the empty categories after a time. But that would also be easy, and since nothing would even point at those categories, it'd be very low-priority anyway - nobody has cause to go to empty categories in the first place.) SnowFire (talk) 18:07, 3 December 2017 (UTC)

OK, In that case I guess I Oppose as I find the classifications useful as they are, and don't see the proposal as an improvement. Cheers, · · · Peter (Southwood) ^(talk): 20:34, 4 December 2017 (UTC)

Strong oppose: I don't see the point of this change, it's a great example of WP:BROKE. If you don't care about assessments, don't use them. If you don't like them, ignore them - they're buried on the talk page for a reason! Other people find them useful. I accept that there can be variations, and many assessments are out of date, but many WikiProjects use these to guide their work - see for example Periodic_Table_by_Quality.PNG. Also, far from this being a "long-abandoned WMF scheme to release print and CD-ROM versions of Wikipedia" (it was never WMF, BTW), offline collections are now being beginning to be used as offline OER packages. We recently held a successful four day hackathon/conference on offline work. There are now monthly dumps of the article metadata produced by Kiwix that include these assessments, and people like Internet-in-a-Box are using these to organize collections. All those metadata will be lost if you destroy the current system - for no real purpose, it seems to me. If people want to do assessments, let them. Are you seriously planning to dictate to hundreds of WikiProjects how they must do their assessments? Walkerma (talk) 02:56, 4 December 2017 (UTC)

• Oppose the proposal. Some people find it useful to grade or to have a grade for articles. For those that disagree they can change the rating themselves or talk about it on a talk or project page. If you don't care about it just leave it alone. Perhaps we can even have a custom css to hide it for those that want to see nothing or to appear to merge things together, but leave intact for everyone else. Graeme Bartlett (talk) 05:57, 4 December 2017 (UTC)

Oppose removing this completely as other editors have noted that Wikiprojects make use of these. However, I would support removing them from the AFC space, as the only thing that should be reviewed there is notability and verifiability, and it's no wonder there's a backlog when reviewers are supposed to be reviewing quality on an entry point for new editors. Egaoblai (talk) 06:33, 4 December 2017 (UTC)

I don't see any problem with tagging a draft as of interest or of importance to a project. If the draft is good enough to tag for quality is is basically a vote of confidence by the tagger. There is also no harm in that. · · · Peter (Southwood) ^(talk): 20:34, 4 December 2017 (UTC)

• Support some sort of compression of the current scheme. Kaldari (talk) 00:02, 5 December 2017 (UTC)

Oppose I do agree that the differences between B, C, and Start are very variable between articles and projects, but that just means somebody should take the time to properly assess the articles in their WikiProjects. Maybe instead of replacing the system we can actually use it and go through the article talk pages and properly assess the problems in those articles. That's what the talk page is for, and why the article assessment exists. Much of the variation in ratings has to do with the fact that nobody updates the talk pages after they've made their improvements. SpartaN (talk) 04:07, 6 December 2017 (UTC)

I agree with you that ratings are variable – by project, by the editor making the assessments, and by date. However, Wikipedia:WikiProject assessment#Grades lists the broad standards (which appear to be unfamiliar to some editors in this discussion). Some WikiProjects, notably including MILHIST (which enforces the use of a six-item checklist for B-class), have somewhat different standards. The individual variation can be much greater, e.g., one editor will read the B-class statement about being "suitably referenced", and conclude that every sentence must be followed by an inline citation, and another will read the next sentence and decide (correctly, BTW) that B-class only requires WP:MINREF to be followed (i.e., no fact tags, no BLP sourcing violations, and nothing uncited that has a >50% chance of getting a fact tag). WhatamIdoing (talk) 19:27, 6 December 2017 (UTC)

Wikipedia editor time is limited, though. What, exactly, is the gain if we had perfectly consistent and accurate article ratings for Start/C/B as of December 2017? Is this the best use of editor time? Even if it was mildly helpful, wouldn't it go out of date anyway? For FAs and GAs, at least those slightly impact the reader experience. There's very little gained from knowing the difference between Start and B - the main thing offered is that it maybe, maybe speeds up WP:ITN/C a little, but not much, because many articles nominated there are very new anyway, so wouldn't be able to rely on an "old" rating. SnowFire (talk) 07:35, 8 December 2017 (UTC)

New article assessment ratings?

Rather than trying to remove ratings, perhaps adding new ones would help here. Specifically, an "article" class rating (which can be applied to B/C/Start-quality articles on WikiProjects that use it), as well as a "good stub" (a referenced but short article) are two ratings that don't currently exist. 2752 Wu Chien-Shiung and Gnophos dumetata are two pages that might be "good stubs". power~enwiki (π, ν) 20:12, 4 December 2017 (UTC)

What criteria are you suggesting for "good stub" that distinguish it from "stub" and "start"? Also what would the point of "article" class be, that would be more useful than arbitrarily rating as "start" class when it is clearly better than stub but you actually don't know what it should be? · · · Peter (Southwood) ^(talk): 20:40, 4 December 2017 (UTC)

You might be interested in Template talk:WPBannerMeta#And old idea, revisited, part 2 and Template talk:WPBannerMeta#Overhaul: moving to Lua & JSON. Headbomb {t · c · p · b} 21:25, 4 December 2017 (UTC)

For "good stub" the primary criteria would be reference quality, as well as an assessment that the article is unlikely to expand in length. The point of "article" class is to allow those projects that don't like the B/C/Start classification to have a way to avoid it. power~enwiki (π, ν) 00:17, 5 December 2017 (UTC)

Well some projects don't rate articles, eg WP:WikiProject Caves. Also C class is newish, and so is opt-in, though do any project still not use C? So really it is up to the project. Graeme Bartlett (talk) 23:35, 6 December 2017 (UTC)

@Graeme Bartlett: C-class is not opt-in; it's part of both the "standard" and "extended" sets (see Template:WPBannerMeta#Assessment). It's opt-out, for which either the "inline" or "subpage" methods may be used. The change from opt-in to opt-out occurred no later than July 2009, possibly somewhat earlier - trying to correlate the revision histories of several subtemplates is not trivial. --Redrose64 🌹 (talk) 00:06, 8 December 2017 (UTC)

It might be a good idea to have a brief (one-sentence) summary of the current ratings scheme, and another one-sentence summary of what is being proposed here. Is the current system, going from Top to Bottom, Featured Article, Good Article, A class, B class, C class, start class, stub class? Or have I left something out there? Or have I put in something which is not generally used (I have not seen many articles ranked A class on Wikipedia)? Just a brief summary of the current system and how it differs from the proposed system would be helpful here. Vorbee (talk) 16:27, 8 December 2017 (UTC)

FA, A, GA, B, C, Start, Stub. See Wikipedia:WikiProject assessment#Grades A-class is only used by a few projects. There are several others too, which have not been mentioned in this discussion. · · · Peter (Southwood) ^(talk): 08:39, 9 December 2017 (UTC)

Currently I participate in many AFDs, and some I wish to watch without havign !voted in. The discussions I have !voted in I can manage from the WMFLabs log, but for the AfDs where I just comment or am interested in the outcome, I have to either remember, dig them out of my contribs, or add them to my watchlist. The problem with adding them to my watchlist is that my watchlist fills up and I have to go and empty out hundreds of months old closed debates. I am proposing a function which would allow editors to add put a time limit on how long AFDs stay in your watchlist before being automatically removed. Because there are many relist-adverse editors who don't like to relist a debate a third time, and very few debates drag on past 4 weeks, I think a 4 week or 30 day maximum time limit would be helpful. I checked Perennial Proposals#Watchlist section and didn't see anything that resembled this nor did a search of the archives come back true. L3X1 (distænt write) 04:19, 10 December 2017 (UTC)

See this. See also WP:AALERTS, which provides a similar function for certain projects, although it's not quite as customizable as a watchlist. Headbomb {t · c · p · b} 04:23, 10 December 2017 (UTC)

I am interested to see how it is implemented, but I think that would do the trick. Thanks for telling me. L3X1 (distænt write) 04:30, 10 December 2017 (UTC)

This would also be useful for watching RfCs and a bunch of other transient phenomena. · · · Peter (Southwood) ^(talk): 17:03, 10 December 2017 (UTC)

Hi everyone. I've just proposed this theme on the IMDb character template talk. I'll do a summary: the section of characters on IMDb doesn't exit yet, but it can be recovered using Web Archive. What shall we do? Please, I prefer those who read this proposal, answer here, so it's easier to following the discussion. Thanks. Labordeta (talk) 12:01, 11 December 2017 (UTC)

Hello, I think that on pages the Category:Hidden categories should be separated and broken down into two groups – tracking categories (for items that need no editor input, like Category:Articles with hAudio microformats or Category:Wikipedia articles with VIAF identifiers) and maintenance categories (for items that need fixing, like Category:Unknown parameters or Category:All BLP articles lacking sources).

Right now all hidden categories are lumped into one batch on pages and it is hard to see if there are issues that were flagged, or if the categories are just there for the sake of being there. For example, hidden categories on Valdas Adamkus look like this:

Among the 12 categories, 11 are tracking and 1 is the maintenance. This category (Category:Wikipedia articles needing clarification from January 2011) gets lost in the visual clutter of stuff that needs no attention from an editor. It would be very helpful if the maintenance categories were separated out in their own basket so that any flagged issues could be seen in a few seconds, instead of parsing thru numerous irrelevant categories.

The change would require a tweak to the Mediawiki software, and I have no clue how that works, but I don't image it would be too difficult of a change. Renata (talk) 17:37, 9 December 2017 (UTC)

More difficult than you seem to think: the software would have to be changed to have additional magic words to replace __HIDDENCAT__; various places that check the resulting page property would have to be updated to check the new page properties too (not just the bit that actually does the category display), some in non-trivial ways to avoid duplicated entries if something has more than one of these new magic words on it; and then everything on the wiki that uses that magic word would have to be changed to use the new magic words. Anomie⚔ 16:41, 10 December 2017 (UTC)

Comment There are maintenance categories that aren't hidden. This very page is categorized in Category:Wikipedia proposals, for example. How would that be addressed? Brightgalrs (/braɪtˈɡæl.ərˌɛs/)^[1] 21:28, 11 December 2017 (UTC)

My proposal is as follows. If a person has recently died, a tag going at the top of the article on that person may appear (this is currently the case with the article on Keith Chegwin). If a country is in the news, a tag may be put at the top of the article on that country - this was the case with the article on Zimbabwe at the time Mugabe was forced to resign. There are sometimes medical stories which head the news, such as tonight (December 11 2017), when there was a report on research into Huntington's disease. This action of providing templates could go to top articles on medical conditions, so that people know that changes to the article may not reflect the most recent research findings. Vorbee (talk) 18:15, 11 December 2017 (UTC)

Existing current event templates are listed here: Wikipedia:Current event templates. Maybe bring this up on Wikiproject Medicine and see what they have to say. Brightgalrs (/braɪtˈɡæl.ərˌɛs/)^[1] 21:57, 11 December 2017 (UTC)

Every animated image should include a method to stop/start the animation. It will be nice if it was possible to stop/resume the animation.

Animated images are supremely distracting when one is trying to read the rest of the article. Some animations are so strong that one is forced to print out the page (if feasible) just for the heck of reading it in peace.

Animated images do serve a useful purpose. This is not a proposal to abandon them. It is strictly about retaining usability of the published page.

Nor am I the only one raising this concern - see [[2]]. That discussion got sidetracked into technical minutiae. Obviously not much visible has come out of that proposal.

For an example, see https://en.wikipedia.org/wiki/Hall_effect_sensor. It is nearly impossible to focus on the content without tiring oneself out. — Preceding unsigned comment added by 50.250.203.165 (talk • contribs)

You can disable animations through your preference page. (You might consider taking this to Wikipedia:Village pump (technical) Hawkeye7 (discuss) 20:15, 7 December 2017 (UTC)

Those just disable CSS animations, not GIFs and animated PNGs —TheDJ (talk • contribs) 20:20, 7 December 2017 (UTC)

(e/c) There are tickets related to this like phab:T101644. If you want something visible, someone will have to do the work. Discussions are not enough to make something happen. Unfortunately we just had the community wishlist, which would have been a perfect opportunity to nominate this as a work item to take on this year. Maybe next year you could propose it ? —TheDJ (talk • contribs) 20:19, 7 December 2017 (UTC)

this would not seem very difficult--we do lots of fixes in addition to the ones on the wishlist, which tend to be major. And there is another approach. (I care because I am one of those who have great trouble if there is an animated image of any sort--and, if it is important, I usually need to be able to slow it down: We should have it as part of accessibility policy that we do not use automatically moving images--that every image we use has to move only if clicked on. There would still be a problem converting all those we do have, but at least there would be no more. DGG ( talk ) 04:21, 12 December 2017 (UTC)

As an editor strongly sympathetic to the breadth of visual impairments people may have to deal with, I wanted to lend some support to what DGG mentioned above. Perhaps a non-technical stopgap would just be an accessibility policy of referencing motion graphics footnote style? That'd keep them quarantined from the text, easily viewable, and wouldn't require any coding or scripting work. Jasphetamine (talk) 11:14, 14 December 2017 (UTC)

A little while ago I decided to expand an article using information from one document published from a company, and I was accused of not including a citation for all of the information. Basically, when you add information to wikipedia, you can either plagerise or rewrite it in one’s own words (A rearrangement of a sentence is almost plagerising, and sometimes the sentence is read better the other way around!). But, if I rewrite it, I get accused of making it up. So I propose an ‘assembly box’ where I paste in all the information, and in there I assemble the pertinent information together so it flows easily from topic to topic (this probably requires periodic saving so the assembly is shown. If the editor’s internet connection drops, he should periodically save a copy if he wants to continue on with his inspiration), and then I incorporate it into the article. The article’s history page will show a page merger rather than a single edit. The history of the merging article can be retrieved so the proof can be given and the lazy critic who does not want to check if each fact exists in the source can be refuted because it will be able to highlight each fact and allow them to be traced back to their original location(s) in the referenced document.Charlieb000 (talk) 22:29, 18 December 2017 (UTC)

@Luschwitz: Deleted the information. Emir of Wikipedia (talk) 22:57, 18 December 2017 (UTC)

We cannot keep any copyrighted material - we even try to remove it from article histories. There is a template to add to articles to show that you are making a series of large edits: ((template:under construction)) Rmhermen (talk) 04:55, 19 December 2017 (UTC)

You can create your own "private" sandbox in your own userspace, where users will generally leave it alone as long as you follow a few basic policies (such as copyright, stripping or disabling the categories, removing any fair use images). Make the updated version of your article there, and then copy and paste it into the main article. עוד מישהו Od Mishehu 09:04, 19 December 2017 (UTC)

Since 2015, the 2017 Community Wishlist Survey – an annual poll of the Wikimedia editorial community on what the WMF Community Tech team (mostly distinct from the Community Liaisons) should focus on in "meeting the needs of active Wikimedia editors for improved, expert-focused curation and moderation tools" (i.e., getting the MediaWiki developers to focus on building and fixing particular stuff).

The 2017 survey has closed; the results are here – and raise the same issues as in previous years.

Statement of the problems: This process is fundamentally lopsided, for numerous reasons:

Some suggestions for making Community Wishlist work better

This is a draft of ideas; I have not yet submitted them to the Community Tech team's talk page for consideration, since some more input first would be of use (I may be missing some good ideas, and some of mine might not be that good).

1. Expand the number of accepted proposals to 15 or more, and vary this number by the number of proposals, either increasing it to match the increase in proposals from last year, or just as a percentage of proposals this year.
2. Open a properly classified Phabricator ticket, if one doesn't already exist, for every proposal (probably should be delegated to the proposer, but made to happen regardless). Identify additional teams and processes to which a proposal that didn't make the cut, but was well supported, can be submitted. ("Some of the other top wishes may be addressed by other development teams" is meaningless if no one knows who/where those are.) If necessary, some Phabricator categories/projects might need to be created for dealing with survey proposals that do not touch on development matters. That system is already being used for things like real-world meeting planning, etc., so it can also be used for this.
3. Reduce the number of categories to, say, 5 major categories, e.g.: Editor Experience, User Experience, Multimedia and WikiData, Administration and Core Technology, and Miscellaneous. Subdivide each more topically; this will also make the proposal pages be less of a wall of unorganized proposal mess. Refactor the pages as needed to keep them organized.
4. Always accept the most-supported proposal in each major category as having passed (as long as support was over 50% of course, but it is never going to happen that a major category will produce all-failed proposals – few proposals are so bad they're outright rejected, since judgement is exercised before including a proposal in the survey to begin with). Accept two as having passed in a category that has a disproportionately large number of proposals. Or use a more specific algorithm to prevent one category from getting excessive attention and other categories getting nothing. After that, consider which remaining proposals, across all a categories, have the most relative support.
5. If a proposal reappears in a later year's survey, its votes from any previous year(s) – by different editors, who did not later change their votes – are counted for this year as well. The simplest way to do this is to transclude previous ones. (Easy, since the proposals are all on their own pages anyway.) This will help good proposals build support over time and not alway fall victim to new proposals that are attractive simply because they're new. It will also mitigate the tendency to vote against or remain silent on good proposals that just aren't among one's favorites.
6. Require that rationales be given with votes, and discount those that do not have one, or have one that makes no sense. (A "per Username" should be permissible, with the caveat that quality of that original vote affects the quality of votes that provide no rationale other than it.)
7. Make a clear statement against non-neutral pro or con advertising of specific proposals. There's no way to enforce this, but most editors will not canvass if told not to. (And not every project has an equivalent of w:en:WP:CANVASS, anyway, so conducting the voting on the projects and aggregating the data later would not be effective, even aside from the work involved.)
8. Advertise the survey in site-wide banners, at WP:Centralized discussions, at WP:Village pump (proposals), and similar processes on other wikis. Enlist the Tech Ambassadors and Community Liasons to help with this; for projects without any, ask that project's equivalent of the Village Pump for help in getting the word out.

 — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  18:14, 19 December 2017 (UTC)

Thanks for pointing this out and especially for proposing solutions. Do you mind if I link from Signpost coverage of the wishlist? ☆ Bri (talk) 18:35, 19 December 2017 (UTC)

The system is designed to identify what the majority of active editors wants, not what the most pressing issues are. As far as those goals are concerned, the way this is setup is fine. It might be a good idea to have a separate process to identify pressing issues, however.

1) Expanding the number of proposals to 15 is a good way of reducing resources from pressing issues, so if your goal is to cover more urgent needs, that's a rather counter productive suggestion.

2) Anyone can file phabricator tickets whenever they want. I agree that creating phabricator tickets should be mentioned more prominently / encouraged, but we have to recognize that several proposals don't quite fit the tickets model well.

3/4) Bad idea as proposed. A reshuffling of categories may be needed, but 5 is way too few. These are meant as navigational/organizational tools, and if the overwhelming demand is for 4 major improvements on something from the watchlists category, with 100+ supports, then those should take precedence over a proposal for something on Wikisource with 15 supports just because it happened to be the top of its category.

5) I'd rather see the previous proposers re-pinged for support. Developments happen in a year that may reduce the demand for a specific proposal. Something shouldn't be adopted just because it built support over 10 years at a rate of 8 per year, inching over something that had a massive active demand. That's something the proposer should be doing if they really care about their proposal.

6) Mandating rationales is pointless. "This would be useful to me" is implicit to every support. That's what support means.

7) Canvassing is good. That's how you make things happen.

8) More advertising is always good, agreed. The wishlist survey is however, already widely advertised on several mailing lists, noticeboards, village pump, etc. If you know somewhere it wasn't advertised but should have been, the place to bring it up is likely meta:Talk:2017 Community Wishlist Survey or meta:Talk:Community_Tech.

Headbomb {t · c · p · b} 18:57, 19 December 2017 (UTC)

• "getting the MediaWiki developers to focus on building and fixing particular stuff" is a bad summary. The Community Tech team isn't "the MediaWiki developers" but a subset of developers.

Most of the MediaWiki developers develop according to the ideas of the WMF about what would be good to be developed. Given the tensions between the WMF and the Wikipedia editors about tech development that the Wikipedia editors didn't like the WMF created the community tech team with it's own budget to do a subset of development according to the popular wishes of the community. To the extend that arguments are made in proposals that particular features are important for Wikimedia that convince WMF people that those features.

When the WMF hears strong arguments that a specific feature would be import but the proposal doesn't get enough votes it's still possible that the WMF develops it with other resources. ChristianKl (talk) 17:42, 20 December 2017 (UTC)

Reply from Community Tech team

Hi folks: I can answer some of these questions -- I'm the product manager for Community Tech. There's a lot here, so I'll just respond to a few points and then if people are interested, I'm happy to talk about any aspects that you want to talk about.

First up: capacity. We started the Community Tech team two years ago as an experiment, with two developers. The team has been successful so far at delivering on a good chunk of the top 10, and over time, we've been able to bring in more people. There's four developers on the Wishlist team now, which means we can take on bigger and more complex problems, and I expect that the team is going to continue to grow. Right now, saying "let's do top 15" is too much for the current team to deliver on in a year, but if the team grows, we'll be able to do more.

Next: importance vs enthusiasm. There isn't an empirical measure of importance, and people disagree. There are things that are very important to some people that don't affect other people at all. For example: Edit summary length for non-Latin languages was the #2 wish in last year's survey, and the votes came mostly from users on Russian Wikipedia. The problem was that Cyrillic characters count as three characters in unicode instead of one, so people writing in non-Latin languages have had one-third of the space for edit summaries than Latin languages like English. That wouldn't have occurred to me as one of the top issues for the year; I speak and write English, and I had no idea this was a problem. But Russian is the fourth most active Wikipedia, and those editors had to deal with this problem every time they wrote an edit summary -- dozens of times a day. So there just isn't a way to objectively quantify what's important for all people.

Instead, what we're measuring with the Wishlist Survey is the amount of enthusiasm that the Wikimedia community has for each proposal. There's no way to judge whether A is more "important" than B is, but if 150 people show up to support A, and 6 people show up to support B, then that's a pretty good measure of the community's enthusiasm. Given that measure, it is inevitable that people will try to "game the system" by canvassing for support votes. That's why we actively encourage people to canvass -- it's on the main survey page, and we tell people that when we talk about the survey. We can't stop people from canvassing, but if everyone is allowed to do it, then it helps to level the playing field. You can only be successful at gaming the system if you're able to convince people that your idea is important enough to vote for. You don't have to convince Community Tech that it's important, but if you can convince 150 active contributors, then your idea gets to the top of the wishlist.

Given that, I do want to say that we discourage sockpuppeting, and at the end of the voting period, we run a bot that checks how old each voter's account is, and how many edits they've made across all Wikimedia projects. Every year, we find a handful of sockpuppets, and their votes don't count.

So that's the basic philosophy of the Community Wishlist; I hope that answers a couple questions. I'm happy to talk more about changes that people want to suggest, if you want. -- DannyH (WMF) (talk) 00:03, 22 December 2017 (UTC)

FYI

 – Pointer to relevant discussion elsewhere.

Please see: WT:Manual of Style#Proposal: Adopt WP:WikiProject Video games/Article guidelines into MoS.
 — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  01:38, 22 December 2017 (UTC)

• Currently, only the admin who deleted the page/article is visible; but not the creator.
  • "What links here" is usable only if the user hasnt blanked his talkpage.
  • Xtools/sigma show the creation by a particular user, but not creators of a page/article.
• If new page reviewers are able to see all the creators of a deleted, or recreated pages; it would be very helpful to catch PR/paid accounts, and/or socks/LTAs.

I am aware adding such a feature would be complicated. But if only new page reviewers (and nobody else except sysops) could see it in page history, the proposed feature may become reality, and cery useful as well.

Note: This was originally proposed on Sept 09-17 at Wikipedia:Page Curation/Suggested improvements as #55 suggestion. —usernamekiran(talk) 22:07, 18 December 2017 (UTC)

• Support because I am a NPP and think this is helpful. L3X1 (distænt write) 02:29, 19 December 2017 (UTC)
• Support Would be useful. I'm not exactly sure why it should be restricted to NPP though. Actually, another useful addition to that would be in the page curation a notification that the page was created before (and by whom if this is possible) instead of having to go to the logs. Galobtter (pingó mió) 03:42, 19 December 2017 (UTC) May just have to make it a community tech wishlist thing next year..tho Galobtter (pingó mió) 03:43, 19 December 2017 (UTC)

Except that the people who run the wishlist have already said that enhancements to Page Curation are not their department. Kudpung กุดผึ้ง (talk) 08:45, 19 December 2017 (UTC)

Ahh okay, thanks. Galobtter (pingó mió) 09:12, 19 December 2017 (UTC)

@Galobtter: Enhancements to Page Curation are not our department UNLESS people vote for it in the Community Wishlist Survey. Otherwise, it belongs to the Collaboration team. Ryan Kaldari (WMF) (talk) 18:39, 22 December 2017 (UTC)

• I would support some type of functionality to this effect. I feel it should probably be in the logs, and not in any "third party" thing like curator. This would be useful to a great deal of people not limited to NPP. GMG^talk 11:01, 19 December 2017 (UTC)
• Support in theory- reading above in practice it may not be able to be developed, but in theory this would be very useful not only from an NPP standpoint but looking at COI and UPE issues too. jcc (tea and biscuits) 20:00, 19 December 2017 (UTC)
• Strong Support: This information is already available through Xtools if you already suspect that a certain user might have created the article before (searching through user page creation logs), this is just turning it on its head to have a creation log for each page. This feature would be extremely useful, especially to those of us at NPP, and I have no idea why it doesn't exist already. — Insertcleverphrasehere ^{(or here)} 20:39, 19 December 2017 (UTC)
• Support in theory; I can't see any non-technical objections. Boleyn (talk) 06:08, 20 December 2017 (UTC)

Discussion - previous creators proposal

• This seem interesting to me, but why restrict it to to new page reviewers? If the reason is privacy then I think that should be Oversightable anyway. Allowing people who are not NPRs could mean that they could determine if a page is being recreated by a same account or sock of it. Emir of Wikipedia (talk) 22:56, 18 December 2017 (UTC)
• See some discussiond about the matter at User talk:Primefac/Archive 14#Wondering.Regards:)Winged Blades^Godric 10:22, 19 December 2017 (UTC)
• Some usernames are redactable but not Oversight-level issues; such a feature would need to pay attention to this - complicated by the fact that frequently the decision to redact the username would be made after the deletion of the article, and the admin deciding to redact the name would be likely to leave deleted revisions alone. עוד מישהו Od Mishehu 10:37, 19 December 2017 (UTC)
• WMF comment would be needed on this. Currently, all information about deleted revisions may not be accessed without the editor going through an RFA or RFA-like process. The WMF requirement on that has been very consistent and strict. It's unclear whether they would allow this. ~ Rob₁₃^Talk 11:38, 19 December 2017 (UTC)

At least xtools can figure out what deleted pages any user has made - so the information is already available to the public. Galobtter (pingó mió) 11:45, 19 December 2017 (UTC)

User:BU Rob13, the functionality, in my mind, and the way I have discussed it with others in the past, would not to be the ability to see any deleted content, but to see a logged action of creating an article, with a username and a timestamp. This would not be unlike being able to see move, delete, or CSD nom logs for articles, even though you could not see the actual content. GMG^talk 14:00, 19 December 2017 (UTC)

Yeah like the delete log, a create log shown. Galobtter (pingó mió) 14:08, 19 December 2017 (UTC)

Rob, I think I had a nearly identical conversation with you recently on your talk page, and my comment then was it’d be a lot of technical work for little reward. TonyBallioni (talk) 14:03, 19 December 2017 (UTC)

I think you probably mean this thread, where you were talking with Rob, but on Primefac's page. Galobtter (pingó mió) 14:08, 19 December 2017 (UTC)

Lookin there, the server costs etc argument I think is spurious - 100 GBs for storage, and the same cost as logging the edit itself. Also, being only useful to the small fraction of the users that do 90% of the editing is fine.. Galobtter (pingó mió) 14:12, 19 December 2017 (UTC)

The original suggestion talked about seeing "page history", which is the basis for my above comment. For the logging suggestion, my thoughts remain what they were in the above linked thread. Not much benefit, lots of extra log entries. ~ Rob₁₃^Talk 14:13, 19 December 2017 (UTC)

Meh. The "lots of extra log entries" argument comes off a bit like "lots of extra grains of sand on the beach". Given that AFAIK, every CSD nomination creates three separate log entries even if it's not deleted, I don't really think we're terribly pressed for space in that regard. I suppose I would add that a minor improvement if temporary is likely not worth pursing, while a minor improvement that is permanent very well may be. GMG^talk 14:17, 19 December 2017 (UTC)

Agree with GMG - put it better than I would've. Also depends on how much cost is there. Probably need a WMF developer to weigh in, right now all we can do is speculate. Galobtter (pingó mió) 14:19, 19 December 2017 (UTC)

Agree with GMG.Waiting for some WMF guy:)Winged Blades^Godric 15:55, 19 December 2017 (UTC)

Well, most of the entries are available somehow. If a deleted page has not been recreated, then it shows date/time of deletion with the admin who deleted it. Xtools shows deleted pages by a particular user. Non-technically speaking, we need to get that information together somewhere, including the creator(s). Pinging the only two WMF a/c's that I come to my mind. @MusikAnimal (WMF) and DannyH (WMF):, and @Sadads:. —usernamekiran(talk) 18:20, 19 December 2017 (UTC)

Creating log entries for page creation doesn't sound like a terrible idea. We log page moves and deletions, so why not creations? It's true that the logging table is problematically large, so we probably wouldn't want to back-fill for all 44 million pages of English Wikipedia, but otherwise I don't think this would be especially onerous. There's already a Phabricator ticket if folks want to discuss the technical details: T12331. Kaldari (talk) 20:03, 22 December 2017 (UTC)

FYI, the technical implementation is pretty simple. I created a patch here: https://gerrit.wikimedia.org/r/#/c/399897/. No guarantee it will be merged though :P Kaldari (talk) 21:29, 22 December 2017 (UTC)

 Comment: a few days ago, there was a discussion about the requirements for AfD candidates (30/500). It began like this, but later at some point it was converted in an RfC to get more opinions.
In the light of few new comments, it is apparent this new feature would be useful for many cabals including, but not limited to NPP/R, COIN, SPI, among few others. Do you think we should convert this into RfC so that we can get opinions from many editors who work with varity of cabals? I think we should do that. But I dont know how to, so would someone please do it? If it is allowed to do, obviously. —usernamekiran(talk) 01:46, 20 December 2017 (UTC)

Alternative - alter Twinkle (and any other admin tools) so that the edit summary in the deletion log adds a linked mention of the article's author. Cabayi (talk) 13:25, 21 December 2017 (UTC)

@Cabayi: your solution brings only one comment to my mind: bwahahahaha!!
You made all of us look like fools. This is like the simplest, yet best solution so far. But what about the recreated pages? —usernamekiran(talk) 20:36, 21 December 2017 (UTC)

Well, recreated pages would show the latest author of the page in the deletion log entry. Galobtter (pingó mió) 18:45, 22 December 2017 (UTC)

Happy holidays everybody. I would like to propose that the classname printonly, which is apparently restricted to citations, be extended for usage in explanatory footnotes. I have explained my proposal in detail at Template talk:Noprint#Footnote option. Thanks.--Nevé–selbert 12:28, 23 December 2017 (UTC)