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, 212

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)

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)

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)

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)

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)

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)

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

RfC: Should Persondata template be deprecated and methodically removed from articles?

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

Consensus is to deprecate and remove. There is a strong numerical majority in favour, and while good faith objections have been raised, there appear to be adequate responses and/or practicable workarounds for these. One theme that does come out is the disjoint between Wikidata and Wikipedia, perhaps a separate RfC might address the form of a feature request to manage this, which is probably the most widely expressed concern. Guy (Help!) 13:46, 26 May 2015 (UTC)

---

Background (Persondata)

From Wikipedia:Persondata: "Persondata is a special set of metadata that can and should be added to biographical articles only. It consists of standardized data fields with basic information about the person (name, short description, birth and death days, and places of birth and death) that, unlike conventional Wikipedia content, can be extracted automatically and processed by cataloging tools and then used for a variety of purposes, such as providing advanced search capabilities, statistical analysis, automated categorization, and birthday lists."

The question of whether to delete {{Persondata}} has been visited in the past, the motivation being that Wikidata (and infoboxes) now provides better functionality, making Persondata obsolete. The main concern from the last RfC was that it was too soon, and that the info from Persondata should be copied to Wikidata before any deleting should be considered. Since then, a TfD ruled the template deprecated, but as there were only 4 users participating (compared with the ~50 users in the RfC) no action was put in motion to stop adding new templates.

In the meantime, PLbot has now copied all of |SHORT DESCRIPTION= to Wikidata (link). In various conversations, all other fields of Persondata have been argued to be too unreliable for any meaningful use. The bot request for copying the data to Wikidata is closed (archived), and Wikidata isn't interested in the remaining Persondata fields.

Faults of Persondata

• Problems with name sorting, formatting guidelines not always followed, and there are also names like "Otto von Bismarck" or "Martin Luther King Jr" which are often mislabeled. (link, link)
• Problems with date formatting, also dates before a certain time are unreliable as Gregorian and Julian formats are indistinguishable (link). Also, dates rarely have references (link)
• Problems with location disambiguation; formatting and when there is no link markup, or too much link markup (link, link, link)
• It is not used by anyone that I know of (Periglio is now using Wikidata)
• User:Periglio/Wikidata: Analysis of accuracy of Persondata vs Wikidata.
• User:Pigsonthewing/Persondata: explains some additional problems with persondata

Reasons to keep Persondata

• If anyone is currently using it.
• If the parameters other than short description can be shown to be useful and worth keeping.
• If any future use cannot be replaced by Wikidata.

Rough plan

I have compiled a rough plan of how Persondata will be migrated to Wikidata and eventually deleted (A more detailed version can be found here). This is my own plan, and doesn't necessarily have to be the way we do it. I am only mentioning it here so I don't give the impression that this RfC is to delete Persondata immediately. Please discuss below if you have any suggestions.

1. Transfer |SHORT DESCRIPTION= across to Wikidata.  Done
2. Stop bots from automatically creating new Persondata templates.
3. Notify users in relevant projects of deprecation.
4. Transfer any new data to Wikidata, then remove methodically.
5. Close the template and relevant pages when ready.

Questions:

1. Is anyone still using Persondata?
   • Are any Wikidata bots still extracting Persondata for new/revised articles?
2. Can Persondata be considered deprecated and no longer added to articles?
3. Is short description the only useful parameter?
4. Main Question: Should the {{Persondata}} template be methodically removed from articles and no longer be used?

Proposed by Msmarmalade (talk) 07:23, 6 May 2015 (UTC)

Discussion (Persondata)

• Have a comment?
• The big problem with WikiData is that its "impossible" to edit and watch changes to articles (from enwiki). E.g. all {{authority control}} data has been moved to WikiData (and deleted from the articles) - how do we suppose editors to figure out how to change any wrong data? I think the same will happend with persondata if its transcluded from WikiData. The question is; - is anybody using persondata to anything? — Preceding unsigned comment added by Christian75 (talk • contribs) 18:15, 6 May 2015 (UTC)
  • Comment In Preferences > Recent changes > Advanced Options, there's a checkbox for "Show Wikidata edits by default in recent changes and watchlist". Based on your comment, I guess it's not checked by default. I've been using it for a long time; so much so I forget when I even turned it on. Basically it shows when any change is made to the corresponding Wikidata entry for any articles in your watchlist. Jason Quinn (talk) 09:24, 6 May 2015 (UTC)
    • I am aware of that, but I rarely use my watchlist. I use diffs. Christian75 (talk) 09:30, 6 May 2015 (UTC)
      • Wikidata has diffs. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 09:50, 6 May 2015 (UTC)
        • So you suggest first to check changes (diffs) on enwiki, and then check changes to WikiData (if I realise that the article transclude anything from Wikidata at all)? Christian75 (talk) 10:12, 6 May 2015 (UTC)
          • I suggested nothing. If you want a suggestion: use watchlists. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:20, 6 May 2015 (UTC)
            • Thats not a solution if the change happend a few days ago. My oppion is. Do not use WikiData (on Enwiki) until its ready and templates on enwiki which transclude data from wikidata should have an "Edit button" with a direct link to the entry on WikiData. Christian75 (talk) 11:06, 6 May 2015 (UTC)
              • This is not a discussion of whether or not to use Wikidata on this Wikipedia. It is a discussion about whether or not to continue storing data in {{Persondata}}. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:23, 6 May 2015 (UTC)
                • I think it is. Your own argument to delete it is "and all of its functionality, and much more, is available using far better technologies, via Wikidata (and infoboxes)". If the alternative is WikiData; the discussion should be about using data from Wikidata too. Christian75 (talk) 14:40, 6 May 2015 (UTC)
                  • This would only be true if we were talking about using [use of content from Wikidata on this Wikipedia] to replace [use of content from Persondata on this Wikipedia]. Since the set of articles in which the latter applies appears to be zero (do feel free to correct me), it's irrelevant to the discussion at hand. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:53, 6 May 2015 (UTC)
                  • A previous RfC came up with the objection that there was no suitable alternative for someone wanting to use the data from Persondata. This has been addressed by the community in getting Wikidata updated with the biographical fields. My own research confirms that the WD database is now just as reliable as Persondata. The question we are trying to resolve with this RfC is whether there is still a need to keep Persondata. The future plans for Wikidata are not relevant as they no longer involve Persondata. Periglio (talk) 22:22, 6 May 2015 (UTC)
                    • Did your own research take into account Wikidata date errors make it unstable and unreliable? — {{U|Technical 13}} (e • t • c) 02:35, 7 May 2015 (UTC)
                      • That's bunkum, as explained elsewhere on this page. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:55, 7 May 2015 (UTC)
• Question: Given that a recent discussion came to a consensus that wikidata was not a reliable source, where is quality control for this data going to be, if it's not in the Persondata additions in wikipedia? The last time I checked, wikidata had no policy equivalent to WP:BLP, so this is a serious issue. Stuartyeates (talk) 08:20, 6 May 2015 (UTC)
  • Wikipedia is also "Not a reliable source". As was noted on the discussion you cite, neither is Wikidata supposed to be. Where is the quality control for persondata? WP:BLP is based on WMF policy, which applies to Wikidata, just like every other project. Please re-read the comments there by User:Snipre, User:TomT0m, User:Izno, User:Kaldari, User:Maximilianklein, User:filceolaire, User:Giftzwerg 88, all of whom correctly attempted to address your misapprehensions about how Wikidata works. Regardless, none of your arguments support keeping persondata. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:18, 6 May 2015 (UTC)
• I don't use persondata actively, but I do use it for search. I have personally put a lot of aliases in the aliases field and these enable findability. Where the alternate comes from other links we have the redirects, but if you delete persondata you will lose these alternate spellings. I do think the accuracy of the dates and places is better on Wikidata, so I don't mind deleting that. As far as editing goes, maybe we should wait until Wikipedians feel more comfortable updating Wikidata. As a Wikidatan it's hard for me to say, but the fact there are so few templates transcluding information from Wikidata is an indication to me that most Wikipedians still feel uncomfortable editing there for some reason. Jane (talk) 08:31, 6 May 2015 (UTC)
  • A better way to make aliases searchable is to create redirects from them (or to add them to or disambiguation pages). Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 09:53, 6 May 2015 (UTC)
    • Yes, but in some cases, such as Gaetano de Rosa, this name is already in use by another article, and making a disambig for an alternate spelling seems a bit extreme. Also, having the redirects on the page also helps for people reaching the page from other projects. Jane (talk) 11:24, 7 May 2015 (UTC)
• Question: as much data is duplicated between the persondata and an infobox on the same page - do we know how many pages contain conflicting datapoints (as in day of birth differences between infobox and persondata, or missing in one but not in the other), and how much of the infobox is getting updated when needed (as in e.g. the subject passed away) and how many editors do take the effort to immediately also update the persondata? I would expect that with the broad implementation of infoboxes that that data is, generally, more reliable than what is in the persondata box (people see the infobox is wrong, and update that). --Dirk Beetstra ^{T C} 08:44, 6 May 2015 (UTC)
  • Not sure anyone knows but I feel that we would know better if we merged the data to WD and had a tool make the comparison and flag the differences for correction. A whole lot easier to do that at WD than here. — billinghurst sDrewth 10:42, 6 May 2015 (UTC)
    • In answer to these questions, death dates are updated within seconds of the death announcement! Persondata is always missed by these morbid people, but will usually be updated within a few days. My validation work has flagged up hundreds of examples where the Persondata is out of sync with the rest of the page. 95% of the time, it is Persondata that has an old or vandalised date. The bulk of birth and death dates have been copied to WD and again I am finding 100's of differences. More often than not, WD has picked up a dodgy date from Persondata. I have been trying to get the bot people to use the more reliable age templates, but thats another story. Periglio (talk) 21:52, 6 May 2015 (UTC)
  • I'd much rather see persondata merged into infoboxes to go at the bottom of the code (possibly creating what appears to be redundant parameters) so the data is still available without having to dig through dozens or thousands of history revisions and this would also allow the addition of vandal detection as the vandals might change the visible data in the infobox but are likely to leave the persondata alone (especially if it is a long infobox and that information is at the opposite end where they are unlikely to see it). This would allow for the infobox templates to detect an inconsistency and add the page to a category for a human to check for data accuracy. — {{U|Technical 13}} (e • t • c) 02:35, 7 May 2015 (UTC)
• I frequently use and make use of persondata. In some cases, I have found it contains details of dates and places or birth and death which do not appear in the text of an article but can prove extremely useful in researching further details of a biography. I also use the facility to record the variations in spelling (especially from non-English-language originals) of names and aliases/pen names/married names, etc. of an individual. In many cases, these variants are too cumbersome for inclusion in extenso in the article (or in a box). I am also rather concerned that Wikidata has not picked up essential data from earlier articles. While my recently created Raquel Lebrón is indeed in Wikidata with a date of birth, Carl Nielsen which has been in existence for years and now covers 37 languages has no date of birth in Wikidata! Can the bots not be upgraded to pick up such details from the articles themselves (since it has been decided the dates in persondata are unreliable)? And if the info is missing, can any editor simply enter it directly on Wikidata? I also think there should be a more straightforward way of entering Wikidata from any article rather than clinking on "edit" under languages (if the article is in more than one language). Maybe there could simply be a prompt "Wikidata" (leading to Create or Edit) in the LH margin?--Ipigott (talk) 09:34, 6 May 2015 (UTC)
  • Please can you provide examples of pages (current or past) with dates in persondata, that are not displayed in the article? The only case where I can envisage this happening is where an unsourced or date has been removed, perhaps from a BLP, but overlooked in persondata - another reason why persondata is harmful. BTW, Nielsen's DoB was added to Wikidata- by a bot - on 27 April: [4]. That was likely picked up from the infobox in another-language Wikipedia; the lack of an infobox on our article makes it near impossible for a bot to extract such data with any certainty. Also, articles already have a "Wikidata item" link in the left-hand navigation (default desktop view) Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 09:56, 6 May 2015 (UTC)
    • On Nielsen, I am amazed that a bot cannot be developed to pick up dates presented in a standard fashion at the beginning of the lead in several language versions, e.g. "Carl August Nielsen (Danish: [kʰɑːl ˈnelsn̩]; 9 June 1865 – 3 October 1931)...". I think the persondata on places and dates of birth is frequently added by editors translating an article from another language, indeed I do it myself. I nearly always start a biography by writing an introduction of one or two lines, a couple of pertinent references (one usually containing place and date of birth), the key categories and the persondata). One of the problems in regard to place of birth is that this should not be included in the lead but rather in a biography section. This means that when there are time constraints and the article is still at stub status, the only reference to place of birth and death might well be in persondata. See this for example. There are hundreds more from me and I often find other editors follow a similar approach -- although I cannot give you chapter and verse. It would be extremely difficult to find examples in retrospect as when I find them I add the missing details to the text of the article. All I can say is that if one has the date and place of birth, it is then much easier to search for other pertinent information about the person in question. This helps greatly when there are several notable people with the same (or similar) name.--Ipigott (talk) 13:04, 6 May 2015 (UTC)
      • So, no examples of pages (current or past) with dates in persondata, that are not displayed in the article? The claimed existence of a very tiny number of instances of an uncited date or place of birth, in persondata, but not in the body of an article, should not stand in the way of the proposed deprecation. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:18, 6 May 2015 (UTC)
        • My validation work has highlighted many examples of living people with a death date lurking in Persondata. The point is that being invisible it is not subject to scrutiny by the average reader, they do not have citations and without additional research can not be treated as a reliable fact. Periglio (talk) 21:18, 6 May 2015 (UTC)
• Question: is there a reason why history functionality could not in principal present an integrated timeline view of all changes to a page, transclusions, linked data, etc.? This was the problem with {{cite pmid}} and the like: it breaks wp:V when linked metadata is no longer valid. LeadSongDog come howl! 13:44, 6 May 2015 (UTC)
• Questions on multilingual issues. Do current plans also cover the German Personendaten, the French Wikipédia:Métadonnées personne, and all the other language equivalents? I can see nothing about the matter here or here. I would suggest the Germans and French in particular should be invited to take part in the current discussion. After all, Wikidata is a multilingual facility. Is biographical data from other languages being copied over to Wikidata on the same basis as data from EN articles? If so, can one trace exactly where it has come from (in case it needs to be updated or corrected)? It would be useful for those of us who frequently write biographies to gain a better understanding of the mechanisms involved. We could then no doubt contribute more usefully to Wikidata. It seems to me to be potentially an extremely useful tool for Wikimedia's multilingual environment. If the other items of data could be backed by editing facilities as efficient as those available to interwiki links, we could handle them very easily when creating new artilces. But we need improved guidelines and better editing facilities to ensure wider coverage and improved reliability.--Ipigott (talk) 14:37, 6 May 2015 (UTC)
  • Probably - but that's irrelevant to the discussion of what we do on this Wikipedia. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:47, 6 May 2015 (UTC)

  • Do current plans also cover [...] the other language equivalents? They could, but that's irrelevant to establishing consensus on this wiki. I don't think I disagree that they might be invited or otherwise.

    Is biographical data from other languages being copied over to Wikidata on the same basis as data from EN articles? If so, can one trace exactly where it has come from (in case it needs to be updated or corrected)? Yes and yes. --Izno (talk) 19:17, 6 May 2015 (UTC)

  • In the french language Wikipedia, the Persondata is obsolete since 3 years. The template has been deleted on 2012-07-31. Visite fortuitement prolongée (talk) 20:29, 6 May 2015 (UTC)
  • The plans discussed in this RfC do NOT include Personendaten. From my understanding, each wiki governs itself, and as such Persondata is not directly linked to Personendaten (or Métadonnées personne). If you think that this discussion will be of interest to them, you're welcome to post a notice over there—Msmarmalade (talk) 03:20, 7 May 2015 (UTC)
• As to whether or not anyone is using {{persondata}}, I occasionally use its presence as a mark of the article being about a person, if I'm doing a category scan (this tool) among stubs - while scanning the deep contrent of Category:People stubs is possible, it's both too big to use. עוד מישהו Od Mishehu 20:23, 6 May 2015 (UTC)
  • We have categories (and indeed, the Wikiproject Biography banner on talk pages) that serve that purpose. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:27, 6 May 2015 (UTC)
  • When you say it's "too big to use", what do you mean? Why wouldn't you want as many results as possible?—Msmarmalade (talk) 02:59, 7 May 2015 (UTC)
    • I mean that the scan would frequently never show up; even if it did, it would take it much longer than it should - all because it would need to scan through dozens (probably even hundreds) of categories. And we're talking about a need to exclude articles about people, not include them. And if I also want to exclude certain stub tags, a template on the talk page isn't helpful. What I would need is a single category or template which would be on trhe article page. עוד מישהו Od Mishehu 04:37, 7 May 2015 (UTC)
• I just want to quickly introduce myself - I used the Persondata template for a personal "celebrity birthday" project. This expanded into a Wikipedia data validation project, and recently converted to Wikidata. My work also confirmed that the bulk of the data in the Persondata templates is now available on Wikidata. i.e. Deleting Persondata is no longer a loss to the Wikidata project. I have spent many hours looking into why discrepancies occur. My conclusion is that both "databases" (Persondata and Wikidata) have accuracy problems, a lot of this is due to dates rarely being referenced in articles, but that is outside the scope of this RfC. I would like to see Wikidata being incorporated within Wikipedia infoboxes which would help with Wikidatas reliabilty problems. Personally, I would like to see Persondata disappear if only to free up resources to push Wikidata forward. Periglio (talk) 20:58, 6 May 2015 (UTC)
• Having now read through the comments so far, I think most people are being sidetracked by Wikidata. The issue under discussion is whether the Persondata template is useful or not. The template has its faults but nevertheless it is a database of biographical information. The big question is "Are there people actually making use of it?". This aim of this RfC is to find out if the effort keeping it maintained is worthwhile. Wikidata provides an alternative database and has potential to provide much more to Wikipedia but that is outside the scope of this RfC. Periglio (talk) 21:39, 6 May 2015 (UTC)
• Question: Some users have shown interest in using infoboxes (or perhaps categories) for the data fields that Wikidata will not take. I am all for this idea, and for mandating infoboxes for BLP articles) (and actually, I mentioned this in the last RfC, but I've just been so caught up in the Wikidata front that I forgot). So, Firstly, Is it ok if I add this to my plan above (I don't know RfC editing protocol) just as something like "(edit: and/or infoboxes?)". Next, do we need separate community consensus to instigate this? Just because Wikidata considers the remaining fields unreliable, doesn't mean that Wikipedia necessarily has to discard them (However, the arguments I linked above may still be relevant). Also there were some potential issues mentioned in the last RfC about infoboxes when there is not enough information to fill them. For example an infobox with just the name is ugly and pointless (But then if Persondata only has the name then it can just be deleted) —Msmarmalade (talk) 02:05, 7 May 2015 (UTC)
  • Strong objection I certainly do not think infoboxes should become mandatory as part of this proposal. The use/need/nature of infoboxes for biographies merits a separate proposal.--Ipigott (talk) 07:47, 7 May 2015 (UTC)
    • @Ipigott: I think for the sake of this RfC, I'm only really interested in the suggestion of migrating excess Persondata to infoboxes (and creating infoboxes where appropriate). Mandating infoboxes on every BIO page would indeed need consensus and would be a huge task to try and implement (@EoRdE6: May feel differently.). If we don't worry about mandating infoboxes, would you be satisfied with moving excess Persondata to infoboxes?—Msmarmalade (talk) 13:53, 7 May 2015 (UTC)
      • I just think we need to have readily updatable machine readable data on these pages for bots and the like. I'm not saying it would be quick, or necessarily retroactive, but maybe just a mandate for new biographical articles with two sections or more, or when an article is expanded to be more than two sections. And the removal of persondata would def be a slow and taxing process, starting with stopping adding it (and stopping tools like AfC helper and AWB from adding it) and then moving and verifying the data has been moved somewhere. I just don't think a bot can really check this data either. EoRdE6^{(Come Talk to Me!)} 14:20, 7 May 2015 (UTC)

Sorry, I cannot agree with EoRdE6. In the case of biographies of artists and others from the cultural sector, there are often good reasons why a carefully chosen image rather than an info box with a photo of the individual is presented at the top of the article. There have been extensive (and often heated) discussions on the matter and as far as I know it has still not been resolved. If an infobox already exists in a biography, I would not object to details from Persondata being added but new boxes should not be created or substituted without consensus on the article in question. I would far prefer to see the data transferred to Wikidata but there seems to be general agreement that it is not reliable enough. I have been informed that we cannot take into account Persondata from other languages but I would have thought that cross-language checks would probably be an excellent way of checking the validity of the data for inclusion in Wikidata. And why has no one suggested checking against all the items in authority control which has been added to a large number of biographies? This too could be automated.--Ipigott (talk) 15:06, 7 May 2015 (UTC)

• Question If we should decide to get rid of Persondata. What kind of time scale between a successful proposal for deletion and the actual deletion would people think is reasonable? In other words, should there be a grace period and, if so, for how long? Jason Quinn (talk) 12:08, 7 May 2015 (UTC)
  • Seventeen seconds? Seriously: as soon as possible, unless anyone advances evidence of an exmaple of a problem that will be caused by delaying. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:31, 7 May 2015 (UTC)
• Question: Currently persondata can be put on redirects (think the individual members of Category:Duos). My understanding is that currently practise limits infoboxes to article space (at least I don't recall seeing an infobox on a redirect). Is this going to change? Stuartyeates (talk) 21:12, 7 May 2015 (UTC)

Support (Persondata methodical removal)

1. Support I would prefer to see the data of birth, death and a short description in an infobox, open to all, not hidden, and connected to the rest of Wikipedia with the links to periods and places. Look at Handel or Beethoven for an example. --Gerda Arendt (talk) 08:24, 6 May 2015 (UTC)
2. Support removing persondata completely, with moving missing data into the infobox. The latter is more visible, and avoids duplication. What WikiData does (besides WikiDataDrowning) is beyond this - I guess it would be good that they have the data .. but as it is unchecked, 'invisible' (our watchlists do not get alerted if s.o. changes it there) I don't have a real opinion on that problem.

   Note: some data, like synonyms etc., does not necessarily be visible, but it would be good to be parsed like in the persondata - that functionality can of course be duplicated by our infoboxes, and the data can then be moved from the persondata box to the infobox. --Dirk Beetstra ^{T C} 08:48, 6 May 2015 (UTC)

   • Watchlist updates for Wikidata changes are already available, as described above. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 09:45, 6 May 2015 (UTC)

   • @Pigsonthewing: - but that would require to check both your local watchlist, and the WikiData watchlist. I do the former, not the latter. If only WikiData would have thought before inserting terafields of data how to have each datapoint verified and referenced ... --Dirk Beetstra ^{T C} 10:44, 6 May 2015 (UTC)

   • No it would not, as Jason Quinn explains near the top of the "discussion" section, above. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:48, 6 May 2015 (UTC)

3. Support removal. Persondata is harmful, as I outline at User:Pigsonthewing/Persondata; and all of its functionality, and much more, is available using far better technologies, via Wikidata (and infoboxes). Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 09:45, 6 May 2015 (UTC)
4. Support using persondata templates is a complete anachronism. It is completely single wiki focused, manual, and doesn't follow a smart idea of keep it simple. For those concerned, ensure that we have a process to ensure that the data is there prior to removal. — billinghurst sDrewth 10:20, 6 May 2015 (UTC)
5. Cautious support for removal of PERSONDATA. I opposed the previous RfC on the basis that it was premature - i.e. Wikidata wasn't ready/up for the task. However, as we can "hide" any data that cannot be migrated, it seems to me a this would be "a good thing".  Philg88 ^♦talk 10:24, 6 May 2015 (UTC)
6. Support. Persondata adds nothing to the encyclopaedia (it's not even visible when reading an article). Metadata like this belongs on Wikidata, and now that the necessary data have been copied across it's time to delete Persondata. WaggersTALK 12:01, 6 May 2015 (UTC)
7. Support for the same reason I gave last time; it is just more edit window clutter. SpinningSpark 12:40, 6 May 2015 (UTC)
8. Support moving this stuff where it belongs, and keeping anything deemed to be useful. — Martin (MSGJ · talk) 12:44, 6 May 2015 (UTC)
9. Cautious support: I believe it is time to enact step 2: Stop bots from automatically creating new Persondata templates. When bots add the template, it creates more article entries into those hidden categories (...missing short description), which fools such as I feel impelled to fill when I am doing other tasks. The other obvious question that I have is: isn't there still some issue with infoboxes being in / out of certain articles? What of those articles declared, (wherever those laws are), to NOT have one under penalty of whatever? (Curious minds...) Fylbecatulous talk
10. Support I believe it is time to remove this. Wikidata covers it better. -DJSasso (talk) 14:07, 6 May 2015 (UTC)
11. Support, per my comment on the last RfC. It's separating plumbing from porcelain. Protonk (talk) 14:09, 6 May 2015 (UTC)

    Also, looking at Pigsonthewing's essay, I can't help but agree. I've never edited persondata, so I've probably inadvertently introduced discrepancies without even realizing it. I didn't even know what it was until the last RfC. Protonk (talk) 12:23, 7 May 2015 (UTC)

12. Support removal. The Persondata template appears to have very very limited usage and I have not seen use cases (including that of Ipigott below) where the benefits outweigh the problems of keeping it. The template's attempt to add semantic structure to data is outside the proper scope of the encyclopedia and now that Wikidata exists, such efforts have a proper venue. The non-reader-facing nature of the data has always been problematic and just adds an extra place for data to be out-of-sync. As far as the encyclopedia should be concerned, the persondata information is best presented in infoboxes or incorporated into the article text, or as redirects in the case of aliases. The non-reader-facing aspect also appears to have impacted its reliability too, as per Periglio's conclusions. After all, we cannot collaborate and fix data we cannot see. I'd also like to inject that the purpose of the persondata template is non-obvious and adds an additional barrier of intimidation and confusion for new editors. If Wikipedia were a garden, persondata would be a weed and we should uproot it. On the whole I am unworried about the loss of data, which I think would be minor, if the template were simply removed: this data is not irrecoverable, and any lost data would be re-added eventually and in a better, more appropriate way. Adding information is what we, as Wikipedians, normally do and what we are best at. Jason Quinn (talk) 14:14, 6 May 2015 (UTC)
13. Support A WikiData based methodology will simply produce more accurate information. Onward! --j⚛e decker^talk 15:12, 6 May 2015 (UTC)
14. Support with the provision that a user should verify that any useful information from the Persondata template has been transwikied to Wikidata before removing the template. —Scott5114↗ [EXACT CHANGE ONLY] 18:42, 6 May 2015 (UTC)
15. Strong support. Ironholds (talk) 18:45, 6 May 2015 (UTC)
16. Support, for all the reasons above. Alakzi (talk) 18:54, 6 May 2015 (UTC)
17. Support - I've never seen the point but anyway WikiData covers it all. –Davey2010^Talk 19:51, 6 May 2015 (UTC)
18. Support - I think there is very little chance that any of the remaining data will be ported to Wikidata. At this point we should move on and not have overlapping workflows for adding the same information. Kaldari (talk) 20:02, 6 May 2015 (UTC)
19. Support - Wikidata has extracted all it can from the template. I was still using it for data validation purposes but finding that the incorrect date was in Persondata 95% of the time. I would rather everyones efforts be put into gettng Wikidata up to speed, not keeping Persondata maintained. Periglio (talk) 20:39, 6 May 2015 (UTC)
20. Support as functionality is better served by other mechanisms, (categories, infobox and wikidata). It adds extra work to add and maintain. It would have less reliable data, for example I am one of the people that will add dubious data from unreliable references to persondata because it does not need any reference. However it would be good to get a copy of what was there before it is removed by bots and overzealous editors. But it would not be truly lost as it will still be in history, so perhaps the scan prior to culling can record the revision that contained persondata. (especially if there are inconsistencies). Graeme Bartlett (talk) 23:32, 6 May 2015 (UTC)
21. Support. Wikidata seems to be as good or better in every significant way, and we shouldn't keep a redundant template around unnecessarily. —Granger (talk · contribs) 00:14, 7 May 2015 (UTC)
22. Support as above. filceolaire (talk) 01:42, 7 May 2015 (UTC)
23. Support but, from a layman's perspective, it looks like we urgently need to make access and editing of Wikidata values more intuitive and easier for non-tech editors, and develop clear guidelines (in common language using short words) about when and how to use Wikidata values in Wikipedia. With all the current buzz about Wikidata, I see little available information, how Wikipedia-content and Wikidata-values are supposed to be handled together in daily practice. GermanJoe (talk) 03:20, 7 May 2015 (UTC)
24. Support this appears to be outdated, redundant, and a maintenance burden. Opabinia regalis (talk) 03:44, 7 May 2015 (UTC)
25. Support no need for it, confusing to the average editor. Dougweller (talk) 09:05, 7 May 2015 (UTC)
26. Support per JasonQuinn's reasoning. APerson (talk!) 13:20, 7 May 2015 (UTC)
27. Support removing persondata completely; data that WikiData wants can go there, and our infoboxes can cover the full set of data currently in PersonData.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  00:45, 8 May 2015 (UTC)
28. Even before Wikidata, I always viewed PersonData as a solution in search of a problem. Resolute 20:20, 8 May 2015 (UTC)
29. Support. Never liked it to begin with. Hidden from readers, unstructured data input, no real uses for the data... Renata (talk) 13:31, 10 May 2015 (UTC)
30. Support. Chase me ladies, I'm the Cavalry (Message me) 14:42, 11 May 2015 (UTC)
31. Support - As infoboxes have all what is needed, persondata is redundant.- Cwobeel (talk) 00:50, 16 May 2015 (UTC)
32. Support - Time to move on. It is a shame to remove something into which editors have put time and effort but that is the price of progress. Wikidata has better structured data and removing persondata allows us to focus our efforts on further improving Wikidata, e.g. to make its functionality and data more visible to editors and readers.--Wolbo (talk) 21:05, 21 May 2015 (UTC)
33. Support per Jason Quinn. — Mr. Stradivarius ^{♪ talk ♪} 14:43, 22 May 2015 (UTC)
34. Support Per various reasons above. I much prefer WikiData, anyway. Prefall 15:03, 22 May 2015 (UTC)
35. Support. It's the first time I support this. I think we are now ready to do that step. Infoboxes are better standardised and large amounts of info have already started being stored in Wikidata. We can ensure a that a bot stores the ALTERNATIVE NAMES in Wikidata too if this is not done already. -- Magioladitis (talk) 10:39, 24 May 2015 (UTC)

Oppose (Persondata methodical removal)

1. Strong Oppose: Provides all kinds of information that wiki articles just don't usually provide: namely: all variants/spellings/iterations of name/aliases/pseudonymns/stage names/birth name/nickname/common name/full name/various married names, etc. Persondata harms no one, and benefits many. I use it and benefit from it. Softlavender (talk) 08:49, 6 May 2015 (UTC)
   • Wikidata provides all that functionality; better. How do you use it? With what tools? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:07, 6 May 2015 (UTC)
   • Moreover, most of the data, and certainly ALL of the functionality can be performed by infoboxes (including non-displaying fields containing all variants/spellings/iterations of name/aliases/pseudonymns/stage names/birth name/nickname/common name/full name/various married names, etc.). Having them all in one place overrules the necessity to duplicate (some fields are commonly found in both the infobox and in the persondata). — Preceding unsigned comment added by Beetstra (talk • contribs) 11:41, 6 May 2015‎
   • Wikidata has the necessary fields for that data (for example pseudonym; official name; nickname; birth name). However in terms of migrating |ALTERNATIVE NAMES= to Wikidata, this information would need to be manually transferred, since the formatting in Persondata is not suitable for a bot to process. @Beetstra: would it be possible for a bot to transfer this information into infoboxes? Or is it a similar situation with formatting? —Msmarmalade (talk) 02:56, 7 May 2015 (UTC)
     • Should be possible, but formatting may indeed be a problem. I am sure that there are many cases where the information is formatted differently between specific infoboxes and persondata. --Dirk Beetstra ^{T C} 04:16, 7 May 2015 (UTC)
2. Oppose: On the basis of my comments above, I think this is still premature.--Ipigott (talk) 09:36, 6 May 2015 (UTC)

   @Ipigott: Under what circumstances would you consider it no longer premature? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:00, 6 May 2015 (UTC)

   Once we have found a more reliable way of transferring basic information on date and place of birth and death and variants on the individual's name over to Wikidata. I do not agree that boxes should be the only reliable source. Maybe tools could be developed to allow editors to add this information to Wikidata, where possible with references, while an article is being created or edited. I have looked at the Wikidata records on several noted individuals and find them sadly lacking.--Ipigott (talk) 12:39, 6 May 2015 (UTC)

   But that has already been tried, and it has been found to be impossible to do so without introducing an unacceptable number of errors; for the reasons stated (and in discussion linked to) elsewhere on this page. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:47, 6 May 2015 (UTC)

3. Oppose if my understanding is correct. Wikidata has no interest in supporting all the fields and they all hold value, so I can't support deprecation and migration to Wikidata. I would probably support deprecation and merging with infoboxes however, if that was to be put on the table as an alternate proposal. I'd happily embed persondata with infoboxes and then go through and bot edit to move the persondata parameters into the infoboxes. — {{U|Technical 13}} (e • t • c) 10:23, 6 May 2015 (UTC)
   • @Technical 13: Which Persondata fields do you believe are not supported in Wikidata? It seems to me that they all are. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:29, 6 May 2015 (UTC)
     • Andy, I'm only going by this proposal, which declares at the very top PLbot has now copied all of |SHORT DESCRIPTION= to Wikidata (link). In various conversations, all other fields of Persondata have been argued to be too unreliable for any meaningful use. (bolding mine) — {{U|Technical 13}} (e • t • c) 10:38, 6 May 2015 (UTC)
       • Hmm .. so the argument is now that since all these fields are too unreliable for any meaningful use, we have to keep 'm all here? --Dirk Beetstra ^{T C} 10:41, 6 May 2015 (UTC)
         • The reliability of the fields is a matter of opinion and debate I suppose, and I don't agree with you that the data we've had in persondata since its inception for name, date of birth, date of death, place of birth, place of death, etc is any less reliable than short description. — {{U|Technical 13}} (e • t • c) 10:54, 6 May 2015 (UTC)
           • No, it is not a mere matter of opinion; the problems have been demonstrated, with examples. People have tried, and been unable to resolve the issues. If you have some solution that's not already failed, by all means please state it now. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:49, 6 May 2015 (UTC)
       • That means we're not copying the Persondata data over; the fields ("keys") themselves are supported by Wikidata, and have been mostly filled in using infobox metadata, if my understanding is correct. Alakzi (talk) 10:43, 6 May 2015 (UTC)
         • I'd have no problem with that if it made sense. If that is the case, why is the mentioned field different? What makes people think that infobox data is any more reliable than persondata info? I've often found BLPs where trolls have modified the infoboxes trying to push their POV and left the sourced data in persondata alone because they didn't know what it was or didn't see it at the bottom of the article. I'd say infobox data is probably less reliable for these things that don't often change (my date of birth hasn't changed in decades and I don't expect it to). — {{U|Technical 13}} (e • t • c) 10:54, 6 May 2015 (UTC)
           • Infobox data is more visible, so more likely to be corrected, if bogus, than hidden persondata. It is also more easily disambiguated, because it is more often linked (e.g. [[Paris, Texas|Paris]]). Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:57, 6 May 2015 (UTC)
           • This is contrary to the experience of the bot operator commenting at Wikidata. Alakzi (talk) 11:01, 6 May 2015 (UTC)
       • The unreliability of the data in Persondata (as previously explained - feel free to refute that explanation; and explain how you would import such data into Wikidata; or even to infoboxes) does not mean that the data fields are not supported (and populated by other means) in Wikdiata. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:51, 6 May 2015 (UTC)
         • Wikipedia:Village_pump_(technical)#Wikidata_date_errors indicates that persondata is likely still more reliable than Wikidata. So, still going to have to go with "Wikidata is not stable and ready yet". — {{U|Technical 13}} (e • t • c) 00:47, 7 May 2015 (UTC)
           • You've linked to a new conversation with no replies, which provides 3 examples of errors (with suspicion of more). While potential coding error is a concern, I find this to be a very weak argument compared to Periglio's analysis and the various arguments linked above.—Msmarmalade (talk) 02:31, 7 May 2015 (UTC)
             • ...and none of those errors relates to people, so persondata is no solution. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 07:33, 7 May 2015 (UTC)
           • The reliability (accuracy) of the data and reliability (availability) of the service are two completely different things. (For God's sake, why are people using Module:Wikidata in mainspace? Whoever's said that it's ready for primetime?) Persondata cannot even be used in this manner, so what point are you trying to make? Alakzi (talk) 02:49, 7 May 2015 (UTC)
             • The argument I think Technical 13 is making is that if Wikidata's dates are less accurate than Persondata's dates, then we can't justify outright deleting Persondata dates. —Msmarmalade (talk) 02:54, 7 May 2015 (UTC)
               • That's not the argument he was making just now. Alakzi (talk) 03:13, 7 May 2015 (UTC)
     • There are over a million Persondata templates and the information from these has been migrated to Wikidata. Wikidata no longer has a use for the template. The issue here is whether the Persondata template can be deprecated and removed from enwiki. I see your point about using Persondata to create infoboxes and this could be discussed further if we get to the stage of talking about how we deprecate. Periglio (talk) 22:52, 6 May 2015 (UTC)
4. Oppose for now. Until consensus can be reached to add infoboxes to all articles it should be kept. More importantly, I ask what harm it is causing? And lastly Persondata may/is relied upon by outside things such as Google Knowledge Graph and other private uses, and I can't see the benefit of removing their sources. I of course support the use of Wikidata, but until all persondata can be found in the infobox, and through consensus they are mandated, I don't support removing this harmless feature. EoRdE6^{(Come Talk to Me!)} 18:54, 6 May 2015 (UTC)
   • The main harm is additional maintenance. The data can end up being in 4 places, in the main body text of the article, in the infobox, in persondata and in wikidata. This would just be the start of reducing that down to three places. Further work could be done on infoboxes to take the data from wikidata (if no parameters were supplied), which would then reduce that to two places. -- WOSlinker (talk) 21:45, 6 May 2015 (UTC)
   • As I keep mentioning, I have worked on data validation. I can confirm that hundreds of articles have conflicting dates and the hidden fields in Persondata are normally the ones that are to blame. Periglio (talk) 22:28, 6 May 2015 (UTC)
   • I've added a comment regarding infoboxes in the discussion section above. Can you provide evidence that Google Knowledge graph uses Persondata? I had just assumed they use infobox. Also can you please specify some examples of "other private uses"? —Msmarmalade (talk) 03:34, 7 May 2015 (UTC)
   • FYI Knowledge Graph uses Wikidata now for this acording to Denny Vrandečić from Google. --FischX (talk) 08:15, 7 May 2015 (UTC)
     • @FischX: Can you please provide a link to where he says this? —Msmarmalade (talk) 10:27, 7 May 2015 (UTC)
       • No, because the webinterface for wikidata-l doesn't support searching. But feel free to subscribe and look it up yourself. --FischX (talk) 13:46, 7 May 2015 (UTC)
5. Oppose "as per" oppose #1 and #3. I'm sorry, I don't have too much more to contribute to this discussion. Thanks, --L235 (t / c / ping in reply) 00:07, 7 May 2015 (UTC)
6. Oppose per #1. But it looks like most people want to get rid of it. BIt will be interesting to see if new article gets any description on WikiData when wikidata cant import it from Enwiki. I think we have evidence that when text are not visible at enwiki nobody sees it and "nobody" edits it like wikiquote, news, and so on. Christian75 (talk) 18:54, 8 May 2015 (UTC)
7. Oppose - right now the infobox simply doesn't have the capability of PersonData, including the ability to have text that is invisible to the page, such as basic description (eg 14th-century English knight) or to include "also known as" for alternate spellings, previous names, etc. These are highly useful for searching. I do favor infoboxes however and think they should be mandatory when sufficient info is available. And Wikidata, in my experience, is very clunky - asking people to go to a second page to input data for every article is going to cause some problems. —Мандичка^YO 😜 00:09, 22 May 2015 (UTC)
   • Description, alternative spellings ("alias") and former names parameters are all available in Wikidata. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 09:31, 24 May 2015 (UTC)
   • 'infobox simply doesn't have the capability of PersonData, including the ability to have text that is invisible to the page' - it seems to me trivial to port that from the {{PersonData}} to any infobox, and then (bot-)migrate the info to infoboxes on each page. --Dirk Beetstra ^{T C} 12:12, 24 May 2015 (UTC)
8. Oppose at least for now.
   • The alternative names field provides information that is not necessarily in the article or redirects
   • The other fields are potentially useful redundancy.

   All the best: Rich Farmbrough, 11:28, 23 May 2015 (UTC).
   

   • • But can all that not be handled by the infobox, which is often (if not always) also on the page. To me it seems trivial to port the code from the {{PersonData}} to the infoboxes, and a bot can migrate the data without any loss. --Dirk Beetstra ^{T C} 12:12, 24 May 2015 (UTC)
     • Right; "information that is not necessarily in the article or redirects" can be added to the article or made into redirects, and should already have been. Alternative name info only found is Persondata is basically wasted and invisible for most intents and purposes.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  13:29, 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.

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)

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

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)

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)
• FYI, there is already half a dozen manual tags in use on fr.wiki. Cenarium (talk) 23:33, 24 May 2015 (UTC)

RfC - Creating Redirects to lists, from the things they are lists of

Pigsonthewing requested at Bot Requests a bot to create redirects for lists. E.g. If there is a list List of Foo and the article Foo does not exist, create the page Foo as a redirect to List of Foo. I have done some pre-processing and this will create over 77000 new pages. I have submitted a request for bot approval. Per WP:MASSCREATION I am submitting an RfC here to gauge support, opposition and otherwise. I have also posted at WikiProject Lists and WikiProject Redirect. Jamesmcmahon0 (talk) 21:01, 11 May 2015 (UTC)

For evaluation purposes, can you build a partial list of cases where "List of Foos" and "Foo" exist but "Foos" does not and would become a redirect to the list? If "s" at the end is literally the only difference then it should be simple to make the list but cases like List of demoparties, Demoparty and Demoparties may be trickier to automate. I don't think Demoparties should redirect to the list. PrimeHunter (talk) 21:56, 12 May 2015 (UTC)

Second this request. Would save people a lot of time pondering this if some examples were given. Jason Quinn (talk) 19:33, 13 May 2015 (UTC)

If, as is common, the list article begins The following is a list of [[demoparty|demoparties]]... then the bot could be programmed to find the first piped link, check both Demoparty and Demoparties and, if neither existed, create the redirect at Demoparties. In this instance Demoparty does exist, so presumably no redirect would be created: Noyster (talk), 20:03, 13 May 2015 (UTC)

The full list has been dramatically scaled down now to around 12000 by removing pages that were of the type 'Foo (A-F)' etc. It is here, the list of cases where "List of Foos" and "Foo" exist but "Foos" does not contains around 500 pages and can be seen here. Since these cases are a little more complicated, I think it is best to leave them out until after the 12000 block has been completed. Jamesmcmahon0 (talk) 10:55, 19 May 2015 (UTC)

On the whole, it's probably a good idea. Praemonitus (talk) 15:45, 13 May 2015 (UTC)

• Comment - If this is going to be done, can we ensure the bot creates the redirect in accordance with WP:REDCAT, and that it contains {{rcats}}: {{R from subtopic}} and {{R to list entry}}. I also think we should create a category for these redirects; like for example: Category:Bot created redirects. The source code would append as follows:

#REDIRECT [[Xxyyzz]]

{{R from subtopic}}
{{R to list entry}}

[[Category:Bot created redirects]]

Thank you for considering this as well.--John Cline (talk) 04:32, 18 May 2015 (UTC)

I was going to use

{{R from list topic}}
{{R with possibilities}}

I don't think {{R to list entry}} makes sense in these cases and I'm on the fence about {{R from subtopic}}. I can definitely do the Category:Bot created redirects however which would probably be a good idea. Jamesmcmahon0 (talk) 10:54, 18 May 2015 (UTC)

Thank you. The rcats I mentioned were a suggestion. I understand that this has been discussed, and do not contest using the rcats you've shown. Cheers.--John Cline (talk) 14:44, 18 May 2015 (UTC)

• Support proposal.--John Cline (talk) 14:44, 18 May 2015 (UTC)
• Support per Jamesmcmahon0's rcat revisions, and with the proviso that in most cases plurals of the topic names should redirect to the singular if it exists (e.g. Demoparties -> Demoparty not -> List of demoparties). It's kind of absurd that we have so many such lists with redlinks for their bare topic names.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  13:50, 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)

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: [5]. 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)

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?

    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)

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)

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

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)

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

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)

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)

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.

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

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)

The article titles "de jure"/"De facto"

The title of the "De facto" article is first-word-capitalized. The title of the "de jure" article is not. I find this disturbing. Vexes my sense of symmetry and seems kinda' awkward and embarrassing for Wikipedia (as they're likely to often be referenced together). I propose we pick 'one way or the other' and stick with it for both. I personally don't have a strong preference as to which, as long as they match. --Kevjonesin (talk) 12:20, 22 May 2015 (UTC)

I'm not entirely sure why de jure is not capitalized in the article title. House style would indicate that the first letter of a title is normally capitalized, with a few exceptions, mostly related to proper names where the first letter isn't capitalized (like iPhone). The article de jure is not one of those exceptions. --Jayron32 12:24, 22 May 2015 (UTC)

De jure is now capitalized: Noyster (talk), 13:24, 22 May 2015 (UTC)

Thanks Noyster, ... but how was it done such that the edit showed up neither in page history nor on my watchlist? (Is some server lagging, or ... ?) --Kevjonesin (talk) 13:47, 22 May 2015 (UTC)

{{lowercase title}} was removed in [8]. I saw it in the page history, and it's also on my watchlist after I have added the page. I don't know why {{lowercase title}} was added in [9]. PrimeHunter (talk) 14:42, 22 May 2015 (UTC)

Problem article

I apologize in advance, because I'm sure I'm posting this at the wrong place.

The article 1967 Greek coup d'état contains not one single reference, including to this statement:

• As it turned out, the constitutional crisis did not originate either from the political parties, or from the Palace, but from middle-rank army putschists.

Further, nearly all of the article's text is identical, word for word, to the much longer text in Greek military junta of 1967–74, which is properly referenced. It seems to me there's no purpose at all to the 1967 Greek coup d'état article, and it ought to be removed. I'm not familiar with this history, but came to Wikipedia looking for information on the subject after seeing the Costa-Gavras movie Z (1969 film). Milkunderwood (talk) 03:42, 23 May 2015 (UTC)

This should just be discussed at the articles' talkpages. However, I quite agree there's a problem with the present state of the articles, and it makes no sense to have them separated like this at the moment. I have redirected the coup d'état article to the junta one, for now. I'll copy this thread to Talk:Greek military junta of 1967–74 for further discussion. Fut.Perf. ☼ 08:36, 23 May 2015 (UTC)

Thanks for your help. I didn't see the point of leaving messages on the talkpages - it looked as though no one ever looks at them. Milkunderwood (talk) 18:29, 23 May 2015 (UTC)

Yeah, not much talkpage activity there, but that of course doesn't necessarily mean there's nobody who's watchlisted it. The junta article has seen substantial recent editing activity, with some experienced editors such as Cplakidas and Dr.K. taking part, so I trust they'll see it and pick up on it if they think it needs more work. Fut.Perf. ☼ 21:22, 24 May 2015 (UTC)

• Post a topic in the article talk page, and then post at WP:Wikiproject Greece and WP:Wikiproject Military history asking them to comment there. Oiyarbepsy (talk) 13:31, 28 May 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)

Missing mobile features

More things should be added to the mobile version of Wikipedia. Red links, collapsible discussion boxes, and archive boxes are 3 things that are oddly missing. There is a lot more. With those green collapsible boxes, there is no writing at all on mobile view. —DangerousJXD (talk) 09:09, 24 May 2015 (UTC)

You can switch to the desktop version by clicking the link at the bottom of the page. Or you can try and convince the WMF developers to add more functionality to the mobile version. Unfortunately i'm pretty sure those are your only options, a proposal here is unlikely to result in any changes to the software as it isn't really a matter of local policy. Beeblebrox (talk) 14:15, 24 May 2015 (UTC)

Minor mobile edits

Edits on the mobile version of Wikipedia should be allowed to be marked minor. GeoffreyT2000 (talk) 17:20, 24 May 2015 (UTC)

Yeah, probably, see the thread directly above this one. Beeblebrox (talk) 18:28, 24 May 2015 (UTC)

UseModWiki modernization

All wikis that use UseModWiki should be modernized to use MediaWiki. 2607:FB90:54A:9F39:45DF:9BD3:926:F52C (talk) 02:13, 25 May 2015 (UTC)

This page is for proposals about Wikipedia, one the wikis run by the Wikimedia Foundation. Wikipedia and all other Wikimedia wikis already use MediaWiki. We have no influence over unrelated wikis that use UseModWiki. If you want them to change their software then you will have to contact them. PrimeHunter (talk) 15:36, 25 May 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)

Transclusion as a general formatting principle

Some places, such as FAC, FPC and RFA, use subpages which are then transcluded onto a main page, which compartmentalises edit histories in a useful way and, if used correctly, eliminates notification linkrot. Many places including VP do not use this method, and I wonder if we shouldn't deploy it more widely. Thoughts? Samsara 01:21, 26 May 2015 (UTC)

No, it's too hard to watch a page when discussions are actually on subpages. Wikipedia is not yet a forum (we're waiting for WP:Flow for that), so discussions should not go on and on, and generally a single page is best. There are good reasons for the exceptions. Johnuniq (talk) 02:34, 26 May 2015 (UTC)

I disagree. Not all places that close discussions use subpages, so it's not clear that there is a direct link between those two questions. Samsara 10:40, 26 May 2015 (UTC)

I don't know what you are disagreeing with—I said three things: hard to watch; not forum; good reasons for exceptions. Perhaps you agree with each of those but disagree with my conclusion? Johnuniq (talk) 11:22, 26 May 2015 (UTC)

The first thing you said was "no". I disagree with that. More specifically, you seemed to be advancing an argument that subpages are not suitable for venues that do not have a prescribed closure mechanism. However, ANI for instance follows the open format and yet encourages formal closures, so these are clearly not mutually exclusive. I also find the subpage format much easier to watch and am drawn to wondering how much experience you have using it. You get one watchlist notification when a subpage is added, and may decide to watch that or not. Much easier for keeping track of things that actually interest you. Samsara 11:42, 26 May 2015 (UTC)

Subpages are good when the quantity of the edits to each subpage is going to flood people's watchlists. Subpages are bad when you want to have each new edit to the page trigger your watchlist. So, once someone is nominated at RFA, I'm either interested in their nomination, or not. The RFA is unlikely to have some dramatic shift in scope that I would want to watch out for and would make me more interested in the discussion. At someplace like AN/I, discussions can develop in unexpected ways, and because the results can be significant, those of us interested in AN/I want to make sure we can see everything in our watchlist or the main history. So for instance if a thread starts off about some minor incivility, I wouldn't watch the subpage. But if a couple days later, a new subsection starts alleging a misuse of admin tools, that I would be interested in reviewing and possibly commenting. But if its a subpage, I wont be able to see that shift from either the history or my watchlist, because the main page is unchanged. If its not a subpage, the flurry of discussion in the new section would alert anyone looking to the new subtopic.Monty₈₄₅ 14:04, 26 May 2015 (UTC)

I concur with both of you. Yes, we should deploy it more widely, where it makes sense, but not impose it where it doesn't. For something like a policy/guideline talk page it would be disastrous, just as it would be for ANI. What we really need a flexible system by which we can be notified new entries and subscribe individual ones, or subscribe to whole page (not just the skeleton of it, but changes to its subpages; i.e. for this page, subscribe to all automatically). Properly developed, we'd even be able to subscribe to all by default, but selectively unsubscribe from others. Really well developed, this would even work in articles, i.e. watchlist particular sections, or watchlist all section by default, but quit watchlisting one in particular.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  03:42, 28 May 2015 (UTC)

• We need some major improvements to our transclusion and watchlist software before we do this. We need watchlist options like "watch this page and all subpages". We need transclusion that puts edit links on subsections, not just the main sections. We need transclusion that puts you back on the original transcluding page (not the subpage) after making an edit. If these kind of technical improvements are made, I would support this just about everywhere, but for now, too many problems. Oiyarbepsy (talk) 13:24, 28 May 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)

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

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

Account anniversaries

There should be a template for an account anniversary notice. Also, there should be a bot named "AnniversaryBot" that automatically places an anniversary notice on a user's talk page every year on the anniversary of the user's account creation date. GeoffreyT2000 (talk) 22:25, 26 May 2015 (UTC)

• Why?
• But if you really want to you can just create the template yourself
• An impersonal automated message from a bot informing users of something they may or may not give a damn about is not an idea I would support, but you can ask at WP:BOTREQ if you insist
• But really, why?

Beeblebrox (talk) 23:24, 26 May 2015 (UTC)

(edit conflict) As far as the template goes; {{User Wikipedian For}} shows if it's a Wikiversery on the day off. See my sandbox for an example (feel free to change the date if needed to make it an anniversary). Kharkiv07 (T) 23:26, 26 May 2015 (UTC)

• @GeoffreyT2000:It looks like the Wikipedia:Birthday Committee already does this, on an opt-in basis. Oiyarbepsy (talk) 13:11, 28 May 2015 (UTC)

Naming of biological conditions

Wikipedia naming of biological conditions should follow a consistent convention. For example, either micrognathism and macrognathism or micrognathia and macrognathia. I suspect that the -ia forms are more useful, but for many, the -ism for might be more prevalent. One form can have the article content, and the other form should redirect to the article. 72.93.214.237 (talk) 01:34, 27 May 2015 (UTC)

• WP:COMMONNAME would probably be the convention that we follow, if we're not already following it. Ian.thomson (talk) 01:36, 27 May 2015 (UTC)
• I'm a bigger fan than many of article title consistency, but I don't think we need to have an explicit convention on this. Maybe just do the on-WP research to find all these would-be-affected articles, note which suffix is used more, and use a multi-article WP:RM to propose moving all the non-compliant cases to the other ending. I'm skeptical that this is really a COMMONNAME issue. I think an analysis along those lines could be misleading, e.g. because one suffix may be more generally standardized across medical professions, but one speciality that puts out a lot of journal articles might prefer one spelling and be over-represented in search results, while more disciplines, and more actual people, use the other but get few Ghits, a false COMMONNAME analysis result Before proceeding, make sure that the alternative spellings are actually interchangeable. I'd be concerned that there's a subtle difference, such that -ia refers, technically, to the underlying disease/disorder, while -ism encompasses the resulting symptoms/pathology. I'm pretty sure that's actually the case, and that worse yet for this idea, there are many -isms that are not caused by an -ia (albinism is a disorder, but albinia isn't a word), and there are probably -ias that do not cause an -ism. For many articles, it won't matter, but it's conceivable that we could in a few cases have separate articles for them, and more than conceivable that we have lots of articles where the editorial focus is on one rather than the other. Hell, medicine can't even settle consistently on -cardio- or -kardio-. If these concerns don't turn out to be overwhelming, then I'd be all in favor of making them consistent to the extent this is practical, without imposing any non-existent or rare -ia forms on -isms or vice versa. If we really did want an explicit convention, the place to propose one is probably WT:NCMED. I'm skeptical it would be accepted because WP:NCMED has no specific rules at all, and just defers to general WP naming practices, and external international authorities (which in most if not all cases are going to agree that both the -ia and -ism versions of the words are legitimate, when both exist).  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  03:10, 28 May 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 dependence 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)

Oppose (edit restrictor)

1. I'm going to sit here for now until my question below is answered. 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)
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)
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)
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)

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)

Hovering over links

It is very good that you can (and I do not want it disabled until it is fixed).

I've come across a number of issues (may be fixed since I saw them): Extra space before comma, unexpected pictures (is second not first the rule?), and maybe some I've forgotten. The latest one:

Talk:Grant-maintained school#Does not "look" right when hovering.. I think what is happening is, as seen by hovering over foundation schools, that the title (singular) is bolded, can be seen by the second bolding that isn't there. Besides that, all formatting seems to be gone, explaining the missing bolded s. comp.arch (talk) 20:50, 27 May 2015 (UTC)

Wrong Village pump page; you want WP:VPT.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  02:44, 28 May 2015 (UTC)