Wikipedia:Village pump (proposals)

From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by 128.237.175.221 (talk) at 19:15, 8 December 2017 (→‎Wikipedia and the Dec. 12th “Break The Internet” day of action for net neutrality). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

 Policy Technical Proposals Idea lab WMF Miscellaneous 
Shortcuts

New ideas and proposals are discussed here. Before submitting:


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)[reply]

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)[reply]

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)[reply]

Survey (Auto skip inactive editors from newsletters)

  • Support As proposer. ϢereSpielChequers 19:15, 27 October 2017 (UTC)[reply]
  • 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)[reply]
  • 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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
  • 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)[reply]
  • Support. Newsletters piling up on inactive talk pages is a nuisance. Alsee (talk) 23:41, 27 October 2017 (UTC)[reply]
  • 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)[reply]
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)[reply]
  • Support as per previous comments, especially the desirability of avoiding long cluttered talk pages. Peter coxhead (talk) 19:47, 28 October 2017 (UTC)[reply]
  • 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)[reply]
  • Support with a time threshold and an optout. jcc (tea and biscuits) 11:33, 29 October 2017 (UTC)[reply]
  • Support I suppose, but I would much prefer 12 months. Jenks24 (talk) 12:09, 29 October 2017 (UTC)[reply]
  • 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)[reply]
Forsooth, my liege, thou canst opt-out, thus to continue the succor of thy monthly Signpost! EEng 07:16, 30 October 2017 (UTC)[reply]
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)[reply]
  • Support 12 months. At a minimum 6, but 4 months sounds too short to me (call it unbelievable, but some people have jobs that require them to travel to far-away places without internet, and a 4-month lapse seems way too short to establish an account will probably not be used any more). Whether the proposal does not solve certain edge cases (e.g. opting out before having a stroke) is not all that relevant (see nirvana fallacy). TigraanClick here to contact me 08:44, 30 October 2017 (UTC)[reply]
  • Support 1 year. Longer may be necessary, but I think 1 year is a good start. JTP (talk • contribs) 01:57, 31 October 2017 (UTC)[reply]
  • Oppose In the case of some newsletters, it can spur people into activity. --Rschen7754 04:01, 31 October 2017 (UTC)[reply]
    But this is about cases where it hasn't (most people seem to favor a full year or more before this triggers).  — SMcCandlish ☏ ¢ >ʌⱷ҅ᴥⱷʌ<  15:53, 6 November 2017 (UTC)[reply]
  • Support Swarm ♠ 20:32, 2 November 2017 (UTC)[reply]
  • Support. Don't care much about the time span; anything over about 6 months seems fine. No prejudice against some other solution (per John Cline).  — SMcCandlish ☏ ¢ >ʌⱷ҅ᴥⱷʌ<  15:53, 6 November 2017 (UTC)[reply]
  • Support a year. Excessively cluttered talk pages serve nobody any purpose. A year's worth of twice a month newsletters is 24 sections! – Train2104 (t • c) 19:00, 6 November 2017 (UTC)[reply]
  • Support a year. If they're not logging on, it's just piling up. White Arabian Filly Neigh 16:29, 8 November 2017 (UTC)[reply]
  • Comment. I think it is important that this be a minimum prescribed behavior - that it explicitly allows bots to drop subscribers who have been inactive for a shorter timeframe than what looks to be the 12 month consensus. If memory serves, the feedback request service stops after one month on inactivity, and this policy definitely should not supersede that timeframe, nor any other talk page subscription that expires in less than a year. VanIsaacWScont 17:35, 10 November 2017 (UTC)[reply]
  • Support a year - Long overdue!, If those inactive still want to read for instance the Signpost then they can bookmark that page .... –Davey2010Talk 00:07, 11 November 2017 (UTC)[reply]
  • Support I didn't edit Wikipedia for two years, and my talk page was completely cluttered. I think that this is a great idea for inactive accounts. EMachine03 (talk) 14:25, 15 November 2017 (UTC)[reply]
  • Support this obvious proposal (i can't believe no one has suggested this already). The timespan is less important, though a year's inactivity should be the outside length. Happy days, LindsayHello 10:31, 19 November 2017 (UTC)[reply]
  • Support anything from 4 months and 12+ months. 6 months seems very reasonable and useful if you have to pick a number. Dennis Brown - 2¢ 17:25, 20 November 2017 (UTC)[reply]
  • Support. I would say that we start with presumption of one year, and adjust higher or lower after observing the results for a while. bd2412 T 22:09, 30 November 2017 (UTC)[reply]

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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
  • Most of the larger newsletters are sent using MassMessage from opt-in lists. I think 4 months is too short, perhaps a year - and mailing lists may want overrides on this. — xaosflux Talk 17:03, 28 October 2017 (UTC)[reply]
    It's not difficult to remove other people from MassMessage mailing lists; here's one that I did recently. --Redrose64 🌹 (talk) 20:40, 28 October 2017 (UTC)[reply]
    When people die mailing list removal makes sense, but if people are on a long wikibreak then skipping inactives is much better - after they come back the latest issue will turn up after a while. ϢereSpielChequers 10:45, 29 October 2017 (UTC)[reply]
    And if someone is severely sick for a long time, there's a chance they may be back eventually; returning them to the active delivery list shouldn't require any action on their part. עוד מישהו Od Mishehu 12:49, 29 October 2017 (UTC)[reply]
  • @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)[reply]
    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)[reply]
    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)[reply]

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)[reply]

  • 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)[reply]

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)[reply]
    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)[reply]
    Is that what happens to my New York Times some mornings? EEng 19:36, 30 October 2017 (UTC)[reply]
    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)[reply]
  • 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)[reply]
  • 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)[reply]
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)[reply]
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)[reply]
Um, OK, well it seems unnecessarily complicate, but anyway why isn't it being used already? EEng 23:17, 30 October 2017 (UTC)[reply]
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)[reply]
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)[reply]
  • 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)[reply]
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)[reply]
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)[reply]
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)[reply]
@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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
  • Maybe abolish in favour of an unsubstituted template? I'm just now wondering, I might prefer to receive newsletters, like the signpost, by email. Investigating, I might like the Wikipedia:Wikipedia Signpost/Subscribe Watchlist notification method. --SmokeyJoe (talk) 04:05, 31 October 2017 (UTC)[reply]
Um, an unsubst'ed template is exactly what I'm proposing. EEng 04:08, 31 October 2017 (UTC)[reply]
Where? --SmokeyJoe (talk) 04:57, 31 October 2017 (UTC)[reply]
A dozen posts up, starting with "Hmmmmm..." EEng 05:21, 31 October 2017 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]

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)[reply]

Newspaper deliverers to remove old newspapers still on the driveway

  • This may be mildly complicated, but I think the bots used to deliver newletters should scan for the previous newsletter and remove it it is still there. The archive of all newsletters should be stored at the source, not on recipients' talk pages or even their talk page archives. --SmokeyJoe (talk) 03:58, 31 October 2017 (UTC)[reply]
    Again, please note most of these are not "delivered by bots" they are delivered by the MassMessage process, the sender never interrogates the recipient pages. — xaosflux Talk 04:01, 31 October 2017 (UTC)[reply]
    Maybe they should be delivered by bots, who could then clean up previous issues of the newsletter. Ivanvector (Talk/Edits) 12:24, 31 October 2017 (UTC)[reply]
    Some users might want to keep all newsletters for archive purposes, though, and might not want old editions to be removed. -Indy beetle (talk) 13:42, 27 November 2017 (UTC)[reply]
    In that case, would a link to the stored source would suffice? Iggynelix (talk) 21:31, 28 November 2017 (UTC)[reply]
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.

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)[reply]

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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
To prove the point, I tried thinning out the infobox on Auxillia Mnangagwa. This was reverted (in good faith) pretty quickly (https://en.wikipedia.org/w/index.php?title=Auxillia_Mnangagwa&oldid=prev&diff=812716383). If editors think that there is a problem with over-sized infoboxes then something like a guideline will be needed.Greenshed (talk) 01:13, 30 November 2017 (UTC)[reply]
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)[reply]
  • Infoboxes are intended to provide a bullet point summary, and should be succinct. Succession boxes provide a means to follow through successive holders of the same office. Here I am thinking of some UK politicians who have had a much longer list of appointments. Peterkingiron (talk) 16:17, 26 November 2017 (UTC)[reply]
  • Also a tentative support, the devil is in the details. Infoboxes like that at Phil Taylor (darts player) are clearly excessive. power~enwiki (π, ν) 22:14, 30 November 2017 (UTC)[reply]
  • I would support an option to collapse succession infoboxes over a certain length. bd2412 T 22:38, 30 November 2017 (UTC)[reply]

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)[reply]

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 Template: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)[reply]


  • 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)[reply]

Discussion (Draft Header Template)

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)[reply]

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)[reply]
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)[reply]
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)[reply]
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)[reply]
That sounds good to me. Smallchief (talk) 20:09, 30 November 2017 (UTC)[reply]
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)[reply]
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)[reply]
Bots on a watchlist? Eww. GMGtalk 20:23, 30 November 2017 (UTC)[reply]
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)[reply]
  • 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)[reply]
    • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
    • 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)[reply]
  • 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)[reply]
    • 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)[reply]
      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)[reply]
      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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
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)[reply]
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)[reply]
  • 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)[reply]
  • Did anyone experience the same complaint about the ratings that is mentioned here? Jo-Jo Eumerus (talk, contributions) 13:48, 1 December 2017 (UTC)[reply]
    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)[reply]
    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)[reply]
  • 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)[reply]
    • 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)[reply]
  • 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)[reply]
    • 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)[reply]
    • 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)[reply]
      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)[reply]
  • 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)[reply]
  • 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)[reply]
    • Actually, there's now a pretty good tool for identifying article ratings. I've found that it's accurate >90% of the time. It tends to over-rate stubs with long bulleted lists or lots of citations as being start-class, but overall, I'm pretty happy with it. See m:Research:Screening WikiProject Medicine articles for quality for more information. I'd be very happy with having this tool assess stubs independently, and with it producing a list every ~month of articles whose ratings appear to be off by two classes. WhatamIdoing (talk) 19:18, 6 December 2017 (UTC)[reply]
      Thanks for that! I do remember when that project started, but had forgotten about it. I will give it a try. Hawkeye7 (discuss) 19:35, 6 December 2017 (UTC)[reply]
  • 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)[reply]
  • 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)[reply]
      • 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)[reply]
        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)[reply]
        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)[reply]
        • #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)[reply]
    • 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)[reply]
  • 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)[reply]
  • 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)[reply]
      • "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)[reply]
@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)[reply]
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)[reply]
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)[reply]

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)[reply]

  • 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)[reply]

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)[reply]

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)[reply]
  • Support some sort of compression of the current scheme. Kaldari (talk) 00:02, 5 December 2017 (UTC)[reply]

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)[reply]

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)[reply]
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)[reply]

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)[reply]

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)[reply]
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)[reply]
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)[reply]
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)[reply]
@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)[reply]

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)[reply]

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)[reply]

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

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)[reply]

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)[reply]

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)[reply]

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)[reply]
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)[reply]

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

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)[reply]

  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
    • Comment Wikipedians as individuals can be as political or apolitical as they like, but Wikipedia qua Wikipedia needs to preserve its impartiality. --Trovatore (talk) 20:30, 7 December 2017 (UTC)[reply]
      • No our articles do, our community is political by nature. The whole idea of free knowledge for everyone is a political statement in itself. —TheDJ (talk • contribs) 20:37, 7 December 2017 (UTC)[reply]
        • I disagree. If Wikipedia becomes a pressure group, its impartiality in presenting information will also be suspect. --Trovatore (talk) 20:40, 7 December 2017 (UTC)[reply]
  • Oppose Are we forgetting Wikipedia Zero? We'd be protesting something we've been lobbying for. Hawkeye7 (discuss) 20:11, 7 December 2017 (UTC)[reply]
    • I don't see why. "Imagine a world in which every single human being can freely share in the sum of all knowledge." comes before being holier than holy about network neutrality in my list of priorities. —TheDJ (talk • contribs) 20:35, 7 December 2017 (UTC)[reply]
    • Excellent point. There is more than one side to this. Natureium (talk) 20:48, 7 December 2017 (UTC)[reply]
    • Wikipedia Zero, because it undermines net neutrality, does, sadly, more harm than good. --Anthonyhcole (talk · contribs · email) 08:36, 8 December 2017 (UTC)[reply]
  • 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)[reply]
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)[reply]
      • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • Oppose a local US issue that is not too serious to Wikipedia at all. Graeme Bartlett (talk) 20:56, 7 December 2017 (UTC)[reply]
  • 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)[reply]
    • 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)[reply]
      • 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)[reply]
  • 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)[reply]
  • Strongly oppose using Wikipedia for political activism. Rentier (talk) 21:08, 7 December 2017 (UTC)[reply]
  • 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)[reply]
  • 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).

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)[reply]
  • 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)[reply]
    • I've added this to {{Centralized discussion}}. I can't think of a better forum than this for the discussion, but it does need to be more widely popularized to be binding. power~enwiki (π, ν) 06:17, 8 December 2017 (UTC)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
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)[reply]
  • Oppose There is a great deal of fear, uncertainty, and doubt (FUD) over this and Wikipedia should not be feeding into that. People are loosing their shit over hypothetical scenarios or are just "taking someone else's word for it". It will also further push Wikipedia into political advocacy, and once you head down that road, it is increasingly hard to turn back. I should also not that this "proposal" was made by a single purpose account whose only purpose is to use Wikipedia as a soapbox by disrupting service to illustrate a point. —Farix (t | c) 12:25, 8 December 2017 (UTC)[reply]
  • Support - Internet neutrality is important for everyone. WP should do what it can to support it. Renata (talk) 13:32, 8 December 2017 (UTC)[reply]
  • 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)[reply]
  • Oppose Per SkyWarrior.--Kevin Dewitt (talk) 14:37, 8 December 2017 (UTC)[reply]
  • 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)[reply]
  • Strong support—Providing universal access to free knowledge is the core purpose of Wikipedia.--Carwil (talk) 16:10, 8 December 2017 (UTC)[reply]
  • 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)[reply]
  • Strong (very) Support Because NN in America sets a precedent for the world. I hope that we can all agree that getting rid of NN for Americans is a bad thing. In other words, allowing ISPs to throttle, change, or charge extra for certain websites is not fair and directly hinders free speech. It's like an art store selling you a Bic Pen for $1.00, but charging you $5.00 if you wish to draw circles, $10.00 if you wish to draw squares, and outright denying to sell it to you if you wish to draw a rhombus; the point is that if we pay for the Bic Pen we should be able to draw whatever we want with it, and not be charged differently for how we use it. The same applies to the internet. The reason this is dangerous for other countries as well is because any action taken in America, one of the world's superpowers, sets an example for other countries. If ISPs can abuse the internet in America, then they are going to move on to other countries and try to abuse it their as well. It may take some, but eventually they will try to gain ubiquitous control of the internet all over the world.

Thus, I strongly support Wikipedia taking action.

  • 1.* YES, join the December 12th "Break the Internet Day of Action".
  • 2.* YES, we should encourage users to call their lawmakers and senate (similar to how we acted during SOPA).
  • 3.* Not sure. Do something similar to SOPA. Black out the site for the first 60 seconds to simulate a long load time due to throttling. During that time, give information on how and who to call to voice your support for NN.

I apologize for incorrect/bad formatting, but this is my first time contributing to the text of (rather than just reading) wikipedia ALefty (talk) 12:06 PM, 8 December 2017 (EST) — ALefty (talk • contribs) has made few or no other edits outside this topic.

  • 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)[reply]
  • Strong supportAs a long time Wikipedia user/reader I strongly support taking action. Wikipedia is about the free dissemination of knowledge. This repeal directly limits the free dissemination of knowledge. Thus every wikipedian should stand behind it, and I don't know why you wouldn't.--bigboopbop1 (talk) 12:43, 8 December 2017 (EST) — bigboopbop1 (talk • contribs) has made few or no other edits outside this topic.
  • 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)[reply]
  • 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)[reply]
  • 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

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)[reply]

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 [[1]]. That discussion got sidetracked into technical minutiae. Obviously not much visible has come out of that proposal.

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

You can disable animations through your preference page. (You might consider taking this to Wikipedia:Village pump (technical) Hawkeye7 (discuss) 20:15, 7 December 2017 (UTC)[reply]
Those just disable CSS animations, not GIFs and animated PNGs —TheDJ (talk • contribs) 20:20, 7 December 2017 (UTC)[reply]
(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)[reply]

RfC: Populating article descriptions magic word

In late March - early April 2017, Wikipedia:Village pump (proposals)/Archive 138#Rfc: Remove description taken from Wikidata from mobile view of en-WP ended with the WMF declaring[2] "we have decided to turn the wikidata descriptions feature off for enwiki for the time being."

In September 2017, it was found that through misunderstanding or miscommunication, this feature was only turned off for one subset of cases, but remained on enwiki for other things (in some apps, search results, ...) The effect of this description is that e.g. for 2 hours this week, everyone who searched for Henry VIII of England or saw it through those apps or in "related pages" or some such got the description "obey hitler"[3] (no idea how many people actually saw this, this Good Article is viewed some 13,000 times a day and is indefinitely semi-protected here to protect against such vandalism).

The discussion about this started in Wikipedia:Village pump (policy)/Archive 137#Wikidata descriptions still used on enwiki and continued mainly on Wikipedia talk:Wikidata/2017 State of affairs (you can find the discussions in Archive 5 up to Archive 12!). In the end, the WMF agreed to create a new magic word (name to be decided), to be implemented if all goes well near the end of February 2018, which will replace the use of the Wikidata descriptions on enwiki in all cases.

We now need to decide two things. Fram (talk) 09:58, 8 December 2017 (UTC)[reply]

How will we populate the magic word with local descriptions?

  1. Initially, copy the Wikidata descriptions by bot
  2. With a bot, use a stripped version of the first sentence of the article (the method described by User:David Eppstein and User:Alsee in Wikipedia talk:Wikidata/2017 State of affairs/Archive 5#Wikipedia descriptions vs Wikidata descriptions)
  3. With a bot, use information from the infobox (e.g. for people a country + occupation combination: "American singer", "Nepali politician", ...)
  4. Start with blanks and fill in manually (for all articles, or just for BLPs)
  5. Start with blanks, allowing to fill in manually and/or by bot (bot-filling after successful bot approval per usual procedures)
  6. Other

Discussion on initial population

  • #5 – allows bot operations for larger or smaller sets of articles per criteria that don't have to be decided all at once, and manual overrides at all times. --Francis Schonken (talk) 10:28, 8 December 2017 (UTC)[reply]
  • #5 is my preference following the reasoning below:
    Option 1, copying from Wikidata, will populate Wikipedia with a lot of really bad descriptions, which will remain until someone gets around to fixing them. My initial rough estimates are that there are more bad/nonexistent Wikidata descriptions than good ones. I strongly oppose this option unless and until someone comes up with solid data indicating that it will be a net gain.
    Option 2, extracting a useful description from the first sentence or paragraph seems a nice idea at first glance, but how will it be done? Has anyone promoting this option a good idea of how effective it would be, how long it would take, and if it would on average produce better descriptions than option 1? This option should be considered unsuitable until some evidence is provided that it is reasonably practicable and will do more good than harm.
    Option 3, copying from the infobox, may work for some of the articles that actually have an infobox with a useful short description, or components that can be assembled into a useful short description. This may work for a useful subset of articles, but it is not known yet how many. I would guess way less than half so not a good primary option.
    Option 4, start with blanks and fill in manually, is probably the only thing that can be done for a large proportion of articles, my guess in the order of half. It will have to be done, and is probably the de facto default. It is easy, quick and will do no harm. It is totally compatible with option 5, for which it is the first step.
    Option 5 is starting with option 4 and applying ad hoc local solutions which can be shown to be useful. Any harm is localised, Wikidata descriptions can be used when they are appropriate, extracts from leads can be used when appropriate, mashups from infoboxes can be used when appropriate, and manual input from people who actually know what the article is about can be used when appropriate. I think there is no better, simpler, and more practical option than this, and suggest that projects should consider how to deal with their articles. WPSCUBA already has manually entered short descriptions ready for use for more than half of its articles, which I provided as an experiment. It is fairly time consuming, but gets easier with practice. Some editors may find that this is a fun project, others will not, and there will inevitably be conflicts, which I suggest should be managed by BRD as simple content disagreements, to be discussed on talk pages and finalised by consensus. In effect, option 5 is the wiki way. It is simple and flexible, and likely to produce the best results with the least amount of damage. · · · Peter (Southwood) (talk): 11:26, 8 December 2017 (UTC)[reply]
    (There was an edit conflict here and I chose to group all my comments together · · · Peter (Southwood) (talk): 11:26, 8 December 2017 (UTC))[reply]
  • #5. Whether a Wikidata description is suitable or not is very different across many groups of articles. It should be decided (and possibly bot populated) per group, sometimes per small group, and for that we need to start from blank descriptions.--Ymblanter (talk) 11:23, 8 December 2017 (UTC)[reply]
  • Start with not using it anywhere, only use it as override per situation. —TheDJ (talk • contribs) 12:09, 8 December 2017 (UTC)[reply]
    TheDJ, To clarify, is this an Option 6: Other that you are proposing here? i.e. Only add the magic word to articles where the Wikidata short description is unsuitable, and use Wikidata description as default in all cases until someone finds a problem and adds a magic word, after which the short description will be taken from the magic word? If this is the case, what is your opinion on reverting to Wikidata description for any reason at a later date? · · · Peter (Southwood) (talk): 14:53, 8 December 2017 (UTC)[reply]
  • #5. That doesn't deal with all the issues, but it comes closest to my views, given the choices. See also my comments at WT:Wikidata/2017 State of affairs/Archive 12 and WT:Wikidata/2017 State of affairs. - Dank (push to talk) 14:06, 8 December 2017 (UTC)[reply]
    • Peter asked me for clarification. If people have specific questions, or if they want a summary of my previous posts, I'll do my best to answer. - Dank (push to talk) 15:30, 8 December 2017 (UTC)[reply]
  • #5 but don't wait too long to fill in where possible. Fram (talk) 14:14, 8 December 2017 (UTC)[reply]
    Fram Are you recommending a massive short term drive to produce short descriptions to make the system useful? · · · Peter (Southwood) (talk): 15:09, 8 December 2017 (UTC)[reply]
    • Yes, although this isn't in my view necessary to proceed with this, only preferable. No descriptions is better than the current situations, but decent enwiki-based descriptions is in many cases better than no descriptions. No need to throw out the baby (descriptions to be shown in search and so on) with the bathwater. Fram (talk) 15:21, 8 December 2017 (UTC)[reply]
  • #6 - don't use it. There has been no consensus to have this magic word in the first place - that is the question that should have been asked in this RfC (see discussion here). I personally think it is a bad idea and a waste of developer time. It's better to focus on improving the descriptions on Wikidata instead. Mike Peel (talk) 15:27, 8 December 2017 (UTC)[reply]
  • #6 — Find a solution that monitors and updates Wikidata descriptions — If a description is good enough for Wikipedia(ns), it should be on Wikidata. If vandalism is blocked on Wikipedia, it should be simultaneously reverted on Wikidata. Wikidata is the hub for interwiki links and a storage site for both descriptions and structured data that then are harvested by external knowledge-based search engines (think Siri, Alexa, and Google's Knowledge Graph). For interwiki purposes, we should want to ensure that short descriptions at Wikidata are accurate, facilitating other language Wikipedias when they interlink to en.wiki. For external harvesting, we should want to prevent vandalism from being propagated. The problems regarding vandalism and sourcing on Wikidata are real, but the solution is for Wikipedians and our anti-vandalism bots to be able to easily monitor and edit the relevant Wikidata material. Possible solutions would include: (a) Implementing a pending changes-like functionality for changes to descriptions on high-traffic or contentious pages; (b) Make changes to short descriptions prominently visible on Wikipedia watchlists, inside the VisualEditor, and as a preference option for Wikipedia editors; (c) Develop and implement in-Wikipedia editing of Wikidata short descriptions using some kind of click-on-this-pencil tool.--Carwil (talk) 15:46, 8 December 2017 (UTC)[reply]
    • After those solutions are implemented, you are free to ask for an rfC to overturn the consensus of the previous RfC which decided not to have these descriptions. This RfC is a discussion to get solutions which give you what you want on enwiki (descriptions in VE, mobile, ...) without interfering in what Wikidata does (they are free to have their own descriptions or to import ours). Fram (talk) 16:01, 8 December 2017 (UTC)[reply]
    Carwil, How do you propose that Wikipedia controls access by vandals to Wikidata? Are you suggesting that Wikipedia admins should be able to protect Wikidata items and block Wikidata users?
    The easy options are… "undo" functionality for Wikidata descriptions in Wikipedia watchlists, and option (a) I proposed above, something like pending-changes that protects pages on Wikipedia from unreviewed changes from Wikidata. Transferring anti-vandalism bots from Wikipedia to Wikidata would also be helpful.--Carwil (talk) 16:47, 8 December 2017 (UTC)[reply]
  • Strongly oppose 4 and strongly oppose 5—Let's reject any solution that mass-blanks short descriptions: these are a functional part of mobile browsing and of the VisualEditor. As an editor and a teacher who brings students into editing Wikipedia, the latter functionality is a crucial timesaver. Wikipedia is increasingly accessed by mobile devices and short descriptions prevent clicking through to a page only to find it's not the one you are looking for.--Carwil (talk) 15:46, 8 December 2017 (UTC)[reply]
    Have you analysed the overall usefulness of Wikidata descriptions and found that there are more good descriptions than bad, or found a way to find all the bad ones so they can be changed to good? If so please point to your methods and results, as they would be extremely valuable. What methods have you used to indicate the comparative harm done by bad descriptions versus the good done by good descriptions? · · · Peter (Southwood) (talk): 16:14, 8 December 2017 (UTC)[reply]
Yes, I have analyzed a sample here. I found that 13 of 30 had adequate descriptions (though 7 of them could be improved), 13 had no descriptions at all, 1 was incorrectly described (not vandalism), 2 were redundant with the article title (i.e., they should be overridden with a blank), and 1 represented a case where the Wikipedia article and the Wikidata entity were not identical and shouldn't share the same description. The redundant descriptions would cause no harm. Mislabelling "Administrative divisions of Bolivia" with the subheading "administrative territorial entity of Bolivia" would cause mild confusion. The legibility provided by descriptions easily outweigh the harms. (The only compelling harm is due to vandalism, which should be addressed by improving vandalism tools not forking the descriptions between the projects.)--Carwil (talk) 16:47, 8 December 2017 (UTC)[reply]
The options 4 and 5 are not to blank anything, they are to put short descriptions, which are text content, into the article they describe, where they can be properly, (or at least better), maintained, by people who may actually know what the article is about. Wikidata can use them if their terms of use allow, and if they are actually better for Wikidata's purposes, which is by no means clear at present. · · · Peter (Southwood) (talk): 16:14, 8 December 2017 (UTC)[reply]
Options 4 and 5 involve starting with blanks everywhere. The whole proposal assumes that we should fork a dataset describing Wikipedia articles into two independently editable versions. Forking a dataset always creates inconsistencies and reduces the visibility of problems by splitting the number of eyes to watch for problems. Better to make Wikipedians' eyes more powerful and spotting problems (which are unusual) rather than to throw up wall between the two projects. My sample suggests that 90% of the time, or more, the two projects are working towards the same goal here.--Carwil (talk) 16:47, 8 December 2017 (UTC)[reply]
They do, but it is unlikely the WMF will switch until the Wikipedia results are no worse than the Wikidata results, though I have no idea how they would measure that, since they don't seem to have much idea of the quality they will be comparing against, or if they do, are not keen on sharing it.
The dataset does not suit Wikipedia. We should not be forced to use it. A dataset that suits Wikipedia may not suit Wikidata. Should we force it on them? Two datasets means Wikipedia can look after their own, and Wikidata can use what they find useful from it, and Wikipedians are not coerced into editing a project they did not sign up for. Using shitty quality data on Wikipedia to exert pressure on Wikipedians to edit Wikidata may have a backlash that will harm either or both projects, not a risk I would be willing to take, if it could affect my employment, unless of course I was being paid to damage the WMF, but that would be conspiracy theory, and frankly I think it unlikely.
I also did a bit of a survey, my results do not agree with yours, and they are also from such a small sample as to be statistically unreliable. I also wrote short descriptions for about 600 articles in WPSCUBA, but did not keep records. Most (more than half) articles needed a new description as the Wikidata one either did nor exist or was inappropriate. There were some which were perfectly adequate, but less than half of the ones that actually existed, from memory. It would be possible to go back and count, but I think it would be a better use of my time to do new ones, if anyone is willing to join such a project. Maybe Wikiproject Medicine, or Biography, where quality actually may have real life consequences, but I don't usually work much in those fields and hesitate to move into them without some project participation. I have already run into occasional unfriendly reactions where projects overlap, but fortunately very few. · · · Peter (Southwood) (talk): 18:18, 8 December 2017 (UTC)[reply]

What to do with blanks

What should we do when there is no magic word, or the magic word has no value?

  1. Show the Wikidata description instead
  2. Show no description
  3. Show no description for a predefined list of cases (lists, disambiguation pages, ...) and the Wikidata one otherwise (this is the solution advocated by User:DannyH (WMF) at the moment)
  4. Other

Discussion on blanks

  • #2 – comes closest to having no description per initial aborted RfC; those who want them can write them, or fill in automatically (per usual bot approval procedures). --Francis Schonken (talk) 10:28, 8 December 2017 (UTC)[reply]
  • #2 The Wikidata description should not be allowed as a default where there is no useful purpose to be served by a short description. An empty parameter to the magic word must be respected as a Wikipedia editorial decision that no short description is wanted. This decision can always be discussed on the talk page. Under no circumstances should WMF force an unwanted short description from Wikidata as a default. Nothing stops anyone from manually adding a description which is also used by Wikidata, but that is a personal decision of the editor and they take personal responsibility as for any other edit. Automatically providing no description for a predefined list of classes has problems, in that those classes may not be as easily defined as some people might like to think. For example, most list articles don't need a short description, but some do. The same may be true for disambiguation pages. Leaving them blank as the first stage and not displaying a short description until a (hopefully competent) editor has added one is easy to manage for the edge cases, and may be managed by other methods per option 5 of population. It is flexible and can deal with all possibilities. There is no need to make it more complicated and liable to break some time. Ideally the magic word could be given a comment in place of a parameter where an explanation of why there should not be a short description would be useful. In this case the comment should not be displayed and is there to inform editors who might wonder if it had been missed. · · · Peter (Southwood) (talk): 11:43, 8 December 2017 (UTC)[reply]
  • Show the wikidata description in stead. —TheDJ (talk • contribs) 12:10, 8 December 2017 (UTC)[reply]
  • #2. No magic word (and magic word with no parameter) should result in no description, not some non-enwiki data being confusingly shown to readers (while being missed by most vandalism patrollers apparently). Today, for 8 hours, we had this blatant BLP violation on a page with 10,000 pageviews per day. Using these descriptions by default (or at all) is a bad idea, and was rejected at the previous RfC. Fram (talk) 14:21, 8 December 2017 (UTC)[reply]
  • From the WMF: We're proposing using Wikidata as the fallback default if there isn't a defined magic word on Wikipedia, because short descriptions are useful for readers (on the app in search results, in the top read module, at the top of article pages) and for editors (in the Visual Editor link dialog). For example: in the top read module from September pictured here, 3 of the 5 top articles benefit from having a short description -- I don't know who Gennady Golovkin and Canelo Álvarez are, and having them described as "Kazakhstani boxer" and "Mexican boxer" tells me whether I'm going to be interested in clicking on those. (The answer on that is no, I'm not really a boxing guy.) I know that Mother! is a 2017 film, but I'm sure there are lots of people who would find that article title completely baffling without the description. Clicking through to the full list of top read articles, there are a lot of names that people wouldn't know -- Amber Tamblyn, Arjan Singh, Goran Dragić. This is a really popular feature on the apps, and it would be next to useless without the descriptions.
We want to create the magic word, so that Wikipedia editors have editorial control over the descriptions, which they should. But if the magic word is left blank on Wikipedia -- especially in the cases where Wikipedia editors haven't written a description yet -- then for the vast majority of cases, showing the description from Wikidata is better than not showing anything at all. As a reader looking at that top read module, I want to know who Gennady Golovkin is, and the module should say "Kazakhstani boxer," whether that text comes from Wikipedia or Wikidata.
I know that a big reason why people are concerned about showing the Wikidata descriptions is that the Wikidata community may sometimes be slower than the Wikipedia community to pick up on specific examples of vandalism. The example that Fram cites of Henry VIII of England showing "obey hitler" for two hours is disappointing and frustrating. However, I think that the best solution there should be to improve the community's ability to monitor the short descriptions, so that vandalism or mistakes can be spotted and reverted more quickly. The Wikidata team has been working on providing more granular display in watchlists on Wikipedia, so that Wikipedia editors can see edits to the descriptions for the articles that they're watching, without getting buried by other irrelevant edits made to that Wikidata item. That work is being tracked in this Phabricator ticket -- phab:T90436 -- but I'm not sure what the current status is. Ping for User:Lydia Pintscher (WMDE) -- do you know how this is progressing?
We've talked in the previous discussions about types of pages where the Wikidata descriptions aren't useful for article display, because they're describing the page itself, rather than the subject of the article. The examples that I know right now are category pages (currently "Wikimedia category page"), disambiguation pages ("Wikimedia disambiguation page"), list pages, and the main page. Those may be helpful in the case of the VE link dialog, especially "disambiguation page", but there's no reason to display those at the top of the article page, where they look redundant and kind of silly. We're proposing that we just filter those out of the article page display, and anywhere else where they're unnecessary. I'd like to know more examples of pages where short descriptions aren't useful, if people know any.
For article pages, I don't know of any examples so far where a blank description would be better for the people who need them (people reading, searching or adding links on VE). If we're going to build the "show a blank description" feature, then we need to talk about specific use cases where that would be the best outcome. That's how product development works -- you don't build a feature, if you don't have any examples for where it would be useful. If people have specific examples, then that would help a lot. -- DannyH (WMF) (talk) 14:58, 8 December 2017 (UTC)[reply]
"For article pages, I don't know of any examples so far where a blank description would be better " Check the two examples of vandalism on pages with 10K+ pageviews per day I gave in this very discussion, including one very blatant BLP violation which lasted for 8 hours today. In these examples, a blank description would have been far preferable over the vandalized one, no? Both articles, by the way, are semi-protected here, so that vandalism couldn't have done by the IPs here (and would very likely have been caught much earlier). "specific use cases where that would be the best outcome." = all articles, and certainly BLPs. Fram (talk) 15:19, 8 December 2017 (UTC)[reply]
Better than no description?
If you want another example of where no description would be preferable over the Wikidata one, look to the right. This is what people who search for WWII (or have it in "related articles", the mobile app, ... see right now and have seen since more than 5 hours (it will undoubtedly soon be reverted now that I have posted this here). This kind of thing happens every day, and way too often on some of our most-viewed pages. Fram (talk) 15:38, 8 December 2017 (UTC)[reply]
I agree that the vandalism response rate on Wikidata is sometimes too slow. I think the solution to that is to make that response rate better, by making it easier for Wikipedia editors to monitor and fix vandalism of the descriptions. I disagree that the best solution is to pre-emptively blank descriptions because we know that there's a possibility that they'll be vandalized. I'm asking for specific examples where editors would make the choice to not show a description on the article page, because a blank description is better than the majority of good-to-adequate descriptions already on Wikidata. -- DannyH (WMF) (talk) 16:10, 8 December 2017 (UTC)[reply]
And I am saying that this is a red herring. Firstly, you claim that there exists a majority of good-to adequate descriptions on Wikidata, without any convincing evidence that this is the case. I am stating that out of several hundred short descriptions that I produced, there were a non-zero number of cases where a short description made no apparent improvement over the article title by itself. · · · Peter (Southwood) (talk): 16:21, 8 December 2017 (UTC)[reply]
DannyH (WMF), Filtering descriptions out of the article page view means that they will be invisible for maintenance which is very bad, unless they are filtered out based on content, not on page type, which may be technically problematic - you tell me, I don't write filter code. Can you guarantee that no vandalism can sneak through by this route?. As long as they are visible anywhere in association with the Wikipedia article they are a Wikipedia editorial issue. · · · Peter (Southwood) (talk): 15:39, 8 December 2017 (UTC)[reply]
We are not asking for a development feature to leave out descriptions that don't exist, it is the simplest possible default. Please try to accept that simply displaying whatever content is in the magic word parameter is the simplest and most versatile solution, and that if we leave it blank that is because we prefer it to be left blank. If anyone prefers to have a short description in any of these cases, they can edit Wikipedia to put in the one they think is right, and if anyone disagrees strongly enough to want to remove it, they can follow standard procedure for editorial disagreement, which is get consensus on the talk page. It is not rocket science, it is the Wikipedia way of doing these things. If it is difficult for the magic word to handle a comment in the parameter we can simply put the comment outside. There may be a few more cases where people will fail to notice that it is there, but probably not a train smash. Is there any reason why a comment in the parameter space should not be parsed as equivalent to no description? I have asked this before, and am still waiting for an answer.· · · Peter (Southwood) (talk): 15:39, 8 December 2017 (UTC)[reply]
  • #1 - and focus on improving the descriptions on Wikidata. Mike Peel (talk) 15:27, 8 December 2017 (UTC)[reply]
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(proposals)&oldid=814423864"