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 on Wikipedia:Village pump (idea lab).
• Proposed software changes should be filed at Phabricator (configuration changes should have gained a consensus).
• Proposed policy changes belong at Wikipedia: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, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175, 176, 177, 178, 179, 180, 181, 182, 183, 184, 185, 186, 187, 188, 189, 190, 191, 192, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211

RfC: Proposal to add global JavaScript and redirect all IRC help links through a disclaimer page

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

---

Propose moving User:PhantomTech/sandbox/IRC Disclaimer to Wikipedia:IRC help disclaimer and redirecting all links that connect users to the #wikipedia-en-help channel to Wikipedia:IRC help disclaimer in addition to adding the script at User:PhantomTech/Scripts/IRCNick.js to MediaWiki:Common.js. PHANTOMTECH (talk) 04:02, 12 April 2015 (UTC)

Details: There are currently several problems with the IRC help channel, a few of those problems are that people often ask the same questions and that helpers sometimes have issues helping people because of the nicks they're given. Right now, almost all links give the default nick "WPhelp" with a nice long number at the end. As this post points out, this not only causes issues for people trying to help but also the people being helped. The proposal aims to cut down on the number of repeated questions (though not everyone may read the page) and give user's a friendlier IRC nick by default. Not all issues with the help channel are solved by this but it is a pretty simple modification that can solve one of the bigger issues. Currently, the script picks nicks in the following way:

• Users who do not support javascript fallback to using one of the current "WPhelp" nicks
• If the user is logged in, their nick is the first 11 characters of their username with anything non-alphanumeric characters replaced with an underscore and "-WP##" added to the end, where ## is a two digit number unless the username has 4 or more characters replaced with an underscore, then the next option is used.
• All other users are given a username that starts with a random color with "-WP###" added to the end, where ### is a three digit number. Colors are used because they are the least likely to offend people.

Example: Someone whose username is User might get the nick User-WP42, someone with the username Full.Stop might get the username Full_Stop-WP20 and someone who is not logged in might get the username blue-WP493. Note, "might" is used because the numbers at the end of the usernames are chosen randomly and the color in the last example is also chosen randomly. Feel free to ask for any clarification or any more examples, the script can be tested by following instructions at the top of the page at User:PhantomTech/sandbox/IRC Disclaimer to see what nick you would be given. PHANTOMTECH (talk) 04:02, 12 April 2015 (UTC)

Cross posted to WikiProject AFC, Teahouse and the help desk. PHANTOMTECH (talk) 16:54, 15 April 2015 (UTC)

• OpposeSee explanation below the disclaimer as written, could support it with some heavy revision. Oppose adding such a script to Common.js as that is not the appropriate place for such a thing. I could see a nick picker added to an on by default gadget though (such as the Teahouse Ask a Question script), and I would support such a suggestion. — {{U|Technical 13}} (e • t • c) 15:41, 13 April 2015 (UTC)

Could you be more specific about what you think is wrong with the disclaimer? I have no issue making this a default gadget instead of something in common.js, assuming that default gadgets are enabled for IP users. PHANTOMTECH (talk) 19:44, 13 April 2015 (UTC)

• Full support. I'm not commenting on implementation as a default-on gadget or as an addition to common.js, but whatever is according to convention is fine by me. --L235 (t / c / ping in reply) 16:35, 13 April 2015 (UTC)
• Support. Because it's nice to give people some context around the Freenode webchat interface, and the username consistency is a nice touch. But I think that it's unnecessary and unhelpful to tell questioners to RTFM before asking. I'd strongly prefer that language be removed if you plan to implement this for the Teahouse IRC channel (TH is the anti-RTFM). That said, no one uses the TH IRC channel anyway, so it's basically a non-issue. Cheers, - J-Mo ^{Talk to Me} _{Email Me}
  • Yeah, I don't see new editors in there often, but I'm pretty sure that is because -en-help is what is linked to from the THQ page and the only one ever mentioned. That kind of makes -en-help the Teahouse channel also, which suggests that it should be the anti-RTFM as well. — {{U|Technical 13}} (e • t • c) 16:41, 16 April 2015 (UTC)
• Support. Great solution and implementation. APerson (talk!) 03:29, 17 April 2015 (UTC)
• So...you want to provide people with a link that will very easily associate their username with their IP address? Legoktm (talk) 03:39, 17 April 2015 (UTC)

@Legoktm: Yes, but not much more than is already done. The script doesn't force the username on them, it just prefills it so they do still have the option to change it if they wish. As it is, people are already associating their username with their IPs, probably without knowing it. One of the first questions people tend to be asked are "What's your username" or "What article/draft" so that they can be helped easier, while the last one isn't direct, it isn't hard to figure out their username from a draft with one contributor and IRC gives us their IP when they join. With this solution, the association is more automated but there's a warning for anyone who's unfamiliar with IRC, something that doesn't exist right now. PHANTOMTECH (talk) 16:50, 17 April 2015 (UTC)

• Support - I think it works well, it's cool, and provides a central place to link all of IRC to. We need a disclaimer talking about IP addresses anyway, and some of the other stuff is also pretty useful. Am not opposed to revising the disclaimer in a way that Technical 13 is happy with. — kikichugirl ^oh hello! 17:02, 20 April 2015 (UTC)
• Support, although I would avoid unnecessary jargon (like "IP" instead of "IP Address", "IRC" without any explanation, "FAQ" instead of "Frequently Asked Questions", and "#Wikipedia-en-help") in the green box. I mocked up a more "noob friendly" version of the green box at User:Ahecht/sandbox/IRC_Disclaimer --Ahecht (TALK
  PAGE) 17:18, 20 April 2015 (UTC)

@Ahecht: Feel free to merge your changes into my sandbox, your version does seem more user friendly. PHANTOMTECH (talk) 20:09, 20 April 2015 (UTC)

• I've trimmed the code and made it HTML5 compliant. That works fine for me. As for the IRC nicks, I've added another option that both addresses the WPHelp/Guest issue and the anonymous issue that Legoktm brought up here. — {{U|Technical 13}} (e • t • c) 20:30, 20 April 2015 (UTC)

• Assuming this isn't closed yet, I'd like to say it sounds like a good idea. I'm not sure why something odd involving revision IDs has been implemented instead. That seems like a creepy way to find out what someone's draft is; better to just have their username, and the -WP### thing is a good workaround for registered nicks. ekips39❦talk 01:54, 28 April 2015 (UTC)
• Strongly oppose forcing additional global JavaScript on every user on the encyclopedia for something that will not work most of the time due to the IRC naming restrictions which limits nicks to 16 alphanumeric characters, plus underscore, hyphen, and pipe, where the first character must be a letter. Many of the people who come to help in the channel are IP editors, so the script wouldn't work for them (can't start with a number or include a period), many of the editors with accounts I've found to have non-latin usernames (Múññå ShÈœhzÄdå), start with a number (2-Door), or include disallowed punctuation (Dermont~enwiki or As'ad A R).

Also, the current scheme for nicks is being misrepresented (as it was modified per consensus yesterday). WPHelp usernames have been deprecated in favor of nicks that offer the helper a starting point for where to help the person that is showing up for help. Quite often, people don't know how to link their draft, don't have a username, can't point the helper to their draft or question, and those people get sent away with "Sorry, you can't be helped, go away and come back when you get a clue", this damages editor retention. Currently, all of the templates give the status of the draft or a single letter indicator and the revision id of the page they came from which allows helpers to help those people who would otherwise be unable to be helped increasing friendliness and improving editor retention.

This proposal to take away the links to IRC from drafts (you have to navigate through a separate page adding to frustration of "can't I just please get some help?"), adds global JavaScript bloat to Common.js (using code that isn't compliant with WMF standards for a gadget no less). I know I suck at explaining things, but this community just made me the Editor of the week for being "a strong voice of the technically-oriented editors", and I hope that says something to some of you that my goal here is to protect the wiki from the damage this highly technical proposal will cause. — {{U|Technical 13}} (e • t • c) 19:23, 28 April 2015 (UTC)

With respect; Technical 13, posting two times with two separate bullet points, with bolded votes for each, is misleading. And I say the following as the person who wrote the nomination statement for your being awarded Editor of the Week: EotW should definitely not be cited in a community discussion as anything that would influence anything. Thanks, --L235 (t / c / ping in reply) 04:10, 29 April 2015 (UTC)

@Technical 13: Not sure why you decided to !vote twice instead of just expanding on your original post or why you felt the need to add so much formatting to your "strong oppose" but guess I should start replying to your points. I don't know what you're talking about with there being problems with IP users, you read the proposal right? I even explained to you in IRC earlier that anonymous users are accounted for by the script with colors instead of trying to use their nonexistent username. Usernames that can't be used as nicks are also accounted for, and again that's explained in the proposal, non alphanumerical characters are replaces with underscores and there's a fallback to colors if too many characters are replaced. You mentioned that there are a lot of users who have usernames that would create a problem, you don't by any chance have any statistics to back that up do you? Sorry for "misrepresenting" the nicks, as you pointed out it was changed after this proposal was made, you wouldn't mind pointing to where the consensus for the change was by the way? It doesn't seem like there was any. Again for the point about people unable to point to their draft or whatever they need help with, could you provide some statistics that show how many people have this problem, excluding anyone that wouldn't have the problem as a result of this proposal? Even if there is no consensus for this proposal, the current (new) system has to be replaced, it appears to have been implemented without any consensus and is a major privacy issue, it uses what looks to users like a random number to effectively link usernames to IP addresses.
As a side note related to your EOTW message, it seems that to say the "community" made you editor of the week is a gross misrepresentation since it looks like only a very small number of users participated in the discussion. Additionally, it seems somewhat dishonest and petty to advertise yourself in this way. There are editors who are familiar with you, these editors have their own opinions of your skills, how much you should be trusted, etc. so to them this is pointless. What you have left are the editors who aren't, for whatever reason, familiar with you and may not be familiar with EOTW, presenting this information to them creates an unnecessary bias in the same way one would be created if sysops advertised their admin status on their replies and it is for these reasons that they don't. It is possible that your concerns are valid however it is counterproductive to say "this code isn't formatted right, let's just throw out the idea, trust me." Surely it would be trivial for someone with the technical expertise you seem to claim to have to make the code compliant with whatever standards it may have an issue with and it doesn't help that you explicitly said that you would support a nick picking gadget in your original oppose !vote. PHANTOMTECH (talk) 04:37, 29 April 2015 (UTC)

Agreed. I wrote something similar but it wasn't as good and didn't add much, so I won't bother posting all of it. I did have a couple of additional points, though: I haven't seen people turned away for the reasons T13 gives, and many people come in with custom nicks, which defeats the purpose of the revision ID nicks. ekips39❦talk 04:43, 29 April 2015 (UTC)

• I struck the above !vote with a note to see down here. It would have been inappropriate to add that much text indented above, and you would have accused me of trying to sneak it in there like last time. So, I added it down here. I very much think that adding JavaScript code to compromise editors privacy and security is a big deal, especially when the code is as badly flawed as it is from a technical standpoint. Also, since the title for this section is very deceitful, I've reworded it to be appropriate. — {{U|Technical 13}} (e • t • c) 14:19, 29 April 2015 (UTC)

• Interesting new title. The proposal is about the help channel, not all IRC links (how would we add a disclaimer to all IRC links, anyway?), and "proposal to add global JavaScript" sounds as if we didn't have any global javascript before. I think the previous title was less misleading, though it's worth including something about the nick bits, I suppose. Something that makes clear what the purpose of the global javascript is. Can't think of a way to say it that doesn't sound too long-winded. Also, that's not what the javascript will be doing, but this has been explained at length... ekips39❦talk 23:17, 29 April 2015 (UTC)

• @Ekips39: I've edited the title to make it more accurate. Also, still not buying Technical 13's objections, seeing as PhantomTech clearly explains that their script would fix all of the alphanumeric character problems. The current revid usage is also a potential privacy issue as someone mentioned somewhere in this textwall... — kikichugirl ^oh hello! 18:23, 30 April 2015 (UTC)
  • While the current revid usage is not a privacy issue as it only connects any IP/person that can view a draft to the draft, this proposal is certainly a privacy issue as it directly connects a username to an IP and in doing so outs the user. — {{U|Technical 13}} (e • t • c) 03:07, 7 May 2015 (UTC)
    • The disclaimer is meant to solve that problem. It warns you that it will reveal your IP. If you willingly enter the room anyway, then you willingly disclose it and connect it to your username. The RevId, done without consensus, does not clearly state that it is a privacy issue at all, or even that an IP will be revealed. — kikichugirl ^oh hello! 03:38, 7 May 2015 (UTC)
    • It is a safe assumption to say that a user who joins the IRC help channel from a draft link is the major, or usually only, contributor, and your original mention of the current system seems to recognize this lack of anonymity by stating that the extent to which their anonymity is important is limited to anonymity perceived by the helpee. There is no worse level of anonymity than near complete transparency which is disguised as anonymity, and, by using what looks like a random number, that is exactly what the current system does. By using usernames, users are fully aware of the information they are sharing and free to change it prior to connecting. PHANTOMTECH (talk) 04:00, 7 May 2015 (UTC)

• Support the disclaimer. I've always thought editors connecting to the help channel were insufficiently warned that their IP would be revealed. As they would need to take further steps to identify the IP with an on-wiki account, it wasn't a huge deal, but did make me a bit uncomfortable. The current implementation has made the issue much more severe. Now, the default nick you enter IRC with, ties your session back to a revision of the page you came from, which in most cases, means that your IP which was already visible on IRC, can with a reasonable certainty, be tied directly back to your account here. In my view, in the absence of a clear notification to the user that this will be possible, this is a violation of the foundation privacy policy. I would actually go a bit further, and explicitly state that it will be possible to connect the IP and username by connecting. We may also want to ask someone from foundation legal whether they feel the language provides sufficient warning about what is going to be revealed. (As an aside, I think many people are unreasonably sensitive about revealing IP information, but the community has decided to respect their concerns, and so we should be consistent) Monty₈₄₅ 14:37, 29 April 2015 (UTC)
• Support the disclaimer for that channel. Not sure if I can get behind adding that script to common.js. We should also all be aware that adding an interstitial page between the IRC link and the channel will cause fewer people to actually go to the channel to get help. On balance that's probably ok (given that inadvertently revealing your IP can cause actual harm), but it's a likely consequence. Protonk (talk) 00:13, 8 May 2015 (UTC)

@Protonk: Would you support adding the script as a default gadget instead of to common.js? PHANTOMTECH (talk) 01:06, 8 May 2015 (UTC)

Well, I don't know. First, if we're going to mangle the usernames to fit them into IRC (and de-dupe, I'm assuming?) why not just assign a random name? Protonk (talk) 01:15, 8 May 2015 (UTC)

• Why not have the nick be a direct link to the page the helpee wants help with so they don't have to be sent away without any help because of language or technological barriers? (that's what it currently is now btw, a status indicator and a revid number so the helper can actually help the helpee). — {{U|Technical 13}} (e • t • c) 01:49, 8 May 2015 (UTC)

@Protonk: Usernames make it easier for helpers to find the information they need to help helpees, a random name (color, since some names could be considered offensive) is assigned to IPs. @Technical 13: Usernames don't look like a random number, so helpees know what information the nick contains, and revids don't solve the problem of making it easy to tell helpees apart that both helpers and helpees have. PHANTOMTECH (talk) 02:04, 8 May 2015 (UTC)

That sounds reasonable. I'll take another look at the code. Protonk (talk) 02:25, 8 May 2015 (UTC)

. I'm onboard with the code now. I'm still skeptical that we want to mangle the usernames in the first place especially imagining a long username truncated and with some "_"'s added could be worse than a random one in a lot of cases. Protonk (talk) 16:55, 14 May 2015 (UTC)

I agree that having to edit usernames at all isn't ideal and that usernames can exist that would be better off just being random but I don't think they'll be too common. I think most of the time a username gets changed it will still be useable, but I'm usually in the live help channel so if I'm wrong, I should notice and be able to modify the script. PHANTOMTECH (talk) 17:57, 14 May 2015 (UTC)

• Oppose Both especially oppose the JavaScript. I hate to say it but JavaScript is a security flaw and a bunch of issues waiting to happen. And the other point, I don't think linking users to yet another page is going to help. When I was new, all I wanted was to actually converse with a real person, not get sent round in circles in Help: pages and Wikipedia: pages... I also want to point out that anyone editing from an IP probably knows their IP is being thrown around (should we add more disclaimers to that -_-) and in general Wikipedia isn't "private or one on one". In my opinion it would make more sense to add a small something to the IRC chat page, like it already has. "Hi there, WPhelp44410...other crap...Replies could take several minutes. If you are asking about a particular page, please provide a link and/or your on-wiki username to make it easier for our volunteers to assist you. " Makes more sense to just toss something on there, instead of routing users away from help and to more useless FAQ's and Instruction pages. EoRdE6^{(Come Talk to Me!)} 01:27, 14 May 2015 (UTC)

Wikipedia already uses JavaScript, what additional security flaws and issues would this script introduce? The disclaimer warns about linking usernames to IPs, not IPs to IPs. Adding a disclaimer inside the IRC channel is like not letting someone read a contract until after they sign, it's too late at that point. PHANTOMTECH (talk) 06:18, 14 May 2015 (UTC)

The issue with "anyone editing from an IP probably knows their IP is being thrown around" is that it doesn't matter if they're logged in or not, if you join the IRC channel your IP is visible unless you have a cloak (which 99.9% of helpees don't). Sam Walton (talk) 08:59, 14 May 2015 (UTC)

• Oppose the JavaScript because people don't read the small print (or the big print, for that matter), and will unwittingly link their IP with their account without meaning to. Support a disclaimer which warns users of the possibility, though not all will take notice, per Monty. Alakzi (talk) 01:49, 14 May 2015 (UTC)

I've said this before somewhere above but there's a lot there now so, people already unknowingly link their IP to their account when they say what draft or whatever they need help with, (or while the current revid system is in place, just by joining) using usernames as the default makes autocompleting nicks easier, is less confusing for helpers/helpees and can help helpers help helpees faster. PHANTOMTECH (talk) 06:18, 14 May 2015 (UTC)

• Unarchived, waiting for formal close. PHANTOMTECH (talk) 07:42, 22 May 2015 (UTC) New timestamp for archive bot PHANTOMTECH (talk) 05:08, 28 May 2015 (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.

Soften the notification number

Tracked in Phabricator
Task T57359

Tracked in Phabricator
Task T58476

Tracked in Phabricator
Task T94634

Surprisingly, I don't find this in our drop-the-stick list.

Despite exhortations in the guidelines, many editors experience an adrenaline spike when they get reverted, and this makes it that much more difficult to stay calm in one's reaction to the revert. This would seem to increase the frequency and severity of edit wars. Considering the known psychological effects of different colors, would it not make sense to use a soft blue or soft green, instead of a bright red, for the background around the notification number? I think we're waving a red cape in front of a human bull in many cases, if not most. ―Mandruss ☎ 13:33, 15 April 2015 (UTC)

For reference, the current colour is  #BD2400 . EoRdE6^{(Come Talk to Me!)} 21:42, 16 April 2015 (UTC)

I agree that the big red square looks too much like an error message (or the more severe warning messages that we place on talk pages). I would completely support a blue to match, for example, or, as a compromise, an orange to match . --Ahecht (TALK
PAGE) 15:10, 15 April 2015 (UTC)

It's hard to think of something which, though likely of very minor value (though maybe not...) would be so easy to try and ought to be uncontroversial. But watch -- someone will argue against it. EEng (talk) 16:07, 15 April 2015 (UTC)

I'll revise my suggestions slightly:  #00528C  to match the bullets in the watchlist or  #F9C557  to match the "You have new messages" background. --Ahecht (TALK
PAGE) 20:45, 15 April 2015 (UTC)

See WP:BIKESHED. That's my last comment on the importance of this issue. --Jayron32 16:14, 15 April 2015 (UTC)

Since the nuclear power plant has already been built, there's no reason why we shouldn't have a nice bike shed there. I'm sure my blood pressure goes up when I get a notification; a blue like Ahecht suggested above might decrease the stress a little.  SchreiberBike | ⌨  16:24, 15 April 2015 (UTC)

It's only BIKESHED if people fuss over this obviously sensible, harmless change. It's a good idea and we should do it. EEng (talk) 16:33, 15 April 2015 (UTC)

I'm honestly not buying it. In any case, blue would blend in too well with the existing personal bar links, so orange should be used at a minimum from Mandruss' suggestions. BethNaught (talk) 16:36, 15 April 2015 (UTC)

Purple's a nice cool color. EEng (talk) 16:47, 15 April 2015 (UTC)

I think multicoloured would be quite nice. Trout71 (talk) 17:08, 15 April 2015 (UTC)

• Support but only if the colour is #a5427e, and if colour is spelled with the u. If you keep it the same or change it to any other shade of any colour or spell it without the u, I will take it to WP:ANI. Seriously, though, it's a reasonable idea, and any of the suggested colours would be fine. Ivanvector (talk) 18:38, 15 April 2015 (UTC) The u is kinda important though.
• Support changing the color without the u - I do think that a bright red is too likely to cause edit wars, or make them more severe. עוד מישהו Od Mishehu 19:58, 15 April 2015 (UTC)
• Support in particular green. Most of my notification list is thanks, or the occasional notice that I've been mentioned somewhere, but the red does seem more like an error message than anything. Jerod Lycett (talk) 20:00, 15 April 2015 (UTC)

Something like the  #008560  used by {{tq}}  #008740  used in the flow logo? I kind of like that. --Ahecht (TALK
PAGE) 22:18, 16 April 2015 (UTC)

• Support in particular orange, as the old message bar. Red works for alerts on less disputatious sites, but not here. NebY (talk) 20:36, 15 April 2015 (UTC)
• I'm not sure I agree that this will accomplish anything, but I certainly don't see any harm or reason to object to it. Beeblebrox (talk) 22:40, 15 April 2015 (UTC)
• Support Green or (if green doesn't pass) orange or (as mentioned above) purple. Really, any cool, calm, not-red color. EEng (talk) 19:44, 16 April 2015 (UTC)
• Alternative but support for the idea in principle even if it is a marginal gain), There was an education study done that showed Green is a much better colour for teachers making HW/Tests based on the effects on students, so perhaps Green is better? --- :D Derry Adama (talk) 20:31, 16 April 2015 (UTC)
• Support I like the  #F9C557  so it doesn't just blend in with the rest of the blue interface and links. Maybe toning down the wording would help too, currently it says "Your edit on [page] has been reverted by [user]. (Show changes)". I think maybe something like "Your edit on [page] has been undone by [user]. (Show changes)". What do you think? EoRdE6^{(Come Talk to Me!)} 21:19, 16 April 2015 (UTC)

Maybe change the word revert to pervert, so it says "Your edit on [page] has been perverted by [user]. (Show perversions)". EEng (talk) 22:14, 16 April 2015 (UTC)

• Comment - I really think soft (pale) is important here, as important as not red. Most of these examples are hard. We only need enough contrast that a notification won't be easy to miss. I'd gladly offer a suggestion or two, but I'm not very handy with color pickers. ―Mandruss ☎ 23:03, 16 April 2015 (UTC)
• Support  #F9C557  per Ahecht and EoRdE6. I've always found  #BD2400  a bit off-putting, but any change can't come too close to the text color, as I would expect matching File:Information.svg might. —ATinySliver/^ATalkPage 23:16, 16 April 2015 (UTC)
• Support in principle; I've thought the same before. I'm not convinced of the usability of the colours that've been proposed. Alakzi (talk) 23:28, 16 April 2015 (UTC)
• Changing the color to a less noticeable color could be problematic. If a new user making problematic edits doesn't notice that they have a message, you have a situation where they keep on doing whatever it is without knowing that they're doing anything wrong. A softer color is less likely to elicit a click. --Yair rand (talk) 00:44, 17 April 2015 (UTC)

Messages on talk pages don't leave a mere notification number; there's accompanying text as well—which, I should note, uses #F9C557 or something virtually identical. —ATinySliver/^ATalkPage 00:47, 17 April 2015 (UTC)

• Oppose, getting an adrenaline spike if you are reverted is exactly as it should be, unless you're a spammer or vandal expecting reverts. –Be..anyone (talk) 01:31, 17 April 2015 (UTC)
  • Why should it be that way? Alakzi (talk) 01:33, 17 April 2015 (UTC)

Agreed. One could argue the converse: "not getting an adrenaline spike if you are reverted is exactly as it should be, unless you're planning to go revert the reversion(s)." —ATinySliver/^ATalkPage 04:20, 17 April 2015 (UTC)

Adrenaline spikes are rarely a good thing, at Wikipedia or anywhere else, as they hinder the ability to think clearly and calmly. They evolved to aid escape (run like hell!) or defense (fight like hell!) when in danger. So I'm afraid you've lost me there, Be..anyone. ―Mandruss ☎

• Support Comment - I like paler, and "You have new messages" could be changed to match. #8EED9D and #CBBAE8:  1   You have new messages   1   You have new messages  ―Mandruss ☎ 11:37, 17 April 2015 (UTC)
• Support. Looks popular, and assuming it remains so the next step would be picking the particular color. If no consensus emerges here I'd suggest showing examples of various colors and asking people to pick their 1st-2nd-3rd choices. Herostratus (talk) 11:30, 17 April 2015 (UTC)
• Oppose I would like to point out the fact that red is the notification color of choice of almost all major websites when it comes to small size indicators. By diverging from that, we isolate ourselves from a common well understood paradigm for users. We also diverge from mainline MediaWiki software, giving users a different experience throughout the WMF properties (just at a time where we finally have brought all the accounts together), which seems unwise to me, and we aren't measuring the effect of all this in any sort of scientific responsible way, which I also think is the WRONG way to make decisions like these. Perhaps the textual messaging is the problem here, and not the color of the notification indicator. Perhaps we should just disable that type of notification. Why is no one asking those questions ? —TheDJ (talk • contribs) 11:48, 17 April 2015 (UTC)

I don't know, but perhaps they could be asked separately without doing damage to Wikipedia? Must the scope of these things always be inflated to the point where no consensus is possible on anything? ―Mandruss ☎ 11:57, 17 April 2015 (UTC)

• Support go with Blue , Blue is good lightsaber, red is bad light saber. Bryce Carmony (talk) 17:36, 17 April 2015 (UTC)
• Support: change to dark blue or dark green matching below if possible, but nonetheless a less irate colour. 1Potato2Potato3Potato4 (talk) 10:43, 19 April 2015 (UTC)
• Note - added column nC and proposal 7. ―Mandruss ☎ 11:54, 19 April 2015 (UTC)
• Support Ahh, this would explain my road rage at traffic lights. I'm fine with any softer shade, but prefer  #F9C557  despite (not because) it matches my sig. --RacerX¹¹ Talk to me^{Stalk me} 12:33, 19 April 2015 (UTC)
• Support. Although I'd much rather have a complete reskinning and modernization of Wikipedia's design (and a dark theme already, my eyes hurt!), I suppose this color change would help. Whenever I see the alert, I'm worried I messed up and someone's alerting me of it. Maybe this is due in part to the color itself. In any case, the red color certainly alerts me, but can do so to the point that it's distracting. A different color may benefit us, even if it comes at the expense of decreased conspicuity. ―Nøkkenbuer (talk • contribs) 13:46, 19 April 2015 (UTC)
• Note - added proposals 8, 9, and 10, per Nøkkenbuer's comments in the next section. ―Mandruss ☎ 14:03, 19 April 2015 (UTC)
• Comment – Would it be possible to make this customizable or something similar? With this many choices below, I have some doubts that any majority agreement will be reached. Dustin (talk) 15:55, 19 April 2015 (UTC)

  That's why I tentatively suggested two rounds of voting in the following subsection. Customization would be a bigger software job and thus harder to pass. Even if passed here, it would likely wait longer in the developer priority queue. I'd prefer to keep this proposal at its current size, but you're welcome to make your own separate proposal. ―Mandruss ☎ 16:01, 19 April 2015 (UTC)

• Comment – I think we should consider not using colors but instead a black and white pattern. Bus stop (talk) 16:31, 19 April 2015 (UTC)

The problem with that is that I doubt many would notice it. The color is intended to draw attention to the notification, since it is a notification. Black-and-white is probably the least noticeable color scheme we could use in this situation. ―Nøkkenbuer (talk • contribs) 18:06, 19 April 2015 (UTC)

Some patterns such as polka dots with intersecting sine waves rendered in black and white are very recognizable without color. Bus stop (talk) 19:28, 19 April 2015 (UTC)

• Support I think it's, at the very least, worth trialling some different colours, red does seem too 'You've done something wrong' and not enough 'here's a notice of something you'll likely be interested to know about'. Not sure on the particular colour, none of the options below grab me straight away, but I also support the idea of collecting colours and voting a few favourites through to a new poll if there is support for change. Sam Walton (talk) 18:21, 19 April 2015 (UTC)
• Oppose. I prefer the red because it stands out. It's also a color widely used for notifications online and on platforms such as the iPhone. Perhaps we should let individual users pick their own preferences. Calidum T|C 21:49, 19 April 2015 (UTC)
• Oppose - it needs to be bright to catch the attention, and as others have pointed out it's consistent with other systems. No objection if it's made a user choice, as long as I can keep red. JohnCD (talk) 22:08, 19 April 2015 (UTC)

That's actually a good idea; an option within each editor's preferences to change the color to his/her own liking, as noted above, "bigger software job" notwithstanding. —ATinySliver/^ATalkPage 22:21, 19 April 2015 (UTC)

This is possible to do manually now. It has been suggested at least a couple of times before, in 2013 and 2014, and both discussions include simple solutions using CSS, which are being used already by editors.--JohnBlackburne^words_deeds 10:31, 20 April 2015 (UTC)

Much obliged! Just created the appropriate page in meta; works perfectly. —ATinySliver/^ATalkPage 19:59, 20 April 2015 (UTC)

@JohnBlackburne: except I can't figure out how to change the "you have new messages" text color. Clearly, I'm not a coder. —ATinySliver/^ATalkPage 01:26, 21 April 2015 (UTC)

See Quiddity (WMF)'s post at the very end of this section (not sub-section), it has CSS for both.--JohnBlackburne^words_deeds 01:43, 21 April 2015 (UTC)

It doesn't work right at Meta; there's a parameter missing or something ... —ATinySliver/^ATalkPage 01:52, 21 April 2015 (UTC)

See the opening post and the first three comments at #Wouldn't this be better as a new preferences option?. The original intent of this proposal has very little to do with personal preferences. If we've segued into that area, I'd gently suggest that we're off topic. Also see some (I think) interesting discussion at the beginning of #Colo(u)r nominations. ―Mandruss ☎ 14:11, 21 April 2015 (UTC)

• Support as proposer, and I think a proposer should have a lot to say about what is being proposed. Others are free to make their own separate proposals. Besides, I once suggested modifying someone else's proposal after some !voting had occurred, in response to Opposers' concerns, and that was not allowed because it would have required all existing !votes to be discarded (or at least re-evaluated by the respective !voters, many of whom were no longer involved in the discussion). This looks like the same situation to me. (meta: It astounds me that, after 14 years, en-Wikipedia has yet to establish clear ground rules for orderly processes. We do love the chaos, frustration, and wasted time, it seems.) ―Mandruss ☎ 09:45, 20 April 2015 (UTC)

[meta]: We do have clear ground rules for the orderly process by which decisions are made on Wikipedia. They are here: Wikipedia:Consensus. The problem with the process described below is it does not seem designed to establish consensus – or at least it is not mentioned at any point – and seems flawed in a number of ways. The result of a poll is no substitution for discussion, but that seems to be what’s being proposed below (though "Details will be determined later". how? By a further "vote"? By discussion? By proposer fiat?). Normally a higher degree of consensus is required for changes to policies than e.g. for content discussions, and if anything an even higher one for changes to the Mediawiki software. In this case because this is part of the software on all Wikipedias if it needs changing it needs changing globally, for consistency, not locally, but that cannot be done here.--JohnBlackburne^words_deeds 11:29, 20 April 2015 (UTC)

Arguments have been presented in this subsection, per WP:CONSENSUS. If the Opposes win, the color selection is moot, but that doesn't mean we can't proceed with the color selection anyway. Besides, one's Support or Oppose might depend on what colors have been presented as alternatives to the status quo, no? Isn't that what you said yesterday? In that sense, color selection might be viewed as prerequisite to !voting. I can't imagine how one would argue for one color choice over another, beyond saying that they find it more visually appealing, so that part is properly a vote, not a !vote.

"Details will be determined later" refers to the specific details of the color selection voting process. There are at least two ways that could go that I believe would be sufficiently fair and accurate for this purpose (we're not electing a president here). Yes, I intended to simply choose one, and I think "proposer fiat" is hyperbolic. If people wish to spend time debating those details, fine, and that will tend to validate claims of BIKESHED in this matter. It will also introduce another opportunity to stall the process and derail the entire proposal, due to lack of a sub-consensus. ―Mandruss ☎ 11:54, 20 April 2015 (UTC)

I had to look up WP:BIKESHED, an essay I had not had reason to look at before. "Don't get hung up on minor details." That would describe the premiss of this yes, a minor interface details that editors can easily fix for themselves. But lack of consensus is not a minor detail. WP:Consensus is a core policy, Wikipedia is not a democracy and holding a vote on this is the wrong way to go about it.--JohnBlackburne^words_deeds 14:38, 20 April 2015 (UTC)

As I said, consensus applies in this subsection. I don't know that WP:CONSENSUS implies that we have to establish consensus for every detail of the process. I'll revise my comments, as this is an argument for a color choice. Nonetheless, I don't know how a closer would decide between multiple viable arguments as to color — such arguments can't be policy-based —, so that part would end up an effective vote anyway. I'm interested in other opinions on this, but I'm for voting on the color and !voting on the proposal, just for sake of simple expediency. Let's not overthink something that several experienced editors have criticized as BIKESHED. In the end, it's about whether the bright orange-red is the best choice or not for the notification number; the rest is minutiae. ―Mandruss ☎ 14:49, 20 April 2015 (UTC)

Alternatively, you could volunteer to design this process, in detail, the way you think it should be done. Give us something specific. Someone has to attend to these details; it's not enough to make the general observation that "things should be done by consensus" and expect the process to proceed to a resolution without some structure. ―Mandruss ☎ 15:16, 20 April 2015 (UTC)

This: come up with a proposal for the new colours, with a rationale for your choice, considering as many of the factors and objections that you can, including the many times it has been raised before. Then post it here as a proposal, and see if there is consensus for the change. A simple, one step process based on consensus.--JohnBlackburne^words_deeds 15:53, 20 April 2015 (UTC)

I see. So the problem is that my proposal was not specific enough. And we're to assume that it will be either up or down on that specific proposal, with no suggestions for modification? ―Mandruss ☎ 16:03, 20 April 2015 (UTC)

(edit conflict)See this, then, as an open and largely co-operative process of forming a single proposal for a new colour scheme, or as a consultation stage, if you prefer a more top-down model. NebY (talk) 16:12, 20 April 2015 (UTC)

One or two of us are making a more serious issue of this than the vast majority appear to. I'm not inclined to put together the full-blown legal case that JohnBlackburne requires, for a little color change. Here at Wikipedia, no question can be too small to argue for weeks or months about, only to fail for lack of clear consensus (see another recent example). I hope the majority will speak up and express their opposition to this approach; absent that, I think I'm done here and this can be closed or continued in whatever direction the remaining participants wish. ―Mandruss ☎ 16:39, 20 April 2015 (UTC)

@Mandruss: please do carry on. There's clear interest in moving away from the old scheme, editors are continuing to join the discussion constructively (in itself an endorsement of your process, even if they don't also comment right here) and others who have already commented will be looking forward to the next stage, we've valuable input on feasibility and alternatives from within WMF, and your plan has an excellent chance of producing a clear outcome within a reasonable time. NebY (talk) 22:44, 20 April 2015 (UTC)

@NebY: Ok, with that comment I'm prepared to continue to move my process along, even if it's unclear whether it will be of any benefit in the end. I'll leave the rest, including debate with JohnBlackburne and discussion of phab, to others. ―Mandruss ☎ 23:09, 20 April 2015 (UTC)

• Support  #008560  - This was brought up either this year or last .... IMHO the notification colours do need to change. –Davey2010^Talk 14:59, 20 April 2015 (UTC)

Worth mentioning in my search for earlier mentions I came across the tasks at top right which would probably address some peoples concerns here, by allowing for different displays for different sorts of notifications. While changing the colour can be done locally and even individually varying it by type of notification requires a change to the underlying software. These go much further than just a simple colour change, and so would render the outcome of this proposal largely moot if implemented. T94634 in particular is quite new, active and being brainstormed. With three open bugs/requests it seems likely something will come out of them. There’s nothing to stop editors here participating in the discussions at phabricator on those tasks.--JohnBlackburne^words_deeds 17:20, 20 April 2015 (UTC)

• Support - every time I see that red number, it freaks me out just a little. And that panic is unnecessary. — kikichugirl ^oh hello! 19:17, 20 April 2015 (UTC)
• NOTE - reminder, the local defaults should only be changed if the proposed colors pass WCAG. Please test all color combinations against http://webaim.org/resources/contrastchecker/ for accessibility. Cheers :) Quiddity (WMF) (talk) 23:40, 20 April 2015 (UTC)

  @Quiddity (WMF): Are we testing per WCAG AA or WCAG AAA? I have stricken those that fail WCAG AA, but some of the remaining ones fail WCAG AAA. ―Mandruss ☎ 00:57, 21 April 2015 (UTC)

  @Mandruss: WCAG AA at minimum, although that should be sufficient in this case because it isn't a long string of text. Quiddity (WMF) (talk) 01:29, 21 April 2015 (UTC)

• Oppose It's meant to be attention-grabbing. One needs one's attention grabbed when one has been mentioned in a comment, or one's edit reverted. Red is by far the best colour for this. — This, that and the other (talk) 09:21, 21 April 2015 (UTC)
• weak support any colour is attention-grabbing really...I think just a bit less overt would be nice. Cas Liber (talk · contribs) 13:27, 21 April 2015 (UTC)
• Colour comment Please do not use green and the current colour — some of us, including me, won't be able to tell the difference. If you want to implement the proposal (I don't have an opinion on the proposal itself), please pick a radically different colour for one of them, like yellow or medium blue. Nyttend (talk) 23:20, 29 April 2015 (UTC)

  @Nyttend: That shouldn't be a problem, as nomiinations are closed and there are no such candidates. Voting is below if you want to. ―Mandruss ☎ 23:30, 29 April 2015 (UTC)

• Oppose - red is the standard color for notification badges on the web. Using UI conventions that are consistent with other websites is a good thing as it makes our UI easier for new users to understand. Kaldari (talk) 20:06, 6 May 2015 (UTC)
• Strong Oppose, red is a standard notification color, and I don't automatically think oh-no when I see my big bright red notification, I'm actually happy to see it, it could be a revert, but it could also be thank. Also, it needs to be seen, if the notification color was a "soft" color, then we don't need to call it a "notification" anymore, because it's not important. If a user gets mad because the system notified them of their revert with red colors (how could we?!), and goes and violates 3RR with an edit war, that's not our problem, it's their's. --AmaryllisGardener ^talk 21:20, 6 May 2015 (UTC)
• lol per Jayron32. Protonk (talk) 01:18, 8 May 2015 (UTC)
• Support, some shade of blue or green or purple, I don't care, just anything but red, orange or yellow. The adrenalin/alarm effect is real, as is the psychological effect of red-to-yellow lights, signs and other alerts. I get the same spike from red and yellow ones in other circumstances, because they look like errors). There is no standard for "notification color" on the Web. The !votes making such claims are hyperbolically misusing the word, when what they really mean is "some browser apps I use have red notification icons". These subjective memories are not even evidence that red notices are typical or a majority. In human–computer interface design in general, red notices most often mean an error or some other condition indicating a need for immediate attention. My Mac's backup notice uses a blue-green-grey icon, and the Ghostery browser app in my Chrome uses a black counter, while the Gmail Notifier one does use red. But WP is not the Web or an OS anyway. We're free to use any color scheme for anything, and we do so on the basis of what is best for readers and editors. Triggering overreactions to messages or pings surely is not among those criteria. We already use color scheme smarts in dispute/cleanup templates in articles, with red, orange, and yellow reserved for more (and respectively decreasingly) serious concerns, and blue, grey and purple for less problematic ones; see Template:Ambox for examples (though they're not 100% consistent - one of them uses an orange bar but a black icon).  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  12:24, 24 May 2015 (UTC)
  • the votes that the above discussion led to have now finished; see below for the outcome(s). I notice also that one of the related tasks, T94634, is now resolved, which may address some editors concerns.--JohnBlackburne^words_deeds 13:42, 24 May 2015 (UTC)

Process description

• Colo(u)r nominations will continue until 26 April, during which time there is no voting. Additional nominators will have to provide the colo(u)r codes, but I or someone else can do the table update for any nominator who is table-challenged.
• On 26 April, I will ping all users then listed in the Interested parties subsection (below), all existing votes will be discarded, and a first round of voting will begin. Any user (pinged or not) may then vote for up to three choices. Details will be determined later.
• Per the above, there's no point in any further voting before 26 April, and any premature votes will be ignored. This will ensure that each voter has seen all the candidates.
• On 6 May, three finalists will be determined and presented, interested parties will be pinged, and the second round of voting will begin. Details will be determined later.
• On 16 May, the winner will be determined and presented and ... wait for it ... interested parties will be pinged. ―Mandruss ☎ 19:29, 19 April 2015 (UTC)

Interested parties

This list will be used to notify interested parties of developments such as the start of a voting round (described above). Add or strike yourself as desired. ―Mandruss ☎ 17:32, 19 April 2015 (UTC)

(Remember that {{ping}} won't work at all if more than 20 users are listed in a single invocation.) EEng (talk) 19:02, 19 April 2015 (UTC)

Thanx. I didn't know that. Ain't collaboration great? ―Mandruss ☎ 19:07, 19 April 2015 (UTC)

1Potato2Potato3Potato4, Ahecht, Alakzi, Allen3, Alsee, APerson, ATinySliver, Be..anyone, Beeblebrox, BethNaught, Bryce Carmony, Bus stop, Calidum, Casliber, Davey2010, DerryAdama, Dustin V. S., EEng, EoRdE6, Fauzan, Herostratus, Hroðulf, Huntster, IJBall, Ivanvector, Jamesmcmahon0, Jayron32, Jerodlycett, JohnBlackburne, JohnCD, Kaldari, Kennethaw88, Kevjonesin, Kharkiv07, Kikichugirl, L235, LindsayH, Mandruss, Mr. Granger, NebY, Nøkkenbuer, Nyttend, Od Mishehu, Origamite, Pathore, PhantomTech, Quiddity (WMF), Racerx11, Renata3, Rich Farmbrough, Samwalton9, SchreiberBike, Soap, Spinningspark, Technical 13, The ed17, TheDJ, TheMesquito, This, that and the other, Trout71, Yair rand

Colo(u)r nominations

Nominations are closed. See voting result.

Omits proposals lacking a specific colo(u)r code. Here is one of several web-based colo(u)r pickers. You may prototype a colo(u)r code here. n nA nB nC 0 (current) #BD2400/white  1   You have new messages  - - 1 #00528C/white  1   You have new messages   1   You have new messages  - 2 #F9C557/black  1   You have new messages  - - 3 #008560/white  1   You have new messages   1   You have new messages  - 4 #F9C557/white  1   You have new messages  fails WCAG AA contrast test  1   You have new messages  fails WCAG AA contrast test  1   You have new messages  5 #8EED9D/black  1   You have new messages   1   You have new messages  - 6 #CBBAE8/black  1   You have new messages   1   You have new messages  - 7 #ED8EDE/black #8EED9D/black - -  1   You have new messages  8 #347BFF/white  1   You have new messages  fails WCAG AA contrast test  1   You have new messages  fails WCAG AA contrast test - 9 #006400/white  1   You have new messages   1   You have new messages  - 10 #008740/white  1   You have new messages   1   You have new messages  - 11 #F9C557/#006400  1   You have new messages   1   You have new messages  - ―Mandruss ☎ 10:11, 19 April 2015 (UTC) For reference, the current colors used for the different types of notifications are as follows: — {{U|Technical 13}} (e • t • c)   No notifications = "#D2D2D2";// (current gray value)   Thanked = "#14B18A";// (green value from icon)   Reverted = "#575757";// (best average of gray color from icon)   Mentioned = "#3867B1";// (blue value from icon)   Talk page post = "#F9C557";// (old orange color)   Userrights = "#060606";// (Black color from the W icon)   Linked = "#3967B0";// (blue value from icon)   Page reviewed = "#26AA64";// (green value from icon)   Notifications = "#CC0000";// (current red value) @Technical 13: I assume that's something in development, as we don't see all those colors now. As I said in the main subsection discussion, I'm proceeding with this process as planned, despite it being unclear what effect it will ultimately have. What bearing does the above have on this process, if any? ―Mandruss ☎ 12:38, 21 April 2015 (UTC) Those are the colors currently used for the icons that represent each event when you see them in the fly-out, so it would make sense that if there was only one event pending, it would be the color of the icon used for said event. — {{U|Technical 13}} (e • t • c) 12:44, 21 April 2015 (UTC) I've added the icons so you can see what I am talking about. — {{U|Technical 13}} (e • t • c) 12:59, 21 April 2015 (UTC) @Technical 13: I see, and the "fly-out" being what we see when we click on the notification number. So that paradigm and this process are incompatible and this process may very well be moot. Nevertheless, unless agreement is reached to cancel this process, I'll continue with it. We're moving in multiple different directions, and that's ok for now; at least we're moving. ―Mandruss ☎ 12:52, 21 April 2015 (UTC) What are you talking about? You lost me. The notification number is the collapsed fly-out, this process is about changing the color of that fly-out, and it should be a color that represents what the new notification is (shouldn't ALWAYS be one color). If I get a new talk message, it should be the red it is now, as that is important (and the icon is the same as the mention one so it should be somehow distinguishable). Since this project is in objection to the red for all events (such as reversion), this is what we are talking about. The "You have new messages" thing is entirely different and doesn't really belong in this discussion, but that point is moot to me and I haven't been talking about it. — {{U|Technical 13}} (e • t • c) 12:59, 21 April 2015 (UTC) @Technical 13: Unless I've been lost from the start, this proposal does not affect the fly-out in any way. It's about the notification number and "You have new messages". Maybe the notification number shouldn't always be one color, but it currently is (most salient to this proposal, it's red for reverts), and this process is about choosing a better alternative than red. If the change you describe to the notification number is implemented, that will moot this process. If that change is definitely going to happen within a reasonably short time, cancelling this process would seem the right thing to do, but there is no agreement to do that at this point. Are we on the same page now? ―Mandruss ☎ 13:14, 21 April 2015 (UTC) The flyout = WP:ECHO = Preferences → Notifications → Notify me about these events "You have new messages" = Preferences → Notifications → New message indicator → Show talk page message indicator in my toolbar OR Preferences → Gadgets → Appearance → Display a floating alert when I have new talk page messages I understand how this can be very confusing. All three are different things. The table above combines all of Preferences → Notifications despite the fact there are actually two pieces to it that work differently. The part with the red box with a number is just the flyout part. Inside of the flyout, there are the icons above using the colors indicated. If' there was a class added to the flyout element (the notification number you click on) for each of the new events (per my list) then css or js could be set up to change the color of the flyout so that if there is only one notification, the editor will have a pretty good idea what it is and be able to know how important it is. The icons themselves are all neutral colors in my opinion, and the ones that don't have their own specific icon (new talk page messages) could be the current red. I don't know if I am making it clearer or confusing you more. Either way, I don't know how to explain it another way, so if you're still confused I'll need to ask the editors watching this discussion to assist. — {{U|Technical 13}} (e • t • c) 13:30, 21 April 2015 (UTC) @Technical 13: Yeah, most of that is over my head technically, but it's very possible I have been on the wrong track here. Being as I lack competence to participate in that discussion, all I need is a clear green light or red light on the voting process described in #Process description. At this point, I perceive the light color as green. ―Mandruss ☎ 13:41, 21 April 2015 (UTC) I like the matching colours, the matching dark blue and the matching dark green especially. 1Potato2Potato3Potato4 (talk) 10:41, 19 April 2015 (UTC) That would be 1B and 3B. Thanks. ―Mandruss ☎ 10:49, 19 April 2015 (UTC) Yes. I have to admit though, 6b is very soothing. 1Potato2Potato3Potato4 (talk) 10:50, 19 April 2015 (UTC) No wonder they call you "1Potato2Potato3Potato4". EEng (talk) 11:11, 19 April 2015 (UTC) 6B (but really, and of the "B"s except I don't like 4B). Update: OK, anything using greens, blues, purples; avoid the orange and red. I'm easy. EEng (talk) 11:11, 19 April 2015 (UTC) 4 came from EoRdE6. S/he may have meant  #F9C557 , but I couldn't be sure so I included it. ―Mandruss ☎ 13:16, 19 April 2015 (UTC) Prefer 2A --RacerX11 Talk to meStalk me 12:33, 19 April 2015 (UTC) Prefer 3A. Just in case, we may have a gadget as the i th option which includes such colo(u)rs as stygian blue, self-luminous red and hyperbolic orange. --Fauzan✆ talk✉ mail 13:42, 19 April 2015 (UTC) I believe the color should be either  #347bff  or  #006400 , both of which are already in common use on Wikipedia (the first is the color for the blue buttons used in Flow's Agora buttons, I think, and the second is the color of added bytes to a page). A third option could be  #008740 , which I personally love and is the color off Flow's logo. In either case, the text color would be white. If not these, I would recommend 2A or 3B. Also, thank you Noah Webster! ―Nøkkenbuer (talk • contribs) 13:46, 19 April 2015 (UTC) Done. Proposals 8, 9, and 10, respectively. ―Mandruss ☎ 14:03, 19 April 2015 (UTC) Thanks, I appreciate it! ―Nøkkenbuer (talk • contribs) 14:05, 19 April 2015 (UTC) prefer 0A, the current colours.--JohnBlackburnewordsdeeds 15:21, 19 April 2015 (UTC) That would be an Oppose in the preceding subsection. ―Mandruss ☎ 15:27, 19 April 2015 (UTC) It makes no sense to exclude it as a choice though. If more people prefer the current colour than any of the alternatives then it should (continue to be) used. Otherwise the result will be an even less popular colour or colour pair, resulting in greater dissatisfaction and probably a request to change it back – which would probably succeed.--JohnBlackburnewordsdeeds 17:23, 19 April 2015 (UTC) Table modified. This would appear to moot the Supports/Opposes, I'm not sure, but it's clearly simpler. ―Mandruss ☎ 18:31, 19 April 2015 (UTC) 1B. 8B as second choice and 3B as third choice. Herostratus (talk) 15:33, 19 April 2015 (UTC) 1A. 2A, to be honest I don't have a good reason I just like the looks better. Kharkiv07Talk 18:34, 19 April 2015 (UTC) 2A as previously noted (though 4A would not get an argument from me). (Strike per process description.) —ATinySliver/ATalkPage 20:10, 19 April 2015 (UTC) NOTE - All voting before 26 April will be ignored. Please read #Process description above. ―Mandruss ☎ 20:40, 19 April 2015 (UTC) Comment: what about  1   You have new messages  (or even  1   You have new messages ) as an option to #2? —ATinySliver/ATalkPage 22:31, 19 April 2015 (UTC) @ATinySliver: Are you officially nominating either or both, or just seeking discussion about them? (Either would be a C option on a separate row, like 7C, so both could be nominated.) ―Mandruss ☎ 09:36, 20 April 2015 (UTC) Either/or. If you feel these are worthy of 2Ci/2Cii, feel free. :) —ATinySliver/ATalkPage 10:43, 20 April 2015 (UTC) I don't feel it's my place to filter nominations. Either you nominate or you don't, although there's nothing wrong with throwing out a feeler before deciding whether to nominate. If that's a feeler, my own personal opinion is that those aren't different enough from other candidates to include them. BTW, and changing what I implied in my previous comment, they would be 11A and 12A, since neither changes the "You have new messages" color. Then, just per the existing pattern in the table, we would also include 11B and 12B. If you like, I could be even more confusing than that. ;) ―Mandruss ☎ 10:51, 20 April 2015 (UTC) Hehe okay, based on the idea that we're here in the first place because so many of us find #BD2400 off-putting, allow me to officially nominate  1   You have new messages  as option 11A and  1   You have new messages  as option 11B. —ATinySliver/ATalkPage 19:51, 20 April 2015 (UTC) @ATinySliver: I added that, but they both look extremely close to 2A to me. A different editor has somehow determined that the text color of the status quo "You have new messages" is #555555 (a dark gray) and modified column nA accordingly, and I changed your nomination to match. ―Mandruss ☎ 23:31, 20 April 2015 (UTC) Looks good, thanks :) —ATinySliver/ATalkPage 23:37, 20 April 2015 (UTC) 10b because green makes the most sense (green means go, red means stop, and we want these messages to encourage constructive participation, not discourage people). I support 3b and 9b as second and third choices, but 10b matching the Flow logo makes sense going forward (assuming all the bugs can finally be worked out there). --Ahecht (TALK PAGE) 14:18, 20 April 2015 (UTC) Sigh. Let's try this: NOTE - All voting before 26 April will be ignored. Please read #Process description above.―Mandruss ☎ 14:29, 20 April 2015 (UTC) Note: phab:T94634 will be in development soon, which for messages in the Flow Notification tab (only shown to editors who have interacted with a Flow board at some point), will change the red-number to a grey-number once the flyout has been opened once (see mockup images at that phabricator task). This will help make it easier for us to determine when a new and unseen notification has arrived, without necessitating marking all messages as read continuously (or keeping mental track of the number, in order to notice when it increments). I've pinged the relevant Product Manager (DannyH) to let him know of the discussion above, and will ping the relevant designer (Pau) to let him know, too, in case they have input/suggestions. Quiddity (WMF) (talk) 20:48, 20 April 2015 (UTC) I've not read this discussion, just part of the parent discussion. That said, I think I understand what the purpose of this discussion is and I've looked at the proposals table through color filtering websites (I had to use a few different ones for the different types) and a lot of the proposed replacements aren't accessible to people with certain types of color blindness and don't meet the contrast thresholds for accessibility. I don't know if Quiddity has brought that up or not yet, but I would think any replacement would need to be accessible to everyone. What I could see as a potential solution would be if there was an API hook for the various notification types or a class added to the flyout element for each type of notification that could be modified by us registered users with css or js to suit each of our individual needs. — {{U|Technical 13}} (e • t • c) 01:02, 21 April 2015 (UTC) Yup, I mentioned WCAG above (briefly) and below (with my recommendation (and example code) that user.css (or a gadget) is possibly the best solution here, given that some people don't wish to change). Changing the color based on the notification type, is an entirely more complicated task, but is filed at phab:T57359, and I've pointed the designer (Pau) currently working with the Collaboration Team (who cover Echo) towards that bug at phab:T94634#1174845. Quiddity (WMF) (talk) 01:27, 21 April 2015 (UTC) 1B - (Sorry If I'm not meant to "!vote" here ... I'm somewhat lost on the whole 26th Apr thing) anyway prefer 1B just looks better imho. –Davey2010Talk 01:04, 21 April 2015 (UTC) @Davey2010: In a nutshell, we're in the nominations phase and voting does not begin until nominations are closed. That will occur on 26 April. I added you to #Interested parties. ―Mandruss ☎ 01:39, 21 April 2015 (UTC) Ahhh right thanks :) –Davey2010Talk 07:42, 21 April 2015 (UTC)

Voting round 1

Voting round 1 is closed. See voting result.

Notification of interested parties @1Potato2Potato3Potato4, Ahecht, Alakzi, Allen3, ATinySliver, Be..anyone, Beeblebrox: ―Mandruss ☎ 12:52, 26 April 2015 (UTC) @BethNaught, Bryce Carmony, Bus stop, Calidum, Casliber, Davey2010, DerryAdama, EEng: ―Mandruss ☎ 13:02, 26 April 2015 (UTC) @Dustin V. S., EoRdE6, Fauzan, Herostratus, Ivanvector, Jayron32, Jerodlycett: ―Mandruss ☎ 13:03, 26 April 2015 (UTC) @JohnBlackburne, JohnCD, Kharkiv07, Kikichugirl, NebY, Nøkkenbuer, Od Mishehu: ―Mandruss ☎ 13:05, 26 April 2015 (UTC) @Quiddity (WMF), Racerx11, Samwalton9, SchreiberBike, Technical 13, TheDJ, This, that and the other: ―Mandruss ☎ 13:06, 26 April 2015 (UTC) @Trout71, Yair rand: ―Mandruss ☎ 13:07, 26 April 2015 (UTC) @EEng: ―Mandruss ☎ 13:31, 26 April 2015 (UTC) Anyone may vote here, whether pinged or not. You have six votes that you may distribute between one, two, or three candidates. If you like only one candidate, give it all six votes. If you like two candidates, distribute your votes between them evenly (3/3) or unevenly (4/2 or 5/1). For three candidates, your voting could be 2/2/2, 3/2/1, or 4/1/1. Any votes that total less than six (why?) will be accepted and counted, but any votes totalling more than six will be flagged and ignored. If this happens to you, you may fix it at any time before 6 May, but you probably will not be notified of the error. You may write your votes in any way that's clear. One very concise example is like this: 7B(4) 0A(2) You will be added to #Interested parties if not already listed there. On 6 May, three finalists will be determined by a simple count of votes, #Interested parties will be pinged, and the second round of voting will begin. n nA nB nC 0 (current) #BD2400/white  1   You have new messages  - - 1 #00528C/white  1   You have new messages   1   You have new messages  - 2 #F9C557/black  1   You have new messages  - - 3 #008560/white  1   You have new messages   1   You have new messages  - 4 #F9C557/black #008560/white - -  1   You have new messages  5 #8EED9D/black  1   You have new messages   1   You have new messages  - 6 #CBBAE8/black  1   You have new messages   1   You have new messages  - 7 #ED8EDE/black #8EED9D/black - -  1   You have new messages  9 #006400/white  1   You have new messages   1   You have new messages  - 10 #008740/white  1   You have new messages   1   You have new messages  - 11 #F9C557/#006400  1   You have new messages   1   You have new messages  - 6B(3) 3B(3) ―Mandruss ☎ 12:22, 26 April 2015 (UTC) 3B(5) 6B(1) 1Potato2Potato3Potato4 (talk) 12:40, 26 April 2015 (UTC) 6B(5) 5B (1) Cas Liber (talk · contribs) 13:06, 26 April 2015 (UTC) 2A(6) --RacerX11 Talk to meStalk me 13:14, 26 April 2015 (UTC) 1B(5) 3B(1). –Davey2010Talk 13:24, 26 April 2015 (UTC) 1A(4) 3A(2) - Sam Walton (talk) 13:33, 26 April 2015 (UTC) 5B(2) 6B(2) 7C(2) EEng (talk) 13:54, 26 April 2015 (UTC) 1B(6) Dustin (talk) 14:57, 26 April 2015 (UTC) 7C(4) 4C(2) EoRdE6(Come Talk to Me!) 15:05, 26 April 2015 (UTC) 1A(5) 1B(1) Kharkiv07Talk 15:18, 26 April 2015 (UTC) 5B(3) 6B(3) Trout71 (talk) 15:53, 26 April 2015 (UTC) 3B(3) 5B(3) --- :D Derry Adama (talk) 16:33, 26 April 2015 (UTC) 1B(2) 3B(2) 9B(2) ―Nøkkenbuer (talk • contribs) 16:38, 26 April 2015 (UTC) 1A(4) 2A(1) 9A(1) Ivanvector (talk) 17:51, 26 April 2015 (UTC) 3A(2) 9A(2) 10A(2) --Fauzan✆ talk✉ mail 18:27, 26 April 2015 (UTC) 11B(3), 11A(2), 2A(1) —ATinySliver/ATalkPage 19:43, 26 April 2015 (UTC) 1A(6) Jerod Lycett (talk) 20:52, 26 April 2015 (UTC) 1A(6) Bryce Carmony (talk) 21:44, 26 April 2015 (UTC) 1B(3), 3B(3)  SchreiberBike | ⌨  21:58, 26 April 2015 (UTC) 0A(6) Like just about every other website. — This, that and the other (talk) 07:59, 27 April 2015 (UTC) 3A(6) Though not opposed to the other green options (9 and 10). --Ahecht (TALK PAGE) 14:09, 27 April 2015 (UTC) abstain. This is gonna end in a 'design by committee' problem where no one will be satisfied. Also acting like this on 'gut' feeling without, metrics etc. is exactly what we keep throwing into the WMF's face when it comes to changes like this, it's hypocritical. —TheDJ (talk • contribs) 14:46, 27 April 2015 (UTC) Can you describe how we might establish a metric for the effect of the color of the notification number on people's reactions to reverts? Shall we conduct a months-long study testing various colors in various segments of the editor population, tracking frequency of edit warring associated with each color, to justify a small color change? Who will do that, and what will not get done while they're doing it? Overthink. ―Mandruss ☎ 15:44, 27 April 2015 (UTC) 1B (4), 3B (2) Herostratus (talk) 16:41, 27 April 2015 (UTC) 3B(3), 6B(2), 1B(1) kennethaw88 • talk 02:34, 28 April 2015 (UTC) 5B(3), 6B(3) All the best: Rich Farmbrough, 17:43, 29 April 2015 (UTC). 0A(6) APerson (talk!) 13:19, 30 April 2015 (UTC) 0A(6) --JohnBlackburnewordsdeeds 19:46, 2 May 2015 (UTC) 2A(2), 3A(2), 3B(2) Origamiteⓣⓒ 11:42, 4 May 2015 (UTC) 0A(6) Ed [talk] [majestic titan] 13:21, 4 May 2015 (UTC) 2A(4), 1B(2) NebY (talk) 12:59, 6 May 2015 (UTC)

Voting round 2

Voting round 2 is closed. See voting result.

Notification of interested parties @1Potato2Potato3Potato4, Ahecht, Alakzi, Allen3, APerson, ATinySliver, Be..anyone: ―Mandruss ☎ 16:13, 6 May 2015 (UTC) @Beeblebrox, BethNaught, Bryce Carmony, Bus stop, Calidum, Casliber, Davey2010: ―Mandruss ☎ 16:14, 6 May 2015 (UTC) @DerryAdama, Dustin V. S., EEng, EoRdE6, Fauzan, Herostratus, Ivanvector: ―Mandruss ☎ 16:14, 6 May 2015 (UTC) @Jayron32, Jerodlycett, JohnBlackburne, JohnCD, Kennethaw88, Kharkiv07, Kikichugirl: ―Mandruss ☎ 16:15, 6 May 2015 (UTC) @NebY, Nøkkenbuer, Nyttend, Od Mishehu, Origamite, Quiddity (WMF), Racerx11: ―Mandruss ☎ 16:15, 6 May 2015 (UTC) @Rich Farmbrough, Samwalton9, SchreiberBike, Technical 13, The ed17, TheDJ, This, that and the other: ―Mandruss ☎ 16:16, 6 May 2015 (UTC) @Trout71, Yair rand: ―Mandruss ☎ 16:17, 6 May 2015 (UTC) Anyone may vote here, whether pinged or not. Candidates include the current colo(u)rs and the three leaders from voting round 1. You have six votes that you may distribute between one, two, or three candidates. If you like only one candidate, give it all six votes. If you like two candidates, distribute your votes between them evenly (3/3) or unevenly (4/2 or 5/1). For three candidates, your voting could be 2/2/2, 3/2/1, or 4/1/1. Any votes that total less than six (why?) will be accepted and counted, but any votes totalling more than six will be flagged and ignored. If this happens to you, you may fix it at any time before 16 May, but you probably will not be notified of the error. You may write your votes in any way that's clear. One very concise example is like this: 3A(4) 0A(2) You will be added to #Interested parties if not already listed there. On 16 May, the winner will be determined by a simple count of votes and #Interested parties will be pinged. n nA nB 0 (current) #BD2400/white  1   You have new messages  - 1 #00528C/white  1   You have new messages   1   You have new messages  3 #008560/white -  1   You have new messages  3B(6) ―Mandruss ☎ 15:41, 6 May 2015 (UTC) 3B(6) --Ahecht (TALK PAGE) 16:17, 6 May 2015 (UTC) 3B(6) --- :D Derry Adama (talk) 16:20, 6 May 2015 (UTC) 0A(6) JohnCD (talk) 16:22, 6 May 2015 (UTC) 0A(6) --JohnBlackburnewordsdeeds 16:24, 6 May 2015 (UTC) 1B (6) –Davey2010Talk 16:30, 6 May 2015 (UTC) 0A (6) --Jayron32 16:47, 6 May 2015 (UTC) 1B (4) 3B (2) -- Herostratus (talk) 16:54, 6 May 2015 (UTC) 1A(6) Ivanvector (talk) 17:07, 6 May 2015 (UTC) 0A(5), 3B(1) BethNaught (talk) 17:35, 6 May 2015 (UTC) 3B(6) —ATinySliver/ATalkPage 17:36, 6 May 2015 (UTC) 1A (3) & 3B (3) Consensus I see not here... EoRdE6(Come Talk to Me!) 18:09, 6 May 2015 (UTC) 1A (6) Sam Walton (talk) 18:12, 6 May 2015 (UTC) 0A (6) Kharkiv07Talk 18:15, 6 May 2015 (UTC) 1A(2), 1B(4) NebY (talk) 20:08, 6 May 2015 (UTC) 0A (6) Kaldari (talk) 20:09, 6 May 2015 (UTC) 1A(4), 3B(2) Origamiteⓣⓒ 20:22, 6 May 2015 (UTC) 0A (6) SpinningSpark 21:24, 6 May 2015 (UTC) 1B(4), 3B(2)  SchreiberBike | ⌨  23:17, 6 May 2015 (UTC) 1A(6) at least it's not 0A.. All the best: Rich Farmbrough, 23:27, 6 May 2015 (UTC). 1A(4) 1B(1) 3B(1) --L235 (t / c / ping in reply) 00:03, 7 May 2015 (UTC) 1A(3) 3B(3) —Granger (talk · contribs) 00:21, 7 May 2015 (UTC) 1A(6) --RacerX11 Talk to meStalk me 00:50, 7 May 2015 (UTC) 3B(6). kennethaw88 • talk 03:08, 7 May 2015 (UTC) 1A(6) I like the other ones too, but spreading out my votes won't help it be *not* 0A. — kikichugirl oh hello! 03:34, 7 May 2015 (UTC) 0A(5) 1B(1), because I like column B better than A, but there was no 0B. –Be..anyone (talk) 05:17, 7 May 2015 (UTC) 0A(6) — This, that and the other (talk) 10:43, 7 May 2015 (UTC)\ 0A(6) APerson (talk!) 13:20, 7 May 2015 (UTC) 0A(3) 3B(3) --Fauzan✆ talk✉ mail 17:40, 7 May 2015 (UTC) 3B(6) 1Potato2Potato3Potato4 (talk) 18:33, 7 May 2015 (UTC) 1A(6) PHANTOMTECH (talk) 23:59, 7 May 2015 (UTC) 1A(5) Trout 71 15:46, 9 May 2015 (UTC) 1B(6) --IJBall (talk) 05:43, 10 May 2015 (UTC) 0A(6) Renata (talk) 13:23, 10 May 2015 (UTC) 0A(6) TheMesquitobuzz 05:30, 12 May 2015 (UTC) 0A(4) 3B(2) —Soap— 06:24, 12 May 2015 (UTC) 0A(6), since I like bold appearances, and all other choices are the antithesis of bold. I simply don't see people being less angry about a reversion because this is blue or green. — Huntster (t @ c) 07:19, 12 May 2015 (UTC) 0A(6) since I'm going to poke at the Phab ticket in the next two weeks to allow per user customization there is no need to change it multiple times. — {{U|Technical 13}} (e • t • c) 02:18, 16 May 2015 (UTC) Thanks, but per user customization won't address the issue. ―Mandruss ☎ 03:53, 16 May 2015 (UTC) Round 3 potential Not to stretch this out unnecessarily but, say, absent a clear winner, a final round between the top two might be in order ... —ATinySliver/ATalkPage 04:15, 7 May 2015 (UTC) 1. What would constitute a clear winner? 2. I'm not opposed, assuming a clear consensus, but it could be seen as bikeshed expansion. Maybe we should !vote on it. not! ―Mandruss ☎ 16:22, 7 May 2015 (UTC) LOL well, to use primary elections as an example, a clear winner is 50% of the vote plus 1; oftentimes, there will be a runoff election between the top two finishers otherwise. Assuming such a situation and that a Round 3 is agreeable, it would be a straight-up either-or !vote per interested editor. —ATinySliver/ATalkPage 20:23, 7 May 2015 (UTC) You could be right. Our current leader has only 34% of the votes. ―Mandruss ☎ 22:17, 7 May 2015 (UTC) Updating: after 221 !votes by 37 editors, the totals/percentages (rounded up): 0A 83/37.6; 1A 57/25.7; 3B 55/24.9; 1B 26/11.8. If we were to assume no change, I for one would consider 12 percentage points reasonably "clear". On the other hand, the argument also can be made: "keep the status quo" gets 83 !votes while "change the status quo" gets 138 combined !votes. Could be a tough call. —ATinySliver/ATalkPage 22:11, 13 May 2015 (UTC) I think it would be a really bad idea to declare any option the winner with a clear majority opposed to that option. That's what run-offs are for, and I've pretty much decided to have one unless for some reason there is a consensus against it. ―Mandruss ☎ 22:25, 13 May 2015 (UTC) While I understand your position, delaying the vote anymore just makes it seem to me that you are like "well the vote did not go my way, so i will keep running it until it does". I think this should be closed as it seems clear the 0A is the one people want to be kept. TheMesquitobuzz 02:12, 14 May 2015 (UTC) I'm not concerned about what it might seem like. My handling of this whole situation has been nothing but forthright, and you know nothing about me otherwise, so your comments are completely without foundation and frankly more than a little offensive. But I'm going to let that pass and just state that 37% of the vote doesn't constitute "it seems clear the 0A is the one people want to be kept" where I come from. ―Mandruss ☎ 02:37, 14 May 2015 (UTC)

Voting round 3 (runoff)

Voting round 3 is closed. See voting result.

Notification of interested parties @1Potato2Potato3Potato4, Ahecht, Alakzi, Allen3, APerson, ATinySliver, Be..anyone: ―Mandruss ☎ 19:57, 16 May 2015 (UTC) @Beeblebrox, BethNaught, Bryce Carmony, Bus stop, Calidum, Casliber, Davey2010: ―Mandruss ☎ 19:57, 16 May 2015 (UTC) @DerryAdama, Dustin V. S., EEng, EoRdE6, Fauzan, Herostratus, Huntster: ―Mandruss ☎ 19:58, 16 May 2015 (UTC) @IJBall, Ivanvector, Jayron32, Jerodlycett, JohnBlackburne, JohnCD, Kaldari: ―Mandruss ☎ 19:58, 16 May 2015 (UTC) @Kennethaw88, Kharkiv07, Kikichugirl, L235, Mr. Granger, NebY, Nøkkenbuer: ―Mandruss ☎ 19:59, 16 May 2015 (UTC) @Nyttend, Od Mishehu, Origamite, PhantomTech, Quiddity (WMF), Racerx11, Renata3: ―Mandruss ☎ 20:00, 16 May 2015 (UTC) @Rich Farmbrough, Samwalton9, SchreiberBike, Soap, Spinningspark, Technical 13, The ed17: ―Mandruss ☎ 20:00, 16 May 2015 (UTC) @TheDJ, TheMesquito, This, that and the other, Trout71, Yair rand: ―Mandruss ☎ 20:01, 16 May 2015 (UTC) Anyone may vote here, whether pinged or not. The leader from round 2 received only 39% of the votes, so a runoff is necessary between it and the first runner-up. You have one vote. Please vote either 0A or 1A. You will be added to #Interested parties if not already listed there. On 23 May, the winner will be determined and #Interested parties will be pinged. n nA 0 (current) #BD2400/white  1   You have new messages  1 #00528C/white  1   You have new messages  1A ―Mandruss ☎ 19:55, 16 May 2015 (UTC) 1A Dustin (talk) 19:59, 16 May 2015 (UTC) 0A APerson (talk!) 20:01, 16 May 2015 (UTC) 0A --Jayron32 20:03, 16 May 2015 (UTC) 0A —Soap— 20:10, 16 May 2015 (UTC) 1A - Not keen on either but prefer blue over the red .... –Davey2010Talk 20:15, 16 May 2015 (UTC) 0A - damn...what happened to the others? I think I prefer the current one. sorry. Cas Liber (talk · contribs) 20:19, 16 May 2015 (UTC) 0A. I'm frankly not at all fond of this scheme, but 1A is worse. In particular, when a user has a notification but not a message,  1  will all but disappear into the mix for anyone using monobook, at the least. (Edit for clarity: it has been my experience using monobook that  You have new messages  shows up only when someone has edited my talk page. Only the number box shows up when I have any notification(s).) —ATinySliver/ATalkPage 20:22, 16 May 2015 (UTC) Yeah. As you noted, only two votes (i.e., one voter) separated 1A and 3B. ―Mandruss ☎ 20:28, 16 May 2015 (UTC) Yup. —ATinySliver/ATalkPage 20:40, 16 May 2015 (UTC) Yes. Indeed my round 2 vote, for example (based on my own misunderstanding at the time), tipped it favor of 1A over 3B. Had I known what I know now, I would have likely voted for 3B. I was fine with this process and thought it work, but an honest mistake has messed it up. Not sure what can be done about it now. --RacerX11 Talk to meStalk me 16:03, 17 May 2015 (UTC) Oddly enough, after using 3B within my own global.js for a while, I'm not as fond of it, and for the same reason: even the #086 notification tended to blend in and escape attention. I'm now using the original 2A so notifications use the same scheme as the text box. —ATinySliver/ATalkPage 20:28, 17 May 2015 (UTC) 1A Origamiteⓣⓒ 20:35, 16 May 2015 (UTC) 1A —Granger (talk · contribs) 20:49, 16 May 2015 (UTC) 0A Ed [talk] [majestic titan] 21:19, 16 May 2015 (UTC) 1A --RacerX11 Talk to meStalk me 21:53, 16 May 2015 (UTC) 0A. Changing my vote per this discusion. --RacerX11 Talk to meStalk me 15:51, 17 May 2015 (UTC) 1A Sure. --IJBall (talk) 22:21, 16 May 2015 (UTC) 0A Kaldari (talk) 23:35, 16 May 2015 (UTC) 1A EEng (talk) 23:46, 16 May 2015 (UTC) 1A All the best: Rich Farmbrough, 00:28, 17 May 2015 (UTC). 0A. --JohnBlackburnewordsdeeds 01:50, 17 May 2015 (UTC) 0A — Huntster (t @ c) 02:34, 17 May 2015 (UTC) 0A TheMesquitobuzz 03:14, 17 May 2015 (UTC) 1A - I beleieve that the red may, in fact, be a bas color to use. עוד מישהו Od Mishehu 03:24, 17 May 2015 (UTC) 0A Still no need to change this while we wait for per type color coordination... — {{U|Technical 13}} (e • t • c) 03:26, 17 May 2015 (UTC) 0A I still prefer red as it is a standard across multiple websites; users should have the option to set colors in their preferences. Calidum T|C 03:31, 17 May 2015 (UTC) 0A — This, that and the other (talk) 04:14, 17 May 2015 (UTC) 0A, but the contrast in this column sucks. –Be..anyone (talk) 05:27, 17 May 2015 (UTC) 0A, stop messing with something that is perfectly servicable and we have all got used to. How much more complicated are you going to make this vote? SpinningSpark 07:58, 17 May 2015 (UTC) 1A As for this process being "too complicated", I've found it very easy to understand. This last round is helpful because the last one could be seen as showing a distinct majority against the status quo and as showing the status quo as the preferred option. Clarifying that doesn't favour either the status quo or change. NebY (talk) 12:46, 17 May 2015 (UTC) 1A,This was the obvious choice. Far preferable to the current red flag-styled notification. Thank you Trout 71 17:42, 17 May 2015 (UTC) 1A, Blue, as I don't want inexperienced editors to be distracted by notifications like 'Linked' or 'Reverted'. The yellow new message indicator is much more important. --Hroðulf (or Hrothulf) (Talk) 18:15, 17 May 2015 (UTC) 1A - I think blue would be a much better choice as the default, as a short, medium or long-term change. Jamesmcmahon0 (talk) 10:31, 18 May 2015 (UTC) 1A Sam Walton (talk) 10:51, 18 May 2015 (UTC) 0A Kharkiv07 (T) 13:28, 18 May 2015 (UTC) 0A This is getting ridiculous. 1Potato2Potato3Potato4 (talk) 18:33, 18 May 2015 (UTC) 1A Ivanvector (talk) 14:51, 19 May 2015 (UTC) 1A as the lesser of two evils, but green on the number would've stood out much more. --Ahecht (TALK PAGE) 16:37, 19 May 2015 (UTC) 0A The blue color lacks luminance contrast compared to the "no new notifications" grey background. The red stands out better. Pathore (talk) 23:18, 20 May 2015 (UTC) 0A As the lesser of two evils. Cheers, LindsayHello 02:58, 21 May 2015 (UTC) Comment This process failed because everyone considered it frivolous enough to have a vote instead of a !vote. Option 0A has a clear opposing rationale, red looks like an alert of something bad. Option 1A has a clear opposing rationale, the blue disappears into the other blue interface elements. Basically ANY of the other options would have been better than these two. Good job Wikipedians! (And the blame goes to me too, I saw this RfC running and I didn't participate before now.) For formal vote purposes I have no position on red vs blue, but if anyone wants to be bold and invalidate this this process for being a vote, the 3B green runner up from round 2 seems to be the most popular vote with no apparent oppose rationale. Alsee (talk) 08:08, 21 May 2015 (UTC) As far as I can tell, the rationale against 1A didn't appear until this round (#8), after 3B was already excluded. An argument does not exist until someone makes it. Throughout the process, some voters have given arguments even though none was required, and I assume that the ones who didn't read and considered those arguments. There's nothing gained by requiring voters to write "per [fill in username]" when they have no new argument of their own. My personal feeling is that the dark blue would contrast with the lighter blue enough to be noticed, and I doubt that many of the 1A voters failed to consider that. I too preferred 3B, and I would be lynched if I supported invalidating these results after they didn't go my way (n.b. the ABF I got when I added a runoff vote). You're right, you're a bit late. ―Mandruss ☎ 08:41, 21 May 2015 (UTC) Alsee, 3B turned out to be not that great, either, at least in my humble opinion. I'm much more fond thus far of what was 2A. —ATinySliver/ATalkPage 19:49, 21 May 2015 (UTC) 1A I'd prefer almost anything other than red. I think the waving a red flag factor affects me sometimes, let alone newbies, and likely other more experienced editors as well (subliminally, if nothing else). ... I've mostly skimmed the preceding thread(s). Has anyone discussed simply removing reversions from among actions given special notifications? As reversions are already noted in the page histories and appear on user watchlists -- both of which may be accessed at will at a time of a user's choosing, as opposed to having a 'flag' (presently a 'red flag') intrude upon whatever else a user may be addressing. Basically, manual reversions don't prompt special immediate notices, why should semi-automated ones do so? Especially in light of the various 'red flag'/'seeing red' concerns that have been raised. While changing the color may help, it seems to me the 'surprise' factor of being interrupted (i.e. 'flagged') with a quick revert notice seems to be (an edit war) cause for concern regardless of the notification color announcing it. --Kevjonesin (talk) 13:02, 22 May 2015 (UTC) Good points, and no, I don't think they have been brought up previously in this proposal. Possible fodder for another proposal. ―Mandruss ☎ 23:34, 22 May 2015 (UTC)

Voting result

Notification of interested parties

@1Potato2Potato3Potato4, Ahecht, Alakzi, Allen3, Alsee, APerson, ATinySliver: ―Mandruss ☎ 07:58, 23 May 2015 (UTC) @Be..anyone, Beeblebrox, BethNaught, Bryce Carmony, Bus stop, Calidum, Casliber: ―Mandruss ☎ 07:58, 23 May 2015 (UTC) @Davey2010, DerryAdama, Dustin V. S., EEng, EoRdE6, Fauzan, Herostratus: ―Mandruss ☎ 07:59, 23 May 2015 (UTC) @Hroðulf, Huntster, IJBall, Ivanvector, Jamesmcmahon0, Jayron32, Jerodlycett: ―Mandruss ☎ 07:59, 23 May 2015 (UTC) @JohnBlackburne, JohnCD, Kaldari, Kennethaw88, Kevjonesin, Kharkiv07, Kikichugirl: ―Mandruss ☎ 08:00, 23 May 2015 (UTC) @LindsayH, Mr. Granger, NebY, Nøkkenbuer, Nyttend, Od Mishehu, Origamite: ―Mandruss ☎ 08:00, 23 May 2015 (UTC) @Pathore, PhantomTech, Quiddity (WMF), Racerx11, Renata3, Rich Farmbrough, Samwalton9: ―Mandruss ☎ 08:01, 23 May 2015 (UTC) @SchreiberBike, Soap, Spinningspark, Technical 13, The ed17, TheDJ, TheMesquito: ―Mandruss ☎ 08:01, 23 May 2015 (UTC) @This, that and the other, Trout71, Yair rand: ―Mandruss ☎ 08:02, 23 May 2015 (UTC)

0A wins 20–17, 54%. The proposal fails. Thanks to all participants. ―Mandruss ☎ 07:56, 23 May 2015 (UTC)

Thanks to User:Mandruss for having the patience and good organisation to manage the decision-making process! — This, that and the other (talk) 09:54, 23 May 2015 (UTC)

Another plan

• I'm sorry, what are y'all voting on? As far as I'm aware the plan is to have a dynamic color based upon the type of notification. So, there will be no static color and my understanding of this vote based on the table above, this vote is a moot point. — {{U|Technical 13}} (e • t • c) 20:02, 26 April 2015 (UTC)

@Technical 13: what is the status of that plan? Is it definitely on the developers' work schedule to deliver it, and if so when will it be delivered? Does it depend on progress of the larger project to replace the current talk page system? I ask these questions because it's not unusual (within Wikipedia or elsewhere) to see simple suggestions - that could have been quickly implemented - dismissed with a promise that eventually something much better will be delivered and yet, for one reason or another, that much better solution is perpetually delayed, or lost in the collapse of another project.

Meanwhile, I'm giving this discussion its own header. It may be that despite your posting, your fellow editors will still want to (!)vote and we don't want to interleave this discussion with those votes. NebY (talk) 20:43, 26 April 2015 (UTC)

• Phab:T57359#1224097 -- > Just waiting for implementation of a class to be added to the growler (echo flyout) for each new notification which is more likely to happen than getting them to just change the color (which you can do yourself with css by adding to your own personal common.css .mw-echo-unread-notifications { background-color: ‹your color choice› !important; color: ‹your color choice› !important; }. — {{U|Technical 13}} (e • t • c) 23:40, 26 April 2015 (UTC)

Indeed, you can make it global. (Oddly, while it balks at "!important", it won't work otherwise.) —ATinySliver/^ATalkPage 23:48, 26 April 2015 (UTC)

I'll remind everyone that, while this vote might be about personal preferences, the proposal itself is not; thus the possibility of a personal change does not address the issue. Anyone who is unclear on this point is encouraged to read the opening post and perhaps the first three comments at #Wouldn't this be better as a new preferences option?. ―Mandruss ☎ 23:55, 26 April 2015 (UTC)

That's more information than is available at Phab:T57359#1224097 but doesn't tell us whether it's definitely on the developers' work schedule to deliver it, and if so when it will be delivered. You do tell us that it depends on other progress without indicating whether the latter is itself on the developers work schedule or when it will be delivered. NebY (talk) 16:11, 27 April 2015 (UTC)

Can you clarify how this is going to work? What colour will it be if I have more than one notification? Sam Walton (talk) 12:54, 17 May 2015 (UTC)

Wouldn't this be better as a new preferences option?

As noted above by Jayron32, this is a WP:BIKESHED problem. As such, it seems unlikely that a large group of self selected individuals will agree on a single colo(u)r scheme. An obvious means to get around this problem is to create a new preference that allows anyone with a registered account to select the shades they prefer. Default values can remain at the current settings, or be battled over by those who feel a need to control the configurations of others, as any values selected are guaranteed to wrong. --Allen3 ^talk 21:20, 20 April 2015 (UTC)

Except that one of the stated problems we want to solve is new users seeing a revert as an "error message" and having a battlefield mentality. This is not just an issue of personal preference, but rather a discussion of what the default should be. The users who would know how to change the notification color are exactly the kind of users that would be least impacted by the change. --Ahecht (TALK
PAGE) 21:28, 20 April 2015 (UTC)

Precisely; thank you; except that many not-so-new editors would apparently benefit, too, and knowing about the preference setting wouldn't mean understanding the potential benefit, or even recognizing any need for a change in the way you react to a revert. This change does not benefit the people "seeing the red" so much as the people they are working with and the community as a whole (e.g., admins who have to deal with edit wars, etc). ―Mandruss ☎ 23:39, 20 April 2015 (UTC)

I adore preferences, I've written about it at length over at mw:Requests for comment/Redesign user preferences (particularly here on the talkpage). But developers really dislike adding preferences, because it is more userpref columns in the database, more code complexity, more code variations to test everything against, and more code to maintain/consider forever going forward; similarly, product managers dislike preferences because they add to the complexity of the already fairly extensive special:preferences tabs (which is a problem because it effectively reduces the probability of the widely useful preferences being discovered & used). Hence this small aesthetic tweak would not be a good candidate for a user-preference

Instead, either the local default could be changed (as suggested above), or the global default could be changed (which would need a vastly wider discussion), or individuals could tweak it for themselves with user.css (I'd recommend this option) - Just add this code to your special:mypage/common.js: .mw-echo-unread-notifications {background-color: #00528C !important; color: #FFF !important;} for the badge, and .mw-echo-alert {background-color: #00528C !important; color: #FFF !important;} for the talkpage notification (changing the color codes as desired).

Regarding the discussion above, the local defaults should only be changed if the proposed colors pass WCAG. Please test all color combinations against http://webaim.org/resources/contrastchecker/

Hope that helps. Quiddity (WMF) (talk) 21:57, 20 April 2015 (UTC)

The distinction has to be drawn between core preferences commonly used, or critical for accessibility, and obscure preferences. Obscure preferences can be accessed from "advanced->very advanced->super advanced" tabs - this is standard UI design. All the best: Rich Farmbrough, 17:49, 29 April 2015 (UTC).

• I haven't read this whole discussion, but I actually worked on this very thing awhile back with User:Technical 13/SandBox/Notification colorizer.js but had to drop the idea for now because there is currently no way to access the types of notifications in the flyout until it is expanded. I've mentioned this in the Phab ticket, and hope it will be acted up in a way that will allow completion of the script I started. — {{U|Technical 13}} (e • t • c) 11:46, 21 April 2015 (UTC)
• That actually sounds a great idea - That way they'd be no "Oh I hate this colour and that colour", Having own preferences mean we'd all be happy, I have wondered if in the next 5 years this will crop up again and everything would be changed. –Davey2010^Talk 16:34, 6 May 2015 (UTC)
• If we aregoing to do this at all, preferences is the place for it. DGG ( talk ) 15:48, 13 May 2015 (UTC)

Revisiting this as a preferences option

Now that Mandruss' proposal to change the base color has not passed, what is the status on this portion of the proposal? On my end, I sure would like to be able customize the Notification box colors so that they are, for example, green for "Thanks", blue for "mentions", etc. using Preferences or something. So what is the status on giving users the ability to do this? (Pinging @Technical 13: as well, as he seems knowledgeable about this...) --IJBall (talk) 02:43, 24 May 2015 (UTC)

Anybody?... --IJBall (talk) 06:45, 31 May 2015 (UTC)

Uniform tables

Presently there is major difference with the layout of wikitables on the desktop site and on the mobile site. Most importantly, the mobile wikitable has no background color for its header cells and its border are brightly colored to the point that they are almost indistinguishable. This creates readability issues for the mobile wikitable. To illustrate this I have made a screenshot of table both in the desktop and the mobile version.

A wikitable on the desktop site

The same table on the mobile site

Therefore, I would like to propose the mobile wikitable's layout to be made the same as the desktop wikitable's, so as to have a uniform table style. Tvx1 19:21, 25 April 2015 (UTC)

Discussion (Uniform tables)

• First question: How exactly does this effect our readers and the encyclopedia? Second question: How do you propose to do this? — {{U|Technical 13}} (e • t • c) 22:37, 25 April 2015 (UTC)

Wikitable CSS is defined:

• Screen: mediawiki.legacy/shared.css
• Print: mediawiki.legacy/commonPrint.css
• Mobile: MobileFrontend/less/content/tables.less

-- Gadget850 ^talk 23:36, 25 April 2015 (UTC)

• The mobile site uses a different skin, "Minerva", specifically tailored to mobile devices. I suspect this colour scheme was carefully chosen for a good reason, and I haven't seen a good explanation of why the desktop site's table colour scheme is any better (or worse, for that matter) than the mobile scheme. As such I would oppose any changes. — This, that and the other (talk) 08:02, 27 April 2015 (UTC)

  This ^^^ Also that table uses colored background to communicate information, which is an accessibility problem. And the background of the table won't matter much to readability on my watch. Also why would things have to be visually consistent across multiple skins ? —TheDJ (talk • contribs) 14:41, 27 April 2015 (UTC)

  I can think of many reasons why it's impractical to have multiple layouts for the same tables. I'm not aware of every type of instance tables are used for on Wikipedia, so I can only talk about the one I'm involved with. I mainly edit in the Formula One Wikiproject. The example use above is of a "result's table". This type of table is quite common in sports articles. The background color used in these tables is supplementary to the text. It's not the sole means of communicating info by any means. The complaints about the tables I have encountered there are that the lack of clearly distinguishable borders on the mobile site's tables makes it difficult to find specific results in these tables. Even more so for colorblind people. You can find some discussion on this here, here and here. Furthermore having different desktop and mobile layouts creates unnecessary complications for editing. Quite often a change of content in a table on desktop works fine on desktop, but creates problems on mobile. I can't see any good reason either why header cell can't have a background color on mobile. I can't give an answer to Technical 13's second question because I'm not adept enough with the site's programming language, so I simply can't point to which part of the CSS has to be changed nor to what it should be changed to. Tvx1 16:28, 27 April 2015 (UTC)

• Oppose any change, that is just the way the mobile site is supposed to look, and it doesn't look any worse (I honestly prefer it). I also think you forget that tables look unique in each different skin, (Similar colourful table in Modern, Cologne Blue, and MonoBook) that is just the way skins work. EoRdE6^{(Come Talk to Me!)} 00:11, 30 April 2015 (UTC)

  Also Vector (for those people who don't have it as default), and Mobile. --Redrose64 (talk) 08:10, 30 April 2015 (UTC)

  EoRdE6, I'm not talking about aesthetics here. I'm talking about accessibility and editing issues caused by the mobile version. The skins you link to only have some minor aesthetic differences which cause no problems with accessibility. Only the mobile version has some fundamental differences to the basic layout which cause these issues. Cell borders are almost indistinguishable, the wikitables have no basic background-color and neither do header cells (!). Also, 2014 Formula One season is not a good example to look at, because those articles' tables have been coded differently by an other editor to make them universal on mobile and desktop. 2013 Formula One season will give you a far better view on just how different those tables are. Tvx1 13:18, 30 April 2015 (UTC)

• So here are the facts that we've determined so far:
  • Every skin looks different.
  • Mobile's headers use bold and centered text, whereas Vector's use bold, centered text and with a gray background. One standard way of describing this difference is that Mobile has a higher contrast/easier readability, especially on very small/lower resolution screens (i.e., old smartphones).
  • Individual tables can be coded to different from the default. (Indeed, most of them are different from the default, because most of them are set to class="wikitable".)
• I'm not really sure that making every skin match every other skin is a good idea. WhatamIdoing (talk) 03:39, 17 May 2015 (UTC)
• I don't see the need for this. They are parts of two different skins, which are different for good reasons although not being part of the design process I do not know the reasons in detail. But changing just one element to make one skin look like another makes no sense, without considering the overall design and how it relates to other skins. Besides the above is a bad example: there are far more problems with the actual table than the underlying CSS/HTML. It looks more like something from a glossy magazine than an encyclopaedia, with all the colours, flags, repetition and bold text.--JohnBlackburne^words_deeds 14:28, 17 May 2015 (UTC)

• Although all skins have their variations, the mobile version is the ONLY one, as I have pointed out earlier, to have fundamental differences to the base style (e.g. header cells, borders) for reasons I don't know. The others just have a different "finish touch" but the BASE style is the same. Not so for the mobile one. So this is a case of making the mobile base style match the numerous other ones, and making them all the 100% exact same. I really can't understand how one can genuinely claim that the mobile one has a higher contrast? It's exactly the opposite. Because of the lack of header cell colors and clearly distinguishable borders it has much LESS contrast and as a result much reduced readability. That's why I made this proposal in the first place. If it's not clear, the mobile table is the one on the right in the picture above. Tvx1 16:45, 18 May 2015 (UTC)

Yes, that's a "higher" contrast. Black text on white background is "higher" contrast than black text on a gray background. WhatamIdoing (talk) 21:38, 20 May 2015 (UTC)

You're both right. Mobile has higher contrast for the text, but mobile gridding is pale-gray to the point of almost invisible. Alsee (talk) 08:37, 21 May 2015 (UTC)

And that's what I have trying to point out. Is there any objection to darkening the gridding? Tvx1 21:39, 5 June 2015 (UTC)

Good Lists

A new class of article to be introduced. It will be a good list. It is similar to good article criteria but in a list format. The step up from list to FL is too great and, like an article, we need a good list. The criteria are below.

It covers a topic that lends itself to list format (see WP:List) and, in addition to meeting the requirements for all Wikipedia content (particularly naming conventions, neutrality, no original research, verifiability, citations, reliable sources, living persons, non-free content and what Wikipedia is not) a good list has the following attributes:

1. Prose. It features a good standard of writing, with no major copyedit issues,
2. Lead. It has a lead that introduces the subject and defines the scope and inclusion criteria.
3. Comprehensiveness.
   • (a) It comprehensively covers the defined scope, providing all of the major items and.
   • (b) In length and/or topic, it meets all of the requirements for stand-alone lists; does not violate the content-forking guideline, does not largely duplicate material from another article, and could not reasonably be included as part of a related article.
4. Structure. It is easy to navigate and includes, where helpful, section headings and table sort facilities.
5. Style. It generally complies with the Manual of Style and its supplementary pages.
   • (a) Visual appeal. It makes suitable use of text layout, formatting, tables, and colour; and a minimal proportion of items are redlinked.
   • (b) Media files. It has images and other media, if appropriate to the topic, that follow Wikipedia's usage policies, with succinct captions. Non-free images and other media satisfy the criteria for the inclusion of non-free content and are labeled accordingly.
6. Stability. It is not the subject of ongoing edit wars and its content does not change significantly from day to day, except in response to the good list process.

TheMagikCow (talk) 17:09, 3 May 2015 (UTC)

This has been discussed before, though I don't have any links handy. Personally, I do not believe there is much value in creating another review process that is ultimately redundant to the Featured List process. There will not be enough difference between a "good" list and a "featured" list to make the process worthwhile. Resolute 17:11, 3 May 2015 (UTC)

How does this proposal compare to FL? What are the similarities and differences? — {{U|Technical 13}} (e • t • c) 17:32, 3 May 2015 (UTC)

There is not much difference between these criteria and those at WP:WIAFL. Apart from changing the word "featured" to "good" throughout, the differences are in just two main criteria and one subcriterion:

In criterion 1, "... professional standards of writing" is replaced by "... a good standard of writing, with no copyedit issues"

In criterion 2, the word "engaging" is omitted

In subcriterion 3(a), the words "at least" are omitted, as is the phrase ", where practical, a complete set of items; where appropriate, it has annotations that provide useful and appropriate information about the items."

In short, I think that the above proposal is expecting too much for a Good List. Compare the requirements for a Featured Article with those for a Good Article - the differences are much greater. In particular, although FA and FL both require compliance with the Manual of Style, GA need only meet the MoS in five areas: lead sections, layout, words to watch, fiction, and list incorporation. I don't think that a GL proposal should require full MoS compliance either. --Redrose64 (talk) 09:58, 4 May 2015 (UTC)

I've found that WikiProject Military history (MILHIST) has a quality scale for lists, which has intermediate levels CL, BL and AL - but there is no "Good List" level, see WP:MHA#SCALE. Accordingly, I've sent MILHIST a note. A shorter version of that has been sent to some other talk pages (example). --Redrose64 (talk) 10:36, 4 May 2015 (UTC)

• Oppose I think we revisit this idea about once a year. As Redrose64 notes, the proposal is very close to FLC already, and trying to define a deliberately weak set of criteria for a "good list" doesn't serve our community well. Full MOS compliance isn't actually that difficult for any article, but it's actually quite important from a technical perspective with lists, so downgrading that would be a bad thing too. The Rambling Man (talk) 10:21, 4 May 2015 (UTC)
• Support Yes and those many thousands of years-related articles that are being maintained for ages with reliable sources needs some recognition. OccultZone (Talk • Contributions • Log)

  Could I ask what is preventing any of those many thousand of years-related articles from meeting the FL criteria? Do you have an example of one which you consider to be good enough to be a good list? The Rambling Man (talk) 10:46, 4 May 2015 (UTC)

2012 in the United States, 2014 in the United States and more. Due to the lack of concentration and dedication that is actually required for FL, they cannot achieve this FL milestone. OccultZone (Talk • Contributions • Log) 11:00, 4 May 2015 (UTC)

You're supporting a proposal because we're lacking concentration? Yes, those articles are awful, awful, but we have many "timeline" featured lists which could be used as a basis if someone could be bothered to look into it. The Rambling Man (talk) 11:18, 4 May 2015 (UTC)

• Support I think the biggest difference between F(L)C and a G(L)C is in the procedure. It takes multiple reviewers to approve a F(L)C nomination, it would only take one reviewer to approve a G(L)C nomination. You can only nominate one article/list at a time for F(L)C but you could nominate multiple for G(L)C simultaneously. The quality of a F(L)C article/lists increases by the diversity of multiple reviewers contributing. Subsequently a list reviewed by just one person most likely will suffer in quality because every review has weaknesses and strength. Having said that, I think a GL-class makes sense, although the criteria may only be marginally different. MisterBee1966 (talk) 12:16, 4 May 2015 (UTC)
• Partial Support The WP:MHA#SCALE approach seems good, I find that the top levels of perfection are unattainable in many cases, but there is a need to bring a start class list upto a C. If you are documenting List of watermills in the United Kingdom or worse still List of watermills in the World then having some lower level goals would be helpful. New editors would probably be happy to work in this uncontraversial area if we had low level goals to set them. -- Clem Rutter (talk) 13:27, 4 May 2015 (UTC)
• Question it looks, to me at least, like the most usual candidates for this "good list" idea are those which are just very long and therefore a lot of work is required to suitably format and reference them, is that the idea? The Rambling Man (talk) 13:38, 4 May 2015 (UTC)

  No the idea is that lists that are not FA class get recognition. There is no minimum entries to a list as long as it is WP:NOTABLE — Preceding unsigned comment added by TheMagikCow (talk • contribs) 16:14, 4 May 2015

  I'm afraid I don't understand your point at all. The Rambling Man (talk) 19:44, 4 May 2015 (UTC)

• I really wish this discussion had not been fragmented on Wikipedia:Village pump (idea lab)/Archive 17#Good Lists. That said, I Support this proposal. — {{U|Technical 13}} (e • t • c) 14:03, 4 May 2015 (UTC)
• Oppose we've had this discussion before (probably been a few years, though) and my opinion is unchanged: There does not exist a quality gap necessary to fill with a Good List concept. Any putative "Good list" would essentially be a featured list anyways. --Jayron32 14:56, 4 May 2015 (UTC)
• Oppose - any "good list" would still need to be complete and be referenced, right? Just like GAs? At that point you might as well nominate it for FL- you're basically there, most lists don't have enough prose to get tripped up on. I appreciate the idea of having an intermediate level for really long lists that take a lot of effort, but "a lot of effort but is not done" isn't really a good point to slap a star on something. I'd like to see some examples from the supporters of what current lists they'd consider "good" - the examples posted so far are just "would take a lot of work to complete", which isn't the same thing at all. --PresN 16:13, 4 May 2015 (UTC)

  Exactly. It's just about lists which need more work, nothing more. The Rambling Man (talk) 19:44, 4 May 2015 (UTC)

• Support As nominator. TheMagikCow (talk) 19:13, 4 May 2015 (UTC)
• Oppose I don't see any tangible benefit to this idea. Beeblebrox (talk) 23:58, 4 May 2015 (UTC)
• Oppose. Per Beeblebrox. --Dweller (talk) 09:30, 6 May 2015 (UTC)
• Oppose featured list is already very easy to achieve and we seem to have a disproportional mount of these already. So having this would just make a lower quality bar that would enable an easy to achieve recognition. Instead just go for FL. Graeme Bartlett (talk) 08:32, 8 May 2015 (UTC)
• Oppose. What nonsense, this is simply lowering the standard of a list. FLs are very easy to achieve. HYH.124 (talk) 08:46, 8 May 2015 (UTC)
• Oppose. It is not difficult to promote any regular list to featured list. If the process itself is like the good article review process, it would probably take less time to promote an article to featured list than good list, due to the relatively little work needed and the backlog of a unilateral review process. Esquivalience ^t 02:55, 9 May 2015 (UTC)
• Oppose. The English Wikipedia is biggest wikipedia; but I think there is not enough list article to make GL.--Skky999 (talk) 02:36, 10 May 2015 (UTC)
• Support: there are multiple lists present that are not FL but they can make GL and need recognition. It might also help identify, which lists have potential to be GLs and would redirect short term efforts towards those lists as well. --lTopGunl (talk) 16:32, 16 May 2015 (UTC)
• Support. I am in agreement with MisterBee1966 regarding the process of GA and FL assessments. Progressing to expand List article's assessments is in the right direction for improvement of List articles in the encyclopedia by giving editors a process to improve List articles in the same manner as Articles rather than the antiquated back of the bus assessment of Lists (Stub, List and FL). Gmcbjames (talk) 01:38, 18 May 2015 (UTC)
• Support: It's good to encourage incremental article improvement with milestones like this, and lack of this particular one is kind of glaring.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  12:27, 24 May 2015 (UTC)
• Strong Oppose. The criteria is pretty much the same as FL, plus featured list don't take that much effort to make; the difference between the two would be splitting hairs and just make more backlogs for the sake of more backlogs and bureaucracy. Most of the supports not only don't persuade me, but convince me of how pointless an exercise GL would be. Wizardman 17:48, 25 May 2015 (UTC)
• Support --- :D Derry Adama (talk) 14:08, 29 May 2015 (UTC)
• Oppose The amount of work that goes in to writing an article makes it worthwhile to have a pause and recognize that it's at a decent level ("good") and another when it reaches featured level. Lists don't have the same level of work to them; once they're complete and referenced, there's not a lot more to be done to make it featured. Matt Deres (talk) 15:56, 5 June 2015 (UTC)

It's time to abolish the "Ignore the Diacritics" rule everywhere

Reasons:

1. Botching diacritics can be seen as very disrespectful by native speakers;
2. Botching diacritics can be a strong indication that the editor has little or no knowledge/acknoledgement of their functions and/or linguistic/cultural significance;
3. With new generations of computers and tablets becoming more and more available, the "I don't know how to type it" excuse is becoming no longer valid.

Based on the above reasons, I strongly propose that it's time for Wikipedia to completely abolish the "ignore the diacritics" rule (or convention or whatever). Cedric tsan cantonais 19:29, 5 May 2015 (UTC)

What rule is that? Where have you seen it being applied? --Redrose64 (talk) 19:46, 5 May 2015 (UTC)

Presumably the guideline at WP:DIACRITICS. Whic does not call to "ignore the Diacritics". -- Gadget850 ^talk 20:29, 5 May 2015 (UTC)

It might as well. Though the use of diacritics is "neither encouraged nor discouraged", the fact remains that we're instructed to make that decision off the back of English sources, which have - by and large and for the most part - omitted diacritics, for a variety of reasons. Alakzi (talk) 20:38, 5 May 2015 (UTC)

"we're instructed to make that decision" Where? -- Gadget850 ^talk 21:02, 5 May 2015 (UTC)

It's the first sentence of WP:DIACRITICS. See also MOS:PN#Diacritics, which contradicts it. Alakzi (talk) 21:13, 5 May 2015 (UTC)

WP:DIACRITICS (which, by the way, only applies to article titles), says "when deciding between versions of a word which differ in the use or non-use of modified letters, follow the general usage in reliable sources that are written in the English language." That is pretty easily derived from WP:V (and, by extension, WP:NONENG). If the common usage in English includes diacritics, that is what's used in the English Wikipedia. If the native language uses diacritics but English doesn't, then neither does the English Wikipedia.

However, the original poster seems to be referring to this diff, in which User:Canuckian89 said that "Wikipedia convention is that diacritics aren't used on NHL-related pages". That is referring to Wikipedia:Naming conventions (ice hockey), which states "All North American hockey pages should have player names without diacritics, except where their use is likewise customary (specifically, in the Quebec Major Junior Hockey League and the Ligue Nord-Américaine de Hockey)." That wording was put in by User:Djsasso in 2003 — previously the guideline stated that they should use "most common spelling in English as described by reputable reference books and media outlets. In most cases this means the omission of diacritics and other characters not commonly found in English.", which is in line with WP:V and WP:NONENG. --Ahecht (TALK
PAGE) 21:18, 5 May 2015 (UTC)

@Ahecht Thank you. This is the very first convention that I seek to repeal. As for references, I would argue that if we are willing to look at sources in other languages (which, according to my experiences, are equally valid in English Wikipedia), there're plenty of sources indicating the correct use of diacritics. For example, in this news release by the Czech Ice Hockey Association, more than one NHL players, including Petr Průcha, David Krejčí and Zdeno Chára, are mentioned and the diacritics in theirs names. Also, the Czech were nice enough to keep all diacritics in players' names, regardless of the languages they're in. All these are making Wikipedia:Naming conventions (ice hockey), which tries to justify botching diacritics, invalid. Also, if TSN and ESPN are seen as valid sources, the Czech Ice Hockey Association just can't be any less valid. Cedric tsan cantonais 22:01, 5 May 2015 (UTC)

If the problem is specific to Wikipedia:Naming conventions (ice hockey), why discuss it here, not at Wikipedia talk:Naming conventions (ice hockey) (plus an advisory note to WT:WikiProject Ice Hockey). --Redrose64 (talk) 22:54, 5 May 2015 (UTC)

I wouldn't say that non-english sources are "equally valid in English Wikipedia". WP:NONENG says "However, because this is the English-language Wikipedia, English-language sources are preferred over non-English ones whenever English sources of equal quality and relevance are available." --Ahecht (TALK
PAGE) 23:23, 5 May 2015 (UTC)

The key words here are whenever English sources of equal quality and relevance are available". In terms of diacritics, I would argue that there are little or no English sources "of equal quality and relevance" available, due to my observation that many English sources, other than English Wikipedia, would already botch the diacritics before making their way into English Wikipedia and, therefore, cannot match the quality and relevance of certain non-English sources. Henceforth, my argument that certain non-English sources, like the news release I posted above, should be deemed equally valid in the case of diacritics.

Also, since my main focus is on Cantonese Wikipedia, I don't edit English Wikipedia as much and that's why I wasn't aware of the existence of Wikipedia:Naming conventions (ice hockey). But now that I know there's this convention, I'll start working on getting the "ignore the diacritics" part amended or abolished.Cedric tsan cantonais 00:08, 6 May 2015 (UTC)

You say "my observation that many English sources... botch the diacritics". You're saying English Sources are "botching" how things are written in English. Even if you're right, Wikipedia is not the place to try to fix it. We follow the sources, we don't lead. Alsee (talk) 05:44, 6 May 2015 (UTC)

I'm not "leading". I'm just cherry-picking the best sources to follow. In the case of diacritics, many non-English sources had proven themselves more trust-worthy than their English counterparts. — Cedric tsan cantonais 17:36, 6 May 2015 (UTC)

• As one of the parties of the compromise over on the hockey WikiProject, I've got two cents to throw in. The compromise was the truce in a long and contentious edit war involving many editors (myself included) and many articles. No one was really happy with it, and there've been a couple attempts over the years since to overturn it, but it's kept the edit warring down to a dull roar.

  My strong preference was then, and remains, to recognize that this is the English Wikipedia; not the Czech, not the French, not the Swedish or Finnish or Viet or any other national Wikipedia that commonly uses diacritics. The English language does not, for the most part, use diacritical marks. I would be thrilled to see WP:DIACRITICS extended project-wide, the hockey articles included. That being said, it's obvious from the guideline itself that private compromises have been enacted -- this MOS section dealing with Ireland-related articles, for one -- and I don't see any horde of editors coming in to force a change to go over any better than it would have on what I see from archives was a long and bitter dispute on those articles. Ravenswing 01:59, 6 May 2015 (UTC)

• I have the same but opposite opinion as Ravenswing. I think they should be used everywhere because they are proper names and as such don't change between languages so if they have diacritics on one they have diacritics in the other. That being said, what Ravenswing says about it being a compromise is true. Diacritics have been an all out war at times on the wiki and the battle over them has left many people on both sides of the issue blocked and/or banned. As such the hockey project for hockey articles in the absence of a true wiki-wide consensus came to a consensus to damper down the edit warring that was constantly on going. It is a topic I generally recommend editors staying away from and usually counsel people to leave it like you found it in the same vein as ENGVAR. I would note the edit of mine being referenced above goes back farther than 2013, it was just added to that particular page at that point, however, it had been listed elsewhere for years before that. -DJSasso (talk) 13:52, 6 May 2015 (UTC)

• I would be shocked to see WP:DIACRITICS extended project-wide since that would be a major sign of collective ignorance. I'm considering adding reference(s) whenever I'm writing diacritics. This is kind of a last-resort measure but now that I know there's such strong opposition towards diacritics, I've got little choice. — Cedric tsan cantonais 17:36, 6 May 2015 (UTC)

• I think many people would view something like that as being disruptive to make a point. Resolute 20:17, 8 May 2015 (UTC)

• I see no reason to change anything here. I'd say 99.3% of the time diacritics aren't appropriate on the English Wikipedia because they are not in the English alphabet. I'll counter your claim that they are proper names and as such don't change between languages so if they have diacritics on one they have diacritics in the other with Hillary Clinton - Hilarė Klėntuon - Hillary Clintonová or maybe even Гілары Клінтан from the collapsed section in support #53 of Talk:Hillary Rodham Clinton/April 2015 move request#Support. We're not using Hilarė Klėntuon because this is English, in the same light, diacritics don't belong on other names in English. Now, as for the claim that "the "I don't know how to type it" excuse is becoming no longer valid, I'm not buying that either, my English qwerty keyboard still doesn't support those characters without knowing the unicode values for each, and to expect anyone to have a huge chart on the wall or know which character means what is unreasonable. — {{U|Technical 13}} (e • t • c) 04:13, 7 May 2015 (UTC)
  • And that is a strawman, Hilarė Klėntuon or Hillary Clintonová are not her name. If they were, and if they were what she used for her name, then yes they would be completely appropriate. You don't need a huge chart on the wall to know what the characters mean, if you don't know what they mean you ignore them just like you are seeking to do in print. As for typing it, its great that the edit box actually has them included so you don't have to know the unicode values, you just click a link. They aren't in the English Alphabet but they are in the English Orthography. -DJSasso (talk) 13:29, 7 May 2015 (UTC)
  • Have you ever visited any Vietnamese article? You might be nonplussed. Alakzi (talk) 13:45, 7 May 2015 (UTC)
  • With all due respect, saying that they (diacritics) are not in the English alphabet only shows that you have nearly zero knowledge of English history. Back in the old days, "one, two, three, four" used to be written as "ān, twā, þrēo, fēowor" — and, still, I don't think anyone can argue that "these are not English words". As for typing, I use a QWERTY keyboard, too, but typing alphabets like áàêęçţčạẇėīōåøœæłțůžĉĝñẽã#€ëýȳÿ are almost as easy as one-two-three (and I don't even need to bring up the special character panel below the edit box). Of course, this took me quite a bit of practise, ḃůţ ħéÿ, ṗřæċťïşẽ ṁąḱęś ṕèřƒēçť! —Cedric tsan cantonais 16:24, 7 May 2015 (UTC)
    • Using that argument suggests that you have a poor knowledge of English history. You do understand, don't you, that however much the English alphabet was different half a thousand years ago, we're editing here on the English Wikipedia, not the Middle English Wikipedia? Your argument is the moral equivalent of claiming that Americans are still subjects of the British Crown, just because they happened to be a few centuries ago. Yogh, thorn, eth, and wynn haven't been in the English language in several centuries, and neither are diacritical marks. Ravenswing 11:43, 8 May 2015 (UTC)
      • You know what? I'm pretty sure that English had already adopted Latin alphabets by the time Beowulf became codified. And yes, I'm totally aware that ð, þ, ƿ, etc., used to be alphabets of Old English, and I would totally advocate re-adopting at least ð and þ. And no, that does not equal me arguing that US citizens are still British subjects because the US had already declared their independence while you never specified which period of English we're talking about. OTOH, arguing that diacritical marks haven't been in the English language is simply ignorant. As far as I know, New York Times, for example, is sticking to café rather than cafe, and I don't think you can argue that "café" is not an English word now, can you? Cedric tsan cantonais 16:50, 8 May 2015 (UTC)
• Do I get this right, Motörhead, Hüsker Dü, Blue Öyster Cult are wrongly named lemma because there is no diacritical sign in the poor english language? European top footballers like Petr Čech, Tomáš Rosický, Tomáš Ujfaluši, Thomas Müller, Jérôme Boateng, André Schürrle, İlkay Gündoğan and so forth (I just looked up Čech and German) should be dumbed down as well? That would be a great loss. The article should be proper named, the dumbed-down diacritic-less version should be a redirect imho. Grüße vom Sänger ♫ ^(talk) 14:01, 8 May 2015 (UTC)
  • Well, I would say the heavy metal umlat is less a problem of language, and more one of trademark. Resolute 20:17, 8 May 2015 (UTC)

• This debate is ultimately a rehash of one that has long plagued the project. And, as with Ravenswing and DJSasso above, I am one of the editors that helped draft the compromise that brought about a truce in WP:HOCKEY's diacritics war. (The short version of the compromise is that NHL and NA team/league articles hide them, while European articles and all player articles show them.) At the time, I was one of the people with the "English Alphabet" mentality, but have subsequently 'switched sides' and favour their use. But from either perspective, and recognizing the overall lack of consensus, I think our compromise does a good job of maintaining order at this point in time. Though it should be noted that times are changing, as diacritical marks are slowly making appearances on NA team hockey jerseys, publications, etc. But that is in its infancy, and I don't see a need to revisit this now. Resolute 20:17, 8 May 2015 (UTC)
  • I beg to differ, sir/madam. As the means of inputting diacritics became more and more easily accessible, I would argue that now is the time for the pro-diacritic side to at least make a push to popularise diacritics (provided that they're used correctly, of course). And by "making a push", I mean that the pro-diacritic side should initiate conversations in order to make diacritics more and more widely accepted. Also, I think now is the time to amend the rules so when pro-diacritic users open up new articles with diacritics, anti-diacritic users won't be able to mess things around in these new articles and push them back into the Old Régime. Cedric tsan cantonais 18:05, 10 May 2015 (UTC)
    • It is not Wikipedia's place to right great wrongs. Nor is it our place to popularize diacritics. I sympathize with your viewpoint, but it will be some time yet before the movement of technology reaches the point where a consensus will form in your favour on Wikipedia. Resolute 18:08, 10 May 2015 (UTC)
      • In that case, I'll just keep telling others to "stop f*cking around on the pages that I opened", even though it wouldn't be likely for me to open up that many articles on English Wikipedia since Cantonese Wiki Projects remain my priority. — Cedric tsan cantonais 21:34, 10 May 2015 (UTC)
• The issue boils down to WP:COMMONNAME and the US/UK news media's inability to deal with diacritics in a sensible fashion. Most 'foreigners' new topics are introduced via the news media so their known-as names are those used by the media. The media refuses to deal with diacritics. Therefore WP:COMMONNAME is typically the topics true name minus the diacritics. Personally I prefer to use VIAF for preferred ASCII renderings of non-ASCII names where possible. Stuartyeates (talk) 22:05, 10 May 2015 (UTC)

  With all due respect, sir/madam, I prefer Unicode. :P — CÉDRIC TSÄN CANTONAIS SAYS NO TO I.P. EDITS! 17:31, 13 May 2015 (UTC)

• It feels weird to have this discussion without User:PBS involved. Also, why isn't this discussion about a general rule over at the talk page for the actual rule? WhatamIdoing (talk) 05:45, 17 May 2015 (UTC)

Thanks for the heads up WhatamIdoing. The title of this section says It's time to abolish the "Ignore the Diacritics" rule everywhere. There is not such rule what rules there are say follow usage in reliable English language sources.

The arguments based on WP:COMMONNAME—for which I think the link WP:UCRN (Use commonly recognizable names) is preferable—which is an important part of the Article titles policy is limited in scope to article titles. As is the guidance given in the policy section called "Foreign names and anglicization" (link WP:UE) and the explanatory guidelines called Wikipedia:Naming conventions (use English) as section of which called "Modified letters" (link WP:DIACRITICS)

The sections of the MOS that covers usage within articles (other than the subject of an article) is MOS:FOREIGN and also Wikipedia:Manual of Style/Proper names § Diacritics.

The fundamental problem here is exactly the same as spelling in general. If one reads a paragraph that contains an unusual spelling such as color/colour and it is not in ones own dialect it tends to look odd, and editors will wish to change it. This was the driving force behind the creation of the rule about MOS:ENGVAR—and it is something that some third party style guides also describe (see here). The use of accent marks on names tends to spark the same annoyance as "incorrect" spellings. This tends to split the community by native monoglot English speakers/reader and those familiar with the presentation of the word in another language. For example I would imagine that most French people reading English Wikipedia see nothing odd in the use of Ivory Coast but if the name used is "Cote d'Ivoire" then it will bother them because they will be used to seeing it as "Côte d'Ivoire and like the color/colour spelling may wish to "correct" it.

On the alphabet. When one is at school in the English speaking world the alphabet is the 26 letter of the alphabet song, it does not include "&" or any other character. Accent marks are not introduced to children until they learn a "Foreign" language (this includes words such as cafe/café which if the child notices will be explained ways as a foreign word not yet fully Anglicised), so consequently accent marks are seen by most English speakers as a foreign things (blame it on teachers). Now I know that some English speakers are passionate about using the "correct" accent marks on words but they (both the users and the letters) are often seen as eccentric or pretentious by monglot English speakers, (an example of this comes across on pronunciation as well for words like Porsche#Pronunciation of "Porsche" those who pronounce it the German way are assumed either to own one or want to own one).

Faced with the instability this problem of "it does not look right", the Wikipedia community has several options.

• No guidance at all and a local consensus for each article. This was ruled out for the same reason that MOS:ENGVAR exists. Article content becomes unstable as people care passionately about this issue and some will edit war over it, so the community needed to issues guidance that reflects a wider community view.
• Guidance that accent marks will never be used.
• Guidance that accent marks will always be used.
• Guidance based on a rule similar to the Economist guideline that those languages which a generally educated person in an English language country ought to know, eg French for the British, Spanish for Americans, (the Economist also includes German and Portuguese).
• Guidance based on English usage. The first advantage of this one is simple to implement and it is less arbitrary than the Economist rule eg why German and not Italian? The second advantage is it produces spellings with "least surprise" for the majority of readers and therefore probably causes the least annoyance. Third it is simple to understand and ties in with the concepts behind "Use commonly recognizable names" (WP:UCRN) which in turn is based on the policy WP:V.

So while following usage in reliable English language sources does not always produce the "best" results, it has proved a reasonable and sustainable method for settling disputes over the "best" spelling to use for many years, because using sources to prove a point is widely used when trying to reach a consensus in many areas of disagreement in on Wikiepdia talk pages. For example the initiator of this section uses a source to make a point:

"As far as I know, New York Times, for example, is sticking to café rather than cafe, and I don't think you can argue that "café" is not an English word now, can you? Cedric tsan cantonais"

This is how the policy is meant to work and it come naturally into play among experienced Wikipedians because it is so frequently used in debates about titles and content. And user:Cedric tsan cantonais when you wished to show that "café" is an English spelling you turned to an authoritative English language source; you did not use a French source such as here (the first page of who's survey seems to contradict your findings). But your point still stands, as does mine that when we as editors discuss the "correct" usage of "Cafe" and "Café" we turn to reliable English language sources to decide on English language usage, and that is what the policies and guidelines reflect. We may or may not disagree on which spelling we think looks better (is more correct), or whatever, but providing we are editing in good faith, even if we do not agree on those issues, we may well be able to agree on what is most frequently used in English reliable sources (even if we we are surprised by the finding and do not like the result). The guidance only breaks down when someone ignores usage (or plays the system by arguing that only sources that reflect their bias are reliable), because as editors editing in good faith, we can always go back to whatever the original usage was if reliable sources do not give a definitive answer. -- PBS (talk) 11:32, 17 May 2015 (UTC)

My two cents: Most of you are looking at this issue too narrowly. You're thinking of words or names in languages you're familiar with (like French in many of the examples), and think the only problem is diacritics on one or two letters. It isn't! Many other languages have have alphabets that have diverged more from the English (i.e, Latin) one than French did. These other languages have not only diacritics, but also additional or bizarrely modified letters, and worse, letters that look like English but are pronounced differently from their English cousin. The end of this spectrum are languages with completely different character shapes from English (e.g., Hebrew, Greek, Russian) or no alphabet at all (e.g., Chinese). At which point do we stop copying the topic's original native name, and start transliterating it into English? This is why we have an article called "Beijing", not "北京市", and "Pasha" not "paşa", because English speakers cannot read, and do not use, these foreign characters, so those are not useful as article names (but can appear in parantheses in the opening paragraph, of course). And if we do transliterate, it should be into some sort of commonly used English - not some phonetic alphabet. Check out http://en.wikipedia.org/wiki/Talk:Nazareth_Illit, where while everyone agreed that Hebrew names (in Hebrew letters) cannot be the name of English wikipedia articles, there was an argument whether the names of the articles should be some sort of theoretic transliteration nobody is familiar with, or the more commonly accepted simple transliteration into English.

87.69.227.74 (talk) 11:06, 18 May 2015 (UTC)

For those who claim that English uses its own "English alphabet", I have a simple message. There is no such thing as the ”English alphabet". English, like many other European languages, uses the Latin alphabet. It just doesn't use every possible letter available in that alphabet. Because of this convenience I myself, whose native language is Dutch, can read English without having to learn a different alphabet beforehand. And this example counts for any combination of languages which use the Latin alphabet. Russian, just like English, doesn't have its exclusive alphabet either. It uses the Cyrillic alphabet. Using or not using diacritics is not just a question of aesthetics, but actually one of spelling and, more importantly, pronunciation. Writing Petr Cech instead of Petr Čech provokes an entirely different and wrong pronunciation. Therefore we simply cannot ignore these characters. Transliterating should only between languages that use different alphabets or syllabaries (e.g. Kanji to Latin, Cyrillic to Latin,...). This is not the England (or even United States) wikipedia. This is an international encyclopedia, and this one is uses by many users, just like me, don't have English as a native language as well. Just claiming that all English speakers cannot read these "foreign" characters is blatantly ridiculous. We should really accept that millions of none native English speakers read this wikipedia as well. Therefore I support Cedric tsan cantonais's proposal to ditch this censoring of these characters which are even part of our alphabet. Tvx1 17:08, 18 May 2015 (UTC)

I agree with Tvx1's point. But I cannot let the claim 'There is no such thing as the ”English alphabet"' stand. Here is the English alphabet: ABCDEFGHIJKLMNOPQRSTUVWXYZ. Here is the Polish alphabet: AĄBCĆDEĘFGHIJKLŁMNŃOÓPRSŚTUWYZŹŻ. Both are derived from the classical Latin alphabet ABCDEFGHIKLMNOPQRSTVXYZ. Maproom (talk) 06:14, 22 May 2015 (UTC)

FWIW, no "support" or "oppose" !vote will have much weight here unless a proper WP:RFC is created. And I wish anyone who attempts it good fortune as I can tell you right now it will end as no consensus. Resolute 17:18, 18 May 2015 (UTC)

@User:Tvx1 you write "There is no such thing as the ”English alphabet”". As I said above disputes are often resolved by looking at sources. What is your reliable source for that statement? Because a search of Google Books of "English-alphabet" states "about 89,600 results" and it returns 960 books,[1] the same search but limited to the 21st century states "about 13,900 results" and about 670 books.[2] which refutes your statement. There is a Classical Latin Alphabet (which was derived from an earlier alphabet) from which the English Alphabet is derived, but contains its own extensions such as "W", other languages have their own alphabets derived from the Classical Latin Alphabet their own additions or subtractions. Those that are derived from the Classical Latin Alphabet can be amalgamated into what is today called the "Extended Latin Alphabet" (or "Latin Alphabet" for brevity), but whether that concept existed and was commonly used before 1960 and the need for a term in computer science I know not, however a search of Google books for "Extended Latin Alphabet" (About 1,740 results) tellingly returns "Extended Latin Alphabet Character Set for Bibliographic Use" ISO (1975) as the second oldest use of the term with one mention the year before.[3]. -- PBS (talk) 10:16, 19 May 2015 (UTC)

Boy do I differ with Tvx1 on this one. This is an English based Wikipedia. That's why we have so many different language encyclopedias to choose from. We use English sourcing whenever possible and we use the English alphabet when English sources lead us in that direction. We don't complain when the Serbian Wikipedia does strange things to US spellings nor should they when we do the same. We simply follow the English sources and use what the sources show us. Fyunck(click) (talk) 09:56, 21 May 2015 (UTC)

(Totally OT, why not Fyunch(click)?) --Thnidu (talk) 03:37, 30 May 2015 (UTC)

Oppose further use of diacritics - Fyunck hits the nail squarely on the head. Let's review some basic realities and first principles:

1. This is the English language Wikipedia;
2. The English language Wikipedia is written in English to serve readers who read English;
3. English is the native tongue of the overwhelming majority of English language readers of Wikipedia;
4. The overwhelming majority of native English speakers are completely unfamiliar with the diacritics added to the Latin alphabet in the Croatian, Czech, Danish, Estonian, German, Hungarian, Latvian, Lithuanian, Norwegian, Polish, Serbian, Slovak, Slovene, Turkish, Vietnamese.
5. Only a small percentage of English-speaking specialists learn these languages in American, British or Commonwealth secondary schools and universities. To the extent Americans learn a foreign language in high school or university, the overwhelming majority study Spanish or French. In short, the overwhelming majority of native English speakers cannot read or write a foreign language that makes widespread use of diacritical marks.
6. The standard QWERTY keyboard in use throughout the English-speaking world does not include diacritics, and cannot produce diacritical marks without resort to the alternative ASCII alternative character sets -- which requires not only some understanding of spelling in the particular foreign language, but also knowledge of the ASCII character maps and ASCII character codes.
7. To the extent the spelling and/or use of diacritical marks differ for an article title or subject, including proper names, we can and we should identify those differences in the first sentence of the lead of the article.
8. To the extent the spelling and/or use of diacritical marks differ for an article title or subject, including proper names, we can and we should create redirects from spellings with diacritical marks to standard English article titles without diacritics.
9. None of this intended as a slight to our international readers whose first language is not English; we love y'all and we appreciate your readership and editorial contributions, but demanding that native English speakers adopt foreign orthography for the English language Wikipedia is a bit over-the-top. One can only imagine the reaction of editors of the German, Hungarian or Serbian Wikipedias if native English writers demanded that those Wikis adopt English spelling and a diacritics-free orthography for articles about American, Australian, British, Canadian, Irish, and New Zealand subjects.
10. Bottom line: Wikipedia should follow the standard majority practices of mainstream publications in the English language when comes to the use of foreign diacritics and orthography. That means omitting the diacritics in the vast majority of cases.

Dirtlawyer1 (talk) 11:39, 21 May 2015 (UTC)

I'm not convinced that diacritics posit any major problem to English speakers. Firstly, technical issues are pretty much non-existent: search engines have got no trouble finding these pages, and we've set up redirects from diacritic-less titles, etc. Secondly, if a speaker of English cannot parse the diacritics, would they not read the text as they normally would? What good does stripping Latin-alphabet names of their diacritics do? Alakzi (talk) 12:00, 21 May 2015 (UTC)

Correction, the standard QUERTY keyboard can produce diacritics simply if the correct operating system is used. It has been simple to include many diacritics on the Macintosh since its inceptions and mobile keyboards make it even easier. Not to detract from the argument though, Windows and Linux do not, allow the easy addition of diacritics.

With that said, the remainder of the arguments are sound and one is missing but alluded to in the conclusion: how do the majority of English-language sources present the name? 208.81.212.222 (talk) 18:19, 21 May 2015 (UTC)

Unfortunately, 208.81.212.222/Anonymous, getting "the correct operating system" is not a very convenient operation for a user who needs it. If you ain't got it, you ain't gonna get it with a "command-control-shift-alt-OS"! --Thnidu (talk) 03:53, 30 May 2015 (UTC)

It's not a question of creating problems, although I give up on many tennis player names once too many diacritics start pouring in. It's a question on what is used in English sources and what the title should be. I'm not saying we shouldn't also mention the foreign spelling, of course we should. But for normal everyday usage we should use standard English as sourced from English sources. If that tells us to use résumé instead of resume then that's what we use. If it tells us to use Zurich instead of Zürich then ditto. We let everyone know alternate spellings exist and move on. It even causes problems when trying to copy and paste a tennis player name from wikipedia into huge databases like the International Tennis Federation. Unless you use standard English it comes back as "not found." So I use a "follow the English sources" viewpoint. If there really aren't any English sources then we move out and use other sources at our disposal. But today we are forced, yes forced, to use diacritics in tennis player names, even if 99% of sources do not. Often even if a player has dropped the use of them herself. And we are not allowed to even mention that a standard English version exists in 99% of sources, lest the diacritic police come down on us like thunder. English versions of player names are banished forever per tennis RfC. I don't fight it anymore unless I can prove that a player uses the non-diacritic version on their own websites, facebook and twitter accounts. It just isn't worth it. I don't know what is taught in Canadian or Australian schools, but US schools don't teach them. They only let us know they exist because a few words still use them on occasion. Fyunck(click) (talk) 19:17, 21 May 2015 (UTC)

I just happened upon this because I was on the page for a different query. I do agree with the OP for the reasons given, and because that's what redirects are for. The article title (and text), whether for a person or a place name, etc., should always be spelled with whatever diacritics are used by the person or place, with however many redirects as may be useful to help people find the article. I honestly don't understand why this should be controversial. Milkunderwood (talk) 04:14, 23 May 2015 (UTC)

Should we also put our Sevastopol article at Севасто́поль? Should we put our Tokyo article at 東京? That's what your logic proposes, using the original language spelling. The other argument is that we follow the sources. If Reliable Sources say the moon is made out of cheese, then we say the moon is made out of cheese. If the sources are wrong, Wikipedia is not a place to WP:RIGHTGREATWRONGS. If Reliable Sources say the English spelling for "Севасто́поль" is "Sevastopol", then we put the article at the English-language title "Sevastopol". If the sources are wrong, Wikipedia is not a place to WP:RIGHTGREATWRONGS. If Reliable Sources say the English spelling for "Tomáš Berdych" is "Tomas Berdych", the article should be at "Tomas Berdych". If the sources are wrong, Wikipedia is not a place to WP:RIGHTGREATWRONGS. Alsee (talk) 18:42, 23 May 2015 (UTC)

Expanding my comment, Google Search finds zero hits at the New York Times for "Tomáš Berdych", but 1330 hits for "Tomas Berdych". An argument that the New York Times misspelled something 1330 times isn't an argument that belongs on Wikipedia. A global Google Search for "Tomáš Berdych" -"Tomas Berdych" gives 1.1 million hits, and eight of the top ten hits are English Wikipedia, Croatian Wikipedia, four Czech language hits, and a pair of twitter hits. A global Google Search for "Tomas Berdych" -"Tomáš Berdych" gives 3.2 million hits, and the only one that isn't an English Reliable Source is an instagram hit. Why the heck do we have this article at Tomáš Berdych?? New York Times, Google, and almost all English Language Reliable Sources say that Севасто́поль is spelled Sevastopol in English, and Tomáš Berdych is spelled Tomas Berdych in English. Alsee (talk) 19:43, 23 May 2015 (UTC)

Re: "Should we also put our Sevastopol article at Севасто́поль? Should we put our Tokyo article at 東京?" That's an obvious red herring fallacy. Different writing systems (scripts) are not comparable to adding diacritics to Latin script. If I paint some stripes on my cat that doesn't make it comparable to a tiger. As for Tomáš Berdych/Tomas Berdych, the fact that you can find an isolated example of an article that may not be reliably sourced for the diacritics it uses is meaningless to the questions at issue here. I can probably find a rock star article that doesn't cite a source for its discography, but that doesn't mean rock star articles should categorically have their discographies deleted. You're certainly correct that WP:GREATWRONGS applies here, but it would be particularly directed at the kind of sustained campaign that's been going on for years by a handful of editors to rid Wikipedia and the rest of the English speaking world of the sinister menace of diacritics.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  13:27, 24 May 2015 (UTC)

• Comment (on original post and some responses to it): We're already mostly using diacritics where appropriate, and moving more toward doing so, despite years of tendentious WP:ADVOCACY against them by a handful of editors. So I don't see the point of the vague proposal. If there's an actual conflict between WP:DIACRITICS and MOS:PN#Diacritics, then normalize to what the MOS page says. MOS governs style, and the naming conventions (even WP:AT policy itself) defers to MOS on style matters, naturally. Conflicts between MOS and NC guidelines are uncommon, but as far as I can recall are always resolved in favor of what MOS says. E.g. the whole species common name capitalization mess we had for several years, with WP:NCFAUNA, WP:NCFLORA, MOS:LIFE, and I think some other page, too, all saying conflicting things, has long been normalized to what MOS:LIFE says. What was probably the single most WP:ACTIVIST RfC campaign in Wikipedia history, WP:BIRDCON, failed to gain consensus to change MOS:LIFE to follow what proponents of the now-rejected changes at NCFAUNA were advocating. That's a really strong precedent for cases like this.

  As for diacritics in particular, the problem with "most tennis sources [or whatever] don't use the diacritics" as some kind of WP style and titles rationale is that the reason they don't is expediency/laziness/disregard, not accuracy. Such sources are not reliable for what the proper form of a name is. Where we have reliable sources that demonstrate that someone's/something's name has a diacritic, then that fact about the styling of the name is reliably established. No amount of sources that just can't be bothered with it (including piles of random websites pulled up in Google searches, or publications of sports governing bodies who jingoistically refuse to respect diacritics) can undo this fact of verifiability. Journalistic (especially tabloid, news daily, television, and sportswriting) sources are utterly unreliable on this, because they are under intense deadline pressure, have editorial control almost entirely focused on getting reported main-story facts like dates and places and statistics and quotations fact-checked, are written for the lowest-common-denominator audience, and are mostly written by people who historically probably didn't know how to generate diacritics without looking it up in a manual. Yet even these kinds of sources are increasingly respecting diacritics, as it gets easier to do so and more expected in anglophone countries. People who live in less ethnically diverse places like Idaho or whatever are probably somewhat less aware of this than those who live in more culturally mixed places like Montreal, California, and Ireland, where names of everyday people, from local politicians to the very newscasters they're watching, often have diacritics. It's an obvious WP:SYSTEMICBIAS matter. Furthermore, it's downright absurd to suppose that we'd disrespect the proper styling of the names of thousands of subjects, many of them BLPs, simply because they're tennis players (or whatever) instead of physicists or painters. It's just not a rational result.

  We've all been over, again and again and again, at WT:AT, WT:MOS, WT:NCP, WP:RM, and many other places, how a WP:COMMONNAME analysis tells us what the common (or only real) name is (Sinéad O'Connor vs. Shinaid O. Conner), but does not govern how we style the name (Sinéad O'Connor vs Sinead O'Connor), which is a WP:MOS matter, determined in each case by the same kind of normal WP:RS analysis used to establish any other article fact. Re-re-re-raising a pretense of confusion or doubt about this at VP doesn't magically actually establish any confusion or doubt. It's just another stop in a long tour of WP:FORUMSHOPPING. This is a perennial waste of editorial time and energy.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  13:27, 24 May 2015 (UTC)

I agree with your points about a campaign by a handful of editors, about WP:FORUMSHOPPING, about a perennial waste of editorial time and energy. However you accuse the the New York Times of being "lazy" and "utterly unreliable". You accuse essentially the entire English Speaking World of WP:SYSTEMICBIAS. Even if New York Times is "lazy" and "utterly unreliable", even if English Speaking World has WP:SYSTEMICBIAS, Wikipedia is not a place to try to fix the outside world. Common usage by the English speaking world defines what is or is not English. The fact is that most English Sources consider the "English Language" to consist exclusively of A-Z and a-z. Exceptions to that practice are rare and extremely notable-as-exceptions. Most English sources translate the name "Пу́тин" into the English language as "Putin". Most English sources translate the name "Tomáš" into the English language as "Tomas". Translation is not "laziness". Our articles should have Пу́тин and Tomáš in the lead sentence, just as our Tokyo article has 東京 in the lead sentence. But our English article titles and English article prose normally shouldn't use the characters и š or 東 when the New York Times and other common English usage don't consider them a normal part of English prose.

Your argument is that the New York Times should stop translating Tomáš. Arguments about what the outside world should do, do not belong here. Alsee (talk) 01:58, 27 May 2015 (UTC)

@Alsee: I'll reply to this just so you know where the holes in your arguments are, but I'm collapsing it because they're obvious enough, no one else needs to wade through it.

Extended content

Yes, many mainstream publishers are lazy when it comes to things they don't want to be bothered with for expediency/disregard reasons. Looking at the NYT's own style guide, they have an explicit editorial policy to always properly use "accent marks" (a misnomer) for names and words in French, Italian, Spanish, Portuguese, and German, but to omit them from "other languages ... which are less familiar to most American[s]". However, they make an exception for American subjects themselves, and always use or don't use the diacritics as the subject prefers when this is known (as WP does for everyone, not just Americans), dropping them "if in doubt", and if they don't qualify under the . So, your belief that the NYT doesn't use diacritics is false, they just do it in a biased and expedient way. It's interesting that their only two rationales for this policy are that trying to use them is error-prone (which might actually be true regarding journalists under deadline pressure but has not proven to be an issue on WP), and that many fonts don't have the right characters, which was probably true when the book was published in 1999, but is not true since the widespread adoption of Unicode. I'd be very interested to see what the current, 2015-05, internal version says. Yes, mainstream newspapers are utterly unreliable on nuances like whether someone's name properly has diacritics in it; they are not linguistic and human nomenclature experts, they're newspapers. You're wandering into a common logic fault covered in detail at WP:Specialist style fallacy, the proposition that a source that is reliable for one kind of thing (e.g. news journalism) must somehow be reliable across the board. WP:Identifying reliable sources#Context matters explicitly warns against this idea. It's argument to authority to suggest that I must be wrong because nothing the NYT does could possibly be lazy/expedient and they could never be unreliable about anything. Next, the idea that an enormous class of people may have biased ideas about the rest of the world is the very definition of systemic bias! Your argumentum ad populum assertion that "the entire English Speaking World" [sic] does not use diacritics is false on its face anyway. Moving on, it's impossible for WP:MOS, WP:AT, or anything else on WP that okays the use of diacritics, to "fix the outside world"; all we're doing is writing articles the best ways we can for WP's purposes and audience. You're turning GREATWRONGS on its head; the purpose of it is to prevent people bringing their external, activistic concerns (like, say, diacritics are polluting the English language) and try to impose them on Wikipedia and its content. 'The fact is that most English Sources[sic] consider the "English Language" to consist exclusively of A-Z and a-z.' Prove it. (Hint: You can't, because it's absurd.) 'Exceptions to that practice are rare and extremely notable-as-exceptions.'[sic] Prove it. (Hint: You can't, because it's absurd.) I've already covered in detail why different writing systems, vs. using diacritics in the same writing system, are not comparable; simply repeating an argument that has already been refuted doesn't magically un-refute it. Using or not using diacritics is not a matter of translation; that word has a specific linguistic meaning (mi casa es su casa -> "my house is your house" is translation). Dropping diacritics (in English, that's anglicization) is not encompassed by the word translation (nor even is conversion between different writing systems; that's transliteration. You're confusing an array of unrelated linguistic ideas and processes. WP:COMPETENCE is required; your evidenced difficulties even with hyphenation and capitalization suggest that you understand little about these matters. It's very difficult to take your objections to diacritics seriously, when you keep getting the facts wrong, make unsupportable assumptions, and your reasoning ultimately boils down to WP:IDONTLIKEIT. How the NYT or whoever decides to write has no bearing on how Wikipedia decides to do so. Wikipedia is not the NYT, or anyone else but Wikipedia, and we do not write in news style, for a specific demographic (other than "everyone in the world who can at least partially understand English", if you want to call that a demographic). Finally, you're making up your own imaginary fantasy about what I think others "should" be doing. I don't actually believe NYT should be using diacritics more than they do; I think that's up to them and their market research. They have a single goal, which is selling as many newspapers as possible, primarily to an American WASP market. That's utterly unrelated to any WP goals.

 — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  01:56, 28 May 2015 (UTC)

Tomas is not a "translation" of Tomáš, that would be Tomash, but a lazy simplification and disregard for proper pronunciation. Simply ditching important pronunciation marks is just lazy. The 2 dots above my nick change the pronounciation of the "a" from [a] to [ɛ]. These are definitely not the same letters. Grüße vom Sänger ♫ ^(talk) 17:38, 28 May 2015 (UTC)

Actually in US English those two dots mean absolutely nothing (same with the ü and ß. We pronounce things the way teachers or others pronounce things. It's not like we are taught about diacritics.... unless perhaps we take an advanced linguistics course at a university, or maybe we see them when taking a foreign language course. The few English words with them are taught as anomalies or perhaps a fancy way of doing things like when we occasionally see café on signs instead of the normal cafe. We are taught they eventually fade away as they become a hindrance to writing and reading. I don't know what is taught in Canadian, UK or Australian schools so perhaps it's different there? Fyunck(click) (talk) 18:23, 28 May 2015 (UTC)

My sig in proper diacritic-free version should be "Gruesse vom Saenger", as ä=ae, ö=oe and ß=ss (or sometimes sz, but not with the czech pronunciation ;).

There is only one way to proper pronounce a persons names, and that is in the native language of the named person, only with geographic objects there are sometimes real translations that deviate from the "real" one, like München/Munich or Moskow/Moskwa. So you either have to use diacritics, or transscribe it to plain letters with the same english pronunciation, that's or Tomash, not Tomas, or what other solutions do you know to get the proper pronunciation across? --Grüße vom Sänger ♫ ^(talk) 05:44, 29 May 2015 (UTC)

That's your own viewpoint and not backed up by 99% of sourcing. Your name spelling in English is usually what English sources tell us it is, not what you tell us it is. My family name in Polish is Kołodziej, in English it's Kolodziej. We don't spell it with a "w" here. And when older relatives travel back to Poland they may or may not switch back to Kołodziej. English is very versatile in that its letters take on all kinds of sounds without needing diacritics. If someone wants to make a Z sound like a K in English we simply tell people that's how we pronounce it. We don't re-spell it phonetically. However to avoid confusion we would drop the B looking letter and make it ss as with "Johann Strauss." Now of course, Wikipedia can do what it likes by consensus. If enough editors agree it can certainly follow non-English sources rather than English sources. It does that often. But that won't change the English language or how it's taught outside of Wikipedia. Fyunck(click) (talk) 06:13, 29 May 2015 (UTC)

If you move to a foreign country and want to use your name there in the native writing in that land you have to decide for yourself how to do this: Rewrite your name that the pronunciation of the new spelling fits to the right pronunciation or ditch the right pronunciation and keep the spelling. Or even translate if possible to something completely different sounding with the same meaning. I know of an example where two brothers did so in different ways in my home village: The dutch "u" ist pronounced like the german "ü", and their name derived from Holland and includen an "u". One decided to be pronounced with an "u", the other changed his name to an "ü". (I would have a problem with the same letter if I moved to Holland, I had to choose whether tu change the letter to "oe" to keep the proper pronunciation or keep the letter and thus change it.

But that has only tangential relation with this topic here, as here it's about peoples names that still live in that country and thus have only one proper pronunciation and no need to decide anything. It's up to enWP to decide whether to respect their names and proper pronunciations or not. Grüße vom Sänger ♫ ^(talk) 09:22, 29 May 2015 (UTC)

"There is only one way to proper pronounce a persons names, and that is in the native language of the named person" Which is going to be awfully inconvenient for English speakers who are addressing someone whose native language is tonal or click. Contrary to the assertion above, people's names do get translated: consider Wenceslaus I, Duke of Bohemia, known as Václav in Czech. The old Christmas carol isn't wrong for using the English instead of the Czech. People also change the pronunciation of their names. I know two people who have permanently changed the pronunciation of their names (one for the sole purpose of helping people figure out how to spell it), several that use translations of their names (e.g., Diego if you speak Spanish, but James if you speak English), and two that choose a different pronunciation depending upon the language. It's impossible to say that "there is only one proper way to pronounce a person's name" when the person is using three different pronunciations himself. WhatamIdoing (talk) 09:40, 29 May 2015 (UTC)

So what if some people translate their names in foreign languages? Many many more don't. And for those who don't we can only use the native spelling, unless their native writing system is different to our Latin writing (e.g. Cyrillic, Katakana, ...). In such a case we cannot avoid using a transliteration. And for people who did translate their names, we could use such a translation if it is backed by a reliable source. Tvx1 18:30, 30 May 2015 (UTC)

• Oppose further use of diacritics as per Dirtlawyer1 and Fyunck(click). I've responded to people above, but this is my base-level response to the original question. The original question and other commenters asserting that the majority of English Language Reliable Sources are "botching" the English Language is not a valid argument to make on Wikipedia. We should follow general English language practice of English language Reliable Sources. Diacritics (usually) do not belong in English language article titles and prose. Alsee (talk) 05:38, 29 May 2015 (UTC)

• REDIRECTs !! I have a strong preference for keeping diacritics per the original language in proper names, but I recognize that not everyone shares it. I propose that for pages whose titles include names in the Latin alphabet
  1. Ideally, the title of an article should use the proper diacritization of the name, per the original language.
  2. But if it doesn't— and there may be good reasons, e.g., Ho Chi Minh, properly diacritized as "Hồ Chí Minh"— there should always be a redirect from the proper diacritization (as there is from Hồ Chí Minh).
  3. Partial diacritizations should also work, though not necessarily via a full redirect. This seems to be already covered, at least in part: typing Antonin Dvořák (with a plain "i") in the search box brings up three possibilities: Antonín Dvořák , Antonín Dvořák Theatre, and Antonín Dvořák Museum, all properly diacritized with "í".

--Thnidu (talk) 03:37, 30 May 2015 (UTC)

• Comment. What would be the next step ? A re-ignition of "The Dakota" war since Dakȟóta would be so more diacritic ? Pldx1 (talk) 10:04, 30 May 2015 (UTC)
• Comment. We should follow the kind of references a professional copy editor might consult. The Chicago Manual of Style recommends Merriam-Webster, Britannica, and American Heritage. British style guides recommend Oxford. WP:DIACRITICS is an incoherent mess. To see how this issue should be handled, take a look at the guideline for geographic place names. This guideline looks like it was modeled on the recommendations given in the CMOS. Too hip to be cool (talk) 23:48, 30 May 2015 (UTC) Wikipedia:Sockpuppet investigations/Kauffner
• Comment. Excuse me for butting in on a subject I know nothing about (and care even less) but this page is now on my watchlist and I have a question. User:Cedric tsan cantonais claimed that diacritics were used in English in "the old days", presumably meaning Old English judging by the examples he gives. So how is it that I can see the diacritics in Wikisource's text of Beowulf, but they are entirely absent from the original manuscript? Perhaps the diacritics are just a modern affectation to aid pronunciation and were never really part of the language. SpinningSpark 19:52, 30 May 2015 (UTC)

  See Old_English#Orthography. Accoring to that, some 'runic' letters and a few diacritics were used in OE manuscripts, but modern transcriptions have added diacritics to preserve distinctions in sound that would have been clear to a reader of the day, but not to a modern reader. DES ^(talk) 20:40, 30 May 2015 (UTC)

  So the short answer is no, "one, two, three, four" were not written as "ān, twā, þrēo, fēowor" in the old days, at least not usually. SpinningSpark 00:27, 31 May 2015 (UTC)

  This is a fair query. From what I understand, Latin didn't really have them, or old Germanic. The better question would be why did many other languages decide to add them while English didn't? Specifically the romance languages. I don't think anyone knows why English or Anglo-Saxon didn't jump on the bandwagon when other languages started added them. Fyunck(click) (talk) 05:52, 31 May 2015 (UTC)

• Comment - the editors inputting on the WP:DIACRITICS guideline historically have been tilted to the anti-diacritics or "English names for foreigners" lobby. As such the WP:DIACRITICS wording reflects an anachronism in conflict with consensus across 100,000s of articles which consistently use diacritics - except for one blonde tennis player who was moved in a RM including a previous incarnation of community-banned sockmaster Wikipedia:Sockpuppet investigations/Kauffner‎ above - and it is that consistent MOS across 100,000s of articles, confirmed in RFC after RFC, which represents the editor reality of the encyclopedia not a guideline with (still amazingly) local consensus defenders some of whom just don't like the way modern hardback English full font books, and/or en.wp article corpus are. In ictu oculi (talk) 22:33, 2 June 2015 (UTC)

A way to prevent revertwars from erupting

I propose a way to eliminate the current separation between the discussion and revision history pages, as it is a major cause of edit wars. For example, if one's contribution is undone (itself a much-abused tool), what is often the first instinct? To revert it! And leave a message in edit summary explaining why the undoer is wrong. They will in turn likely do the same... leaving an edit summary message saying why you are wrong. This only leads to reversion wars, because the only way to reply, to leave a message on that page, is to make an edit... The talk page? Indeed, leave the edit conflict, go there and navigate the wall of text, edit the page (which is more cumbersome than a message box system), then try to attract the other's attention... and who is going to start the discussion? The one whose version is current doesn't care anymore, the other one only cares about making their version current! If only messages could be posted inline on the revision history page, the whole process would become so much less reversome and smoother. The messages would be posted through a message box, and be posted on the page as expandible stubs, shown in chronological order between the revision versions. There would be clickable tags inside the messages that would scroll to the message being replied to, and tags to scroll to any replies. If there are more than eg five or ten messages between two revisions, the list could be collapsed. Messages posted privately from one of the users to another would show up as stubs that are only expandible by the sender and receiver. And a captcha in the messagebox would prevent spam and overuse.

The current system makes it pathologically ready to invalidate another user's contribution by deleting it entirely (which is distinctly inflammatory), and far too cumbersome to discuss changes instead. And this creates disproportionate damage when the edit in question is large, as it's more likely to be reverted. So even though most edits aren't reverted, reversion is a big problem.

Regarding undo: 'undo' is far too often a way of saying 'I sort of disagree, and can't be bothered to show subtlety'. Instead of 'undo', the button should be 'see changes' (with an edit box below a comparison of this version and the one preceeding it, and the ability to select and copy text from the two sides separately). This would encourage people to treat others' contributions with greater respect. — Preceding unsigned comment added by 85.211.109.208 (talk) 03:55, 7 May 2015 (UTC)

How often have I thought this: what a clumsy system - if you want to know for sure whether an editor has provided any justification for, e.g. a content removal, you have to check both the edit history and the talk page. In practice, article talk pages seem to be going out of fashion, with whole elaborate discussions taking place through a sequence of edit summaries. IP is also right that we have a structure that makes for conflict, not collaboration, owing to the fact that reverting is very much less trouble than judicious editing and discussion. If a system along the lines described turned out to be technically feasible it would be well worth pursuing. We do, though, need to keep the "undo" button, for straight reversion of straight vandalism: Noyster (talk), 11:15, 7 May 2015 (UTC)

WP:BRD. --Atlasowa (talk) 12:19, 7 May 2015 (UTC)

Posting nothing but a WP link, without anything in your own words, is unconstructive or even borderline linkspam. BRD?? there's a joke. Thag whole page is nothing but a wall of politically correct refusal to admit straight up that a monster has been created (and no offence to monsters), that noone seems willing to do something about 'undo' abuse, when it's so pathologically easy to wipe a contribution out in two clicks rather than bother editing with consideration, or devote entire days to discussion on a separate page...

I do think Noyster is right about the need to have a way to easily undo vandalism. I do think, however, that a Report Vandalism button could work better, by invoking a third party (an admin), to resolve arguments over whether deletion of a content the editor dislikes is vandalism or not. 85.211.108.179 (talk) 08:38, 9 May 2015 (UTC)

IP editor, the problem is that you (and other editors at that article) are engaging in WP:REVTALK. Don't Do That, chuckle. REVTALK actually encourages reverting because the only way to communicate is by preforming more reverts. Your proposal would actually make the problem worse.

A simple revert with edit summary is appropriate - the first time. Do not simply make an edit that you know is contentious and is likely to be reverted. Generally, you know someone already objects to your edit the moment you would be reverting a revert. I have a trick that actually works in your favor. If you would be reverting a revert, first explain your case on the Talk page then and make the revert with an edit summary pointing to the Talk page explanation. That breaks the REVTALK cycle and sends the other person to Talk. By being the person to break the cycle you (usually) get the advantage of keeping your version live on the article page during Talk discussions. If the other person reverts instead of Talking then they are blatantly at fault for editwarring.

P.S. You have the right to IP Edit, but it's easier to work here and you'll get more respect if you make a named account. Alsee (talk) 11:04, 10 May 2015 (UTC)

I've got a better solution: No more anonymous edits. Everyone who wants to edit Wikipedia should open up his/her/their own accounts. Statistics had told us that 80% of vandalism on Wikipedia are done by those hding behind IP addresses. If people truly want to contribute to Wikipedia, identifying themselves by opening up accounts really isn't that much to ask for. Cedric tsan cantonais 17:20, 11 May 2015 (UTC)

Preventing revert spats from occuring, is like preventing editors from having emotions. Nobody likes to see their additions or deletions reverted & quite often our reaction tends to be revert back. At that very moment, tempers flair. The only way you're gonna cut down this occurances, would be a Wikipedia-wide 1RR rule. GoodDay (talk) 17:40, 11 May 2015 (UTC)

'The only way to communicate is by preforming more reverts' is exactly what the proposal is addressing; to have comments posted in between page versions on the revision history page, instead of the (no) talk page where only tumbleweed proliferates. The very existence of the REVTALK article is like an admission that people find the talk pages way too separated from the centre of activity, and REVTALK for the convenience of having the conversations where the edits are.
Indeed noone likes 'being reverted' (or so it feels), and yes tempers flare... but often they flare even before that time, as soon as the dark red messages notification square appears in the top middle of the screen, clashing with the rest of the color scheme. The 'message' is often the automatic undo notification, meaning you are supposed to go and BRD the other... well-intentioned editor. This is why I don't browse logged in anymore - I want to read my beloved Wikipedia in peace, without looking over my shoulder all the time, for someone potentially reverting an edit I made months or (on quieter pages) years ago.

The problem is that the 'undo' gives people the wrong kind of power. By its design a powerful anti-vandalism tool, using it essentially says 'this edit is vandalous/superfluous'. All in just two clicks. If people instead edited actual text, they would put some care into it, and be less casual about erasing it. If i stead there was a button to open the altered section of the article for editing, and to show the difference that that revision had made, that would decrease the incidence of complete reversion. An infopopup should appear, telling that the other editor would be notified - this should be a prominent element, and give people a moment's pause.
-And by showing the differences, any vandalism would be obvious and easy to reverse, too. (the preceeding version of the page should be available in a box below in case of restoring deleted material)
85.211.108.179 (talk) 18:58, 12 May 2015 (UTC)

Would encouraging editors to perform dummy edits (edits that don't change the article in any visible way) with either a response or a "see talk page" instead of a response also address this problem? Darkfrog24 (talk) 04:43, 17 May 2015 (UTC)

Please don't do that. Histories are sufficiently hard to follow without a bunch of pointless dummy edits cluttering them further. The advice above is correct: the first revert should use a decent edit summary, and any second revert should be only after posting on talk, in which case the edit summary would include "see talk". Johnuniq (talk) 12:09, 17 May 2015 (UTC)

Darkfrog24: - I too thought about the leaving summaries via dummy edits, but people might be too tempted to edit once they have the edit window open. A more elegant way of posting short/collapsible comments on history would work better.

Johnuniq: - this advice would be an improvement compared to the current BRD, as it would not require people to plead, and then wait to receive the reverter's consent before putting back the material. The design of BRD is a prominent example of misunderstanding of humans, and misplaced expectations. It was supposed to 'highlight opposing views'... and it does this alright. BRD as it is might as well be 'Bold Rage Delete'. As a policy BRD altogether goes out the window in revert conflict. But at the start, it is what helps trigger it. BRD 'emboldens' potential 'reverters' (especially with the 'undo' link as prominent as it is). It implies that the immediate way to deal with (potentially any) edit is to obliterate (revert) it, rather than try to adapt it to the article content. The policy (once one reads it) does of course encourage people to work with the new edit. But that is not the popular perception borne from the phrase 'bold revert discuss'. People see BRD as excusing hair-trigger reverts. Most people do not actually see their edits as 'bold', and being reverted triggers a feeling of unfsirness, and a reaction to put it back. And maybe add the reason in an edit summary (not the talk page). And you'll find it hard to convince them of the fine difference. But there wouldn't be a whole WP waggling its finger at people for talking via edit summaries, if only there was a way to post 'summaries' without the 'edit' part. It would make it a nonissue, as people would post a reply on the history page and then edit. The entire edit cycle would go a lot smoother with this.

-- The preceding comment was unsigned.

I'll respond to this whole thread at once rather than interleave any more small replies:

1. WP:BRD process works fine usually, and when it is ignored (it's not a policy, remember), there's WP:3RR, so revertwarring cannot continue indefinitely.
2. We don't need a new way or place to leave messages. Edit summaries are for summarizing edits and providing concise rationales for them, not for carrying on conversations. Talk pages exist for that purpose.
3. Dummy edits to abuse the edit history system as an instant messaging system are a bad idea. Use a dummy edit to correct an erroneous previous edit summary of your own, not to try to carry on a conversation. Use the talk page for that.
4. If you get reverted, without there being a clear rationale for the revert, opening a talk page discussion justifying your change, then undoing the revert, with a pointer to that discussion in your edit summary, puts the pressure back on the other party to engage in the D part of BRD process instead of continuing to revert. But they may do it again anyway, on the grounds that your change was bold (B), has now been reverted (R), and so it should be discussed (D) and consensus reached. Such an observation is usually correct.
5. If the original revert had a clear rationale to begin with, in talk or in edit summary, the the ball is in the bold editor's court to convince others that the desired change should be made. (Note that this necessarily means you should check the talk page for relevant discussion before undoing a revert, and doing so has at least a little bit of a cooling-down effect on the knee-jerk reaction to want to undo a revert.)
6. If a revert or pattern of reverts is a one-editor WP:FILIBUSTERing attempt against a change no one else has a problem with, this should become apparent quickly in discussion, as will lack of any actual revert rationale, or one that doesn't make sense. If a filibusterer is going out of their way to cloud discussion to evade a finding of consensus against their view, open a formal WP:RFC about the proposed change. While that process is slower than some of us would like, it's more difficult to "game".
7. A third way of resolving such a dispute is often to pay attention to what a reverter is specifically objecting to and address it, while otherwise proceeding as usual, working around the objection. Far too often, someone objects to one change among three or ten or 40, and mass-reverts everything another editor has done at a page (or even everything all editors have done at the page), since the reverter's preferred version. While this is usually rude, sloppy, and disrespectful, more editwarring can often be forestalled by re-inserting the edits that were not specifically objected to, and taking the one contentious point to the talk page (and perhaps asking the other party not to do blanket reverts, since these tend to imply bad faith and discourage the participation of editors, whom we need more of not fewer).
8. That said, there are times when resetting a page back to a stable version is actually the best course of action, especially when one editor or camp of editors is insisting on one version of a change, and another is demanding an alternative change, but questions have been raised about whether any such change is needed at all. Not all reverts, even mass reverts, are a bad thing. This is especially true when the talk page already has active discussion(s) of the proposed changes and the various rationales for them.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  08:07, 25 May 2015 (UTC)
   

“WP:BRD process works fine usually” - are you even joking? There is absolutely no grounds for such a statement whatsoever. Why was 3RR was strengthened with a 'bright line rule 'etc, if it's all fine and and dandy?

Merely saying 'the talk page is preordained as the place for discussion by the Admin Gods' doesn't mean people actually use it. The gulf between 'history' and 'talk' remains unaddressed, and is such that many reverts often pass before anyone goes to talk. Going to the talk page feels like giving up, like being dragged down into a discussion that's out of sight, away from relevance and will stumble on forever.

And the part about WP:FILIBUSTER doesn't address kneejerk filibustering that comes from some editors' instinctive OWN, plus xenophobia.

So far these are just an intellectual rehashing of the status quo, while refusing to admit that there is any kind of problem at all. It's all 'go to page x' or 'open a thread on page y', except that when the solution is not intuitively, readily at hand, it's approaching uselessness in a majority of cases. To wit: the fact that people revtalk much rather than go to the talk page. It's unintuitive, clumsy, nauseatingly long. A place for endless geekish arguments may in fact strangely appeal to some wikipedians, but refusing to acknowledge that the talk page is regarded with instinctive distaste by a great many editor is a misjudgement of human psychology.85.211.108.65 (talk) 23:09, 26 May 2015 (UTC)

Consensus is Wikipedia's primary mode of decision making. That's not my opinion, that's a very well established and widely supported site policy. There's no way to form a consensus without discussion. The only way to prevent revert wars is to block people who engage in them and/or protect the page from editing. If you can't get down with that you aren't going to have a very good time editing Wikipedia. Beeblebrox (talk) 23:31, 26 May 2015 (UTC)

It might be possible to form a consensus without technically "discussing", in the simplest cases. (I'd bet that you and I could do it.) WhatamIdoing (talk) 08:24, 27 May 2015 (UTC)

The vast majority of consensus is formed without discussion, simply by edits being accepted silently.  — SMcCandlish ☺ ☏ ¢≽^ʌⱷ҅_ᴥⱷ^ʌ≼  02:21, 28 May 2015 (UTC)

True, but I assumed that Beeblebrox was thinking of a situation in which there was an actual dispute, rather than the most common case of silent-consensus editing. WhatamIdoing (talk) 09:43, 29 May 2015 (UTC)

(edit conflict) @85.211.108.65: I'm not sure what the point of all that hyperbole is. Moving past it, your response doesn't make sense to me. I made a statement that WP:BRD works (present tense), but you've replied with complaints about changes that were made a long time ago to WP:3RR, which isn't closely related. BRD is an optional, but generally expected practice, that relates strongly to WP:Consensus processes; 3RR is part of WP:Edit warring policy, which is about restraining disruptive behavior. The fact that reverts have something to do with both doesn't mean they should be confused with each other. I agree kneejerk filibustering by would-be page WP:OWNers is a real problem, but it wasn't the one I was addressing at the time, and is resolved the same way, anyhow. Admins don't tell us to use the talk page; Consensus policy does. Psychological incompatibility with using the talk page is a WP:COMPETENCE matter; not every human on the planet is temperamentally suited to editing WP collaboratively, and that's just too bad. If they won't engage in basic processes here, like having conversations, instead of abusing edit summaries to snipe dismissive barbs at each other, their participation tends to become increasingly disruptive and unsatisfactory, both for the encyclopedia and its editing community, and for themselves. I agree that the talk page system is clumsy, but it's what we have. I've seen the draft version of what they're developing to replace it, and feel that it's even worse in innumerable ways, but I"m sure I'll get used to it after they roll it out. Anyway, if you're going to play football, you learn the rules and play with the right equipment, you don't show up with a bowling ball and a fishing rod, and try to get everyone on the field to play some new game you want to invent using what you brought.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  02:20, 28 May 2015 (UTC)

Instead of 'psychological incompatibility' with the talk page, I meant recoil from its unwieldiness. (vs a more elegant discussion format that doesn't require re-editing and reloading whole pages). What's the point of saying - existing layout 'is what we have', 'yes it's bad and 'they' will replace it with something even worse in innumerable ways, but we'll get used to it? Might as well shut down the Village Pump, give up on discussing constructive changes. I didn't 'complain' about the changes to 3RR - I was saying that if BRD had been adequate in the first place, nobody would be making these changes. Being categorised differently won't stop them happening alongside. Although the gap between 3RR and BRD is the biggest problem, other than the revert-happiness encouraged by BRD itself.
Saying I'm trying to turn football into bowling/fishing is senseless. Not trying to create a 'new game', but to improve the existing one, by making collaboration easier. The point about BRD is that it's making consensus more difficult to achieve (especially with existing layout), and improvement is needed, that will make it easier for people to show their 'suitable temperament'.
I haven't seen the new system yet, but it's hard to imagine it's clumsier than this..? 85.211.105.223 (talk) 08:19, 4 June 2015 (UTC)

Which usergroups should be allowed to add and remove tags ?

It is now possible to manually add tags, provided they have been defined by admins at Special:Tags, and to remove these as well as undefined tags. Two userrights are added :

• The applychangetags right allows to add a tag when making an edit, which is useful for scripts since it allows to track edits made by the script. It is given to all registered users by default, and it is not proposed to change this.
• The changetags right allows to add tags after the edit has been made (typically by another user) and remove tags provided they are user defined or not defined at all. It is useful especially for bot tagging (vandalism, copyvios, etc), and the ability to remove them is needed in case of abuse or bot failure. It is given to all registered users by default.

In the original feature request, there was consensus to provide the abilities offered by the changetags userright to bots and sysops, but not beyond these two groups. As such, I suggest that this second right, changetags, be removed from the 'registered user' group, in accordance with the previous consensus, and added to 'bot' and 'sysop', for the following reason :

1. The user interface is quite visible in histories, logs and once phab:T98611 will have been resolved, contributions; which could be confusing for inexperienced users and of little general use. On the other hand, sysops already have the chechboxes of revision deletion so it's a minor change for them. (It is not shown currently since no manual tags have been defined. EDIT: But as soon as tags will be created for use by bots or scripts, the UI will be visible again.) See also Wikipedia:Village pump (technical)/Archive 136#Edit Tags.
2. The use case is relatively small, and when needed a sysop can be asked to make the cleanup (same as moving without redirect).
3. It's relatively easy to cause disruption with this feature by removing undefined tags which might still be of use, and in other ways once multiple manual tags will have been defined.

It has also been suggested to grant the 'changetags' userright to template editors and edit filter managers, to which I have no objection but which would require a consensus. Cenarium (talk) 16:58, 8 May 2015 (UTC)

• You do realize it is already hidden from all other users except sysops right, so we can't use it anyway. It was solved on VPT last week and in phab, don't know the number RN. EoRdE6^{(Come Talk to Me!)} 17:05, 8 May 2015 (UTC)
  • This was 'solved' only temporarily (and sysops can't see it either, for your information). When tags will have been defined, the UI will be visible again. I made this clearer. And even though the UI is hidden, the action can still be used. Cenarium (talk) 00:32, 9 May 2015 (UTC)
• I think we should move it to auto confirmed. Then hide the interface behind some type of opt in, requiring either a preferences setting or css/javascript to enable it. It seems no more likely to be abused than many other things auto-confirmed editors can already do, and the issue with it being so visible on the interface of everyone is mitigated. Also, so few editors commented on the user rights question in the previous discussion that it is a really weak consensus. Monty₈₄₅ 00:54, 9 May 2015 (UTC)
  • That was not a weak consensus. The proposal was for bot tagging of (other users') edits, and everyone supported bot tagging of edits, but nobody suggested going beyond that, i.e. allowing ordinary non-bot users to tag edits. Sysops need to be able to remove these for cleanup, which I described as 'mass untag' in the original proposal, so they should also have the right. You suggest to somehow 'hide' actions available to a usergroup by default. Is that some sort of security by obscurity ? I disagree with this approach. If a userright is not useful to a group, then we should not grant it. If it is useful, we should grant it. There is no preference option to hide/show this UI, and I do not expect one to be created. As for gadgets, these tend to be unreliable. And this would have the significant disadvantage of not showing the UI for those where this would actually be useful, i.e. sysops and members of the template editor or abuse filter manager groups. Cenarium (talk) 10:58, 9 May 2015 (UTC)
• I think this should be limited to bots and sysops, with the ability to grant it to other users should a strong need arise (I don't know if it ever will but its a possibility). I'm under the impression this feature was added so that bots could tag edits, not so that anyone could. Sam Walton (talk) 11:07, 9 May 2015 (UTC)
• I'd like this ability to be used for all sorts of scripts from the teahouse script, twinkle, to Technical 13's^[†] OneClickArchiver^[†] script. Since not all the maintainers for scripts that would be using this are sysops, TEs and EFs should be able to manage the tags for their scripts. I don't care if it's given directly to those existing group or if it's added to a new script/gadget maintainer group with a set of api/gadget/technically related permissions. — {{U|Technical 13}} (e • t • c) 11:35, 9 May 2015 (UTC)
  • Okay, so I created a test tag for OneClickArchiver on testwiki:Special:Tags and learned that in order to add labels and descriptions, tag managers would need to be able to create and edit pages in the MediaWiki namespace (I had to create testwiki:MediaWiki:Tag-OneClickArchiver and testwiki:MediaWiki:Tag-OneClickArchiver-description for my test to work properly). That being said, knowing that there has been some objection to the ability to edit interface pages being added to TE in the past (although I suppose WP:CCC), I'm thinking the best way to handle this is to create a new usergroup for "Scriptmaintainers" I'd suggest that this new group should be a vetted nomination RfX style process and that any permissions that may be needed to work on scripts should be granted to this new group. I'd think that at a bare minimum:
    • managechangetags Create and delete tags from the database
    • editinterface Edit the user interface (needed as mentioned above because tags use these interface pages, this is also where gadgets are stored)
    • edituserjs & editusercss Edit other users' JavaScript files & CSS files (this is why I suggested a vetted process, there is a lot of abandoned code that needs to be repaired on this wiki and forking it may not always be sufficient or appropriate because it is hard to maintain the attribution that way)
    • noratelimit (probably not minimum necessary, but would be useful)
    • apihighlimits (script = api = very useful for testing and working on scripts and improving ability to update template transclusions as needed.
    • tboverride per  Template editor
    • templateeditor per  Template editor
    • rollback (to quickly rollback a change to a script that has an undesired result that proper testing didn't reveal that could be damaging to the encyclopedia)

    I have to run, but I will happily finish this train of thought later and hope to see some feedback on it. — {{U|Technical 13}} (e • t • c) 22:49, 10 May 2015 (UTC)

We should settle this one way or the other, otherwise once user-defined tags will get created, we'll have another panic, so here's a poll. Cenarium (talk) 01:14, 17 May 2015 (UTC)

I should clarify that the poll is only on the changetags userright, for the reasons given in my original post. Cenarium (talk) 15:28, 17 May 2015 (UTC)

Option 1 (tag editing permissions)

The following usergroups may add or remove tags on arbitrary edits and logs (changetags userright) : bot, sysop, edit filter manager and template editor.

1. Support Since there's only consensus for bot tagging and script tagging, but not for manual tagging. Those usergroups would benefit from access, they may need to cleanup after bots and scripts, but autoconfirmed users in general have no use for it, and hiding the interface for all would make it harder for the former to find out about it when the need arises. Cenarium (talk) 01:14, 17 May 2015 (UTC)
2. This should be for managechangetags and related rights needed to accomplish this task if not already present. — {{U|Technical 13}} (e • t • c) 03:21, 17 May 2015 (UTC)
3. Okay, but this has nothing to do with editing templates..? — This, that and the other (talk) 04:15, 17 May 2015 (UTC)
   • I should note that I support giving this right to edit filter managers. It is conceivable that they may set up an edit filter that tags edits in error, and they might wish to remove those tags from edits after deactivating the relevant filter. — This, that and the other (talk) 01:31, 23 May 2015 (UTC)
4. Bot, sysop: yes. Edit filter manager and template editor, no, neither needs it for their job. A "changetageditor" group assignable by admins at WP:PERM, sure. Anomie⚔ 11:05, 17 May 2015 (UTC)
5. Support for admins and bots - I see no reason, in general, to allow non-admions to do it, except for plausably the need to rename tags - and this would be done by a bot. עוד מישהו Od Mishehu 11:21, 21 May 2015 (UTC)
6. Support, but only for admins and bots. Tags, as others have already stated, have nothing to do with editing templates. APerson (talk!) 18:45, 22 May 2015 (UTC)
7. Support the more limited proposal, at least for now. Let's see how tags work for a while. We can always come back and examine the use cases for autoconfirmed later. Also as others noted above, I don't see why template editors would be included here, aside from the general idea that they are "trustworthy". "Trustworthy" isn't really a use case. Alsee (talk) 02:33, 24 May 2015 (UTC)
8. Support admins and bots only. --L235 (t / c / ping in reply) 14:05, 24 May 2015 (UTC)
9. Support for admins, bots, and EFMs (to clean up after a bad edit filter). Not for template editors, though, as it seems out of scope. Jackmcbarn (talk) 01:34, 28 May 2015 (UTC)
10. Support for admins, bots, and EFMs, per Jackmcbarn. And for Template Editors, per SMcCandlish below. All the best: Rich Farmbrough, 17:43, 31 May 2015 (UTC).
    

Option 2 (tag editing permissions)

All autoconfirmed users may add or remove tags on arbitrary edits and logs (changetags userright), but the interface is hidden by default in common.css or js.

1. Support As its pretty much what I proposed above. I don't really see how disruption incorporating tags will be any worse than other auto-confirmed vandalism, so this seems the right permission level. By setting it up so that editors need to turn it on, hopefully most people will educate themselves on how they work (any any relevant policies on their use) before using them. Monty₈₄₅ 02:02, 17 May 2015 (UTC)
2. Yes, this should be for applychangetags and changetags — {{U|Technical 13}} (e • t • c) 03:23, 17 May 2015 (UTC)
3. Support: This isn't "dangerous" enough that it needs to be limited to admins. At worst limit it to templateeditors and similar. And allow templateeditors to do what was above suggested for "scriptmaintaners". We don't need yet another caste of editors. Either we're responsible and technically competent, or we're not. We don't need to fork the tech stuff into little techie sub-fiefdoms. If it's not so fraught with peril that only admins should be allowed to do something, just have templateeditors be a general class of technically proficient editors and stop making it so hierarchically, bureaucratically complicated.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  13:48, 24 May 2015 (UTC)
4. Support: not dangerous enough. Creating a new group for tagging and giving tagging permissions to template editors may create a new generation of hat collectors. Esquivalience ^t 21:53, 28 May 2015 (UTC)

Discussion (tag editing permissions)

WP:Tags has some technical details, but there should be an outline of why adding/removing tags might be desirable before discussing who is able to perform that operation. Are there any examples of how this activity would benefit the encyclopedia? I recently added a discretionary sanction notification here and its history shows the useful "Tag: discretionary sanctions alert". However, if it is technically possible for, say, template editors to manually add or remove that tag, its utility would be diminished. At the moment, the "Tag filter" search on a long history page provides a guaranteed way to quickly show whether or not a notification has been delivered. Things would be less certain if such tags could be added/removed manually, perhaps by accident. Why would it be helpful, say, for someone to add "references removed" tags to hundreds of edits? It sounds like just another thing to argue about, unless there is some known reason why manual tagging would be useful. Johnuniq (talk) 01:54, 17 May 2015 (UTC)

Any tag must be specifically activated for user editing before it could be edited. And further, a tag applied by an existing edit filter cannot be marked for user-editing (although the reverse could be done). So much of this is worrying about things that will probably never happen (i.e. unless some admin does something stupid). Anomie⚔ 11:05, 17 May 2015 (UTC)

• We'll also need to contact bot operators to see if they're interested in making their bots tag edits, for which I guess a BAG approval would be needed. A couple of bots I think of : ClueBot NG (talk · contribs) (for edits with a high prob of vandalism but not high enough for rollback), CommonsDelinker (talk · contribs) (some of the deleted commons files may be acceptable on enwiki), CorenSearchBot (talk · contribs) (copyvios, copy pastes, templates often get removed), EranBot (talk · contribs) (copyvios) and XLinkBot (talk · contribs) (bad links/spam).

Now, for scripts and such : WP:TW, WP:HG, WP:STiki. Should we have some sort of process for approving these, or just a discussion at WT:Tags ?

The last part would be replacing some of the tag-only edit filters, with bot requests. Cenarium (talk) 15:22, 17 May 2015 (UTC)

I'm not sure what sort of standard we need for new scripts, but well established widely used scripts should be fine with a basic discussion at WT:Tags. Alsee (talk) 02:53, 24 May 2015 (UTC)

Agreed. Cenarium (talk) 23:33, 24 May 2015 (UTC)

• I suspect I am not the only one who would appreciate it if someone could explain in plain, non-technical English what this is and why we might want to use it. Beeblebrox (talk) 14:31, 24 May 2015 (UTC)
  • Tags are useful for tracking certain kinds of edits, so that you could find all of the edits that did "X" through RecentChanges. Imagine, for example, that you care about the addition of a particular piece of wikitext markup (or spam-looking links, or copyvios, or whatever interests you): you could have a bot tag edits that insert it, and manually remove the tags after you review the edits. So that's one use: finding the exact diffs in which a given action was taken, even if it's since been reverted.
    Not knowing exactly how people will want to use this is IMO the strongest argument in favor of letting (almost) anyone use it/experiment with it. That's what we did with templates: anyone could create one, and the original creators of the template system were surprised to find that what editors ultimately wanted was a programming language. Letting a lot of people use it increases the odds that we'll find (and refine) useful and efficient ways for using this tool. I think this is something that would benefit from a brainstorming or "fail quickly" model: try lots of things, and quickly reject the ones that don't work. I don't think that a top-down or centrally planned model is going to work as well. WhatamIdoing (talk) 10:25, 29 May 2015 (UTC)
• FYI, there is already half a dozen manual tags in use on fr.wiki. Cenarium (talk) 23:33, 24 May 2015 (UTC)

Establish Wikipedia talk:MoS as the official page for style Q&A on Wikipedia

Because the proposal to establish a dedicated style noticeboard has fallen through, it is now proposed that Wikipedia talk:MoS be established as Wikipedia's official page for style Q&A. This would involve the following actions:

1) Adding text to the effect of "and for questions about the use of capitalization, punctuation, organization and other matters of style on Wikipedia" to "This is the talk page for discussing improvements to the Manual of Style page."

2) Inserting text to the effect of "ask style questions at Wikipedia talk:MoS" any place that would otherwise have pointed to a style noticeboard.

3) Inserting text to the effect of "ask style questions at Wikipedia talk:MoS (and not here)" in the talk pages of other style guide pages so that style Q&A is more centralized.

Here are the kinds of questions that people ask: 1, 2, 3.

The goal of this proposal is make help with Wikipedia style issues easier to find and more centralized without increasing opportunities for forum shopping. WT: MoS has already served as an unofficial Q&A board for many years. The discussion leading up to this proposal is available here. 05:06, 14 May 2015 (UTC)

Support: WT:MoS for Q&A

1. Support 1, 2, 3 The MoS has provided clear, low-drama Q&A for years. The problem with the current system is that not enough people know about it, there's overlap across multiple talk pages, and, because it's unofficial, people might think they're breaking rules by using it. A noticeboard might have solved these problems more cleanly, but actively guiding users with questions to the existing system will also do it. Darkfrog24 (talk) 05:06, 14 May 2015 (UTC)
2. Support 1, 2, 3 Moved to Support: One official page will help new editors/ editors with a question. TheMagikCow (talk) 14:40, 16 May 2015 (UTC)
3. Support 1, 2, 3 - Centralizing style issues is a good idea. Disagree with the editors who oppose. Robert McClenon (talk) 21:43, 16 May 2015 (UTC)
4. Support 1, 2, 3 Much as a greatly dislike the MoStafarian 'reasoning' process and the mad beaating by the reggaelation players here, there is a need for an identified place to ask questions that will be seen and responded to. My recent question on a side talk page probably didn't get seen by more than one morlock dreadlocked being. So while my emotional impulse is much the same as Beeblebrox, I see the need for "where to go" for reviewed questions. Shenme (talk) 05:13, 17 May 2015 (UTC)
5. Support 1, 2, 3 - An official page for Q&A about Wikipedia's Manual of Style would really help the newcomers. Having newcomers ask about MoS at the Administrator Noticeboard should not be the place to ask such questions: An official Q&A for MoS would serve as that place for questions about the policy in context. CookieMonster755 (talk) 23:03, 22 May 2015 (UTC)

   No-one has proposed the Administrator Noticeboard for such questions. The sensible alternative is the Help Desk. Maproom (talk) 10:58, 23 May 2015 (UTC)

6. Support. Given the amount of opposition, this is a rather token support. I honestly don't see the problem here. If there's problematic behavior or users, there's ANI. Also, MOS pages are already under discretionary sanctions, so problematic users can be removed quickly. NinjaRobotPirate (talk) 04:52, 24 May 2015 (UTC)

Support giving express permission

Users who support action #1 but oppose the rest of the proposal:

@Scs: (Steve Summit)

@Tevildo:

Put me down as Neutral on this issue. In my opinion, people should be encouraged to ask such questions on WP:HD rather than WT:MOS, but I don't think they should be required to, or prevented from asking them on WT:MOS. In short, I'm in favour of retaining the status quo. Tevildo (talk) 00:42, 2 June 2015 (UTC)

@SMcCandlish:

@Finell:

All users have permission to add or remove their own name from this list. Ask for any other changes. Darkfrog24 (talk) 23:04, 1 June 2015 (UTC)

Oppose: WT:MoS for Q&A

1. Oppose all – This flies in the face of the recent RfC, whereby a clear consensus was to not have any such designated place for style. What's more, locating the proposed space at the MoS gives the proposal a partisan air, allowing MoS editors to have undue influence on outside disputes. There is no way that this can be tolerated. Do not buy Mr Frog's canards about an "existing system". There is no existing system. The MoS talk page is only for discussing changes to the MoS, and nothing else. RGloucester — ☎ 14:27, 14 May 2015 (UTC)

   The previous proposal concerned whether or not to create a new noticeboard. No decision whatsoever was made regarding existing pages where Q&A is already taking place. By "existing system," I mean the fact that people ask style questions at WT:MoS and receive answers there: [4]. Darkfrog24 (talk) 20:09, 15 May 2015 (UTC)

2. Oppose largely per RGloucester. This is basically a rehash of the rejected proposal to create a style notice board. Calidum T|C 23:26, 14 May 2015 (UTC)

   Oppose We have the WP:HD TheMagikCow (talk) 14:38, 16 May 2015 (UTC) Moved to Support: One official page will help new editors/ editors with a question. TheMagikCow (talk) 14:40, 16 May 2015 (UTC)

3. Oppose I understand the intent here. If you have questions for admins you go to WP:AN. If you have questions about biographical articles you go to WP:BLPN, for sourcing we have WP:RSN and so on. So it should logically follow that if you have questions about writing style you go to the MOS, where the experts or "gurus" are. And that's where we run into a problem that is going to hamstring any attempt to do this unless and until it is fixed: the ranks of MOS regulars include a lot of grammar/punctuation obsessives, who wrongly believe that in each every situation there is a hard and fast rule. This would not be an insurmounatable problem if they at least agreed on what that rule was, but they pretty much never do. So this would just draw innocent, curious users into a cesspit in the back rooms of Wikipedia, A simple question about style could end with a giant drama fest in which multiple users are blocked, as has happened time and again in the MOS area in recent years. I'd much rather have some slight inconsistencies in our overall style than allow these obsessive types to have undue influence over actual content. Beeblebrox (talk) 16:03, 16 May 2015 (UTC)

   You seem misinformed about what actually happens when people ask style questions at WT:MoS. Please click these links (or check the archive): 1, 2, 3. Darkfrog24 (talk) 21:26, 16 May 2015 (UTC)

   Indeed. The dramafests are almost exclusively limited to axe-grinding to insert some pet new "rule" (usually from wikiprojects) or delete something someone personally doesn't like. For some reason a tiny percentage of the WP editorship refuse to absorb the obvious fact that it's essentially impossible for anyone to personally agree with every single thing in MOS, because on every style point imaginable at least one off-WP style guide offers conflicting advice from others, so we all have differing expectations. MOS is, necessarily, a compromise (i.e. something that no one is perfectly happy with every single aspect of), and we agree to abide by it here so we can actually get some consistent editing done and not drive our readers and other editors crazy over style nit-picks. The drama comes from people who can't get past their confusion of what they want/expect in their day-to-day writing vs. what WP editors are compromising on in a consensus process to get on with the content. MOS is not a style guide for the world, only for WP, and virtually every MOS flamewar comes out of failure to understand or remember this.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  14:46, 24 May 2015 (UTC)

   Clear-cut questions may be answered simply, but what happens if a questioner inadvertently asks about a topic which touches on someones pet "rule"? It'd be intimidating to new-ish users to touch off a dramafest due to an innocent question. ("WT:MoS is the place to ask style questions ... but don't mention the war.") -- 162.238.240.55 (talk)

   @162.238.240.55: Actually that happened once. While I don't approve of the belittling "pet" term, WP:LQ has both fierce supporters and fierce opponents. (It gets challenged about once a year; chains of RfCs and related discussion can last for months.) This is what happened when someone asked about it: [5] Darkfrog24 (talk) 02:31, 30 May 2015 (UTC)

4. Oppose - Absolutely not. MoS and its ridiculous intractable debates are a 6,000 watt beacon for obsessive-compulsive moths. The last thing I want to do is to give such creatures venomous fangs with a noticeboard. Carrite (talk) 16:29, 16 May 2015 (UTC)
5. Oppose While I respect and appreciate the work MOS editors do, I feel most editors just want to write and improve content. So far, I have found that general legibility requirements like grammar, spelling, sections etc. can be achieved by discussion on the talk page and people coming and copy-editing. Every time I have seen the MOS be used in a dispute, it has not gone well (generally due to lack of focus on content, wikilawyering etc.). Since the goal is to produce a useful encyclopedia, I think that if MOS issues are causing disputes, it's time to drop the MOS and focus on the content. I fear any MOS noticeboard-type entity would attract those who either see MOS as the goal of Wikipedia, or those who want to use it to wikilawyer (in short, wp:NOTHERE). Don't get me wrong, I think most MOS edits are non-controversial and beautify the encyclopedia, but those edits don't need a forum/noticeboard anyway. Happy Squirrel(Please let me know how to improve!) 17:43, 16 May 2015 (UTC)
6. Oppose all. The Help Desk is experienced in, and I believe good at, dealing with new editors who ask things like "what is the recommended way to capitalise section headers?" The MoS talk page has no experience in dealing with human beings. I never knew of its existence until today. I have just looked at it, and read a long debate on the correct shape for the apostrophe-thing in "Qur’an". While I appreciate that such discussions need to be held, and admire the scholarship of the editors who hold them, I believe that such discussions should be kept out of sight of ordinary users. Asking one's first question on Wikipedia is a stressful experience. Adding a redirect to it adds to the stress. And redirecting new users away from a place where they are likely to get a helpful answer is crazy. Maproom (talk) 07:34, 17 May 2015 (UTC)
7. Oppose all. This just does not fit into the structure and feels wrong to me per RGlouster and Beeblebrox. SpinningSpark 12:24, 17 May 2015 (UTC)
8. Oppose all per Beeblebrox and Maproom. Everything I'd like to say has already been said by them, but I'll emphasize that WT:MoS is definitely not where we should be sending new editors. APerson (talk!) 18:29, 18 May 2015 (UTC)
9. Oppose. The recent consensus was that people don't want a designated area for style questions. Anyone can ask a style question anywhere, and if they want to go to WT:MOS they're welcome to do that. Sarah (SV) ^(talk) 19:29, 20 May 2015 (UTC)

   That wasn't the consensus at all. It was that they don't want a noticeboad, because those are generally for policy matters that require enforcement (or entirely procedural things like bureaucrat and bot owner matters), not guideline matters subject to interpretation. There are exceptions like the RS noticeboard, and WP:NOTICEBOARDS lists a lot of things that aren't noticeboards.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  14:46, 24 May 2015 (UTC)

10. Oppose. As a general proposition, we should be less concerned about enforcing "rules" about the minutia of style, not more. —Steve Summit (talk) 21:16, 20 May 2015 (UTC)

    I would be fine with 1a. Adding text to the effect of "and for questions about the interpretation of the Manual of Style" to "This is the talk page for discussing improvements to the Manual of Style page." —Steve Summit (talk) 21:25, 20 May 2015 (UTC)

    Well, that doesn't sound like an "oppose" then, just a brevity suggestion for proposal point #1, and a preference against #2 and #3  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  14:46, 24 May 2015 (UTC)

    I was afraid the rewording I suggested was more significant than could be accommodated by those words "to the effect of". (Anyway you don't need VP/Pr consensus to change the intro text on a talk page.) —Steve Summit (talk) 11:32, 25 May 2015 (UTC)

11. Oppose, what is this? Didn' we just have an RfC regarding this? Why does there need to be a centralized location? Why not just place a please see link on the WikiProject's page? — Preceding unsigned comment added by RightCowLeftCoast (talk • contribs) 21:29, 22 May 2015‎ (UTC)

    This is not a game of wackamole, or kick as many balls towards the goal, and see what comes through.--RightCowLeftCoast (talk) 21:29, 22 May 2015 (UTC)

    While I'm not supporting the proposal either, I have to observe that it's standard operating procedure to modify failed proposals in ways that were suggested in the original run, and see if the alternative approach gains traction. It's actually rare for proposals of any real scope to not go through multiple iterations. The rationale for centralizing in both proposals (and the third idea, for a Help Desk page) is that centralizing discussions on the same general topic is usually helpful to editors. That's why we do it so much.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  15:37, 24 May 2015 (UTC)

12. Oppose any further move to empower or give special designation to the MoS black pit. The last thing any productive content editor (new or old) needs is to get mired in the MoS's idiotic maelstrom. Neutrality^talk 21:35, 22 May 2015 (UTC)
13. Oppose. The place for questions about style on Wikipedia is WP:HD, or the article talk pages - the place for questions about style in general is WP:RD/L. Of course, if people want to ask questions about style on WT:MOS, they can, but I don't think we should require them to use it to the exclusion of our more official support pages. Tevildo (talk) 21:36, 22 May 2015 (UTC)
14. Soft oppose I supported the proposal of a centralized style and format discussion space, but this is just not the right place for it. In effect, the MoS talk page does tend to function more or less in this fashion already, and there's no real reason to (or even a reasonable possibility of) discouraging that ad-hoc practice, but I can only imagine that to codify that role for the talk page of a major guideline would invite nothing but bedlam. I will say that some of the other oppose !votes here which allege a general level of "obsessiveness" on that talk page strike me as being predicated on excessively straw-man-like and accusative generalizations that are both needless and no way provable. In my experience, the editors active on that page generally follow a very helpful, collegial and consensus-based approach. But all of that said, I agree this move would likely only lead to increased intractability and an expansion of the weight accorded to the views of this one page in areas where there is not an established and broad community consensus. In short, I'd rather see the formal noticeboard notion refined and proposed again, hopefully not too far down the line. Snow ^{let's rap} 22:49, 22 May 2015 (UTC)
15. Oppose because the Help Desk is fine for such questions. And because WT:MoS is where the obsessives hang out. AndyTheGrump (talk) 22:56, 22 May 2015 (UTC)

    Why the mass personal attack? Are you somehow unaware that hundreds of editors post on that page every year, and people, from longest-term veterans to firstday newbies, regularly use it as the place to ask legitimate WP style questions?

16. Oppose any further codification or crystallisation of the MoS in any way, shape or form.—S Marshall T/C 23:14, 22 May 2015 (UTC)
17. Reluctant oppose because it's not helpful to fragment first line places to ask questions, or to muddy MoS talk pages with simple style queries. WP:Tea House and Help Desk should be a first port of call. I have no objection to abstruse questions being shared with WT:MoS. All the best: Rich Farmbrough, 11:50, 23 May 2015 (UTC).
    
18. Oppose all: absolutely most astonishingly oppose! I did so in the last iteration of this and I most certainly care enough to keep after this. I have read the entire conversation leading up to this latest proposal: what RGloucester wrote there is my objection: The "CREEP" objections, as I understand them, are based on the premise that such a page (or direction to this page) would be a form of overregulation, whereby editors uninvolved with an article would be directed to interfere with local page processes: except I would also include any changes to an article in addition to during its creation. No article is static here. If that is not enough, I invoke what Beeblebrox has written in the opposition here and echo that. Did I say oppose?? I most certainly did. Fylbecatulous talk 12:38, 23 May 2015 (UTC)
19. Oppose - Help Desk, AN/I and various other boards all do the job so pointless having this. –Davey2010^Talk 18:56, 23 May 2015 (UTC)
20. Oppose We don't need another place to deivert editors from editing Wikipedia. It is easy to answer MOS questions where they arise.—Finell 23:30, 23 May 2015 (UTC)
21. Oppose seems to be an attempt to sneak in a thoroughly rejected proposal without much fundamental improvement. Andrew Lenahan - Starblind 10:41, 24 May 2015 (UTC)

    Why the assumption of bad faith? A proposal to create a noticeboard (which is usually for enforcement of policy) is nothing like a proposal to accurately note the fact that WT:MOS is generally used by editors to ask WP style questions (and to use redirects to point people there).  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  14:46, 24 May 2015 (UTC)

    Noticeboards are NOT used to "enforce policy". RGloucester — ☎ 15:08, 24 May 2015 (UTC)

    Um, OK. I guess you don't read noticeboards much, since that's about 90% of what most of them do, either basic operational policy like WP:CONSENSUS, etc., at WP:ANI, or specific policies like WP:V with their own noticeboards. Yes, there are some noticeboards for some guideline matters (remember I said "usually"?), but I submit that they're odd ones out, and a poor model for how to deal with questions about guideline interpretation. Most of those are about guidelines that border on policies, like WP:RS. They're dissimilar to MOS. (There are also entirely procedural noticeboards, like the bot owners NB and the bureaucrat NB, but I think we all know I don't mean those. Nor the large number of non-noticeboards that are listed at WP:NOTICEBOARDS.) Regardless, the point obviously was that while a MOS noticeboard isn't a good approach (and you opposed that proposal yourself), it's clearly not the same proposal as this one, and an assumption of bad faith behind this different proposal on the basis that they're the same isn't appropriate. I think Starblind can respond for himself, and doesn't need you to leap in and sport-argue for him. — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  15:20, 24 May 2015 (UTC)

    I did not "oppose" that proposal. I wrote that proposal and submitted it. Your definition of noticeboards is incorrect. The convention on this matter, WP:PNB, makes it clear that what you think a noticeboard is is not what a noticeboard is. RGloucester — ☎ 15:39, 24 May 2015 (UTC)

    Sorry on the first point; I lost track of who I was responding to. I didn't offer a definition of noticeboards, anywhere. I'm pretty clearly referring to pages with "noticeboard" in their names, most of which (when not covering procedural stuff like 'crat business) are in fact used for policy enforcement matters. Maybe you're just negatively responding to the word "enforcement", but I'd defend it; I'm not sure what else to call warnings, blocks, topic bans, and other community and administrative sanction to ensure that policy violations by someone stop (or discussion in which consensus determines there's not actually a policy violation). I'm not sure how I could be any clearer about this, and I decline to re-explain it to you again. I also already referred to WP:NOTICEBOARDS a.k.a. WP:PNB, so I don't know what point you have in directing me to the very page I just pointed out lists a lot of things that are not actually noticeboards but just sort of similar. I have no further interest in this circular conversation.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  16:02, 24 May 2015 (UTC)

    @Starblind: In response to your concerns about bad faith, the conversation leading up to this proposal is linked in the proposal.[6] If you don't want to click, the jist is that I ran a breakdown of the opposition to the proposal for a style noticeboard. Because so many people said, "Let's not make one more page for style," and some said "we should have the talk pages do this," I figured there would be less opposition to simply endorsing an existing talk page. Darkfrog24 (talk) 05:33, 25 May 2015 (UTC)

22. Weak oppose, though I prefer the brevity suggestion "and for questions about the interpretation of the Manual of Style" (which was made in an "oppose" !vote that is actually only opposed to the 2nd and 3rd points). WT:MOS has already been consistently used this way for years, and there's no need to "hide" the fact that people can and will use it that way, but I've come around to agreeing that WP:Help Desk is the proper venue, because the it's more newbie-friendly. (It's actually perfectly legitimate for a discussion at WT:MOS to decide for or against the idea that the page top can inform editors that they may ask such questions there, BTW.) To address some other points:

    The objection by an MOS detractor that MOS regulars would dominate the answers is silly; it doesn't matter where people ask these questions, the editors who know MOS best will tend to be the ones who provide most of the answers and provide the most accurate ones. Obviously. If you want facts about physics you should consult physics books instead of astrology or baking books, and if you want legal advice you go to a lawyer, not a nurse.

    A large number of the oppose !votes here are incivil, assumptive of bad faith, and in some cases patent personal attacks on a mass scale. How would you like to be name-called "obsessive-compulsive" because of what pages you edit here? There no such thing as a special caste of "MOS editors". Every single person who cares to edit MOS or WT:MOS, ever, is "a MOS editor". Everyone who wants to work on List of Firefly episodes can be "a List of Firefly episodes editor". Such labeling is ridiculous, imagining a false dichotomy, a hierarchical caste system that demonstrably cannot possibly exist.

    That fallacy is, notably, closely related to the equally false conception, shredded by WP:LOCALCONSENSUS policy, that wikiprojects are sovereign little fiefdoms that get to make up their own rules about "their" articles, in defiance of site-wide guidelines and policies. It's no accident that most MOS detractors and outright deletion advocates are editors who also advance or operated under this false view of wikiprojects, trapping themselves into an "our tribe vs. your tribe" WP:WINNING stragedy that generates almost all of the strife at WT:MOS. Only an MOS detractor with a WP:BATTLEGROUND axe to grind against the guideline itself could even conceive of the un-wiki notion that wanting to help people with MOS-related questions gives a "partisan air" to WT:MOS. If I work on articles about pool players, and someone personally thinks pool players are categorically not notable, does that make me a "pool player partisan", or does the problem perhaps exist between that editor's own keyboard and chair? Or let's flip it around: If you create a template for formatting reference citations to Canadian periodicals, and I observe (in my view, entirely righteously) that it's pointless, being redundant to {{Cite journal}}, is it civil for me to call you "partisan" about your {{Cite Canadian journal}}? Clearly not.

    Next, it doesn't require some VP proposal to create a page here, BTW. If someone wants to actually run a HD page for style questions, go create one and do the work. That's how all of WP gets done.

    Finally, I agree with the earlier consensus that a MOS noticeboard is inappropriate, since MOS is not a policy matter and cannot be "enforced" (the closest thing we have is that disruptive anti-MOS editing can result in blocks at WP:ANI sometimes, but those are blocks for WP:DE, not for "disobeying" MOS).  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  14:58, 24 May 2015 (UTC)

23. Oppose. I can understand the thinking behind a single place for newcomers to ask questions about Wikipedia's house style, but the crazy den of pigs at WT:MOS is certainly not it. Someone, somewhere, should probably write an even more simplified version of the simplified MOS for new users, briefly skimming over what parts should be taken seriously and which parts are just a couple of MOS authors expressing a personal preference, but it would probably be impossible to get consensus about what it would say. – iridescent 11:50, 25 May 2015 (UTC)
24. Oppose; just talk about style on the article pages; don't send it over to that bottomless pit that is the MoS, and the people who watch the talk page. Handle it at the site of the issue, I'd support some kind of {{help me|MoS}} tag to be placed on article talks, but keep it there. Kharkiv07 (T) 12:55, 26 May 2015 (UTC)
25. Oppose, seems like a mess. Stifle (talk) 14:45, 26 May 2015 (UTC)
26. Strong oppose for all BMK (talk) 08:30, 5 June 2015 (UTC)

Discussion: WT:MoS for Q&A

Without opposing or supporting per se, right now, I will note that the previous discussion was opposed for many reasons, and the fact that it was rejected was not universally agreed upon. The devil is in the details here, and unlike what RGlouscester asserts here (and elsewhere), we cannot say "The community unilaterally rejected any and all forms of centralized style discussions". All we can say is that the community rejected one very specific proposal for one very specific way to manage style-based discussions, and because people had many different reasons for opposing that discussion, it is perfectly fine to have a new discussion about different ways to handle the problem. The community did not reject having centralized style discussions. The community rejected one proposal to do it one specific way. I think it is fine to revisit the issue from a different perspective. --Jayron32 20:18, 15 May 2015 (UTC)

I did a breakdown of the reasons that participants gave for supporting and opposing the creation of a style noticeboard here if anyone wants to look at it. Many opponents said that they didn't want to create one more page for style discussions. It's reasonable to say that at least some of these participants would support endorsing an existing page with a proven track record. Some even explicitly said that they thought a talk page system would be better than a noticeboard. Darkfrog24 (talk) 21:11, 15 May 2015 (UTC)

• Comment. If an editor has a question about style, telling him to read MOS isn't bad. If he has a question about MOS, then WT:MOS is the right place. But if he has any other question - for example about some decision not prescribed in MOS, if any are left - that's for article talk, or just try it and see what happens. Wnt (talk) 20:09, 28 May 2015 (UTC)

What usually happens is that no one who knows the answer sees the question.

The kinds of questions that we're talking about involve things like, "Does modelling have one L or two? Is this an ENGVAR issue?"[7] "So-and-so has been reverting my changes. Who's right?" "Does Wikipedia have a rule about X?" "I've been editing multiple articles about discontinued aircraft; should they be in past tense or present?"[8] "Is there one right way to start this sentence or do I have options?"[9] Not all of them pertain to a specific style page. Darkfrog24 (talk) 16:44, 29 May 2015 (UTC)

If someone has question relating to style, where should they go to ask it?

This really is the first question that needs to be answered... The answer may be that there is not one single "official" page... but if not, what are the options... it would help to know where to direct them. Blueboar (talk) 21:04, 15 May 2015 (UTC)

Article talk page. RGloucester — ☎ 21:05, 15 May 2015 (UTC)

that may work if there are a lot of style guru's who work on the article... but what about an article with few editors... it is quite possible that none of the editors working on the article (ie those watching the talk page) will know the answer to the question. So where do they go to find out the answer if asking on the talk page doesn't work? Blueboar (talk) 21:10, 15 May 2015 (UTC)

There is no need of "gurus", who do not exist. A consensus of editors on a given talk page is enough to resolve a dispute, and if a consensus does not form, the usual channels remain open, such as DRN. RGloucester — ☎ 21:21, 15 May 2015 (UTC)

Sorry, I wasn't talking about resolving disputes ... I was asking where editors go if they have a simple question about style, if they need help and advice. For example: An editor who knows he/she isn't great at punctuation - and wants to ask for help and advice... Where would that editor go to ask for help? Blueboar (talk) 02:14, 16 May 2015 (UTC)

WP:HD. --Redrose64 (talk) 05:11, 16 May 2015 (UTC)

Quite right, Mr Redrose. If someone feels a bit off with his English orthography, that has nothing to do with the MoS at all. That belongs at the existing venues for such matters. RGloucester — ☎ 13:43, 16 May 2015 (UTC)

Except the MoS is where we wrote down all the rules concerning those matters, and it's where most people already go. Darkfrog24 (talk) 21:32, 16 May 2015 (UTC)

Agreed. This situation is analogous to that which leads to a desire path; we can try to insist upon an exact methodology which we believe would be most ideal, but it won't stop a strong majority from following the approach which is most intuitive to them in the moment, unless you give them another obvious and efficient option -- good public space engineers account for this kind of factor these days and we should here as well. The MoS talk page clearly gets much more traffic in the from of style inquiries than does the help desk (which frankly is not a readily apparent option to newer editors, at least when compared to MoS, which is linked to across numerous policies and guidelines). I actually do oppose formalizing this role (as my !vote above indicated), but I do think that some form of centralized space for style and formatting issues would be ideal. Snow ^{let's rap} 03:34, 23 May 2015 (UTC)

A page that is specifically for style help but also isn't WT:MoS would make it easier to keep the "what should the MoS say" separate from "what does the MoS say," but there was concern in the talk page discussion that any such page would be construed as gaming the system considering that the noticeboard proposal failed to gain consensus. Jayron and FormerIP recommended creating a sub-page, WT:MOS/questions Darkfrog24 (talk) 06:19, 23 May 2015 (UTC)

Well I'm not talking about doing an end-run around the no consensus result of the previous proposal by essentially creating the same kind of noticeboard in a different-than-proposed space. Rather I'm suggesting the original proposal be tabled for a time and then brought back for central community discussion once the argument for it (and its proposed format and dimensions) are more significantly refined. The somewhat lopsided !votes of the previous discussion not withstanding, I think this proposal is bound to gain traction and broad approval in the community sooner or later, since the need is (to my view) certain. In the meantime, I think it would be counter-productive to the priorities and concerns espoused by most editors on both sides of the major divide (amongst those who spoke in the VPP thread) to try to establish a guideline talk page as a formal resolution/help space. Snow ^{let's rap} 07:54, 23 May 2015 (UTC)

That's interesting. What would you change about this or the previous proposal? Darkfrog24 (talk) 04:38, 24 May 2015 (UTC)

Right now, no there isn't one official page for style Q&A (though WT:MoS has done a large part of the job unofficially), but I feel there should be just one. Call it a noticeboard, call it a help desk; I don't much care so long as the Q&A that we currently do at WT:MoS and other talk pages all happens in one place and is made easier for editors to find. If we use multiple pages, then people get contradictory results. Other editors have also expressed concerns about forum shopping. Darkfrog24 (talk) 21:16, 15 May 2015 (UTC)

I agree that it does notmatter what we call this proposed forum. The problem, as I noted above, is that these self-appointed "gurus" are often extremely obsessive rule-mongers, often disagree with one another to the point where everyone else decides that they don't care anymore and they just walk away, and sometimes even resort to socking and other unacceptable behavior to get their way in whatever is their latest utterly pointless dispute. It would be a terrible idea to direct anyone to go to these people for help. So, regardless of the name of the page, we just shouldn't do this. In fact, I would support large notices at the current MOS talk pages advising users to go elsewhere with their inquiries. Beeblebrox (talk) 17:50, 16 May 2015 (UTC)

Beeblebrox, please click the links of example questions, if you think they're cherry-picked, check the WT:MoS archive. People show up, ask their question, get their answer and move on. When people say "What should the MoS say?" yes we fight about that, but when people ask "What does the MoS say?" it's pretty straightforward. Or on the flip side, can you post a link to a time when an editor asked a style question and it devolved into a fight with sock puppets (or comparable viciousness)? Darkfrog24 (talk) 21:30, 16 May 2015 (UTC)

Responding to Darkfrog24's notice at WT:HD. I have worked the Help desk with some frequency for about a year and I can't recall seeing a style question, not that I have seen everything or that my memory is perfect. I would consider that outside the scope of HD, being in the realm of editorial rather than how-to, so I would personally direct such a question elsewhere. That said, I haven't seen a clear consensus as to the scope of HD (no surprise there), or much concern about enforcing any such scope. Regardless of the question, many responders will try to answer it rather than direct the OP to a place where they might get a higher quality answer. ―Mandruss ☎ 22:00, 16 May 2015 (UTC)

User:Darkfrog24 you said "the MoS is where we wrote down all the rules concerning those matters, and it's where most people already go." That's not quite correct. The Wikipedia:Manual of Style is not a list of rules it is a Guideline. That is, a set of best practices that can, within reason, be ignored. Is Wikipedia talk:Manual of Style the page where most people go to ask? I really don't know as I rarely look at any MOS talk pages. CambridgeBayWeather, Uqaqtuq (talk), Sunasuttuq 22:15, 16 May 2015 (UTC)

Guidelines in name, rules in practice. Whether that's a good thing is a matter for another discussion, but I refer to the MoS's contents as rules quite deliberately. As to whether it's "most," I'll concede that we'd have to count them. The whole point of this proposal is the idea that lots of people with style questions give up before they ask them anywhere. But certainly a lot of users ask their style questions at WT:MoS. Darkfrog24 (talk) 22:19, 16 May 2015 (UTC)

And that's why you are getting resistance to a single style Q&A page governed by MOS experts. Too many see them as rules that must always be obeyed. As to them being "rules in practice" there are many pages that do not conform to the MOS. I've ignored the MOS when it seems like a good idea to do so and so do many others. CambridgeBayWeather, Uqaqtuq (talk), Sunasuttuq 22:28, 16 May 2015 (UTC)

Actually, many of the MoS experts disagree with me about whether they should be considered rules or not. But if you check the example questions provided (or the WT:MoS archive), you will see that the people who ask questions want to know what the MoS's rules/whatever-you-call-them are. I remember one question that was about "Someone else is doing X and I want to do Y; tell me whom the MoS supports." Most of them are more along the lines of "What's the right-or-at-least-MoS-compliant way to do Z?" This isn't about reaching out to other editors and telling them to stop doing what they're doing. The other editors are already reaching in to the MoS and asking what they should do differently. Darkfrog24 (talk) 23:59, 16 May 2015 (UTC)

I had not known about the recent RFC, and only saw the proposal above. Reading here and there I am glad (though sadly...) to see my feelings about MOS are shared by many. However, since I do want "a place" to ask questions related to 'style', I saw in comments to User:Darkfrog24's summary of objections to the RFC that WT:MOS is suggested as 1) existing, 2) likely to be seen by MOStafarians who can volunteer opinions. I may repost my question about "JaMon 1st" vs. "JaMon Ist" there. Shenme (talk) 04:53, 22 May 2015 (UTC)

This is a really good question. My own answer may seem heretical. I don't think it's any secret that the MoS exists. So if someone is writing something, and they're not sure what the "official" way to write it would be, and they somehow don't know about the MoS, or they do know about it but they're not sure how to interpret it and they can't figure out where to ask, my own preference is that they simply not worry about it, and write whatever sounds best to them, and let the style take care of itself later. —Steve Summit (talk) 01:20, 23 May 2015 (UTC)

There are two problems with that, Steve. 1: The explanation at the top of WT:MoS says that the page is for discussing changes to the MoS, not for asking questions about the MoS (easily fixed if you ask me). 2: If a Wikieditor has a question about style, that means that they think that style is important enough to spend their time on. Some of these questions are "Why did so-and-so revert me?" and "Stop caring about it" isn't a good answer to that. Darkfrog24 (talk) 02:51, 23 May 2015 (UTC)

• There should be no official "should" location. What already happens (and should remain) is that editors go somewhere they believe will be an appropriate forum and where they feel most comfortable asking for help. These are in my noticing: 1. article talk page, especially if there has been already previous friendly conversation on that TP. 2. a users talk page (sometimes found from prior discussions at article TP). 3. The Teahouse serving up warmth and tea and then advice or direction to a more appropriate forum. 4. The Help desk. 5. An Administrator's talk page if it is an open forum (and there are some, actually); proposing question to the admin and talk page stalkers to answer. 6. Village Pump. 7. Noticeboard to fight for their right to party in drama. 8. WikiProjects: some are actually quite receptive and grateful for questions about style. Fylbecatulous talk 14:09, 23 May 2015 (UTC)

And what about the ones who 9. give up because they can't find anyone to answer their question? Darkfrog24 (talk) 04:11, 24 May 2015 (UTC)

Since this is hypothetical and you have provided no specifics, I will speculate that they possibly make an incorrectly styled edit in an article. (EEK! The horrors...WIkipedia will surely slide into the abyss). Fylbecatulous talk 14:38, 24 May 2015 (UTC)

You seem to think this is about MoS regulars reaching out to impose their preferences on the article space. Remember this is about questions. This is about other editors reaching in. They don't want to write improperly styled articles. "Stop caring about that" isn't a good answer, not when a better one would be easy.

As for specifics, I did provide examples of questions that were asked and answered on WT:MoS. If you want something else specific, how about you say something a little more specific about what it is? Darkfrog24 (talk) 05:24, 25 May 2015 (UTC)

You seem to be totally discounting all eight locations for help that I listed, as though they are of no use and thusly leave a poor editor stranded all alone in the world of style (what is formal wear after dark? Help I haz to buy a tuxedo!! Do I wear white after Labour Day?). I am saying these avenues work. Here is a diff to an active discussion at the Teahouse. Nice and tame and helpful at the same time. No harm, no foul. I am going to link the current diff but might have to relink to the section after the faithful bot automatically archives it. updated after archive: this is its final resting place: [10]. Why the cats meow is this not an exchange that worked ( in your opinion)? I just want to see all the current avenues for style advice remain active. I do not wish to have every writer rerouted to what I see as an alternate bad route with negative outcomes. See, that Teahouse inquirer received virtual tea of kindness and I do not want that cut off. Thanks. Fylbecatulous talk 13:58, 25 May 2015 (UTC)

Actually, I'm not. I checked out the help desk, teahouse and other spots before I made this proposal, and if I were a new user and hit help desk, I'd think it was only for technical issues. Their archive doesn't have many style questions in it, and the answers given there aren't as clear-cut as the ones provided at WT:MoS. According to Help Desk regular Mandruss, the help desk doesn't really cover this stuff and the regulars there often don't know the answer when it does. As for the others, article talk pages don't usually have style experts on them who can answer these questions, I'm not clear why asking just any other user or just any administrator would necessarily result in accurate style advice, and there is no style noticeboard.

I'd like you to do the same. I'd like you to either click into the MoS archive or try the three links offered in the proposal and take a look at the way the MoS regulars handle questions about style, the way we have been handling them for years. I think you'll find that at least some of your concerns are unfounded. Darkfrog24 (talk) 20:37, 25 May 2015 (UTC)

See, that is it right there. We do not need a "style expert". This just reiterates that what is desired here is the setting up of a Style ARBCOM to handle issues and to nail down the "one correct way". Sorry. Fylbecatulous talk 13:09, 26 May 2015 (UTC)

I'm not sure why any of this makes think we don't need style experts. People keep asking for us to help them. That shows that there's a demand for style help. Darkfrog24 (talk) 16:42, 26 May 2015 (UTC)

Since the other discussion is closed, I'll just chime in here to say that with now 37 watchers on that page, I'd support the style noticeboard as a viable venue. Samsara 11:50, 26 May 2015 (UTC)

The biggest legit objection to the noticeboard was "we don't want to create a new page just for this." But the biggest objection to endorsing the existing page WT:MoS for help is "We don't want the same people at WT:MoS officially endorsed." Putting them on separate pages might help with that. Of course, we're still going to get at least some of the same people on the same page, but it would be a lot easier to say "Remember this is for help only; do not disgress into what the MoS should say" if they were on two separate pages. Darkfrog24 (talk) 16:42, 26 May 2015 (UTC)

Brainstorming support for users with style questions

It looks pretty clear that making the current system official isn't a popular decision, but we can see very clearly that there is a need to provide users with some way to receive answers to style questions. According to Mandruss, the Help Desk is not currently meeting this need. Let's talk ideas. The previous proposal, creating a style noticeboard, met with a split that was close to fifty-fifty. One of the objections was the idea of giving MoS regulars and other style experts too much power. How would everyone feel about creating a separate page, specifically for style questions, that did not have the weight that most of us associate with noticeboards? A separate "style Q&A page" would also make it easier to keep discussions focused on the asker's needs rather than on what the MoS should say or how it should be changed. Would any of you who object to endorsing the MoS support a proposal along these lines? Other ideas? Darkfrog24 (talk) 16:49, 29 May 2015 (UTC)

• No! How many times must people tell you the same thing? How many RfCs must be held to make it clear that the community does not want such a page? RGloucester — ☎ 14:54, 30 May 2015 (UTC)

RG, for the fifth time, revising and improving failed proposals is normal and expected on Wikipedia. Also, I'm a bit confused. You proposed that we establish a style noticeboard. Were you kidding? Darkfrog24 (talk) 17:35, 1 June 2015 (UTC)

Indeed. I second that response to RG's outburst. More practically, the obvious answer to me seem to be to let this entire VPPRO thread die, and see if there's consensus at WT:MOS to add a note to the top of the page saying it's okay to ask style questions there, pertaining to editing Wikipedia, and then just leave it alone. I really don't think we need to do anything further. If a year from now, there's still some problem, then let's revisit the issue. This entire VP thread is now just a distraction, and a temper-flare magnet.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  00:01, 2 June 2015 (UTC)

I proposed it, and the proposal FAILED. The view of the community is clear, regardless of whether I endorse that view. The method that SMcCandlish proposes is gaming the system, and nothing else. A local MoS consensus cannot override a community consensus. Absolutely disgusting comments, indeed. RGloucester — ☎ 17:22, 2 June 2015 (UTC)

Actually, the view of the community was not clear. It was a very slight majority that included people who clearly didn't understand what your proposed noticeboard would be for. When proposals fail to gain consensus, especially by narrow margins, it's okay to look at them, check out what people didn't like about them, change them, and try again. We're not violating the will of the people by asking, "Well if you don't want strawberry ice cream, how about this vanilla?" They didn't say "No ice cream!" They said "No strawberry!" Darkfrog24 (talk) 00:26, 3 June 2015 (UTC)

• Where is all this need for a style noticeboard coming from? Is there some evidence that the Help Desk is failing to adequately answer such questions? Because I'm not seeing it myself. SpinningSpark 15:10, 30 May 2015 (UTC)

Um, did you not read any of the above discussion? The need for people to know where to go to ask style questions as they pertain to WP editing has been made clear. So has the fact that Help Desk people themselves say "We don't do this".  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  00:01, 2 June 2015 (UTC)

• Give it up: Honestly, this is a losing battle in so many ways. You are perched in your Ivory Tower and I (your average editor) am out fighting in the trenches. This is the type of article I encounter every day while you are discussing your tedious 'in or out': [11] (B.V.S.Ravi). I didn't even bother to place a clean up tag; my main concern is a BLP / unsourced. I am just laughing at you now! Worrying about style on Wikipedia is like bailing out the flood with a teaspoon. Take on the Gender Gap or something. Sheesh! Fylbecatulous talk 01:26, 31 May 2015 (UTC)

Fylbecatulous, I gather that you don't think things like punctuation and sentence structure are important, but the people asking for help with those issues do. The creation of a style help system would not stop you from fixing articles in ways that interest you more. An article can be properly sourced and properly written at the same time.

To answer the only legitimate question that's been asked, @Spinningspark: the evidence of demand for style help is all the people who show up at WT:MoS asking for style help (which they are technically not supposed to do, hence action #1 on this proposal). What we can infer is that they don't think the Help Desk is the place to go. For myself, I'd say that the Help Desk isn't addressing these needs well. According to Mandruss, in the rare cases when the Help Desk gets a style question, the people there try to answer it even if they don't know the answer. According to my own experience, the Help Desk deals almost exclusively with technical issues, with the nuts and bolts of how to get Wikipedia to do something. The person who hangs out at the Help Desk to answer questions is likely to be knowledgeable about those things but only a few will also be knowledgeable about style matters and Wikipedia's rules on style matters. If I hung out at the Help Desk, I'd see twenty questions that I didn't know how to answer for every one that I did, if not more. Having one dedicated page or some equivalent solution would make it easier for the people who know how to punctuate an appositive to answer questions about punctuating appositives. Darkfrog24 (talk) 17:35, 1 June 2015 (UTC)

Fylbecatulous, that's not a sensible response. It's not very clear that you assume any good faith at all about anyone who often edits at MOS, and you make it crystal clear that you believe they do not work on writing article content, sourcing improvement, or anti-POV-pushing efforts, and are aren't otherwise doing anything important. That's pretty insulting, and easily disproven by simply looking at what else they edit. You're entitled to whatever fantasy you like, I suppose. That doesn't really have anything to do with the question, which is "Since people obviously want somewhere to ask style questions as they pertain to editing Wikipedia, where should they ask them?" The obvious answer to this question, as it would be for any similar question about where to ask how to interpret and apply any other guildeline, is "on the guideline's talk page". This whole thread is pretty moot, since no one needs VPPRO's "permission" to do that or to tell people they're allowed to do that. So, can we please now zip it and get back to editing, without any further finger-pointing and invective?  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  00:01, 2 June 2015 (UTC)

I have striken my last comment. I agree it is over the top and entirely unnecessary to have continued on in the manner I did. I have to sleep at night as do you all, so I apologise for raising the blood pressures of the editors at MoS. I also agree that you are dedicated to your tasks. Fylbecatulous talk 02:29, 2 June 2015 (UTC)

Date and time in contribution lists

When viewing a contribution page of an editor with many edits per day, after selecting year and month, it is not uncommon to skip several pages of 50 edits each, before arriving at the desired edit. Therefore I suggest there be added boxes for selecting Day, Hour and Minute on user contribution pages and page history pages. I know that it is possible by editing the URL, but I still feel this suggestion will make things better. Iceblock (talk) 16:41, 14 May 2015 (UTC)

• Support Useful feature, no downside except the time necessary to code it. --Jayron32 01:50, 18 May 2015 (UTC)
• Support adding a 'Day' field, no question. (I can't tell you how many times I've wished for that!) I dunno about 'Hour' or 'Minute' fields (especially 'Minute') – I suspect that might make the proposal more complex for implementing than we'd want... --IJBall (talk) 01:17, 19 May 2015 (UTC)
• Comment: While I have no specific support or opposition to this, I'm pretty sure that any consensus gained on this will be a WONTFIX in Phab on the grounds that the interface is too cluttered. I'm not saying just give up on this proposal, but that's what I expect if we ask for it to be implemented that way. If there is consensus for this (or even if there isn't but there are enough people that want it), it could probably be implemented as a userscript (if it doesn't already exist, which I think it does which is why I'm posting this comment in the first place). — {{U|Technical 13}} (e • t • c) 02:06, 23 May 2015 (UTC)
  • Concur: The date and time is coded in the url so a gadget should be easy for a gadget writer. All the best: Rich Farmbrough, 11:54, 23 May 2015 (UTC).
    
• User:Jayron32, User:IJBall, User:Technical 13, User:Rich Farmbrough: If just a 'From day (and earlier)' field be added, outside a userscript, will this make the interface too cluttered? Iceblock (talk) 21:36, 23 May 2015 (UTC)
  • Well I would like it - I'm used to typing the date and time into the url, and it is very error prone. If you want to make a request at Phabricator, go ahead! All the best: Rich Farmbrough, 22:22, 23 May 2015 (UTC).
    
• Support, down to the hour at least. I'm not sure we need it to be minute-specific.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  08:23, 25 May 2015 (UTC)
• Maybe thisis just me, but I'm having trouble imagining a scenario where I know down to the hour and minute when someone made an edit, but still somehow can't find it. Beeblebrox (talk) 20:48, 27 May 2015 (UTC)
• This is not about being able or unable to find an edit. It's about making it a lot easier. Iceblock (talk) 20:00, 29 May 2015 (UTC)

RfC: Proposal to add optional multi-factor authentication to the English Wikipedia

Should optional multi-factor authentication be enabled on the English Wikipedia? PHANTOMTECH (talk) 23:30, 21 May 2015 (UTC)

Details

Multi-factor authentication allows users to require that, in order to sign in to their account, they provide a code generated by another device (their phone) in addition to their password. The extensions mw:Extension:TwoFactorAuthentication and mw:Extension:OATHAuth allow for multifactor authentication on sites that use MediaWiki, note that only one is required, there are just two that I'm aware of. This proposal will take up to 2 phases:

• Phase 1: Determine if there is consensus to implement optional multi-factor authentication. If there is not, this will be the only phase.
• Phase 2: Determine recovery options, what someone who decided to turn on multi-factor authentication would have to do to have multi-factor authentication on their account disabled without logging in, in case they lose their phone or something. Each possible option here will have its own subsection, any possible options that have consensus will become recovery options.

Phase 1

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

---

Should optional multi-factor authentication be enabled on the English Wikipedia?

Support (optional multi-factor authentication)

1. Support As proposer. Not aware of any reason to not allow optional multi-factor authentication. PHANTOMTECH (talk) 23:30, 21 May 2015 (UTC)
2. Support. I use 2FA for almost all my services (email, Dropbox, finance, heck even Wikimedia Labs) myself, so I personally support this and would use it fully, but I would also ask those who don't to still support, as there will be no disruption or difference to those who do not use MFA/2FA. --L235 (t / c / ping in reply) 02:14, 22 May 2015 (UTC)
3. Support. Absolutely. -- King of ♥ ♦ ♣ ♠ 04:36, 22 May 2015 (UTC)
4. Support. Multi-factor authentication would be a very good idea. I have seen evidence of someone trying to break into my admin account before, when I received notification emails from external sites after someone had used the "reset your password" feature with my Wikimedia email address. And a lot of damage can be done with a compromised admin account before it is locked, some of which is not easily recoverable. Multi-factor would make it much harder for password-snooping attacks etc. to be effective, and I can't see any downsides, especially if it would be optional. — Mr. Stradivarius ^{♪ talk ♪} 06:26, 22 May 2015 (UTC)
5. Support - Sounds like a very good idea to me, it should be strongly recommended for admins. I would be interested to hear from the developers of tools such as AWB and PyWikiBot as it seems to me that Bots are another type of account that would benefit from extra protection, however the tools would have to be updated to work with whatever multi-factor might be used. Jamesmcmahon0 (talk) 10:28, 22 May 2015 (UTC)
6. Support Seems completely sensible as an option. Sam Walton (talk) 11:10, 22 May 2015 (UTC)
7. Support. Most other websites I use allow this, so why not Wikipedia? APerson (talk!) 18:31, 22 May 2015 (UTC)
8. Support as optional. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:10, 22 May 2015 (UTC)
9. Support as optional. --Wolbo (talk) 23:18, 22 May 2015 (UTC)
10. Support as an option. If people wnat to use it great, if not then they dont (still fine.. Amortias (T)(C) 10:07, 23 May 2015 (UTC)
11. Long overdue. Essential for editors with advanced permissions (that includes myself). - Mailer Diablo 05:25, 24 May 2015 (UTC)
12. Support - The additional security would be a welcome addition. I dont see any downside, per PhantomTech's arguments refuting privacy concerns, below.- MrX 15:28, 24 May 2015 (UTC)
13. Support, as long as it doesn't require personally identifiable information, per PhantomTech's explanation below.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  08:25, 25 May 2015 (UTC)
14. Support: unauthorized access to an autoconfirmed, admin, bureaucrat, steward, or (worst case nightmare) Jimbo Wales' account can be catastrophic. Multi-factor authentication significantly enhances security: a MITM attack or a careful examination of the 2FA system would have to be done, which automatically puts account cracking out of reach of 99% of amateur hackers, and increases the workload for the remaining 1%. Inconvenience issues can be resolved by having an alternate account for public computers. Esquivalience ^t 02:45, 26 May 2015 (UTC)
15. Conditional support: While I like the idea of additional authentication—particularly for privileged accounts—I can't support a system that would require I provide highly-identifiable personal information (like a phone number), especially when the system would require that the information be stored retrievably (compare phone numbers, which must be retrievable to be used, with passwords, which are salted). {{Nihiltres|talk|edits}} 07:24, 26 May 2015 (UTC)
16. Support but strictly optional only. Stifle (talk) 14:44, 26 May 2015 (UTC)
17. Support This would be a very good thing to have, especially for users with additional rights. Mike V • Talk 22:27, 26 May 2015 (UTC)
18. Support as an optional feature. This seems like a no-brainer. --Ahecht (TALK
    PAGE) 14:13, 27 May 2015 (UTC)
19. Conditional support I think Phase II is the tricky part. It needs to be carefully thought out, not simply opened up for votes.--agr (talk) 00:25, 28 May 2015 (UTC)

    I agree, decisions made in Phase 2 can turn a security feature into nothing more than a nuisance. PHANTOMTECH (talk) 01:20, 28 May 2015 (UTC)

20. Support Absolutely no reason to not add this as an opt-in feature. Jackmcbarn (talk) 01:32, 28 May 2015 (UTC)
21. Support this could be a very good layer of securuty. As some editors have explained above, compromised accounts can have a catastrophic effect on the operations of the site. 2600:1003:B12D:D329:9442:C04B:E459:ED40 (talk) 04:09, 29 May 2015 (UTC)
22. Some of us have access to things better left private --Guerillero | Parlez Moi 05:26, 29 May 2015 (UTC)
23. And this should be implemented at once by every functionary/arbitrator, (as should their email accounts). Courcelles (talk) 05:38, 29 May 2015 (UTC)
24. NativeForeigner ^Talk 06:12, 29 May 2015 (UTC)
25. Long overdue. T. Canens (talk) 07:00, 29 May 2015 (UTC)
26. Support as vital for functionaries and arbitrators. Doug Weller (talk) 09:45, 29 May 2015 (UTC)
27. Lankiveil ^{(speak to me)} 09:47, 29 May 2015 (UTC).
28. Support As optional and highly recommended Lor^Talk 10:00, 29 May 2015 (UTC)
29. Support as optional. Notwithstanding that I have no idea about the cost/implementation of this, I have used this sort of thing for logging into accounts in the past (although with a dongle, rather than a smartphone app). I see no issue with this sort of thing when I log in, and would welcome the additional layer of security. --kelapstick^(bainuu) 11:00, 29 May 2015 (UTC)
30. Support - I use 2FA for several services, and feel that Wikipedia is way behind on this. Particularly for those of us with advanced permissions, this is a very important extra layer of security. ​—DoRD (talk)​ 11:53, 29 May 2015 (UTC)
31. Support - there is literally no reason to oppose this proposal. — foxj 13:07, 29 May 2015 (UTC)
32. Support as optional.   ~ Tom.Reding (talk ⋅contribs ⋅dgaf)  13:12, 29 May 2015 (UTC)
33. Support per RGloucester. Ironholds (talk) 15:40, 29 May 2015 (UTC)
34. Support, would be very useful as an option for rights holders. Nakon 15:48, 29 May 2015 (UTC)
35. Support the principle, but... I think optional two-factor authentication should be enabled for login to Wikimedia CentralAuth. As I've outlined below, I don't think there's any way it could be implemented solely on one local project (like en.wp). I support the principle that we should have optional two-factor authentication, but I don't think that it can be implemented at the per-project level. The best course of action is probably a discussion on Meta-Wiki and/or mediawiki.org. If we can show the Foundation that numerous projects would be keen on having 2FA at the CentralAuth global login level, then that might give them the incentive to do the work to enable it. There are some issues with doing it (like, making sure that there are good, secure FLOSS TOTP implementations that support internationalisation (people should be able to two-factor in their own languages). —Tom Morris (talk) 16:05, 29 May 2015 (UTC)
36. Suppport. I think the main opposition arguments (unnecessary collection of personal information, and unnecessary complication for non-technologically inclined editors) are mostly negated by the 2FA being optional. I see no problems with this, if it's kept as an option (and Wikipedia doesn't go the Google route of bugging you mercilessly until you enable it). The extra layer of security would also be welcome, I think, for users with elevated permissions. –GlottalFricative (talk) 20:09, 29 May 2015 (UTC)
37. Support - all the privacy concerns are mitigated by the fact that this is optional (and I assume, opt-in). I'd imagine if this was implemented there'd be some spiel on the information you provide WMF/servers/etc when you enable the feature. Steven Zhang ^{Help resolve disputes!} 07:38, 30 May 2015 (UTC)
38. Support optional implementation, but also making usage mandatory for individuals with access to non-public data. At any tech company or finance firm, lack of strong multifactor authentication for employees with access to sensitive information would be borderline negligence. While we're volunteers here, the data protected is in many cases equally sensitive. LFaraone 06:11, 31 May 2015 (UTC)

Oppose (optional multi-factor authentication)

1. Oppose: This seems to require the collection and retention of potentially large amounts of personal information such as email addresses, phone numbers etc. This would pose severe privacy problems if the was hacked into or misused. While I'm sure that people will endeavor to keep this information secure, the best way to avoid the risk of it being divulged is to not have it in the first place.Nigel Ish (talk) 16:08, 22 May 2015 (UTC)

   While some types of multi-factor authentication require personal information, by using a Time-based One-time Password Algorithm, no personal information has to be stored or shared. The server (Wikipedia) provides the client with the information it needs to generate codes, ideally that information is shared only once and is shared securely. From that point, both the client and server keep the information and use it, combined with the current time, to check what the current code should be. So to summarize, the only information shared is from Wikipedia to the client and is not personal, after that the client requires nothing but the current time to generate a code, which is checked by the server using the information it sent and the current time. PHANTOMTECH (talk) 18:55, 22 May 2015 (UTC)

   It looks like that editors would have to either have their phone with them and charged every time they log on or have to have specific software (i.e. browser extensions) installed on the computer they use to edit Wikipedia. This would limit the ability of many people to log on - i.e. no edits from computers where the user isn't allowed to install software (such as work, libraries, schools etc.). Going through this sort of routine every day seems extreme, and OTT compared to other uses of multi factor authentication that I have seen (generally for setting accounts up, or changing passwords). Also, I do have a concern about Slippery Slope issues - while what is being suggested here is an optional proposal, there is a danger, that like use of HTTPS, it will be expanded and made mandatory.Nigel Ish (talk) 12:15, 25 May 2015 (UTC)

   It is true that editors who chose to enable the feature would be required to have their phone or computer with the software installed with them whenever they logged in to Wikipedia. This may limit some people from editing, if they enable it, specifically those who can't access a device while logging in and that is something editors would have to consider when deciding to enable it. This type of mutli-factor authentication is the standard type offered by many sites including Facebook and Google and it's one of the few with a genuine security benefit so I wouldn't consider it extreme. I don't think there's any chance of this becoming mandatory any time soon. I'm not aware of a single site, including financial sites, that requires multifactor authentication, it wouldn't make sense to require it on Wikipedia and I don't think the WMF would be willing to make it a requirement. PHANTOMTECH (talk) 15:41, 25 May 2015 (UTC)

2. Oppose – I don't know what this is, but I imagine it is just some kind of "techie" rubbish. Any complications added on top of the existing system are unacceptable. We needn't bow to those with minds rooted in the technological. The most basic and simple programme should be used to run Wikipedia. RGloucester — ☎ 11:48, 24 May 2015 (UTC)

   RGloucester, This proposes that we implement an optional feature. Those that opt in would need to send or receive a message (probably a text message) via their phones (or other device) to log in to Wikipedia. As the proposal is for this to be optional, not required, it would have no effect on any user who does not opt in, as I understand it. DES ^(talk) 16:21, 24 May 2015 (UTC)

   DES is right that users who do not opt in would be unaffected, other than seeing a setting in their preferences allowing them to opt in. The extensions I'm aware of don't use text messages, they use a secret key that is shared between the server and user during setup, the user's device then uses that key and the current time to generate a code that is valid for at least 30 seconds by default which has to be entered while logging in, along with the normal password. PHANTOMTECH (talk) 19:19, 24 May 2015 (UTC)

   Ah my error. I have worked with a non-wiki two-factor authentication protocol that did use text messages. I also worked (several years ago) with a physical key system, where the key device displayed a code that changed I think once a minute, or maybe it was 30 seconds. This sounds similar but using a smartphone or other device instead of a dedicated piece of hardware. DES ^(talk) 20:01, 24 May 2015 (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.

Discussion (optional multi-factor authentication)

This RfC provides very little context. What is the reason for requesting it i.e. what issue does it address? What are the consequences, advantages, disadvantages, if any? --Wolbo (talk) 23:55, 21 May 2015 (UTC)

@Wolbo: The reason for the request and advantage of having it is that multi-factor authentication increases security for users who use it because in addition to needing the user's password an attacker needs access to the device the target uses for authentication, their phone. I'm not aware of any disadvantages of having it as an option, though the "risk" of enabling it is that if you lose your device and don't have any backup codes, it's like losing your password except you have no chance of remembering it since it changes about every 30 seconds, the second phase of the RfC would be to create ways for users in that situation to regain access to their account without completely removing the security benefits of multi-factor authentication. If implemented properly, users who decide not to opt-in to multi-factor authentication would notice no difference, the only way they would be affected is that the possibility of multifactor authentication being enabled on their account may discourage some attackers from trying to access their account. PHANTOMTECH (talk) 00:11, 22 May 2015 (UTC)

I would add that possible disadvantages are; multifactor may not work initially with 3rd party tools such as AWB, Huggle, PyWikiBot, WP Cleaner etc. Though I expect that would be resolved reasonably quickly. Another downside would be additional coding and server processing etc. I have no idea what scale this would be on though I would guess fairly minimal as there are a number of standardized options for multi-factor already in widespread use. Jamesmcmahon0 (talk) 10:34, 22 May 2015 (UTC)

Phone? I'm in China, so that might not work. The article on the subject says other thing could be used, like a question about a favourite pet or something. Anna Frodesiak (talk) 23:59, 23 May 2015 (UTC)

Multi-factor authentication is the broad term for what the extensions allow for, questions about something like your favorite pet would not be a significant improvement when combined with a password. Specifically, the extensions I'm aware of use a Time-based One-time Password Algorithm which is supported by apps on the popular smartphone OSs, a Google Chrome extension and popular computer OSs. I've never used it besides on mobile devices since the "further" the code generation is from where the site password is being entered the better but a program on your computer should still provide a significant security benefit in most situations, specifically situations where your computer hasn't be compromised by a virus or something. There is also a web application but, though it does seem to use local storage, at that point you've lost most of the security benefits, if you do use the web app I'd recommend keeping a backup of all the keys on your hard drive just in case. Hopefully you can find a way to make use of it, if not you shouldn't be any worse off since it's optional. PHANTOMTECH (talk) 01:59, 24 May 2015 (UTC)

• As always, I note that I know next to nothing about the technical aspects of such things so maybe this is totally wrong, but this sounds like it will cost money to implement. While I can see the utility of such systems I have to wonder if the WMF is even remotely willing to pay for it. Until we have some idea of that I'm not sure there's a point to discussing this. I also think that actual incidents of admin accounts being hacked are basically an urban legend, in eight years of contributing here I cannot recall a single instance in which an admin account was actually hacked and used by an unauthorized person. Beeblebrox (talk) 14:23, 24 May 2015 (UTC)

Multi-factor authentication that relies on text messaging would likely have a cost associated with its implementation, however, this type of multi-factor authentication uses a secret key held by both the server and the user's device. Both the server and the user's device use the code and the current time to generate a code, the user gives the code while logging in and the server checks to see if the code it generated matches the given code, allowing for at least 30 seconds of error on the user's clock by default. Since information is only sent once, to share the secret key, and the information is sent through the browser, (it gives you the key in your preferences or something while you're setting it up) no money has to be spend on sending the keys. The only potential cost would be to handle the additional load of computing codes from keys whenever a user logged in and that would likely be insignificant. PHANTOMTECH (talk) 19:10, 24 May 2015 (UTC)

Forgot to address what you said about admin accounts being hacked. It might be true that no one will ever have any interest in hacking an account on Wikipedia, (what would you get for all that work? a bit of time to play around with the tools before being blocked?) and so it wouldn't make too much sense to implement a costly solution to prevent hacks, but this isn't a costly solution. If Wikipedia accounts are never targeted by hackers, this is like someone coming up to you at your house on a mountain in the desert asking if you want free flood insurance, do you need it? No, probably not. Will you take it? No, you'll assume it's a scam because who goes around offering free insurance for anything? But if you knew it weren't a scam you'd probably take it. PHANTOMTECH (talk) 19:32, 24 May 2015 (UTC)

Accounts have been hacked in the past, quite a few times. Some are by people just getting their kicks out of vandalizing, and an admin account in the hands of a malicious person, esp if that person is using scripts for automated editing, can do a LOT of damage that is not easy to repair in a short time. I'm not going to suggest specific things such a person could do, per WP:BEANS, but think about the possibilities. In any case trust me, some quite nasty things have been done in the past. i remember when a change was made requiring all admins to have strong passwords (for some definition of "strong"). The other major reason for hacking is to use a hacked account to spam. Wikipedia is very widely read, and a spammer with a valid account, particularly an admin account, can make spam links very visible in a lot of places. This can be worth money to the spammer. And ther is also the posibility of more subtle vandalism, either for fun or profit. DES ^(talk) 20:11, 24 May 2015 (UTC)

It's also worth remembering admins are only one level of permissions. AFAIK, all that can be said about admins can be said about higher level privileges like checkuser or access to supression (oversight). The WMF does have clear expectations about account security for such high level privileges and perhaps they have some additional security that isn't discussed much (like checking for logins from odd locations) but I think there are more than admin tools that some people would like to get access to, that 2FA would hopefully make more difficult. Nil Einne (talk) 23:03, 24 May 2015 (UTC)

Mind you, I should clarify I'm not saying high level privileged accounts are the main reason. Ultimately it doesn't matter whether the account doesn't even have rollback or reviewer. People may not want their account to be compromised for various reasons. Now the people most likely to have their account compromised aren't likely to use 2FA probably because they don't care, but there is going to be a subset of people who do care and who would feel more comfortable with the benefit of 2FA. I presume the OP of the thread Wikipedia:Village pump (proposals)#Additional Security for Wikipedia Editors and authors which I think is the catalyst for this is one of them. Nil Einne (talk) 23:23, 24 May 2015 (UTC)

Some examples of compromised or believed to be compromised admin accounts include Wikipedia:Administrators' noticeboard/IncidentArchive239#Another hacked admin account and site-wide vandalism and Wikipedia:Wikipedia Signpost/2007-06-18/Account compromised. These examples came from before the sysops begun to try and bruteforce priviliged accounts and appeared to involve weak passwords (not sure about VCG), and in fact it sounds like we possibly didn't even have any sort of Captcha or other limits to prevent attempts to brute force an account, however I think there were at least some after the WMF got more serious. Nil Einne (talk) 23:33, 24 May 2015 (UTC)

• Any opinion on making it mandatory for certain user groups (ie. Stewards)? EoRdE6^{(Come Talk to Me!)} 13:27, 27 May 2015 (UTC)

Stewards are not bound by any local policies here, so you would need to take that to Meta and/or the WMF itself. Good luck with that.

As for other, local groups with advanced permissions, is there really a problem that needs solving here? I've been an admin for six years, a functionary for five years, and did a year as an arb, and somehow managed not to need this. I don't object to it being opt-in for those that desire it, but I don't think it needs to be mandatory for anyone. Beeblebrox (talk) 20:52, 27 May 2015 (UTC)

Lack of problems in the past is no guarantee. Things on the computer security front are getting worse, perhaps at an accelerated pace. Putting additional security in place proactively makes sense. I wouldn't object to being required to pass an additional layer of security before using admin tools.--agr (talk) 00:39, 28 May 2015 (UTC)

• Comment. This idea needs a detailed proposal and a thorough review before anything is done with it. We must verify:

• A free-licensed hash-based message authentication code generation mechanism must be actually available for users and known to work on Wikipedia (not just hypothetically or with customization by experienced users). In other words, we do not recommend or promote Google Authenticator.
  • I don't see what's so wrong with supporting RFC 6238, for which there are many compatible freely-licensed apps including, but not just limited to, Google Authenticator. I also don't see what's wrong with including GA as an option among other RFC 6238 implementations. After all, we fully support users editing Wikipedia using closed-source browsers and operating systems, but we make sure that a freely-licensed option is available. --Ahecht (TALK
    PAGE) 20:19, 29 May 2015 (UTC)
• Any possible risks of app revocation must be avoided. We cannot wake up one morning and 10,000 users are begging for someone to wave the magic wand because Google just settled a patent dispute by somehow disabling its app. (I don't know if they can do that but I would want to)

• Any possible privacy risks involved with the generation and transmission of tokens must be evaluated. Wikipedia has made great strides in going to https to defy surveillance; there must be no backsliding.

Wnt (talk) 20:24, 28 May 2015 (UTC)

@Wnt: Here is an open source app for Android and iOS. Here is an open source one for desktop OSs, though it's more on the "experienced users" end of things. Don't think this one is open source but it is another alternative to Google Authenticator. Keys are stored on the device and apps don't need (and shouldn't use) an internet connection to generate codes, so unless an app is uninstalled by force users should still be able to use it to generate codes, even if it is discontinued. I've talked about what information is shared before, but to expand on that, here is how an ideal (and typical) implementation works:

1. User decides to enable multi-factor authentication
2. Server (Wikipedia) generates a key and gives it to the user
3. User gives the key to their multi-factor authentication application, which stores it on the device it is installed on
4. The user's application generates a code based on the key and current time, this code is independent of any information other than the key and current time
5. The user gives the server (Wikipedia) they generated code to confirm the user is able to generate valid codes
6. The server (Wikipedia) generates multiple codes, (by default) one based on the current time, one 30 seconds earlier and one 30 seconds later (in case the time on the user's device is off a bit)
7. If the code the user gave matches one of the 3, multi-factor authentication is enabled on the account
8. In future logins, the user's application uses the stored key and current time to generate codes, the server (Wikipedia) does the same thing it did to verify the first code

PHANTOMTECH (talk) 21:21, 28 May 2015 (UTC)

• Agreeable provided that the second factor is in no way dependent on hardware. Messages to mobile phones are (1) expensive and (2) unreliably available. (I wound up disabling a two-factor authentication system because it was phone-based and resulted in a $40 additional bill in just one month of generation. Remember that we have a huge number of participants for whom cost would be a genuinely limiting factor.) Physical tokens (e.g., USB-based tokens) are limited to being usable only on equipment that is compatible, which is increasingly problematic as more and more people use platforms other than traditional desktop/laptop computers; the technology also is probably illegal to provide to people in certain countries. So...the objective is to identify a cost-free process that is not dependent on any form of technology and is available around the clock and around the world without costing the users. Keep in mind that high cost or difficult access is more likely to result in users keeping themselves logged-in pretty much constantly and continuously, which is a far, far greater security risk than what is being discussed here. The topic of two-factor authentication has been batted around within the WMF security and developer group for several years now, and it strikes me that any proposal that commits the WMF to doing anything needs to get buy-in from that group even before dreaming up ways of implementing it. Risker (talk) 13:00, 29 May 2015 (UTC)

I brought up the fact that this sounds like it would cost the foundation money up and we should find out if they are even willing to do this above, five days ago, and the answer I got was basically "probably, but we should do this".. Apparently we're going to decide we are doing this, and then afterword try to figure out if we actually can. Seems a bit backwards to me, but so does a lot of stuff that goes on around here. Beeblebrox (talk) 15:46, 29 May 2015 (UTC)

Eh, it's all up to the developers anyway. When we have an RfC that requires technical intervention, we're not really deciding anything, we're having a community discussion where the end result is "hey, nice people at WMF, can you do this please? Pretty please?" It's worth doing in as much as it gives our collective consent to the Foundation implementing it if and when they decide to do so. But there's no real way to make them do it if they don't want to. —Tom Morris (talk) 16:08, 29 May 2015 (UTC)

Tom Morris, I think you'll find that it's a bit more complicated than that, but anyone who wants to become one of the volunteer devs (which outnumber the WMF's staff devs by a significant margin) should see mw:How to become a MediaWiki hacker. WhatamIdoing (talk) 03:10, 30 May 2015 (UTC)

@Beeblebrox: Sorry if my reply to your earlier message wasn't clear, certain types of multi-factor authentication would come with a (probably significant) cost but the extensions I've linked use a type that does not require anything like text messages and so would not cost WMF money to implement. PHANTOMTECH (talk) 16:42, 29 May 2015 (UTC)

Technical issue: how would this work with CentralAuth?

CentralAuth exists, and global accounts have now been set up and normalised. When you login to Wikipedia, you login to the CentralAuth server and thus can visit any other Wikimedia site (the sister projects like Commons and Wikinews and Wiktionary etc., Meta-Wiki, MediaWiki.org and a bunch of others) and be logged in.

This proposal seems to be about consenting for it to be enabled on English Wikipedia. I broadly support the idea but how would this fit with CentralAuth? This is really a question that needs developers familiar with CentralAuth to answer.

When you type your username and password into Wikipedia, you aren't logging into English Wikipedia anymore, you are logging into Wikimedia's CentralAuth (login.wikimedia.org), which then logs you into a global account across the various different wikis. When you visit a new wiki for the first time, a local account is set up to match your global account username.

It seems likely to me that if the Foundation were to implement 2FA, it'd be on a global scale rather than on a per-wiki basis. Why? Because...

1. User visits en.wikipedia.org and types in their username and password. They are then asked to type in their two-factor authentication token. They don't have their 2FA device on them so decline. As Wikimedia Commons does not have 2FA turned on, the user goes to Wikimedia Commons and can start editing but they can't edit on English Wikipedia.
2. On Wikimedia Commons, the user (who is an admin or file renamer locally on Commons) renames a file. When you do this, the edits propagate back to English Wikipedia... except they don't, because they are logged into Commons but not English Wikipedia.
3. The user then visits Wikidata. For the sake of argument, Wikidata has not enabled 2FA. As with Commons, the user is allowed to edit. The user makes some edits on Wikidata which then propagate out to other Wikimedia sites, except they aren't because some of those require 2FA.

I just don't see any way that 2FA could sensibly be implemented on a per-project basis. It's all or nothing: optional two factor authentication for CentralAuth or not. It seems like deciding on local consensus on what is highly likely to be a global change is a bit of a waste of breath... —Tom Morris (talk) 15:57, 29 May 2015 (UTC)

CentralAuth is certainly a problem, and one I didn't think of when creating the original proposal. The only way to implement per-project 2FA would be to split authentication, which would be a bit odd. English Wikipedia consensus can't affect all Wikimedia wikis but if consensus here is any indication of what it would be across the other project, I don't think there would be much opposition to project-wide 2FA. Based on this issue, and some other people having concerns about the willingness of WMF to implement 2FA, I think I'd be a good idea to get a dev to comment. (Though I'm not sure how to go about that) PHANTOMTECH (talk) 16:42, 29 May 2015 (UTC)

So this discussion was mentioned on IRC, and as the main person working on this on the developer-side, I figured I'd give some background on what I'm doing. Right now there are two extensions, mw:Extension:OATHAuth and mw:Extension:TwoFactorAuthentication. The reason two exist is an accident on my part, and right now I am in the process of merging the two extensions together. Once it is done, there will just be one extension. The technical problems that need to be fixed are:

• Allowing for storing credentials in a central database, so it works with CentralAuth. As said already, it is basically impossible to do this on a per-project basis, so it would be all or nothing. However, as a means of a test run, we were thinking of only allowing certain user groups to use it, just as a test trial, before opening it to everybody.
• The extension in its current form adds a "Token" checkbox below the login form, which is terrible because it confuses anybody who doesn't know what 2FA is and doesn't use it. I have a series of patches in mw:Gerrit right now that are fixing that. It'll be a little while before they are merged, but once they are this should be fixed.
• We are also worried about recovery. If somebody loses their two-factor device (which is usually their phone, but can be something else), then they are basically locked out of their account. We can't allow email recovery, because then it defeats the point, so MetaWiki would have to have some sort of steward-based process. Hence why we want to have a test trial.

That's about it. Once my series of patches for the extension are merged, this can maybe start moving forward on testwiki or some other private wikis that are not in CentralAuth. — Parent5446 ☯ ^{(msg email)} 17:31, 29 May 2015 (UTC)

Parent5446: the second point you bring up - adding a 'token' checkbox - is definitely a poor UX. Sites I've used that have 2FA tend to do it after you've submitted your username and password. I think if there eventually becomes (global!) consensus to enable this on Wikimedia sites, that would have to be the UX that would work. Affecting the login UI for non-opt-in users are not acceptable. —Tom Morris (talk) 21:37, 29 May 2015 (UTC)

Continuation of RfC

As has been brought up, CentralAuth prevents any per-wiki implementation of multi-factor authentication. This makes the second phase of this RfC useless as a proposal but potentially beneficial for generating ideas. Since 2FA doesn't seem to be coming too soon, I don't think there is much need to discuss recovery options at this time so I don't think I'll be starting phase 2. If someone else feels there is a need for recovery options to be discussed right now, feel free to start it, but keep in mind that since this is a WMF wide change the discussion would just be for generating ideas. PHANTOMTECH (talk) 17:54, 29 May 2015 (UTC)

As I said above, it might be an idea to set up an RfC on Meta. And by an RfC, I don't just mean a "should we do this?" but one where all the various technical and policy issues are presented and hashed out (global vs. local logins, recovery options, SMS fallback, the availability of TOTP clients for different platforms and their support for Wikimedia's many different language communities, whether the Wikipedia mobile apps should contain TOTP functionality) rather than a simple up/down vote. Once we've got a handle on the issues, then it makes sense to then have a global vote. —Tom Morris (talk) 07:29, 30 May 2015 (UTC)

@Tom Morris: I've never started or participated in a discussion on meta so I'm probably not the best person to start it. If you or anyone else would like to, please post a link here and I'll join in. PHANTOMTECH (talk) 18:09, 30 May 2015 (UTC)

Linking to disambiguation pages

There should be a tool that automatically replaces Foo with Foo. GeoffreyT2000 (talk) 01:25, 22 May 2015 (UTC)

Moved from Wikipedia talk:Village pump § Linking to disambiguation pages.

 – Redrose64 (talk) 06:57, 22 May 2015 (UTC)

Links to disambiguation pages without " (disambiguation)" should be automatically fixed by a bot to link to the redirect with " (disambiguation)". 2602:306:B8E0:82C0:5151:4DE4:D781:AD4C (talk) 22:32, 21 May 2015 (UTC)

Why? PrimeHunter (talk) 02:02, 22 May 2015 (UTC)

AWB could do this, but we still want a human to check it is doing sensible things. Graeme Bartlett (talk) 05:46, 23 May 2015 (UTC)

No there shouldn't. If it was desirable (in that instance) then Foo should be a redirect to Foo (disambiguation). If anything (and there would be much weeping and wailing and gnashing of teeth, for good reasons as well as bad ones, should anyone try it) Foo should be replaced with [[Foobar|Foo]]. All the best: Rich Farmbrough, 11:59, 23 May 2015 (UTC).

No; let's say that somebody links to North Eastern Railway, which is a dab page. How is a bot to know that the dab page was linked on purpose? The user may have meant to link to the page about the railway in the United Kingdom, and hadn't realised that others exist. The link should indeed be fixed, but it needs to be examined by a human because a bot cannot tell whether a link to a dab page is accidental or intentional. Only the intentional ones (see WP:INTDAB) should be altered to e.g. North Eastern Railway (disambiguation), the accidental ones should be fixed to an appropriate link such as North Eastern Railway. --Redrose64 (talk) 06:57, 22 May 2015 (UTC)

There is (already) a bot which corrects the intentional ones (as in uses of {{for}} for example). --Izno (talk) 14:11, 22 May 2015 (UTC)

The bot can correct the intentional links in a small set of circumstances. There are many more where human correction is needed, but no one has gotten around to checking the link yet. bd2412 T 20:57, 23 May 2015 (UTC)

How many? (I tried attacking this problem manually some years ago, and some of them are very hard and need research. Not "London, England" vs "London, Ontario" at all...) All the best: Rich Farmbrough, 22:27, 23 May 2015 (UTC).

No we don't need this, and it wouldn't be workable. AWB, with human oversight, can do this when we need it done. There are (not frequent) times when we want to intentionally link to disambiguation pages (and you can prevent people undoing them by using code like this: [[Foo|Foo<--Yes, this is an intentional link to a disambiguation page.-->]] One serious problem with automating replacement as GeoffreyT2000 and the anon suggest is that part of the very process of establishing a disambiguation page is going through uses of that character string as a link in articles before the decision was to make the link target for that string be a disambiguation page, and figure out which of the actual subjects to be disambiguated each instance actually refers to.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  08:31, 25 May 2015 (UTC)

The reason we use [[Foo (disambiguation)|Foo]] links rather than a notice on the page is to prevent editors from having to waste time looking at tens of thousands of pages containing intentional disambiguation links, in order to ferret out the links that do need fixing. bd2412 T 15:02, 25 May 2015 (UTC)

There aren't tens of thousands of intentional links to DAB pages (other than in hatnotes). In article text, it's a rarity.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  03:52, 28 May 2015 (UTC)

I can assure you that there are because I have seen them myself - most often in the "See also" sections of other disambiguation pages. They do pop up in unusual places, however. There is no telling when an article on a particular person or battle or city will note in the text that there are others by that name (or named after it) with a link to the disambiguation page. bd2412 T 04:03, 28 May 2015 (UTC)

Most see-also cases are not intentional links to DAB pages, it's just sloppy editing. I agree that a "lots of things are named after it" kind of link qualifies. These links aren't terribly common, and don't seem to be a problem.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  00:05, 2 June 2015 (UTC)

Is this Male chauvinism ?

Few months ago i saw a banner from Wikipedia which was something like this: "Why there so few female editors in Wikipedia, give your valuable suggestions and ideas to encourage the participation of more female editors."

Now when I wanted to keep the pages Heroine, Actress, Empress under my watchlist; I found that they exist as redirect to their male version. Now why can't we have an independent page of them, instead of redirect?

Please don't tell me, "You have come to the wrong place, you can discuss at the talk page of those articles." This is a subjective topic. One has to do lots of research and find sources to define those pages. I can't do it.I am a science student. Someone else must do it.--C E (talk) 13:05, 23 May 2015 (UTC)

Having articles at the female version of those terms would only make sense if there was a significant amount of content related specifically to women that could be placed there. The articles on those terms seem to have very little such material. Nor is having the article at that title necessarily sexist: the article on hero says that the term can be gender neutral and the article on actor notes that the term is increasingly being used to describe women as well as men. I don't think Wikipedia would be any more feminist by maintaining segregated content about women in areas where the material is almost entirely gender-neutral. Hut 8.5 13:47, 23 May 2015 (UTC)

I have seen articles with smaller notability with minimum content. Should Mother be a redirect for Father.C E (talk) 17:56, 23 May 2015 (UTC)

So... you would like Wikipedia to have seperate pages for the female terms for the same subjects, but you refuse to do any actual work to make that happen and demand that someone else do it? Good luck with that. Beeblebrox (talk) 18:35, 23 May 2015 (UTC)

Take a look at the Mother article. It goes into detail about biological, social, religious and cultural aspects of motherhood, none of which is applicable to fatherhood. If you can write that much about actresses that doesn't apply to actors as well then we can certainly have an article at actress. However to judge from the current state of the actor article being an actress is almost exactly the same as being an actor. (In any case this isn't a very fair comparison because "actor" can be gender-neutral and "father" can't.) Hut 8.5 20:39, 23 May 2015 (UTC)

I am not discussing it for animals:: Bitch , Tigress, if you are referring to them.C E (talk) 18:52, 23 May 2015 (UTC)

There are arguments both for and against separate treatment. Wikipedia traditionally avoided such, for example deleting the category for female American senators several times back in 2006-8, after which it stayed. More recently the creation of a category "Female American novelists" caused a (minor) media storm as it was claimed that it was denying that female novelists were "proper" novelists. The category, however, remained, and is now (as was inevitable) accompanied by "Male American novelists". For more detail on recent history of the debate see WT:GGTF and its archives. Please also join the ongoing debates there. All the best: Rich Farmbrough, 22:41, 23 May 2015 (UTC).

This quote from The Handbook of Non-Sexist Writing by Casey Miller and Kate Swift may also be of interest:

Of all the techniques for avoiding linguistic sexism, none is simpler than using the same agent-nouns for both sexes."

--Boson (talk) 22:55, 23 May 2015 (UTC)

Yep, and if you read the actor article it makes it clear that in recent times that term is increasingly considered gender-neutral, and "actress" is mainly just a category at awards shows now. I think the same probably applies to hero/heroine. Empress is the only one I would consider to be really debatable out of three mentioned in the initial post. Since we don't have emporers and empresses anymore there isn't really any chance of a linguistic shift to more neutral usage. Beeblebrox (talk) 00:58, 24 May 2015 (UTC)

Well, for actors and actresses in particular, these are not really interchangeable things, really; if you hire Jessica Lange for a part and she falls ill you can't really replace her with Keanu Reeves or whatever, without making significant script changes. This isn't true for all films and plays but is for most, and this constriction of roles greatly colors the careers of actors and actresses. The practical difference between an actor an actress is certainly more than between a shortstop and a third baseman (a shorstop can fill in at third base better than an actress can fill in for an actor), and we have separate articles for those.

But if you're going to have one article for both, it's rather silly to assume that its going to fall under the male rubric without even thinking about it. Which y'all have and you know that you have. What I would suggest is that the article Actor be moved to Actress and the opening sentence changed to "An actress (actor for a male; see terminology)..." and other changes to body text as appropriate.

The objection that "Well other people don't do that" is meaningless of course (I mean, so what?), and any appeal to preponderance of reliable sources completely misunderstands what reliable sources are for: for establishing statements of fact, not for tying us to the dead corpse of the past centuries. Reliable sources have little or nothing to do with what our article titles are. And the objection "The male role should have pride of place as nature intended" I do not not find particularly edifying.

It's hardly worth talking about because, for various reasons, we're not going to do this.

But we should. Herostratus (talk) 01:29, 24 May 2015 (UTC)

Your first paragraph is a complete red herring. The term "actor" can apply to all sexes. Jessica Lange is an actor, Jessica Lange is an actress. You cannot say Keanu Reeves is an actress. --NeilN ^{talk to me} 15:19, 25 May 2015 (UTC)

I can and I will: Keanu Reeves is an actress. There's not a shred of a reason, beyond mere habit, or the unthinking assumption that "male" is the default status for a human being, or the mindless parroting of people who are of that mind, not to embrace that nomenclature. Join the 21st century. Not worth arguing over as I don't expect to make much headway on this point, notwithstanding being correct. Herostratus (talk) 18:17, 26 May 2015 (UTC)

Sure, one can call Keanu Reeves, actress -- indeed, if he was really superb at his art everyone could and would suspend disbelief and go along with him in the role. Regardless, on the original issue Hut makes the most sense. Alanscottwalker (talk) 18:59, 26 May 2015 (UTC)

Yes indeed! Meanwhile, back at the question, as anyone who follows entertainment news has become aware over the last decade or so, most thespians of the female persuasion now refer to themselves as actors, not actresses. On the one hand, this is informed by the egalitarian impulse that has pushed aside "stewardess" for "flight attendant" and, less successfully, "waitress" for the ungainly "waitperson" or ambience-free "server." Methods of interpreting dramatic roles may vary from school to school, performer to performer, but there is no gender-defined difference in process. An actor is an actor. On the other hand, if there is no difference in craft between men and women, why are there separate Oscar and Emmy award categories for males and females? I don't see that custom changing anytime soon, just as I don't see any imminent change in WP customs in this regard. DoctorJoeE ^{review transgressions}/_{talk to me!} 19:38, 26 May 2015 (UTC)

There are separate categories in the Oscars because some organizations are behind the egalitarian curve, and because the Oscars show would be cut in half, and because actors don't want to see the available awards halved, and .... The fact that some organizations do gender-divided things doesn't mean WP has to follow suit. We already do far too often.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  03:48, 28 May 2015 (UTC)

• If you ask me, having separate articles at heroine, actress and empress would be male chauvinism. It would suggest that the females are different, and imply inferior, to their male counterparts. And in the case of heroine, that is actually true, as in traditional literature, the heroine is rescued by the hero, rather than being a real hero in her own right. Oiyarbepsy (talk) 13:28, 28 May 2015 (UTC)

There is a discussion here, about merging an female-specific category. One of its arguments is that such gender-seperation is 'marginalising'. … … ps it occurs to me that most professions DON'T have gender-specific names (driver, lecturer, doctor, politician, teacher, singer, artist etc.), therefore it would be inherently arbitrary to have articles for the (relatively few) that do. This is of course in addition to the 'gender being irrelevant to achievement' argument.Pincrete (talk) 23:35, 31 May 2015 (UTC)

There is quite a lot of false logic on this page, 'er'/'or' are two of the common suffixes for 'person who does this', an inventor is someone who invents. The created word only becomes gender-specific when a 'female' form of the word also exists (temptor/temptress). If there is a distinct need for a gender-specific article (I cannot think of examples, but they may exist), we should have one, but otherwise there is no point in having a general rule to have them.Pincrete (talk) 10:22, 1 June 2015 (UTC)

Query strings in URLs and other languages

Words in query strings in URLs under other language versions of Wikipedia should also be written in that language, rather than English. For example, on the Spanish Wikipedia, instead of displaying "title=", it should display "título=". GeoffreyT2000 (talk) 18:18, 25 May 2015 (UTC)

You could file that suggestion in phab: if you wanted, but I'm not sure that it's a good idea. For most languages, some users will get an encoded, unreadable string of ASCII characters instead of their own language. (What you see in your web browser will depend upon your computer.) For all its flaws, "title" may be better than "t%C3%ADtulo" (the encoded version of título). Whatamidoing (WMF) (talk) 08:44, 27 May 2015 (UTC)

Perhaps generalised labels such as t= (title), d= (diff) or v= (version), o= (oldid), a=e (action=edit), s=3 (section=3), etc., so their language-specific nature were less obvious? —sroc 💬 11:52, 2 June 2015 (UTC)

WikiWidgets

Some time ago I thought that many readers would benefit if we could embed simple interactive programs (widgets) into articles to help illustrate and explain the concepts within them. So I thought of a crude way to implement it and made a proposal here. However, maybe due to technical and conceptual immaturity, it didn't garner much support. So I took it to my home project, the Spanish Wikipedia. There it sparked some interest, and slowly we refined it and eventually implemented it. Today we have two wikiwidgets already deployed, you can check them out here and here.

Today I'd like to share with you the way we implemented it, and ask for your support to get it working here in the English Wikipedia. Basically, to get the wikiwidgets working we need three things.

First we need to create the Template:WikiWidget. That's easy, I just did it. Second, we need to add the following lines to MediaWiki:Common.js:

/**
 * Inserts WikiWidgets in the articles with the Template:WikiWidget
 * WikiWidgets serve to illustrate and explain interactively the concepts treated within articles
 */
$( '.WikiWidget' ).each( function () {
	var wikiwidget = $( this ).attr( 'data-wikiwidget' );
	importScript( 'MediaWiki:WikiWidget-' + wikiwidget + '.js' );
	importStylesheet( 'MediaWiki:WikiWidget-' + wikiwidget + '.css' );
});

This code checks for the presence of the WikiWidget template in every page. When found, it loads the code of the wikiwidget named in the first parameter of the template. If the wikiwidget is called X, the loaded code will be MediaWiki:WikiWidget-X.js and MediaWiki:WikiWidget-X.css. So the third step is to add the code of one or both existing wikiwidgets to their proper pages in the MediaWiki namespace, that is:

• MediaWiki:WikiWidget-Formicarium.js
• MediaWiki:WikiWidget-Formicarium.css
• MediaWiki:WikiWidget-Vivarium.js
• MediaWiki:WikiWidget-Vivarium.css

You can find the code in the homonymous pages in the Spanish Wikipedia, or at the GitHub project here.

Besides the implementation, a bit of documentation will be needed for the template, at Wikipedia:WikiWidget and maybe even a WikiProject, but I can take care of that. What I cannot do by myself is the stuff in the MediaWiki namespace, but even if I could, I think that the project is novel enough to require some support of the community before asking an admin to implement it. So I hope you like it and support it, and even help me develop it, cheers! --LFS (talk) 15:50, 26 May 2015 (UTC)

While this would be interesting in theory, I have to oppose this on the principle that we shouldn't require JavaScript for page content. JavaScript can and should enhance site functionality, but shouldn't be strictly required whenever possible. {{Nihiltres|talk|edits}} 16:37, 26 May 2015 (UTC)

I also think this is a bad idea, for a number of reasons. Embedded JS raises serious performance, accessibility and security concerns. Performance in that running JS uses CPU cycles. Accessibility as many people disable JS; many more have browsers unable which don't support HTML5/JS which this needs. And security as having complex and arbitrary JS run on pages opens them up to all sorts of exploits. We can already do animations with animated GIF or movies, so there’s little need for it.--JohnBlackburne^words_deeds 16:52, 26 May 2015 (UTC)

Hi, thanks for your constructive criticism. The wikiwidgets don't make JavaScript necessary in any way. I forgot to mention this (sorry) but the second parameter of the WikiWidget template is the file to be shown when the wikiwidget isn't loaded. In fact, the file is always shown, it's just that it's replaced by the wikiwidget when the JavaScript code loads. If the code doesn't load for whatever reason, then the file will just stay there. This means that the JavaScript code isn't required at all, pages will render fine without it. Having JavaScript just enhances the user experience.

As to security, the development process of wikiwidgets is very similar to that of gadgets, yet we don't reject gadgets for security concerns. We just need code review, like with gadgets or any other piece of code, and this will be accomplished through the GitHub project.

Regarding performance, I can edit the existing wikiwidgets so that they don't start automatically, and we can establish this as a rule for further wikiwidgets. This would make them much less of a bother for those with weak CPUs.

I think that a wikiwidget isn't nearly the same as an image or a movie: it incorporates a key element to the learning process: interactivity. The existing wikiwidgets already show some of the potential (did you play with them for a while?), but there is a lot more to be discovered. Imagine other wikiwidgets for explaining the movements of the planets or other physical phenomena, and all those that we cannot imagine yet. The field is vast. But even if we never get beyond a few wikiwidgets, then a few is better than none, don't you think? We already have two available, all we need are a few lines of code to get them working. Cheers! --LFS (talk) 01:55, 27 May 2015 (UTC)

Your two demo links were impressive. They are very valuable additions to the articles. Unfortunately I don't think we can allow editors to inject arbitrary code into pages. It's a security issue. Alsee (talk) 02:56, 27 May 2015 (UTC)

Hi Alsee, I'm glad that you find them valuable! As mentioned above, the security risk is no greater than with gadgets. Do you think gadgets are a security issue? --LFS (talk) 03:35, 27 May 2015 (UTC)

I do, and I suspect that anyone who knows anything about what could be done by an admin who is careless (or whose account was hacked by someone malicious) will agree with me. We ought to require code review for popular gadgets—including every single change, not just when it's first enabled. Code review isn't fun, but it does prevent problems. WhatamIdoing (talk) 08:50, 27 May 2015 (UTC)

WhatamIdoing: so some gadgets are not reviewed? That sucks, I agree that every gadget should be reviewed! The one gadget I contribute to (ProveIt) does have code review. In any case, unlike gadgets, WikiWidgets will be developed in a centralised way through the GitHub project. In GitHub, only approved users can contribute code, and if a non-approved user wants to contribute, s/he has to do a "pull request" and the code will necessarily go through review. GitHub is a tried and tested platform for code collaboration. If the project gets implemented, people will not rush in to create wikiwidgets, more likely there will be one submission per year, so I will definitely review it properly. And if somehow the project starts getting too many submissions for me to review (extremely unlikely) then surely other developers will help me, especially given the fact that this project aims to be inter-wiki, so the same code will be used in all Wikipedias. --LFS (talk) 13:10, 27 May 2015 (UTC)

Gadgets have been mentioned but they have two key differences. First they are opt-in. They may start off as some editors personal tool, which they advertise and gets adopted. Eventually they may be added to preferences, but that's not a requirement, and many still exist as snippets of JS and CSS you add to your own common.js and .css or similar. This means they cannot affect editors who haven't enabled them and aren't aware of them. Second because of they way they work they are typically visible to editors using them across all pages. This means that problems with gadgets are almost always spotted and reported very quickly.

On the other hand problems in articles can go unnoticed and unreported for a very long time, weeks, months even years. At the moment these only damage the encyclopaedia, by lowering its average quality. But if JS widgets were allowed in page the potential for direct harm to readers is much much greater, which also increases the incentive to do harm, and to hide the nature of the damaging JS. Mandating a thorough code review would catch many if not most of these but that would be an immense amount of work, which we don't do for any other sort of content. JohnBlackburne^words_deeds 16:24, 27 May 2015 (UTC)

JohnBlackburne, I take it that your previous concerns about performance and accessibility were answered. It seems that the security issue is the main concern for everyone involved in this discussion, so hopefully if we dismiss it the project may get some support. WikiWidgets will be developed through GitHub, the largest platform for code collaboration in the world. GitHub has a system by which only approved users may submit code directly, and non-approved users have to submit a "pull request" which forces approved users to review the code before merging it. This is the way most software is developed today. The existing wikiwidgets are composed of a single JavaScript file of less than 1000 lines of code, and future wikiwidgets are unlikely to grow much bigger, which means that they are really easy to review, compared to gigantic softwares like MediaWiki. You mention that the workload may be too great, but don't worry, most likely there won't be a single submission in the rest of the year, and if there is I will be glad to review it, rather than burdened. (Plus you won't be doing the work, I will!) As with any piece of software, the risk of malicious code slipping by will never be absolute zero, but I hope you will not let that dim chance put a stop to a project that could be a step forward for Wikipedia and has much more potential to do good than harm. --LFS (talk) 18:58, 27 May 2015 (UTC)

No, the performance and accessibility issues are still issues: pages on WP currently load fine with no JS at all (though it's needed for many optional and editing features). But security is the main concern. We certainly don't want to require editors to sign up to and become familiar with GitHub to contribute. It has its uses but largely replicates what we have here already. E.g. instead of a commit history we have a page history. Instead of being able to fork here you can use a sandbox or sandboxes. And as far as we are concerned WP's mechanisms are stronger: we have e.g. user rights so not everyone can edit code. Anyone can sign up to GitHub. Users contributions here are tied to their accounts, useful for awarding rights and reviewing them. That would not be possible with GitHub contributions. And so on.JohnBlackburne^words_deeds 19:34, 27 May 2015 (UTC)

Ok JohnBlackburne, let me know what concerns you about performance and accessibility, maybe there is a solution. Regarding the use of GitHub, please remember that software designed for code collaboration is much more efficient at code collaboration than software designed for building an encyclopedia. The MediaWiki software is developed using Git, though not GitHub. We use another code review software called Gerrit, plus Phabricator for tracking bugs. Many MediaWiki gadgets are developed using GitHub, as well as some extensions and dependencies of the software. Nevertheless, if this project gets some support, I can almost certainly move the development of wikiwidgets to Gerrit and Phabricator, where it would be more in line with the way the majority of the software for Wikipedia is developed. --LFS (talk) 02:16, 28 May 2015 (UTC)

Again the performance and accessibility issues are that it uses JavaScript. I am typing this on a relatively old (2006) laptop. Hardly ancient and it still works fine. Except many web sites are unusable due to JavaScript; they slow to a crawl, and/or start using 20% of CPU. Open two or three tabs and it can bring my whole machine to a halt. So I sometimes have to turn off JavaScript to browse them. Not WP though which works fine without JavaScript (though I loose some gadgets such as popups). Right now any WP page wastes no CPU cycles on JS whether reading or editing. If it did I would have to consider disabling JavaScript to view such pages, or not visiting them at all. Other people may not have that choice, or may not be aware of it, so may just find WP suddenly slow and stop visiting. Still others will disable JavaScript for other reasons: to disable adverts, or paywalls, or for general security reasons. And many will have older browsers which do not support the particular HTML/JS capabilities this depends on.

The point about Github is these are content, not parts of the WP software. And content is hosted on WP, or on Commons. This even includes source code, such as Lua, and a limited amount of JS such as MediaWiki:Common.js. Hosting it on GitHub would just exclude many editors from contributing, whether that's contributing code, checking and verifying code, or making suggestions for improvements. Given that GitHub largely duplicates what we have here it would seem perverse to host it there when it can be done very easily on WP with far better integration into WP systems and accessibility for WP editors.--JohnBlackburne^words_deeds 19:50, 28 May 2015 (UTC)

I'm adding a few quick comments here, to make sure that we're all using the same language:

• "Gadget" means "thing listed at Special:Gadgets". These are the scripts that you'll find in Special:Preferences#mw-prefsection-gadgets. If you create the same kind of thing, but it isn't listed there, then it is called a "user script".
• Gadgets can be, and sometimes are, enabled by default. At the moment, I count nine gadgets enabled by default in the list at MediaWiki:Gadgets-definition at the English Wikipedia (this is the page you [if you're an admin] change to add, remove, or re-configure all gadgets). The list of on-by-default gadgets include mostly Javascript (e.g., charinsert, RefToolbar, Reference Tooltips) and a couple of things with both Javascript and CSS (e.g., Teahouse, Featured Article links).
• Code review is a sort of (very) fully protected style of WP:Pending changes for code. The general idea is that I post my code revision, but nobody uses that code unless and until someone else (someone trusted) looks it over and agrees that my code is sensible and unlikely to break stuff.
• There is no way to require code review for any user script, any gadget, or any other page hosted on wiki. (Even if it could be applied to Javascript files or pages in the MediaWiki: namespace, Pending Changes never stops an admin from making live changes to a page.)
  • Exactly like user scripts, almost none of the gadgets at the English Wikipedia are fully (formally) code reviewed. This is because most of them are hosted directly on wiki, where your change to the page is live immediately, no matter what.
  • There is no way to prevent any admin from making immediate changes to what's in the list of gadgets or whether they're turned on by default. Other tech-savvy admins also watch the page, but your (any admin's) change to the gadgets page is live immediately, and if your typo breaks things, then it's broken for thousands of readers and editors immediately. There is currently no way to force code review for this page. Admins can optionally choose to post their suggested code in a sandbox or on the talk page, but there's nothing except their own fear of breaking things to require sensible measures like that.
  • Ditto for pages like MediaWiki:Common.js, which hosts what you might think of as "gadgets" that you're not allowed to opt out of. m:WikiMiniAtlas is a particularly relevant example, since it's code-reviewed using the same system that LFS is proposing, it's enabled for everyone (with no ability to opt out, even), and it directly affects article content.
• The lack of code review for on wiki scripts has led to a variety of problems, usually minor, over the years. Here at the English Wikipedia, it's usually resolved within a few hours. At some of the smaller wikis, problems have persisted for years, and many of them are quite easily identified through basic code review. For example, in 2013, someone found and fixed a problem at a small Wikipedia that was due to someone pasting the same code twice into the common.js (or was it common.css?) file. This is the sort of problem that code review usually catches.

If you're interested in this problem, then I'll add that a system for code review for gadgets and other designated scripts could be implemented, but it would require more than a little bit of dev time. I don't know if it's likely to happen unless the larger communities request it. WhatamIdoing (talk) 15:19, 29 May 2015 (UTC)

Thanks for your contribution WhatamIdoing. I just checked and it seems like Gerrit has no repositories for gadgets! It looks like they are all developed via GitHub or some other code developing platform, or even through no platform at all (no code review). Indeed it would seem that organising and even centralising gadget development would be a good thing, but this is another issue (and a big one for sure). I may start a proposal at Wikimedia when I find the time. Anyway, back to the wikiwidgets, I told JohnBlackburne that I can probably move their development to Gerrit, but it would probably be easier to do that if we first implement wikiwidgets in the English Wikipedia, as doing so would add weight to the request to open repositories for them at Gerrit. Do you think that it would be better to move the development of wikiwidgets to Gerrit, or does it seem equally ok to you if it's done via GitHub?

JohnBlackburne, regarding performance and accessibility, I updated the code of the wikiwidgets so that they don't start by default. Could you check if the pages with the wikiwidgets in the Spanish Wikipedia load ok for you now? Here and here are the links. Cheers! --LFS (talk) 15:14, 5 June 2015 (UTC)

I have no preference between Gerrit and GitHub. I am satisfied with any platform that encourages code review. WhatamIdoing (talk) 20:35, 5 June 2015 (UTC)

• Tenatively support: This would be very useful for all sorts of things. An immediate one that comes to mind is illustrating things in cue sports articles, with a virtual billiards, pool, or snooker table. My security hairs raised immediately too, along with those of others, but your answers so far seem adequate. I'm seeing some "damned if you do, damned if you don't" flawed reasoning in some of the security-related naysaying. We can't simultaneously expect that the ability to inject Javascript into pages must be strictly limited, then complain that it can't be strictly limited because that would impede editors from using this tool. It's perfectly fine to require people to use GitHub if that's what's it takes to do this securely. We do stuff like this all the time, like now all the interwiki stuff is done offsite at Wikidata, and I can't be bothered to figure out how to use it. There are 100,000 other things for me to do on WP, so no overall productivity to the project is lost; some people just become Wikidata-competent and some don't. The move of complex templates to Lua modules is the same; some editors choose to learn enough Lua to deal with it, others work on something else. I also don't buy the "we can't require Javascript" argument; it'd be a simple content guidelines matter to add a line somewhere saying not to build articles in such a way that they can't be understood without JS. This really isn't any different from adding videos and other supplementary material, and frankly WP is already greatly usability-impeded without Javascript, as are almost all modern, complex websites. JS support is just part of how the Web basically works, and has been since the late 1990s.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  03:33, 28 May 2015 (UTC)

Thanks for the tentative support SMcCandlish, let me know if you see any blocking problems. --LFS (talk) 15:14, 5 June 2015 (UTC)

I don't see any, really.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  20:29, 5 June 2015 (UTC)

• These examples show that the javascript is used differently to the rest of the javascript on wikipedia. Rather than a tool for editing (or reading) support, the javascript is the content. I think this is important and that this this javascript needs to be treated more like images to video than the rest of javascript (think: moving to commons, systematic approaches to finding display alternatives, etc.). Stuartyeates (talk) 03:47, 28 May 2015 (UTC)

Stuartyeates, moving the wikiwidgets to Commons would definitely make sense, as the code should be exactly the same throughout the various Wikipedias, except for the internationalised messages. However, I'm pretty sure that the software isn't quite ready for that, and until there are enough wikiwidgets in enough Wikipedias, there is little incentive for the Foundation to invest resources on it. If we want the wikiwidgets to be hosted in Commons, I think that the best start would be to implement them in enough Wikipedias, starting by the English Wikipedia, and if the project grows enough, we can then do a stronger proposal to the Foundation. --LFS (talk) 15:14, 5 June 2015 (UTC)

I tend to concur, though it wouldn't hurt to ask over at Commons and see what the reaction is. These strike me as different and severable issues though. Where it's hosted has little to do with whether en.wiki should use this.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  20:29, 5 June 2015 (UTC)

Proposal to add edit restrictor to MW software

The goal of wikipedia is to be able allow anyone to edit. It also follows the policy that blocks are to be preventative but not punitive. We also have topic bans. I propose we add a component to Wikipedia that allows administrators to block users from editing specific pages with the ability control expiry.

Purpose:

• To allow administrators to control which pages a user cannot edit through specific page matching or through regex matching as well as control a restriction rule's expiry.

Description of proposed addon:

• The functioning is similar to the combination of the block function combined with parts of the title blacklist function, spam blacklist function, and the abuse filter. The blocking administrator is able to create a rule, where within the rule, s/he can place a regex expression into a deny list as well as pages in a page matching list. Any false positives through the regex deny list can be overridden through a page matching allow list.
• The blocking administrator is able set an expiry for this rule.
• There is no limit to the amount of rules that can be added, each with their own expiry.
• Expiry can be indefinite.
• Rules can be modified by other admins.

Usefulness:

• Users with topic bans can be stopped from editing those topic pages through a reggaeregex expression or several page matching expressions.
• Users caught in an edit war can be stopped from editing the page they are warring on while still allowing them to productively edit other pages.

Why:

• While blocks are to prevent a user from being disruptive somewhere, it also may prevent them from being constructive elsewhere on the project.
• Reduces arbitration enforcement blocks for those with IBANs or topic bans, thereby allowing the editor to continue to contribute constructively.
• Blocks are not meant to punish, so let's not punish with them. Blocks can still be used for vandalism, or persistent disruption, but that can be worked out in a policy RfA should this pass.

Policy:

• Should this feature come to pass, this feature is not to be used until the necessary follow up RfAsRfCs focusing on the policy on the usage of this feature have to come to pass.

Userrights introduced: 3 user rights are introduced and grouped into the sysop user group. (or into different usergroups sometime in the future)

• restrict-editing: Allows a user to create an edit restriction rule.
• unrestrict-editing: Allows a user to remove an edit restriction rule.
• modify-restriction: Allows a user to modify an existing rule.

Access to this function:

• Links to this function neighbor the block links, if visible.

These abilities have been split into 3 rights should there be a reason to add certain abilities into different user groups.

Proposed by —^cyberpower_Chat:Online

Support (edit restrictor)

1. As proposer.—^cyberpower_Chat:Online 12:50, 27 May 2015 (UTC)
2. Pretty top idea... I'm sure technical and procedural issues will need to be overcome, but as an idea it gets my support. EoRdE6^{(Come Talk to Me!)} 13:23, 27 May 2015 (UTC)
3. While I suspect that many users blocked from their pet pages might take to vandalizing elsewhere in retaliation, it might be worth a trial run. It would probably be easiest to allow blocking by category tree (although I'm not sure on the software end how feasible it is to include a category and all pages in sub-categories). --Ahecht (TALK
   PAGE) 14:06, 27 May 2015 (UTC)
4. Blocks aren't punative, thry're preventative. If we have a reasonably simple preventative method against users attacking specific groups of pages, without blocking them from nearly all of Wikipedia, it's certainly better. עוד מישהו Od Mishehu 14:17, 27 May 2015 (UTC)
5. There will certainly have to be a lot of discussion regarding implementation and policy, but I support the tool and the theory of using it. Kharkiv07 (T) 14:46, 27 May 2015 (UTC)
6. Support, it is like a technical embodiment of a topic ban, but I hope this restrictor can compare article categories too (not only article titles), because topics often have articles with very dissimilar titles but similar categories. Spumuq (talq) 14:47, 27 May 2015 (UTC)
7. Support, block is a very blunt tool. Having administrators be able to use more specific intervention could be useful in cases where a usually great editor looses their head on a particular topic. It would give a great way to deal with those occasional, but very frustrating to newbies, cases where an established editor is allowed to act very badly on some pages because they are so useful in other areas. Happy Squirrel (talk) 19:06, 27 May 2015 (UTC)
8. Support. Blocks are sometimes too broad and prevent otherwise constructive contributions as a result of issues on a specific page. Of course, as others have mentioned, there may be complicated technical work involved, but I support the concept. --Biblioworm 02:20, 28 May 2015 (UTC)
9. Tentatively support: Anything that reduces WP's dependenc—e on blocks (which we all know are often punitive, despite policy against this) would be an improvement, if it doesn't cause additional problems. I share the concern about movewarring, but not very seriously. If the tool is used to enforce a topic ban, then simply renaming the article to edit it won't do anything but get the user blocked for violating the topic ban. I would see this a supplement to editing restrictions of our present sort, not a replacement for them, but one that might obviate a large number of blocks. There may be devils in the details, though. I'm not sure I like the idea using this to stop alleged editwars and other supposed disruption. Plenty of noticeboard claims that "so-and-so is editwarring" aren't actually sustained on closer examination. The tool would also rob users subjected to it of a possibly minor editorial right, to WP:IAR against a topic ban, e.g. to revert blatant vandalism, for which they'd be unlikely to be found guilty of an actual topic-ban violation. I agree with the basic goal, which is keeping sometimes-productive editors productive instead of driven away completely.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  02:38, 28 May 2015 (UTC)
10. Support. I was going to bring up the same problem that Steel1943 had mentioned below, but I rather like cyberpower678's proposed solution. Otherwise, great idea. APerson (talk!) 01:33, 29 May 2015 (UTC)
11. Support per SMcCandlish – RGloucester — ☎ 02:14, 29 May 2015 (UTC)
12. Support – great idea and makes a lot of sense. – Hshook (talk) 04:31, 29 May 2015 (UTC)
13. Huge Support - Great idea, could be used as a topic-band or just to keep someone off a page. There is an anon user who vandalizes the same page repeatedly. We block, he comes back, we block again. To block him on just that page would be excellent. One question: would it be possible to use this as a rangeblock (for IP users)? - Neutralhomer • Talk • 05:31, 29 May 2015 (UTC)
14. Conditional Support - As another said, the devil is in the details. (1) The ban should be imposed for a finite period, automatically lifted when expired. I suggested the page-specific ban in my comment to the recent news about Sony executives puffing Sony pages. I hypothesized a trained and experience writer/researcher in the Sony office who gets out of line with his/er puffery in Wiki editing. The administrator imposes a 28 day ban on the Sony-related pages. The effect of the ban is a career penalty on that person at his/er place of work -- his/er production is frozen for 28 days. As long as s/he stays under the wire, everything is good. Over the wire -- bam! -- penalty. The puffer learns. (2) The word for this tool must be caution and discretion. My experience shows that Wikipedia is a community. Editors have specialized areas of interest and knowledge, so they stay active for extended periods on those pages. Controversies develop. The page pan must not be allowed to fall into partisan hands. (3) The page ban could be useful during DRN. During two recent DRN actions, some editors continued to edit the pages even even while the subject pages of the edits were under discussion. Other editors, even when instructed to avoid ad hominem, launched immediately into ad hominem, disrupting the DRN. A page-specific ban would be a useful tool in the hands of the arbitrator, imposed for the period of the DRN process would be useful. (4) A page-specific lock routinely imposed on DRN interested parties might prove useful during all DRN actions. This last proposal might be a bit drastic, but I am wondering if any editor named as an interested party in a DRN should be editing the subject page. If not, the routine page ban would be no hardship. Grammar's Little Helper (talk) 07:52, 29 May 2015 (UTC) PS: (5) This is not the remedy for vandalism; true vandalism should should incur complete banning. Grammar's Little Helper (talk) 00:55, 30 May 2015 (UTC) Addendum: I did not pay much attention to the regex proposal, and forgot to answer that. Given the complexity and various dialects of regular expressions, and given the variety of backgrounds among the administrators, I would vote against the use of regular expressions in this context. I have used regular expressions for more than 25 years, and would still never write an expression without thoroughly testing it prior to application. It is also unnecessary. To ban a user from a page or a list of pages, name the page or the list of pages. In that way, the ban can be posted to the user's page along with the expiration date, and everyone will understand (not just the reg and his ex'es). Grammar's Little Helper (talk) 04:59, 31 May 2015 (UTC)
15. Support - Should be able to help situations where user vandalise a specific set of pages without precluding them from making useful contributions to other articles. — Andrew Y _talk 08:39, 29 May 2015 (UTC)
16. Cautious support - as long as it doesn't become abused, this should be a useful feature. --ProtoDrake (talk) 09:09, 29 May 2015 (UTC)
17. Support but without the regex funny stuff. If an editor is to be blocked from editing multiple pages, each page must be specified explicitly. Some simple wildcards, like subpages, are OK. -- [[User:Edokter]] {{talk}} 09:32, 29 May 2015 (UTC)
18. Emphatically Support - just because an editor is having trouble in one "department" should not allow us to assume that he/she will cause trouble elsewhere. Adopting this policy will allow for the fine-tuning of blocks and bans to achieve their purpose of separating warring parties on specific articles, rather than using a sledgehammer for what a nutcracker can do. David Cannon (talk) 10:26, 29 May 2015 (UTC)
19. Support - A useful intermediate step before a proper block, as long as it's not abused (which is the same stipulation given to any proposed control device).   ~ Tom.Reding (talk ⋅contribs ⋅dgaf)  13:03, 29 May 2015 (UTC)
20. I'd like to see this used in place of blocks for isolated instances of edit warring. Other uses ... not so sure - let's see what comes out of a wider discussion. But as a far more surgical and less disruptive response to edit warring, it has my vote. --Anthonyhcole (talk · contribs · email) 13:12, 29 May 2015 (UTC)
21. Support --- :D Derry Adama (talk) 14:08, 29 May 2015 (UTC)
22. Support with a period of time specified as with full blocks. The edit restrictor looks to be a better way to automate a topic ban. -Fnlayson (talk) 14:35, 29 May 2015 (UTC)
23. Support the idea of per-page editing restrictions. At the moment if someone is edit warring on a single article then we have no way to get them to stop without preventing them from editing all pages, anywhere, whether they're causing disruption anywhere else or not. This just doesn't make much sense. Hut 8.5 16:47, 29 May 2015 (UTC)
24. Support - in principle; the idea of implementing a 'topic ban' with actual technical restrictions is a very good one. GiantSnowman 16:58, 29 May 2015 (UTC)
25. Support: Practical way of enforcing topic bans, and where an editor is only causing disruption in one area of the encylopedia but is helping elsewhere, that editor can still be constructive. I once had a proposal to "selectively block" users from editing certain pages, but possibly because of the way I worded it, it didn't gain as much ground as this one. I still doubt this will pass though, since Wikipedia editors hate change and seem to oppose everything (that is, the majority of sensible proposals here still have more opposes than supports it seems). Dustin (talk) 17:24, 29 May 2015 (UTC)
26. Wildly, enthusiastically, head-over-heels in a flowery meadow support I have been suggesting this for a very, very long time, and was told the main problem was that it was a non-trivial technical problem. I am pleased to see that it no longer seems to be the case.

    Before I voted, I took the time, as we all should, to read the oppose votes. I understand their objections but believe them to be misplaced:

    Some opposes say that "anyone who can't follow a topic ban should not be allowed to edit in the first place." This might be true in the many cases where the tbanned editor's edits are overwhelmingly, predominantly, in that one topic. But even when it is ... we should give the editor a chance to prove that it's not the community that's the problem, but the topic. I have often suggested to editors feeling the walls closing in on them that they try editing articles about something other than their favorite bands or TV shows for a while, perhaps their hometowns, or their favorite foods. I find that editors, like myself, who edit in a wide and disparate group of topic areas are generally better-adjusted than those who focus on, say, one particular region's political history or something like that.

    And others say it's a technical solution to a policy problem, that editors should be on their honor to obey topic bans. If that approach worked in real life, we wouldn't need radio-equipped ankle bracelets or ignition interlock devices. Nor do I think this will lead to move wars to evade topic bans ... if you can't edit the article to begin with, you can't move it. Daniel Case (talk) 17:30, 29 May 2015 (UTC)

27. Support- It will be useful when blocking a new editor or ip user who edits disruptively on specific articles but edits constructively on other articles. I don't see any bad sides of the tool, then having it is useful when time comes. I don't think this tool will be used as widely as standard block but it is definitely useful in some areas. I think rangeblock or autoblock will be helpful for reducing the chance of block evasion. - Supdiop ^talk 17:40, 29 May 2015 (UTC)
28. Support - If nothing else it might force a definition of the "broadly construed" construction. It's also clear that some editors work fine in certain areas but may cause problems in others. This helps address that without resort to a more punitive block. Intothatdarkness 18:46, 29 May 2015 (UTC)
29. I am all in for it if it gets tested first. If something goes wrong, this could be disatorious. And just for clarification, would this be for edit war style things only, or will it be used on vandals?--AMTalk/Contribs 20:29, 29 May 2015 (UTC)
30. Support - I support, as not all disruptive editing is straight up vandalism. There may be certain situations were an editor is just stubborn with a certain edit regarding a certain page, despite being over-ruled by the Talk Page/consensus. This would serve as a way to let the editor continue to helpful elsewhere while still restricting him/her for the sake of protecting the page he/she is disrupting. And if he/she continues to disrupt other pages, then administrators would still be able to block the user completely. It can also serve as a lesson to new users that disrupt one page, that way they don't disrupt any other pages in the future. I believe there is no harm in trying this out and, if it doesn't work, Wikipedia can just do away with it. Darkknight2149 (talk) 00:10, 30 May 2015 (UTC)
31. Support with caveat: I'm in favor, but we really need to avoid the Scunthorpe problem; see below. --Thnidu (talk) 03:58, 30 May 2015 (UTC)
32. Partial support. I've often had to put in edit filters for this very purpose, so in my opinion, it should be used primarily for blocking a dynamic IP on a very active range who is targeting a narrow set of articles. I oppose the reasoning behind this proposal; I don't think it would be particularly helpful in dealing with topic bans. Nonetheless, I am in favor of the technical specifications as described, despite wanting to use it for a different purpose. -- King of ♥ ♦ ♣ ♠ 05:20, 30 May 2015 (UTC)
33. Support Everyking (talk) 06:41, 30 May 2015 (UTC)
34. Qualified support I do not understand the technical details of this proposal, and so cannot comment on its feasibility. I believe it is desirable, though; I work in multiple highly disrupted areas of the project, and we spend far too much time at AE and ANI because somebody violated a specific ban or another. If it were possible to simply prevent that, that might allow a lot of time to be better spent building content, which is what we're here for. I share the concerns expressed below that this might provoke move-wars, but I don't think that's too likely; editors with topic bans that still allow them to edit have too much at stake. This proposal won't help with users here purely for disruptive reasons, but it might help with those who are too outspoken or lack self-control, but are still a net positive elsewhere. Vanamonde93 (talk) 09:07, 30 May 2015 (UTC)
35. Support I remain extremely skeptical about the utility of the proposal as applied to established editors, for the reasons explained by many of the opposes. However I don't see much harm, only a wasted effort, and as recently pointed out, this could be really useful if we could block IP Ranges from certain articles, without inflicting collateral damage on the unrelated edits coming from the range. Monty₈₄₅ 15:31, 30 May 2015 (UTC)
36. Support. There are many people who are fairly normal editors, unless they get in an edit war. You could also request that someone be blocked from editing your talk page, a problem that some have had. I'm a bit skeptical about non-admins getting this feature, though. Eman235/talk 16:51, 30 May 2015 (UTC)
37. Conditionally Support. I'm a bit worried that Admins will feel freer to issue these new restricted blocks. The same standards should apply as now. Compare to police tasers, which would be a wonderful alternative to using deadly force, but many police seem to use them so they don't have to run after a fleeing suspect, or as a punishment, or out of sadism. I don't want Admins also getting lazy and just permanently blocking anyone in a dispute from ever editing the disputed article again. StuRat (talk) 00:17, 31 May 2015 (UTC)
38. Support Topic blocks are a great idea. I've seen many editors who are disruptive in one area but very constructive in another area (e.g. edit warring on a political/religious article while pushing a science-related article towards GA or FA). Editors should only be prevented from editing areas where they are not a net benefit. Punishing them outright is silly. Gizza ^(t)(c) 01:45, 31 May 2015 (UTC)
39. Support for use in e.g. dealing with revert wars. Would oppose using this in lieu of a "topic ban." But, specifics of use can be whittled out when the capability comes to fruition. --EEMIV (talk) 03:59, 31 May 2015 (UTC)
40. Support as it would also be able to eliminate SPA's that are sockpuppets of banned editors or others that use multiple accounts to avoid a full accounting of their edits. --DHeyward (talk) 06:57, 31 May 2015 (UTC)
41. Support because it sounds like a useful tool in managing a certain type of editor. Jonathan Tweet (talk) 03:44, 1 June 2015 (UTC)
42. SupportAs for the AbuseFilter, the Pending Changes, etc. etc., of course this will be a burden on the server, but likely way less than the AbuseFilter. Although its functionality is currently covered by the AbuseFilter, the lower server load and a possibility to implement timelimits is a pré. This is a good idea to be developed and made available to MediaWiki (and developing it, and making it available does not incur that it is going to be widely used, but there is use for this). --Dirk Beetstra ^{T C} 04:58, 1 June 2015 (UTC)
43. Support but keep it simple, just have one right similar to block ( you can also reblock with changes or unblock). Also I expect a bit of code to make this efficient so that a regex is linked to a user, so it only slows down that one user. Alternately perhaps some users may get blocked from everything except one page to appeal or respond to a discussion about them. Graeme Bartlett (talk) 11:45, 1 June 2015 (UTC)
44. Support do I see problems like the opposers say? Yes, but I do think there are some situations it could be of good use. So worth a trial. Cas Liber (talk · contribs) 12:09, 1 June 2015 (UTC)
45. Support Most problem edits are local. A person has either a POV/obsession/ignorance on a page and keep banging. I thought about it long ago. Specific blocks will help a lot. Actually, better specifications will help in other things too. Jazi Zilber (talk) 15:41, 1 June 2015 (UTC)
46. Support Keep it simple and give it a try. Editors -- as humans -- have weak spots and instead of a using a heavy hand, this is a solution to keep otherwise good editors editing. Gmcbjames (talk) 20:56, 1 June 2015 (UTC)
47. Support Some admins are far too quick to block over isolated disputes (i.e. editwars). As least this would limit the damage and allow such editors to continue editing in unrelated areas. Curly Turkey ¡gobble! 10:59, 2 June 2015 (UTC)
48. Support Teemeah ^{편지 (letter)} 11:15, 2 June 2015 (UTC)
49. Support I think it would be helpful to allow admins to enforce topic bans using this function. Everymorning talk 12:13, 2 June 2015 (UTC)
50. Support: many Opposers seem to feel that if an editor should be banned from a topic, this should be achieved by banning them completely, as the editor is clearly irresponsible and not here to contribute. That's not what currently happens: topic bans can be and are implemented and enforced. I'm not saying the number of editors who should be given benefit of the doubt in the rest of Wikipedia is huge (run-of-the-mill vandals should just be blocked entirely), but within the narrow scope of people who benefit from topic bans, I think this proposal would be useful. Not a replacement for anything. Just an addition. And for the people arguing bans should be punitive, every unnecessary ban that stops someone contributing positively hurts the community. (And go easy on the regexing until you're sure the technical functions works. Another useful proposal might be to block users from editing any article whose talk page has Wikiproject X's template on it, if this is possible.) — Bilorv_(talk)^(c)(e) 16:24, 2 June 2015 (UTC)
51. Support: Good way to enforce bans. TheMagikCow (talk) 12:08, 6 June 2015 (UTC)

Oppose (edit restrictor)

1. From what I can see from the information provided, this proposal has good intentions. But with the way this proposal is currently worded/intended, it has the capacity to promote move warring (possibly by meat puppets or sock puppets) to allow the blocked editor to bypass the set title regex protection, and that essentially causes more harm than good. There are some things on here that are better off not automated, and per this proposal's current wording, this seems to be one of them. That, and enforced topic bans are probably more useful than this anyways since most topic bans usually come with a flurry of editors who are aware of the ban and have the affected article/subject on their Watchlist, and some will even go to extremes to watch the banned editor's contributions to see if there are violations. Steel1943 (talk) 19:18, 27 May 2015 (UTC)
2. As repeated failures to automatically tag articles with wikiproject tags shows, it's surprisingly hard to do things like this in a reliable fashion. I have very little confidence that even a regex guru would be able to craft suitable regexes to protect the appropiate pages. Stuartyeates (talk) 02:02, 28 May 2015 (UTC)
   • Thedifference is that in the case of WikiProject taging, we tend the bots to do a no-error job; in the case of regex page restrictions, a large number of missed pages doesn't make the filter bad - if it can do a 25% job, it's bettter than nothing. עוד מישהו Od Mishehu 07:58, 29 May 2015 (UTC)
3. oppose This is well meant and certainly would have its uses, but I shudder to think of the amount of work that would be needed. The addition of an entirely new mechanism for controlling access per user, with potentially large amounts of per-user data, with ways of viewing and editing (and controlling access to both) it. The amount of extra work for admins learning regexps and/or compiling lists of excluded articles/categories. The potential for it to break in all sorts of hard to detect ways (especially as only the editor that is banned will be able to confirm it is working as intended). And for what? The existing method of topic banning works pretty well, as all it requires is informing the editor (after e.g. an arbitration or AN decision). It is then up to the editor to abide by it. If they can't, so if they can't even after further warnings they cannot follow it, then blocks can be used. Also a ban done the current way is much more flexible than any filter based one can be: it can include topics within files, edit restrictions such as 1RR and interaction bans.--JohnBlackburne^words_deeds 02:15, 28 May 2015 (UTC)
4. A similar proposal was discussed at ANI where my response noted that if an editor cannot abide by community consensus they are not a good fit for Wikipedia—hiding a problem with a technical fix is not a solution. I saw a recent example of an admin topic-banning a user, where later the user asked at the admin's talk if the user could edit certain pages covered by the topic ban—after a very brief discussion the response was "yes". That is a perfect example of people collaborating, and someone who has to be forced to comply with reasonable conditions will find other ways to be a problem. Johnuniq (talk) 12:10, 28 May 2015 (UTC)
5. Commendable thinking, but this is begging to be gamed or be undermined by the swiss cheese holes in it. --Dweller (talk) 12:17, 28 May 2015 (UTC)
6. Topic bans are handled via social security, not automated security. The existence of an automatic, page-specific block will have the unintended consequence of assuming such a block is sufficient to enforce the topic ban. It isn't. A topic ban is enforced by everyone being vigilant and reporting a person who violates it. The existence of such a tool implies that a topic ban merely consists of a finite and unchanging list of pages a person is not allowed to edit, and that enforcement requires nothing more than preventing someone from editing a few pages. No. That's a small part of what a topic ban is, and we should not turn over the human element of behavior enforcement to machines. They are ill suited for it. --Jayron32 14:57, 28 May 2015 (UTC)
7. Good intentions aplenty for sure but not seeing this as a good idea. Not only does this seem like a wikilawyer's dream, it's incredibly prone to gaming ("My topic ban said I couldn't call that user a dick anymore, but 'veiny spunknozzle' went through the edit filter just fine, so it's ok."). But fundamentally I'm just not sure it would justify its added trouble--anyone disruptive enough that we need to program robots to stop them from shitting all over the furniture would probably be better off simply being shown the door. Andrew Lenahan - Starblind 15:18, 28 May 2015 (UTC)
8. This is a technical solution for a policy problem. The problem is the incredible popularity, among admins, of the phrase "broadly construed". If topic-banned editors actually know what they're allowed to edit and what they're not, they would seldom have any trouble following the ban; the problem is, they not only have vague boundaries, but often (usually?) there's some opponent from their previous trouble watching what they do and waiting for a chance to call them out. Suggestion: make the topic bans smaller and clearer, and you won't need the tool; otherwise, the tool will be useless anyway. Wnt (talk) 20:31, 28 May 2015 (UTC)

   Except that this feature would promarily be used for the "narrowly contrued" topic, not the "broadly construed" one. The broadly construed topic can't easily be identified by software, and certainly can't by a regex. עוד מישהו Od Mishehu 08:01, 29 May 2015 (UTC)

9. Oppose: prone to wikilawyering, among other problems, especially the use of regular expressions. With "broadly construed", many regular expressions would have to be written to block even a majority of related articles covered by a topic ban. For example, while banning an editor from a very narrow area (like the village pump, broadly constured) requires only one or a few regular expressions (e.g. Wikipedia:.*Village pump.*); topic bans encompassing wide areas, which compose the majority of all topic bans, is difficult (imagine configuring a topic ban from American politics). — Preceding unsigned comment added by Esquivalience (talk • contribs) 17:49, 28 May 2015‎ (UTC)
10. Oppose I understand the idea behind this, but I have serious concerns, especially the idea that a tban represents a choice for the sanctioned user, and this would remove that important indicator. And the incredible potential for wiki-lawyering should a user violate their ban by editing a page that hasn't been explicitly added to the restrictor. Beeblebrox (talk) 02:08, 29 May 2015 (UTC)
11. Oppose, this should be able to be handled by the edit filter. The edit filter can prevent edits based on user and article names. I don't think there are any policies that would support this, however. Nakon 04:30, 29 May 2015 (UTC)

    Edit filters would be an inefficient way to implement this, and indeed would probably fail because of the processing limits imposed, unless new functions were provided that would be the equivalent of this proposal anyway. All the best: Rich Farmbrough, 19:27, 31 May 2015 (UTC).
    

12. Oppose - I'm impressed by the number of admins - who, presumably, would be who this tool is designed to serve - opposing this, so I'm going to monitor the discussion, but for the moment, I will oppose as well. BMK (talk) 04:57, 29 May 2015 (UTC)
13. Oppose as impractical and not conducive to cooperation. Instead of simplifying the amount of work and resources involved in dealing with someone who already creates enough of a nuisance to get banned. It's too easy to cheat and escalate edit warring in other forms. Doczilla _{@SUPERHEROLOGIST} 07:54, 29 May 2015 (UTC)
14. Oppose - Wikipedia needs to start blocking or permanently banning editors that have been engaging in blatantly disruptive behavior. Wikipedia does not need to restrict bad faith editors from editing in a certain area of Wikipedia, only so they can spread their disruptive behavior elsewhere on Wikipedia. Wikipedia's blocks should be both preventative and punitive. Guy1890 (talk) 08:32, 29 May 2015 (UTC)
15. Oppose - If an editor does not voluntarily comply with a community decision to topic ban them they are not fit to be editing at all. Simple as that.Charles (talk) 09:16, 29 May 2015 (UTC)
16. Oppose per all above. Plus, when our trusted mop users (admins) block someone, they mean it. If he's a vandal, I don't find a reason why he should be given concession for editing. Otherwise, topic ban and Arbicom are the best methods we have now and further specific topic ban, IMO, is not so useful and isn't a much needed one. -The Herald (Benison) • ^{the joy of the LORD}_{my strength} 09:59, 29 May 2015 (UTC)
17. Oppose Unnecessarily complex and only a partial solution anyway. The problem is often disruptive editors using shared IP addresses to disrupt randomly. Blocking the IP address for a period is a good way to encourage genuine would-be editors to register. Protecting articles is a simpler solution. Tony Holkham (Talk) 10:56, 29 May 2015 (UTC)
18. Oppose It seems unlikely that the costs and complexity of implementing this solution would be outweighed by the benefits of the contributions that users who repeatedly vandalize or war over particular pages would make to other pages. Also, someone who has shown a tendency to be disruptive and is blocked from one arena is likely to just repeat the behavior in another arena. TheBlinkster (talk) 13:09, 29 May 2015 (UTC)
19. Oppose If an editor can't abide by a topic or article ban, he has a serious attitude problem, and should not be allowed to edit on Wikipedia at all. Also, as the previous editor wrote correctly, if an editor has a problem, they often have it in other areas as well, and a block is the best solution. Debresser (talk) 13:52, 29 May 2015 (UTC)
20. Oppose This seems technically rather difficult (because so much disruptive editing is done by IP hoppers). Besides, editors unable to abide by the terms of (for instance) an ArbCom restriction probably aren't going to be much use to the project anyway. A combination of sensible page protection, escalating blocks and (if necessary) a swinging of the Ban Hammer™ should continue to suffice. -- Scjessey (talk) 14:02, 29 May 2015 (UTC)
21. Oppose, per everyone else, I'm not really seeing how this helps solve the problem of troublesome editors. Some solid, real, examples of problematic editing where this would have been a better solution might help me change my mind. SpinningSpark 15:44, 29 May 2015 (UTC)

    The biggest example I can think of is an edit war. If the user is generally constructive but also edit wars a lot, blocking them from the page, instead of entirely, allows that editor to cool off, but still edit positively somewhere else. If it's clearly a vandal, then a normal block is in order. Another example, let's say an editor, not giving a name here, is probably one of the best editors around, but has trouble keeping his fingers off of TBANed areas. Clearly, blocking that editor from the page itself rather than entirely, will help him and the project. He can still contribute to the project, while being forced to keep his fingers off of the page he's banned from.—^cyberpower_Chat:Online 16:36, 29 May 2015 (UTC)

    @C678: When I said "solid, real, examples" I did not mean made-up fictitious scenarios. Is there a single case you can point to where edit restrictor would have had better results than a topic ban? SpinningSpark 17:29, 29 May 2015 (UTC)

    Edit warring happens all the time. As for the second scenario, I pulled that from another editor currently active on Wikipedia, but refuse to mention his name, for I fear it may cause needless drama.—^cyberpower_Chat:Online 18:40, 29 May 2015 (UTC)

    I know edit warring happens all the time, that's not the issue. In my experience editors who edit war have that in their character and are likely to do it on any subject that they get hot under the collar about. True, many edit warriors concentrate on one topic area, but that is because they obsess on that area and don't edit much else. I refuse to be convinced that edit restrictor has any value until I see real cases of individuals who were blocked after a topic ban while at the same time being model editors in non-disputed areas. I want to examine the edit histories for myself to see if this proposal has any merit. SpinningSpark 22:01, 29 May 2015 (UTC)

22. You get banned. Abide by it, or you are not suitable for wikipedia. An editor who can't control themselves can't be expected to abide by the guidelines in the future. --Fauzan^{✆ talk}_{✉ mail} 16:59, 29 May 2015 (UTC)
23. Oppose Why make work for ourselves? It also imposes yet another new rule new administrators must learn; their job is difficult enough. - Tim1965 (talk) 17:49, 29 May 2015 (UTC)
24. Per Fauzan, the requirement that users have the self-control to avoid the topics they're banned from is a feature, not a bug, of the current system. Mr.Z-man 18:19, 29 May 2015 (UTC)
25. Oppose People who edit Wikipedia are volunteers. If they cannot voluntarily follow rules and rulings, then the problems they create will not be worth the contributions they make. Even if you could get the tool "smart" enough to tell when the person is editing something they shouldn't, having people enforce these blocks is a reminder that this isn't a video game to be "played", but a community to be interacted with. Richard-of-Earth (talk) 19:10, 29 May 2015 (UTC)
26. Oppose Clever idea, but seems completely impractical to me. If people get topic-banned and aren't going to abide by it, then the obvious solution is to block them, not employ some confusing technology. Same with edit warring- forcing people to stop isn't going to change their attitudes to collaborate and discuss. Joseph2302 (talk) 20:22, 29 May 2015 (UTC)
27. Oppose - kind of takes WP:ROPE away from a generally disruptive editor. An editor who is disrupting the project by edit warring or POV pushing, for example, is driving towards exhausting community patience and should get blocked. Restrictions are just a way of slowing this cycle which clears out those who learn and those are are WP:NOTHERE to learn to collaborate. Secondly, as some one else noted above, topic bans / ibans are not finite specific pages that one can't edit. They are broadly construed and this would just invite wikilawyering. On top of that, it also prevents a topic banned editor from reverting blatant vandalism from a page he is 'restricted' at... so we have a clear blockade of WP:IAR. Nope. --lTopGunl (talk) 20:33, 29 May 2015 (UTC)
28. Oppose. More or less guarenteed to cause more problems than it solves. Anything based around regex (which I very much doubt that the majority of admins are sufficiently familiar with to use effectively) will generate false positives, and fail to cover articles it is intended to. A simple list of articles covered by a ban would be more practical, except that topic bans are generally based around topics, not titles. In any case, if the admin is going to be that specific, they can simply inform the contributor of the scope of the ban - as others have said, if a contributor can't comply with a topic ban voluntarily, they shouldn't be editing Wikipedia. AndyTheGrump (talk) 20:50, 29 May 2015 (UTC)
29. Oppose, as this complicates things unnecessarily, and I have a hard time believing that editors who misbehave in one area will simultaneously be productive in another. – voidxor ^{(talk | contrib)} 21:03, 29 May 2015 (UTC)
30. Oppose, because if i get blocked in a page, or anyone gets blocked in a page by example: vandalism, i can make the same thing in other wikis or in another page. by Pancho507, questions?? (talk)
31. Oppose,I really can see the good intentions behind such a proposal but banning only from certain topics only could make it easier to give bans more frequently and very fast ( I know some editors test admins patient big time but I am talking about people who are really just caught in misunderstanding condition ) don't get me wrong for me personally all admins I have been in touch with have been reasonable in giving bans to people and it seems work just fine. ,and then more importantly ..I just don't see how can someone with vandalism editions can be productive in another topics...so what is the point from all of this then ? Adnan (talk) 22:21, 29 May 2015 (UTC)
32. Oppose. Don't put another burden on the shoulders of the admins. They are the next endangered species.Pldx1 (talk) 23:11, 29 May 2015 (UTC)
33. Oppose. At first sight I thought the proposal attractive, but reading the arguments for and against, above, I think the balance of advantage lies in a No vote. Tim riley talk 08:23, 30 May 2015 (UTC)
34. Oppose. When I saw the proposal, my thought was, brilliant - this is a no brainer. But as I read the details, I realised that it wouldn't work, and would create more problems than it solves. If an editor is messing up one page, than applying an individual lock to that page would make sense. But trying to enforce topic bans by automation is not going to work, because already there are arguments as to which articles do come under a topic ban. A ban based on a word string will create problems, and there will be appeal discussions that the block is preventing legitimate editing, as well as notifications that the block is being evaded because XYZ article is in the topic, but doesn't meet the word string; there will likely be frequent attempts to fine tune the word string, increasing the work load on enforcing a topic ban. SilkTork ^{✔Tea time} 08:25, 30 May 2015 (UTC)

    If you think idea itself is brilliant, then you should be supporting this. How this is going to be used will be discussed some other time.—^cyberpower_Chat:Online 15:43, 30 May 2015 (UTC)

35. Too complicated. Also, conduct problems are social problems and require social solutions (e.g., dispute resolution, bans) rather than technical ones. Good regex are hard to write, mediocre regex will produce a lot of false negatives and positives, with all the attendant overhead. I also doubt that regex can be written that would accurately cover what a WP:TBAN entails.  Sandstein  19:32, 30 May 2015 (UTC)
36. Oppose, per all of the above, especially the comments of Richard-of-Earth and Sandstein. In my view, adding yet another bureaucratic rule or regulation or tool is not absolutely necessary in this case, would be largely ineffective, and would contribute to strengthening the (much less important) technocratic/ bureaucratic aspect of the project while eroding and weakening the (much more important) communitarian/ social component of the project. IjonTichy (talk) 20:19, 30 May 2015 (UTC)
37. Cautious oppose. (edit conflict)I understand the reasoning behind wanting such a tool, however, blanket page bands IMHO are dangerous. Individuals, although they may not agree with the majority of editors who actively edit a page, should still be able to suggest edits on article talk pages IMHO. A broken clock is right at least twice a day after all. Also, having this at the admin level IMHO is far to low. Furthermore, as suggested above, the idea of indef bans are draconian. Individual editors should be able to show that they can reform themselves.

    I will say it is an interesting idea, which in some form I might support, but in its present form, I cannot.--RightCowLeftCoast (talk) 20:23, 30 May 2015 (UTC)

38. Oppose. This idea fundamentally misconstrues the social contract between individual editors and the community. Fundamentally, and even before it has any evidence to that effect, the community agrees to assume the editor will edit with good faith. That means editors are responsible for their own behaviour; it's not the community's responsibility to micromanage editors. For an overwhelmingly vast majority of editors, this trust is well placed. For a tiny minority it isn't; we already spend too much of the constructive people's efforts in handholding those who can't or won't behave properly. We never used to do things like topic bans, namespace bans, or interaction bans - if someone had showed that the community's trust in them was misplaced, we asked them to leave. Now we've added various kinds of restrictions - trying desperately to show a little more good faith, even when someone has misbehaved for such a protracted time and to such a significant degree, we give them one last chance. And again, we put the onus of compliance on the individual editor. A topic-banned editor is responsible for policing their own topic ban; it's not the community and not admins' responsibility. Editors are responsible themselves for not edit warring - it's not up to the rest of us to step in and stop them. It's by consciously abiding by those restrictions that a sanctioned editor can show they've changed how they edit. This proposal attempts to impose restrictions by cumbersome technical and administrative means. No software can be written which will make people who can't or won't edit constructively do so. -- Finlay McWalterᚠTalk 20:38, 30 May 2015 (UTC)

    Talking about "trust" and "good faith" is beside the point. Wikipedia is a vast volunteer project, and we can't possibly expect our unpaid editors to behave like a disciplined community of monks or regiment of soldiers—unless we want a very small community or regiment. People will inevitably argue, arguments will inevitably escalate, and if we kick out everyone involved, who will be left to write the encyclopedia? We need people. If someone gets into a skirmish, it doesn't mean they are automatically "untrustworthy" or acting "in bad faith"—it usually just means there are strong feelings and hot tempers involved. Be realistic. Everyking (talk) 21:29, 30 May 2015 (UTC)

39. Oppose Topic bans are intentionally vague- mechanically enforcing it would be entirely too hard. You'd either hit too little, and the users would still edit in that topic area (possibly pleading ignorance because they hadn't been blocked by the software from editing those unblocked but still related pages) or would hit too much, blocking them from pages that are unrelated to the topic area. Additionally, this would stop editors editing pages from which they have valid reasons to edit but might be topic banned from- for instance, for reverting obvious vandalism or removing BLP-violating material. PeterTheFourth has made few or no other edits outside this topic. 03:03, 31 May 2015 (UTC)
40. Strongly Oppose Wikipedia was founded as a democratic forum. Already a two tiered system has developed where certain editors wield more powers than others regarding reverts or determining the “right” content (even if the editor provided academic sources, inline citations and even tried to engage with those editors in good faith). Mechanisms for other editors being able to plead their case are flimsy at best, ignored and ad hoc in getting due attention, and seeking out others may be regarding as “canvassing” which puts them at risk of being blocked and later even banned. There are times when even administrators seem not to give due attention when someone is asking for assistance or even advice in a matter. Hence with such avenues limited in what an editor can do I strongly oppose this proposal that would further curb Wikipedia’s ability to serve as a democratic educative and academic repository that is free for all to use. In the end who is allowed to be the gatekeeper? And what makes some editors/administrators privileged to have that status over others whom they may not personally like (because they may have expertise and credible academic sources on a topic which they dislike) and may block at will based on inadequate rationale. How long will it then take an editor to clear his/her name, if at all? Some thoughts for all to reflect upon.Resnjari (talk) 05:56, 31 May 2015 (UTC)
41. Oppose. Another level of abstraction requiring a mini-language to set up a controlling matrix; which might be appropriate way to guide Curiosity on Mars, but not the right way to trim the wiki-ship. It adds human workload, while scattering bits and chads to the detriment of transparency. Ultimately it is the community that makes intervention work. Ban-lets and block-lets will make enforcement more complicated and less effective — Neonorange (talk) 10:31, 31 May 2015 (UTC)
42. Strongly Oppose All or nothing. A ban is a ban - it is supposed to hurt. If it doesn't hurt, it is not worth imposing. If an editor breaks the rules there should be consequences, none of this "Well, she is only a little bit pregnant". - Kiltpin (talk) 12:12, 31 May 2015 (UTC)
43. Oppose per Sandstein and AtG. GregJackP Boomer! 13:15, 31 May 2015 (UTC)
44. Oppose, as I've never been fond of this idea. I've always said - if they're causing so much trouble that they need to be prevented from editing a page then they should not be wasting our time at all and be blocked entirely. Rjd0060 (talk) 15:42, 31 May 2015 (UTC)
45. Oppose I consider there should be a more effective way to prevent vandalism, but this just went extreme. We already have several tools for fighting vandalism and I consider including a never expiry ban is strict NO-NO. This would certainly give admins more power, but also would cause young editor from refrain editing Wikipedia. Indefinite expiry is No-No. Hence I am opposing this proposal. - abhilashkrishn ^talk 16:30, 31 May 2015 (UTC)
46. Oppose. This would dramatically increase the workload of admins because we'd be playing Whack-a-mole until bad editors are eventually blocked entirely. The whole assumption that editors will go off to be constructive elsewhere when they are disruptive on particular topics seems very naive to me. On top of this it puts an additional technical burden (learning and knowing regex) on the daily tasks of admins and a difficult practical one (reading regexes can be time consuming and difficult). Jason Quinn (talk) 20:28, 31 May 2015 (UTC)
47. Oppose per John Blackburne. This has the potentially to drastically increase the backlog already facing administrators. Spencer^T♦C 22:48, 31 May 2015 (UTC)
48. Oppose: Topic/page bans should be decided by a bigger group of people (e.g. the community by consensus or the arbitration committee), as they are in their current form. More oversight and administration (sysop) time would be required to deal with appeals to the blocks, assuming there would be an appeal process, which would be an absolute necessity. I also assume this would require articles to be further categorized at least at some level (for the topic bans), which would require work and management/upkeep over time. —Godsy^(TALK_CONT) 02:33, 1 June 2015 (UTC)
49. Oppose. The proposed layer of filtering would impose a heavy burden in processing time and it would add too many new ways to game the system. We either trust a user or we don't. Binksternet (talk) 04:06, 1 June 2015 (UTC)
50. Oppose. Seems to be more trouble than it would be worth, adding a lot of work for a small benefit; topic bans seem to be enough to accomplish the goal desired. 331dot (talk) 11:40, 1 June 2015 (UTC)
51. Oppose. Per many of the above. Manxruler (talk) 11:41, 1 June 2015 (UTC)
52. Oppose. Per Kiltpin and others. While a well-meaning idea, it will (IMO) have the consequence of just "shifting" the behaviour or issue elsewhere. Making it harder to track, manage, or address. Guliolopez (talk) 12:38, 1 June 2015 (UTC)
53. Oppose. Individuals who decline to be responsible for their own editing decisions should not be editing, period. Establishing technically-complicated, irritating-to-implement, likely-full-of-holes rubber rooms to protect these individuals from having responsibility for their own conduct isn't a good use of community resources. Lots of excellent additional opposing arguments above. TenOfAllTrades(talk) 13:54, 1 June 2015 (UTC)
54. Oppose. For topic bans, they need to be by definition broad, and so must be human interpreted. If someone is being disruptive in editing at the climate change article (the first discretionary sanctions area that comes to mind), they probably shouldn't be editing An Inconvenient Truth, either. I've seen some ugly regexes in my time, but good luck building one for an area like that, and having neither false positives nor negatives. Rather, we say "You're not allowed to make edits regarding climate change, and if you do so anyway, you'll get blocked." A reasonable person who wants to continue contributing here but just can't quite behave in that particular area would know when an edit is likely to be too close to a topic banned area and stay well away, and an unreasonable person or one whose only intent is to disrupt the area they were banned from will continue dancing on the line and eventually be shown the door. Both of those are useful outcomes, and neither can be implemented in software. Seraphimblade ^{Talk to me} 14:08, 1 June 2015 (UTC)
55. Oppose. I share the enthusiasm of supporters for a technical means to enforce topic bans, but in my opinion the one proposed is impractical. Topics cannot be defined by article titles, and even if effective regex construction was easy (which it isn't) it can't hope to catch anything close to the totality of required titles, and it would also create many false positives. Adding on a hand-crafted list of pages (and perhaps categories) is also not practical, as the articles that would need to be covered could easily number in the thousands. (Go create a list of, say, all pages covered by an "Israel/Palestine, broadly construed" topic ban, and see if you can get close to the whole lot before the Sun gets cold.) Implementing this in the software would require work, and trying to implement it for individual bans would require masses more, and with admin resources apparently quite badly pushed right now I really can't see anyone being prepared to put in the huge effort that would be required. The current system of "You're banned from X, and if you violate that we'll block you" takes no longer to implement than it does to type it, and only a relatively trivial effort to block if necessary. So, nice idea, but in practice it would be a massive waste of effort. Mr Potto (talk) 15:51, 1 June 2015 (UTC)

    To get on to another angle that others have raised, I don't think we should even be wanting to implement this. A big part of the value of a topic ban is that it hopefully makes the banned editor stop and think about what they're doing, and seeing how they behave when given the chance to consciously stay away from topics can make a big difference to how they're viewed when it comes to re-examining their ban. Mr Potto (talk) 15:55, 1 June 2015 (UTC)

56. Oppose as impractical and almost impossible to implement. If someone gets topic banned from editing articles relating to India-Pakistan-Afghanistan the edit restrictions would have to be registered on thousands, if not tens of thousands, of articles. Unless the editing ban was for all articles in a certain category, in which case every single article would have to be catalogued and added to a bunch of new categories. In order to prevent abuse adding and removing articles from those categories would also have to be limited to administrators. Thomas.W ^talk 18:04, 1 June 2015 (UTC)
57. Oppose This is a poor technical solution to a social problem. wctaiwan (talk) 19:06, 1 June 2015 (UTC)
58. Oppose weakly. I can see the legitimate uses of this - technically enforcing a Tban or ArbCom decision (much of which tend to be Tbans - but as has been pointed out above this is too gameable, and is utterly impractical for Tbans in extremely wide topic areas (such as gender and sexuality or the Balkans), as you'd have to include regex for every article and category covered by the Tban. I will also note that the requirement for regex knowledge means that, if this is paired with any other userright, it should be EFM, not admin (Admins do not automatically get the Edit Filter Manager right). If the scope is lessened to enforcing bans on individual pages as opposed to topic areas (perhaps as a subtle means of encouraging SPAs to branch out) I'd be more willing to support, but at present the manpower concerns are a dealbreaker. —Jeremy v^_^v ^Bori! 20:31, 1 June 2015 (UTC)
59. Weak Oppose After reading the proposal, I initially supported it. It seems to be made of common sense, which is usually a good thing. But after reading some of the objections, and noting the responses to some and the lack of response to others (along with my inability to refute them), I have to say that I don't see how this would be useful enough to be worth it. There's just as much potential for errors and abuse as there is for benefit. MjolnirPants Tell me all about it. 20:47, 1 June 2015 (UTC)
60. Strongly Oppose Bad idea. We will be following them around blocking them from one article at a time. The anti vandal work will become even a bigger monster. Also, If someone can't be reasoned with to stop messing up a particular article, what makes you think they will be a saint anywhere else? You say that "banning is not a punishment". You're right, it's an exile off this site, and good riddens to them. Let them start a blog if their opinion is more important than Wikipedia.-Pocketthis (talk) 21:58, 1 June 2015 (UTC)
61. Oppose - Personally I think Blocks do the trick and are more of a "lesson learner", With this IPs/Editors will simply vandalize a page, Get restricted, and then move on to the next page, As for topic bans - If you can't abide by a topic ban then you deserve blocking and or banning plain and simple. –Davey2010^Talk 00:31, 2 June 2015 (UTC)
62. Oppose We have more important tech things to develop. If people cannot follow their topic restrictions than they get blocked. Doc James (talk · contribs · email) 08:38, 2 June 2015 (UTC)
63. Oppose. Far too much of an olive branch to editors whose sole intention is to vandalise articles. Also allows them to string along sysops who could be devoting their time to far more worthy causes than taking care of disruptive editors. Removes the deterrent of a wiki-wide ban for making non-constructive edits. --Half past formerly SUFCboy 12:48, 2 June 2015 (UTC)
64. Oppose Creates more work than it reduces, editors who knowingly violate topic bans should blocked swiftly for the duration of the ban and their edits reverted. The current system is both effective and efficient. Winner 42 Talk to me! 15:47, 2 June 2015 (UTC)
65. Oppose: Someone who refuses to follow a topic-ban voluntarily is someone the project is best rid of. – Smyth\^talk 17:52, 2 June 2015 (UTC)
66. Oppose per above, particularly Finlay McWalter. This is simply a "Block-Lite": if the editor to be sanctioned is not deemed to be deserving of a full block, then that should be the end of it. If they are deserving a block, likewise. Keri (talk) 22:10, 2 June 2015 (UTC)
67. Strong Oppose I see no hard data or analysis, that this is serious problem, needing a solution. Just unverified opinions. I also agree that regexs are not the way to do this, if hard data shows a need. Regexs are a hard to use tool with a very steep learning curve - a burden we should only ask of our Admins, if there is enough benefit, or a better way can not be found. - Lentower (talk) 04:30, 3 June 2015 (UTC)
68. Strongest possible opposition - Technical solutions are never the answer to a social problem. Reaper Eternal (talk) 03:22, 4 June 2015 (UTC)

Discussion (edit restrictor)

• @Cyberpower678: Do you mean follow-up RfCs? Kharkiv07 (T) 13:20, 27 May 2015 (UTC)

  Thank you for bringing that up. I have struck and corrected it in the proposal above.—^cyberpower_Chat:Online 13:47, 27 May 2015 (UTC)

• Topic bans generally cover a range of articles; in some case this range can be quite broad (for example, someone topic-banned from "gender-related articles" will be prohibited from editing hundreds if not thousands of fairly disparate pages, with no easily-identifiable common factors). In addition, it is sometimes appropriate for topic-banned editors to edit some parts of an article but not others if the article covers a sizable topic (the hypothetical "gender-banned" editor could write about the architecture of London, for example, but not about its gender demographics). There is also the issue that topic-banned editors are often prohibited from discussing certain topics, which they can, in theory, do on any talkpage. How does the proposal address these issues? (In theory, I like the idea, but I see these as major stumbling blocks.) Yunshui ^雲_水 14:14, 27 May 2015 (UTC)
  • Most topic bans explicitly will cnclude (but not be restricted to) groups of pages defined by regular expressions; using this feature will be useful in that regard. עוד מישהו Od Mishehu 14:19, 27 May 2015 (UTC)
  • If you have a topic ban that enormous, it will obviously be difficult to manage but as one would block with arbitration enforcement, an admin could block the page instead with the same reason for example.—^cyberpower_Chat:Online 14:43, 27 May 2015 (UTC)

• This is an interesting and well-thought-out idea, but I'm not entirely sure I'm on board with it for the following reasons:

• Seems kind of complicated, unlike most admin tasks which are (don't tell anyone) incredibly simple. Good judgement, not tech skills, are what make an admin. Perhaps this can be rectified with a script or something for non-technically minded admins like myself.
• Topic bans, more often than not, use the phrase "broadly construed" to indicate to the user that they should just stay the hell away from anything that could possibly be a violation for them to edit. For some topic bans this could mean tens of thousands of pages, for example if someone is banned from all BLPs or all articles related to politics in the United States, both very real examples.
• More of a philosophical issue, I feel that topic and interaction bans are a chanve for a user to show that they can voluntarily stop engaging in behavior that the community has deemed disruptive. If they aren't able to do that, they get blocked. This would eliminate that power to choose, to show some real character and maturity and just not do the thing they shouldn't be doing. I'm not sure there is a fix for that concern.

Beeblebrox (talk) 17:02, 27 May 2015 (UTC)

• Maybe I can put your mind at ease. Technologically, if they can't create regex expressions they can use the page lists. Philosophically, my suggestions at pre-emptively blocking users from editing pages is a suggestion. Procedures for when a user should get blocked from page specific editing would get created in a follow up RfC if this passes. Policy could develop to only restrict when a user can't be mature enough to stay away on their own.—^cyberpower_Chat:Online 20:36, 27 May 2015 (UTC)

Perhaps if implemented could it be as simple as that a topic ban a category is used to blanket block all pages within that category? As a side effect this would also solve issues attached to page moves, it still may circumvented but almost everything is able to be circumvented.- McMatter ^(talk)/_(contrib) 03:00, 28 May 2015 (UTC)

• Question: Will the user's page edit block still work in the event that the page is moved to a new title that does not match the regex? (Example: User is banned from editing "Green box", but then the article is moved to "Sulfuric Terminator", which doesn't match the previous title in the least.) Steel1943 (talk) 18:52, 27 May 2015 (UTC)

  I hadn't considered that, but I imagine there is some feasible way to make sure. For example the move log can be checked at the time the rule was put in place to make sure the block isn't being bypassed. Another way, is to have the regex expression run against the pages currently on the database and compile page IDs. Page IDs never change even when the page gets moved. So even when a page gets moved, a person can't edit the page.—^cyberpower_Chat:Online 20:36, 27 May 2015 (UTC)

• Quick note "Regex" stands for regular expression, not reggae expression :-) Unless you're trying to propose a way to block Bob Marley and the Rastafaris from editing :-) Nyttend (talk) 23:56, 27 May 2015 (UTC)
• It seems that the way to do this might be some kind of category block - That is, you can block an editor from editing a page in a particular category or in a category and all sub-categories. This brings the humans back in, so that if a topic ban is complex or unusual, you could create a specific category just for that (something like Category:Gamergate topic banned pages or something) and block the users from the category. On a different note, I agree that this won't solve everything with topic bans, but it will make it easier to enforce them. Oiyarbepsy (talk) 13:03, 28 May 2015 (UTC)

• Another problem (I could have added it to my oppose comment but it seems distinct enough to be worth raising here). As other editors have noted if an editor is not able to abide by a necessary ban then they don't belong here at all, and after further warnings and blocks may find themselves permanently blocked. But this works both ways. If an editor can show they can abide by an ban and continue to contribute to improving the encyclopaedia, without causing problems like those that led to the restriction, then they can show that the ban may no longer be needed and so can be relaxed or lifted. This is far harder to do with an edit restrictor like that described, as you don't know if the editor is being well behaved of their own accord or because the restrictor is making them.--JohnBlackburne^words_deeds 15:46, 28 May 2015 (UTC)
• While I don't support this specific proposal, maybe something similar to restrict editing by namespaces would work: for example, COI accounts couldn't edit articlespace but could raise concerns or suggest imrovements in talk, and so on. Andrew Lenahan - Starblind 17:15, 28 May 2015 (UTC)
• Keep it simple and start with simple blacklistes of pages. If, after initial trials, admins requests that the tool be made more difficult to use, you can introduce regex.--Anders Feder (talk) 05:02, 29 May 2015 (UTC)
• This would put a big burden on those who are familiar with regex and could lead to some surprising outcomes that will require maintenance or even maintenance of maintenance, as shown in this example for {{citation}}. - Sitush (talk) 05:40, 29 May 2015 (UTC)

Seriously, when in the history of mankind have anyone ever thought the thought: "Oh, damn, I wish could block that dude from editing ",? *'*[Ee][Tt] *[Aa][Ll][%.']*$"!"?--Anders Feder (talk) 06:01, 29 May 2015 (UTC)

• When evaluating this poll, it should be noted how admins vote. They are the ones who will be using it. Richard-of-Earth (talk) 19:18, 29 May 2015 (UTC)
• Though I'm generally in favor of this, where there's a regex block functionality there's a Scunthorpe problem: unintentionally blocking superstrings of a banned string. For example, a carelessly coded ban on topics (article titles, categories) having to do with Tory politics could unintentionally block anything mentioning "victory" or "factory". --Thnidu (talk) 03:02, 30 May 2015 (UTC)

  Blocking a problem editor from a few unintended extra pages is not so big a problem. The Scunthorpe problem is a only a real issue when it gets applied to the body of editors in general. SpinningSpark 11:33, 30 May 2015 (UTC)

• Note that I oppose the philosophy behind the proposal, that is, the implementation of t-bans, etc. However, the proposal from a purely technical point of view is worth supporting, I guess it is possible to restructure the proposal then? --Fauzan^{✆ talk}_{✉ mail} 18:59, 30 May 2015 (UTC)
• I'm a regex geek, but I'm ungeeky enough to realize it is a foreign language to most admins. If there is merit to this, I'd say jettison the regex part of it and replace it with something that is easy to understand, namely (1) the namespace restriction mentioned above plus (2) article name prefixes plus (3) category. Every admin should be able to understand these three. YBG (talk) 03:36, 31 May 2015 (UTC)
• Where is this search supposed to be conducted? If you look in titles, your likely to miss something. If it searches topics, the general consensus about the accuracy and reliability of those topics is not very good. If you search the text of the pages themselves, your going to have more than a few false positives. Furthermore, this seems like it could easily overwhelm the administrators very quickly. For example, if userA starts messing with one page and is restricted, and then another, and another, the Administrator that is dealing with userA has already had to restrict userA from numerous pages before deciding on an outright ban, or several other admins have become involved. Granted, this may be useful for normally reliable editors but, I think it would probably be better impose short bans on those, or long term bans on individual articles they just can't seem to leave alone. ZodiakCat (talk) 11:32, 31 May 2015 (UTC)
• Comment - I am not an admin here, but I have maintained access control lists in other applications/places. Maintenance for anything as large as (# of Wikipedia articles) x (# of Wikipedia editors) is a very large, very messy problem. Add to that the complexity of regexes and I foresee lots of both false positives and false negatives. Multiply that by (# of Wikipedia admins) and you get something which becomes, I think, a problem larger than the one you're trying to solve initially. Maybe if someone can design a good ACL management interface which compiles the whole list of article bans into regexes which are implemented "under the hood" it could work, but this is a huge project I don't really see working smoothly the way it's currently described. As a methodology, the best approach is "focus on the problem, not the solution." If you want mw development to solve a problem, it's better to specify the problem rather than proposing solutions. Then come up with a list of requirements for how the solution should work, not how the solution should be implemented. --Unready (talk) 03:16, 1 June 2015 (UTC)

Problem IP editors

• User:King of Hearts raises a good point in his partial support of the proposal. While I cannot see the benefit of this as proposed (with the target of edit warring editors) and have voted against, I could perhaps support a repurposed proposal. IP hopping disruptive editors are frequently a problem for administrators, often living in an IP range that is too wide to rangeblock. Help pages and the Reference Desks are particulary difficult because page protection is not a viable option either, since those pages are widely used by IPs. Blocking a wide IP range would be much more acceptable if it were limited to a small specified set of pages. SpinningSpark 11:33, 30 May 2015 (UTC)

  This proposal proposes the idea itself. Use cases are just examples and are something that would be worked out in follow-up RfC.—^cyberpower_Chat:Online 15:23, 30 May 2015 (UTC)

I was also skeptical about its utility as applied to established editors, but if this works for IP Ranges, it could be really useful. Being able to block a large range, but only for certain articles could be quite effective and immensely reduce the collateral damage. Monty₈₄₅ 15:29, 30 May 2015 (UTC)

No, sorry, we shouldn't just implement any old stuff in the hope it might be useful for something. We should start with a definition of a problem and then construct a solution. Otherwise we could end with something not intended or envisioned by the people who supported it. This proposal explicitly talks about topic bans and most of the discussion has centred around that. I am unconvinced that this would address that problem any better than what we already have, and could conceivably make matters worse by encouraging an edit warring editor to start disrupting a page that was not included in the regex, but was intended to be included in his topic ban. I cannot vote for this proposal in its current form, it would first have to be rewritten entirely and be addressing a problem that really exists, rather than one that I think doesn't. SpinningSpark 16:38, 30 May 2015 (UTC)

Article specific ban?

How about this —something I think most supporters (like me) and most opponents of the proposal could live with : instead of creating the ability to ban users per topic, how about the ability to ban users from particular articles? That way, we are precise. I'll tell you why I support the proposal : people may have passionate views on certain hot-button topics (e.g., religion, politics, etc), and may get carried away when editing on such topics. But the same editors might be very constructive contributors to other articles. Just because someone has produced a POV-packed article on gay marriage, for example, doesn't mean that he or she should be banned from editing an article on volcanoes. That's why I'm in favour of the proposed policy. I notice that some opponents of this change claim that it's too vague. So, how about an article-specific ban for certain editors who are seen to be causing problems with the article? David Cannon (talk) 03:58, 31 May 2015 (UTC)

Well, I proposed something similar to that with "selective blocks", but that didn't gain enough steam among other users to really go anywhere. Dustin (talk) 15:45, 31 May 2015 (UTC)

Editor numbers and recognition

I'd like to propose that more can be done by way of editor recognition as a potential way of encouraging more editor involvement on en Wikipedia. Proposed changes are:

• changing the text at: https://tools.wmflabs.org/xtools/pcount/ to present something like "Contribution statistics" rather than "General statistics" and to gear presentation, as far as may be possible, to be CV/resume/record of achievement friendly.
• expanding or extending the "View history" tab on Wikipedia pages. On the expansion interpretation perhaps this could mean converting it into a drop down menu entitled "Contributions".
  • The first item in the menu could be entitled as something like "Contributor history" or just "Contributors" and be composed as a link to a relevant search via a tool such as : https://tools.wmflabs.org/xtools-articleinfo/ . Again, in this tool, I think that "General statistics" can be swapped to "Contribution statistics" or "Contribution summary" and perhaps the title "Top editors" might be changed to a potentially less competitive "Contributors".
  • The second item on the menu could then perhaps link to the current "View history" content but, perhaps, under a name such as "Edit history".

The issues mentioned here have been on my mind for a while but they were set into motion after seeing a comment regarding "shrinking editor numbers especially on En Wikipedia" via a link at: Wikimedia Foundation Board of Trustees Elections 2015 and after development of ideas during discussion with Doc James.

I think that any form of certification that could be developed may be positive and perhaps this could cover such topics as getting articles to higher rated standards. GregKaye 16:07, 29 May 2015 (UTC)

Yes would be interesting to take [12] and add further measures of contributions.

We have a gadget that does some of this here under "A three-month test" that can be turned on. There is still a lot of work required to get it functioning well enough to leave alpha testing though. Doc James (talk · contribs · email) 11:22, 30 May 2015 (UTC)

Rating template

Hey,

I would like if someone could do a rating template for books such as recipe with 1-5 starts for use in another wiki-media.

thanks, --79.179.121.146 (talk) 18:37, 29 May 2015 (UTC)

There is already a {{rating}} template that produces a number of stars. E.g. {{rating|4|4}} will produce four yellow stars: . Alternatively, it can display a fraction of the maximum number of stars: {{rating|3|5}} → . De728631 (talk) 18:44, 29 May 2015 (UTC)

File renaming

Wikipedia:File names currently lists eight acceptable reasons for renaming a file, and I've proposed that a ninth be added. Your input at Wikipedia talk:File names#Proposal for ninth reason would be helpful. Nyttend (talk) 22:20, 29 May 2015 (UTC)

Moving subpages

When a page is moved, all of its subpages should be automatically moved as well. GeoffreyT2000 (talk) 01:55, 30 May 2015 (UTC)

That is an option available in the admin toolset. I would guess it being restricted has to do with the havoc moving a page with a particularly large number of subpages could cause. Some have several hundred. Monty₈₄₅ 02:55, 30 May 2015 (UTC)

Yes you have to always consider do you want to move sub pages or not, eg moving a talk page to an archive, you don't want to make and archive of an archive. Graeme Bartlett (talk) 12:07, 30 May 2015 (UTC)

Incorrect information

Dear All at Wiki:

Mightn it not be a prudent policy that before a posting is made where factual data might be dubitable, especially in light of changes that the passage of time might bring about, that that posting made available to the 'editing' public prior to that data being posted? Case in point: I opened the page on Nikeri, a town in Suriname, South America. It says there are tensions between Nikeri and neighboring country Guyana. The wiki approved article goes on to say in parenthesis that there has been sporadic fighting between the two neighboring states. There has never been any physical fighting nor talk (intentions) of fighting or any gesture of any disagreement that can be misconstrued as such in the course of the modern histories of the two South American countries.

P. Singh, Guyana

ref: resident of border Guyana-Suriname last 60 years. — Preceding unsigned comment added by Prakash singh ny (talk • contribs) 17:05, 30 May 2015

What you are proposing sounds like pending changes, which we use to allow preview of edits on pages that have been subject to disruption. However, I can't find any mention on Nikeri anywhere so I'm not sure what actual article it is you are talking about. Beeblebrox (talk) 17:19, 30 May 2015 (UTC)

P. Singh appears to be talking about Nickerie District.-gadfium 23:23, 30 May 2015 (UTC)

The sporadic fighting referred to in that article presumably is about the incidents of 1969; as the article says, they were in the south of the country, not in Nickerie District, but this provides background for the scarcity of border crossings. There was an arbitration in 2007 which may have resolved this, but the article's content predates this. See Borders of Suriname#Western border.-gadfium 23:35, 30 May 2015 (UTC)

Counter

Wikipedia Counter
PLEASE permanently ADD A COUNTER TO EACH WIKIPEDIA PAGE now.
Why?
So that the most VIEWED/VISITED PAGES on WIKIPEDIA can be identified and are UPDATED first before less popular pages are.
No point in RUSHING to UPDATE information on a page on WIKIPEDIA that nobody views. Update the most viewed pages first.

Can't help pass onto something that will help.

Thanks

Stuart — Preceding unsigned comment added by 81.131.208.20 (talk) 03:29, 31 May 2015 (UTC)

Page counts are published by the Wikimedia Foundation, and searchable on stats.grok.se. LFaraone 06:03, 31 May 2015 (UTC)

You can also click the "Page view statistics" link on any article's page history, which you can access by clicking "View history" at the top of the article page. ―Mandruss ☎ 06:27, 31 May 2015 (UTC)

Wikipedia is an ongoing project, we are not rushing to get pages complete for a deadline. Also, Wikipedia is maintained by independent editors working within their specific interests. Although there are features to highlight areas that need work, it is not possible to enforce which articles are to be updated first. Periglio (talk) 11:42, 31 May 2015 (UTC)

Diff generator enhancement

Hi, for as long as I can remember, the Wikipedia diff generator for revisions has failed to handle the insertion or removal of paragraph breaks sensibly. If a paragraph break is added or removed, the whole of the paragraph is shown as having changed, like this and/or the diff generator mistakenly tries to compare existing content with an insertion, rather than realising that the insertion has pushed existing content further down, like this. I would like to request that the enhancement to make this work properly is given some impetus and developer effort. I really do think it is about time it was fixed. 109.157.11.203 (talk) 20:40, 31 May 2015 (UTC)

For logged-in users, there is a gadget for an enhanced diff view that does not mark a split paragraph as having changed (only the inserted line break). SiBr₄ (talk) 20:51, 31 May 2015 (UTC)

Great, well let's roll that feature out to all users. 109.157.11.203 (talk) 20:59, 31 May 2015 (UTC)

(OP) Does no one else think this is worth doing?? What are the objections? 86.183.129.51 (talk) 17:32, 5 June 2015 (UTC)

The main thing is that someone has to do the work, which would mean that something else would have to wait. So they prioritize things, and I doubt this would ever make it to the top of the list. Especially considering that User:Cacycle/wikEdDiff is already available, stable, and time-tested. If anyone wants the tool and needs help installing it, such help shouldn't be hard to find. They may click my talk button, for example. ―Mandruss ☎ 17:56, 5 June 2015 (UTC)

Wouldn't stuff like this be extremely right to do by all this techies payed by our contributions of the wealthy WMF instead of rubbish like Flow? They are wading in multi-millions and don't get basics done right, but push unwanted stuff like MV with superprotect against the communities. But hey, it's not as sexy as some brand new stuff, and it's really useful, not just pretends to be, so why bother? Grüße vom Sänger ♫ ^(talk) 07:37, 6 June 2015 (UTC)

More interactivity

My concern is born out of the fact that I am authoring the Dutch Language wikibook, but it may well be of larger interest. I have left similar massages on both meta and mediawiki, but they seem to get ignored. Wikibooks itself is worse: people seem to be so singularly interested in authoring their own book that there is little discourse between them. Learning a language by just reading a written text is a terrible way to acquire language. So, writing a wikibook easily defaults into writing a grammar that occasionally will be consulted by the odd reader at best. In an electronic age that just won't do and is not necessary either. Computers can very well engage learners in a far more interactive way. One good way is sound files. Fortunately uploading sound files has become less cumbersome and bureaucratic at common than it used to be, but putting them on a page is still overly cumbersome. The smallest button I can put on a page seems to be:

[[file:nl-dit.ogg|noicon|20px]]"dit" which yields

• "dit"

With an unnecessary line feed that screws up all tables. In fact collapsible wikitables for some reason only take a smallish number of these links and then things get out of whack, like in the collapsible table called Vocabulary on the right of this page.

Sound files have been treated as a stepchild far too long, I think. Pretty much all Dutch words have a sound file despite of that being the case.

But using sound files is only one possibility of increasing interactivity. I now find myself making practice sets for external websites like Quizlet of Memrise and send our readers there to practice their vocabulary because the wiki system has nothing comparable to offer. For example Dutch past tenses need to be memorized, so I created this set. But why do I have to send our readers / learners away from the wiki system for that? Wouldn't it be more sensible to start thinking of how to make it more interactive? Granted authoring language books is not what most people do here, but I'm sure there are other potential uses of more interactive software. The wiki system has already transformed the concept of an encyclopedia to a much enhanced level, but it could move much beyond that.

Jcwf (talk) 19:57, 1 June 2015 (UTC)

Looks to me like what you want is more appropriate for Wikiversity than for Wikibooks. Ntsimp (talk) 22:43, 1 June 2015 (UTC)

I am really at a loss why you say that. There are many language books at Wikibooks ranging from German, French to Zulu or Punjabi. And no you do not need to go to a university to learn a language. In most countries learning languages starts long before that and continues long after. The US is perhaps -a rather sad- exception to that. Besides whether what I want is hosted at Wikibooks or Wikiversity is rather irrelevant for the point I made, because Wikiversity will run into the same lack of interactivity in the wikisoftware. But yes the poor interactivity of current wiki software is certainly a handicap for whatever is taught at Wikiversity.

Jcwf (talk) 00:46, 2 June 2015 (UTC)

Jcwf, I didn't suggest Wikiversity because of the subject matter of language, but because of the approach you desire. Since you're dissatisfied with what a textbook can offer, but textbooks are what Wikibooks does, it's not the right project for what you want to do. It may well be that Wikiversity can't technically handle this yet, but at least it would be a more appropriate location than Wikibooks. Ntsimp (talk) 17:28, 4 June 2015 (UTC)

I know nothing about Wikiversity and Wikibooks, but from the titles, this is what I would expect:

• Wikibooks sounds like I'd find books, maybe on-demand printing of material that is non interactive and not primarily oriented toward instruction.
• Wikiversity sounds like I'd find an educational institution, i.e., oriented primarily toward instruction and possibly interactive.

For this reason, it seems like you should look toward wikiversity not wikibooks. The title makes it sound like adult tertiary education, I would fully expect to find secondary school courses like history, biology, algebra and geometry. Primary school topics like penmanship and basic arithmetic would seem a bit less likely because of the name 'wikiversity', but I still think I'd be more likely to look for these things at wikiversity than at wikibooks. YBG (talk) 06:22, 2 June 2015 (UTC)

Well, your expectations are wrong. There is a lot more language text books at wikibooks than at wikiversity. The only one of any real importance is one in Breton. The wikiversity info for Portuguese and German e.g. refer to the wikibook version.

But as I said this is also totally irrelevant to my question and concern of interactivity. Because neither Wikiversity nor Wikibooks nor any other site in the wimimedia universe has that. Jcwf (talk) 06:50, 2 June 2015 (UTC)

Fair enough. My comment was about what I would expect, not about what actually exists. And your point about irrelevance is well taken; I had not thoroughly digested all of your previous reply. You are right in saying that lack of interactivity is not project-specific, but rather just as true at WP as at WV or WB. About all I can come up with is demonstrated over at my talk page. But if you are looking for others to join with you in advocating for more interactivity, it seems to me you'd find more support over at wikiversity than you found at wikibooks. Interactivity provides more benefit to courseware designers than to book authors or encyclopedia contributors. And that interactivity should be helpful in all topic areas, not just in language learning, so the relative lack of language materials at WV shouldn't deter you from trying over there. But even in the best imaginable outcome, it would probably take a long time for significant interactive features to get implemented. Best wishes! YBG (talk) 08:04, 2 June 2015 (UTC)

Have you checked out Template:Listen and template:multi-listen start? Rmhermen (talk) 16:18, 2 June 2015 (UTC)

Yes, Rmhermen, I have. In dismay. They remind me of this old and cruel joke about the GDR priding itself on having biggest transitors and computer chips... Sorry to get sassy, but they are perfect example of how outdated, quaint and obsolete wikimedia software really is. Both of those templates are GINORMOUS. If you have a hunderd words on a page that you want the reader to be able to hear they are totally, absolutely useless.

Actually they are bigger than my ginormous statement. Far bigger, bulkier an unwieldier. Real dinosaurs. Jcwf (talk) 19:56, 2 June 2015 (UTC)

How 'bout {{audio}} then? Isn't that exactly what you need? And if it's still too unwieldy, is there anything preventing you from modifying that template slightly so it only contains the parts needed for your purposes?—Ëzhiki (Igels Hérissonovich Ïzhakoff-Amursky) • (yo?); June 5, 2015; 14:44 (UTC)

• @Ntsimp:If you look above you'll see a possible solution - little javascript apps that can be embedded in an article, now in use at Spanish wikipedia. Something like this might be what you need? Oiyarbepsy (talk) 20:03, 2 June 2015 (UTC)
• Two suggestions for you: Please add this to m:Community Tech project ideas. Also, look at the number eins (one) at wikivoyage:German phrasebook#Numbers, to see if that sort of idea might work for you. (It was mostly lifted from Wiktionary, and I don't know if it works in every browser. You'll get the best results from clicking on the pseudophoneticization, not the speaker icon.) Whatamidoing (WMF) (talk) 13:59, 3 June 2015 (UTC)

Can we get a bot to check the Internet Archive for dead link solutions?

Moved from Wikipedia:Village pump (technical) § Can we get a bot to check the Internet Archive for dead link solutions?

 – ―Mandruss ☎ 08:15, 2 June 2015 (UTC)

Rather than merely tag dead links as being dead, can we have a bot see if the dead link was archived at the Internet Archive around the time when the link was added to the Wikipedia article, and either change the dead link to point to that Internet Archive link (which would presumably be a working representation of the page before it was a dead link), or at least make a report on the talk page proposing the fix? bd2412 T 04:05, 2 June 2015 (UTC)

On a related point: If the archive is added to the citation, I think it should be added as |archive-url= with |deadurl=yes. This makes the citation title link to the archive while preserving the original link as "original" in the citation. Thus the original link can be easily checked for possible resurrection, which does happen sometimes. ―Mandruss ☎ 05:03, 2 June 2015 (UTC)

• Support this is an excellent idea. "repairing" dead links have become a common spamming technique. If we had a bot add archive links from internet archives that would solve a lot of problems. Do we have someone interested in building such a bot? We could also added an internet archive for the links that are not dead just incase they become so. We would use for the live ones |deadurl=no Doc James (talk · contribs · email) 07:59, 2 June 2015 (UTC)
• Problem: sometimes the archived page at Internet Archive is not valid—they really do have to be checked by human eyes. Curly Turkey ¡gobble! 11:05, 2 June 2015 (UTC)
  • True, IA has significant reliability problems. Many times an archive version is unusable but another version of the same page, archived a few hours or days earlier or later, works fine. And a bot likely wouldn't be able to tell the difference. But is a bad archive version any worse than a dead link? Either way, a human needs to try to find an archive version that works. ―Mandruss ☎ 11:55, 2 June 2015 (UTC)
    • I completely agree that human eyes are needed for confirmation, but it would be helpful to have a bot find and suggest the link. If a page has a lot of dead links, a bot report of some kind will also save the trouble of searching the Internet Archive for the ones that don't exist there at all. bd2412 T 12:12, 2 June 2015 (UTC)

Another issue is the (rather uncommon) case that the cited webpage changes over time and the archived version chosen by the bot may not be the correct version to support the content it references. A good way to address technical problems would be for the bot to leave a message on the article's talk page, much like bots do on user talk pages. The message would say something like "On [date], [bot name] repaired [number] of references by inserting a link to archived versions of these dead links. The archived webpages should be verified to determine if the archived webpage displays properly and supports the content it references." That's just an idea for what the text should say, it needs to be worded better. The message would include a link to edit diff and could even display the links to the added archived webpages to make verification easier. The message template could also include a parameter for the verifying editor to adjust to indicate verification, similar to how Template:Request edit includes a parameter indicating that the requested edit has been made. A parameter "archivebot=[date]" could be added to citation templates to indicate that the archive link was added by a bot. I believe the benefit of repairing dead links (should check both IA and other web archiving sites) with a bot outweigh the drawback that a small percentage of archived webpages won't display properly or may not link to the right version of a webpage. AHeneen (talk) 13:10, 2 June 2015 (UTC)

I came across an archived webpage at IA yesterday that first displays a message that cookies are disabled and need to be enabled to use the website (the page is in French) and in Firefox the tab has a spinning green circle indicating the page is loading. The first screen has a box to check "OK" and if you click "OK" it goes to the archived version of the webpage and the green spinning circle disappears (again, using Firefox). This is something that a bot might reject as a bad archived webpage. This supports using a bot that lets editors review the archived webpages, rather than automatically rejecting them. AHeneen (talk) 18:49, 5 June 2015 (UTC)

• Support I think this is much better than just tagging the dead link. See comments in the threaded discussion above. AHeneen (talk) 13:10, 2 June 2015 (UTC)
• Conditional Support ... the condition being that it is not a fully automated process. Thanks for the idea S a g a C i t y (talk) 15:03, 2 June 2015 (UTC)
• Script it The internet archive sometimes archives 404 not found pages (many websites make fake 404 pages that look like real webpages to bots), so this won't do. A script that shows a human the proposed link and gives them a yes or no choice and changes the link if the human clicks yes is just the ticket. Oiyarbepsy (talk) 20:07, 2 June 2015 (UTC)
  • That would be ideal, yes. bd2412 T 20:18, 2 June 2015 (UTC)
• Support as a semi-automatic script with user-check. GermanJoe (talk) 21:14, 2 June 2015 (UTC)
• Comment (for Firefox users) In the meantime, this little add-on on the Firefox Addon page adds a "Check for Internet archives" function to contextmenus of links and to the toolbar (not my invention, just mentioning it). Not a huge improvement, but still quite helpful. GermanJoe (talk) 20:29, 2 June 2015 (UTC)
• Support I think this is an essential service we need. We all know we have dead links scattered throughout wikipedia. WP does not control the status of external sites, but we rely on that information for our sources. Essentially when a dead link is detected, it becomes the sequence for removing content, sometimes selectively for POV purposes. Used in such malicious circumstances, the offending editor must first fail to search for the archive link and then deliberately remove content. An automated process will eliminate the question and the opportunity. Once a link to a website is posted within wikipedia, frequently it will cause the archive spider to find an otherwise unknown link and start the archiving process, so all WP needs is a means to link back to that archive if the originating site goes down and the proper information is retained in perpetuity. The knowledge is not lost. "Knowledge is good." Trackinfo (talk) 20:55, 2 June 2015 (UTC)
• Support Excellent idea and an efficient way to manage dead links. Winner 42 Talk to me! 20:57, 2 June 2015 (UTC)
• Support The issue of the bot retrieving non-pertinent archive urls could be well dealt with by chucking in a template field that says the archive url has not yet been verified. Even if we say that the bot has only 50% accuracy in getting a good archive url, this would be a vast improvement from the current arrangement, at the cost of a slight amount of disappointment over there being two bad urls rather than one. I also support the idea of a scripted tool which would show users a non-verified link and allow them confirm, replace or remove the bot-provided url. SFB 21:02, 2 June 2015 (UTC)
• Support: This would also help reduce the incidence of a form of "article rot", in which dead links are used as excuses to pepper articles with inline or block citation dispute tags, or simply delete material as "unsourced" when it takes about as much time to take these unhelpful actions as it does to just go to archive.org and find a URL for the source that still works. Might as well just have a bot do it, if it can be done that way.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  19:55, 4 June 2015 (UTC)
• Support: Having worked on repairing dead links, having a way of harvesting the archived versions of an URL seems useful. Maybe have such a bot add a marker (like {{Archived URL available}} with the URL) that can be reviewed instead of outright replacing links, too - in case the archived URL is not suitable. Jo-Jo Eumerus (talk) 11:11, 5 June 2015 (UTC)
  • I would say that an "unsuitable" link is no worse than a "dead" link. I would prefer outright replacing the link and putting a "needs review" tag on it. bd2412 T 14:41, 5 June 2015 (UTC)
    • That also works, I'd say. Jo-Jo Eumerus (talk) 20:23, 5 June 2015 (UTC)

Galleries - Who needs them?

Apologies if this has been discussed before but I propose that, given the existence of Commons and Wikilinks, there is no need for any wikipedia article to include a gallery. The danger being that inexperienced readers may believe that the gallery contains all images relating to the subject that the project holds when this is far from the case. Comments please S a g a C i t y (talk) 15:08, 2 June 2015 (UTC)

• Visual arts articles in particular benefit greatly from good use of galleries. You're not going to protect articles from newbies' shitty use of galleries any more than you'll protect them from newbies' shitty prose. The answer is to fix it, not to ban it. Curly Turkey ¡gobble! 20:20, 2 June 2015 (UTC)
  • Well gobbled. We have link templates to point readers to the relevant collection of images on Commons, so even if an article contains a gallery, chances are high that there will be a note "Wikimedia Commons has media related to <subject>" at the bottom of the page. And if inexperienced readers don't get such hints, that's no reason at all to penalise the rest by abolishing galleries. De728631 (talk) 20:30, 2 June 2015 (UTC)
  • I agree 100%. Curated galleries are a benefit to some articles. Galleries should not be banned because of poor implementations on some articles. AHeneen (talk) 01:43, 6 June 2015 (UTC)
• As a long-term user of Wikipedia, I understand the problems with galleries of indiscriminate images tacked on to the end of articles, as I've seen plenty and they can be bad. But used well, a gallery can definitely improve an article. The visual arts example given by Curly Turkey is a good one, and for example, the Pablo Picasso article would be poorer without a gallery of some of his works. But galleries can also be used very well in general subjects. See the article section Roman Britain#Roman rule is established, where a simple two-image gallery is used to good effect (and there's another just below). So no, I think it would be a bad move to get rid of galleries. Mr Potto (talk) 09:07, 3 June 2015 (UTC)
  • In the Roman Britain example would actually be better off using Template:Multiple image instead of a gallery. Using the template would eliminate the excessive gray border of those images and allow a single caption. AHeneen (talk) 01:43, 6 June 2015 (UTC)
• I concur with Mr Potto. The problem of galleries of indiscriminate visual clutter is the same as, e.g., the problem of someone dwelling on excessive detail about a biography subject's childhood, or any other form of over-inclusion: It's a WP:RELEVANCE matter of content determination and adjustment for discussion at a particular article's talk page, not indicative of a site-wide problem requiring sweeping change.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  19:52, 4 June 2015 (UTC)

RfC: Allow "Edit in Wikidata" links for templates using data from Wikidata

Please comment on the RfC/discussion at Wikipedia talk:Wikidata#Edit_in_Wikidata_links. Thank you - Evad37 [talk] 01:32, 3 June 2015 (UTC)

Proposal on including sister-project links in nav templates

FYI

 – Pointer to relevant discussion elsewhere.

There's an open proposal discussion, that could use more eyes and minds, at Wikipedia talk:Categories, lists, and navigation templates#The inclusion of 'Commons', 'Wikiquote', and 'Wikisource' on appropriate templates.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  02:36, 3 June 2015 (UTC)

@SMcCandlish: This is now an RFC. --Rob Sinden (talk) 12:08, 4 June 2015 (UTC)

Non-neutral commentary does not belong here; this is just a neutral notice that the discussion exists and may be of interests to VPPRO regulars.

The question, as you can see from the above open discussion notice, is really about limited sister projects, "Wikiquote" and "Wikisource", but Robsinden wants to make it about all sister projects (the RFC by Sadads was mistaken in its scope, and Sadads asked us to modify it. I changed it to reflect the original question minus 'Commons' (which was removed after a legit concern), Robsinden brought that into an edit war, and now I can't revert a third time, leaving the inaccurate RFC question visible for the time being until Sadads can come by. Please take the original question, which pertains only to 'Wikiquote' and 'Wikisource texts' into your consideration and not adding the entire sister project universe to templates, which, although I presented the original question, even I would oppose. Thanks. Randy Kryn 12:04, 4 June 2015 (UTC) This is not the forum for this, this is nothing more than a notification of discussion. Stop being childish. If you have a problem with the question as it was asked in the original RFC, bring it up at Wikipedia talk:Categories, lists, and navigation templates#Comments and other opinions/approaches, rather than edit the question. --Rob Sinden (talk) 12:26, 4 June 2015 (UTC)

Sockpuppet Investigations (Random SPI checks is not always fishing)

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

---

https://en.wikipedia.org/wiki/Wikipedia:Sockpuppet_investigations/OccultZone

I am shocked to find that User:AmritasyaPutra turned out to be a sockpuppet of OccultZone. User:AmritasyaPutra's account was opened on 10 August 2008 and he became (pending changes reviewer, rollbacker). Few months ago I saw an old user User:Darkness Shines blocked as a sockpuppet of Mark Nutley(which was renamed as Darkness shines 2). Now Darkness Shines is unblocked.

SPI cases are filed when there is some suspicious behaviour by two accounts, or when three/four new accounts support some old blocked account. Then SPI clerk asks for CU check, if he is provided with sufficient evidence . SPI cases without evidence is considered personal attack.

I suggest:

"There must be compulsory CU check on a user when he/she gets some extra rights as rollback rights, pending changes review rights,Auotopatroller, Template editor rights, Mass messaging rights along with Administrator rights. And Users should not feel bad about it. In airport all has to face metal detector test even if they are not terrorists. So the editors must be ready to face compulsory CU checks to get those extra rights mentioned here in WP:UAL".

On a different note, in most SPI cases only one clerk is working on all cases. There must some other clerks also. In most pages I see Vanjagenie's comment. What happened to other SPI clerks? --Cosmic  Emperor  18:33, 3 June 2015 (UTC)

Those who are typing oppose, oppose: can you give a solution to stop these clever sockmasters. CU is not for fishing. But how to stop socks from becoming powerful editors like User:AmritasyaPutra and Darkness Shines? People think that there will be too much burden on Check Users. Most Check Users don't work in SPI. Those Check Users who work in SPI, i don't want to increase their burden. But those who have Check User rights , still don't perform CU checks in SPI, i want them to do this.--Cosmic  Emperor  01:40, 4 June 2015 (UTC)

• Support concept: although CU is not for fishing, I really support the concept of this (if it would amend the scope of CU for this specific purpose and not put too much burden on the CUs) having been on the "wrong side" of both the cases in question that revealed such users to be sock puppets of their older, disruptive, accounts. I'll like to support an agreeable version of this which ensures all loopholes are covered both to protect the user being CU'd and to enforce such a concept. It wouldn't make sense to CU on a single rollback right but maybe for sysop or say when a user gets 3-4 such rights which give them tools that experienced editors are trusted with, it might be a good idea to ensure they are not socking. --lTopGunl (talk) 18:45, 3 June 2015 (UTC)
• Oppose as per CU is not for fishing. Moving from social to technological methods of behaviour enforcement is the path of arms races. Stuartyeates (talk) 20:30, 3 June 2015 (UTC)
• Oppose (edit conflict)A:overreaching use of CU and B:some users legitimatly use multiple accounts without disclosure but within policy and don't won't them disclosed at rfp.

EoRdE6^{(Come Talk to Me!)} 20:34, 3 June 2015 (UTC)

I agree with you. In that case the Check User who will perform the test must be E-Mailed about those legit socks.--Cosmic  Emperor  01:50, 4 June 2015 (UTC)

• The harm to the community from a sockpuppet receiving access to most of those rights is minimal, and as such I think automatic checkuser fishing would be unjustified. For candidates for admin, template editor, edit filter manager, and Arbcom, I could see supporting a check. But then the problem becomes if everyone knew they would get checkusered as a result of candidacy, it becomes trivial for any serious sockmaster to make sure they waited until they were outside the window for technical evidence. So at most you catch sloppy socks trying to get permissions. All in all, not sure its worth it. If you really wanted to stop it, you would need some type of random checks of existing holders of the rights your concerned about. Monty₈₄₅ 22:42, 3 June 2015 (UTC)
• oppose. Those metal detectors everyone goes through at airports? Security theater which does little to stop determined terrorists, and anyway entirely irrelevant. No, CU is not for fishing. People granted additional rights are already subjected to heightened examination of their editing, before and after gaining such rights. How much so varies greatly by the rights. If you think e.g. admins become admins to easily then take it up at RfA. But CU is not the way to do it.--JohnBlackburne^words_deeds 22:52, 3 June 2015 (UTC)
• To answer your last question first, two of our most active SPI clerks became CheckUsers in March, so they've been focusing more on the other side of cases. As for the proposal, I must oppose. I don't think, for most userrights, that such checks are necessary or even allowed by policy. Also per the preceding opposes, particularly Monty845 and JohnBlackburne. ​—DoRD (talk)​ 02:05, 4 June 2015 (UTC) Edit: Also, the OccultZone case was a complex investigation. I have doubts that any of the accounts would have been caught in a cursory "rights check". ​—DoRD (talk)​ 02:13, 4 June 2015 (UTC)
• Oppose. CheckUser should not be used unless there is sufficient evidence to suggest that a user is abusing multiple accounts. Furthermore, since CheckUser can reveal a user's location, using it without prior evidence of abuse (obtaining a new right is obviously not abuse) would be baseless invasion of privacy. --Biblioworm 02:08, 4 June 2015 (UTC)
• Not going to happen. This is a flat-out violation of the privacy policy; "is applying for a permission above autoconfirmed" doesn't come close to the required criteria for doing a check. Risker (talk) 02:44, 4 June 2015 (UTC)

@Risker: The privacy policy has a catchall provision that says information may be shared with the permission of the user. While it seems pretty clear this proposal isn't going anywhere, if a process was structured such that consent to having a checkuser performed was explicitly given at the time of application for the user right, I think it would be permissible under the privacy policy. There also doesn't seem to be anything in Meta Checkuser Policy that would prohibit it either. Our local checkuser policy is much stricter than the baseline Meta policy, which I think is probably a good thing, but it does mean we do have flexibility if we as a community want it. Monty₈₄₅ 04:56, 4 June 2015 (UTC)

Sorry, no. It is not possible to require users to surrender their privacy, not to mention the privacy of every other user who might show up in an otherwise unjustified check, so they can gain access to what is, at the end of the day, a rather inoffensive and harmless tool. There is no other user permission anywhere in the entire WMF sphere that requires the user submit themselves to a checkuser in order to be considered for the permission, simply because there is no justification for it. (Notwithstanding, checkusers and oversighters do need to supply personal information as required by the privacy policy. That's not the same as running a CU - which also compromises the privacy of others.) Risker (talk) 05:08, 4 June 2015 (UTC)

• Oppose - per Risker, this is a pretty heavy privacy policy violation. Also violating a lot of other people's privacy.--Jorm (talk) 02:47, 4 June 2015 (UTC)
• Oppose I see no need to stop anything not being used deceptively or disruptively. If there is no direct suspicion of misbehavior, we should not be using exceptional investigative tools to find them. The OP's premise, that hidden alternate accounts present a scourge that needs rooting out, is not a position I support; at least not that we must sacrifice core values of due process and privacy to do so. --Jayron32 02:52, 4 June 2015 (UTC)
• Not happening. First, we don't go on fishing expeditions. Secondly, what do you draw the line? - Mailer Diablo 06:17, 4 June 2015 (UTC)
• Oppose and will not be done as a violation of the privacy policy. Reaper Eternal (talk) 02:57, 4 June 2015 (UTC)
• Oppose per the others who have noted that it is contrary to policy.--Bbb23 (talk) 04:20, 4 June 2015 (UTC)

Some Administrator must close this discussion, after DoRD's statement about OccultZone's case.Cosmic  Emperor  04:51, 4 June 2015 (UTC)

• Comment. I am bemused by the claims that checkuser violates the privacy policy - if so, why do we have it? The existing threshold for making one is ostensibly a community lynch mob, really an admin deciding whether or not he is curious. The process needs more transparency - there have been stories about people being checkusered over three year old accounts. I don't feel like there's any real protection now, so the shocked invocations of privacy seem to be 'protesting too much'. That said, I don't see petty little rights like reviewing and rollbacking as being that important, nor should they be. Checkusering the admins routinely might be more interesting, but I'd rather see the whole capability uninstalled. Wnt (talk) 12:21, 4 June 2015 (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.

Scrub SourceForge links?

Proposal to scrub all SourceForge links or mark them with some sort of exclamation icon due to their recent unscrupulous behavior. See: http://www.gimp.org/ http://www.infoworld.com/article/2929732/open-source-software/sourceforge-commits-reputational-suicide.html http://arstechnica.com/information-technology/2015/06/black-mirror-sourceforge-has-now-siezed-nmap-audit-tool-project/ — Preceding unsigned comment added by Abdd0e77 (talk • contribs) 21:36, 3 June 2015 (UTC)

Our role is not to punish websites for their behavior. How would "scrubbing" all the links be in line with WP:EL? VQuakr (talk) 22:24, 3 June 2015 (UTC)

I didn't look into it enough to see if it is still an issue, (saw something saying they've stopped) but the links seemed to have been violating WP:ELNO by tricking users into installing adware and other unwanted software instead of just what they came there for. With many of the SourceForge links on Wikipedia being to actual project sites and simply going to SourceForge not being an issue, it would be better to just include a warning instead of removing them if any action is required. PHANTOMTECH (talk) 23:15, 3 June 2015 (UTC)

ELNO prohibits links to malware, not adware. VQuakr (talk) 23:25, 3 June 2015 (UTC)

Open an issue at MediaWiki_talk:Spam-blacklist#Proposed_additions and discuss it there; the editors there will have experience of such situations. Stuartyeates (talk) 23:28, 3 June 2015 (UTC)

Adware is a form of malware. 'Malware' is an umbrella term used to refer to a variety of forms of hostile or intrusive software, including computer viruses, worms, trojan horses, ransomware, spyware, adware, scareware, and other malicious programs. (emphasis added) The spam blacklist doesn't seem appropriate because links to the site do have some validity, since some open source projects with articles use it as their only distribution method, but a cross-post to WP:VPT might not be a bad idea for getting more input. @Abdd0e77: Do you know if there is any evidence SourceForge is continuing to replace installers or have there been no cases since they've said they stopped? PHANTOMTECH (talk) 23:48, 3 June 2015 (UTC)

How I read the situation is that it only affects the download of source code and/or software, and not for the general web sites themselves. I don't think this would be an ELNO aspect, as these are valid project sites that would be linked to from articles on the open source projects, but I do agree that having a template that one can wrap links it to caution them about downloads possibly containing adware from the site. --MASEM (t) 23:56, 3 June 2015 (UTC)

There is a strong case made here that any SourceForge link is now suspect, since the official projects in general seem to be preferring other distributors. I think it would be useful for someone to go through by hand and see how many of these links can be changed to something else. However, if push comes to shove, it is still likely better to link to a creepy commercial website than to link to nothing. Warnings are still an option... Wnt (talk) 12:16, 4 June 2015 (UTC)

Lists of the links that we are talking about: [13] [14] [15]. I have some serious concern here as well, but then again, download.cnet.com is only slightly better than sf.net right now. Yes, there is a lot of bad stuff out there, but it's also a bit the geocities of the 2000s open source development world, and in that regard, there is still a lot of valid links in our articles I think... (perhaps archive.org versions instead?) —TheDJ (talk • contribs) 15:38, 4 June 2015 (UTC)