Wikipedia:Village pump (proposals)

 Policy Technical Proposals Idea lab WMF Miscellaneous 

• Table of contents
• First discussion
• End of page
• New post

New ideas and proposals are discussed here. Before submitting:

• Check to see whether your proposal is already described at Perennial proposals. You may also wish to search the FAQ.
• Consider developing your proposal at Village pump (idea lab).
• Proposed software changes should be filed at Phabricator (configuration changes should have gained a consensus).
• Proposed policy changes belong at Village pump (policy).
• Proposed WikiProjects or task forces may be submitted at Wikipedia:WikiProject Council/Proposals.
• Proposed new wikis belong at meta:Proposals for new projects.
• Proposed new articles belong at Wikipedia:Requested articles.

« Archives, 192, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212

Auto skip inactive editors from newsletters

The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion. A summary of the conclusions reached follows.

• Summary:-There is a near-unanimous consensus to support the proposal.
• Enactment:-Thus, the following policy is enacted:--

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

• Caveat-A local disc. may be launched at some appropriate venue to establish consensus as to whether the defining last edit has to be local or it can be global.

Best of wishes for the technical challenges etc. that might need to be scaled in the execution of the consensus:)

Thankfully,Winged Blades ^Godric 14:10, 3 December 2017 (UTC)

---

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

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

Survey (Auto skip inactive editors from newsletters)

• Support As proposer. ϢereSpielChequers 19:15, 27 October 2017 (UTC)
• Support at one year. Users inactive for that long don't need active newsletter posts. Four months might be safe, but a year is safer. —swpb^{T go beyond} 19:33, 27 October 2017 (UTC)
• Support at whatever time threshold (4 months, year, ...). And this should be the default behavior for bots such as User:SuggestBot and Feedback Request Service. Of course, there should be an opt-out so people can ask continue to receive these posts despite their own inactivity. EEng 21:56, 27 October 2017 (UTC)

  The problem with in opt-in option is that some of us (and they don't know it) will either die suddenly, or become permanently incapable of editing Wikipedia suddenly. We don't want these users' talk pages to become cluttered with newsletters. While some of these users have friends who would be trusted to confirm that they will never be back, most probably don't. עוד מישהו Od Mishehu 12:46, 29 October 2017 (UTC)

  I said opt out i.e. the mechanism for suspending delivery after X months of a user's inactivity is active by default, but a user can opt out of that stop-after-4-months'-activity behavior if he wants i.e. set it so that even if he's inactive for X months, delivery continues indefinitely. No matter what, as soon as the editor makes any single edit, he's no longer inactive and delivery resumes. EEng 13:13, 29 October 2017 (UTC)

  A user opts out of delivery stoppiong, and then if this user dies suddenly (perhaps several years later), delivery still continues indefinitely. If it's reasonably possible, I would certainly say that if a user goes on a declared WikiBreak, delivery could start at the last round before the declared return date; however, we do need to put an absolute, non-overridable, date beyond which delivery stops. עוד מישהו Od Mishehu 07:55, 30 October 2017 (UTC)

• Support Long, cluttered talk pages make it hard to see substantive content, and it is sometimes necessary to investigate why some things were done a certain way. Also, while monitoring pages with broken templates I have often found user talk pages where templates no longer work due to superfluous bot messages. Johnuniq (talk) 22:01, 27 October 2017 (UTC)
• Support. Newsletters piling up on inactive talk pages is a nuisance. Alsee (talk) 23:41, 27 October 2017 (UTC)
• Support, but give the user a notification to tell them their newsletters won't be sent if they don't perform an edit or logged action within the next N days (and/or a notification after the suspension of newsletters). Jc86035 (talk) 10:57, 28 October 2017 (UTC)

And so it begins. Let's not start adding more posts. They're just newsletters. Most such posts have a link that says, "To stop receiving this newsletter..."; change that to "To stop or resume receiving..." and leave it at that. EEng 14:23, 28 October 2017 (UTC)

• Support as per previous comments, especially the desirability of avoiding long cluttered talk pages. Peter coxhead (talk) 19:47, 28 October 2017 (UTC)
• Support, provided that the suspention stops immediately once editing resumes - that is, for the user to start getting them again, all (s)he needs to do is a single edit with no need to resubscribe; additionally, a bot should probably warn the user at the last delivery of a subscription (in a separate section) about such suspention. I think the longer of 4 deliveries and 4 months is lone enough. עוד מישהו Od Mishehu 11:22, 29 October 2017 (UTC)
• Support with a time threshold and an optout. jcc (tea and biscuits) 11:33, 29 October 2017 (UTC)
• Support I suppose, but I would much prefer 12 months. Jenks24 (talk) 12:09, 29 October 2017 (UTC)
• Oppose - though, clearly, a good faith effort, this remedy has collateral consequences that suggest its achievable gains, both can and should be managed in some other, more efficient way. In general, I support centralized solutions over local solutions where the means are; invariably: more costly and far more inefficient. My recurring notifications arrive via an alternate account which this proposal, to my chagrin, would cease; for the editing inactivity of that account. Not withstanding these, I can not support the local mechanics of this proposal, nor the stifling effects their inadequacy too often spawn.--John Cline (talk) 06:41, 30 October 2017 (UTC)

Forsooth, my liege, thou canst opt-out, thus to continue the succor of thy monthly Signpost! EEng 07:16, 30 October 2017 (UTC)

One potential solution would be a bot which can parse templates from Category:Alternative Wikipedia account templates, and keep delivering to a publicly-declared alternate account if the main account is still active. עוד מישהו Od Mishehu 07:57, 30 October 2017 (UTC)

• 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). Tigraan^{Click here to contact me} 08:44, 30 October 2017 (UTC)
• 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)
• Oppose In the case of some newsletters, it can spur people into activity. --Rschen7754 04:01, 31 October 2017 (UTC)

  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)

• Support Swarm ♠ 20:32, 2 November 2017 (UTC)
• 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)
• 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)
• Support a year. If they're not logging on, it's just piling up. White Arabian Filly ^Neigh 16:29, 8 November 2017 (UTC)
• 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. VanIsaac_WS^cont 17:35, 10 November 2017 (UTC)
• Support a year - Long overdue!, If those inactive still want to read for instance the Signpost then they can bookmark that page .... –Davey2010^Talk 00:07, 11 November 2017 (UTC)
• 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)
• 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, Lindsay^Hello 10:31, 19 November 2017 (UTC)
• 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)
• 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)

Threaded discussion (Auto skip inactive editors from newsletters)

• This looks very much like a solution in search of a problem. If someone hasn't edited for 4 months then why would anyone feel the need to read the user talk page anyway? And if nobody is reading the page then what does it matter how long it is? It's quite possible that a user doesn't edit but is still interested in reading newsletters, and, if not, it does no harm to carry on sending them. 86.17.222.157 (talk) 20:19, 27 October 2017 (UTC)

Many of us will have multiple inactive Wikipedians on our watchlists. The absent Wikipedian can be assumed absent, but not others. As for the problem, eventually these newsletters turn such talkpages into ones that are slow to load, hence the earlier, more intrusive proposal to autoarchive them. ϢereSpielChequers 21:30, 27 October 2017 (UTC)

I've got a number of "missing Wikipedians" on my watchlist hoping to be able to welcome them back, and these notices every few days just gum up my watchlist. I find the argument that maybe someone is silently reading newsletters for a year, without making a single edit, unpersuasive to say the least. Anyway, we can have an opt-out by which people can explicitly ask to continue receiving. EEng 21:56, 27 October 2017 (UTC)

Does anyone force you to have these pages on your watchlist? Surely you can just remove them. This is supposed to be an encyclopedia, not a social networking site, so welcoming people back should be very low on anyone's list of priorities. 86.17.222.157 (talk) 18:40, 28 October 2017 (UTC)

I disagree; there's a serious shortage of editors, and welcoming editors back is very worthwhile. Peter coxhead (talk) 19:49, 28 October 2017 (UTC)

I realise that I'm in a minority here, so I'll make this my last comment, but I don't believe that there is any evidence that any of this touchy-feely stuff actually leads to a better encyclopedia, which is supposed to be what Wikipedia is about. 86.17.222.157 (talk) 21:24, 28 October 2017 (UTC)

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

  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)

  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)

  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)

• @WereSpielChequers: can you explain how easy to change the newsletter bots to only post to talkpages of editors who have been active in the last 4 months? Also note - not all newsletters are sent "by bots", regarding MassMessage above - are you proposing that the extension somehow be able to detect "activity"? Will cross-project activity account? What is your measure of this (e.g. will a logged action suffice?) — xaosflux ^Talk 00:40, 30 October 2017 (UTC)

  For example, lets look at a very popular newsletter, Wikipedia:Wikipedia Signpost - this is not sent "by bots", it is sent by editors. — xaosflux ^Talk 00:45, 30 October 2017 (UTC)

  Hi Xaosflux. I'm happy for cross project activity to count, and yes one logged action would be sufficient to show you are still around - afterall we do have cross project notifications now so if you are only active on commons you would know if you were still receiving a newsletter on EN. As to the mechanics of this there are several ways it could be done. It could be on the fly with a new massmessage bot that people could use putting in their subscription list and the latest newsletter, or a standalone bot that moved people from subscription lists to an inactive subpage and back again when they reappear. At present I'm just seeking consensus for it to happen, precise mechanics would be up to the bot writer. ϢereSpielChequers 07:10, 30 October 2017 (UTC)

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

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

Should talk page newsletter notices be abolished completely?

• Has there ever been a community discussion about whether "newsletter" notification should ever be used? I find it lazy and obviously its become resource intensive on inactive editor pages. Why can't we expect editors to just put newsletters in their watchlist and keep informed via that existing mechanism rather than use a bot-driven, spammy mechanism like talk page posts? Every time a "newsletter" is updated, it becomes my watchlist that is spammed as many people I've interacted with on their talk page gets these notifications. -- Netoholic @ 07:33, 30 October 2017 (UTC)

  Indeed; I have never subscribed to The Signpost, but sometimes read it - on the user talk pages that I am watching for other purposes. My own User talk page stays pretty clear of newsletters - all the ones that I'm interested in are subscribed to by other people. --Redrose64 🌹 (talk) 09:48, 30 October 2017 (UTC)

  Is that what happens to my New York Times some mornings? EEng 19:36, 30 October 2017 (UTC)

  Especially with the notification system (which is newer than these newsletters were originally created), these subscriptions are probably unneeded. With the signpost we have a transcludable template, a system which can be used for all newsletters; a bot could easily PURGE all pages transcluding a particular newsletter's template, and the notification system will inform any interested user about the new edition without spamming any page visible to anyone else. However, if we make such a change, we need to actively inform all users on any distribution list about this change. עוד מישהו Od Mishehu 13:50, 30 October 2017 (UTC)

• Hmmmm... There's a good point here. Maybe people who want to subscribe should just add a template to their page which transcludes the current version of the newsletter, plus whenever there's a new "edition" they would get a ping. (The template would add the user to a category, and everyone in that category gets the ping.) That's a very clean approach. EEng 19:39, 30 October 2017 (UTC)

• Brilliant. That would solve all problems. And it could include a link to an archive in one location that lists every issue so the hypothetical contributor who has been offline for ten months can spend a couple of days reading the past issues to see what they've missed. Johnuniq (talk) 22:10, 30 October 2017 (UTC)

Johnuniq, you know the Ways of the Pump better than I. Can you find the best way to make sure other participants in this RfC know about this? Perhaps WereSpielChequers will suspend this RfC in favor of a new one on this template idea -- we can always revive this discussion if the template idea fails. When you think about it, the template idea is way easier to implement, and with fewer design decisions to make (e.g. what counts as activity?). EEng 23:07, 30 October 2017 (UTC)

I see no need to abolish these entirely, but they might become redundant to Extension:Newsletter if installed. Sam Walton (talk) 23:15, 30 October 2017 (UTC)

Um, OK, well it seems unnecessarily complicate, but anyway why isn't it being used already? EEng 23:17, 30 October 2017 (UTC)

That extension looks insanely bureaucratic for the purposes of most Wikipedia newsletters, and I'd vehemently oppose any suggestion to roll it out across Wikipedia except possibly for a couple of high-traffic high-visibility newsletters like Signpost. As I read it there will be a separate set of admin-granted userrights for every single newsletter, and anyone wanting to contribute to a newsletter will need to persuade an admin to grant them the "publisher" userright for that specific newsletter—no sane person is going to want to jump through those hoops. ‑ Iridescent 23:29, 30 October 2017 (UTC)

mw:Extension:Newsletter#User Rights says that by default only admins can do things, but the extension would be customized for whatever was wanted at enwiki. For example, certain groups (say admins) could create or delete a newsletter, but other groups (say extendedconfirmed = 30 days/500 edits or autoconfirmed = 4 days/10 edits) could manage any newsletter. Johnuniq (talk) 03:19, 31 October 2017 (UTC)

• As a purely practical issue, assuming I'm understanding this proposal correctly as "if you want to subscribe to a newsletter, transclude it to your talkpage or a dedicated newsletter page in your userspace and you'll get a notification when it's updated", I can see a potential issue with Wikipedia's numerous phantom newsletters. Because of the tendency for people to get bored, a lot of newsletters get updated very infrequently—to take an extreme example, had this setup been in place previously all of these people would have had the December 2013 edition of the WikiProject London Transport newsletter sitting on their talk page for the last four years as nobody's bothered to put out a fresh issue since then. ‑ Iridescent 23:30, 30 October 2017 (UTC)

Well, then, after a while someone noticing that the LT newsletter is stale can just go move the "current" (way old) issue to the newsletter archives, making the current issue empty i.e. there's no current issue. EEng 00:28, 31 October 2017 (UTC)

Changing a transcluded template does not trigger echo notification. And why would you want to keep an old newletter on your page indefinitely - not knowing when it is going to be updated again? — xaosflux ^Talk 01:40, 31 October 2017 (UTC)

Re how the notification works, please read my proposal carefully, in the post starting "Hmmmmm." Re "indefintely", as also already explained, defunct newsletters can be blanked. EEng 02:37, 31 October 2017 (UTC)

@EEng: have you got a working demo of this? I just tried a quick and dirty and neither changing the transcluded page, or changing the category it include only'd had any echo notification to another account transcluding such page. (including after a force purge) — xaosflux ^Talk 04:01, 31 October 2017 (UTC)

I'm not making myself clear. A bot would walk the category and ping every user in it. I don't know if it's possible for a custom message to accompany a ping e.g. A new issue of the X newsletter is now available on your Talk page. Honestly, though, now that I think about it, why not then just ping people to the page where the newsletter itself is, and just skip the transclusion part? EEng 04:08, 31 October 2017 (UTC)

Ping them where (some random page?, the actual newletter template?) This also requires every single project with a newletter to get a bot to manage their newletters and MassMessage - is that what you are proposing? — xaosflux ^Talk 04:25, 31 October 2017 (UTC)

A bot delivers the newsletters now. In no way does this require "every single project with a newletter to get a bot to manage their newletters and MassMessage" – what are you talking about? A project that wants to use this very simple technique can do so, and everyone else can keep doing what they're doing if that's what they want. EEng 04:37, 31 October 2017 (UTC)

Hi @EEng: we must have a big disconnect in this scope - which "newsletters" are you referring to? I'm seeing this on VPR and thinking this is a proposal to change enwiki newletter processes in general - if any single project wants to change how their newletter wants to be managed, it doesn't need to be here, they can just do it. For reference, several newsletters on my own talk page were not "delivered by bots", whereas other things that are not "newletters" (such as SuggestBot suggestions) are actually delivered by bots and maybe unneeded clutter for departed editors. — xaosflux ^Talk 05:02, 31 October 2017 (UTC)

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

Um, an unsubst'ed template is exactly what I'm proposing. EEng 04:08, 31 October 2017 (UTC)

Where? --SmokeyJoe (talk) 04:57, 31 October 2017 (UTC)

A dozen posts up, starting with "Hmmmmm..." EEng 05:21, 31 October 2017 (UTC)

Unsubst'd templates/transclusions have the disadvantage of never notifying people that the template was changed. A new message on your talk page lights up your notifications; a change to a page that you're transcluding doesn't even put your talk page in your watchlist.

Iridescent, there's currently a live test of Extension:Newsletter at mw:Newsletter:Tech Showcase, and it really doesn't seem to be bureaucratic. User:Qgil-WMF could give you more information about the practical details, but as far as I can tell, he just tells it to send a page to everyone. It probably doesn't take him even 30 seconds to send the "newsletter".

@MZMcBride: People are talking about changes to MassMessage, so you might want to look this discussion over. Whatamidoing (WMF) (talk) 17:02, 8 November 2017 (UTC)

Whatamidoing (WMF) It's not the sending that's bureaucratic—unless I'm misreading the documentation completely, each newsletter will need to have its own bureaucratic structure with specific userrights for who can edit it and who can send it out. Thus, if I were to try to revive (for instance) the aforementioned moribund London Transport newsletter, I'd need to find out who was currently its admin (who may not even be active any more, given that the newsletter hasn't been published since 2013), persuade them to grant me the editor right for that newsletter, persuade them to grant the editor right for anyone else I wanted to approach to contribute to it, and then persuade them to send it out or grant me the right to send it out. The sort of people who have time and inclination to jump through that many hoops aren't the sort of people who are likely to have anything very interesting to say. ‑ Iridescent 18:41, 8 November 2017 (UTC)

Having glanced at the documentation, I think that any admin (i.e., anyone on the list at Special:ListAdmins) can grant you the right to send out any newsletter. ("Editing" a newsletter is just a matter of editing a normal page.) Whatamidoing (WMF) (talk) 04:47, 9 November 2017 (UTC)

Iridescent, Whatamidoing (WMF), Johnuniq Hi, mw:Extension:Newsletter was designed with minimalism in mind. The permission to create newsletters is currently set to admins in MediaWiki.org because it is a new extension and we wanted to see it being used by real publishers without risking types of abuse that we hadn't think of. It can be configured to any user group. I personally think that newsletter account creation can be permissive, because the potential damage is directly proportional to the number of subscribers, and a publisher will only get subscribers if the newsletter is interesting, not some kind of spam. Once the newsletter has been created and a publisher has been assigned to it, the publishers of that newsletter can add/remove other publishers themselves. I don't think you can have it simpler than that. For what is worth, the Newsletter extension is not being deployed to other Wikimedia wikis as long as interwiki support is not resolved (phab:T110645). Qgil-WMF (talk) 10:54, 9 November 2017 (UTC)

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

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

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

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

Newspaper deliverers to remove old newspapers still on the driveway

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

  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)

  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)

  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)

  In that case, would a link to the stored source would suffice? Iggynelix (talk) 21:31, 28 November 2017 (UTC)

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

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

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

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

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

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

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

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

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

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

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

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

To summarize so far, we have several options:

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

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

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)

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

A {{Find sources}} on every draft could only be helpful.

Basic information that would also be very helpful includes:

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

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

Discussion (Draft Header Template)

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

Proposal for a better article assessment process

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

New article assessment ratings?

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

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

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

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

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

Category and categories: equivalence needed

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

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

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

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

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

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

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)

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 end net neutrality rules in the United States and reclassify broadband Internet access as an ‘information service’ under the Communications Act of 1934. This move will end rules that prevent broadband providers from blocking sites, slowing or speeding up certain services, or charging sites and users new fees for privileged “fast lane” access. The impacts on donation-supported access to knowledge projects like Wikipedia could be significant.

The agency’s December 14th vote will remove the legal foundation for enforcing net neutrality through reclassification, 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 unprotected from anti-competitive traffic management practices used by the country’s largest ISPs.

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.

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:

• Should the Wikipedia community join the December 12th ‘Break the Internet’ day of action?
• 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)?
• What would be a creative way to “break” Wikipedia for a day and garner public attention?