Jump to content

Wikipedia:Village pump (proposals)/Archive 143

Add links
From Wikipedia, the free encyclopedia
Village pump (proposals) archive  

This page contains discussions that have been archived from Village pump (proposals). Please do not edit the contents of this page. If you wish to revive any of these discussions, either start a new thread or use the talk page associated with that topic.

< Older discussions · Archives: A, B, C, D, E, F, G, H, I, J, K, L, M, N, O, P, Q, R, S, T, U, V, W, X, Y, Z, AA, AB, AC, AD, AE, AF, AG, AH, AI, AJ, AK, AL, AM, AN, AO, AP, AQ, AR · 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175, 176, 177, 178, 179, 180, 181, 182, 183, 184, 185, 186, 187, 188, 189, 190, 191, 192, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212, 213, 214

RFC on automatic archiving of long user talk pages

The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion. A summary of the conclusions reached follows.
There is no concensus as to the implementation of either of the proposal(s).A skew towards oppose may be noted in the sense that the desired thresholds of talk-page-accesibility-problems widely vary among the discussant(s) and many discussants have felt that it's not our duty to be bothered with other's talk-pages.Additionally, the progress and closure of this concurrent RFC, on a connected topic, may affect the issue under discussion.Winged Blades of GodricOn leave 06:34, 11 November 2017 (UTC)

How should we deal with the problem of long user talk pages (e.g. User talk:ThaddeusB) which makes them very slow to load and extremely slow to edit, especially on older machines (WP:CHOKING). This is particular relevant for inactive/retired editors that are subscribed to newsletters and such. Headbomb {t · c · p · b} 12:27, 11 October 2017 (UTC)

Proposal (2)

This is something that bothered me for a long time, but I'm getting around to tackle it today. Some people have truly massive talkpages (e.g. User talk:ThaddeusB). The problem grows worse over time, since they may be subscribed to newsletters and various twinkle/bot notices. To help remedy this, I propose the following (the exact numbers can be tweaked to something more suitable, if those are off).

Active editors (at least 1 edit in the last year)
  • If a user talk page is over 250K (based on 2.5×WP:SIZERULE, see below for rationale)
  • If a user talk page has more than 25 level 2 sections (==Section==)

Have a bot send a notice, reminding editors that archiving bots exists, with relevant links explaining how to setup archives.

Inactive editors (no edit in the last year)
  • If a user talk page is over 250K (based on 2.5×WP:SIZERULE, see below for rationale)
  • If a user talk page has more than 50 level 2 sections (==Section==)
  • Look for User talk:Foobar subpages with "Archive(s)" in the title
    • If none are found, automatically setup basic archiving ([[User talk:Foobar/Archives/<YYYY>]])
    • If archives are found, list the user talk page on a master list of 'long user talk pages in need of manual archiving', and empower editors to setup an archiving scheme on behalf of the inactive editor (or archive things manually on their behalf).

Headbomb {t · c · p · b} 12:27, 11 October 2017 (UTC)

Survey (automatic archiving of long user talk pages)

  • Support, as proposer. Headbomb {t · c · p · b} 12:27, 11 October 2017 (UTC)
  • Support all of it as proposed, per WP:SIZE. Pages that are much over 100k are literally impossible to edit and/or load at all on some older devices and slower connections, I'm talking a year or two old, not people editing on their Apple II. Long user talk pages especially are a serious detriment to collaboration. However I suggest allowing a {{nobots}}-type flag for users like EEng (sorry to single you out) who deliberately keep their talk pages long for the lulz, so they don't get unnecessary notices. Or maybe they want the notices, so their pages will be even longer? Ivanvector (Talk/Edits) 12:56, 11 October 2017 (UTC)
  • Oppose as written - the #of section headers to send notices and force archiving is too small - getting 25 sections is no big deal, especially if the page size is small. — xaosflux Talk 13:16, 11 October 2017 (UTC)
  • Oppose User talk:ThaddeusB is positively brief compared with the talk pages of some distinguished Wikipedians (at least one is highly distinguished). Leave people alone please on their talk pages. Interventions will just create fuss and bother. I wouldn't object to a single message asking if they want help with archiving if they have no archives already.Thincat (talk) 17:14, 11 October 2017 (UTC)
  • Oppose - 100k is nothing. As written, this is a bad idea. Dennis Brown - 2¢ 21:13, 11 October 2017 (UTC)
  • Oppose I don't want archives of old newsletters. It might be better to arrange for newsletters keep themselves tidy by automatically deleting their previous edition. Andrew D. (talk) 22:19, 11 October 2017 (UTC)
How is having 100 sections of newsletter on the talk page is better? Headbomb {t · c · p · b} 23:14, 11 October 2017 (UTC)
This would actually be really useful. —Tom Morris (talk) 20:50, 23 October 2017 (UTC)
  • Oppose - I'm not seeing this as a problem needing a solution forced on editors against their will. Beyond My Ken (talk) 23:22, 11 October 2017 (UTC)
  • Support in principle The number of sections is ultimately irrelevant but yes, we should have *any* content here ultimately capped somewhere or else it will become unusable/unnavigable to other readers. In user/user talk namespaces, we can be more lenient but user talk is not a personal playground or personal hosting--it's made for others to interact with you. ―Justin (koavf)❤T☮C☺M☯ 23:28, 11 October 2017 (UTC)
  • Oppose overzealous policing of user's own territory. For inactive users, it is unnecessary, and active users have the right to display their obnoxiousness if that is their choice. Sure, you can send active editors with talk pages longer than 800k (comparable to the longest page at Special:Longpages) a polite notice, but enforcing restrictions is only going to cause completely unnecessary drama. —Kusma (t·c) 09:12, 12 October 2017 (UTC)
It certainly matters for inactive users. E.g. User talk:La Pianista has 223 sections, exceeding 336 KB, with the vast majority those populated by newsletters. It grows at a rate of roughly 30 KB/year, and has doubled in size since she's effectively retired in 2012. It's taking 12+ seconds to load on my Pixel on university wifi (which is usually extremely fast here) by comparison, my own talk page took about 2 seconds. This may not matter a whole lot to me, because I live in a wealthy nation with access to faster technology and solid wifi, but it will matter a whole lot more to someone in a developing nation, with crap wifi, and lesser phones, or those limited by data caps (see WP:CHOKING).

And no one is proposing forcing any active users to do anything. But a reminder that their page is getting out of hand will alleviate the issue in many pages. If we feel 1 years is too little to inactivity, then go to 2 years, or if 250 KB is too little, then go to 500 KB. But 2.5 times WP:SIZERULE seems like a reasonable thing to me. Headbomb {t · c · p · b} 17:23, 12 October 2017 (UTC)

@Headbomb: If you're using SIZERULE as a guide, be aware that those numbers refer to "readable prose size", which is generally far smaller than page size/file size. E.g. Donald Trump currently has readable prose size of 80K (as measured by User talk:Dr pda/prosesize.js) and page size of 317K. Prosesize.js has its limitations and I haven't found a good way to measure prose size with much accuracy. That would appear to make SIZERULE problematic as a guide; I'd suggest abandoning it and just choosing a reasonable page size. This advice is worth about what you paid for it. ―Mandruss ☎ 17:45, 12 October 2017 (UTC)
I'm aware it's prose size, but on talk page, wikitext and prose do match a lot closer than on articles. The code-to-prose ratio of templates (and references) in the mainspace is very high, which is not usually the case in talk pages. The proze-to-size ratio seems about 2.5:1 from what I can tell by doing some limited test with prozesize.js on simplified pages (try it here, I get a ratio of 2.32 on my page), so it suggests to me that 2.5 times × 100 KB is a reasonable treshold. I'm certainly open to any other reasonable yardstick. WP:CHOKING say 32 KB = 5 seconds on dial up, which ignores images and the rest of the Wikipedia interface. 250 KB would be 39 seconds just to download the page on dialup, and if you have dialup, chances are you're not running the most recent of computers either, and you'll need quite a while to render the page as well. Headbomb {t · c · p · b} 18:02, 12 October 2017 (UTC)
So? We shouldn't hold on making Wikipedia more accessible and user friendly (especially to those who lack advanced technological resources) because one person insists on having a long talk page (a choice they'd still be allowed to have). Headbomb {t · c · p · b} 14:16, 13 October 2017 (UTC)
  • Oppose. We have no business imposing this kind of thing on editors, especially since there's no policy that says that it has to be this way. Moreover, if the auto-archiving bot comes around during the middle of a discussion, it might archive the first part of the discussion and force an un-archive; whether or not to archive is something that should never be done by a bot, except when the bot's following the instructions of the user in question. Nyttend (talk) 23:00, 13 October 2017 (UTC)
I don't think you understand how archive bots work. They can't 'coming in the middle of a discussion', or archive parts of one. Headbomb {t · c · p · b} 21:35, 15 October 2017 (UTC)
  • Oppose it's annoying AF, but annoyance is a "me" problem not a "them" problem. No need to force this to happen. --Jayron32 19:39, 16 October 2017 (UTC)
  • Oppose. Even 250kb is nothing; it's not unusual for my talkpage to get up to that kind of length just because there happen to be a few lengthy discussions taking place simultaneously (as I write this it's on about 120kb), and I can't imagine anyone being pleased to keep being pestered by a hectoring nanny-bot ordering them to comply with a non-existent maximum size policy. If you find someone's talkpage annoying for whatever reason, feel free to tell them to their face that you find it annoying, but don't insist that everyone else comply with your personal preferences. ‑ Iridescent 19:48, 16 October 2017 (UTC)
  • Oppose - At most, a user could nudge newer editors in the right direction. No need to codify or harass users over something such as this. Nihlus 19:51, 16 October 2017 (UTC)
  • Oppose - Because you have rejected out of hand fixing a main driver of the problem, subscriptions, even though mentioned "The problem grows worse over time, since they may be subscribed to newsletters and various twinkle/bot notices." Instead you want to save/store/preserve the advertising brochures rather than stopping them in the first place? Shenme (talk) 23:39, 22 October 2017 (UTC)
  • Support but do it at 2MB when it will become actually impossible to save the page. Jc86035 (talk) 03:44, 23 October 2017 (UTC)
  • Support It is an WP:ACCESSIBILITY issue, really. 250k seems like a decent yardstick to notify users and to auto archive for inactive users. — Insertcleverphrasehere (or here) 02:48, 25 October 2017 (UTC)
  • Support. It is a very bad idea though. If it were up to me, I'd have implemented a more advanced form of Flow (similar to WikiData) and did away with current talk pages and their pesky archival problems. (It'd be load-on-demand per thread.) —Codename Lisa (talk) 05:50, 25 October 2017 (UTC)
You're supporting something even though it's "a very bad idea"??? EEng 06:02, 25 October 2017 (UTC)
Ha ha! I really wanted to know who would write this first. Writing it means pretending not to know that I actually meant "but not doing it is a worse idea". Actually, I dropped a hint too, by writing a better idea, giving clear indications that I think status quo is a problem.
I kinda hoped an admin would ask such a question. But that would be abysmal.
—Codename Lisa (talk) 06:55, 25 October 2017 (UTC)
  • Support reminder that archival bots exist, but: how often do we send the notice should be discussed. Maybe it can be a one-off thing for currently existing users, and then post it for accounts created later when they first bump into whatever threshold is decided, but that needs a bit of thinking about the architecture (how do you keep the list of notified users?). Oppose "forced" archival of inactive user pages - if a user is inactive, it is unlikely that many people will come to their TP anyways, so I do not think it is worth the "invasion". TigraanClick here to contact me 19:00, 26 October 2017 (UTC)
  • Oppose we shouldn't muck with other people's talkpages especially if they are on a long break, but here's an alt suggestion. Why not just autolapse editors from subscriptions if they haven't edited in 6 months? It should be easy to change the newsletter bots to only post to talkpages of editors who have been active in the last 6 months. ϢereSpielChequers 09:38, 27 October 2017 (UTC)
I'm nominating this for Best Idea of the Year. It should apply to SuggestBot as well. EEng 11:36, 27 October 2017 (UTC)
I support the current proposal, but I also support this idea. Give it its own RFC, and you can consider me a support. —swpbT go beyond 18:15, 27 October 2017 (UTC)
OK swpb Wikipedia:Village_pump_(proposals)#Auto_skip_inactive_editors_from_newsletters is started. ϢereSpielChequers 19:17, 27 October 2017 (UTC)
  • Support. Active editors can easily ignore this, and inactive editors' concerns should be secondary to those of the active editors who, for whatever reason, need to load these talk pages. —swpbT go beyond 18:12, 27 October 2017 (UTC)
  • Support. I support this, and wish for this, for all talk pages. Some talk pages, especially old user talk page, have been extremely problematic for me due to a weak connect. Auto-archiving a 1MB, would be good. --SmokeyJoe (talk) 23:53, 30 October 2017 (UTC)
  • Oppose - We should not be concerning ourselves with the talk pages of other editors. And we needn't pretend that the talk pages of inactive users are somehow causing difficulty for the community and stress on our computers. Swarm ♠ 20:32, 2 November 2017 (UTC)
  • Support with caveats: should only be done for truly excessively large (like crash danger or inability to save page in some major browsers, whatever that number is); user (if active) has the right to disable the archival after the page is under a manageable size.  — SMcCandlish ☏ ¢ >ʌⱷ҅ᴥⱷʌ<  15:50, 6 November 2017 (UTC)
  • Oppose - We're here to build an encyclopedia .... not start worrying over silly things like talkpage size, if an editor cannot be arsed to archive then fine, If on the other hand they can then great. –Davey2010Talk 00:12, 11 November 2017 (UTC)

Discussion (automatic archiving of long user talk pages)

The problem with that is that some people may be inactive on Wikipedia, but still read the newsletters/want to be notified by RSS, or whatever. Headbomb {t · c · p · b} 21:03, 11 October 2017 (UTC)
Yet, the most effective action to motivate users to "clean up" would be to simply stop automatic posting from subscriptions, when pages get "too large". Taking responsibility is no bad thing. Shenme (talk) 23:43, 22 October 2017 (UTC)
  • Comment: AFAIK, the number of sections in a talk page does not affect usability. Size is the issue, so let's focus on size. In any event, my talk page currently has 23 level-2 sections, is archived regularly, dates back less than four months, and is only 30K, yet by the criteria above, I would get a notification with only two more sections added. That would be a problem. The example page given above, User talk:ThaddeusB, has 266 sections and is 393K. Headbomb, please consider revising the criteria based on a purely technical rationale. – Jonesey95 (talk) 14:11, 11 October 2017 (UTC)
What about x number of headings which haven't been edited in so many days? That's how the archiving bots determine staleness. Say, if you have more than 25 threads which meet CB3's basic staleness criteria, you get a notice? But also, Headbomb, the bot should check for existing archives for both active and inactive users, then pages like Jonesey95's wouldn't get flagged for a notice. Ivanvector (Talk/Edits) 16:05, 11 October 2017 (UTC)
Jonesey wouldn't get flagged for a notice, since his talk page is well below 100 KB (as are pretty much any page with archives setup). I suppose it wouldn't hurt to check for archives though, in the odd chance that his talk page somehow more than triples in size before the archive bot has a change to do its job. Headbomb {t · c · p · b} 17:38, 12 October 2017 (UTC)
Agreed. The worst case I'm aware of currently has 480 sections and it takes me about 7 seconds to scroll through the TOC. Annoying? Yes. Significant problem? Not really. Currently #171 on my Wikipedia Annoyances List. ―Mandruss ☎ 16:32, 11 October 2017 (UTC)
Actually, CB3's default staleness age is 0 hours, so I guess we would have to define it differently for this. Ivanvector (Talk/Edits) 16:08, 11 October 2017 (UTC)
Yes, but increasing a page's length by 1% to prompt them to cut it down by 90%+ is worth it. Headbomb {t · c · p · b} 21:09, 11 October 2017 (UTC)
  • Comment: I support this idea in principle, but how many pages are affected here? Are we talking about ten pages, or 10,000 pages? Let's at least have a sense of the scale of this problem. I think that makes a difference. I request a histogram of the number of pages of a given size, perhaps something like 100K to 250K, 250 to 500K, 500 to 750K, 750K or more. That might help us determine a good breakpoint for a rule. – Jonesey95 (talk) 00:32, 16 October 2017 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Exponentially increasing the potential of charitable contributions that would have been lost with 2 simple changes.

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.

Simple diff

Normal diff
Simple diff

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)

Using Wikimedia maps instead of geohack ?

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

TfD for Authority Control

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)

Appeal by Δ (BetaCommand)

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)

Allow prominent linking to expert- or peer-reviewed articles

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)

$200 worth of books to win

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)

2 Solutions for allowing Tor users

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.

Renaming "Hyperloop Makers UPV" to "Hyperloop UPV"

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. GMGtalk 19:15, 27 November 2017 (UTC)

Show the metadata gadget to all readers

The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion. A summary of the conclusions reached follows.
There is a near unanimous consensus to oppose the proposal. The arbitrarily lettered grading scale of the project and the acute subjectiveness of the entire process outweighs it's benefits (if any) massively. Winged Blades Godric 16:43, 28 November 2017 (UTC)

The metadata gadget gives a reader a summary assessment of the quality of the article in question. In the case of featured and good articles, it is more prominent than the star or icon on the side. In the case of lower quality articles, it gives the reader an expectation of the quality of the content that they are going to see (they can then read the article and then judge it on its own merits).

Should the Wikipedia:Metadata gadget be shown to all readers, logged in or logged out, regardless of whether it is enabled as a gadget for registered users? My name isnotdave (talk/contribs) 12:22, 10 November 2017 (UTC)

Survey (Show the metadata gadget to all readers)

  • oppose — Readers unfamiliar with wikipedia may find this confusing. And you say you don't want it to be enabled by default, but how else would readers that aren't logged in activate/deactivate it? Natureium (talk) 20:37, 10 November 2017 (UTC)
  • Strong Oppose both from the resource concerns discussed below, but also because this system is not designed for readers. FA's and GA's already get an article identifier. If we want a full quality rating system, we need to pick one and install it (e.g. a flavor of mw:Extension:FlaggedRevs or the like. — xaosflux Talk 21:36, 10 November 2017 (UTC)
  • Oppose – There isn't a compelling encyclopedic reason to impose our internal quality rating system on our readers. All of the classes other than FA and GA (and the rare A-Class) are self-assigned, oftentimes even by the creator of the article themselves. As a result, there is a good deal of variation in the actual quality of specific ratings – some B-Classes could very well be GAs whereas others are probably closer to C-Class or even Start-Class. Given the amount of subjectivity, these quality ratings are probably less important/meaningful to readers as they might be to editors. Mz7 (talk) 23:31, 10 November 2017 (UTC)
  • Oppose - I see no value in this proposal. Beyond My Ken (talk) 18:05, 11 November 2017 (UTC)
  • Oppose the rating system, especially beyond GA/FA (which are already displayed), has too many problems to be promoted to logged-out users. power~enwiki (π, ν) 18:51, 11 November 2017 (UTC)
  • Oppose not a default suited tool, showing it for all readers is effectively that. The article rating system is just an internal tracker mostly for WikiProject work tables, all that matters for the readers is GA/FA and stub, all of which are shown already. Any editor who needs this ought to have enabled it already. Dysklyver 12:26, 12 November 2017 (UTC)
  • Support Providing it would not put an unreasonable drain on the servers (and I accept it may well do!), I see absolutely no reason for hiding any quality/completeness assessment from any of our readers or editors, whether logged in or not. We invite both user-types to make improvements where they can, so should facilitate them seeing how the community has currently assessed each article and encourage their improvement where we can. It's a really useful guide to editors on page quality, whilst non non-editors (school students especially) should be aware of the quailty of what we're giving them to use in their homework. Someone said there's no compelling reason - I think the reverse. It should be available by default, and removable if wished by logged-in users. As the Hovercard page eloquently explains: Unfortunately, there is no good way to tell users about a new feature without showing it to them first. OK, it's not a new feature, but why on earth should we hide our own assessment of the quality of each page? If the assessment is wrong, having it more clearly displayed can only encourage others to make a re-evaluation or an improvemnt to the article. Stamp it on every page, I'd say. Regards from the UK, Nick Moyes (talk) 17:25, 12 November 2017 (UTC)
  • Oppose. I use it, and find it useful, but that's because I understand how the system works; a tiny minority of IP-only editors will benefit from this, but 99.9% of anglophone Internet users won't understand what it means, and we'll confuse a good proportion of them. `Nyttend (talk)
  • Oppose, will confuse majority of readers. Stifle (talk) 10:30, 14 November 2017 (UTC)
  • I have no idea what this is and neither will 99% of readers TonyBallioni (talk) 23:23, 14 November 2017 (UTC)
  • Oppose. Other than FA, GA and stub, all of which are already flagged to readers, Wikipedia's article assessment scale is almost completely arbitrary and will mean absolutely nothing to readers. (Would you understand a grading scale where the grades are S-C-B-G-A-F if it weren't explained to you?) If anything, we should probably be deprecating it altogether, as its original purpose (to determine which articles were of an adequate enough quality to be included in proposed print and CD-ROM versions of Wikipedia) is long since obsolete. ‑ Iridescent 23:32, 14 November 2017 (UTC)
  • Oppose. The assessments are totally subjective. For those articles that don't go through WP:FAN, WP:GAN, or WP:Peer review, anyone can assess an article as whatever grade they want, which isn't very helpful for our readers. -- œ™ 04:58, 15 November 2017 (UTC)
  • Oppose Showing this for everyone will just confuse the large majority of Wikipedia readers that don't understand Wikipedia quality standards. EMachine03 (talk) 14:29, 15 November 2017 (UTC)
  • Oppose. Ugh. feminist 15:02, 18 November 2017 (UTC)
  • Support Most articles are utter junk and the reader should know that. Chris Troutman (talk) 21:01, 18 November 2017 (UTC)
  • Oppose As per Mz7. This would be a lot of overhead for what is very little objective information. Dennis Brown - 2¢ 17:24, 20 November 2017 (UTC)
  • Oppose - This would only confuse our readers and that isn't something we want to do.... –Davey2010Talk 21:01, 20 November 2017 (UTC)
  • Oppose - Newby opinion: for all other information sources, consumers decide for themselves how reliable, complete, neutral etc. the information (and provider) needs to be and actually is. To varying degrees they have confidence in the editorial policy and processes of information sources. I think we have to trust the intelligence of information consumers to discern good quality from poor quality as they do elsewhere. If articles fall below 'acceptable editorial standards' we should withdraw them from publication until such time as they do. Mikemorrell49 (talk) 15:30, 22 November 2017 (UTC)
  • Oppose - Aesthetically ugly, clutter, and article assessment ratings are frequently inaccurate. Neutralitytalk 21:40, 22 November 2017 (UTC)

Threaded discussion (Show the metadata gadget to all readers)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

RfC: Add a link to Wikinews on the Main Page

The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion. A summary of the conclusions reached follows.
There is a snow consensus to oppose this proposal.And, there seems to be a near-unanimous consensus that Wikinews is effectively dead and sending our readers to such a project will be a dis-service. Winged Blades Godric 16:49, 28 November 2017 (UTC)

Proposal: A link to Wikinews should be on the main page, perhaps in the "In the news" section.

Rationale: A recent RfC on WP:NOTNEWS stated that the policy should be loosened because "Wikinews is dead". Regardless of the outcome of that RfC, I believe that Wikinews' problem is the lack of outside readership, and therefore editors. A more prominent location on Wikipedia's homepage would likely do wonders for the traffic to Wikinews, which is likely the only viable solution for its lack of readership and contributors.

As I put it in the Idea Lab, which I posted when I was more awake and by extension a lot more convincing:

The rationale is "Wikinews is dead". You know, sure. It's not the most popular WMF project - not by a long shot. However, the problem is mainly that:

  1. No one seems to know it exists (except the more active Wikipedians)
  2. Not many non-editors go there
  3. No one seems to know it exists (again, I know, but no one does)

I know Wikinews is technically on the main page by the other WMF pet projects, but a link in In the news will be more beneficial to WN.

Below is a copy of the discussion on the Idea Lab. Thanks. ProgrammingGeek talktome 15:19, 16 November 2017 (UTC)

Discussion copy

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Okay, I know what you're thinking. Hear me out.

This RfC proposes to reduce the enforcement of WP:NOTNEWS to increase news coverage on Wikipedia.

The rationale is "Wikinews is dead". You know, sure. It's not the most popular WMF project - not by a long shot. However, the problem is mainly that:

  1. No one seems to know it exists (except the more active Wikipedians)
  2. Not many non-editors go there
  3. No one seems to know it exists (again, I know, but no one does)

Whether or not it's a good or bad idea to put news in Wikipedia is not a discussion for here. However, why does wikipedia not try to increase awareness of sister WMF projects? enwiki is in a good place to do this, it's one of the most popular websites in the world, and is renowned for its impartiality and stunning dedication to consensus. WN is much the same, but without participation. If we could increase participation and awareness (the two go hand in hand, just look at the growth of the number of editors on enwiki), then it could be a quality news source that people rely on.

Isn't it already on the front page? Yes, technically. By the links for Wikibooks and the other pet projects of the WMF. However, if we could link to it more prominently (eventually link to WN articles in the In the News section, perhaps), it would grow a lot more.

Haven't we given it up for dead? They're still publishing articles over there, although admittedly few. We could do a lot better!

I'd just like thoughts at this point. Thanks. ProgrammingGeek talktome 15:56, 8 November 2017 (UTC)

This does not address the fundamental problem of; consumer demand of recentism and Wikipedia quality vs. Wikipedia's rigid stylistic form and immediate publishing vs. copy cat news website that usually publishes after people stopped showing interest in the topic, if at all. We have created this situation to reflect our reality, but we need to recognize that it is not a situation that a consumer will ever consider logical. As such we cannot fix the problem unless we start bending either Wikinews or Wikipedia to closer match the desire of real consumers of the information. —TheDJ (talk • contribs) 16:20, 8 November 2017 (UTC)
There's several concurrent discussions related to NOT#NEWS in general, but one of the issues that comes up is the "consumer" aspect - that we do know people are coming to Wikipedia for current news articles. The problem is that an encyclopedia should be the last place you come to breaking news, as we're supposed to be summarizing news with a long-term view. There are stories that we can write on en.wiki with that perspective, but it is a very careful approach, but vastly different from how one would write a standard newspaper article (eg what would be more appropriate at Wikinews). Unfortunately, there's a fair number of editors that like to write recent news, and no end of consumers for that. That said, we have in the past taken steps to cut off content that may have been consumer-driven: for example, early on was the removal of endless lists of fiction-related elements that were only sourced to primary works (eg Pokemon lists). They may have been popular pages, but as they were written then, not encyclopedic content. We have to have a consensus decision to cut off current event articles and move them elsewhere, and these concurrent discussions suggest that's not going to happen easily. --MASEM (t) 19:02, 8 November 2017 (UTC)
Masem, exactly. We have a ready-made location for this sort of content. I don't want it to seem like we're outsourcing the problem, but if people know about Wikinews, we won't be inundated with these articles. ProgrammingGeek talktome 19:11, 8 November 2017 (UTC)

To raise awareness of other Wikimedia foundation projects, could we not put information about them on Wikipedia: Main Page? The main page is one of the most viewed articles on Wikipedia, if not the most viewed, and putting information about Wikipedia's sister projects on the main page would seem a good way to raise awareness of them. Vorbee (talk) 18:23, 8 November 2017 (UTC)

The Main Page of Wikipedia has a section in its top right-hand corner called "In the news..." ... it should not prove too difficult to put in a note that there is such a website as Wikinews there.Vorbee (talk) 20:14, 8 November 2017 (UTC)

  • I support linking to Wikinews articles in the "In the news" section of the main page because Wikipedia is not for news, but Wikinews is, and if we're going to mention news on our main page, we should link to our sister project, not just Wikipedia articles. Conservapedia has a similar section on its main page, commonly known as "mainpageright," it has included links to external sites for a long time, and it is one of the most popular features of the wiki. PCHS-NJROTC (Messages)Have a blessed day. 22:10, 8 November 2017 (UTC)
  • This does seem like a useful idea, regardless of other developments (unless there is a vested interest in actually having WikiNews wither on the vine). --Elmidae (talk · contribs) 09:25, 15 November 2017 (UTC)

Perhaps we could have a note at the bottom of the Main Page's "In the news" box saying "For more information on news stories, see Wikinews". Vorbee (talk) 16:31, 15 November 2017 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
  1. Oppose WikiNews is dead. They have nothing serious to offer our readers and would decrease our credibility. I'd support a global RfC just to get rid of it as a project. While I am very much team NOTNEWS needs to be enforced, our ITN section offers our readers infinitely more than WikiNews ever would. Sending people who want to learn about relevant current events to a project that doesn't have that would be a joke. TonyBallioni (talk) 21:55, 16 November 2017 (UTC)
  2. Wikinews is completely defunct and the only reason it still exists is that nobody has the energy to start the Meta RFC to pull the plug. (FWIW, in the entire month of September a mighty 19 people made five or more edits there, and that was the highest rate of activity for over a year.) Even Jimmy, who was the main cheerleader for creating it, has lost all interest and has instead set up a direct rival. The conversation to be having is how it can be put out of its misery most painlessly, not what we can do to prop it up a little while longer. ‑ Iridescent 22:12, 16 November 2017 (UTC)
  3. I wanted to support this as an experiment, but then I remembered that we used to have the Wikinews link until 2013. Things were not much better then. Note that I would support a "link to Wikinews" proposal if there was at the same time an effort to re-start Wikinews (which currently has many problems, mostly linked to the fact that it isn't a very wiki Wiki). —Kusma (t·c) 18:02, 19 November 2017 (UTC)
    For the curious, if you look at the Wikinews page views (third chart down), removing the link had almost no measurable impact on average page views. (The later apparent crash in 2015 is an artefact of the WMF deciding not to count crawler bots as "page views", and doesn't reflect any actual change in the number of readers.) ‑ Iridescent 18:08, 19 November 2017 (UTC)
  4. I suspect wikinews is effectively dead as per evidence posted above. And linking will not benefit it Cas Liber (talk · contribs) 23:30, 19 November 2017 (UTC)
  5. I don't support propping it up. If it survives, it should be on its own merits. If it regains merit, then we would consider linking it. Linking it now is a disservice to the reader. Dennis Brown - 2¢ 17:22, 20 November 2017 (UTC)
  6. Their recent changes indicate WikiNews is long dead, Seems kinda stupid to redirect our readers to a site they have 0 interest in and is long dead, Linking could bring in some editors but I highly doubt it, If anyone wants to run an Meta RFC on pulling the plug I'd support that tho!. –Davey2010Talk 20:55, 20 November 2017 (UTC)
  7. Don't prominently link to it from the main page, and NOINDEX it because it's no kind of service to the reader in its present state. --Anthonyhcole (talk · contribs · email) 10:05, 21 November 2017 (UTC)
  8. Oppose. Wikinews is dead and should be put out of its misery altogether. Neutralitytalk 04:41, 23 November 2017 (UTC)
  9. Directing our readers to Wikinews would be doing them a disservice. It is a dead project walking and cannot make any credible claim of being able to keep whatever readers there may be informed. The Wicked Twisted Road (talk) 18:20, 23 November 2017 (UTC)
  10. Jesus tapdancing christ no. FACE WITH TEARS OF JOY [u+1F602] 04:01, 28 November 2017 (UTC)
  • "Wikinews is inactive"? If someone wanted to delete all the sister project link, transwiki request, etc. templates (except for the Wiktionary, Commons, and Meta ones) for that reason, then they'd be laughed out of TFD. KMF (talk) 23:22, 18 November 2017 (UTC)
    Not surprisingly, this has absolutely nothing to do with those templates. It has to do with putting a more prominent link to Wikinews on the main page. --Majora (talk) 23:54, 18 November 2017 (UTC)

As I tried to show at the Ideas Lab, I would be in favour of such an idea. Vorbee (talk) 16:48, 19 November 2017 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Convert all old full creation protected articles to ECP creation protection

Withdrawn. ~ Rob13Talk 15:15, 28 November 2017 (UTC)

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Historically, we’ve used full protection as the usual form of creation protection because it was the lowest form of protection that tended to work in that scenario. Since the introduction of extended confirmed protection, creation protecting at this level has become more popular (endorsed for this usage near unanimously at WP:ECPP2). Editors with 30 days and 500 edits on the project can generally be trusted not to recreate an article with serious issues. It’s good to lower protection where possible, so I propose we switch all articles which were fully creation protected before ECP existed to ECP creation protection. This does not prevent admins from using full creation protection if appropriate going forward, just lowers protection where ECP was previously not an option. Thoughts? ~ Rob13Talk 19:48, 27 November 2017 (UTC)

@BU Rob13: Do you have a list of articles saved anywhere? Or are you talking about all of the articles found here? Nihlus 20:11, 27 November 2017 (UTC)
The articles included would by everything on the list you link to minus everything protected after ECP was introduced. I don’t have a list saved anywhere, but one could easily be generated (pinging Oshwah). If preferred, the list could be up for a certain period of review where any admin can remove an entry to keep it fully protected. ~ Rob13Talk 20:14, 27 November 2017 (UTC)
BU Rob13 - Here you go. ~Oshwah~(talk) (contribs) 20:45, 27 November 2017 (UTC)
How often do editors have to contact an admin to unprotect a salted page? Looking at that list, it seems most of those articles would never need to be created. Natureium (talk) 20:25, 27 November 2017 (UTC)
  • Strong Oppose I have mixed views on this because I hate when people come to DRV asking for permission to move something into mainspace, because I think it is used as a way to "G4-proof" an article. This would get rid of that excuse. At the same time, salted articles like Steak and Blowjob Day, sometimes get picked up by good faith editors, and there should be a firm consensus to unsalt before we allow them back in mainspace. Full protection is the only way to ensure that. I also don't see the advantage of a manual review of each of the these articles, which per Steak and Blowjob Day would be needed. Most of these articles shouldn't be created and doing a manual review of them for the principle of lowering protection on an article no one actually wants seems like a waste of volunteer resources. TonyBallioni (talk) 20:30, 27 November 2017 (UTC)
    • Updating this to Strong Oppose after Oshwah told me off-wiki the number of full-protected salted pages linked above is 4742. Lowering all of those without review is a horrible idea and manually doing it would be a bigger time suck than I had guessed. TonyBallioni (talk) 20:54, 27 November 2017 (UTC)
      I don't think there was any statement in the proposal that specifically says "will do it automatically" or "without review". Nor do I think that you should oppose the other option for the length of time it would take. We should rarely be indefinitely create-protecting anything, and as the AN discussion is evidencing, several admins have mis-fired on the trigger for blocks--I expect a similar reaction to the protected ones as well. (No comment on the original comment.) --Izno (talk) 22:55, 27 November 2017 (UTC)
  • Oppose because this is a solution in search of a problem. WP:RFPP rarely has a backlog of more than a day or two, and users who wish to remove protection just have to ask. --Jayron32 15:03, 28 November 2017 (UTC)
  • Oppose - Protection can be easily lifted when necessary as all a user needs to do is bring it to the attention of the protecting administrator (or eventually bring it to RFPP). This seems like a lot of work for a very limited benefit. Nihlus 15:09, 28 November 2017 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
  • 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)

RFC on production section wording in the Film Manual of Style

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)

Avatars On Wikipedia

SNOW CLOSE
Clearly not happening. ♠PMC♠ (talk) 06:39, 29 November 2017 (UTC)

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

It would be nice if each user has the option to have his or her own avatar. I know Wikipedia isn't a social networking site, but Wikia does enable avatars. Who knows, it may also attract potential new users and increase the growth rate of Wikipedia.31.215.115.49 (talk) 16:42, 28 November 2017 (UTC)

  • Oppose Wikipedia is neither a social networking site nor Wikia. Also, avatars (unless of the simplest form, like the letter-in-a-coloured-disc as used by GMail) are images, and this would be against WP:SIGIMAGE. In any case, this has been discussed and rejected before. --Redrose64 🌹 (talk) 18:06, 28 November 2017 (UTC)
  • Oppose. What Wikia does is completely irrelevant; they're a site for the organisation of fan clubs, and we're an academic collaboration. Without wanting to sound too elitist, we want new editors who come because they want to contribute something useful, not the sort of people to whom "does it allow avatars" is a consideration. With 61,849,232 pages currently, "increasing the growth rate of Wikipedia" is the least of our worries. ‑ Iridescent 18:10, 28 November 2017 (UTC)
  • Oppose: It is completely counter-intuitive to our purpse and would make us look less professional and trustworthy to outsiders. --Deathawk (talk) 05:56, 29 November 2017 (UTC)
  • Oppose, but for a different reason. I feel that customizing your own signature is already a pretty good compromise for self-expression. Having jumping animated GIFs bouncing around as avatars, well, you can imagine how quickly that would devolve. Let alone the technical challenges of it. Where would the avatar appear? If it were Facebook style (at the beginning of a comment), I'm not even sure how that would be implemented in our current system. Drewmutt (^ᴥ^) talk 06:24, 29 November 2017 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Proposal to enhance the "Search Wikipedia" box

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

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

Add always-present template at the top of every draft.

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)

Limit the size of biographical infoboxes and use succession boxes for multiple offices

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://wiki.riteme.site/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)

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)

Auto skip inactive editors from newsletters

The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion. A summary of the conclusions reached follows.
  • Summary:-There is a near-unanimous consensus to support the proposal.
  • Enactment:-Thus, the following policy is enacted:--

Editors will be auto-suspended from any subscriptions, newsletters etc. being delivered/mass-messaged to their talk-page, if they haven't edited in a year.But, an editor shall have an option to exclude him/her out of this mandatory delisting, if he/she chooses to.

  • Caveat-A local disc. may be launched at some appropriate venue to establish consensus as to whether the defining last edit has to be local or it can be global.
Best of wishes for the technical challenges etc. that might need to be scaled in the execution of the consensus:)
Thankfully,Winged Blades Godric 14:10, 3 December 2017 (UTC)

Editors come and go, but if someone has not been around for a year or three their talkpage can get very cluttered with newsletters. Eventually as per an earlier proposal this prompts others to suggest that said inactive editor should start talkpage archiving, so why not autosuspend editors from subscriptions if they haven't edited in 4 months? It should be easy to change the newsletter bots to only post to talkpages of editors who have been active in the last 4 months. ϢereSpielChequers 19:15, 27 October 2017 (UTC)

Update. 4 months is arbitrary, I'm not actually bothered between 4 months and 12 months. Perhaps if others express a view on this then if the proposal has consensus the closer can set the time period. ϢereSpielChequers 10:48, 29 October 2017 (UTC)

Survey (Auto skip inactive editors from newsletters)

  • Support As proposer. ϢereSpielChequers 19:15, 27 October 2017 (UTC)
  • Support at one year. Users inactive for that long don't need active newsletter posts. Four months might be safe, but a year is safer. —swpbT go beyond 19:33, 27 October 2017 (UTC)
  • Support at whatever time threshold (4 months, year, ...). And this should be the default behavior for bots such as User:SuggestBot and Feedback Request Service. Of course, there should be an opt-out so people can ask continue to receive these posts despite their own inactivity. EEng 21:56, 27 October 2017 (UTC)
    The problem with in opt-in option is that some of us (and they don't know it) will either die suddenly, or become permanently incapable of editing Wikipedia suddenly. We don't want these users' talk pages to become cluttered with newsletters. While some of these users have friends who would be trusted to confirm that they will never be back, most probably don't. עוד מישהו Od Mishehu 12:46, 29 October 2017 (UTC)
    I said opt out i.e. the mechanism for suspending delivery after X months of a user's inactivity is active by default, but a user can opt out of that stop-after-4-months'-activity behavior if he wants i.e. set it so that even if he's inactive for X months, delivery continues indefinitely. No matter what, as soon as the editor makes any single edit, he's no longer inactive and delivery resumes. EEng 13:13, 29 October 2017 (UTC)
    A user opts out of delivery stoppiong, and then if this user dies suddenly (perhaps several years later), delivery still continues indefinitely. If it's reasonably possible, I would certainly say that if a user goes on a declared WikiBreak, delivery could start at the last round before the declared return date; however, we do need to put an absolute, non-overridable, date beyond which delivery stops. עוד מישהו Od Mishehu 07:55, 30 October 2017 (UTC)
  • Support Long, cluttered talk pages make it hard to see substantive content, and it is sometimes necessary to investigate why some things were done a certain way. Also, while monitoring pages with broken templates I have often found user talk pages where templates no longer work due to superfluous bot messages. Johnuniq (talk) 22:01, 27 October 2017 (UTC)
  • Support. Newsletters piling up on inactive talk pages is a nuisance. Alsee (talk) 23:41, 27 October 2017 (UTC)
  • Support, but give the user a notification to tell them their newsletters won't be sent if they don't perform an edit or logged action within the next N days (and/or a notification after the suspension of newsletters). Jc86035 (talk) 10:57, 28 October 2017 (UTC)
And so it begins. Let's not start adding more posts. They're just newsletters. Most such posts have a link that says, "To stop receiving this newsletter..."; change that to "To stop or resume receiving..." and leave it at that. EEng 14:23, 28 October 2017 (UTC)
  • Support as per previous comments, especially the desirability of avoiding long cluttered talk pages. Peter coxhead (talk) 19:47, 28 October 2017 (UTC)
  • Support, provided that the suspention stops immediately once editing resumes - that is, for the user to start getting them again, all (s)he needs to do is a single edit with no need to resubscribe; additionally, a bot should probably warn the user at the last delivery of a subscription (in a separate section) about such suspention. I think the longer of 4 deliveries and 4 months is lone enough. עוד מישהו Od Mishehu 11:22, 29 October 2017 (UTC)
  • Support with a time threshold and an optout. jcc (tea and biscuits) 11:33, 29 October 2017 (UTC)
  • Support I suppose, but I would much prefer 12 months. Jenks24 (talk) 12:09, 29 October 2017 (UTC)
  • Oppose - though, clearly, a good faith effort, this remedy has collateral consequences that suggest its achievable gains, both can and should be managed in some other, more efficient way. In general, I support centralized solutions over local solutions where the means are; invariably: more costly and far more inefficient. My recurring notifications arrive via an alternate account which this proposal, to my chagrin, would cease; for the editing inactivity of that account. Not withstanding these, I can not support the local mechanics of this proposal, nor the stifling effects their inadequacy too often spawn.--John Cline (talk) 06:41, 30 October 2017 (UTC)
Forsooth, my liege, thou canst opt-out, thus to continue the succor of thy monthly Signpost! EEng 07:16, 30 October 2017 (UTC)
One potential solution would be a bot which can parse templates from Category:Alternative Wikipedia account templates, and keep delivering to a publicly-declared alternate account if the main account is still active. עוד מישהו Od Mishehu 07:57, 30 October 2017 (UTC)

Threaded discussion (Auto skip inactive editors from newsletters)

  • This looks very much like a solution in search of a problem. If someone hasn't edited for 4 months then why would anyone feel the need to read the user talk page anyway? And if nobody is reading the page then what does it matter how long it is? It's quite possible that a user doesn't edit but is still interested in reading newsletters, and, if not, it does no harm to carry on sending them. 86.17.222.157 (talk) 20:19, 27 October 2017 (UTC)
Many of us will have multiple inactive Wikipedians on our watchlists. The absent Wikipedian can be assumed absent, but not others. As for the problem, eventually these newsletters turn such talkpages into ones that are slow to load, hence the earlier, more intrusive proposal to autoarchive them. ϢereSpielChequers 21:30, 27 October 2017 (UTC)
I've got a number of "missing Wikipedians" on my watchlist hoping to be able to welcome them back, and these notices every few days just gum up my watchlist. I find the argument that maybe someone is silently reading newsletters for a year, without making a single edit, unpersuasive to say the least. Anyway, we can have an opt-out by which people can explicitly ask to continue receiving. EEng 21:56, 27 October 2017 (UTC)
Does anyone force you to have these pages on your watchlist? Surely you can just remove them. This is supposed to be an encyclopedia, not a social networking site, so welcoming people back should be very low on anyone's list of priorities. 86.17.222.157 (talk) 18:40, 28 October 2017 (UTC)
I disagree; there's a serious shortage of editors, and welcoming editors back is very worthwhile. Peter coxhead (talk) 19:49, 28 October 2017 (UTC)
I realise that I'm in a minority here, so I'll make this my last comment, but I don't believe that there is any evidence that any of this touchy-feely stuff actually leads to a better encyclopedia, which is supposed to be what Wikipedia is about. 86.17.222.157 (talk) 21:24, 28 October 2017 (UTC)
  • @WereSpielChequers: can you explain how easy to change the newsletter bots to only post to talkpages of editors who have been active in the last 4 months? Also note - not all newsletters are sent "by bots", regarding MassMessage above - are you proposing that the extension somehow be able to detect "activity"? Will cross-project activity account? What is your measure of this (e.g. will a logged action suffice?) — xaosflux Talk 00:40, 30 October 2017 (UTC)
    For example, lets look at a very popular newsletter, Wikipedia:Wikipedia Signpost - this is not sent "by bots", it is sent by editors. — xaosflux Talk 00:45, 30 October 2017 (UTC)
    Hi Xaosflux. I'm happy for cross project activity to count, and yes one logged action would be sufficient to show you are still around - afterall we do have cross project notifications now so if you are only active on commons you would know if you were still receiving a newsletter on EN. As to the mechanics of this there are several ways it could be done. It could be on the fly with a new massmessage bot that people could use putting in their subscription list and the latest newsletter, or a standalone bot that moved people from subscription lists to an inactive subpage and back again when they reappear. At present I'm just seeking consensus for it to happen, precise mechanics would be up to the bot writer. ϢereSpielChequers 07:10, 30 October 2017 (UTC)

Can inactive editor be determined by having logged in, rather than edited? Because if you are never logging in you probably won't be looking at the notices anyway. ClubOranjeT 19:39, 30 October 2017 (UTC)

  • I'd be somewhat in support of a software change to the MassMessage extension to "skip inactive" users, possibly as an option that the sender could use. This would require developer time. — xaosflux Talk 04:26, 31 October 2017 (UTC)

Should talk page newsletter notices be abolished completely?

  • Has there ever been a community discussion about whether "newsletter" notification should ever be used? I find it lazy and obviously its become resource intensive on inactive editor pages. Why can't we expect editors to just put newsletters in their watchlist and keep informed via that existing mechanism rather than use a bot-driven, spammy mechanism like talk page posts? Every time a "newsletter" is updated, it becomes my watchlist that is spammed as many people I've interacted with on their talk page gets these notifications. -- Netoholic @ 07:33, 30 October 2017 (UTC)
    Indeed; I have never subscribed to The Signpost, but sometimes read it - on the user talk pages that I am watching for other purposes. My own User talk page stays pretty clear of newsletters - all the ones that I'm interested in are subscribed to by other people. --Redrose64 🌹 (talk) 09:48, 30 October 2017 (UTC)
    Is that what happens to my New York Times some mornings? EEng 19:36, 30 October 2017 (UTC)
    Especially with the notification system (which is newer than these newsletters were originally created), these subscriptions are probably unneeded. With the signpost we have a transcludable template, a system which can be used for all newsletters; a bot could easily PURGE all pages transcluding a particular newsletter's template, and the notification system will inform any interested user about the new edition without spamming any page visible to anyone else. However, if we make such a change, we need to actively inform all users on any distribution list about this change. עוד מישהו Od Mishehu 13:50, 30 October 2017 (UTC)
  • Hmmmm... There's a good point here. Maybe people who want to subscribe should just add a template to their page which transcludes the current version of the newsletter, plus whenever there's a new "edition" they would get a ping. (The template would add the user to a category, and everyone in that category gets the ping.) That's a very clean approach. EEng 19:39, 30 October 2017 (UTC)
  • Brilliant. That would solve all problems. And it could include a link to an archive in one location that lists every issue so the hypothetical contributor who has been offline for ten months can spend a couple of days reading the past issues to see what they've missed. Johnuniq (talk) 22:10, 30 October 2017 (UTC)
Johnuniq, you know the Ways of the Pump better than I. Can you find the best way to make sure other participants in this RfC know about this? Perhaps WereSpielChequers will suspend this RfC in favor of a new one on this template idea -- we can always revive this discussion if the template idea fails. When you think about it, the template idea is way easier to implement, and with fewer design decisions to make (e.g. what counts as activity?). EEng 23:07, 30 October 2017 (UTC)
I see no need to abolish these entirely, but they might become redundant to Extension:Newsletter if installed. Sam Walton (talk) 23:15, 30 October 2017 (UTC)
Um, OK, well it seems unnecessarily complicate, but anyway why isn't it being used already? EEng 23:17, 30 October 2017 (UTC)
That extension looks insanely bureaucratic for the purposes of most Wikipedia newsletters, and I'd vehemently oppose any suggestion to roll it out across Wikipedia except possibly for a couple of high-traffic high-visibility newsletters like Signpost. As I read it there will be a separate set of admin-granted userrights for every single newsletter, and anyone wanting to contribute to a newsletter will need to persuade an admin to grant them the "publisher" userright for that specific newsletter—no sane person is going to want to jump through those hoops. ‑ Iridescent 23:29, 30 October 2017 (UTC)
mw:Extension:Newsletter#User Rights says that by default only admins can do things, but the extension would be customized for whatever was wanted at enwiki. For example, certain groups (say admins) could create or delete a newsletter, but other groups (say extendedconfirmed = 30 days/500 edits or autoconfirmed = 4 days/10 edits) could manage any newsletter. Johnuniq (talk) 03:19, 31 October 2017 (UTC)
  • As a purely practical issue, assuming I'm understanding this proposal correctly as "if you want to subscribe to a newsletter, transclude it to your talkpage or a dedicated newsletter page in your userspace and you'll get a notification when it's updated", I can see a potential issue with Wikipedia's numerous phantom newsletters. Because of the tendency for people to get bored, a lot of newsletters get updated very infrequently—to take an extreme example, had this setup been in place previously all of these people would have had the December 2013 edition of the WikiProject London Transport newsletter sitting on their talk page for the last four years as nobody's bothered to put out a fresh issue since then. ‑ Iridescent 23:30, 30 October 2017 (UTC)
Well, then, after a while someone noticing that the LT newsletter is stale can just go move the "current" (way old) issue to the newsletter archives, making the current issue empty i.e. there's no current issue. EEng 00:28, 31 October 2017 (UTC)
Changing a transcluded template does not trigger echo notification. And why would you want to keep an old newletter on your page indefinitely - not knowing when it is going to be updated again? — xaosflux Talk 01:40, 31 October 2017 (UTC)
Re how the notification works, please read my proposal carefully, in the post starting "Hmmmmm." Re "indefintely", as also already explained, defunct newsletters can be blanked. EEng 02:37, 31 October 2017 (UTC)
@EEng: have you got a working demo of this? I just tried a quick and dirty and neither changing the transcluded page, or changing the category it include only'd had any echo notification to another account transcluding such page. (including after a force purge) — xaosflux Talk 04:01, 31 October 2017 (UTC)
I'm not making myself clear. A bot would walk the category and ping every user in it. I don't know if it's possible for a custom message to accompany a ping e.g. A new issue of the X newsletter is now available on your Talk page. Honestly, though, now that I think about it, why not then just ping people to the page where the newsletter itself is, and just skip the transclusion part? EEng 04:08, 31 October 2017 (UTC)
Ping them where (some random page?, the actual newletter template?) This also requires every single project with a newletter to get a bot to manage their newletters and MassMessage - is that what you are proposing? — xaosflux Talk 04:25, 31 October 2017 (UTC)
A bot delivers the newsletters now. In no way does this require "every single project with a newletter to get a bot to manage their newletters and MassMessage" – what are you talking about? A project that wants to use this very simple technique can do so, and everyone else can keep doing what they're doing if that's what they want. EEng 04:37, 31 October 2017 (UTC)
Hi @EEng: we must have a big disconnect in this scope - which "newsletters" are you referring to? I'm seeing this on VPR and thinking this is a proposal to change enwiki newletter processes in general - if any single project wants to change how their newletter wants to be managed, it doesn't need to be here, they can just do it. For reference, several newsletters on my own talk page were not "delivered by bots", whereas other things that are not "newletters" (such as SuggestBot suggestions) are actually delivered by bots and maybe unneeded clutter for departed editors. — xaosflux Talk 05:02, 31 October 2017 (UTC)
Um, an unsubst'ed template is exactly what I'm proposing. EEng 04:08, 31 October 2017 (UTC)
Where? --SmokeyJoe (talk) 04:57, 31 October 2017 (UTC)
A dozen posts up, starting with "Hmmmmm..." EEng 05:21, 31 October 2017 (UTC)
Unsubst'd templates/transclusions have the disadvantage of never notifying people that the template was changed. A new message on your talk page lights up your notifications; a change to a page that you're transcluding doesn't even put your talk page in your watchlist.
Iridescent, there's currently a live test of Extension:Newsletter at mw:Newsletter:Tech Showcase, and it really doesn't seem to be bureaucratic. User:Qgil-WMF could give you more information about the practical details, but as far as I can tell, he just tells it to send a page to everyone. It probably doesn't take him even 30 seconds to send the "newsletter".
@MZMcBride: People are talking about changes to MassMessage, so you might want to look this discussion over. Whatamidoing (WMF) (talk) 17:02, 8 November 2017 (UTC)
Whatamidoing (WMF) It's not the sending that's bureaucratic—unless I'm misreading the documentation completely, each newsletter will need to have its own bureaucratic structure with specific userrights for who can edit it and who can send it out. Thus, if I were to try to revive (for instance) the aforementioned moribund London Transport newsletter, I'd need to find out who was currently its admin (who may not even be active any more, given that the newsletter hasn't been published since 2013), persuade them to grant me the editor right for that newsletter, persuade them to grant the editor right for anyone else I wanted to approach to contribute to it, and then persuade them to send it out or grant me the right to send it out. The sort of people who have time and inclination to jump through that many hoops aren't the sort of people who are likely to have anything very interesting to say. ‑ Iridescent 18:41, 8 November 2017 (UTC)
Having glanced at the documentation, I think that any admin (i.e., anyone on the list at Special:ListAdmins) can grant you the right to send out any newsletter. ("Editing" a newsletter is just a matter of editing a normal page.) Whatamidoing (WMF) (talk) 04:47, 9 November 2017 (UTC)
Iridescent, Whatamidoing (WMF), Johnuniq Hi, mw:Extension:Newsletter was designed with minimalism in mind. The permission to create newsletters is currently set to admins in MediaWiki.org because it is a new extension and we wanted to see it being used by real publishers without risking types of abuse that we hadn't think of. It can be configured to any user group. I personally think that newsletter account creation can be permissive, because the potential damage is directly proportional to the number of subscribers, and a publisher will only get subscribers if the newsletter is interesting, not some kind of spam. Once the newsletter has been created and a publisher has been assigned to it, the publishers of that newsletter can add/remove other publishers themselves. I don't think you can have it simpler than that. For what is worth, the Newsletter extension is not being deployed to other Wikimedia wikis as long as interwiki support is not resolved (phab:T110645). Qgil-WMF (talk) 10:54, 9 November 2017 (UTC)

Hi. Thanks for the ping. It's no real secret that EdwardsBot was a spam bot. And its replacement MassMessage created infrastructure and additional legitimacy to the concept of spamming user talk pages. The architecture never made much sense, obviously. I always found it akin to, as EEng suggests, delivering the paper to household driveways and businesses when you could instead have a Web site. But people really liked getting the talk page messages, just as some people still like getting the newspaper delivered to their home or office.

I think that's kind of a key point: hundreds of people subscribed to The Signpost and liked getting a new talk page message each week, so we supported that. User talk page messages also came with "free" e-mail notifications for users who have talk page messages send an e-mail. And, yes, of course, you could just e-mail people directly instead, but people liked getting the talk page messages for The Signpost, for wiki meetup invitations, for newsletters, etc.

The wiki talk page delivery system is also used with non-user talk pages. Some users watchlist centralized pages that receive notifications, such as technical news posted to Wikipedia:Village pump (technical).

I'm not clear to me what specifically is being proposed for the MassMessage extension or the Newsletter extension, but the better venue is probably Phabricator. :-) --MZMcBride (talk) 05:28, 9 November 2017 (UTC) (cc: Legoktm, wctaiwan)

Newspaper deliverers to remove old newspapers still on the driveway

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Hall of Fame

WP:DENY
The following discussion has been closed. Please do not modify it.

I thought it might be a nice gesture to create a wikipedia page for famous/notable vandals from the early days of wikipedia (the first ten years, before the whole colbert thing). There were a number of vandals who were innovative and memorable, employing things such as practical jokes or using their own identifiable style. As a former vandal myself I think it would be interesting as the readers would learn more about the "wild west" early days of wikipedia as well as some internet culture from that era. thanks.

There is zero want or need to highlight those editors that have be rejected by the community.--Moxy (talk) 15:24, 9 December 2017 (UTC)
No, vandals do not deserve any thing that resembles "fame". —Farix (t | c) 15:30, 9 December 2017 (UTC)
(ec) My first reaction was much like those above, but this is a neutral encyclopaedia, we do have articles about notable criminals and sociopaths. Do you have anyone in mind who meets the general notability criteria?
Also, please sign your posts on talk pages.· · · Peter (Southwood) (talk): 15:40, 9 December 2017 (UTC)

Category and categories: equivalence needed

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)

Open-door policy of allowing anyone to edit... and have their edits almost instantly removed.

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)

Proposal for a better article assessment process

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. GMGtalk 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. GMGtalk 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. GMGtalk 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. Cullen328 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. GMGtalk 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)
  • 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)

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)

Temporary Watchlist for AFDs

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)

IMDb character

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)

Separate hidden categories into "tracking" and "maintenance" categories

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)

Medical template may be needed

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)

Skool vacations

Not a whisper of support for the well-intentioned proposal, and opposition from 9 editors, including some of our most esteemed (wear that if you like), including both anecdotal and hard evidence contradicting the premise. Even the OP's support was tentative. S/he asked, "Would it be against our credo...?", and the answer appears to be "Yes." Seems snow-worthy to my eye, but anybody including the OP is welcome to revert me. ―Mandruss ☎ 03:27, 13 December 2017 (UTC)

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

We are coming up to that time of year again when many school kids have a short winter break. During such times WP gets inundated with higher levels of vandalism from bored children, just at the very times we wish to sit back and relax. Would it be against our credo to suspend the creation of new accounts and anonymous edits for these periods? WP is so big now, that current active editors are having to spending more time policing than adding content – yet we 'need' new editors from the younger generation to join us. Thus, I am at sixes and sevens over this. The only real silver lining I can see to this suggestion is that they turn their attentions to vandalizing Facebook and Twitter instead. Aspro (talk) 15:12, 12 December 2017 (UTC)

No, we don't prevent good-faith new editors from joining us because we're too lazy to deal with vandals. Just no. --Jayron32 16:07, 12 December 2017 (UTC)
It is nothing to do with wanting to be lazy, rather than the distraction and shear volume of these one-or-two-or-three edit disruptions, plus the extra time required read through and then revert them – sometimes, several times in quick succession on the same article when a Wikiholiday would help avoid this. Aspro (talk) 18:35, 12 December 2017 (UTC)
The distraction and sheer volume is always there. We'll deal. We always have been, and we're going to keep doing so. --Jayron32 18:39, 12 December 2017 (UTC)
[citation needed]. I've always found that the amount of vandalism is drastically reduced when schools are not in session. The increase in vandalism in September and January, and correlation with school hours, is actually quite noticeable. I'd suggest that there's probably more recognition and peer pressure behind it. Plus maybe the vandal kids are just more easily bored in school? They've probably got more interesting ways to get in trouble during the holidays, and probably don't want to spend too much time looking at encyclopaedias. -- zzuuzz (talk) 19:08, 12 December 2017 (UTC)
Anecdotally, I have to agree that there is more vandalism in September. Also, what about the college students who are bogged down in work during the semester, and break is the time for them to venture onto Wikipedia? If we locked them out, we could lose a lot of valuable, energetic, constructive editors. —C.Fred (talk) 19:14, 12 December 2017 (UTC)
You don't need to be anecdotal—see the activity level chart (the first red-shaded graph) and you can see for yourself that activity levels significantly and consistently drop during school vacations in the US, and rise again when the schools are back in session. ‑ Iridescent 23:00, 12 December 2017 (UTC)
  • Absolutely not. Even if your during such times WP gets inundated with higher levels of vandalism from bored children claim were true—which it isn't—we're not going to change our core operating model just it happens to be the time when you personally wish to sit back and relax. ‑ Iridescent 22:48, 12 December 2017 (UTC)
  • No as per Zzuuzz - We shouldn't stop people from registering and potentially becoming well respected and well loved editors all because of a few bored knobheads, If the kids vandalise they get blocked and FWIW kids will vandalise whether they're in school or out of school. –Davey2010Talk 23:08, 12 December 2017 (UTC)
  • To be more accurate, kids will vandalise significantly more when they're in school (where Wikipedia will likely be the only user-editable site the schools' Webmarshall software will allow them to access), than when they're not in school and have a free run of the internet. Normal children don't generally tend to spend their vacation time reading a text-based online encyclopedia. ‑ Iridescent 23:13, 12 December 2017 (UTC)
  • I absolutely agree (and somewhat off topic but during my school years various software was introduced that could block websites (even game sites!) and by 2006 virtually every website was blocked and that was in 2006 so I assume since then software in schools has probably got even worse and as such Wikipedia is probably the only website kids have access too! - Thinking about it I assume most kids when at home would be interested in Netflix and Instagram so yeah I have to agree WP probably becomes more of a target in schools then it does when they're at home). –Davey2010Talk 23:31, 12 December 2017 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Require every animated image in the article to include a method to start/stop animation

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://wiki.riteme.site/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)

Wikipedia and the Dec. 12th “Break The Internet” day of action for net neutrality

Considering it is now December 15 in parts of the world, I think this discussion is effectively moot. (non-admin closure) Narutolovehinata5 tccsdnew 00:33, 15 December 2017 (UTC)

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Background

On December 14th the US Federal Communications Commission (FCC) will vote on a proposal to dismantle net neutrality protections in the United States and reclassify broadband Internet access providers as ‘information services’ under the Communications Act of 1996. This move will allow broadband providers to block sites or services on the basis of their content, charge websites, apps and services fees just to be able to reach an ISP's subscribers, slow down or speeding up services, and charge sites for privileged “fast lane” access. The impacts on donation-supported access to knowledge projects like Wikipedia could be significant.

The agency’s scheduled December 14th vote would remove the legal foundation for enforcing net neutrality at the FCC, and will strip away the specific provisions banning blocking, throttling, and paid prioritization. As a result, Internet users and businesses across the country will be largely unprotected from a wide array of traffic management practices the country’s largest ISPs could use to enact tolls on the open internet.

The agency’s final order was made available on November 22, 2017 and is available here: https://transition.fcc.gov/Daily_Releases/Daily_Business/2017/db1122/DOC-347927A1.pdf

The Wikimedia Foundation policy team has released a statement opposing the repeal, reiterating many of the arguments they made to the FCC in a filing earlier this year. They recognized that a loss of net neutrality would create barriers to accessing Wikipedia and other access to knowledge projects. They recognize that a loss of net neutrality will create barriers to the creation of primary sources, as well as the ability for contributors to edit and create entries. Moreover, Wikipedia would have to dedicate a higher percentage of their donations to bandwidth costs to ensure their site is “prioritized” by ISPs or even loads at all.

When the U.S. bill “The Stop Online Piracy Act” or “SOPA” threatened Wikipedia’s ability to exist by encouraging ISPs to block websites containing even small amounts of copyrighted material, the Wikipedia community, in this very forum, decided to “black out” its site for a day, alerting visitors to the legislative threat and inviting them to contact elected officials. See Wikipedia:SOPA_initiative.

As a result, nearly unprecedented numbers of people did so, and the legislation stalled. Proposed changes to net neutrality rules would allow similarly bad behavior by ISPs. and—like SOPA—these rules could be averted by a large number of calls to Congress, according to experts at leading organizations such as Public Knowledge and the Electronic Frontier Foundation

Now net neutrality advocates are organizing are calling on Internet users, websites, apps, and small businesses to participate in “Break the Internet,” an online protest starting 48 hours before the FCC’s scheduled vote, where participants will use widgets and banners to creatively “break” their online presence in some way, driving phone calls to Congress.

Proposal and Discussion

  1. Should the Wikipedia community join the December 12th ‘Break the Internet’ day of action?
  2. Should the Wikipedia community do *something* to keep the rules in place short of participating officially in the action (e.g. a message inviting visitors to call elected officials)?
  3. What would be a creative way to “break” Wikipedia for a day and garner public attention?

— Preceding unsigned comment added by Jdtabish (talk • contribs) 19:42, 7 December 2017 (UTC) — Jdtabish (talk • contribs) has made few or no other edits outside this topic.

  • Strong oppose. I was opposed to SOPA but had reservations about even that action; I was afraid it would lead to this sort of slippery slope. But SOPA was arguably an existential threat. This is not. Wikipedia should not be taking political sides. --Trovatore (talk) 19:38, 7 December 2017 (UTC)
  • Power level 6000000000 Support. I think it's important to Wikipedia that anyone be able to access it's content regardless of who your ISP is. While Wikipedia might not be directly affected by the end of net neutrality it could harm people's ability to access it. Those people unable to afford the 'nice lane' might have trouble reaching our site in the future. The whole purpose of Wikipedia is to share knowledge and Wikipedia's ability to do this will likely be affected by the bill. I concede that it's not the Wiki foundation's problem if not everyone can afford a nice internet connection, but if we are in a position to take preventative action against legislation that allows ISPs to slow down people's connection to Wikipedia's service, we should. SpartaN (talk) 20:07, 7 December 2017 (UTC)
  • Strong Support in general, but I doubt wikipedians will be up for it. They are so apolitical, they'll rather sell their soul to the devil than take any form of stand. I'd just start throttling all traffic from Verizon, Comcast and AT&T and redirect all traffic from Washington DC to the Net Neutrality article for a week or so. Should be a nice and quiet. —TheDJ (talk • contribs) 20:09, 7 December 2017 (UTC)
  • Oppose Are we forgetting Wikipedia Zero? We'd be protesting something we've been lobbying for. Hawkeye7 (discuss) 20:11, 7 December 2017 (UTC)
  • Support initially I thought this was different than SOPA, and in some ways it is. However, Wikipedia Zero, while the exception that would be nice, could also be turned on its head. For-profit encyclopedias (or Wikipedia mirrors loaded with ads) could cut deals with ISPs and have preferential treatment over us. Or Verizon et al could very well try to extort money from the WMF so that Wikimedia projects get throttled/blocked in favour of other competitors. This possibility alone warrants opposing any weakening to net neutrality, and I believe this is infinitely more likely than Wikipedia Zero becoming a thing in the USA. As such, repealing net neutrality is a threat to Wikipedia. While out articles need to be impartial about net neutrality and the laws governing it, we as a community need not be apolitical about this. (I'm Canadian, so I'm unaffected by this either way.) Headbomb {t · c · p · b} 20:38, 7 December 2017 (UTC)
Comment If you're curious I found an article on how it might affect Canadians here: https://www.nationalobserver.com/2017/12/04/analysis/yes-us-net-neutrality-debacle-will-impact-people-canada-no-we-cant-sit-sidelines
    • That's speculation. As I understand it, the repeal proposal would return the state of affairs to what it was in 2014. Why didn't this parade of horribles happen then? I don't see any SOPA-level threat to Wikipedia here. --Trovatore (talk) 20:52, 7 December 2017 (UTC)
      • This wouldn't take us back to 2014. 2014 had net neutrality protections from the 2010 net neutrality rules. Before 2010, net neutrality was protected by the FCC's 2005 policy statement, by enforcement actions (Madison River 2004, Comcast/Bittorent 2008), merger conditions (Comcast/NBC, AT&T/SBC) and spectrum auction rules. The U.S. internet has always been under de facto net neutrality. -- rsingel
      • It'll affect us, but very indirectly. Kinda like how US elections affects us indirectly. Headbomb {t · c · p · b} 20:57, 7 December 2017 (UTC)
  • Strongly oppose How about Wikipedia:Do not disrupt Wikipedia to illustrate a point? We do not need to be getting more political. Natureium (talk) 20:48, 7 December 2017 (UTC)
  • Support While SOPA was directly more about free speech, and its impact on Wikipedia more about what-ifs rather than a direct immediate threat (but still a threat nevertheless), this is a more direct threat in that we know the Internet providers are chomping at the bit to make internet fast lanes to favor content they prefer, which is going to be large commercial media corporations. There's a lot fewer steps should this be voted in favor of that would harm WP directly (since it is stored in the US) compared to SOPA. Yes, this is principally a move from the Republican side, but I disagree protesting here is a political element - it is about freedom of speech which is one of the reasons WP was made, to be empowered by that. --Masem (t) 20:53, 7 December 2017 (UTC)
  • Oppose a local US issue that is not too serious to Wikipedia at all. Graeme Bartlett (talk) 20:56, 7 December 2017 (UTC)
  • Strongly oppose disrupting Wikipedia to prove a dubious political point affecting only a single country; if you want to run a political campaign, get a blog. SOPA at least had a potential impact on Wikipedia; this does not. (Indeed one of the WMF's showcase projects is explicitly against net neutrality.) FWIW, I've lived for 30 years now in a country without net neutrality and have yet to notice the sky falling in. ‑ Iridescent 20:59, 7 December 2017 (UTC)
    • The US also didn't have "net neutrality" until 2014, so it's not like it's ever been a big problem in practicality. Natureium (talk) 21:03, 7 December 2017 (UTC)
      • This is false. Repealing the existing rules wouldn't take us back to 2014. 2014 had net neutrality protections from the 2010 net neutrality rules. Before 2010, net neutrality was protected by the FCC's 2005 policy statement, by enforcement actions (Madison River 2004, Comcast/Bittorent 2008), merger conditions (Comcast/NBC, AT&T/SBC) and spectrum auction rules. The U.S. internet has always been under de facto net neutrality. -- rsingel
      • You mean they didn't have a law to protect net neutrality, a concept originally so coined in 2003, but that existed in practice long before that as unwritten rules that made the Internet so successful. The law was a response to parties like Comcast trying to break that model, at a time where the Internet became so fundamental in going about your daily life. —TheDJ (talk • contribs) 21:35, 7 December 2017 (UTC)
  • While I personally support net neutrality I'm not convinced that this is as someone above said an existential threat to us, or a global as opposed to merely a US issue. Then of course there is as Hawkeye points out the whole WikipediaZero thing..... Would our involvement in this add to the strength of the net neutrality campaign, or weaken it because our WikipediaZero campaign shows we don't back net neutrality where it suits us not to. ϢereSpielChequers 22:22, 7 December 2017 (UTC)
  • Strongly oppose using Wikipedia for political activism. Rentier (talk) 21:08, 7 December 2017 (UTC)
  • While I personally support net neutrality I'm not convinced that this is as someone above said an existential threat to us, or a global as opposed to merely a US issue. Then of course there is as Hawkeye points out the whole WikipediaZero thing..... Would our involvement in this add to the strength of the net neutrality campaign, or weaken it because our WikipediaZero campaign shows we don't back net neutrality where it suits us not to. ϢereSpielChequers 22:22, 7 December 2017 (UTC)
  • Strongly Support The battle to preserve net neutrality in the US is the defining fight for the internet. Wikipedia has to care about how the larger internet functions in its largest and most important geography (by number of readers + editors).
  • Strongly Support When Wikipedia did what it did during the SOPA protests, it did not compromise it's neutrality. So why then, would this? This affects Wikipedia as much as anything else. A blackout is absolutely necessary. Retroity (talk) 05:52, 9 December 2017 (UTC)
Some counterpoints to those opposing:

(1) If net neutrality goes, it is definitely an existential threat to Wikipedia; editors will not necessarily be able to cite on Wikipedia in the way they used to, and it's not even clear if Wikipedia itself will be affected by differential access speeds. If this isn't an existential threat, I don't know what is.

(2) Wikipedia 0 is not a conflict with net neutrality. There are many, many differences between Wikipedia 0 and what the FCC is now proposing. We don't pay; we are a valuable, essential, public service. Protecting and promoting us (you could say) is a fundamental duty of the internet. For those in the US, it's like sending taxpayer money to preserve Yellowstone National Park. Wikipedia is the public park of the internet, and providing access to it through whatever means and incentives is a public service, not a net neutrality conflict.

(3) Using Wikipedia as a political weapon: I totally agree. Wikipedia isn't a soup kitchen for causes. But it has been a powerful force in the past to protect itself (when protesting SOPA PIPA) and it has to do the same now. Or else, we're just giving in to something we could actively block, as we did before, and hastening our own destruction.

(4) It's not just a US issue. If net neutrality falls in the US, that sends a powerful signal to other big countries around the world that it's fine to kill net neutrality there. I live in India. All those telcos that have bought the current proposals to end net neutrality in the US also operate here. This could happen everywhere if we allow it to happen in the US.

(5) Wikipedia lives in the internet, and is enabled by it. The idea that the US internet is this other thing that has nothing do with us is nonsense; the worse the general state of the internet is in the US, the more it directly impacts how and whether someone can access us, read Wikipedia, and much worse, edit Wikipedia, because the ability to edit Wikipedia is directly connected to the ability to freely consult the wider internet.

For others out there, still on the fence, do please consider joining this protest. If you would like some more information on what's at stake, the NYT has a deep story on the fight to preserve net neutrality; worth a read. --aprabhala 04:53, 8 December 2017 (UTC)
  • Support It would be awesome to not be sullied by dirty politics, to remain morally aloof and above such petty things, but this issue directly impacts Wikipedia itself and we could be seriously compromised by remaining silent. Sometimes doing something is less painful than doing nothing. If there was an issue to act on, this is it. -- GreenC 04:40, 8 December 2017 (UTC)
  • Oppose - Regardless of the issue, an overall Wikipedia stance would have to represent the views of a majority of Wikipedia editors. Those views are not going to be determined by a self-selected handful of editors at the Village Pump. ―Mandruss ☎ 04:49, 8 December 2017 (UTC)
  • Oppose Not that I'm not concerned about the repeal, but I think the Wikipedia Zero criticism would eat us alive. --Rschen7754 06:48, 8 December 2017 (UTC)
  • Strongly Oppose any Wikipedia activism, and per the above. This shouldn't affect us. As someone above stated, start a blog... GenQuest "Talk to Me" 07:46, 8 December 2017 (UTC)
  • Oppose. Arguably, Wikimedia breaks net neutrality itself through Wikipedia Zero. This is not the type of existential threat that Wikipedia should protest. We are not a political organization. ~ Rob13Talk 08:20, 8 December 2017 (UTC)
  • Strongly Support. Net neutrality is absolutely fundamental to everybody's use of the internet. The current US legislative proposals are dangerous, and much more serious than the earlier SOPA affair. Remember that doing nothing is also a political act, because Wikipedia then becomes complicit in this sordid business. --NSH001 (talk) 08:27, 8 December 2017 (UTC)
  • Support. Wikipedia Zero, because it undermines net neutrality, is, in sum, at the end of the day, when you think through the wider effect, stupid and bad. Always has been. Wikimedians are, on the whole, far too myopic and self-serving to grasp this very simple point. --Anthonyhcole (talk · contribs · email) 08:36, 8 December 2017 (UTC)
  • Strong Support I couldn't care any less about what the WMF is doing with Wikipedia Zero in terms of me supporting or opposing something. Anything that undermines net neutrality for anyone anywhere should be antithetical to any website that calls itself "The Free Encyclopedia", including the ridiculous zero-rating. Additionally, the comments saying that "We shouldn't be political" or that this won't affect but one country miss the mark entirely and makes me wonder if they even know what they are commenting on. Nihlus 08:47, 8 December 2017 (UTC)
  • Comment What should we do if this gets enough support? No attention has been paid to whether Wikipedia join "Break the Internet", or merely put up a banner about it. Presumably, if this gets support, we're at least going to have a banner about net neutrality at the top of pages. Break the Internet is only 4 days away and the vote is 8 days, meaning we should work on such things beforehand. SpartaN (talk) 10:27, 8 December 2017 (UTC)
Comment-Whatever is done let it only be shown to IPs originating in the US. — comment added by Force Radical (talk • contribs) 11:47, 8 December 2017 (UTC)
@TheFarix: There are now a bunch of SPA votes and an IP vote signed "A Student". SPI filed. – Train2104 (t • c) 19:34, 8 December 2017 (UTC)
  • Support - Internet neutrality is important for everyone. WP should do what it can to support it. Renata (talk) 13:32, 8 December 2017 (UTC)
  • Oppose It's an important issue, but we shouldn't use Wikipedia as a political soapbox. Wikipedia shouldn't take sides on any political issues, really, regardless of importance. SkyWarrior 13:49, 8 December 2017 (UTC)
  • Oppose Per SkyWarrior.--Kevin Dewitt (talk) 14:37, 8 December 2017 (UTC)
  • Strong oppose picking a side in a political dispute and disrupting Wikipedia in the name of supporting it. – Train2104 (t • c) 15:37, 8 December 2017 (UTC)
  • Strong support—Providing universal access to free knowledge is the core purpose of Wikipedia.--Carwil (talk) 16:10, 8 December 2017 (UTC)
  • Strong oppose There is nothing "neutral" about the federal government regulating anything - the name is biased and misleading. WP should not be involved in political issues like this. MB 16:19, 8 December 2017 (UTC)
  • Oppose Not every wikipedian feels the same way about the issue. Plus, I joined 10 years ago to build a free encyclopedia, not be part of a political movement. Dennis Brown - 2¢ 17:37, 8 December 2017 (UTC)
  • Support. I propose that we implement a sneak peek of what charge-per-use internet would look like, and set up a monetization structure for that day, where we require all visitors (and editors) to pay ten cents per page visited (and edited) for the day. Maybe fifty cents per page for high-traffic pages or very large pages. Although we can't know the monetary assessment in advance, because providers will be able to set those arbitrarily, this will be a fair approximation of the result. bd2412 T 17:51, 8 December 2017 (UTC)
  • Very strong support I proposed at the meta wikimedia forum logged out (by mistake, look for 68.233.214.74 in the history) that we implement the script found [battleforthenet.com here], and as I am directly affected by net neutrality being broken down, please do something like that. The script loads an alert once per day per user and is easy to dismiss. Bardic Wizard (talk) 18:00, 8 December 2017 (UTC)
  • Strong Support I believe that Wikipedia, as a free source of information for anyone in the world, much less the US alone, should stick with the ideal of free access to information. Loss of net neutrality will negatively affect that ideal, and Wikipedia should do everything it can to maintain net neutrality - A Student — Preceding unsigned comment added by 128.237.175.221 (talk) 19:15, 8 December 2017 (UTC)
  • Oppose per WP:POINT, WP:SOAP + Dennis Brown's argument: I joined 10 years ago to build a free encyclopedia, not be part of a political movement. Also, the contradiction with WP:ZERO would make us look ridiculous. — JFG talk 21:37, 8 December 2017 (UTC)
  • support not that there'll be any consensus so I'll just put down my view for the record. jcc (tea and biscuits) 21:39, 8 December 2017 (UTC)
  • Hesitant. I definitely support Net Neutrality, however something like this needs particularly high participation and a particularly high level of support. I am willing to join the support *if* there is a solid viable plan and strong participation and strong support (70% is extremely borderline, preferably at least 75%). This would have to be some sort of banner, rather than "break the Wikipedia". It should almost certainly be targeted to US viewers. It would almost certainly need WMF moral-and-technical support. Given the short time frame and the non-trivial rate of opposes, I think it unlikely that this proposal will succeed. Alsee (talk) 22:45, 8 December 2017 (UTC)
  • Oppose People writing an encyclopedia have no business using the platform to make political statements. Chris Troutman (talk) 01:49, 9 December 2017 (UTC)
  • Oppose. Initially I wanted to support this, but after seeing the break the internet advocacy site, I changed my mind. Under this proposal, Wikipedia would join in the ranks of GitHub, Reddit, PornHub, and other illustrious such websites of minor importance. Meanwhile, Google, Amazon, NetFlix, and others that actually stand to lose the most appear not to be participating in this blackout. If it were that essential to their bottom line, they'd be leading the charge like they were on SOPA, etc, not some random advocacy site that has managed to ensnare a few token extreme libertarian sites. Sławomir Biały (talk) 02:09, 9 December 2017 (UTC)
    Google, Amazon, Netflix do not need net neutrality, and are able to cut preferential deals with ISPs. I don't see why we should support that over the long tail of small websites who can't do that. —Kusma (t·c) 21:47, 9 December 2017 (UTC)
  • Support and cancel Wikipedia Zero while we're at it. James (talk/contribs) 09:24, 9 December 2017 (UTC)
  • Oppose – Wikipedia is not a vehicle to promote the political views of its editors. The project should not be taking a stance on political issues because it undermines our ability to maintain a neutral point of view for the issues we take a stance on. Additionally, there is a significant lack of clarity as to whether Wikipedia Zero is compatible with net neutrality. As our article on it mentions, it has been held to violate net neutrality in at least one jurisdiction (Chile). The broader Wikimedia movement’s relationship with net neutrality is therefore complicated, no matter how you spin it. Mz7 (talk) 11:07, 9 December 2017 (UTC)
  • Weak support This may have a potential effect to American Wikipedia readers and editors. The WP0 thing is a bit embarrassing, but I'd consider such an argument to be whataboutery, and not important to the current situation. !dave 20:36, 9 December 2017 (UTC)
  • Oppose per above JFG. If this occurs please limit it to US readers and do not disrupt the whole world's English WP for a US issue (at present). --Tom (LT) (talk) 21:29, 9 December 2017 (UTC)
  • Support some form of participation in protest, including protesting against Wikipedia Zero. —Kusma (t·c) 21:47, 9 December 2017 (UTC)
  • Support some form of protest. Enterprisey (talk!) 04:05, 10 December 2017 (UTC)
  • Strongest Oppose Don't disrupt Wikipedia to make a point. You have an awful lot of advanced permission editors like myself and many of you above who can a lot of damage very quickly if you annoy us. I have worked a lot on Wikipedia to keep it presentable, useful, legal, informative, etc for the people of Earth, and don't take kindly to using it as political forum. I disaprove of power tripping jerk moves like the black out and I disaprove of disrupting the entire world over net neutrality. Y'all didn't do Wikipedia against Donal Trump, or Wikipedia Against Brexit, or Wikipedia Against Racism. L3X1 (distænt write) 04:24, 10 December 2017 (UTC)
  • Support. To do otherwise is to surrender the Internet & its freedom of speech to corporate interests -- many of whom have an international reach. This is not just an issue local to the US. -- llywrch (talk) 05:06, 10 December 2017 (UTC)
  • Strongest possible oppose Wikipedia must remain neutral at all costs and not be a soapbox for random issues. There are other sites for that. 128.180.138.57 (talk) 05:33, 10 December 2017 (UTC)
  • Strong oppose Wikipedia must remain neutral at all cost and not join a political issue where opinion is clearly divided.If anyone wants to join they are free to do so.But do not want Wikipedia to join the protest.Pharaoh of the Wizards (talk) 17:04, 10 December 2017 (UTC)
  • You can't even consider opposing this. I'm sorry, but as a Wikipedia lover and someone who has large amounts of clout on several Wikia pages, I cannot oppose this. As for blackout ideas, rig an automated system so that whenever someone tries to access Wikipedia, it sends an email to the FCC telling them what bullshit this is, and then blacks out the site. Unsigned comment by MitchG74 who has made few edits outside this topic and may be ducky
  • Oppose. This is not an existential threat, and therefore our absolute neutrality is completely mandatory. Wikipedia will continue to exist regardless of what happens to net neutrality, and that is the determining factor for whether we can get involved. --Yair rand (talk) 22:23, 10 December 2017 (UTC)
  • Support Yes we should advocate for equal and fair access to information. Access to information is political. Many of us opposed the ban of Wikipedia in Turkey for example. Access to information hopefully is not a partisan issue, though it might be in some places in the world. Just because one supports Wikipedia Zero does not mean one must support no regulations on the Internet at all. Doc James (talk · contribs · email) 22:42, 10 December 2017 (UTC)
  • Oppose. I am as much in favor of net neutrality as the next Wikipedian, but this is a U.S. domestic political dispute, not something that Wikipedia should get involved in. Sandstein 08:24, 11 December 2017 (UTC)
  • Strong Support. The internet as we know it is in danger.— Preceding unsigned comment added by Kmcinnis1091 (talk • contribs) 14:49, 11 December 2017 (UTC)— Kmcinnis1091 (talk • contribs) has made few or no other edits outside this topic.
  • Support The very act of creating a free encyclopedia, one that is generally free from commercial goals, free from advertisements, free to access, free to redistribute, free to write about almost anything regardless of religion, government, or authoritarian control, free to consume on any device, free to see the code that makes it work - all are radical acts political in nature. Maybe not from where you are sitting. But many people who get daily value from the work of volunteer contributors have no other source of knowledge. Many contributors - themselves in less than ideal situations - do so out of no external motivation. We do it because we believe it has value to others, to our society and the world as a whole. Wikipedia won't die because we didn't invest in some new whizz-bang technology. It will die because we let it bleed slowly, to wither. A healthy editorship, a civil community, standing up for something as important as unrestricted access to the entire internet - those are the things we need now. Ckoerner (talk) 23:10, 11 December 2017 (UTC)
  • Support per above. We already know that there are editor WP:BIASes on Wikipedia that either degrade the quality of articles, or limit who can edit them. At the same time, the is an impoverished class in the US that may not have access to WP:ZERO. Wikimedia supports this. I believe it is the moral decision to make. Buffaboy talk 09:35, 12 December 2017 (UTC)

A general background note

Those asking "Well, we didn't have net neutrality protection in 2014 or before, why would this affect us now?", I suggest reading through this good history of Net Neutrality from 2015. Key is that leading into 2014, the Internet providers were looking to implement preferred lanes, the FCC issued statements that said "No you can't do that" and issued initial net neutrality rules before 2014. Verizon challenged those and won in court in early 2014, since the court ruled internet providers were not common carriers and thus not regulated by the FCC, though did agree FCC should regulate broadband networks. The 2014 FCC quickly put into place a revised ruleset for of Net Neutrality that has prevented internet providers since from favoring traffic. That 2014 ruling is what the FCC is planning to revoke next week.

So the short answer is that ever since there was discussion of favoring traffic by the Internet providers, there has been some type of net neutrality protection from the FCC to stop it, just not necessarily in its current form. The upcoming vote will be the first that that that will change and allow providers to do what they want. --Masem (t) 21:49, 7 December 2017 (UTC)

  • Moot point for those of us that do not want Wikipedia to ever turn political, regardless of the consequences, for this or SOPA or whatever comes next. This also assumes everyone here agrees on Net Neutrality, which unlike Free Speech, is not the case, so you would alienating editors who have a different opinion and forcing them to say something against their political philosophy or leave the community. Dennis Brown - 2¢ 19:52, 9 December 2017 (UTC)

Closing

Are we ready to close this as no consensus? It has been open for more than 24h, everybody had a chance to participate, and there is no way consensus either way could be established here.--Ymblanter (talk) 21:53, 8 December 2017 (UTC)

I think it's best to just let people talk, as long as it remains non-acrimonious (which so far it seems to be). Discussions that do not need urgent closure are typically left open for longer to allow for comments from people who edit less frequently. Yes, in this case, the calendar imposes a deadline, but we may as well let the clock run out on the thread. Oftentimes, closing conversations early is more trouble that it's worth. isaacl (talk) 05:33, 9 December 2017 (UTC)
I agree with Isaacl here. Leaving it open might be pointless insofar as changing the consensus, but it's one of those topics that people want to opine and debate, and cutting it off early might be seen negatively. Better to keep the discussion in one place, particularly as it has been very civil up to now. Dennis Brown - 2¢ 19:47, 9 December 2017 (UTC)

Should we close this soon? Today is the 12th, and any decision made after today would essentially be moot. SkyWarrior 11:33, 12 December 2017 (UTC)

Bumping. The 12th is already past for our friends on the other side of the Atlantic, and it will soon be past for us in the States as well. This should be closed as it is effectively moot now. SkyWarrior 02:43, 13 December 2017 (UTC)

Individual action

What can we do (on-wiki in particular) as individuals? Cunningham's Law applies. Tag edit summaries in some consistent way during the event? Userboxes? Organize an edit-a-thon for the day of around the topic of the internet, FCC, etc? How can the enthusiastic share ideas and participate as indivusls? Without disruption, of course. :) Ckoerner (talk) 23:16, 11 December 2017 (UTC)

Tagging edit summaries is a very big no from me, and it might be a little too late to create an official edit-a-thon, giving that the 12th is tomorrow. Userboxes are perfectly fine, however, and I think that may be the only thing we should do as individuals. SkyWarrior 00:34, 12 December 2017 (UTC)

Here's some tweet examples you can consider, with links to either the EFF action page or the foundations blog post:

—TheDJ (talk • contribs) 14:03, 13 December 2017 (UTC)

Game over:(. 17:43, 14 December 2017 (UTC)
The internet lost. Bardic Wizard (Tell your congressman to vote against net neutrality) 20:20, 14 December 2017 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

An ‘Assembly box’ (a serious sandbox)

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)

WMF Community Wishlist Survey is system-gameable

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:

  1. Only the top-ten items will have any resources devoted to them (barring some other process being invoked) – no matter how many proposals there are or how urgent or important any of them are.
  2. Because it's a popularity contest, and a pure voting mechanism, normal Wikimedian consensus-building methodology is thwarted. Reasons don't have to be good.
  3. While this is a weak form of proportional voting, it's a variant that directly encourages people to vote for the 10 things they want most, then ignore – or even vote against – every other proposal even if they agree with it. Votes on the same proposal across multiple years are also lost, so proposals cannot build support.
  4. There's no "leveling of the playing field" between categories. For example, this year, 3 "Editing"-category proposals were approved, all 10 successful proposals were in just 6 categories, and 9 categories got nothing. This sort of pattern repeats year after year; important proposals of narrower interest (e.g. to admins, or to technical people) never pass, even if support for them would have built over years.
  5. Proposals can be – and are – shamelessly canvassed with impunity; meanwhile, too few Wikimedians even know the survey exists or when it is open, which greatly compounds the skew caused by focused canvassing (i.e., there is no broad tide of input that washes away intentional statistical spikes – the spikes, along with lower-common-denominator appeal, and novelty, are actually what determine the outcome.

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)
TLDR L3X1 disagrees that the issues named, if they exist, are a major problem
  • A. I Thought it said that other proposals would get some resources if the WMF had them, just not the full amoutn that the top 10 get
B. So? They dont' want consensus, they want to know which is the most popular.
C Ignoring the stuff they don't want, well I would too. If I don't care about something enough to support it, I'm not going to support it. As for voting against, that is useless because only support votes are counted. If 500 people voted against the top proposal, the top proposal would still be top because it got the most supports.
D I didn't support stuff I didn't understand because that would be wrong. Naturally, people will have less of an interest in and be unable to see why something would be important if they have no connection to it. I doubt any of us here (excepting myself) would be interested in participating in a nerd-vote regarding Ford's suspensions technologies. Same reason I didn't even look at the mobile proposals.
E I think a notice was sent out to the talk pages here on wiki, but I can't remember. I also think most people didn't spend a few hours going through nearly every proposal.
1. The more the merrier, right?
2 Lots of the poposals not in top 10 have a Phab ticket open.
3 Seeing as every 4 hours the topics resort the porposals, I say the current version is fine.
4 as long as support was over 50% of course seeing as there is no voting against I don't understand that bit.
5 …
6 No no no. Voting not !voting. No point in a rationale seeing as we aren't here for consensus and there is no admin to deem certain rationales better or worse. We have enough problem in AFD because we use not!votes already.
7 no point
8 yes. I know it is hard to get more than 200 editors to turn out to anything, but I think most people only go to it because they were "in the loop". L3X1 (distænt write) 14:46, 20 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)

Proposal to adopt WP:WikiProject Video games/Article guidelines into MoS as "WP:Manual of Style/Video games"

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)

List of previous creators of an article

Tracked in Phabricator
Task T12331
  • 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)

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. GMGtalk 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 BladesGodric 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. ~ Rob13Talk 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. GMGtalk 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. ~ Rob13Talk 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. GMGtalk 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 BladesGodric 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)

Retrieved from "https://wiki.riteme.site/w/index.php?title=Wikipedia:Village_pump_(proposals)/Archive_143&oldid=1252047486"