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, 213, 214

Proposal: creation of "style noticeboard"

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.

---

Note: Dank has offered to the close this RfC upon its conclusion.

A user has proposed the creation of a "style noticeboard" (Wikipedia:Style noticeboard) at the MoS talk page, similar to the likes of the reliable sources noticeboard. He described the noticeboard in this manner: "a place where editors can raise and discuss specific situations, and get opinions on how to interpret the policy or guideline in the context of those specific situations". Such a noticeboard does not currently exist, and style issues are dealt with across a wide variety of labyrinthine MoS pages. The goal of the noticeboard is to allow for the centralised discussion of specific style issues at specific articles, so that users can come to consensus on how to interpret a specific piece of style guidance in our policies and guidelines, such as WP:AT and WP:MOS. Should such a noticeboard be created? RGloucester — ☎ 18:10, 28 March 2015 (UTC)

Support: style noticeboard

1. Support – There is no reason for there not to be such a noticeboard. The present system is not very good. Discussions are scattered across tens of MoS pages, article talk pages, Wikiprojects, &c. The creation of this noticeboard would allow for centralised and organised discussion of style issues, so that they can be quickly resolved. As we already have a series of similar noticeboards, such as WP:RS/N and WP:OR/N, I believe that this proposal should go forward. I have created the proposed noticeboard page, modelled on WP:RS/N. Please see Wikipedia:Style noticeboard. RGloucester — ☎ 18:15, 28 March 2015 (UTC)

   At this edit you originally opposed this idea. Can you explain whether this is a change of heart, or a different proposal, or what? Dicklyon (talk) 00:22, 29 March 2015 (UTC)

   It is merely a thought process. RGloucester — ☎ 02:01, 29 March 2015 (UTC)

2. Support it would be helpful to have a place for people to ask specific style questions other than wt:mos. I think a central noticeboard is better than a giant "request for style guidance!!!!" template on talk pages throughout wikipedia, both for ease of management and for ease of locating past discussion, which is what I understand PBS to suggest. Not sure what's going on with the numbering here. AgnosticAphid talk 17:20, 29 March 2015 (UTC)
3. Mild support I have no problem whatsoever answering people's questions at WT:MoS, but a noticeboard might be easier for people to find. Darkfrog24 (talk) 18:29, 29 March 2015 (UTC)
4. Support – I think WP needs a different venue for discussions about MoS issues. Often the discussions on talk pages (such as MOSNUM talk, in particular) can become overly long, and they can easily wander too far from the supposed topic of the talk page: changes to the MoS. Many threads on that talk page, indeed, have been about how editors should understand the existing MoS text, rather than proposals for changes to it. But as it stands, there is simply nowhere else to go to ask such questions. Archon 2488 (talk) 21:16, 29 March 2015 (UTC)
5. Support - A centralized noticeboard would be beneficial to getting help with style questions and getting outside opinions in style disputes.- MrX 21:28, 29 March 2015 (UTC)
6. Support Good idea, so long as it's watched by active knowledgeable editors. §FreeRangeFrog^croak 21:47, 29 March 2015 (UTC)
7. Support - A noticeboard would be easier for newbies to find and maybe a little easier to patrol, once we get past the initial re-routing posts to the new board. Mlpearc (open channel) 21:52, 29 March 2015 (UTC)
8. Support creation of this noticeboard; there were times I would have used it myself – had it been an option in my time of need. I am familiar with the cadre of personnel who generally comment on questions of Wikipedia styling and they are a competent creed who engender great confidence. Because of their collective professionalism, I expectantly anticipate that this noticeboard will quickly become the go-to example of a Wikipedia-thing "done well". Also, when you consider the stifling effect that discretionary sanctions have brought to so many talk pages, it becomes more apparent that neutral "sanctuaries of discourse" like this are needed things. Ironically, even Wikipedia talk:Manual of Style is subject to discretionary sanctions which cements my belief in the need for this noticeboard. Consider mine: strong support.--John Cline (talk) 03:33, 30 March 2015 (UTC)
9. Support – It would be a nice change to have a better, centralized place to bring up discussions concerning the Manual of Style rather than starting threads on one of the many different style talk pages. Dustin (talk) 00:39, 31 March 2015 (UTC)

   Comment - I'm abstaining, but it's It's worth noting that a note at the top of WP:VPP says: If you have a question about how to apply an existing policy or guideline, try the one of the many Wikipedia:Noticeboards. It says nothing about WT:MOS or any other talk page. ―Mandruss ☎ 01:57, 31 March 2015 (UTC) No longer abstaining. ―Mandruss ☎ 22:02, 13 April 2015 (UTC)

   Apparently that's as it should be, the MOS talk pages are for discussions about the MOS pages, not for general help with MOS applications. WP:PNB and {{noticeboard links}} list teahouse, help desk, etc. and also don't mention WT:MOS. –Be..anyone (talk) 00:32, 2 April 2015 (UTC)

   The first line at WP:PNB kinda sums it up. Mlpearc (open channel) 00:40, 2 April 2015 (UTC)

10. Support: Makes for more organized discussion of style guidelines, which are one of the most discussed areas of Wikipedia editing. Esquivalience ^t 03:13, 31 March 2015 (UTC)
11. Support as an attempt to centralize discussions which currently get spread all over the place. — {{U|Technical 13}} (e • t • c) 17:14, 1 April 2015 (UTC)
12. Support: I understand this as a proposal to create a place to help people who have writing style questions. At the top of WT:MOS, it says: "This is the talk page for discussing improvements to the Manual of Style page" but it has also served as a place to answer style questions. I think it is good to separate out those two functions. Inevitably there will sometimes be disagreements there, but it is good to keep them separate from discussion of what the MoS should say. It could turn into forum shopping, but better to expose style questions to people with an interest in writing style than leaving them on a seldom watched talk page. The people opposing seem to be talking about something else. If I'm missing something - let me know.  SchreiberBike | ⌨  00:47, 2 April 2015 (UTC)
13. Support: great plan. It will help bring consistency. Atsme☯^Consult 18:32, 2 April 2015 (UTC)
14. Support Per the above; obviously a good suggestion.--Ubikwit ^連絡 _{見学/迷惑} 19:09, 2 April 2015 (UTC)
15. Support: WP:Reference desk allows users to seek specific factual information that they may have trouble finding themselves in our articles. The proposed noticeboard would do the same for style guidelines and best practices. —174.141.182.82 (talk) 02:00, 4 April 2015 (UTC)
16. Support, let's give it a shot, there seems to be enough people who are willing to volunteer. Kharkiv07^Talk 02:14, 4 April 2015 (UTC)
17. Support It sounds like a good idea. A place to get answers about style based on policy from uninvolved editors. AlbinoFerret 02:57, 4 April 2015 (UTC)
18. Support WT:MOS is a place to discuss the MOS itself, not an (official) place to ask questions. --Fauzan^{✆ talk}_{✉ mail} 14:38, 4 April 2015 (UTC)--Fauzan^{✆ talk}_{✉ mail} 14:38, 4 April 2015 (UTC)
19. Support MoS talk pages have always sufficed on those handful of occasions I needed to clarify a particular matter of style. I think it occurs to a lot of people naturally as the place to go in that, if one is questioning a given style guideline, it is probably because it seems unintuitive to them in some way, and they are thus correspondingly interested in whether or not the MoS page should be altered, or at least in discussing the issue in that context even if they aren't certain a change is called for. Outside that context, the VPP and the the help desk are options as well. All of that being said, I really see no substantial downside to setting aside a dedicated space for this sort of thing. So long as it's made clear that this is the space for discussing implementation of existing policy, not debating it. Other noticeboards that exist for procedural, technical, and behavioural matters manage to operate under this dichotomy and are generally seen as beneficial (if not essential) to greasing the wheels on quickly resolving various types of issues and bottlenecks. Some have cited forum shopping as a concern, but no one seems to suggesting that we suspend policy or allow for endless debate on maters that we already have guidelines for (the appropriate place for such discussion should remain the talk pages of the relevant MoS/policy pages, central discussion spaces, and so forth). To the extent anyone lands at this forum looking to shop their perspective, it will sink or swim on the basis of how it conforms to community consensus, exactly the way it should. Snow ^{let's rap} 01:46, 7 April 2015 (UTC)
20. Support seems a good idea, often advise and discussion on style issues can be all over the place. MilborneOne (talk) 15:55, 7 April 2015 (UTC)
21. Support, for much the same reason that Carrite (whom I deeply respect) has opposed it: "The Manual of Style is a beacon attracting obsessive sorts from far and wide to fight over dashes and capitalization". The current system is fragmented - style concerns are discussed in several different, obscure locations and can even involve one wikiproject's quirks becoming wikipedia-wide law, or different areas having mutually incompatible style rules - and this fragmentation makes it more likely that a small number of editors can get their own personal style-obsession regarded as a "consensus" and can then go about imposing that "consensus" on a much wider community. A single, centralised noticeboard would attract a wider audience and get a broader basis for any consensus. Doing without a proper discussion point won't make the (small, noisy minority of) problematic editors go away - the last decade of religious wars over minor points of style have shown us that. bobrayner (talk) 19:05, 8 April 2015 (UTC)
22. Support: WT:MoS is for discussing proposed changes to the MoS itself, while a Style noticeboard would be for discussing interpretation and application of the MoS. I can see how there would be some overlap between the two arenas of discussion, but given how difficult it is to navigate the many MoS subpages (and related, non-MoS, pages), I believe a noticeboard would be more beneficial than detrimental. Xaxafrad (talk) 23:13, 8 April 2015 (UTC)
23. Support - I only just realised that, while I'm prepared to man (or "woman") the board, I hadn't expressed why I'm in favour of it. One of the greatest problems I encountered, as regards the Wikipedia learning-curve, was that of having to dig through the WP and MoS guidelines in order to establish transliteration standards, common name standards, dashes vs hyphens, lower case as the standard as opposed to the conventions used in Western academic norms, English language variants... well, you name it, it isn't intuitive, and it certainly isn't easy to find the relevant guidelines or norms. It's difficult enough to get one's head around policies and guidelines, much less having to spend hours trying to decipher discrepancies between geographical nomenclature conventions from other conventions. For the sake of new users, it would serve as an obvious and straight-forward method of addressing their concerns. Even for the sake of experienced editors, few could claim to be all-rounders. Pooling our knowledge at an easily accessible noticeboard has to be a better approach than guesstimating, only to have your hand slapped. --Iryna Harpy (talk) 04:47, 10 April 2015 (UTC)
24. Support as long as it's active. I think it would really service all editors and users very well. CookieMonster755 (talk) 21:46, 10 April 2015 (UTC)
25. Support a one-year trial period. At the end of that year, if anyone feels the need, there can be an RfC (MfD?) to decide whether to keep or remove, using actual tangible data instead of the CRYSTAL that is pervading this discussion. This deserves a chance to work. ―Mandruss ☎ 22:02, 13 April 2015 (UTC)
26. There are two reasons why I support this proposal. First, I think it will help prevent instruction creep at the MOS pages. Currently, whenever an issue related to style comes up, the only place to discuss it is at one of the various MOS guidelines. Since those talk pages are focused on discussing changes to the MOS pages themselves, any discussion quickly devolves into a question of "should the MOS be changed to say X?" or "We need to add something to the MOS to cover Y". However, often what is needed is not a change to current guidance, but a consensus as to the interpretation of it. I think the MOS guidance would become more stable and less contentious. The other reason is that I think it would help cut down on conflicts between MOS pages. We have many MOS pages, and they sometimes end up give conflicting advice. A Noticeboard would help highlight conflicts when they occur... If someone asks a question and gets conflicting answers pointing to different MOS pages, we will know that we have a conflict to resolve. Blueboar (talk) 19:23, 14 April 2015 (UTC)
27. Support with conditions: I am concerned with the use of the term "noticeboard" in relation to this outlet, primarily because it implies complaints about the states of articles. I'd call it a "Style help desk" instead. ViperSnake151  Talk  16:17, 15 April 2015 (UTC)
28. Support – I believe the above arguments are cogent and although the below ones are likewise valid, I personally believe that a MoS Noticeboard, or Style Noticeboard (or "Style help desk", like Blueboar said above) is long overdue. The MoS talk page already serves as a de facto noticeboard anyway. Why not send those discussions to their appropriate place while keeping this talk page for exclusively discussing the content of the Manual of Style? To me, this is an obvious decision. To many, however, I suppose it obviously is not. Seeing as many of their arguments comprise concerns about beaurocracy creep, however, I find it difficult to classify this as a more convincing argument than the need for such a board. I consider these fears to be unfounded, and for the board to be justified in this circumstance. Such concerns are certainly worthwhile to consider; I've considered them, and find them insufficient. ―Nøkkenbuer (talk • contribs) 13:44, 25 April 2015 (UTC)

    [indenting duplicate vote - Dank (push to talk) 11:15, 4 May 2015 (UTC)] Support - absolutely. There should be consistency in formatting and style across the project. A noticeboard will help achieve such a goal, and it will also help identify where editors are having the most issues. Atsme☯^Consult 13:59, 3 May 2015 (UTC)

Oppose: style noticeboard

1. Oppose per WP:CREEP, WP:NOTFORUM and de gustibus non est disputandum. Andrew D. (talk) 21:49, 29 March 2015 (UTC)
2. Oppose. For style questions relating to individual articles, the place to encourage discussion is not on a new noticeboard, but on the talk pages of the relevant article (or template, category etc.). We should also encourage style-related questions to be raised within the various WikiProjects. I also agree with Andrew D.'s concerns, noted above. Neutrality^talk 23:34, 29 March 2015 (UTC)
3. Oppose We don't need yet another place to drag users and berate them when we disagree with them. If someone is being disruptive over style issues, we already have places to discuss that. If people want to have genuine, non-confrontational discussions of style issues, we already have places for that too. This board is unneeded, and more "noticeboards" are merely magnets for more drama. No thanks. --Jayron32 00:04, 30 March 2015 (UTC)

   Jayron32, your comment rests on a false premise. You must surly speak in jest when you suggest such nefarious motives; underpinning the creation of this noticeboard.--John Cline (talk) 04:06, 30 March 2015 (UTC)

   No where in my post did I mention any motive for creating this board. I don't really care why you want to create it, or what your motives are, and my oppose isn't based on what your motives are, because I am not a mind reader, and have no way to know your motives. I merely based my opposition the expected result of creating the board, based on the action at literally every other board at Wikipedia titled "noticeboard". What users do at anything named "noticeboard" is drag their enemies in for a good kangaroo court session. I could care less why you want to create this board. But because that's what every other single "noticeboard" is at Wikipedia, we don't need another one of those. I can only judge the likely future by the patterns of the past. And those patterns tell me this will be nothing except another dramah bord. No thanks. --Jayron32 02:42, 2 April 2015 (UTC)

   Thank you.--John Cline (talk) 03:36, 2 April 2015 (UTC)

4. oppose per Andrew D., WP:RS is a respected guideline, WP:MOS is a maze of twisty little passage, all alike, mainly existing to keep the contributors busy on something that won't cause havoc in the main namespace. –Be..anyone (talk) 10:08, 30 March 2015 (UTC)
5. oppose - This is interesting in theory, but I fear problematic in practice. I've worked in places where creative efforts and processes are reviewed often and the derision and debate is endless. Trained artistic professionals sometimes debate vehemently, and we want to invite a bunch of anonymous amateurs to do this?! I feel that creating a board where "artistic differences" are discussed will devolve into something that will make WP:ANI A.K.A. The Drama Board pale in comparison. --Scalhotrod (Talk) ☮ღ☺ 17:11, 30 March 2015 (UTC)
6. Oppose per above It's a good idea, but I feel Wikipedia_talk:Manual of Style is "a place where editors can raise and discuss specific situations, and get opinions on how to interpret the policy or guideline in the context of those specific situations" in relation to the WP:MOS. If you ask a MOS-related question there about MOS someone will answer. --Psychotic Spartan 123 02:08, 31 March 2015 (UTC)
7. Oppose since in light of his comment here, I can only interpret RGloucester's proposal as an attempt to prevent the MOS from influencing style decisions. WT:MOS serves the purpose, and if we want more central style guidance, trying to move that role further from the MOS makes no sense. I would consider the original proposal more favorably. Keep in mind that RGloucester has made his contempt for the MOS very clear and explicit; so what kind of style guidance does he have in mind; he says his edits are directed by God, so I suppose that's his source of style guidance, too? Dicklyon (talk) 06:37, 1 April 2015 (UTC)
8. Seems like more bureaucracy and arguments. Stifle (talk) 09:25, 1 April 2015 (UTC)
9. Oppose we already have the teahouse, help desk and village pump pages to ask at. We do not need the helping volunteers to be further spread out having to look at more pages. Graeme Bartlett (talk) 11:20, 1 April 2015 (UTC)
10. Strongest possible oppose One of the most frightening proposals I've seen. "Neutrality" (near the top of this section) has it exactly right: changes to guidelines should be discussed on the respective branches of Talk:MOS, and questions about individual articles belong on the talk pages of those articles. When and if a particular issue proves itself to be wasting editor time on multiple articles, then it's time for that issue to come up at MOS for a possible change in the guidelines, to end that waste of time. What we DO NOT NEED is another place for disgruntled style warriors to forum-shop. If it matters enough for broad discussion, then that discussion should take the form of a consideration of a change to MOS; if it can't be expressed as a possible change to MOS, then it doesn't need broad discussion and should be discussed on the talk page of the article in question. EEng (talk) 15:06, 1 April 2015 (UTC)

    @EEng: We don't seem to be on the same page. The noticeboard is meant to address cases like this one: [1]. Lots of people show up to WT:MoS asking "What should I do?" "What's correct?" "Does Wikipedia have a rule about this?" The noticeboard would be for these questions, not for suggested changes to the MoS. Blueboar and RG have both confirmed below that this is what they meant. Darkfrog24 (talk) 17:54, 1 April 2015 (UTC)

    I guess I was imagining this as mostly as a place where disputes would be brought, rather than (as in your example) simple, probably noncontroversial inquiries. That feels less objectionable to me, but still I wonder whether Village Pump isn't enough. What's the volume of such inquiries? In fact, that gives me an idea... how about if those who see a need for this new board link to a half-dozen recent inquiries (somewhere...) that would have been better handled under this proposal. If there's really a need for this, that ought to be easy. EEng (talk) 18:48, 1 April 2015 (UTC)

    The concern that the creation of the noticeboard would address is that there might be many more people with questions who simply don't know that they're supposed to go to WT:MoS to ask them. It's not that creating a noticeboard would improve the quality of the answers (which is already quite high); it's that it would improve accessibility. If a new Wikieditor has heard about the RSN noticeboard and the V noticeboard then he or she is more likely to suppose that there might be a style/English/writing mechanics noticeboard (and vice versa) than that he or she should go and ask at WT:MoS. As for examples, I did provide a few links in the discussion section below, but the list is certainly not exhaustive. I just picked an archive page more or less at random and looked around for something representative. Darkfrog24 (talk) 21:40, 1 April 2015 (UTC)

    After watching the discussion develop for some time now, I've decided to let my oppose stand. The argument that there's an unfilled need for a place for people to ask where-is-it-in-MOS questions seems to me weak, but I'm absolutely terrified at providing another place for editors to pontificate on split infinitives, serial commas, and so on -- and that will happen, guaranteed, on any page with "style" in its title, no matter what's intended. EEng (talk) 02:49, 10 April 2015 (UTC)

11. Oppose; this is a recipe for more bureaucracy, disputes, drama, and chaos - all of which this area has historically managed to attract even without a dedicated noticeboard. Ncmvocalist (talk) 15:17, 1 April 2015 (UTC)
12. Oppose There are existing venues for asking for help with style. A noticeboard to discuss and establish consensus about style is likely to contribute to the divisiveness and unlikely to be beneficial. wctaiwan (talk) 17:32, 1 April 2015 (UTC)

    Agree, and melding what you say with what I said earlier, we shouldn't have two tiers of MOS-like guidance -- some actually embodied in the text of MOS, and some embodied in some vague consensus you can only find by trawling through discussions on this new noticeboard. If we want to do something a certain way projectwide, that should be memorialized in MOS, and the various branches of Talk:MOS are the place to decide on that. EEng (talk) 17:57, 1 April 2015 (UTC)

    If one looks at the noticeboard, it makes it clear that its answers are not policy. They are merely third opinions. These would not constitute a body of precedent, or whatever. The purpose of the noticeboard is to allow people to ask questions about style guidance, just as with WP:RS/N and reliable sources. This is not about "memorialising" or "changing" the MoS. It is about directing people to obscure MoS pages, showing them the guidance, and explaining it to them, in reference to particular piece of text. It is about answering people's questions in a centralised and easy to access location. This is a great misinterpretation of the proposal. WP:RS/N does not override WP:RS. RGloucester — ☎ 18:00, 1 April 2015 (UTC)

    Oppose, unless I'm missing something, this seems like something that's best to gather consensus for on the talk page of the article. Kharkiv07^Talk 00:52, 2 April 2015 (UTC)

    Moving to support Kharkiv07^Talk 02:13, 4 April 2015 (UTC)

    I think you may well be missing something. The noticeboard is meant to be for asking style questions in specific instances, e.g. "I was working on article X, and found X. I was wondering if Wikipedia has a guideline about how to present this text, as the present styling seems off". It is not meant as a substitute for article talk pages, just as WP:RS/N is not. RGloucester — ☎ 01:02, 2 April 2015 (UTC)

    The proposed noticeboard is meant to address cases like this one [2], not proposed changes to the MoS or other pages. Darkfrog24 (talk) 03:48, 2 April 2015 (UTC)

13. Oppose - The Manual of Style is a beacon attracting obsessive sorts from far and wide to fight over dashes and capitalization. This new notice board would give them increased leverage over productive content writers who may disagree with their idiosyncrasies and compulsions. We have adequate mechanisms for ensuring reasonable consistency of form already, this new noticeboard would be CREEP towards disruption. Carrite (talk) 15:13, 2 April 2015 (UTC)
14. Oppose - What Wikipedia needs least is another drama board. Guy1890 (talk) 02:49, 4 April 2015 (UTC)

    I think that's overly cynical, fundamentally at odds with Wikipedia's bedrock principles, and unconstructive. If I'm wrong, those who feel that way are doing the project a major disservice by failing to actively and seriously advocate the elimination of all "drama boards" (I'm talking about an RfC at WP:VPR, not randomly placed negative comments). Sorry for being blunt, I don't wish to start trouble, but I think it really needed to be said. It also applies to many other discussions, past and future. ―Mandruss ☎ 03:07, 4 April 2015 (UTC)

    Since when does opposing the addition of yet another drama board mean that one must oppose all drama boards? Quite frankly, when you've been editing here more than a year or so, you'll eventually come around to one of two opinions...that many (not all) of Wikipedia's drama boards help Wikipedia move forward with improving an online encyclopedia or they hinder its further development. Live & learn my friend... Guy1890 (talk) 22:38, 4 April 2015 (UTC)

15. Oppose per Carrite mostly. Other 'drama boards'are at least in theory supposed to relate directly to content issues - the distinguishing characteristic of most MoS-related drama is how little it actually matters to readers, who one can safely assume are more interested in relevant information than they are in whether an article does or doesn't conform to a self-contradictory 'manual' that could usefully be reduced to half a dozen short pages. Or to a simple instruction to write for the expected readership. Get that right, and 'style' issues are generally of little real consequence. AndyTheGrump (talk) 03:50, 4 April 2015 (UTC)

    You seem to be reducing the entirety of the MoS to a handful of useful recommendations that are mere suggestions. In reality, it's a major content guideline that represents a staggering amount of community consensus formulated meticulously over countless broadly-representative discussions and representing the solutions and best practices with regard to technical constraints, language policy, and accessibility issues, to name just three of the critical areas it provides consensus and consistency for. Snow ^{let's rap} 03:17, 7 April 2015 (UTC)

16. Oppose because of flawed premise. Instead, policies and guidelines should be kept as simple as possible, and use clear language. Samsara 08:54, 4 April 2015 (UTC)
17. Oppose If you are so concerned about MOS that you think a new noticeboard is needed try upping your meds, instead. I'm not handing anyone a cudgel to go along with their obsession. Chris Troutman (talk) 13:22, 4 April 2015 (UTC)

    Does WP:RS/N imply an "obsession" with RS? Does WP:NOR/N imply an "obsession" with no original research? It is simply a matter of answering questions. It seems like many editors here are challenging the existence of the MoS at all, and if that's the case, they ought do something about it. Otherwise, given that we have an MoS and that it is a guideline, we must provide clarity. RGloucester — ☎ 13:57, 4 April 2015 (UTC)

    Verifiability, of which reliable sourcing is an essential component, and No original research, are fundamental content policies, along with several others. Having noticeboards to discuss in central places such critical content matters is a necessity. On the other hand, while having a MOS is nice, and some of the suggestions in it are good, it's not so fundamental as to require a noticeboard. It's not critical if some obscure MOS advice is not exactly followed, it's a minor inconvenience at best; the same cannot be said about NPOV, BLP, V and such essential policies. Cenarium (talk) 18:13, 4 April 2015 (UTC)

    The people who come to WT:MoS asking for help with style issues think that those issues are important enough to be worth their time. Here's one case: [3] Don't they deserve a place to do it? What about the people who want help but don't know that WT:MoS is the unofficial place to go? Wikipedia funnels new users with questions toward noticeboards, and we've already seen that they work. Darkfrog24 (talk) 21:31, 4 April 2015 (UTC)

    For people who need help? Surprisingly, there is WP:HELPDESK. Alanscottwalker (talk) 21:38, 4 April 2015 (UTC)

    Yeah but it doesn't seem to be drawing the style questions. I plugged "spelling" and "punctuation" and "engvar" into its archive search and they don't seem to deal with those issues the way we see them at WT:MoS. Did I miss something? Darkfrog24 (talk) 23:10, 4 April 2015 (UTC)

    Direct them to help, we have a whole desk for it, if you don't want to answer there. You can even put up a banner. Alanscottwalker (talk) 23:13, 4 April 2015 (UTC)

    Actually I don't mind answering on WT:MoS. The problem that the noticeboard would solve is that the newcomers and even veteran Wikieditors might not know that WT:MoS is the place to go for style help. A noticeboard would be easier for them to find. As for the help desk, what about the part where 39 out of 40 help desk requests have nothing to do with my area of expertise? We don't make NPOV specialists wade through three dozen style, R, and V threads. That's what noticeboards are for. Darkfrog24 (talk) 02:03, 5 April 2015 (UTC)

    Experts? What experts. Helpful people fine, but experts? Don't help those you don't want to help, help those you do. Alanscottwalker (talk) 07:21, 5 April 2015 (UTC)

    I mean editing, proofreading and linguistics experts. There are people, such as myself, who do this for a living and are willing to share their expertise. Darkfrog24 (talk) 19:26, 7 April 2015 (UTC)

    The concept of "experts" is elitist and antithetical to the project. You have no expertise here. RGloucester — ☎ 19:37, 7 April 2015 (UTC)

    Wikipedia:Reference desk/Language is the place for linguistic sharing (it can use help), and Wikipedia:WikiProject Guild of Copy Editors is always begging for proofreaders. Alanscottwalker (talk) 19:58, 7 April 2015 (UTC)

    WP:EXPERTS No, expertise is not antithetical to the project. Guild of Copy Editors is fine, but a noticeboard would specifically help people with specific style questions rather than improve articles one by one. Darkfrog24 (talk) 14:57, 8 April 2015 (UTC)

18. Oppose, per WP:CREEP and reasons stated by Neutrality.--RightCowLeftCoast (talk) 19:08, 4 April 2015 (UTC)
19. Oppose - I agree with Carrite, above. CorinneSD (talk) 01:54, 7 April 2015 (UTC)
20. Oppose There is already far too much argument about MOS issues, and no indication that any good would result from providing another forum for enthusiasts to promote their favored style. Johnuniq (talk) 23:01, 7 April 2015 (UTC)
21. Oh God no.—S Marshall T/C 12:34, 8 April 2015 (UTC)

22. I lean this direction per WP:CREEP. To explain myself further, my thought is that there may (often) come times where an editor asks for help at this proposed board, at least one person answers, and then a second answers, where the second somewhat contradicts the first. The likely scenario in my mind is that they hash it out on this noticeboard about what they think is the correct answer, but then nothing is fedback into the MOS. Alternatively, they don't settle it, then invite discussion on WT:MOS... at which point you should just have left the question at WT:MOS.

    I do see and agree with a concern that there are a lot of style talk pages lying around where one could ask a question about style but either a) get an answer from limited persons or b) not get an answer at all, both of which are negative experiences. If this is a real problem (and I might suggest that it is), then perhaps there should be some discussion about consolidating the MOS talk pages instead of creating this noticeboard. --Izno (talk) 01:26, 9 April 2015 (UTC)

    People don't ask questions on the talk page very frequently because at the top, it says the page is only for discussing improvements to the MoS. When people do ask, I've seen what you describe in the first paragraph a couple of times, but far more often the question is asked and answered and that's the end of the issue. I see a noticeboard as a place where people would be encouraged to ask questions about how to write for Wikipedia. Our MoS is complicated, as most thorough manuals of style are. It seems a kindness to provide a place for people to ask questions.  SchreiberBike | ⌨  01:49, 9 April 2015 (UTC)

    To back up, what SB has just said, since this proposal was initiated, four people have come to WT:MoS with questions: [4] [5] [6]. They got straightforward answers with no debate. Even though the guy asking about "birthplace" got different answers, they were based on different interpretations of the question ("If you mean X, do Y." "If you mean Z, do Q.") and did not contradict each other. That's more typical Darkfrog24 (talk) 05:17, 9 April 2015 (UTC)

    @SchreiberBike: What a page self-describes itself as is irrelevant to the discussion. If there's consensus found, the purpose of the page of will change, so this argument is specious. Finding a place to ask questions, and having this "noticeboard" be that place, thusly does not follow.

    @Darkfrog24: And I have seen each and every one of those go by on my watchlist (as I do watch WT:MOS), which is why I did not dispute the evidence that there is a common kind of question that people will ask that does not seem to require much action beyond "here's where to go/what to do". What does not immediately follow is that there must be a noticeboard for this question to be asked at, above and beyond WT:MOS (which seems to do just fine). WP:BROKE is relevant. And I have not seen evidence to the contrary that there is anything broken, because the supporters of this proposal cannot show evidence of a non-action regarding this kind of question; a poll of users might be interesting in this regard. Show me evidence that WT:MOS actively causes users not to ask their question (whether the name of the title is simply enough to invoke non-action or if the users associated with the MOS cause non-action on the part of a question-seeking-answer user). --Izno (talk) 14:38, 9 April 2015 (UTC)

    Alternatively, I happen to subscribe to the view presented by User:Samsara at #Does this even need community approval?. Be bold, put a noticeboard together, see if people actually do use it or silently accept its use (if even they don't agree with its existence). Add it to a nav template here, another there. If it gains traction (because editors at WT:MOS suggest its use or for other reasons), then that's an improvement of the encyclopedia. --Izno (talk) 14:59, 9 April 2015 (UTC)

    The noticeboard isn't meant to change the way questions are answered; it's meant to be easy to find. As Mandruss points out in his comment, new users are directed to noticeboards for help. The idea is that there may be many people who have style questions but don't know that they're supposed to ask them at WT:MoS, so naturally we don't have evidence of how many people give up before asking. Darkfrog24 (talk) 17:05, 9 April 2015 (UTC)

    Let's not forget the many subpages, as well, which greatly complicate matters. RGloucester — ☎ 17:18, 9 April 2015 (UTC)

    @Izno:I find some reasons to be suspicious of this project too, but not enough to reject the idea. When I started on Wikipedia, I looked for a place to ask questions but didn't find one. Instead I tried to read the massive MoS and I made mistakes.

    How about a trial period? Put up such a noticeboard, make it well known, and see how it works. After six months, a new RfC here to continue or stop. The problems people talk about could come true, but it also might help editors and make the writing on Wikipedia better.  SchreiberBike | ⌨  17:42, 9 April 2015 (UTC)

    I personally think that would be a good idea, provided we could find an administrator to close this RfC. I can very quickly get the board up and running. RGloucester — ☎ 17:49, 9 April 2015 (UTC)

    I just !voted for such a trial, and I got to believe I was introducing the clever idea for a few minutes before I found this. I suggested one year, and I think that much time would be necessary to get sufficient experience and data for any RfC. Those who like the idea might wish to modify their !votes to specify it. ―Mandruss ☎ 22:24, 13 April 2015 (UTC)

23. Per Carrite. I have lost more productive editing time over the years having to deal with obsessive-MOS types seeking to force the entirety of Wikipedia into their own preferred styles than for nearly any other reason. As Carrite notes, creating a centralized forum that could offer them greater leverage to impact the far larger population of editors will cause more harm than good. Resolute 02:50, 12 April 2015 (UTC)
24. Oppose: Where editors cannot work things out on an article's discussion page, the discussion page of the page of the pertinent MOS page already serves this purpose. If an editor behaves disruptively on such an issue, we have the administrators noticeboards.—Finell 02:54, 12 April 2015 (UTC)
25. Oppose, for the reasons given by Carrite. Kanguole 12:31, 12 April 2015 (UTC)

    So, we seem to be getting a lot of "per Carrite" points here. Please, elucidate. What exactly is Carrite's point? Such a noticeboard would not give "leverage" over anyone, and I don't see how it would. MoS is a guideline. RGloucester — ☎ 15:15, 12 April 2015 (UTC)

26. Oppose per Carrite, and despite the remark directly above this one I think his point is well expressed and does not require expansion, which is why so many opposers have cited it. Beeblebrox (talk) 21:54, 12 April 2015 (UTC)

    How is that an expansion of Carrite's diminutive negative observation? No one is asking you – or any of those 'opposing' per Carrite's CRYSTAL prediction of how it will inevitably turn into some form of hissy-fit-come-leverage-board – to involve yourself in manning (or wo-manning) the noticeboard. If it fails, it fails. Failure to render assistance and become an energy sinkhole for those willing to oversee the board will become self-evident quickly enough. You'll have to pardon my stupidity if I still fail to see the Carrite argument as any form of well expressed anything other than cynicism. By the same token, the NPOVN and RSN should also be removed as a waste of valuable time and energy for those "seeking leverage". All of the established noticeboards are equally, if not more, prone to abuse. Does that automatically make them unviable? --Iryna Harpy (talk) 05:55, 13 April 2015 (UTC)

    I have to says your calm, well expressed, and entirely logical and civil response has convinced me he is wrong and this noticeboard would not spawn the exact sort of problems Carrite describes. Well done. Beeblebrox (talk) 19:05, 13 April 2015 (UTC)

27. Oppose: I am going to say echoing Carrite and iterate specifics. Their quote: The attraction of obsessive sorts from far and wide to fight over dashes and capitalization. <snip> ... with their idiosyncrasies and compulsions. Two editors immediately come to my mind that I encountered because I employ an unusual grammar at times. I used an absolute adjective in an informal vote process, not in an article, even. And was pinged and critisised and teased in two different places. These are the type that would gleefullly dwell on such a board. I also agree that we have avenues now in place: start with the Teahouse, the article talk page, Village Pump, and since I am an active member of so many WikiProjects, I know they are a good resource. (Make an attempt to create a different style for Dog articles, for example with their rather stringent style, images, gallery size, infobox, sources already in place and you will get advice...). Fylbecatulous talk 17:45, 13 April 2015 (UTC)

    I don't see how what you just said has anything to do with the Manual of Style, or even "style" in general... RGloucester — ☎ 17:59, 13 April 2015 (UTC)

    Then I shall just state: oppose per WP:CREEP. Just above you said: "Please, elucidate", if one was using Carrite's statement as reason. If it is not the type of words you wanted, so be it. I still oppose per Carrite... Fylbecatulous talk 11:38, 15 April 2015 (UTC)

28. Oppose per Carrite. Wikipedia does not need a uniform style, which this noticeboard seems to imply, and will be used to enforce. --SmokeyJoe (talk) 06:29, 14 April 2015 (UTC)

    Now I'm just baffled. This noticeboard has nothing to do with "enforcement". It has no power. It is answering questions. Like it or now, we do have a manual of style. It isn't "uniform" because nothing on Wikipedia is uniform. It exists, however...This is just incomprehensible. RGloucester — ☎ 14:09, 14 April 2015 (UTC)

    I fear it will be used as a staging ground for self-appointed MOS enforcers. MOS aficionados definitely desire style uniformity, some even arguing that anything less makes us look ridiculous. Mandruss, 13 April 2015, offers a possibly reasonable compromise. --SmokeyJoe (talk) 06:15, 15 April 2015 (UTC)

    I'm perfectly fine with a trial period. RGloucester — ☎ 21:42, 16 April 2015 (UTC)

29. Oppose. The MoS requires internal consistency within articles, not consistency across Wikipedia: "Style and formatting should be consistent within an article, though not necessarily throughout Wikipedia." A style board might be used to try to force consistency across the project. If people have questions about the meaning of anything in the MoS, they can ask on that talk page. Also, volunteers are spread too thinly across the various boards as it is. Sarah (SV) ^(talk) 04:09, 15 April 2015 (UTC)
30. Oppose per the reasons Andrew D. brought up, especially WP:CREEP. APerson (talk!) 14:46, 17 April 2015 (UTC)
31. Oppose per WP:CREEP, The current model works, edit, disagree leads to discussion in article talk page. during the discussion MOS is cited, if a party thinks MOS is wrong they can go to that talk page and discuss changing it. a noticeboard would just create a place for WikiLawyers to argue instead of editors to discuss. Bryce Carmony (talk) 17:26, 17 April 2015 (UTC)
32. Oppose per Andrew D and Sarah. Ealdgyth - Talk 16:37, 22 April 2015 (UTC)
33. Oppose I think the current system works. The separate talk pages give some structure and people know where to go for certain topics. Fnagaton 14:02, 27 April 2015 (UTC)
34. Oppose. In fact, I'd sooner support doing away with the entire concept of "style" than giving people another place to fight over it. Nobody leaves Wikipedia because they see a dash where there should be a hypen or whatever. They do leave because of endless petty bickering over nothing, which is exactly what a style board would attract. In a project this big and diverse, some conflict is inevitable--there's nothing we can do about that. We can, however, keep the conflict to things that actually matter rather than commas and spacing. Andrew Lenahan - Starblind 13:14, 1 May 2015 (UTC)

Discussion: style noticeboard

I will oppose this proposal if it includes WP:AT as there is a perfectly good process for discussing Article titles Wikipedia:Requested moves and having a second place to discuss such things is a bad idea. -- PBS (talk) 20:23, 28 March 2015 (UTC)

This is not about moving an article. This is about asking for clarification on style guidance, just as RS/N is for asking clarification as to whether a source is reliable. RGloucester — ☎ 21:04, 28 March 2015 (UTC)

Yeah... I could see a style question that relates to an article title being raised at the new noticeboard... and what WP:AT says would logically have to factor into any answer to that question (Since a title is involved). Like other noticeboards, the proposed noticeboard is for asking questions and getting opinions... it won't issue "rulings". Blueboar (talk) 02:09, 29 March 2015 (UTC)

I have similar thoughts. To me, it isn't a problem that someone might ask a style related question at this noticeboard that they could have asked at a number of other places, like: the article's talk page, the teahouse, or Wikipedia:Requested moves – what matters is that they receive accurate information they can understand, and properly use. For example if their query did relate to a desire to move a page to another title, a quality answer would invariably include mentioning that Wikipedia:Requested moves is the correct page for advancing such a request. I do not see anything counterproductive with this noticeboard rendering such service.--John Cline (talk) 08:36, 29 March 2015 (UTC)

Another example showed up in the past twenty-four hours: [7]. This should serve both as an indicator of the kind of problem that this noticeboard might solve and the efficiency with which such problems are currently handled. The way I see it, the advantage of a noticeboard is that it might be easier to find. While the Wikieditors who come to WT:MoS with questions of this kind see them answered promptly and thoroughly, it might not occur to everyone that it is okay to ask such questions at WT:MoS. What I expect is that if this noticeboard goes up, we'd do the exact same thing but just do it there instead of at WT:MoS. Darkfrog24 (talk) 19:28, 30 March 2015 (UTC) @Mandruss: raises a good point. I think that if this motion does not carry, we should modify the note at the top of VPP to direct users with style questions to WT:MoS. That would make the status quo more official. If WT:MoS is then drowned in new questions, we can revisit the noticeboard idea. Darkfrog24 (talk) 17:35, 31 March 2015 (UTC)

Oppose – That's not what the MoS page is for. It isn't a noticeboard, and it cannot be listed amongst noticeboards. It is only for discussing changes to the MoS. Instead, I would suggest that people be redirected to the help desk. RGloucester — ☎ 03:59, 2 April 2015 (UTC)

@RGloucester: Maybe you should remove the bold "oppose" from your comment. Someone skimming the conversation might think that you are opposing the creation of the noticeboard. I am not at this time formally proposing that we direct style questions to the MoS but I plan to if this motion does not carry. As for said line or two, we already answer style questions there and it doesn't much disrupt regular business. As you can see from my comment, it would also allow us to collect information that could be used to revisit the creation of a noticeboard. Darkfrog24 (talk) 23:40, 2 April 2015 (UTC)

Oppose – Unacceptable. Style questions do not belong at the MoS talk page. RGloucester — ☎ 23:43, 2 April 2015 (UTC)

Well we got another one there just today [8]. It doesn't seem to be hurting anything, though I agree that a centralized, well-publicized noticeboard would be a better place. Darkfrog24 (talk) 01:40, 3 April 2015 (UTC)

Darkfrog24 is correct, it's potentially misleading to use a boldfaced "oppose" as a substitute for "I disagree with the preceding comment", which you've now done twice, RGloucester. ―Mandruss ☎ 01:52, 3 April 2015 (UTC)

I oppose his proposal. This discussion is not about support for my proposal. RGloucester — ☎ 03:19, 3 April 2015 (UTC)

Opinion: If this noticeboard is created and then goes horribly wrong, it will likely be because its respondents had the same mindset as the opposers here—that they’re not there to simply answer questions, but to make decisions. Which they shouldn’t. —174.141.182.82 (talk) 02:11, 4 April 2015 (UTC)

I fail to see how it could go "horribly wrong". As with other noticeboards of the same ilk (NPOVN, RSN, etc.), a style noticeboard would fulfil a need for having somewhere to consult with other editors who have MOS experience. There are a multitude of MOS guidelines/accepted standards that are extremely difficult to find unless you've been working a specific area of Wikipedia for a considerable time. Consulting on a centralised noticeboard is not the subject of sanctions unless a user is FORUMSHOPPING, which is a pre-existing problem with any noticeboards. Considering that the majority of new posts to similar boards end up being archived without any clear outcomes, it's hardly a precedent for hard and fast "decisions" to be laid down as a 'written in stone' outcome. --Iryna Harpy (talk) 21:28, 12 April 2015 (UTC)

• As Monty845 suggested below, how would people feel about Wikipedia:Style help desk instead of Wikipedia:Style noticeboard? That seems less like a drama board and more like the Wikipedia:Help desk which generally works well. It would be a place for people to ask and answer style questions and a place for people to get advice when there's a disagreement. We could specifically disallow discussion of changes to the MoS and it would have zero power. Approving something like this for a trial period might be a good idea. I don't think it will, but it could turn into a toxic cesspool of evil; so how about trying it for six months and only continuing it if it passes a new RfC?  SchreiberBike | ⌨  20:50, 13 April 2015 (UTC)

Oppose – The proposed noticeboard must be a noticeboard, as with other noticeboards. There is no reliable sources help desk, and there should not be a style help desk. There should be a noticeboard, per WP:PNB. This noticeboard proposal is already a place where discussion of changes to the MoS are strictly disallowed, and where the discussions have "zero power". Please do not skewer the proposal into irrelevance. RGloucester — ☎ 22:02, 13 April 2015 (UTC)

If the people with questions have a well-publicized place to go for help then what's the difference? A noticeboard would be better because that's Wikipedia's existing format and would be easier for new guys to find, but what's this vehemence? RG, what do you consider to be the advantage of noticeboard format over help desk format? I'm also not clear on how a help desk would be any more or less prone to drama. We'd still be dealing with the same straightforward questions, which would have the same answers. Darkfrog24 (talk) 01:14, 14 April 2015 (UTC)

I believe we should use the established WP:PNB conventions for noticeboards. There is no justification for creating parallel new structures, which would make the whole thing for confusing. "Help desk format" is non-existent. This is noticeboard for policy and guidelines, and should follow the standard format for that type of noticeboard. To be frank, I hope that the closing administrator takes into account that much of the opposition, including this hair-splitting about "noticeboards", "enforcement", &c. is incomprehensible. RGloucester — ☎ 16:38, 14 April 2015 (UTC)

Where to place the discussion

Another issue is the style that the proposed notice board can take, I suggest that it would be better to follow the method used for WP:RM/RfC, rather than the WP:RS/N. Ie the discussions remain on the talk page of the articles rather than being placed in a central area. -- PBS (talk) 20:23, 28 March 2015 (UTC)

That's not the purpose of this noticeboard. RGloucester — ☎ 21:04, 28 March 2015 (UTC)

Can you further explain this suggestion? Exactly what sort of notice board do you propose? Is what you suggest that if someone has a style question about the article "pizza" that they put their suggestion at Pizza:talk/noticeboard? That seems like it defeats the purpose of creating a centralized place that people can ask style questions. AgnosticAphid talk 21:58, 28 March 2015 (UTC)

Exactly, AgnosticAphid. I cannot understand this suggestion. The purpose of the proposed noticeboard is to allow for editors to request a third opinion on style-related questions in a neutral space, as with RS/N. RS/N is of great use for this purpose, and I see no reason why this similar page would not be of such use. Discussion on article talk pages are important, but third opinions are essential to resolving localised disputes. RGloucester — ☎ 22:04, 28 March 2015 (UTC)

I am not sure what a style noticeboard would achieve that isn't already covered via Wikipedia:Requests for comment/Wikipedia style and naming. GregKaye 10:35, 29 March 2015 (UTC)

GregKaye the current RfC you mention is for proposals like this, things that would change the styling manuals or naming conventions. Typically they take place at WT:MOS or whatever. Those RfC are not intended to discuss how implementing MOS would affect the content of a specific article. -- PBS (talk) 15:53, 29 March 2015 (UTC)

An RfC is not practical in every situation, of course. Many editors can resolve their discrepancies within days of receiving accurate information within collegial discourse. They do in fact, often use any of a number of noticeboards, they resolve issues in a few days, instead of thirty, and then they move on. Also, before selling too many shares in RfC efficacy, let me say that I filed an RfC a few months ago. One editor responded, and an admin closed it after 30 days; opining that the one response was reasonable, of which I agreed. When you consider all of the specialized noticeboards that are currently in productive use,[9] It is counter-intuitive to speculate that something as specialized as "Wikipedia styling" wouldn't benefit from a noticeboard as equally as the others aforelinked, and counterproductive to impede forward progress for the sake of obstruction; in my opinion at least.--John Cline (talk) 13:12, 29 March 2015 (UTC)

John Cline my experience of the reliable sources notice board is one is lucky if a conversation involves more than a handful of editors eg the last one I initiated:RN/N § Tudor Place -- PBS (talk) 15:53, 29 March 2015 (UTC)

The way RM works is that a template is placed in a section on the article's talk page. It is then listed by the bot onto the RM page (see WP:RM#Current discussions). People who like to participate in RMs are presented with a current list to watch, while those who are interested in the article will be watching the talk page, so it encourages more input from both those interested in the issue in general and by those interested in the article. RM is similar to that of an RfC in that discussions are not centralised but placed on the article's talk page. I am not suggesting using either RM or RfC, for this proposal, but the RM model is I think superior to that of the notice board as the conversation is kept close to the subject of the conversation and it is easily available for future reference either on the talk page of the article or in its archives. -- PBS (talk) 15:53, 29 March 2015 (UTC)

I strongly agree with PBS that a RM model would provide an efficient way of providing a central point of reference to relevant discussion some of which might even be located on the talk page of the same project page. Perhap it is relevant to note that issues of style in wiki are something that go beyond Wikipedia. I would be interested if an RM model could be extended to cover content such as commons. I wouldn't be surprised if there may be plenty of commons and other editors who would appreciate the existence of this type of notice board, either of a form that just covered Wikipedia or that worked across projects. GregKaye 16:19, 29 March 2015 (UTC)

An "RM" model defeats the purpose of this proposal. An "RM" is about a request for a change to a specific article. This noticeboard is about requesting third opinions on the interpretation of style guidance in a neutral space away from a dispute. The whole purpose of this noticeboard is to avoid the "closeness" you are speaking about, as it is that closeness which leads to disputes. Please note that the proposed noticeboard, WP:SNB, requires that a link to the noticeboard discussion be placed on the relevant article talk pages. All editors will be informed. RGloucester — ☎ 16:57, 29 March 2015 (UTC)

RGloucester , the "neutral space away from a dispute" idea gives me the heebee jeebees as I think that this could be used in behaviours like forum shopping. The RM format might simply state the nature of the discussion with indication being given to the location of the discussion. GregKaye 13:09, 30 March 2015 (UTC)

Right now, people come to the MoS talk page asking, "Should I hyphenate this? Where?" "Should I capitalize this or use lowercase?" "Does the MoS have a rule about this?" Here are some examples: [10] [11] [12] I'm guessing that this noticeboard would be for people with these questions. Frankly, I don't mind answering them at WT:MoS (though Wavelength usually beats me to it, heh) but a noticeboard like the RSN and V boards would probably be easier for people to find. RG, Blueboar, other proponents, is this what you mean the noticeboard to do? Darkfrog24 (talk) 18:17, 29 March 2015 (UTC)

That's correct. Instead of having discussion scattered across WT:MOSNUM, WT:MOS, MOS:BIO, &c., have one centralised noticeboard for asking such questions as these. RGloucester — ☎ 18:48, 29 March 2015 (UTC)

Ecactly. Blueboar (talk) 00:31, 30 March 2015 (UTC)

• @Neutrality: No one is suggesting a depreciation of talk pages. However, many and most talk pages have few watchers, if any. It is also true that disputes often require third opinions if they are to be resolved. Talk page discussion is always the first step, but what is the next step? That should be the style noticeboard, which would provide a neutral space watched by many editors for specific style questions, just as RS/N does. RS/N does not supplant talk page discussion, and neither would this noticeboard. As it is, people are already seeking advice across many guideline and policy talk pages, as mentioned above. The noticeboard would provide a transparent and strictly defined space for people asking for such advice. RGloucester — ☎ 00:06, 30 March 2015 (UTC)
  • The "next step" would be a RFC, or a note on the relevant Wikiproject, or Wikipedia:Third opinion. I disagree with creating yet another process when we already have multiple processes. Duplication is, all other things being equal, a bad thing. Neutrality^talk 04:01, 30 March 2015 (UTC)

RfCs last thirty days, and are not useful for answering quick style-related questions. Wikiprojects can be useful, but do not provide a structured and quick format for answering such questions, and are inherently non-neutral spaces. 3O, once again, is not structured to help with the specific problem that this noticeboard is trying to solve. This proposal is for something more like the reference desk or help desk, not a request system for direction intervention in the article in question. It simply an attempt to centralise discussions that are already occurring in outlying MoS pages. RGloucester — ☎ 04:17, 30 March 2015 (UTC)

• @Dicklyon: It is very odd that you think that I "hate" the MoS, given that I spend most of my content work time on copyediting and enforcing MoS recommendations in various articles. This proposal will obviously not reduce the "impact" of the "MoS". Nothing could "reduce its impact" other than a stripping of guideline status, which no one in his right mind would even consider. The purpose of this noticeboard is to ensure that the MoS is clear, and that its prescriptions are followed. However, I think there is a fundamental problem, and that's that you are interpreting "MoS" to mean a group of editors who support your interpretation of the MoS. The proposed noticeboard sits in a neutral space. It must be in such a neutral space, or else it will loose credibility to petty squabbles amongst different factions. Disputes about style rage across the encylopaedia, and have done since time immemorial — the response to these disputes is not to continue with such attacks as the one you've written into your "oppose" comment. The goal of this noticeboard is serve as a reference desk for style questions, nothing more. Wikipedia policy and guidelines do not change because of this proposal. It will merely be easier for editors to access the MoS, which is a dense document spread out over tens of pages. RGloucester — ☎ 06:54, 1 April 2015 (UTC)

The best way to ensure that your voice is heard is to support the formation of the noticeboard and provide answers to the questions of those seeking them, not to squelch the proposal for the sake of vengeance. I can assure you that I will not be answering questions at WP:SNB if it is formed, as I recognise that my name is tainted. RGloucester — ☎ 06:57, 1 April 2015 (UTC)

Volunteers are obviously needed

Without volunteers watching this page; prepared to respond, this noticeboard cannot be the resource envisioned. For those so comprised, please consider adding Wikipedia:Style noticeboard to your watchlist now, and let's hope to see more than thirty who are willing[13] Thank you.--John Cline (talk) 09:15, 29 March 2015 (UTC)

• Done. I plan to participate if this proposal carries. Darkfrog24 (talk) 18:19, 29 March 2015 (UTC)
• I added it my watchlist and will help where I can. - MrX 21:31, 29 March 2015 (UTC)
• On-board. Mlpearc (open channel) 21:53, 29 March 2015 (UTC)
• +1 lurker. ―Mandruss ☎ 05:47, 30 March 2015 (UTC)
• Sounds like fun and an opportunity to help people and help make the writing on Wikipedia better.  SchreiberBike | ⌨  22:33, 1 April 2015 (UTC)
• On my watchlist. Lemme know how I can help. Atsme☯^Consult 00:05, 3 April 2015 (UTC)
• +1 (for several days already, but making it 'official'). --Iryna Harpy (talk) 21:57, 5 April 2015 (UTC)

It is usually easy to get a bunch of people to sign up for such a list, but it in no way guarantees that there will actually be broad particpation. Many inactive, half-dead WikiProjects have membership lists with dozens of names on them. Beeblebrox (talk) 21:57, 12 April 2015 (UTC)

Well for my own part, I already do my bit answering questions at WT:MoS. It would be nice to have a clearer and more organized place to do it, but a few of the people here, like SchreiberBike, already have multi-year track records. Darkfrog24 (talk) 17:20, 13 April 2015 (UTC)

What this board would actually do

I was against this idea at first, but then I got confirmation about what it actually is.

Right now, people already come to WT:MoS with questions like "Does Wikipedia have a policy about this?" "Another editor is doing X; is that against the rules?" "Why did so-and-so revert my changes?" "What's the right way to present this word in this variety of English?" While we've been having this conversation, two such individuals have raised such issues at WT:MoS. [14] [15]

So if you're concerned about drama... 1) You'll notice that their questions were answered clearly, briefly and without debate or argument. This is typical. 2) They're asking about things like whether "modeling" has one L or two; making the MoS shorter wouldn't help with that. 3) The demand for a noticeboard isn't coming from MoS regulars and style experts; it's meant to serve the demonstrated needs of those who wish to consult MoS regulars and style experts. This is about replacing an unofficial system with an official one, using a format that we've already seen to be effective on WP:RSN and WP:NPOVN. 4) It's the threads about changes to the MoS that tend to get everyone's back up, and the noticeboard would not be dealing with those. Darkfrog24 (talk) 14:04, 4 April 2015 (UTC)

Does this even need community approval?

Since it doesn't sound like this board will actually have any special powers, I'm not sure that its creation needs community approval. It's essentially just a WikiProject for MoS discussion. So anyone should feel free to start one if they so desire. The more interesting question is probably whether it will have enough active users to stay alive. Samsara 02:38, 9 April 2015 (UTC)

Of course it requires community approval, as it will not be a "WikiProject", but a noticeboard under WP:PNB. The community must decide whether it wants such a noticeboard. If the board doesn't have community consensus, it won't be able to function effectively. RGloucester — ☎ 02:41, 9 April 2015 (UTC)

Okay, well, that's the kind of statement that makes me suspicious of the direction you want to take with this. It seems to me that if there is really a need for this, it could be run at a lower level of privilege and then promoted once it's proven to have traction. Forcibly injecting it as a new cog into a working machine, well, let's just say it's not to everyone's taste. Samsara 03:08, 9 April 2015 (UTC)

I understand your concern, but I simply don't think it would be appropriate to start something like this without having the community behind it. You can look at my mock-up, at WP:STEIN. It is ready to go, and I could've just started it up the bat. However, I really don't think that's appropriate. As you can see, there is opposition, though I think most of the opposition is misguided. Not having consensus may result in a certain sabotage, I imagine. RGloucester — ☎ 03:37, 9 April 2015 (UTC)

Actually, most of the issues we'd address wouldn't require the formation of any new consensus. All three of the people who've asked style questions during the time we've had this discussion have had straightforward "This is what the rule is"/"This is the policy you were thinking of"/"Here's the page you want" answers. The only way I see the noticeboard needing to form any consensus would be if there were a question of how to interpret a rule to fit a specific case. We've gotten a few of those in the past.

RG, she's got a point. Now that the discussion's ongoing, we should abide by the outcome, but you or Blueboar could have just done it and then taken it down if a consensus ever formed against it. That is allowed. Darkfrog24 (talk) 05:10, 9 April 2015 (UTC)

Whether it is "allowed" or not is irrelevant. It is wrong, and flies in the face of the basis of this encylopaedia, which is WP:CONSENSUS. If the community doesn't want a noticeboard, it won't get one. If it does want one, it will. One cannot just circumvent the usual processes because one feels one knows better than everyone else. That would be atrocious behaviour. I do not want any changes to Wikipedia policies or processes that have not attained consensus. They are recipes for disaster, and result in the likes of the Esperanza debacle. RGloucester — ☎ 05:14, 9 April 2015 (UTC)

Actually WP:BOLD is as much a part of the basis of Wikipedia as consensus is. It is the usual process. You actually did something unusual by asking permission first. Darkfrog24 (talk) 05:19, 9 April 2015 (UTC)

"Bold" applies to editing articles. It does not apply to Wikipedia processes. I can't start a new process called "requests for such and such" merely because I want to. Such a process requires consensus of the community. That's how it works with all community processes, otherwise we'd end up with tons of parallel and competing structures. The usual process for establishing community procedures is discussion at the village pump. RGloucester — ☎ 05:49, 9 April 2015 (UTC)

• Oh goody: a meta-meta-debate on the process by which the framework for the process for debating the forum for discussing style should be discussed is determined. Decided. I think. EEng (talk) 16:51, 9 April 2015 (UTC)

Such a board likely would need community support and consensus. Stating BOLD as a justification for such a significant is possibly stretching its meaning a bit. In any case getting consensus is the best path as it raises awareness of the project and precludes any future questions over the legitimacy of the project.Trout71 (talk) 01:50, 11 April 2015 (UTC)

Apparently the first item of business at this new board will need to be a discussion of its vs. it's. ;-) EEng (talk) 12:39, 11 April 2015 (UTC)

If you don't like it, you don't have to help. Darkfrog24 (talk) 23:33, 11 April 2015 (UTC)

If you don't like the joke, you don't have to laugh. EEng (talk) 23:56, 11 April 2015 (UTC)

Apologies user:EEng for a minor mistake which you clearly felt it necessary to point out. I am assuming your motive was petty, like your action. In any case I doubt that you are an expert on grammar. After a few seconds on your page I was simply horrified by the false apposition and the sundry other mistakes that are tell-tale signs of someone trying to use constructions and language that he doesn't really understand.Trout71 (talk) 23:00, 12 April 2015 (UTC)

You don't have to be a grammar expert to find amusement in an its/it's mixup during a discussion of a proposed Style Noticeboard, though you do have to take yourself very seriously to be offended by a goodnatured ribbing – particularly one tagged by ;-).

In any case if my userpage exhibits false apposition (or other offenses tsk-tsked in your 19th-century grammar) please boldly correct it for me. I don't mind having my errors pointed out, whether for humor or enlightenment. EEng (talk) 01:17, 13 April 2015 (UTC)

Right this conversation is geting really interesting... No you don't have to be a grammar expert to find that funny, but you do have to have a lot of time on your hands coupled with a lack of any constructive activities to partake in. Anyway we'll have to disagree on our tastes in humour. I appreciate humour which is funny, you obviously appreciate whatever you call that stuff above. Do I even need to bother pointing out the irony in you accusing me of 19th century19th-century grammar? And you may be bold yourself and correct your own page, if you can.Trout71 (talk) 17:20, 15 April 2015 (UTC)

I'm afraid the irony escapes me‍—‌please explain. The invitation to correct any errors on my userpage stands; in reciprocation I've taken the liberty (subject to your approval) of correcting your 19th century (above) to 19th-century, though if you'd rather it remain wrong please change it back and accept my apologies. (I've left the comma splice, run-ons, misspelling, and other illiteracy for you to handle yourself.) EEng (talk) 21:44, 16 April 2015 (UTC)

If the irony escapes you I suggest you attempt to read your own user page and then return here and accuse me of 19th century grammar. Above you have accused me of breaking a rule of grammar that is both defunct in this context and also rather obscure in general. A hyphen is needed when there is an opportunity for confusion as to which words are associated. Unless one is a bit stupid one will realise that the words 19th and century are associated and that together they act as an adjective for the word grammar. While the hyphen is useful, it is not necessary in this example and is not often used any more. I concede the spelling mistake, but your other points without exception are either irrelevant or incorrect. Run-on lines are hardly bad grammar and are often used in poetry. It can be observed that I use them here to express exasperation. I disagree with your accusation of the comma splice. As for your kind invitation I reiterate my declining of it. It's your user page and it's your business to correct it. I am not a lout who feels the need to alter another persons writing, even if I think it's incorrect. It is his right to alter it if he chooses to. Look I'll be nice to you now. I realise at this point that you have little to be doing with your time other than pointing out insignificant or theoretical grammar mistakes. The mistakes you typically note do not impair the quality of the text. So for your pleasure I have included a grammar "mistake", I have used a proposition to finish a sentence with. Twice. That must be like Christmas and Easter rolled into one for the man would probably scold Shakespeare for bad grammar. With love Trout71 (talk) 17:19, 17 April 2015 (UTC)

I have used a proposition to finish a sentence with. Oh, dear. EEng (talk) 21:13, 17 April 2015 (UTC)

EEng?? Trout71 (talk) 21:31, 17 April 2015 (UTC)

You rang? EEng (talk) 21:59, 17 April 2015 (UTC)

You've been trouted.p Trout71 (talk) 22:04, 17 April 2015 (UTC)

So you have a sense of humor after all. P EEng (talk) 22:34, 17 April 2015 (UTC)

EEng, there's a chap outside who wants you to sign for this industrial sized pot and a couple of high-grade titanium stirrers..... Ritchie333 ^{(talk) (cont)} 08:40, 18 April 2015 (UTC)

Industrial-sized needs a hyphen. P P P P EEng (talk) 12:02, 18 April 2015 (UTC) Thanks for the caption, BTW. Perfect.

• You could start the WP:Style Help desk with little to no community consensus, just some volunteers interested in answering questions. Which under my reading of the proposal is what is being proposed. You would need consensus for a true noticeboard, where issues are taken, and a resolution is reached through consensus there, possibly over the objection of one of the parties. Monty₈₄₅ 01:59, 11 April 2015 (UTC)

Eh, a noticeboard sounds better to me but as long as the new guys have a place to go that they can actually find. Darkfrog24 (talk) 23:33, 11 April 2015 (UTC)

• You can't have the B without the R and the D, so we would end up here (or somewhere) anyway. RGloucester's tack seems the correct one. ―Mandruss ☎ 12:49, 11 April 2015 (UTC)

The fringe theories noticeboard is an example of BRD-like creation. It was boldy created, sent to MfD within a few days, discussion ensued, and it was kept. That whole thing took less than half the time and far fewer words than this discussion has required, by the way. Orange Suede Sofa (talk) 23:54, 11 April 2015 (UTC)

• While I am firmly opposed to yet another drama board for this purpose, I would fully support a simple help desk. If it was strictly to help find relevant guidance from the MOS and explicitly not for any kind of dispute resolution I don't see a problem. Beeblebrox (talk) 19:00, 13 April 2015 (UTC)

I'm not clear on what the difference would be. The kinds of questions we're talking about would be the same, and would have the same answers. For example, while this discussion has been taking place, three or four people have asked questions at WT:MoS: spelling/ENGVAR organization definite articles. Darkfrog24 (talk) 01:22, 14 April 2015 (UTC)

It is apparent to me that many of the people above have not read WP:PNB. This noticeboard is meant to be established in the model of WP:PNB. I don't know why you think it has anything to do with "dispute resolution", though it may inadvertently resolve some disputes. RGloucester — ☎ 01:36, 14 April 2015 (UTC)

Halftime report

This RfC is about halfway through, and it seems like one of those RfCs that might not get closed for a month, so I'm offering to close. (As always, speak up if you object.) One thing I'm not seeing that I think would be helpful would be more discussion of the general case: what happens on WP when some people are already doing something, and others believe that their process isn't visible enough or doesn't provide the best answers, so they set up another page to try to do it better? This strikes me as territory that's already well-covered by our policies and practices (but I don't want to inject my own views, of course). - Dank (push to talk) 18:29, 14 April 2015 (UTC)

Orange Suede Sofa cited the WP:Fringe theories noticeboard. It seems to be working out. Darkfrog24 (talk) 18:54, 14 April 2015 (UTC)

That's part of the reason why the opposition baffles me. This noticeboard would be ten times more transparent (something many of them seem to want) than the existing mess, would allow easier access for users looking for assistance, and is based in a common community standard, the WP:PNB. RGloucester — ☎ 19:19, 14 April 2015 (UTC)

When I have my closer hat on, I'm just a mid-level drone with experience in applying policy and judging consensus; you guys are the ones who will have to figure out how to proceed. When I close, I'll try to sum up some of the arguments, but for the moment, I want to talk about policy. It's better for voters to discuss how policy does or doesn't apply, but apart from mentions of WP:NOTFORUM and SHOPPING (and Izno's link to IAR) ... correct me if I'm wrong ... that didn't happen here. I've got some suggestions for how policy might apply, but we've still got a week to go before the 30 days are up; feel free to correct me or suggest other policies. So: since SHOPPING is well-established policy, it's a bad idea to create a new page that is likely to produce a stream of people asking the same question on two pages in hopes of getting the answer they want. Note that it's a good start but not sufficient to define what a new noticeboard is supposed to handle: if the likely or actual result is a lot of SHOPPING violations, that's a problem, no matter how explicit you were when you set it up and no matter who's at fault. OTOH, if we're talking about some new page that succeeds in doing something useful that isn't being done elsewhere, then policy as a whole pushes in the other direction, for instance per WP:IAR and WP:OWN. An analogy: suppose Wikiproject Widgets has never shown any real interest in widget law, but Wikiproject Law has, and now WP:LAW has just set up a task force on widget law. WIDGETS objects strongly to the existence of the task force and begins arguing with them over multiple pages. IAR and OWN put limits on how successful WIDGETS can be in stopping someone else from doing something that the WIDGETS guys weren't doing and weren't likely to start doing, even if they have an argument that, since it concerns widgets, they'd be better at it. - Dank (push to talk) 21:37, 20 April 2015 (UTC)

Point of clarification: if people asking a question in the wrong place are politely and consistently directed to the right place, that's only inefficient, not a big problem. The problem I'm talking about above would be anything that leads to a serious uptick in SHOPPING. - Dank (push to talk) 01:12, 21 April 2015 (UTC)

It sounds like you don't think there should be a style noticeboard because you think the community's needs are already being met at WT:MoS. Here's the issue, then: are people being directed to WT:MoS? Do the new guys give up before anyone can direct them there? Do other Wikieditors know they're supposed to direct people there? These things by definition don't leave a trail, but my guesses based on my own experience are "yes" and "no."

It also sounds like you think that the creation of this board is likely to result in forum shopping. This question can be answered: One of the arguments against this board has been "people will forum shop," but one of the arguments in favor has been "right now, questions are scattered across too many different talk pages." Given that lots of MoS pages have overlapping content, it sounds like there is plenty of opportunity for forum shopping already. I tend to spend my time on the main MoS talk page, but could someone who frequents multiple pages tell us, is forum shopping for style issues a problem now? Does someone get an answer at WT:MOS and then hop over to WT:MOSCAPS or WT:MOSDATE to get a different one? If this is not something that people with style questions tend to do, then it is not something we should treat as likely. Darkfrog24 (talk) 19:15, 21 April 2015 (UTC)

It sounds like you don't think there should be a style noticeboard [Darkfrog24]

I'm sure that I don't have an opinion on whether we should have some kind of style noticeboard. If I did, I wouldn't have signed on. - Dank (push to talk)

because you think the community's needs are already being met at WT:MoS.

Language is IMO one of the hardest subjects we tackle on WP. I don't think it's possible to meet everyone's needs with the current resources.- Dank (push to talk)

You're losing me ... which is the problem I'm generally having with this RfC, I'm not clear on what we're trying to create here (possibly because we don't have a consensus answer yet, which is fine ... hopefully we'll get there). Are you saying that WT:MOS functions in part as a noticeboard, except it's not attracting enough attention? Are you saying that, without making any changes to what happens at WT:MOS, you'd like to create a second noticeboard, because that will attract more attention? If so, are there any other pages on Wikipedia that serve as noticeboards where you see a benefit to setting up a second noticeboard to handle the same sorts of questions? I don't think I'm following you. - Dank (push to talk) 20:51, 21 April 2015 (UTC)

What we are proposing is a noticeboard, which is well described at Wikipedia:Noticeboards. Asking questions on the talk page of the style guide is discouraged. It says at the top, in bold, "This is the talk page for discussing improvements to the Manual of Style page" and presumably not for anything else. People sometimes ask anyway, but that notice turned me away from asking when I was a newbie and I suspect it turns away others. Also the style guide is spread over dozens of pages (see Wikipedia:Manual of Style/Contents) and many of those pages are seldom watched. So, sometimes the Manual of Style talk page does serve as a noticeboard, but it doesn't do it well, and there is no place where people are encouraged to ask questions about the way to write for Wikipedia.  SchreiberBike | ⌨  21:16, 21 April 2015 (UTC)

Yes, that's it exactly. WT:MoS has been serving as an unofficial noticeboard for years and not enough people know about it. Yes, we want to create a noticeboard because Wikipedia's existing structure funnels editors with questions to noticeboards and not to WT:MoS. Yes, the quality of the answers that people receive at WT:MoS is very high. No, those discussions don't usually lead to drama. Yes, we want to do the exact same thing but on a noticeboard. I don't know if there are other talk pages that are also unofficial help desks—my area of expertise is writing and style—but I guess a noticeboard might be easier to find in those cases too.

Most of these things have already been covered in this conversation. Here are the highlights: 1) I ask what this board is intended to do and RG and Blueboar answer: [16] [17]; 2) There's even a section called What this board would actually do in this discussion, 3) Mandruss points out that even the text at the top of the Village pump (policy) says, "if you need help, go to a noticeboard." [18]; 4) A lot of the supporters are saying, "This is a good idea because questions about how to apply style don't belong on the talk pages"; 5) A lot of supporters are saying "a noticeboard would be easier to find than a talk page." The first link and "What this board would do" section contain links to examples of questions that people have asked at WT:MoS. Darkfrog24 (talk) 21:14, 21 April 2015 (UTC)

Dank, I'm not 100% sure what you're asking for with "second noticeboard," but I think I might have an example in reverse: You know how we have a reliable sources noticeboard even though WP:RS has a perfectly good talk page, an NPOV noticeboard even thought WP:NPOV has a perfectly good talk page, and so on? Same idea. Not all policy pages have their own noticeboard—WP:CANVASSING doesn't—but it also doesn't get that many questions about how to apply the rule. WT:MoS and its subordinate talk pages do get a lot of questions about how to apply their rules. So if by "set up a second noticeboard" you mean "establish a noticeboard so that people can ask questions there instead of on the talk pages," there are several cases in which that's already been done. Darkfrog24 (talk) 22:22, 21 April 2015 (UTC)

Okay, so you know my main concern now; I'll unwatch for the time being. Another analogy: suppose that, unexpectedly, we find out that there have been two pages for a while that have both been claiming to be the noticeboard for BLP. Different WPians would probably try to resolve this in different ways (and I'm not passing judgment on the best way to resolve conflicts on WP, particularly when it comes to language. Do whatever works for you.) Some would take a legalistic approach, along the lines of: you're ordered to cease and desist, the other board got here first, or is more active, or something. Some would take a more people-centered approach, and ask the regulars at both boards if they were aware of the other board, and if so, why they chose to post where they posted ... is there something about that page that works better for them? Is there something they need before they'd be comfortable consolidating the boards? Suppose I close this RfC next week and say "Because of the superior arguments of the minority, I decree that there shall henceforth be a MOS Noticeboard on Wikipedia." Some people would laugh at me, then try to remove the new noticeboard. If for some reason they weren't successful, then they could try to get it removed by legal means, such as an appeal to overturn the close, or they might try a more people-centered approach, asking regular posters to WT:MOS why they were comfortable asking their questions there and making replies there, and whether it would work better for them if they moved the more noticeboard-y stuff to an actual noticeboard, and if so, how we would be able to tell the difference between talk page stuff and noticeboard stuff. That would be quite a long process, and they'd be likely to get a wide range of responses, requiring a lot of conflict resolution. I haven't seen evidence of even a start on that process yet, but maybe I've missed it. Until that process reached a resolution (if ever), we'd have, in effect, two MOS noticeboards. (And to be clear, SHOPPING is just one of many policy problems people have noticed when we try to do the same thing in two different places. There are a range of reasons we don't try to cover the same territory with two wikiprojects, two talk pages, two noticeboards, etc.) - Dank (push to talk) 16:14, 22 April 2015 (UTC)

We have that problem now: Talk pages of MoS subpages that have overlapping content. The noticeboard is meant to fix this problem by providing one official place for writing questions instead of several unofficial ones.

I'm not sure what you're getting at with most of your post. You seem to be describing a hypothetical scenario. The idea as I see it is that, after the noticeboard is established, anyone who asks a style question at one of the talk pages is told, "We have a noticeboard for that; here's the link." The worst likely scenario at WT: MoS is that someone answers their question there anyway and the noticeboard gets less use than it should.

If you haven't already, you should look at WT:MoS or to any of the example links I've given. Look at the style questions that people ask there and at the answers they get. Do you think the problems you're describing are likely with questions like these? There's a lot less gray area with this than with RS or OR or NPOV. Darkfrog24 (talk) 19:19, 22 April 2015 (UTC)

@Dank: Should this proposal fail, I imagine there will be a discussion on WT:MOS about encouraging and explicitly allowing style questions on the MOS talk page. I think many will object to it because making decisions about what the MoS should say is challenging enough and it is a waste of editors' time to answer questions about what it does say. I can imagine problems for this board, but I can imagine almost anything. Personally I grew up hating grammar and writing because I am dyslexic. I have worked very hard to be a competent writer and to follow the rules I can understand. Honestly, I'm not sure what a preposition is, but I can direct people to MOS:CT so they can figure out which words to capitalize in a title and avoid future arguments.  SchreiberBike | ⌨  19:56, 22 April 2015 (UTC)

I have a problem with the "should vs does" say argument you're making, and that is that the people who know what it does say are the same as those who argue about what it should say. Additionally, a large number of them above have "signed on" to man this noticeboard. So the claim that questions at WT:MOS are causing them to waste their time does not seem to be true. --Izno (talk) 16:52, 26 April 2015 (UTC)

Yes, but those same people handle the "should" and "does" questions differently.

Case in point: The MoS has a rule called WP:LQ. I despise that rule for reasons that I will list here if anyone thinks it's relevant. I'm quite possibly its #1 non-fan. WP:LQ is one of the most, if not the most, frequently challenged parts of the MoS, and every time someone says, "We should change that rule," I'm right there saying "Yes! Here's why and how and evidence and precedent and what to change it to!" However, when a guy came to WT:MoS asking, "What is Wikipedia's rule on the placement of periods and commas with quotation marks?" even I said "It's WP:LQ. You might know it better as the British system. Here's how to do it correctly." Darkfrog24 (talk) 21:09, 26 April 2015 (UTC)

I'm not sure it's an issue that those same people handle the should and does questions differently. I would imagine them to be different kinds of answers, just as you're illustrating yourself. That they happen on the same talk page does not provide evidence that a new noticeboard is needed. (But I digress. I did not pop into this spot in the discussion except to point out what seems to be an illogical argument and I myself did not advance any new ideas.) --Izno (talk) 23:37, 26 April 2015 (UTC)

@Izno: I think you are right that a large number of people want to help on this new board, but as others have observed, some of the people active on WT:MOS seem to enjoy a good argument and may have no interest in helping newbies. I also know that there are excellent writers who have zero interest in the sometimes contentious discussions at WT:MOS, but I hope some of them will want to work with people who are asking for assistance.  SchreiberBike | ⌨  22:26, 26 April 2015 (UTC)

Your response does not seem to answer my original one, so I'll take it as granted that you neither disagree with me nor fail to see fault with that part of comment.

Regarding those people who have no interest in helping newbies, do they actually exist? If they do, where's the evidence? Why aren't those excellent writers simply watching WT:MOS? They don't need to get involved in actual change discussion (which I agree, it is sometimes driven by a handful of editors trying to beat each other with sticks). --Izno (talk) 23:37, 26 April 2015 (UTC)

Oh, I see. I thought you were worried that the MoS regulars would be too busy dueling to help the askers, and I was offering a clear case in which that could have happened but didn't.

The noticeboard is needed not because people who ask questions at WT:MoS don't get good answers—they do—and it's not because these questions disrupt business there—in my opinion, they don't. It's needed because not enough newbs know that WT:MoS is the place to go for questions. Wikipedia's existing structure funnels them to noticeboards (and the talk pages explicitly say not to ask help questions there). It's about making help easier to find and Wikipedia's instructions less contradictory. Darkfrog24 (talk) 00:17, 27 April 2015 (UTC)

Deciding what the MoS should say is a different thing from explaining what it does say. Such things appeal to different people. You are correct that I don't know the thoughts of others or how this noticeboard will actually be used, but I am making an educated guess as a regular watcher of, and occasional contributor to, MoS discussions. I am also someone who looked for a place to ask questions and found that there was none. I think trying to make WT:MOS such a place would be controversial.  SchreiberBike | ⌨  01:03, 27 April 2015 (UTC)

Sorry for the delay; I'll be closing this within a day or two. I prefer to write short closing statements, and figuring out what to say and what not to say is hard. - Dank (push to talk) 14:01, 1 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.

Precedent for precedent's sake

As you can see at Wikipedia:Articles for deletion/Abhay Vidhya Mandir Senior Secondary School, Hindaun City there are 2(3 if the speedy counts) votes for delete, one vote for keep, and two for keep because of precedent.

I'm proposing we drop the idea of precedent for precedent's sake.

A school existing should not be a reason to have an article on it. It should have to be notable, just like everything else on here. This seems like a really strange exception to me. While I understand precedent, I feel that it should only ever be used to end something quickly, or if there is no consensus reached. Right now when the AfD closes it would be deleted if not for the votes for precedent. If on the other hand there was no consensus then the closing admin could use precedent to close as keep. In the legal system a judge uses precedent as a guide, not a rule. We should do the same here. Jerodlycett (talk) 04:19, 30 March 2015 (UTC)

I'm no expert, but it seems to be that the whole argument from prededent is really a short-hand way of saying "the factors that are relevant to the current matter have been debated before, and come to a satisfactory conclusion, so there is no reason to expect a different conclusion this time." And that's fine if the old and new matters are the same, but there are always differences. By analogy to the legal situation, I believe it is better treated as persuasive precedent, not as binding precedent. Look at the old case, and decide what, if anything, from that discussion is pertinent to the current. It may or may not lead to the same decision.--Gronk Oz (talk) 05:34, 30 March 2015 (UTC)

Thank you for the comment. Jerodlycett (talk) 14:30, 30 March 2015 (UTC)

• False premise, cannot oppose or support: "Precedent," except in the form of very recent consensus or policy or guidelines, does not exist here. Indeed, the concept of it not existing is enthroned at Wikipedia:Arguments to avoid in deletion discussions#What about article x? An argument at AfD citing "precedent" is, really, an argument that the outcome is a common outcome, see Wikipedia:Articles_for_deletion/Common_outcomes#Schools. In short, it's an argument that "though in theory these can be deleted for lack of sources, as a practical matter these never get enough "delete" !votes to actually be deleted so this is a waste of time". The "rules," namely NHSCHOOL, are clear that schools have to establish notability through multiple sources, but there is sometimes a disconnect between what the notability guidelines say and what actually happens in deletion discussions. That's okay, of course, because consensus can change, both generally and on a case by case local exception basis. The point that should be made in the AfD discussion is that there is no such thing as precedent and "usual outcome" is not a substantial argument for retention. Regards, TransporterMan (TALK) 14:11, 30 March 2015 (UTC)

There are two arguments on the example I gave that state precisely that precedent is the reason for keeping. I don't know if the solution is a huge banner on common outcomes or on AfD stating that, but it's irritating to think that the article would have otherwise reached consensus and been deleted, but due to votes of precedent it may not be. The reason I put out an RFC is to try to get comments on this matter mainly, not necessarily votes, so thank you. Jerodlycett (talk) 14:30, 30 March 2015 (UTC)

• Agree with TransporterMan. Precedent means nothing at Wikipedia, every single discussion should be decided on its own merits, based on consensus-based discussions in accordance with Wikipedia's core principles. All discussions stand on their own. That does not stop people from making bad arguments based on existing "precedent", but that doesn't mean we have to give those arguments any weight. --Jayron32 14:16, 30 March 2015 (UTC)

If this is true, then the article should close as delete per the consensus set there, correct? I'm not willing to make the bet that it will be. Thank you for your comment. Jerodlycett (talk) 14:30, 30 March 2015 (UTC)

No, consensus is assessed by the weight of the arguments. Admins are free to (and encouraged to) ignore arguments which are based on unsound principles or spurious rationales. --Jayron32 02:43, 2 April 2015 (UTC)

• I also can neither support nor oppose because the practice of precedent for precedent's sake is not occurring, per se. WP:SCHOOLOUTCOMES is based on prior discussions which have often led to a common result, and the common result is that schools of a certain level are almost always eventually found to be notable according to WP:ORG, unless they don't actually exist. However, each case is evaluated in isolation; one school isn't notable because another one is, and there is no inherent notability for any school. This is better described at WP:WPSCH/AG#N. Ivanvector (talk) 16:14, 30 March 2015 (UTC)

I'm not sure what you mean that it isn't happening, as it is. Even an administrator is doing so. Thank you for the comment. Jerodlycett (talk) 17:40, 30 March 2015 (UTC)

What I mean is that there is a better justification for this practice than simply "precedent" or "we've always done it this way". Ivanvector (talk) 20:13, 30 March 2015 (UTC)

I have seen many !votes at school AFDs that are simply invocations of precedent. The ones that bother me most are the editors who invoke precedent to delete articles about elementary schools that easily comply with both ORG and GNG. WhatamIdoing (talk) 16:47, 9 April 2015 (UTC)

• As far as "precedent" boils down to "essay" trying to outsmart a "guideline" ignoring the "essay" as it recommends at its top might be good enoough. Deleting the essay as nevertheless misleading and not helpful might be better. What exactly do you propose here? I'm tempted to add support, but I'm not sure what I'd support. –Be..anyone (talk) 16:51, 30 March 2015 (UTC)

It seems the problem isn't exactly what I thought it was, so I'm waiting on more input to see. I'm beginning to think you have the best solution for what seems to be the exact problem, that essay. Thanks for the comment. Jerodlycett (talk) 17:40, 30 March 2015 (UTC)

This particular schools a borderline case. We should;t use such cases to change established statements of practice, or we will have no stability at all, and no basis for consistent decisions. We can;t be expected to be perfectly consistent, but we should at least try. DGG ( talk ) 19:48, 30 March 2015 (UTC)

"A foolish consistency is the hobgoblin of little minds." We should strive not for consistency, but propriety. We do what is proper to the specific situation, not what has been done in other situations merely because of some random points of coincidence. --Jayron32 02:46, 2 April 2015 (UTC)

Note that word foolish in the quotation. A wise consistency is the hallmark of seriousness & intelligence. A foolish inconsistency is the hallmark of using no mind at all. The WP policy that avoids foolish consistency is IAR, but IAR is intend for the exceptions, not the general run of things. Newcomers are entitled to learn from reading our guidelines what they are supposed to do. Trying to build an encycopedia without consistency produces of hodgepodge of miscellaneous internet pages. Encyclopedias are by definition organized knowledge. DGG ( talk ) 18:58, 7 April 2015 (UTC)

Consistency is an accidental biproduct of propriety, and never a goal unto itself. Doing the proper thing will lead to similar results in many situations, but that doesn't mean that should be the goal. When consistency is valued as an end to itself, that is a problem. That our results end up consistent is a happy coincidence, and the outward sign that we're probably doing the right thing, but we don't let consistency be the driving force behind our decision making. It is that thinking that makes it foolish. Wise consistencies aren't planned first as consistencies. They are merely wise. --Jayron32 02:33, 12 April 2015 (UTC)

Proposal after comments

Thank you who left comments assisting in this. My proposal is now as follows.

I propose deletion, or rewrite to indicate use only for assistance when no consensus is found, of WP:OUTCOMES.

It is being quoted as the reason to keep a subject that isn't notable on its own. While I gave one example above of it being used that way, and the results from it, you can see the discussion at WikiProject Christianity which shows it is considered a guideline, not an essay. Jerodlycett (talk) 03:55, 2 April 2015 (UTC)

• Comment: I think the page itself, in its lead and first section, already does that well enough. Also, I think what you’re desiring is for precedent itself to be considered irrelevant in such cases, rather than this page that attempts to document it. As for WT:XNB, I see only that it’s considered a relevant page in the context of that discussion. —174.141.182.82 (talk) 02:32, 4 April 2015 (UTC)
• Support, this wannabe-essay trying to overrule guidelines not in the form of a WP:AFD subpage is harmful, intentionally misleading, and pointy. –Be..anyone (talk) 02:05, 5 April 2015 (UTC)
• Support marking WP:OUTCOMES with {{historical}}. It is a fantastically unhelpful page that hamstrings proper discussions of articles on their own merit. We should be discussing each article individually, not pointing at OUTCOMES and saying "Nope, can't delete it... precedent says we can't" We don't normally delete such pages, but we should tag it as historical and that it should not be used for resolving deletion discussions. --Jayron32 02:11, 5 April 2015 (UTC)
• Oppose I believe the example this proposal is based on is being misunderstood by the nominator. At a first level, schools are notable in the same way bridges and train stations are, as elements of infrastructure and public service - and we've included coverage of some very minor bridges and train stations. Motivation for this proposal seems to amount to WP:IDONTLIKE. Samsara 08:19, 5 April 2015 (UTC)
• Oppose Removing this will eliminate any sense of rationality. Discussing each article on its own merit will mean about 500 Afds a day,and we don;t have enough interest people to discuss properly even the 100 we do have. It will also result in an encycopedia where decisions are made not by the merits, but by chance occurrence of easy to find web links, and by the intensity of the people arguing. A reader should know whether or not they can expect to find churches or high schools or elementary schools, or what types of businesses or people they will find. DGG ( talk ) 19:02, 7 April 2015 (UTC)
• Oppose, DGG is right. OUTCOMES is just an essay, and like all essays can be referred to or ignored as the situation warrants. Schools are a somewhat unusual situation where notability is assumed to be inherent at high school level and above. Wikipedia doesn't like absolutes, but this particular precedent is useful as at one time years ago AFD was cluttered with lots of wildly inconsistent debates about schools, and it's far simpler to assume high schools are notable and move on. For what it's worth, precedent does exist--articles on human settlements and heads of state are essentially never deleted, for example. Andrew Lenahan - Starblind 02:42, 8 April 2015 (UTC)
  • Actually, no they aren't presumed notable. The actual guideline states otherwise, see WP:NHSCHOOL. Only the essay indicates they are notable, contradicting the guideline. I'm not trying to change your vote, just pointing that out. Jerod Lycett (talk) 08:54, 8 April 2015 (UTC)
    • Ok, but in actual practice, they really are. I've been following deletion debates here for over 10 years at this point, and the only high schools that get deleted are ones of such profound obscurity that it's difficult to prove they really exist. Nominating a random school is basically a waste of time. If you really feel strongly about it, the path forward would probably be proposing merging high schools with their school districts or equivalent community articles, as middle and elementary schools often are. Not something I'd support myself, but better than trying to delete a single random school. Andrew Lenahan - Starblind 12:59, 1 May 2015 (UTC)
• Comment Rather than deleting OUTCOMES, I like the idea of creating a simple template, similar to {{spa}}, that can be used to 'reply' to "Vote per OUTCOMES". It should say something like "Outcomes describes what happened to average articles, and is neither binding nor necessarily relevant to this particular one". WhatamIdoing (talk) 16:44, 9 April 2015 (UTC)
  • That would work for me. Jerod Lycett (talk) 18:07, 9 April 2015 (UTC)
    • Jerod Lycett (and anyone else who is interested), I have just created {{Outcomes}}. I'm sure it can be improved upon. WhatamIdoing (talk) 02:20, 22 April 2015 (UTC)
• Oppose - the essay is a handy documentation of the "usual" result for common types of articles that always come up at AfD. It's not policy and it doesn't try to be. Ivanvector (talk) 18:21, 15 April 2015 (UTC)
• Oppose If AfD was staffed by hundreds of careful researchers carefully analysing every article on its merits, I would agree with the proposal. But in real life, that's not what happens. Precedent provides useful guidelines and makes AfD run more efficiently. If people feel it shouldn't apply in some circumstance, they're free to argue why. --Colapeninsula (talk) 13:27, 20 April 2015 (UTC)
• Oppose - In my opinion entirely too much energy goes into deletion arguments. When general patterns emerge they indicate a rough community consensus and that is very valuable information which should be considered in guiding similar decisions.--agr (talk) 14:25, 27 April 2015 (UTC)

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

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)

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

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)

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, APerson, ATinySliver, Be..anyone, Beeblebrox, BethNaught, Bryce Carmony, Bus stop, Calidum, Casliber, Davey2010, DerryAdama, Dustin V. S., EEng, EoRdE6, Fauzan, Herostratus, Ivanvector, Jayron32, Jerodlycett, JohnBlackburne, JohnCD, Kaldari, kennethaw88, Kharkiv07, Kikichugirl, Mandruss, NebY, Nøkkenbuer, Nyttend, Od Mishehu, Origamite, Quiddity (WMF), Racerx11, Rich Farmbrough, Samwalton9, SchreiberBike, Spinningspark, Technical 13, The ed17, TheDJ, This, that and the other, Trout71, Yair rand

Colo(u)r nominations

Nominations are closed. Voting round 2 is open.

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. Voting round 2 is open.

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

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

1. 3B(6) ―Mandruss ☎ 15:41, 6 May 2015 (UTC)
2. 3B(6) --Ahecht (TALK
   PAGE) 16:17, 6 May 2015 (UTC)
3. 3B(6) --- :D Derry Adama (talk) 16:20, 6 May 2015 (UTC)
4. 0A(6) JohnCD (talk) 16:22, 6 May 2015 (UTC)
5. 0A(6) --JohnBlackburne^words_deeds 16:24, 6 May 2015 (UTC)
6. 1B (6) –Davey2010^Talk 16:30, 6 May 2015 (UTC)
7. 0A (6) --Jayron32 16:47, 6 May 2015 (UTC)
8. 1B (4) 3B (2) -- Herostratus (talk) 16:54, 6 May 2015 (UTC)
9. 1A(6) Ivanvector (talk) 17:07, 6 May 2015 (UTC)
10. 0A(5), 3B(1) BethNaught (talk) 17:35, 6 May 2015 (UTC)
11. 3B(6) —ATinySliver/^ATalkPage 17:36, 6 May 2015 (UTC)
12. 1A (3) & 3B (3) Consensus I see not here... EoRdE6^{(Come Talk to Me!)} 18:09, 6 May 2015 (UTC)
13. 1A (6) Sam Walton (talk) 18:12, 6 May 2015 (UTC)
14. 0A (6) Kharkiv07^Talk 18:15, 6 May 2015 (UTC)
15. 1A(2), 1B(4) NebY (talk) 20:08, 6 May 2015 (UTC)
16. 0A (6) Kaldari (talk) 20:09, 6 May 2015 (UTC)
17. 1A(4), 3B(2) Origamite^ⓣⓒ 20:22, 6 May 2015 (UTC)
18. 0A (6) SpinningSpark 21:24, 6 May 2015 (UTC)
19. 1B(4), 3B(2)  SchreiberBike | ⌨  23:17, 6 May 2015 (UTC)
20. 1A(6) at least it's not 0A.. All the best: Rich Farmbrough, 23:27, 6 May 2015 (UTC).
    
21. 1A(4) 1B(1) 3B(1) --L235 (t / c / ping in reply) 00:03, 7 May 2015 (UTC)
22. 1A(3) 3B(3) —Granger (talk · contribs) 00:21, 7 May 2015 (UTC)
23. 1A(6) --RacerX¹¹ Talk to me^{Stalk me} 00:50, 7 May 2015 (UTC)
24. 3B(6). kennethaw88 • talk 03:08, 7 May 2015 (UTC)
25. 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)

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)

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)

Another take on why newbies find Wikipedia unfriendly

Thoughts sparked by the long discussion above on discouraging biting.

If a new driver were encouraged to start without any instruction or preparation, simply getting into the driver's seat and setting off into the traffic as soon as he had worked out how to start the car, he would certainly find the highway an unfriendly place, with people hooting, flashing and yelling at him and police flagging him down and issuing warnings and threats.

A Wikipedia newbie is in very much this position, and it is no wonder that many newbies' talk pages contain strings of notices and warnings. Making constructive edits to an encyclopedia is not a simple task, and pretending that it is helps no-one; but the whole message to new users is still "Come on in, it's easy!".

If new users, until reaching some standard like autopatrolled, were prevented from creating articles directly but had to go through AfC or a similar process, they could be given advice rather than see their first attempts deleted. An incompetent article with possibilities could be worked on out of view of the readers. If newbies were more strongly encouraged, or even somehow required, to read a basic page or two of introduction like WP:YFA, the time spent would be amply repaid in saved time and trouble later.

Another step which would save a lot of wasted time and frustration for many newbies, and greatly lighten the load on new page patrollers and admins, would be to explain before sign-up that Wikipedia is a project to build an encyclopedia, with standards on notability and verifiability, and is not a social-networking site for people to write about themselves, or a free advertising platform for telling the world about their companies. Of course, some would press on regardless, but many might desist who are now encouraged to join and create unsuitable pages, often putting in considerable effort, before we tell them "sorry, but that's not what Wikipedia is for".

Of course ACTRIAL, a more modest proposal on these lines in 2011, was summarily vetoed by the WMF, seemingly on the grounds that no kind of obstacle must ever be put in the way of anyone who wishes to edit; but considerable changes are now happening at the top of the WMF and a new proposal on these lines might at least be listened to. JohnCD (talk) 21:53, 19 April 2015 (UTC)

It is true that misguided attempts to make Wikipedia look welcoming ("Come on in, it's easy!") might well be the thing that does most to make Wikipedia look unwelcoming. And giving an explanation what Wikipedia is and what an account can be used for in Special:Login (instead of claiming "Wikipedia is made by people like you." which is misleading - at the very least, other encyclopedias are not written by dogs and geese either) would be a step in a right direction. But making one use WP:Articles for Creation until one gets WP:Autopatrolled is too much. People are different. For example, someone who mostly edits other Wikipedias is not going to have "autopatrolled" flag. --Martynas Patasius (talk) 22:32, 19 April 2015 (UTC)

The only way to really teach people how to engage in a complex social and technical task like WP editing is by guided experience, with a guide knowledgeable in the task but also in the art of guiding, assisting people individually, one at a time, in detail. This is not easy and there are no shortcuts--I try to do this, but I think I do it fully only once every month, and succeed about half the time.

The limiting factor is that while we have about 2,000 people here at least who can write a good article, we have perhaps 200 who can effectively help someone, and perhaps 20 who can really teach the art of helping. The qualities needed for proper teaching are not preferentially found among people attracted to systems like WP, who will always be predominantly loners. This is to a large part inherent to the nature of WP, and while there might be improvement if our contributors become more diverse, there cannot be expected to be a quick solution. DGG ( talk ) 00:18, 20 April 2015 (UTC)

I agree with the principles behind the ACTRIAL refusal, which would also apply here. WP is the encyclopaedia anyone can edit, and that means anyone without asking first, without going through any sort of application process or tutorial process. They can and should just jump in and edit. The problem with anything that gets in the way of that, no matter how well intentioned, is it will deter editors. Every extra step they have to take, every additional sentence they have to read, will cause some to give up, close the browser window, go do something else, and we will lose those editors and their contributions.--JohnBlackburne^words_deeds 00:53, 20 April 2015 (UTC)

The key point in editor retention is the first big argument. If we want to retain editors we should cede some ground to argumentative new editors. It happens all the time that a new editor realizes that something is impossibly wrong and that they are in opposition to many seasoned editors. Some concession should be made at that point to the new editor's argument. Bus stop (talk) 02:02, 20 April 2015 (UTC)

• I have been pinged for my thoughts here. I was one of the major driving forces behind the WP:ACTRIAL project even if I was not the actual nominator of the various RfC that led up to it. The proposal came about as part of research by me, Blade, WSC and a couple of others into possibilities of vastly improving WP:NPP which is our only firewall against all kinds of unwanted new pages. The consensus was vetoed in the first instance by junior paid devs and their decision was rapidly supported in not-too-polite terms by very senior influential staff who are still in their positions immediately below the CEO/vice-CEO. What we got in response to our concerns was the excellent new software suite for WP:NPP developed by the Foundation; unfortunately it did not and could not of course even remotely address the actual problems with NPP for which we were searching for solutions and which today are more critical than ever, What we must also absolutely not ignore is the experience drawn from the ailing and even worse performing project at WP:AFC where also a huge number of totally inappropriate pages are submitted and are (or should be) declined and deleted on the spot.

Wikipedia is the only serious web site that does not need registration to be able to edit. Websites, forums, and and blogs that require registration and/or review of new content by a moderator do not appear to deter their contributors. I have never seen any compelling arguments or conclusive proof that making wannabe Wikipedia new-article creators waiting 4 days and 10 edits to be able to create an article in mainspace would deter the serious , mature person from creating their first article.

Rome was not built in a day and an encyclopedia is also a perpetual ongoing process. Nothing is so urgent that it needs to be published immediately - not even the artspam bios for political candidates shortly before ele3ctions or soccer player bios that consist generally of little more than an infobox and of which we have literally tens of thousands of entries..

The decision to accept the restriction that would have been tested by WP:ACTRIAL was denied even that test. Times change, Wikipedia continues to evolve. It has evolved already into an information resource where most of the traditional encyclopedia articles have already been created and are now under permanent maintenance and updating. It has clearly evolved into a place where spammers and paid editors are rising to the challenge to circumvent our non-advertising policies and in this they are largely successful - not only, but also due to the fact that even some admins offer such 'professional' services and are hard to expose. My Wikipedia energy and that of some other prominent editors and admins who have already left, is being significantly eroded by those who use my volunteer time for their profit. The motion to restrict the creation of new articles was carried by a very large community participation and an overwhelming majority, it is time to review this position again because what users like DGG and I and a few others can do to combat the junk is only a tiny drop in the ocean. Time to decide whther to introduce restrictions or continue to lose editors who like me, are sick and tired of what some editors/creators are allowed to get away with.

So to recapitulate, I interpret the core Foundation policy as 'Wikipedia is the encyclopedia anyone can edit ' (emphasis mine), but I do not interpret that even broadly construed to mean 'Wikipedia is the encyclopedia for which evety crank, delinquent, and spammer can create a new article live in mainspace' . Time to decide whether to introduce restrictions or continue to lose editors, admins, and maintenance workers who are sick and tired of of fighting a losing battle and a Foundation that is isolating itself exponentially from the realities down here at the coal face and is turning itself into an NGO-style salary-paying machine. The biting will stop when the Foundation finally gets round to creating the new inter-active welcome page they rpomised 4 years ago. But no, they prefer to develop and impose software solutions that nobody asked for and nobody wants - anyone who can edit a common web forum or an online-site builder can very easily get to grips with editing Wikipedia, and if not, for genuine new-article creators, plenty (if not already too much) help is on hand. QED. --Kudpung กุดผึ้ง (talk) 02:25, 20 April 2015 (UTC)

I've got to say, I'm still sore about how all of that happened and my view on the matter hasn't changed. Although it's not the reason I initially took a 2+ year retreat into a specific topic, it's part of the reason I'm still doing so today; I currently use Wikipedia as an outlet for some interests of mine that I wouldn't otherwise have someplace to perseverate on without very serious stigma. Although I'd be a liar if I said I was unhappy that it helps other people, I'd also be a liar if I said I was doing so out of some effort to help the Wikimedia Foundation. I personally find it deflating to see resources thrown at things such as the gender gap (if I may, speaking as a white heterosexual male who also has this to contend with, my feeling is that the WMF treats people like me as a monolithic group that doesn't need encouragement to edit here; even though I don't need or expect compliments for my writing I'd like it if, at least once in a while in the myriad discussions of Wikipedia identity politics, I wouldn't be treated as if my being white, heterosexual, and male is somehow a detriment to the mission of writing an encyclopedia) while entirely failing to address the issues that editors—that is, the people who are already established assets who want to do more—are looking to have resolved. The Blade of the Northern Lights (話して下さい) 02:40, 20 April 2015 (UTC)

I sympathize; I was also diagnosed with PDD-NOS, and Wikipedia helps me deal with that. I also feel that we should be encouraging everyone to edit, regardless of age, gender or anything else, but laying aside a person directly wanting to make an edit, I've never seen anyone decide to become an editor, so I'm unsure what affect the GGTF has. I think that the discussion on WT:Flow might interest you. Origamite^ⓣⓒ 03:46, 20 April 2015 (UTC)

This seems to ignore that a vast amount has been done to deal with unwelcome contributions. Including

Filters that catch many problem edits as they are made, including ones creating new pages

Bots that revert many problem edits quickly and automatically

Tags that help editors spot problem edits and editors

Navigation popups, Twinkle and many other tools that help editors identify and deal with problem edits and editors

All these work (and they do work very well) without imposing restrictions on the vast majority of edits, which I think is how it should be. Disruptive editing by new editors is annoying but I think quite manageable. Experienced editors that become disruptive are much harder to deal with, and up-front restrictions would do nothing to stop them.--JohnBlackburne^words_deeds 02:50, 20 April 2015 (UTC)

All of those were there before ACTRIAL, and are all quite useful. None of them stopped a page saying "Let's expose all burakus for what they are!!!! [link to a list of burakumin in a Japanese prefecture]" from appearing (if you don't know offhand how truly horrific that is that's part of the problem I'm getting at, most people wouldn't have recognized that for what it was), nor another accusing two men of conducting multiple sexual assaults on children. This sort of thing happens every day, and even if it can't be entirely eliminated it can be dramatically scaled back. Even for those which are not outright defamatory, we checked in 2011 and found that 75% of these pages were deleted within a week. Of the remaining 25% many were on some topic such as schools or places, which are notoriously resistant to deletion even in the face of blatant inaccuracies, and all ended up being an enormous time sink for those of us willing to take on NPP. I'm not sure if the proposal forming the basis of ACTRIAL would have resolved that, but we definitely don't know now because we never had a chance to try it. The Blade of the Northern Lights (話して下さい) 03:08, 20 April 2015 (UTC)

My own experiences as a relatively new user may be of some help here. My experiences here have been quite mixed.

I found that the introductory material was quite unhelpful. It gave some very basic how to get started info that was useful to a point and then it just falls to pieces. The information on references was very basic and was not consistent with the more usual templates. More simply put, it was outdated and not very useful for anything other than references with a 1:1 relationship. Secondly, finding your way around the WP 'back of house' is pretty difficult. It makes it very hard to find out how to do things. My observation is that WP is a very user-friendly interface as an encyclopedia but not very user-friendly as a work environment. It needs better 'induction resources'. It also needs a better way to navigate through the material that makes up the 'work environment' - the 'how do I do this' and the 'how should this be done'. I have tried to get some interest in this at the Village pump but it appears to largely fall on deaf ears.

Secondly, I find that too much about style and related issues relies on 'unwritten rules',which a newbie can never hope to know until they have been bashed about the ears many times. It is a poor organisational structure that is based heavily on a culture of unwritten rules. WP editors are drawn from a global domain. There is very little that can reasonably be assumed to be 'universally understood'. Yet WP makes many assumptions to its detriment. Matters of style and editorial policy need to be stated clearly and unambiguously. It is not just about stating the mandatory but also what is optional or discretionary. In many cases, annotation can be a useful tool - something which is quite different from making the relevant material overly prescriptive. WP does not provide a structured environment within which to work. On one hand, it is very easy for a newbie to break the unwritten rules but on the other hand there is a strong resistance to and even open hostility to making these unwritten rules explicit.

Finally, WP markets itself as a collaborative and respectful experience. It is not. I do not suggest that this is a consequence of many but of a few. Unfortunately, the impact is disproportionate to their number and their conduct is not necessarily aimed only at newbies. Cinderella157 (talk) 05:39, 20 April 2015 (UTC)

Interesting. My experiences are different, but I was scared off originally. When I joined just over 2 years ago, I decided to make an organization like the AWWDMBJAWGCAWAIFDSPBATDMTAD. Accidentally, I put it in the wrong namespace. After some panicking when I saw the speedy template, I decided to quit Wikipedia. That November, I saw another edit I wanted to make, but I left again after that. It wasn't until February 2014 when I did some of The Wikipedia Adventure and I decided I wanted to edit some more, I'm not sure what to say--maybe suggest to more editors that they try TWA? Origamite^ⓣⓒ 06:33, 20 April 2015 (UTC)

• I don't think we regulars mean to be cliquey and offputting to goodfaith newbies, but I'm aware that we can come across that way. I think we need a sharper divide between the way we deal with goodfaith newbies and badfaith ones, we also need some system changes to make the place less bitey. Top of my list, because it shouldn't cost much (certainly less than V/E, AFT or Flow), would have a big impact and the community would broadly welcome it, would be to fix some of the longstanding suggestions on phabricator to reduce edit conflicts. Adding a template or category to an article need not be treated as an edit conflict against adding the second sentence of an article, nobody likes having or causing edit conflicts, but we should keep pointing out to the WMF that they are one of the most frequent ways that newbies get bitten. To the programmers who run phabricator and who used to run bugzilla, these are a trivial issue not worth the time to fix - any programmer should be able to recover from an edit conflict and why should anyone else edit? But if we want to make Wikipedia more friendly to goodfaith newbies this is the easy uncontentious first step. ϢereSpielChequers 06:50, 20 April 2015 (UTC)

There are some really arrogant individuals out there who preside over particular domains. I say this in part from personal experience but to a larger extent from observation. For me though, the biggest thing is accessing information and making it easier to access. For an encyclopedia, we do a really poor job of presenting our internal information and of making it easily accessible. Cinderella157 (talk) 07:00, 20 April 2015 (UTC)

There are real issues here. Like it or not Wikipedia addresses all the issues of the day. Whole articles can be about an issue, or fragments of otherwise straightforward articles can bring to the forefront an issue about which editors disagree, sometimes heatedly. I think some editors leave in a huff when the odds are stacked against them having their voice heard. Everyone wants to express themselves. It can be fun doing minor odds and ends. I enjoy most edits. There is actually satisfaction in building something. When one knows that one has made an improvement, one becomes attached to the project. But it is a reality that disputation constitutes a lot of the activity around here. Just look at WP:AN/I. I think that personal clashes that involve article content become serious issues concerning editor retention. Sometimes a new editor feels strongly about something of this nature. It is then that we should be thinking about not biting the newbies. Bus stop (talk) 18:45, 20 April 2015 (UTC)

I'm guessing that most veteran editors don't take the time to tell the newbie what he did wrong and how to correct it in the future. A quick edit summary often doesn't cut it. I always try and put a welcome template on their talk page, but I don't always point them to the proper WikiProject where they could find even more help on the topic they edited. I would say "time" for me is the number one reason I don't always add a more personal note, but I do try especially in tennis articles. When I see a new good faith edit that is wrong, I find it helps to point them to the TennisProject guideline and talk page and to tell them we need new editors passionate about tennis, but that they need to follow past consensus decisions and my talk page is always open for any questions. But we don't always do that for lack of time (self included). But that approach has helped retain some now not-so-new editors that keep on top of heavily trafficked articles... bumpy at the beginning, but now generally with the program. The other thing that can stop a helpful talk page writeup is that after doing 90% mischief or vandalism reverts, a newbies' one word change gets lost in the shuffle and simply gets a "I feel the original word worked better" edit summary from me. After reading some of these posts here I'll try to keep a better watch for initial "good faith" edits, though anon IPs often only have one edit to their credit because they shift like revolving doors. Fyunck(click) (talk) 19:15, 20 April 2015 (UTC)

That's one of the reasons why I think we should turn away at the gate those many newbies who don't actually want to contribute to an encyclopedia, but are looking for a social-networking site, or a noticeboard where they can promote something. If we didn't have to spend so much time explaining to them that WP is not for what they want to do, there would be more time to help the newbies who really do want to contribute but haven't worked out how. JohnCD (talk) 22:15, 20 April 2015 (UTC)

Above I see Twinkle being touted as something to "help editors". Frankly, that's a matter of opinion. Text-based communication is one of the worst, if not the worst way of communicating with newcomers. Knowing how they feel and how they might react is a total crapshoot, and their initial experience of WP is, as has been said before, a gamble of which patroller they run up against first. I try and do damage limitation on speedies wherever practical, but there's only so much work I can do, and there's plenty of other articles I read whose quality is found lacking. One question I haven't really seen asked before is - how many newbies have we bitten? That would be an interesting metric, as from my experience one bad experience with Wikipedia travels to that person's family and friends, exacerbating the decline.

We're now at the stage where we have far too many abandoned articles that nobody pays attention to. I've only got 40-50 articles I steward carefully (mostly ones I've taken to GA), and every time an IP adds a large piece of unsourced content to one I sigh and wonder if I can get away with reverting it, or whether I've got to copyedit and source their work for them. Not biting newbies is important, but I think we're now at the stage where we need to go further than that and look out for long-term article stewards. As we all know, Gregory Kohs took great advantage of this recently, and he found it was not hard to add blatant hoaxes to articles where nobody had a good handle and expertise on the subjects in them - it was WP:POINTy, of course, but the point was still there to make. Of course, he hasn't told me anything I didn't already know about article quality, which is so hit and miss - I've nothing against people creating GAs and FAs, more power to them, but when a casual reader sees a good article about a place right next door to a start-class one, they might wonder if the quality has been guided in the right direction.

I am cautiously optimistic that the recent turnover in the WMF staff mean we may have turned a corner, and can give serious thought to proposing something like WP:ACTRIAL again in the future. Otherwise, I fear that editor retention is going to carry on declining until we've only got the basement-dewelling ANI drama-whores and powermongering article owners left. Ritchie333 ^{(talk) (cont)} 13:23, 21 April 2015 (UTC)

I'm not in the slightest bit optimistic. The WMF is too concerned with increasing new user and new article stats irrespective of whether the articles get deleted or the users get blocked. The current changes in staff at the top involve people who are not in the slightest bit interested in the nuts and bolts on the factory floor; they are more concerned with playing at business management and finding new ways of spending the funds, and as Hammersoft said somewhere recently, they do not understand the need for investing for a rainy day when eventually it will matter most. --Kudpung กุดผึ้ง (talk) 21:07, 28 April 2015 (UTC)

• I've recently found there are potential plans for an endowment. See Foundation:Minutes/2015-02-06#Endowment. However, I'm honestly not holding my breath for two reasons; (1) it took them nearly 15 years to think this might be a good idea, and (2) they initiated discussion 1 1/2 years ago with nothing concrete yet. On another point; Wikimedia's projects depend on there being a large body of editors ready and willing to ensure quality. The reality? Editorship is in a long term (over eight years now) decline. Their best efforts to avert the decline, starting four years ago, have utterly failed. They keep on trying to avert the decline, but it will get them nowhere. A serious strategy and vision would take this into account and understand there is an enormous resource here that needs to be managed into a future where there are not sufficient editors to maintain quality. Wikimedia lacks that vision, and in my opinion is not competent to handle the tasks before them. I believe this incompetence stems from structural issues. For example, the board that ultimately guides the Foundation is elected. There are no prerequisites regarding prior experience, skill sets, or even an interview by qualified interviewers. I.e. anyone can become a member of the board, regardless of their qualifications. They could have failed out of kindergarten, but if they are able to draw enough votes they will be placed on the board. --Hammersoft (talk) 22:09, 28 April 2015 (UTC)

To my mind the real issue with newbies is that we have (currently) no way of telling who is worth cultivating. We have something like 1300-1400 new accounts (that actually edit within a few days of being created) per day, who don't receive a talk page welcome. Many of them will never make another edit. Of course some are vandals, some are socks, some are self-promotional. But even the Good Faith editors who stay might not wish to do more than correct the odd typo, or update sports results - these people do not need to know about AfD, ANI, or even much about MoS - they might never use an article talk page. Inundating them with reams of policy to read is counter-productive. Conversely someone editing actively in a fraught area might benefit from substantial individual help. All the best: Rich Farmbrough, 18:08, 29 April 2015 (UTC).

Couldn't agree more with the OP. Wikipedia needs to get a grip and develop a better solution than en masse live article creation by new contributors followed by speedy deletion. Remember, Wikipedia started before the spread of social media, whereas now every company, group or public person expects to have a "my profile" or "our page" all over the internet. The aim must be to ensure that new contributors understand the basics of what WP is about, at the earliest stage possible. We should also do away with the multiplicity of routes for their new articles such as AfC, Drafts, Userdrafts, and straight into mainspace with or without a {{New unreviewed article}} banner and category entry.

First-time new articles should all be channelled through something like the Article Wizard, and the results should all go into some holding pen, until they are checked and either moved to mainspace or a friendly (where appropriate) message sent: "Sorry, not acceptable as it stands because... This is what you would need to change": Noyster (talk), 18:49, 1 May 2015 (UTC)

It sounds like you're proposing that users not be autoconfirmed until they have successfully created an article (non-autoconfirmed users have to submit articles through WP:AFC, which does as you've described). The real problem is that the Article Wizard is truly, utterly terrible, and would need to be rethought from scratch before it was made mandatory (Protonk put it better than I ever could here. --Ahecht (TALK
PAGE) 20:04, 1 May 2015 (UTC)

non-autoconfirmed users have to submit articles through WP:AFC Not so, nothing stops the newest of accounts bypassing all the advice and typing or pasting a new article into a blank edit screen. The system you mention was proposed for testing in the abortive WP:ACTRIAL, referred to above: Noyster (talk), 13:26, 3 May 2015 (UTC)

Yep, you just need to be logged in. No previous experience necessary. --Redrose64 (talk) 14:06, 3 May 2015 (UTC)

• IDEA: 48 hour visibility delay. This is a crude idea and needs work but here goes: Create two flags one being the New User Flag (NUFLAG) and the other being the New Page Flag (NPFLAG). All new registered users will have their NUFLAG turned ON by default. When a new page is created WP will check the NUFLAG and if it is on then the page's NPFLAG will also be turned on. NPFLAG-ed pages will not be publicly visible (only admins+ and the creator can see it) for at least 48 hours until NPFLAG is turned off. A 48 hours delay would allow the page to be developed safely but reduce hit and run editing by commercial editors). What the criteria for the NUFLAG should be will need to be thought out but maybe something like user must have made a minimum of 99 edits before the flag is turned off. Admins of course can turn off the NPFLAG early if they feel the article meets the WP standards. 104.32.201.0 (talk) 17:41, 3 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)

Nearing 100 !votes at Talk:Hillary Rodham Clinton/April 2015 move request

Counting a half dozen "neutral" votes, we are now just shy of a hundred people having !voted at Talk:Hillary Rodham Clinton/April 2015 move request, which is the highest participation we have had at a move request since Chelsea Manning (and, frankly, I can't remember any other move request that has had this much participation). bd2412 T 15:12, 29 April 2015 (UTC)

Yoghurt=>Yogurt? All the best: Rich Farmbrough, 18:11, 29 April 2015 (UTC).

That, and I don't know why this is posted here at all. Beeblebrox (talk) 21:56, 29 April 2015 (UTC)

I don't want to be mean but this isn't just a post anything community noticeboard, and this definitely isn't a proposal. EoRdE6^{(Come Talk to Me!)} 00:02, 30 April 2015 (UTC)

The proposal to move the page is technically a "proposal", but I just found it fascinating that it has this much traction. There are now 118 !votes total, so I have added it to WP:MISC100. bd2412 T 19:25, 30 April 2015 (UTC)

Edit-conflict warning

This is a proposal for a feature change; it's not something that we can implement with a button-click here. If successful, this proposal will serve as evidence that the community supports a Phabricator request.

Right now, there's no way to know whether someone else is editing a page, and that's part of the reason that edit-conflicts occur — someone else is changing something at the same time, and you're not aware of it. What if the software displayed a banner when someone else is editing the same content as you? I'm imagining that it displays something like an editnotice in the following situations:

• When you edit a section and someone else is editing the same section
• When you edit a section and someone else is editing the entire page
• When you edit the entire page and someone else is editing a section

Doing something of real-time detection (e.g. after you click Edit, someone else opens a window, and it warns you) would be way too resource-intensive. Consequently, I'm just imagining that it does this upon loading the page: when you click Edit, it warns you if someone else already has the edit page open with one or more changes. We already have a preference to "Warn me when I leave an edit page with unsaved changes" (Special:Preferences/Editing), and I'm imagining that the warning would only be activated if another username or IP address has made unsaved changes to a page.

If it's not possible (or not practical) to do it, who cares whether it's a good or bad idea? And if it's a bad idea, who cares whether it's practical to do? So please offer comments both on the technical possibility of doing this and on the idea in general. Nyttend (talk) 23:11, 29 April 2015 (UTC)

The immediate concern that comes to mind is: What if somebody leaves their edit window open and sit idle indefinitely? --RacerX¹¹ Talk to me^{Stalk me} 23:48, 29 April 2015 (UTC)

(edit conflict) When you click on an edit link, you're sent a token along with the page (including the edit window). When you click Save page, you send that token back along with the content of the edit window. So, the edit begins, and later on, it ends. But what if the user decides to abandon their edit part way through? They could click the "Cancel" link, which would send a message back meaning "I am no longer editing this page, let somebody else have it" - but I never use that link. Instead, I use the "back" button on my browser, so the Wikipedia servers have no idea that I'm done editing. It might then put up an erroneous warning to some other user; that warning would never go away, and that other user might then be put off entirely. --Redrose64 (talk) 23:50, 29 April 2015 (UTC)

If you open the edit window, leave it open for a good while, and then save the page, you normally get the thing that says basically "We couldn't save, because whatever-it-was has expired, and we don't want your session to get hijacked". We could obviate your concerns by setting it to stop paying attention once the session's time limit expires, although again I don't know if that's practical to do. Nyttend (talk) 00:03, 30 April 2015 (UTC)

If I understand correctly, If A starts editing, and B attempts to edit in a way that could cause an edit conflict, B would be notified of the risk, and could choose to continue or not? And if B either chooses to edit anyway, or doesn't have the feature enabled, A receives no edit conflict protection? Which would also mean that A isn't actually stopping anyone from editing by leaving the window open, which eliminates the main potential issue. If that is the effect of the proposal, I'd favor it in principal as a feature some people may find useful, though I suspect it may be complicated enough to implement that its not worth it. Monty₈₄₅ 03:49, 30 April 2015 (UTC)

That's kind-of it. This wouldn't prevent anyone from doing anything, and "protection" seems to me to go too far, because it's just a warning that a conflict might result. It would just be a notice that appears when you start editing and that can be ignored if you choose, very different from the "Warn" feature of the edit filter: if you ignore it, either nothing will happen, or you'll get into an edit conflict as if it hadn't appeared. At edit-a-thons I've attended, if two people start editing the same article, sometimes one of them will mention this fact to the other: this is nothing more restrictive or complicated-to-understand than that, with the added advantage that the software can detect it even if the people are around the world. But perhaps you mean complicated from a technical perspective; I have no idea how simple or difficult that would be. Nyttend (talk) 12:01, 30 April 2015 (UTC)

PS, you're correct on the A-and-B situation. I don't know how you'd notify A without real-time analysis, which presumably would take lots more effort, and at any rate it would be foolish to implement it without trying my simpler idea first. Nyttend (talk) 13:07, 30 April 2015 (UTC)

Even if there's no way to protect A from an edit conflict, I think we should do our best to help B. Of course, if A uses the Preview feature, (s)he can be warned immediately. The warning should be shown to B if A has opened the Edit window, or used the preview button, during the last X time, and hasn't saved the edit or indicated the lack of interest of doingt so. The warning will work like the semi-protected page warning - a note at the top of the edit page, no other action taken. עוד מישהו Od Mishehu 13:34, 30 April 2015 (UTC)

I like your idea of displaying it in Preview: that's a possibility that hadn't even come to mind. And yes, the semiprotection warning is a good analogue. Nyttend (talk) 13:50, 30 April 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)#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)

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)

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

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

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

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

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.