Editors may use or omit a comma before Jr. or Sr. so long as each article is internally consistent. Do not place a comma before a Roman numeral designation. Examples: Sammy Davis Jr.; Martin Luther King, Sr.; Otis D. Wright II, not Otis D. Wright, II.

Hopefully this will avoid ongoing arguments on which is the "right" form for individual subjects (based on their preferences or sources' preferences) and won't lead to editwarring (see MOS:DATERET for the guideline avoiding similar editwarring over date formats).

As flagged in the previous discussion, this raises the issue of commas appearing after Jr. and Sr.. All style guides state that, if a comma is used before, a matching comma must appear afterwards if the sentence continues—acting as an appositive, much like commas after dates in MDY format (MOS:DATEFORMAT) and after city–state combinations (MOS:COMMA).

Unfortunately, many editors are not aware of this rule in English and sometimes argue against it. Therefore, I recommend this section be further amended as follows:

Editors may use or omit a comma before Jr. or Sr. so long as each article is internally consistent (Sammy Davis Jr. or Martin Luther King, Sr.). If using a comma before, also include a comma after Jr. or Sr. if the sentence continues (John D. Rockefeller, Jr., was an American financer and philanthropist...).

Do not place a comma before a Roman numeral designation (Otis D. Wright II, not Otis D. Wright, II).

—sroc 💬 05:54, 14 May 2015 (UTC)

Guidance on commas after Jr. and Sr.: Comments

• [Support:] Yes, if a comma goes before, it goes after. Standard logical clause construction. NB. Much prefer the British style where Jr and Sr do not need the period. --SmokeyJoe (talk) 06:21, 14 May 2015 (UTC)
• Support the use of proposed addition. Consistency is a poor justification for going against WP:UCRN. GregKaye 06:34, 14 May 2015 (UTC)

  User:GregKaye - what does requiring the second comma have to do with WP:UCRN? Dohn joe (talk) 16:54, 14 May 2015 (UTC)

  Dohn joe My personal preference is that we should generally use a form of name that corresponds to WP:RECOGNIZABILITY and WP:NATURALNESS. Unless there are other pressing concerns, these are the considerations we, I think, should predominantly follow the way things are normally done for that person. WP:UCRN presents that: "Wikipedia prefers the name that is most commonly used (as determined by its prevalence in reliable English-language sources) as such names will be the most recognizable and the most natural." GregKaye 18:56, 14 May 2015 (UTC)

  User:GregKaye - agreed. But again, what does that have to do with whether we allow "John Smith, Jr., was..." and/or "John Smith, Jr. was..."? This RfC is only about whether we require that second comma after Jr. or not, not how we present the name (except for cases below like the Rockefeller library). I'm still confused about the relevance of wp:ucrn. Dohn joe (talk) 19:04, 14 May 2015 (UTC)

Dohn joe My apologies for not understanding what you were saying. My support is mainly for the inclusion of examples such as "Sammy Davis Jr. or Martin Luther King, Sr.". I still think the commas content makes reasonable sense but you are right to point that this has nothing to do with issues relating to prevalence of use. GregKaye 19:40, 14 May 2015 (UTC)

• Oppose - What are you trying to do? The whole proposal that you have supported had no consensus. I checked the closed discussion, and you're still persistent on having all commas before successor or predecessor omitted. Also, you haven't contacted or pinged Go Phightins!, who accurately closed the previous discussion. Well, I'm still in favor of omitting a comma, but not when sources are divided or when consensus opposes it. This is instructional creep. --George Ho (talk) 07:04, 14 May 2015 (UTC)

@George Ho: What are you on about? This RfC isn't about the comma before Jr. or Sr.—it's about the separate issue of providing guidance for the comma after Jr. or Sr. All style guides say if there's a comma before there must be a comma after. That's all this RfC seeks to add to the guideline for clarification. —sroc 💬 15:21, 14 May 2015 (UTC)

Note that this proposal was already flagged in the previous RfC:

Note: This RfC only concerns the comma before Jr. and Sr. If the result allows for that comma, then a follow-up discussion may be necessary regarding guidance on a comma after Jr. or Sr.

The result of that RfC allows for the comma before, so this RfC is about the comma after, exactly as previously stated. —sroc 💬 15:47, 14 May 2015 (UTC)

My bad. If you're concerned about a comma after Jr or Sr, perhaps I was mistaken. I struck original vote, so I will make a fresher one. George Ho (talk) 18:37, 14 May 2015 (UTC)

Weak support - Look like an instructional creep, but a comma after Jr/Sr makes more sense when a comma before Jr/Sr is added. No comma before, no comma after, however. And I wouldn't care about regional differences as long as commas are properly used.

• Oppose, it's an archaic style that's still listed in quite a few places and used in even less. The Jr. or Sr. without a comma has been the standard way of using the style as long as Jr. and Sr. have existed, or at least in my experience, which is almost as long. Official names, such as the Martin Luther King, Jr. Memorial, don't use it, probably because it makes things look worse instead of better and is so uncommon that the mind latches onto it and won't let go, like some kind of little dog sitting there growling at the preceding period. Randy Kryn 10:54, 14 May 2015 (UTC)

@Randy Kryn: That would be a good argument to do away with the commas altogether, but that argument has been and gone. English construction and style guides universally agree that a comma before requires a comma after. The fact that some sources flout this rule is no reason for this encyclopedia to follow in their folly. —sroc 💬 15:56, 14 May 2015 (UTC)

• Oppose - The recently closed RFC closure on the issue of commas before Jr. or Sr. (essentially saying that we should have no rule other than "be internally consistent" within an article) reflected a practical and common sense approach that accounts for our lack of consensus on the issue. I think the same approach should be applied to the question of commas after... The important thing is for the style to be internally consistent within any given article. More than that is unnecessary instruction creep. Blueboar (talk) 13:33, 14 May 2015 (UTC)

@Blueboar: Style guides generally agree that commas may be included or omitted (the trend is to omit them) but all agree that a comma before requires a comma after. If we're consistent within each article about whether or not to have the comma before, "common sense" requires that we also be consistent about whether or not to include the comma after. —sroc 💬 15:24, 14 May 2015 (UTC)

• Oppose I'm fairly certain this covention is completely unknown in British English - were any of the "all style guides" for BE? People should be more careful about this. Even in AE it doesn't seem to me to be what is usual. Just in case it is adopted it should be made clear that this applies within AE only, for ENGVAR purposes. Johnbod (talk) 14:01, 14 May 2015 (UTC)
• Support – The following comma is required in both British English and American English, and always has been (I'm a Briton). If the form with the comma before is to be allowed, the following comma must also be required. RGloucester — ☎ 14:24, 14 May 2015 (UTC)

This is simply nonsense! Johnbod (talk) 15:17, 18 May 2015 (UTC)

There is nothing "nonsense" about it. Yes, we don't generally use "junior" and "senior" suffixes in British English. However, the rules of comma usage remain the same. Completing the apposition requires a following comma. Take a look at this guide here, which explains the use of commas with appositives quite well. In the American context, one might look at this Chicago style guide bit, which notes the necessary nature of the following comma. RGloucester — ☎ 15:09, 21 May 2015 (UTC)

• Support Now I know why the British omit the period, so you do not have to argue of the mid sentence period. I agree that you should have a comma after a mid sentence period, except after Mr. and Dr. and others that are name prefixes, but that has nothing to do with changing the titles of articles. --Richard Arthur Norton (1958- ) (talk) 15:52, 14 May 2015 (UTC)
• Oppose. It may be that all style guides that address the issue recommend using the second comma, but there are two complications. 1) Not all style guides even discuss this relatively minor point of punctuation. 2) In practice, many reputable sources leave out the second comma, regardless of the preferences of style guides. For example:

Routledge: Cromwell, Adelaide M. An African Victorian Feminist: The Life and Times of Adelaide Smith Casely Hayford 1848-1960. p.31. 2014.

Oxford University Press: Lischer, Richard. The Preacher King: Martin Luther King, Jr. and the Word that Moved America. p.197. 1995.

Many more (see for yourself with this Google Books search).

We have also already come across the case where WP editors have decided that the second comma might not be a part of the name of something. For example:

Talk:John_D._Rockefeller,_Jr._Memorial_Parkway#Requested_move_2_March_2015

Leaving out the second comma in general does nothing to change the ability of our readers to comprehend the meaning of the sentence. Despite style guides' efforts, the second comma is quite often left out, even in reputable, professionally edited sources. Real-world usage shows that both using and leaving out the second comma is acceptable in English. WP should therefore allow both styles, as long as an article is internally consistent. Any particularly strong argument for including or omitting the second comma should be taken up on a case-by-case basis. Dohn joe (talk) 16:41, 14 May 2015 (UTC)

@Dohn joe: The fact that some sources don't follow proper punctuation is no reason for this encyclopedia to follow in their folly. Cases like the Memorial Parkway (where even the "official" sources disagreed on the punctuation) show exactly why we should have proper guidance on this to avoid recurring debates by editors who are singularly focussed on particular articles without a considered understanding of this specific punctuation issue. —sroc 💬 03:55, 15 May 2015 (UTC)

User:sroc - the point is that style guides do not have a monopoly on what is "proper punctuation." Usage in reputable, professionally edited sources is good evidence of what is proper usage. When a significant portion of sources use a style (as with not using a second comma after Jr.), then WP should be allowed to permit usage of that style. Dohn joe (talk) 15:36, 15 May 2015 (UTC)

@Dohn joe: Prescriptivism vs descriptivism. I would rather defer to style guides on matters of style. If there was some leeway in some style guides then I might accept the argument, but all the style guides I've seen say comma before requires a comma after; none concede that the comma after is optional when the comma before is used. It's poor form for an encyclopedia's style guide to go against all style guides on proper punctuation. —sroc 💬 04:22, 16 May 2015 (UTC)

If this is folly, as you repeat, then the U.S. government is guilty of folly (not for the first time, if truth be told) over and over again. The comma after a Jr. or Sr. would change the name of institutions and memorials, of books and beanstalks. As I said, the use of comma after such a word combination misses the point of clear and clean language, and just adds more data into something which doesn't need to be explained. Randy Kryn 11:10, 17 May 2015 (UTC)

The comma is there precisely because it makes for "clear" language by following standard logical rules, as explained by the mentioned style guides. Some sources fail (for example, it has been said that newspapers omit the comma after MDY dates and city–state conjunctions to economise on space in narrow columns) and often disagree (for example, the same geographical feature is "officially" named as "John D. Rockefeller, Junior, Memorial Parkway" in founding legislation; "John D. Rockefeller Jr. Memorial Parkway" on signs and publications; and "John D. Rockefeller, Jr. Memorial Parkway" on its website). Where others fail, we should strive for accuracy and encyclopedic standards. —sroc 💬 11:40, 17 May 2015 (UTC)

• Support - As far as I am concerned, British English uses' this standard. CookieMonster755 (talk) 23:12, 14 May 2015 (UTC)
• Support—if editors are going to use a comma before Sr./Jr., then some form of punctuation is necessary to close the appositive. By default that is another comma, but it could be a semicolon, dash or terminal punctuation. We do this with constructions like "Milwaukee, Wisconsin", so we should be doing this with these types of names. (Dropping the comma completely in these names would simplify things greatly, of course.) Imzadi 1979 → 05:32, 15 May 2015 (UTC)

  The comma in the Jr. or Sr. is part of a person's proper name. "Milwaukee" is a proper name on its own, as is "Wisconsin", so in that form the comma is needed, but not if the comma is part of the proper name. Randy Kryn 1:38, 22 May 2015 (UTC)

Except his name is often given simply as "Martin Luther King" and the "Jr." is only added as a distinguishing feature when needed; and in any case, this involves the rules of English punctuation which are supported by the cited style guides—you have provided no style guide references to contradict this. —sroc 💬 01:43, 22 May 2015 (UTC)

King himself used the comma as part of his proper name. The U.S. government, in its naming of the Martin Luther King, Jr. Memorial and Martin Luther King, Jr. Day have set the style in his case. Randy Kryn 1:48, 22 May 2015 (UTC)

• Support - on the basis of completing the apposition. Cinderella157 (talk) 00:52, 16 May 2015 (UTC)
• Support- logical --L235 (t / c / ping in reply) 18:14, 17 May 2015 (UTC)
• Support as proposed. If anyone doubts this lack of clarity results in editwarring, guess again. —sroc 💬 01:38, 22 May 2015 (UTC)

  You began that editwar (I'd rather call it an edit disagreement, or edit snowball fight) by choosing the very prominent Dr. King page to place the awkward after-proper-name commas without a consensus being reached. The consistency in Wikipedia of not using the comma after King's name is present in using the names that the U.S. government has given to the Martin Luther King, Jr. Memorial and Martin Luther King, Jr. Day. Randy Kryn 1:54, 22 May 2015 (UTC)

You may think it "awkward", but it's English. The alternative was to do away with commas before "Jr."/"Sr.", but the consensus went against that. Americans failing English punctuation is no excuse for Wikipedia to pander to them. —sroc 💬 01:59, 22 May 2015 (UTC)

Eh, it's generally everyone but American's who are dropping the commas, though.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  09:53, 24 May 2015 (UTC)

@SMcCandlish: I was responding to Randy Kryn's comment about US government sources. I don't care who's dropping the comma after; mismatched commas are wrong and an encyclopedia shouldn't settle for sub-standard punctuation. —sroc 💬 17:47, 24 May 2015 (UTC)

Right. :-) — Preceding unsigned comment added by SMcCandlish (talk • contribs)

• Support a comma after when there is one before. – SJ + 15:15, 24 May 2015 (UTC)
• Support: Yes, this is basic English punctuation. I'm skeptical that a Village pump (policy) RfC was needed for this. Minor clarification edits to MOS pages are discussed at their talk pages, or at the main WT:MOS talk page if the MOS subpage's talk page is poorly attended.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  14:56, 25 May 2015 (UTC)

I posted it here because the antecedent RfC: Guidance on commas before Jr. and Sr. was posted here, and that was because it was considered that MOS was not sufficiently patrolled for a previous RfC. Notification was also posted at Wikipedia talk:Manual of Style/Biographies § RfC: Comma or no comma before Jr. and Sr. §§ New RfCs. —sroc 💬 02:16, 26 May 2015 (UTC)

By the way, I would have hoped this wouldn't be controversial, but alas my fear that this would court controversy was realised. —sroc 💬 02:23, 26 May 2015 (UTC)

It courts controversy only because MOS-bashing has become a wikisport (and a team one at that), while not everyone who writes Wikipedia has much training in writing, plus the human tendency to believe that a rule someone doesn't want to be bothered with is a wrong in the world. Competent writers, and reliable sources on English-language usage, all know that commas are balanced in cases like this.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  00:36, 28 May 2015 (UTC)

It's controversial simply because competent writers, and editors, such as the ones cited above from Routledge and Oxford, do in fact sometimes omit a following comma. An acceptable option in reliable sources should be an option here on WP. Dohn joe (talk) 17:00, 28 May 2015 (UTC)

Evidence of usage that has managed to make it into print doesn't constitute reliable sourcing that such a style choice is widely acceptable in a formal register like encyclopedia writing. Routledge and Oxford as publishers have little to do with the output of Cromwell and Lischer, the authors of the books in question. While the writers were surely subject to some level of editorial revision, we have no insider data on why this usage was not corrected to something more standard; we can't suppose it was because officials at the publishers preferred it, or it was just an oversight, or the authors in each case lobbied hard for it because they thought their audience didn't like commas, or what. There's no evidence.

It certainly isn't the case that Oxford can be cited as some kind of authority of in favor of omitting that comma, or even being neutral on it. Oxford's own style guide under various titles doesn't address this exact case, but they do address the general case. With the comma in such a name, "Jr." or "Sr." is an appositive, a qualifier, added to the name. Oxford is clear on these in general: "Use a pair of commas when the apposition falls in the middle of a sentence; they function like a pair of parentheses or dashes, though they imply a closer relationship with the surrounding text". (New Harts Rules: The Handbook of Style for Writers and Editors, p. 68, Oxford U. Pr., 2005). That even neatly explains why we use commas, instead of some other convention like "Martin Luther King (Jr.)".

So, we do have four things here: 1) style/usage guides recommending commas before and after "Jr." and "Sr."; 2) guides not addressing this specific question but giving more general advice that inexorably leads to the same conclusion; 3) guides recommending or at least permitting the dropping of both commas (mostly news style guides, with focus on expediency); and 4) guides offering no applicable advice at all. The one relevant thing we do not have is style guides recommending dropping the second comma if the first is used. Even if a style manual can be found somewhere recommending no second comma, it would be dwarfed by the stack of books contradicting it. So there's really no debate to continue with on this point. It remains well sourced (in this thread and many before it) that reliable sources on English-language usage consistently say that commas are balanced in cases like this. The dropping of the second comma is fairly common in vernacular and journalistic writing (including books written by journalists). I catch myself doing it out of expediency pretty often. But it's not formal, precise writing, and it can lead to sentences that are difficult to parse correctly. Finally, WP is not bound to do what a numeric majority of external style guides do, anyway. MOS recommends what our consensus (collectively built and refined) determines is best for the encyclopedia's purpose and readership, not for the approval of pundits at any external publisher of style guides. An enormous number of WP:MOS-related and WP:AT-related arguments are predicated on approaching MOS/AT as if we're writing a style guide / naming convention for the world, instead of an in-house one for a single publication.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  18:24, 28 May 2015 (UTC)

• Support per WP:COMMA. It's parenthetic material. --Ahecht (TALK
  PAGE) 22:32, 2 June 2015 (UTC)
• Support per nom and per Ahecht. If a comma is used before "Jr" or "Sr", the standard (and in my experience, the usual) style is to also use a comma after it. -sche (talk) 17:35, 6 June 2015 (UTC)

English policy: Support

• Support as proposer, not to mention it's so blindly obvious KoshVorlon Rassekali ternii i mlechnye puti 11:02, 18 May 2015 (UTC)
• Support all non-English articles should generally be moved to draftspace on sight when they don't qualify for speedy deletion but also can't be fixed up in a short amount of time. With the current process, if someone creates an article about some non-notable nonsense in English then it gets speedied in five seconds, but if the article happens to be in some other language then we give it a two-week grace period to see if it gets translated and/or it may get forgotten entirely -- this doesn't make any sense to me and dealing with these articles is pretty annoying. — Jeraphine Gryphon ^(talk) 11:36, 18 May 2015 (UTC) amended — Jeraphine Gryphon ^(talk) 17:23, 18 May 2015 (UTC)
  • Amending my !vote: this doesn't necessarily have to be a new policy page, it can also be written into some other policy or information page, and described as a standard/approved/okay method of dealing with non-English articles. But also it doesn't have to be mandatory to move every non-English article into draftspace (if an editor feels that it will be easy enough to turn that article into something worthy of inclusion on Wikipedia, i.e. they understand what the topic is and have the time to work on it). — Jeraphine Gryphon ^(talk) 14:55, 18 May 2015 (UTC)

I think this is the essence of just do it! If you can translate the article, do it! But if you can't or don't have the time right now, add it to the list at WP:PNT and you or someone else can get to it soon. Is it easy enough to move an article back from Drafts to the mainspace, or does this require an admin to move over a redirect? —sroc 💬 15:58, 18 May 2015 (UTC)

After moving an article to draftspace, the redirect that gets created after the move should be speedied as R2. Cross-namespace redirects -- articlespace redirects that redirect to the Draft namespace should get deleted. So, assuming some time has passed and the redirect has been deleted, it will be easy to move the draft back to mainspace. — Jeraphine Gryphon ^(talk) 16:11, 18 May 2015 (UTC)

Yeah, I just saw this. All the more reason to move the article to drafts if you can't fix it right away, and it can be moved back when it's done. Not that the move needs to be mandatory, but they shouldn't linger in the article space unnecessarily. —sroc 💬 16:58, 18 May 2015 (UTC)

• • Another amendment: as said I don't necessarily support the creation of a new policy, but, wherever it is written, we should not include this part: "This cannot be done if it's in a language that cannot be read on this Wikipedia (English)." -- we can indeed judge articles even if they're in a language we can't understand, it can often be possible to determine (like by using a translator) if an article is total baloney or not. We can do it and we're allowed to, too. (And then tag for speedy (with an explanation for deleting admin if necessary) instead of moving to draftspace.) — Jeraphine Gryphon ^(talk) 17:14, 18 May 2015 (UTC)
• Support-ish. I don't see that we need to enshrine in policy the fact that this is the English Wikipedia, but I'm a big fan of the idea of automatically moving non-English submissions into Draft-space. Yunshui ^雲_水 11:58, 18 May 2015 (UTC)

@Yunshui: What do you think of my counter-proposal below? —sroc 💬 14:11, 18 May 2015 (UTC)

• Support – Anything that makes WP:ENGLISH stronger is welcome in my view. --IJBall (talk) 13:06, 18 May 2015 (UTC)
• Support - yes, I think that this should be obvious; however, I think that draftifying non-English articles is better than either keeping them in the mainspace or deleting them outright. עוד מישהו Od Mishehu 13:10, 18 May 2015 (UTC)

@Od Mishehu: What do you think of my counter-proposal below? —sroc 💬 14:11, 18 May 2015 (UTC)

• Support This will only have positive effects.Bosstopher (talk) 13:11, 18 May 2015 (UTC)
• Support As per above. A no-brainer IMO. Regards  Aloha27  talk  13:13, 18 May 2015 (UTC)
• Support I don't know if there's something in the water but there seem to be more and more non-English articles turning up at NPP (or simply I'm noticing them more), and investigating why people are not inclined to put them in the right language Wikipedia is probably also worth investigating. Ritchie333 ^{(talk) (cont)} 13:52, 18 May 2015 (UTC)
• Support as per above. But are there any non-English articles in mainspace, or is this preventive? Robert McClenon (talk) 13:54, 18 May 2015 (UTC)

@Robert McClenon: See Category:Wikipedia articles needing translation. Winner 42 Talk to me! 13:58, 18 May 2015 (UTC)

• Support This is a fairly common sense proposal. It is preferable to the current status quo of tagging them for translation and leaving them in article space. Winner 42 Talk to me! 13:58, 18 May 2015 (UTC)

@Winner 42: So move them and tag them. We don't need a policy for this. See my counter-proposal below. —sroc 💬 14:11, 18 May 2015 (UTC)

• Support, I have seen non-English articles in mainspace before, most of which get mopped up in the NPP process. I have also seen articles that have been vandalized and left with completely non-English text for months though, so I would add the cautionary note of "any editor who is preparing to move a non-English page to the draft namespace must check the edit history to see if there is an English version that can be restored". Lukeno94 (tell Luke off here) 14:26, 18 May 2015 (UTC)
• Support. Duh. This is the English wiki, if someone wants an article in a different language, it should be directed to that language's wiki. GregJackP Boomer! 15:19, 18 May 2015 (UTC)
• Support. Lingua anglicana est universale.--Sigehelmus (talk) 22:55, 18 May 2015 (UTC)
• Support it really is a no-brainer. Get them into draft space so they can be translated and verified more easily. Fyunck(click) (talk) 04:53, 22 May 2015 (UTC)
• Support any other policy only creates more work and time put on the back of volunteer editors. I have enough trouble now assessing potential vandalism articles or good faith reversions when I cannot assess the content because I speak English (and Haitian, but no haitian topics have come across my path). Even assessing articles written with heavy jargon related to video gaming are difficult for me to assess without the proper vocabulary!  Bfpage |leave a message  21:00, 9 June 2015 (UTC)

• By that logic, any page on any topic in any language that a particular person may not be able to understand, should be automatically moved to the draft space? You may not be able to understand it, but other people can when they are informed of it - i.e. the current process--Jac16888 ^Talk 21:01, 11 June 2015 (UTC)

Jac16888 Absolutely, let it be checked first , in draft space, by those that understand it, to make sure it's fit for article space. If it is, translate it and move it over into article space. It's not much different from how we tell people to construct articles, first in draft space, then as an article. KoshVorlon Rassekali ternii i mlechnye puti 16:06, 19 June 2015 (UTC)

English policy: Oppose

• Oppose creating a new policy to say we can do this. There is nothing in any policy that says we can not move (not cut and paste) an article that is not ready from the mainspace to the draft space. An article that is not written in English is not ready for the mainspace so there is nothing stopping us from moving it. The creator should be notified where the article was moved to and why, so they can work on it. -- GB fan 12:14, 18 May 2015 (UTC)
  • Well that's an option too: we don't need a policy for this, if an editor is still allowed to move an article into draftspace for the main reason that it's not in English. — Jeraphine Gryphon ^(talk) 12:31, 18 May 2015 (UTC)
• Oppose the proposed policy as unnecessary. I have an alternative proposal set out below which I think is a lot simpler and easier to implement. —sroc 💬 14:05, 18 May 2015 (UTC)
• Oppose This is a good example of an idea with a lot of merit, but some flaws that need addressing. A candidate for the Idea Lab to work out the kinks before asking for an up or down vote. Examples of kinks:
  • Suppose I run across an article in mainspace in another language, which when translated, is absolute gibberish, and qualifies as a G1. Of course, after moving to draft space I can delete it as a G1, but this policy, as written, requires that I move it to draft space first. If I do not, I am potentially santionable for violating policy.
  • Rinse and repeat for an article which is a clear copyvio, but in another language.
  • Or an article which is an attack. Yes, this could be fixed, but there are other issues to address. It states that the article will be moved to draft to verify that the article in question doesn't violate copyright . Moving an article to draft space doesn't solve the copyright problem. We don't have an exception that allows copyvios in draft space. There are other issues as well, so it isn't the case that a couple minor copy edits will make this acceptable as is. That said, it has promise.--S Philbrick(Talk) 14:57, 18 May 2015 (UTC)
    • These are problems that we already have. Currently it's not possible to speedy an article simply because it's non-English, and often that's a problem because we can't tell whether the article complies with policy or not. It could be blatant vandalism but we have to keep it for at least two weeks until someone can identify what we're dealing with. Moving that kind of an article out of mainspace (and to somewhere where search engines can't find it) is a good compromise. — Jeraphine Gryphon ^(talk) 15:07, 18 May 2015 (UTC)

Yes, it is possible to speedy an existing article in another language. (After re-reading, I guess you are saying that simply being in non-English is not a sufficient reason for CSD, but as I'll explain, I can identify valid CSDs even though my language skills are minimal.) I can tell that something is a copyvio if it is clearly an exact copy of a published item. Google translate is deficient for some purposes, but if Google Translate produces John Doe is a well-know child molester I don't need a competent human translator to tell me it can be deleted. If the article is created by a banned or blocked user, I don't even need to translate the content. Yet, this proposed policy says I should move it to draft space first. Why?--S Philbrick(Talk) 16:57, 18 May 2015 (UTC)

Does it really say that? That you must? I'm not seeing it. If you can tell that an article qualifies for speedy then of course you can speedy it, I don't think anyone would argue that. Though in cases like this you may have to leave a note behind explaining how it qualifies, if it's not immediately obvious to admins who do the deleting. — Jeraphine Gryphon ^(talk) 17:03, 18 May 2015 (UTC)

• Oppose as unnecessary bureaucracy. Speaking as one of the half dozen or so editors who handle non-English articles at PNT every single day, we always deal with these articles in the best and most efficient way possible. This can be one of many ways, sometimes they're translated, becoming valuable articles, sometimes they are speedy deleted if they meet a criteria (and yes I'll admit that I usually IAR delete the essays and rants we often get), sometimes they are prodded/blpprodded or afd'd if we think they're not worth translating, if we think they are worth an article but can't translate them ourselves we leave them (and after two weeks they are prodded and deleted it not translated) and yes we sometimes userfy them if we feel they were created in good faith and that . To just point out how small a problem this is, currently there are 6 articles (out of 6,832,583) that are entirely not in English, 3 of which are currently prodded. Trying to enforce a firm rule that all non-English articles be immediately userfied is just overkill, and a good way to prevent potential good articles, the current system works just fine, the article which started this whole drama-fest being a perfect example.--Jac16888 ^Talk 17:18, 18 May 2015 (UTC)
• Oppose per WP:CREEP. We already have processes for non-English articles. While they are not perfect they work well enough, better than this clunky idea would anyway. Beeblebrox (talk) 18:04, 18 May 2015 (UTC)
• Oppose per Jac16888 who says the current system is working fine. Also, we assume good faith until shown otherwise. We don't assume the article may be "dodgy" just because we can't read it. SpinningSpark 18:22, 18 May 2015 (UTC)
• Oppose There is already an established procedure for translating non-English articles, Wikipedia:Pages needing translation into English. This happened to me once. I created a new article by copy-pasting the French language version, then proceeded to translate it in place. I expected this to be a quick task, but got sidetracked and then interrupted by an offline event. (I should have created it in the draft space, but this requires an admin request.) For my trouble I got templated that I should first list the article for translation, and then come back and translate it. Hawkeye7 (talk) 20:07, 18 May 2015 (UTC)

* Comment Actually it doesn't require admin permissions. I've created a draft space article and I'm definitely not an admin. KoshVorlon Rassekali ternii i mlechnye puti 20:14, 18 May 2015 (UTC)

Even IPs can create draftspace pages. o_O — Jeraphine Gryphon ^(talk) 20:16, 18 May 2015 (UTC)

True! But unfortunately moving the draft article to the mainspace causes a redirect to be left behind, which then requires a CSD (admin request) to delete. So I try to avoid this whenever I possibly can. Sorry, I did not make myself clear. Hawkeye7 (talk) 02:53, 19 May 2015 (UTC)

Redirects from draftspace to mainspace are okay. AFC reviewers leave them behind all the time. — Jeraphine Gryphon ^(talk) 09:06, 19 May 2015 (UTC)

@Hawkeye7: When moving an article there is an option to not leave behind a redirect = uncheck the "leave a redirect behind" box. --User:Ceyockey (talk to me) 00:42, 22 May 2015 (UTC)

@Ceyockey: Not true if you aren't an admin. Though I have been pushing for allowing this permission for non admins recently, it has been met with resistance. EoRdE6^{(Come Talk to Me!)} 00:45, 22 May 2015 (UTC)

@EoRdE6: Ahhh. I did not realize this was an admin-only function. Apologies and thanks for highlighting that. --User:Ceyockey (talk to me) 00:58, 22 May 2015 (UTC)

• Oppose revoking WP:PNT#Standard procedures without the proposer either acknowledging its long-standing acceptance or notifying the page that he hopes to revoke it (perhaps he just didn't know that it exists? Nobody can keep up with everything around here, because there are so many pages). In fact, most of the above "votes" don't seem to know that we have a procedure for handling such pages. I expect they all would have guessed that "edit-war to blank the page" isn't it, though. Jeraphine, Yunshui, IJBall, Od, Bosstopher, Aloha27, Ritchie333, Robert, Winner, Luke, Greg, I'd be interested in knowing how many of you were aware of the standard procedure before this discussion, and whether you think that years-old advice is probably an adequate approach, or if you still think we need yet another policy or guideline for the occasional article that isn't written in English. WhatamIdoing (talk) 21:39, 18 May 2015 (UTC)

I was aware of the standard procedure when !voting, and have looked at and speedied persian article on WP:PNT from time to time. I voted under the assumption that if this passed, PNT would still function, only pages translated would be temporarily moved to draftspace first. This seems like the most common sense solution.Bosstopher (talk) 21:50, 18 May 2015 (UTC)

I can see why a reasonable person might hope for that, but this policy would actually preclude the standard procedure. The proposed policy prohibits leaving a non-English article in the mainspace for two weeks (= it prohibits "the standard procedure"). The editors at PNT do not handle articles anywhere else (by choice, and those WP:VOLUNTEERS are the only ones who get to make that choice). It is not possible to have "the new policy" and "the standard procedure" operating at the same time. "There must never be articles needing translation in the mainspace" and "We only translate articles in the mainspace" cannot function at the same time.

The potential for confusion is why I'm unhappy about the failure to be more explicit about the policy's effects. I am worried that some people are voting for a benign-sounding, commonsensical statement without understanding that the intended outcome is to eliminate a long-standing process. This proposal amounts to revoking PNT's standard procedure, although it doesn't come out and say so in ways that will be clearly understood by everyone. If you want to change an old process, that's fine, but IMO you should say so, using words that cannot possibly be misunderstood (e.g., "I propose stopping the bad old way and replacing it with this obviously better idea:").

The immediate history also gives me pause: The precipitating incident is that the proposer blanked an article (three times in three hours, if the comment below is correct) and was told that the standard procedure is to tag it and wait for two weeks. He was not satisfied with waiting for two weeks, so he proposes here a policy to override it. However, he does not mention the existing standard procedure. He gives only the briefest mention that he lost a dispute because of it. The sole practical effect of his proposed policy is to revoke the process that caused him to lose the dispute. He makes no acknowledgement of how this proposal affects longstanding processes. I've spent years around policy pages, and I can tell you that this situation is a fairly reliable recipe for disaster and drama. If you want to kill an old process, then you need to tell to people that you're doing it.

Note that I don't mind changing old processes, if that's what people want to do. I've done it myself. My only requirement is that supporters understand that's the point of the proposal and say that they're intentionally replacing an old process. WhatamIdoing (talk) 23:38, 18 May 2015 (UTC)

I think it's very simple to keep the old and new processes in place at the same time. You just apply all the same rules to the drafts that you would to non english articles, and speedy them if no one translates after two weeks. A venue for translation is still maintained and you don't end up with old non-english articles on god-knows-what languishing about in draftspace. Best of both worlds.Bosstopher (talk) 23:46, 18 May 2015 (UTC)

1. This proposal doesn't actually do what you want it to do. (The alternate below does something close, but the original does not.)
2. In my experience it is never "simple" to force volunteers do things that they do not choose to do, and the volunteers at PNT have already said that they have no interest in doing what you want them to do. WhatamIdoing (talk) 01:43, 19 May 2015 (UTC)

First of all I am someone who volunteers from time to time at PNT (as is GregJackP who supported the proposal and responded to you below), and in my capacity as someone who does so I believe its better to not have completely non-english articles languishing about in mainspace, and I would completely willingly move non-english articles to draft space. Also can you point me to exactly where the collective you refer to as the "volunteers at PNT" have unanimously opposed this decision? As for the proposal not doing what i think its supposed to do, this seems to be another example of an incredibly simple and beneficial change being bogged down in Village pump bureaucracy. I'm sure the closing admin will be able to interpret what I mean.Bosstopher (talk) 16:48, 19 May 2015 (UTC)

I base my statement about the volunteers at PNT on the comment below: "There is a long-held consensus, re-affirmed just a few weeks ago, at PNT that draft articles do not fall within our scope of work..." by User:Jac16888. WhatamIdoing (talk) 17:13, 19 May 2015 (UTC)

Thanks for directing me to that. Although I'd forgotten about it, I actually took part in that discussion and at the time (although I didnt write it because enough other people had) was opposed to the idea of putting all non-english drafts in PNT. However, I think this case is very different to that, as only drafts that were intitially posted in article space would be brought to PNT for temporary holding, as opposed to any gibberish written in draftspace. I think it's an apples and oranges situation. Bosstopher (talk) 20:22, 19 May 2015 (UTC)

I was aware also, and have tagged many such articles. I've also watched articles not be translated for significant periods of time. However, I don't think that we need to keep articles which are not written in English. BTW, your comment was very condescending, I guess us mere non-WMF editors wouldn't have thought of other options. GregJackP Boomer! 22:53, 18 May 2015 (UTC)

It's worth noting that the existing standard procedure predates the existence of the Draft namespace, and therefore might be due an overhaul with the new option in mind. That's probably something for the appropriate talkpage, though. It's my opinion that the suggestions offered here, especially the alternative version below, constitute an improvement on the current process. Yunshui ^雲_水 07:50, 19 May 2015 (UTC)

• Oppose Over at Wikipedia:WikiProject Anime and manga we use a template called Template:nihongo, not everything should be in English per WP:BIAS. - Knowledgekid87 (talk) 23:59, 18 May 2015 (UTC)
• Oppose I agree with Beeblebrox that this is nothing but WP:CREEP. There is no need to have a policy or guideline to state that the English Wikipedia should in English. —Farix (t | c) 00:31, 19 May 2015 (UTC)
• Oppose (a) the proposal incorrectly implies that there is a single english language and (b) articles have very good and well established grounds for using non-English languages (be it Japanese, Arabic; Latin or native american languages) in places (alternative names, linguistic examples, etc, etc); many articles would be significantly impaired with those. Stuartyeates (talk) 10:43, 19 May 2015 (UTC)
• Oppose per several comments above. Most notably, we already delete or translate articles written in foreign languages, so this proposed policy does not actually accomplish anything. As such, it is unnecessary WP:CREEP. Resolute 14:10, 19 May 2015 (UTC)

• Comment Knowledgekid87 Bias huh ? Note the proposal is for articles not templates (I'm also a self-described Otaku :) ) TheFarix I actually agree, this shouldn't have to be policy, I would have thought it common sense, however this little incident told me otherwise. SpinningSpark AGF is not a suicide pact, further, author editors, even in good faith sometimes run afoul of copyright concerns because they're not aware of how ours works (and BLP as well ). KoshVorlon Rassekali ternii i mlechnye puti 15:42, 19 May 2015 (UTC)

• The template makes both Japanese and English text appear on the page, we also have Japanese names as article titles and as character names (as such the name would be included in the article's body) per WP:COMMONNAME. By all in English do you mean all content of a given article? I want to have an open mind but please specify as it sounds too broad if I read "All entries in article space need to be in English" right. - Knowledgekid87 (talk) 16:29, 19 May 2015 (UTC)
• @KoshVorlon: I would support your proposal for entries that are written fully in another language or a certain percentage of the article, there has to be some kind of footnotes/exceptions though if this is to become policy. - Knowledgekid87 (talk) 16:40, 19 May 2015 (UTC)

Kosh, you continue to refer to your "little incident" as why this change needs to be made, and yet the article which started all of this (Detective Willy for anyone not already aware), was, once properly reported to PNT, translated and then prodded within a few hours of being created, similarly a dozen+ other articles have been created and dealt with in the time since then - I don't see how any of this is problematic. If anything your incident shows that, when procedure if actually followed, the system we have works great --Jac16888 ^Talk 20:41, 19 May 2015 (UTC)

• "Hard cases make bad law" or in this case bad policy/guidelines. It's clear in that discussion that you didn't follow already existing procedures for handling such types of articles. But I honestly don't see the need for a policy over just one incident. —Farix (t | c) 20:20, 19 May 2015 (UTC)

• Oppose. If it ain't broken, don't fix it. The current process is working fine, and no non-English article is kept any longer than necessary. De728631 (talk) 18:30, 19 May 2015 (UTC)
• Oppose: no pressing need to adopt an English only policy for the first appearance of an article. A working proceedure is in place. — Neonorange (talk) 21:22, 19 May 2015 (UTC)
• Comment For those opposing, please see this recent posting to WP:AN where the the reverse happened. Just so I'm totally clear, I'm not suggesting that if we have an article about a Japanese term, or a Spanish term, that we can't use the Spanish or Japanese word itself, nor am I suggesting that that word be written out in the English alphabet. What I'm suggesting is that any article in article space needs to be in English, currently we're getting entries in article space that are 100% not English. I'm suggesting that they be placed in draft space where they can be translated , then judged to be in compliance with all applicable Wikipedia policies and guildelines. That's it, simple, obvious and very much common sense. KoshVorlon Rassekali ternii i mlechnye puti 11:00, 20 May 2015 (UTC)

You mean the posting which shows that when a non-english article is submitted to the proper place, it is dealt within just a few hours? A perfect example to me of how well the current PNT system works, when of course it it is actually used rather than ignored--Jac16888 ^Talk 16:32, 20 May 2015 (UTC)

Except that article space is the wrong place for non-English articles. So no, it wasn't in the proper place. KoshVorlon Rassekali ternii i mlechnye puti 16:42, 21 May 2015 (UTC)

Not sure if you're intentionally misunderstood my point there or not. By "proper place", I mean PNT, as in, a user followed procedure and logged it there, and then it was resolved shortly afterwards. In fact had you done so yourself, or had you actually moved it to the draftspace properly (that being one way we do deal with non-english articles already anyway), there would have been no issue. I feel I have to ask this, as you've never actually addressed this: please can you tell me that you understand why blanking a page or copying and pasting it to another place is a bad thing--Jac16888 ^Talk 17:00, 21 May 2015 (UTC)

Jac16888 - yeah, I did. I consider article space to not be the proper place for articles not in English, rather I'd say Draft space is. The article was in article space when I first ran across it. Yes, I agree PNT acted correctly by translating the article, I wasn't trying to change the process that got the article translated, rather the fact that the article should have been in article space prior to translation. KoshVorlon Rassekali ternii i mlechnye puti 15:29, 22 May 2015 (UTC)

• Oppose - you lost me at "Further, most of the users on this Wikipedia do not read any other language." That's absurd. Where did you get this information? I don't remember indicating what languages I can read when I created an account. It seems that, because you can't read any other languages, you assume everyone is the same? Otherwise why would you assume this? Further, how often are there articles that are entirely in another language that are not copyright violations or able to be removed for another basic reason? Why is this policy necessary? I looked at the ANI you suggested as cause for the proposal and I agree with Jac16888 - your insistence that you should be able to blank a page because it's in another language is not sound. It's laziness at best, censorship at worse. —Мандичка^YO 😜 00:28, 22 May 2015 (UTC)

Actually, what I mean is the language of this Wikipedia is English. I see your name is in Russian (ok, Cryllic , so it might not be Russian as other languages use the Cryllic Alphabet ) assuming you ARE Russian, would it make sense to have an article in ru.wikipedia.org in English rather than in Russian, even though there may be people on that Wikipedia that read English ? Of course not, it's common sense, the lingua franca on that Wikipedia is Russian, just the the lingua franca on this wikipedia is English. Articles should conform to the lingua franca, obviously there may be portions of the article that need to be in a different language (reliable references in other languages, a term in another language that needs to be in. That kind of thing. ). What we should not have in an article of any sort , written completely in another language. KoshVorlon Rassekali ternii i mlechnye puti 15:29, 22 May 2015 (UTC)

What irks me more is how we have maps that are written in different languages being used (Examples: Battle maps, road maps, ect...). Yeah the maps are encyclopedic but unless you speak the language there is no way to understand them. - Knowledgekid87 (talk) 15:54, 22 May 2015 (UTC)

A good caption on the map can usually address that problem adequately. There's also a brand-new tool for making charts and maps (links at Wikipedia:Graphs and charts#Vega) that should make it much easier to translate vector-based maps. WhatamIdoing (talk) 17:32, 22 May 2015 (UTC)

• Oppose: We don't need a WP:POLICY for this. That's overkill. Userspacing or deleting these things is already standard operating procedure. [PS: The expression is "blindingly obvious", not "blindly obvious"; it's a metaphoric reference to a very bright light.]  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  09:47, 24 May 2015 (UTC)
• Oppose per WP:CREEP. VQuakr (talk) 03:45, 30 May 2015 (UTC)
• Oppose PNT works pretty well as far as I have seen, don't fix what ain't broke. This proposal also seems kind of pointy to me. Fyddlestix (talk) 23:19, 31 May 2015 (UTC)
• Oppose as per [[U|S Philbrick)), Wikimandia, Jac16888 and others above. This is WP:CREEP. It is a solution in search of a problem. Copyvios and attwack pages are no more to be tolerated in Draft: than in article space, so moving to draft is not an answer mto a fear of such problems alipping past undetected. As others have noted, google translate while not good enoguh for finished articel prose, should enable a patroller to detect attack pages and other blatant policy violations, and the copyright detection tools still work on non-english text, as I understand it. I havn't seen any reasons why our current procedures aren't workign or need to be changed. And I understand that the volunteers at WP:PNT don't want their remit changed/broadened to include or consist of the Draft namspace. I see no good reason for this. DES ^(talk) 02:15, 18 June 2015 (UTC)
• Oppose Yes, it may seem reasonable, but we already deal with the problem. Articles not in English get translated or removed, or moved to userspace. Discussions already are required to be in English. We need to eliminate unnecessary rules, not add to them.DGG (at NYPL) -- reply here 14:59, 20 June 2015 (UTC)

English policy: Discussion

• Why is this necessary? We already have Wikipedia:Manual of Style § National varieties of English ("The English Wikipedia prefers no major national variety of the language over any other") and Wikipedia:Pages needing translation into English ("This version of Wikipedia is written in English") for example, and it's inherent in the fact that this is the English Wikipedia (there are other language varieties). Is this really a problem? Or a solution looking for a problem? —sroc 💬 11:50, 18 May 2015 (UTC)

I can see that KoshVorlon had an issue (Wikipedia:Administrators' noticeboard § Behavior of Jac16888) after blanking (three times in three hours) the article Detective Willy which was written in Spanish (it was translated into English within two hours afterwards).

Wikipedia:Pages needing translation into English (WP:PNT) provides a process encouraging translation before hasty deletion, which may be a useful approach. It worked for the above-mentioned article and, if the article survives proposed deletion on notability grounds, it will be a good addition to Wikipedia. PNT isn't a policy or guideline, but if the policy proposed here were adopted, it would need to be completely re-worked. Accordingly, I have flagged this discussion on its talk page (Wikipedia talk:Pages needing translation into English § Proposed policy to move articles in foreign languages to draft space).

—sroc 💬 12:36, 18 May 2015 (UTC)

I don't see why an article could not both be (1) moved into draftspace and (2) listed at PNT. Wholly non-English articles where it's hard to even determine the subject, are not ready for articlespace, and they shouldn't be immune from our usual deletion criteria (like A7) simply because we can't understand what's going on in those articles. — Jeraphine Gryphon ^(talk) 12:42, 18 May 2015 (UTC)

@Jeraphine Gryphon: I don't think Wikipedia:Criteria for speedy deletion § A7. No indication of importance (individuals, animals, organizations, web content, events) necessarily applies just because an article is in a foreign language; however, you're quite right that an article which has no (or barely any) English-language content doesn't belong in article space. Wikipedia:Deletion policy § Alternatives to deletion §§ Incubation can be applied to move them to draft space while they are being re-worked.

I note that some of the articles listed at Wikipedia:Pages needing translation into English § Pages for consideration have some English-language content and some foreign-language content requiring translation, so these would not be ripe for deletion and leaving them in article space may attract users to bring them up to grade. There are some articles, however, that are entirely in a foreign languages and have been listed for some time:

• Shkolla fillore 7 marsi (since 25 April, 23 days ago)
• SMK Permas Jaya (since 29 April, 19 days ago)
• ئه‌شكه‌وتى پاڵى گه‌وره‌ (since 1 May, 17 days ago)
• Les Pétards (since 3 May, 15 days ago)

That's just the ones that are over the two-week period. This shows that while the system can sometimes work quickly (as in the case of Detective Willy), articles can languish in article space waiting for attention. This being the case, I would support WP:PNT being revised to encourage moving articles to draft space until they are translated, perhaps then allowing a longer period before nominating them for deletion to give them a better chance of being salvaged. I'm not convinced this needs to be enshrined in a separate policy, however. —sroc 💬 13:43, 18 May 2015 (UTC)

• This has nothing to do with varieties of English. — Jeraphine Gryphon ^(talk) 12:30, 18 May 2015 (UTC)

• Question: Will this be appended to, or be a new part of, the pre-existing WP:ENGLISH? Or will these be merged together? If not, how will this work?... --IJBall (talk) 12:33, 18 May 2015 (UTC)

IJBall I'd suggest making this part of WP:ENGLISH. KoshVorlon Rassekali ternii i mlechnye puti 13:03, 18 May 2015 (UTC)

Sroc You're right. That's what started this proposal. KoshVorlon Rassekali ternii i mlechnye puti 13:03, 18 May 2015 (UTC)

WP:ENGLISH is actually Wikipedia:Naming conventions (use English), which I see as interpreting Article titles policy, so I don't think it can simply be appended there -- at least not without additional changes. This new rule would apply to the whole article, more like WP:MOS. I see this new rule as based more on the policy Wikipedia:What Wikipedia is not or Wikipedia:Wikipedia is an encyclopedia, where the English-language Wikipedia should be defined as written in English. --Boson (talk) 13:40, 18 May 2015 (UTC)

I agree that this should not be part of Wikipedia:Naming conventions (use English). There's a section Wikipedia:Drafts#Incubation which discusses moving articles from mainspace to draft space. Maybe a paragraph about when this is appropriate could be added there, including pages not in English.—Anne Delong (talk) 13:47, 18 May 2015 (UTC)

Suggestion: As this is the case, I suggest that the new policy's "shortcut" should become "WP:ENGLISH" if adopted, and the "old" WP:ENGLISH's shortcut should become something line WP:ENGLISHTITLE or some such... --IJBall (talk) 13:53, 18 May 2015 (UTC)

WP:ENGLISH is a bit vague, and WP:ENGLISHTITLE may be better. However, a new policy may not be needed; instructions to move pages awaiting translation to Draft space can be added at Wikipedia:Pages needing translation into English#Standard procedures.—Anne Delong (talk) 13:59, 18 May 2015 (UTC)

WP:ENGLISHNAME would also work. --IJBall (talk) 14:02, 18 May 2015 (UTC)

Changing the target of shortcuts if often a bad idea, because previous usages of the shortcut will then all point to the wrong target. — Jeraphine Gryphon ^(talk) 14:33, 18 May 2015 (UTC)

Yes, agreed. But if this proposal passes, I think it may be warranted. At least, it should be discussed. --IJBall (talk) 15:54, 18 May 2015 (UTC)

I think changing the description of the process would be better than a "policy" change, but am still wondering about whether any change in normal practice is necessary. In any case, it might be appropriate to change WP:English into something like a disambiguation page pointing to a number of pages that also deal with the use of English (e.g. pages needing translation, diacritics, transliteration etc.).--Boson (talk) 19:27, 18 May 2015 (UTC)

Or at least to add a hatnote to ENGLISH that directs people to WP:PNT#Standard procedure. WhatamIdoing (talk) 23:42, 19 May 2015 (UTC)

 Comment: In at least one country where English is the most widely used language, requiring English, or mandating English is a politically fraught topic (see English First). Also in en.Wikipedia, it seems. Better to ease along with what has worked for 5,000,000 articles. — Neonorange (talk) 02:22, 31 May 2015 (UTC)

I hope no-one minds that I've fixed a typo in the above proposal, and made the wording of one sentence a bit clearer: it had said "a language that cannot be read on this Wikipedia (i.e. English)", which made it sound like English was a language that could not be read on this Wiki. [1] -sche (talk) 17:39, 6 June 2015 (UTC)

The proposed new policy is unnecessary and would conflict with existing processes, such as Wikipedia:Pages needing translation into English (WP:PNT), which would then need to be re-worked. Instead, in order to streamline things and avoid fracturing, I would recommend amending WP:PNT to change the process for dealing with articles entirely (or almost entirely) in foreign languages as follows:

1. Move the article into the Draft namespace.
2. List the article at Wikipedia:Pages needing translation into English § Pages for consideration.
3. Articles that are not likely to survive may be proposed for deletion according to the usual deletion policy or speedy deletion criteria to the extent that they apply to drafts (see Wikipedia:Drafts § Deleting a draft).

—sroc 💬 14:03, 18 May 2015 (UTC)

I'd like to take this opportunity to acknowledge KoshVorlon's insight in highlighting this issue and getting the discussion going.

I would like to add that my proposed process doesn't need to be mandatory: if an article in a foreign language is obviously a copyvio, vandalism, etc., it can be sent straight to speedy deletion as usual without having to be moved to Draft first. This process is intended for articles that could survive if they are translated into English. —sroc 💬 17:08, 18 May 2015 (UTC)

• Support - Not because I disagree with us KoshVorlon's idea, but because we don't need a policy, we need a process. As a new page patroller, I routinely move articles to draft space as an alternative to deletion, or as an alternative to leaving really incomplete content in article space. If either of these proposals passes, someone should follow up with the Twinkle developers to make sure that this multi-step process can be semi-automated.- MrX 14:35, 18 May 2015 (UTC)
• Support I'd be equally happy with this proposal (and hear hear to getting the process Twinklified). Yunshui ^雲_水 14:39, 18 May 2015 (UTC)
• Support Has the same net effect as the above policy, but is a more efficient implementation. Per MrX I would like to see Twinkle support moving articles to draft space more easily. I would also like to here other editors thoughts on moving other types of very-low quality articles by new editors into draft space without going through AfD to do it. Winner 42 Talk to me! 14:44, 18 May 2015 (UTC)
• Support – OK, this sounds good as well. --IJBall (talk) 15:57, 18 May 2015 (UTC)
• Support It seems clear that KoshVorlon's idea is based on an actual problem (and not an imaginary one) but I am skittish about adding still more rules to Wikipedia's already large collection. This looks like it would dovetail well with the existing structure. Also, "most, if not all read no other language"? Mis seis años de clases de español no están de acuerdo contigo. WP:COMMONSENSE already covers the idea that the English Wikipedia must be in English, and this looks like it would protect Wikipedia from copyright violations without overdoing it. Darkfrog24 (talk) 16:15, 18 May 2015 (UTC)
• Oppose As noted above, there are articles entirely in non-English that may qualify as a CSD. If this policy is approved, it means if I find an article in Spanish written by a banned user, I cannot simply delete it as a G5, but I must first move it to Draft space. This is the very definition of silly bureaucracy. On a more general note, what is the reluctance to use the Idea Lab to sort out a sensible approach?--S Philbrick(Talk) 17:05, 18 May 2015 (UTC)

  This would not be a policy. It would be a process that you can choose to use, or not. Neither this nor the previous proposal would prevent other deletion processes from being used as needed. You say that this is the definition of a silly bureaucracy, but suggest sending it to the Idea Lab. Irony?- MrX 17:23, 18 May 2015 (UTC)

@Sphilbrick: Are you saying this to oppose Kosh's proposed policy or my proposed amendment to WP:PNT? Articles could still be deleted without being moved to Draft first, at least with my proposal, so your reasoning doesn't hold. —sroc 💬 17:58, 18 May 2015 (UTC)

Given that the original was proposed as a new Policy, and this is labeled as an Alternate proposal, I thought it was intended to be alternative proposal for a policy. I now see it is an alternate proposal for a rewording of a process, so it doesn't contain the same weight as a policy. Still, my objection remains. The proposal step one says Move the article into the Draft namespace. I disagree. I'd start with Determine whether it qualifies as a CSD as is.If not, or indeterminate, move into the Draft namespace But this is OTTOMH and could use word smithing. Re "irony" I think it is misplaced. I am a big fan of bureaucracy, when sensible. We ought to have well-thought out rules for handling solutions, and well-thought out processes for dealing with issues. What I oppose is mindless bureaucracy, such as moving an article to Draft space, then deleting it when it is perfectly obvious it should be deleted as is. The entire concept of the Idea Lab is that it is difficult, if not impossible, to write up new Policies, and there ought to be a place to work on them, and get them ready for an up or down vote. Both the original and the alternate proposals qualify. Neither were ready for prime time. Both has some good ideas that I could support if the issues were addressed. The Idea Lab is intended as a place to address them. I get why people want to come here first, because they think their idea is so good it can be supported exactly as worded, or maybe with a tiny word change, but they miss that it often takes a robust discussion of issues to come up with good wording for a new proposal. This is more true today than it was in the early days of WP, when there was so low-hanging fruit, and it might have been reasonable to slap together a policy and approve it.--S Philbrick(Talk) 18:09, 18 May 2015 (UTC)

@Sroc: I oppose the policy proposed by Kosh as written, for the reasons I outlined (and there are more objections, I just didn't think it was necessary to be exhaustive.) I oppose the alternative wording of WP:PMT. The existing process has a set of steps for entire articles. Your proposed step 1, which presumably replaces the existing step 1, says Move the article into the Draft namespace. Maybe you think it is implicit that you can delete via CSD before this step, but that's not what it says.--S Philbrick(Talk) 18:16, 18 May 2015 (UTC)

@Sphilbrick: Nothing in my proposal seeks to usurp current deletion policy, and I've expressly said in my further comment that articles could still be deleted as usual without having to move them to Draft namespace first. I haven't set out the exact wording as I was just seeking ro assess general support—the exact implementation might be put to an RfC if necessary—but I was especially hoping to point out that although Kosh's intentions were good, that doesn't mean we have to leap to the first proposal (i.e., a new policy) and alternatives should be considered. —sroc 💬 19:08, 18 May 2015 (UTC)

• Oppose also per WP:CREEP. We don't need a new policy, or a new process. And I do not like setting a precedent that anyone can just move an article into draft space on a whim, that will put us on a slippery slope. The correwct way to currently deal with such issues is to put the great big ((translate)) tag on the article, list it at pages needing translation, and add one the appropriate tag from WP:PNT/T to the creating user's talk page. I don't see how temporarily hiding it in the draft namespace on top of all that is any better. Beeblebrox (talk) 18:12, 18 May 2015 (UTC)

I don't disagree with @Beeblebrox: on many things, so I'm probably wrong here, but I wouldn't mind if we were more aggressive in moving articles into draft space. However, I'd prefer to do it as part of a comprehensive overhaul of the review process, in which articles which aren't quite ready for prime time were moved to Draft space, and I see articles written in a foreign language (which are otherwise not eligible for CSD) as an important special case. However, I worry that Draft may become a wasteland, so I wouldn't support it unless we had some good processes for clearing it out. I'm struggling with this because my position is closer to Kosh's and Sroc's than my opposes may suggest. I, too, have run across articles in main space, written entirely in another language, and thought that moving them into the Draft space might be a good next step. But while I can think of such examples, getting from a couple examples to a policy or even a process is trickier than some seem to realize.--S Philbrick(Talk) 18:25, 18 May 2015 (UTC)

@Beeblebrox: My counter-proposal is not really a "new process" but refining an existing one. In fact, moving an article to Draft namespace may save potential articles that just need to be translated that might otherwise be hastily deleted just because the current (arbitrary) two-week time limit has passed. —sroc 💬 19:12, 18 May 2015 (UTC)

I now see the language in wp:PNT I had missed earlier Articles that are not in English are still subject to all other forms of speedy deletion should they meet the criteria. That mitigates my concern, but emphasizes the need to improve that page. When I see a process page with a list of steps, it seems reasonable that I should start with step 1.

In fact, one is expected to carry out some unnumbered steps first, which I will number, with the smartaleck convention of keeping the existing numbering intact:

Step -2: If someone speaks the language the article is written in and can state that it is not worth translating, the item should be moved to AfD or tagged with ((prod))

Step -1: If the article is a mere copy of (all or part of) an article in a foreign-language Wikipedia, it can just be tagged with ((db-foreign)) to get added to Wikipedia:Candidates for speedy deletion

Step 0: Check to see if other CSD criteria apply

Step 1 (existing): Use the notice ((notenglish|NameOfLanguage)) ...

Step 1 (proposed by you):Move the article into the Draft namespace.

Did you ever read the book Onion John? (I loved it, my daughter hated it), John waswanted a barn door hinge for the door on his house, because the wood is so rotten, standard house hinges won't hold. The town decides that they shouldn't just do the minor fix, they should replace the whole house. It goes badly. Which is unfortunate for me, because I'm looking at your proposed replacement of step 1 with a different step, and I'm noticing that the house is falling down, and think we ought to fix the house, while the lesson in the story is that this approach ends badly. So I don't know what to do, but I am still unhappy about tinkering with a process and ignoring the glaring problems.--S Philbrick(Talk) 20:35, 18 May 2015 (UTC)

@Sphilbrick: I haven't read that book, but I see your point. I agree WP:PNT could use some work and can probably be simpler to follow. I would support a re-working of WP:PNT to solve the underlying issues and incorporate the use of Draft namespace (at whatever stage); I think that would be more productive than a new policy (which would only make WP:PNT harder to follow).

The comments here suggest an emerging consensus that: (1) something needs to be done to prompt utilising the Draft namespace for articles in languages other than English that need attention before being re-admitted to article namespace; (2) a new policy is not necessary or desirable to achieve this; (3) WP:PNT should be re-worked to address this (amongst fixing the barn generally). Perhaps this should be workshopped on the Wikipedia talk:Pages needing translation into English talk page? —sroc 💬 21:27, 18 May 2015 (UTC)

• Oppose per Beeblebrox and SPhilbrick. GregJackP Boomer! 19:19, 18 May 2015 (UTC)
• I feel I need to make another clarification here in regards to this counter-proposal, it will read a bit odd at first, but bear with me. WP:PNT is not a translation project (keep going): it is an article crisis-centre, along the lines of Wikipedia:Copyright problems, Wikipedia:WikiProject Unreferenced Biographies of Living Persons, Wikipedia:Reliable sources/Noticeboard and more. Just like those pages we focus on a specific issue and we fix it however we can. There is a long-held consensus, re-affirmed just a few weeks ago, at PNT that draft articles do not fall within our scope of work, as they do not fall under many other "problem article" pages, to change that would be to swamp us with hundreds of pages that are simply not a problem for Wikipedia. Wikipedia:Translation is the translation project, it is there that editors specifically looking at translating articles (properly I mean, not just dropping non-English articles into the articlespace) --Jac16888 ^Talk 21:40, 18 May 2015 (UTC)

@Jac16888: Thanks for the insight. Do you think this would work better if articles that have not received attention after the two-week period, and which otherwise do not obviously meet any deletion criteria, be moved to the Draft namespace then? Thus, all articles in foreign languages: (1) would be marked with a maintenance tag and listed at WP:PNT, as they are now; (2) after two weeks, would then moved to Draft namespace where someone could recover it in due course if they felt inclined; (3) could be deleted at any time just as with any article or draft subject to the deletion criteria. —sroc 💬 22:35, 18 May 2015 (UTC)

That could be done, but chances are that if after two weeks a page hasn't been translated by the creator or anybody else, it never will be.--Jac16888 ^Talk 23:02, 18 May 2015 (UTC)

• Support I dont see the earlier proposal as clashing with this one, but oh well.Bosstopher (talk) 20:15, 19 May 2015 (UTC)
• Oppose - first, there is already a process that works fine. If the good people who patrol WP:PNT felt there needed to be a new policy and their current routine wasn't working, I would defer to them. Instead this seems to me to be about an editor who randomly came across a page in Spanish and doesn't like that his decision to blank it kept getting reverted. Secondly, moving them to userspace decreases the likelihood that an editor who doesn't patrol WP:PNT will come across the article and help translate it. I strongly feel tagging the article with "please translate me if you can" is the best approach. —Мандичка^YO 😜 00:38, 22 May 2015 (UTC)
• Oppose, but do clarify: Existing processes are working. User:Sphilbrick's note above about "Step -2", etc., indicates that extant procedure needs clarification, but that can be done without a proposal like this, simply by amending the PNT instructions. His "smartaleck" list (with adjusted numbering) is actually a good draft of what to use.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  15:05, 25 May 2015 (UTC)

Cattle articles have two different styles of names and this is confusing. They are Highland cattle (no brackets) and Limousin (cattle) (notice the brackets around cattle). We need to establish consensus over which one to use.TheMagikCow (talk) 15:59, 19 June 2015 (UTC)

Discussion

I believe that the title should be without brackets. When you see the breed's name in any other source, it is without brackets. Why is Wikipedia the only place to differ? TheMagikCow (talk) 15:59, 19 June 2015 (UTC)

You might want to bring this up at WT:LIVESTOCK. --jpgordon^{::==( o )} 21:30, 21 June 2015 (UTC)

just looking at the examples given. Highland cattle are always called highland cattle, not just highlands. the word cattle is part of their name. Limousins are called limousins without the qualifier, so require a disambiguation in brackets. It's all well Wikipedia wanting consistency but correct usage surely must come first. IdreamofJeanie (talk) 22:14, 21 June 2015 (UTC)

@IdreamofJeanie: Take a look at the nav bar here. http://www.highlandcattlesociety.com/ The official society refers to them as the highland. TheMagikCow (talk) 13:58, 22 June 2015 (UTC)

• This discussion is probably better had at WT:LIVESTOCK as Jpgordon suggests, unless you mean to test a particular policy. From the article titles policy I'll point out WP:NATURAL, which suggests that natural disambiguation is preferred over parenthetical disambiguation, therefore if (for example) Limousin is not concise enough, then Limousin cattle would be a preferred disambiguation, rather than Limousin (cattle), even if that's not the breed's proper name. However, per WP:PRECISE from the same policy, if there is a common convention or local consensus that cattle breed articles should be consistently named one way or the other, then that can override the policy. So, yes, this should be discussed at WT:LIVESTOCK. Ivanvector (talk) 20:05, 22 June 2015 (UTC)

The Limousin cattle are actually called limousin cattle. They can be called limousins after being called limousin cattle. It is usually for convenience and being shorter to type/speak. TheMagikCow (talk) 06:09, 23 June 2015 (UTC)

Without brackets

• User:TheMagikCow
• AHeneen

With brackets

Either method is acceptable

• User:Ivanvector

Currently on Talk:Caitlyn Jenner there is disagreement about how to handle WP:BIRTHNAME with respect to MOS:IDENTITY.

WP:BIRTHNAME says that then a legal name change has occurred, mentioning the birth name in the lead sentence is advisable. For example, William Jefferson "Bill" Clinton (born William Jefferson Blythe III, August 19, 1946) ... However, using "birth names" for trans people is usually considered offensive (see GLADD, NPR) and WP:MOSIDENTITY makes it clear that BLPs on trans folks are handled differently and with more sensitivity to the living person's identity and wishes. For many trans people's articles, birth names are not mentioned in the lead sentence (e.g., Laverne Cox, Janet Mock). Nevertheless, it seems the be the norm that if the trans person was notable prior to coming out, the birth name is mentioned in the lead sentence (e.g., Chelsea Manning, Chaz Bono, Kellie Maloney). The only past discussions I can find on this issue are here and here but neither directly address this issue.

I seek to clarify WP:BIRTHNAME with respect to MOS:IDENTITY for BLPs of trans and non-binary people who have changed their name (whether on legal documents or not). Below are some proposed wordings to add to WP:BIRTHNAME directly following the sentence starting In some cases, subjects have legally... and two following examples:

Option 1 - Specifying apparent norm

In the case of transgender and non-binary people, birth names should only be included in the lead sentence if the person was notable prior to coming out.

• (from Laverne Cox, not notable prior to coming out) Laverne Cox (born May 29) ...
• (from Chelsea Manning, notable prior to coming out) Chelsea Elizabeth Manning (born Bradley Edward Manning, December 17, 1987) ...

Option 2 - No birth name specified in lead sentence

In the case of transgender and non-binary people, birth names should not be included in the lead sentence.

• (from Laverne Cox) Laverne Cox (born May 29) ...
• (from Chelsea Manning) Chelsea Elizabeth Manning (born December 17, 1987) ...

Problem: Not all notable pre-change names are birth names. Interpret as "pre-change name" instead of "birth name"?

Option 3 - Same as Option 1, but change "born" to "formerly"

In the case of transgender and non-binary people, birth names should only be included in the lead sentence if the person was notable prior to coming out. Instead of "born", use "formerly".

• (from Laverne Cox, not notable prior to coming out) Laverne Cox (born May 29) ...
• (from Chelsea Manning, notable prior to coming out) Chelsea Elizabeth Manning (formerly Bradley Edward Manning, December 17, 1987) ...

I offer Option 3 as a sort of compromise. Part of the problem can be the language of "born" as some trans and non-binary people have never accepted the name their parents gave them, so the name they were called as a child was never really their name. Using "formerly" acknowledges the transition and name change, but also to me acknowledges that it's the name people used to call them, not necessarily their chosen name.

Note, I do not offer a fourth option of using "born" for all people as that seems far too counter to MOS:IDENTITY and, as explained by GLADD and NPR above, does too much WP:HARM. EvergreenFir (talk) Please ((re)) 19:39, 2 June 2015 (UTC)

"Never really their name" is virtually a spiritual position, not something we can verify with reliable sources, unlike the recorded birth name. How the subject feels about that name is their personal business, but vital statistics are a matter of public record. There's no way around that. That said, if Option 1 carries, this will only be a problem in cases where a) the subject was notable before the change, and b) they also have utterly disavowed the name, so it's probably not a long list. Perhaps more to the point any such person is a public figure and has way, way, way bigger PR fish to fry that one website among thousands happening to mention, once, what their old name was. It's a non-issue in such a case.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  11:39, 18 June 2015 (UTC)

Option 1 - Norm specified

1. Support as a compromise (between former/birth/current names), and because the birth name is used in articles of similar nature, where the subject is not transgender but their current name is different. Intermediate names, which use "formerly", can be explained further in the article's body sections. Epic Genius (talk) 20:01, 2 June 2015 (UTC)
2. Support. Our articles should retain the usual format (Wendy Carlos (born Walter Carlos)) for trans people as for non-trans. It should not be a concern of ours that some trans people do not prefer the neutral statement of fact that is the Wikipedia standard. Binksternet (talk) 23:12, 2 June 2015 (UTC)

   ...your example is of a transgender person, perhaps choose a different example of our "usual format" such as William Jefferson "Bill" Clinton (born William Jefferson Blythe III; August 19, 1946)? Ogress _smash! 08:33, 7 June 2015 (UTC)

3. Support. I don't see an issue here, the use of "formerly" I can see causing more confusion. As it is, we have to explain why we use opposite pronouns when describing a transgendered person. - Knowledgekid87 (talk) 00:50, 3 June 2015 (UTC)
4. Support per my comments on Talk:Caitlyn Jenner. ¡Bozzio! 04:37, 3 June 2015 (UTC)
5. Support and add birth names for all. Wikipedia records facts, and facts are facts. If someone was born with one name and changed it for whatever reason that is a fact. If they find a fact "offensive", well, sorry, but tough! This is an encyclopaedia. -- Necrothesp (talk) 13:52, 3 June 2015 (UTC)
6. Support. Talking to or about a trans person in the present day by referring to a birth name they no longer use can be viewed as offensive. However, the historical record is what it is. So whether or not a trans person was notable prior to coming out and/or changing their name, if we intend to be serious about creating complete, accurate biographies, we need to be neutral about history as well. That being said, if using "formerly" is considered a more neutral way to do it, I would be fine with that as well. The only problematic choice here is pretending that a birth name did not exist. Resolute 17:05, 3 June 2015 (UTC)
7. Support option 1 or option 3 (I have no preference). It is extremely important to have the birthname specified in the lead if the subject was well-known primarily by that name at some point. For example, Bradley Manning was already very well-known as Bradley Manning prior to coming out. A reader arriving at Chelsea Manning might legitimately wonder if they had arrived at the correct page, were it not clearly specified early on. The goal of an encyclopedia, first and foremost, is to inform. This is an important part of doing that. Sławomir Biały (talk) 21:29, 3 June 2015 (UTC)
8. Support. I see no point in making an exception to the general rule in this case. -R. fiend (talk) 22:14, 3 June 2015 (UTC)
9. Support Mentioning the birth name in the first sentence. I also support using the birth name and gender when referring to events that happened before the gender change. Bobby Martnen (talk) 02:21, 4 June 2015 (UTC)
10. Support It's consistent. We don't allow subjects to suppress or downplay information about them just because they find it unpleasant (and frankly that kind of double standard is condescending). A change of gender identity should not be treated shamefully as The Name Change We Dare Not Speak Of. Option 3, using a different word, would be inconsistent, but would at least preserve WP's independent neutrality. -Jason A. Quest (talk) 17:10, 4 June 2015 (UTC)
11. Support I actually agree with Necrothesp above... this is an encyclopedia that's filled with facts regardless of whether we like it. Add birth names for anyone that changed it. Fyunck(click) (talk) 09:22, 5 June 2015 (UTC)
12. Support. Dirtlawyer1 (talk) 17:25, 5 June 2015 (UTC)
13. Support. -sche (talk) 18:03, 6 June 2015 (UTC)

    Incidentally, I notice that Mother Theresa's article, although its subject is cis, happens to follow this practice — it omits her birth name from the lead because she was not notable under it. -sche (talk) 08:23, 14 June 2015 (UTC)

14. Support: if the birth name is notable (like Manning), it should be in the lead. --NaBUru38 (talk) 23:40, 7 June 2015 (UTC)
15. Support - Wikipedia is supposed to be an encyclopedia, which is a depository of facts. The current norm of using prior names should definitely continue in the lead. Onel5969 (talk) 18:42, 8 June 2015 (UTC)
16. Suppport per Binksternet. Acather96 (click here to contact me) 14:51, 9 June 2015 (UTC)
17. Support in part, sometimes but other times #3; not all former names are birth name. The part I don't support is suppressing factual, verified information, if it's encyclopedically relevant.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  15:00, 14 June 2015 (UTC)
18. Support. This seems to reflect current policy on leads, which says that we have to mention any names the subject might be searched under to avoid confusion; and I don't see any reason to change that here. I don't feel that a simple acknowledgement that they once had a different name violates the WP:BLP requirement to respect their self-identification. Without this, someone who searches for Manning under her old name without knowing her full history might think they'd arrived on the wrong page. On the other hand, if the original name is not notable, there's no particular need or requirement to mention it, since people are unlikely to search using it (and anyone who knows it probably knows the subject's new name.) --Aquillion (talk) 18:17, 15 June 2015 (UTC)
19. Oppose. I don't think WP:BIRTHNAME and MOS:IDENTITY conflict. "the subject's full [birth] name should be given in the lead paragraph, if known," regardless of whether they were "notable prior to coming out." A subjects birth name has various possible uses to readers (further research on the subject prior to their name change etc.).—Godsy^(TALK_CONT) 04:23, 22 June 2015 (UTC)

Option 2 - No birth names

1. Weak support? I really don't think the use of birth names is actually useful, given the existence of redirects. All things considered, I think this option is basically probably the best choice. — Preceding unsigned comment added by Cam94509 (talk • contribs) 19:08, 3 June 2015 (UTC)
2. Oppose - why suppress information that is important to identifying subjects of articles and is all over the internet? Bobby Martnen (talk) 02:22, 4 June 2015 (UTC)
3. Support in lede. If we need to give someone's birth name, we can do it in an "early life" section. Something like this: """==Early life== Susan Bloggs was born Joseph Francis Bloggs on 2 December 1971 in Lower Fnord, Ruritania, to Joseph Philip Bloggs and Sarah Smith-Bloggs.""" --Alison (Crazytales) (talk; edits) 14:45, 5 June 2015 (UTC)
4. Oppose - Option 1 is the better, more nuanced choice. Dirtlawyer1 (talk) 17:27, 5 June 2015 (UTC)
5. Support non-inclusion of birth name in lead sentence, but require birth name in both Infobox and in Early life section only if the subject was notable pre-transition.I'd not include the birth name anywhere if the subject was not notable prior to their transition. Most transgender people in states which allow it get their birth certificate reissued with their chosen name and gender. At which point the previous certificate is retired and not available on request. Claiming a birth name in such a case could lead to an article which is verifiably wrong. In fact, I don't think such an article should mention the gender-transition at all, even if there are sources to support it, because it is simply not interesting or relevant unless the subject was notable pre-transition. Give these folks some privacy. Skyerise (talk) 19:53, 5 June 2015 (UTC)

   I don't believe it is accurate to say "most" do anything. It was only this year that passports were allowed to be updated without proof of sex reassignment surgery and only a small fraction of trans people have this surgery (e.g. Jenner did not have this surgery). It is probably accurate to say that "most transgender people that have had sex reassignment surgery" get a new birth certificate but that's it. --DHeyward (talk) 20:20, 7 June 2015 (UTC)

6. Oppose We don't usually go out of our way to censor here on Wikipedia. Where known, we give the birth name. Fyunck(click) (talk) 20:05, 5 June 2015 (UTC)
7. Oppose - Extremist POV pushing. Carrite (talk) 20:28, 5 June 2015 (UTC)
8. Oppose This is overdoing it. - Knowledgekid87 (talk) 22:46, 5 June 2015 (UTC)
9. Support - It is hard for me to see why birthnames seem so important to editors. Whatever made the person notable enough to be included in Wikipedia should have more weight. Implementing a policy to avoid birth names would help combat deadnaming. - MellowMurmur (talk | contributions) 20:47, 7 June 2015 (UTC)
10. Oppose: if the birth name is notable (like Manning), it should be in the lead. --NaBUru38 (talk) 23:41, 7 June 2015 (UTC)
11. Oppose: We do not suppress verifiable information if it's relevant. It doesn't have to be notable to be relevant, and relevance is determined on a case-by-case basis, in this as in all other matters.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  15:01, 14 June 2015 (UTC)
12. Oppose. This is well-intentioned, but the problem is that in situations where the article's subject was highly notable under their old name, there are likely to be people who search for them under it who will be confused when they end up at a different-looking article. This is why the policy states that we have to explain any likely names people will use to arrive at an article in the lead; I don't think it's a problem to mention their old name in this context as long as we make it clear that it is old and is no longer their name, and use their current name everywhere except in the places specifically clarifying that point. --Aquillion (talk) 18:21, 15 June 2015 (UTC)

Option 3 - Use "formerly" instead

1. Support per my explanation above as a compromise. EvergreenFir (talk) Please ((re)) 19:39, 2 June 2015 (UTC)
2. Support per EvergreenFir. Please note my signature... :) --Guy Macon (formerly Guy Macon) (talk) 22:16, 2 June 2015 (UTC)

   You missed a golden opportunity to go with "Girl Macon (formerly Guy Macon)" or vice versa. :-p -sche (talk) 00:00, 3 June 2015 (UTC)

   LOL Loved that (though maybe that's what Guy intended). Epic Genius (talk) 02:52, 3 June 2015 (UTC)

   Nope. I just wasn't clever enough to think of it. :( --Guy "do you mind if we call you Bruce?" Macon (talk) 05:50, 3 June 2015 (UTC)

3. Support Given EvergreenFir's argument, I think this is best solution, actually, for anyone who changes their name. I prefer "formally" rather than "birth name". For notable people, what matters is their commonly known former name, not what name was on their birth certificate. Liz ^{Read! Talk!} 21:22, 3 June 2015 (UTC)
4. Support this seems most accurate, all things considered. Lirazelf (talk) 21:27, 3 June 2015 (UTC)
5. Support less horrific for trans people who are "dead name shamed" constantly. — Preceding unsigned comment added by 2602:306:CE95:57B0:ED66:B25B:B2A2:792D (talk) 22:10, 3 June 2015 (UTC)
6. Support No one is "born with" a name or a gender; these are assigned. We are all born babies. Funcrunch (talk) 03:59, 4 June 2015 (UTC)
7. Support, second choice - I could support this as an alternative to Option 1. Dirtlawyer1 (talk) 17:28, 5 June 2015 (UTC)
8. Support offense is reduced that way. But if any are offended, they have chosen to be offended, and for the vast majority of readers it is not offensive in the slightest. People are not often born with a name any way, that step comes a bit later. Graeme Bartlett (talk) 22:37, 5 June 2015 (UTC)

   The vast majority of readers are not transgender. People affected by gender dysphoria do not "choose to be offended". It causes actual pain for us to be misgendered (including being referred to by our previous names). I voted for this option with the understanding that it would apply only to people who became notable under their previous name (whether assigned at birth or adopted later), as a compromise. Funcrunch (talk) 22:49, 5 June 2015 (UTC)

   I believe you. I wouldn't dream of calling you by any other name, but at the same time you don't hold any special privilege on how all trans people should be gendered in an article during various phases of their life. Generally we should go by what the sources say. Fortunately for you almost every RS uses the persons preferred gender for present and future tense. But this "carve out" where we have to use the preferred term for all phases unless the subject makes it known otherwise is ridiculous. This is an encyclopedia, not an activist proving ground (not that I think you were acting in this way, far from it). 69.143.188.200 (talk) 01:37, 6 June 2015 (UTC)

   It's not "ridiculous", it was already an established guideline in MOS:IDENTITY to handle gender this way. It's not about activism, it's about respect and not causing unnecessary harm. Funcrunch (talk) 02:23, 6 June 2015 (UTC)

   Well even if it causes no difference in offense I am still in favour of this option. The people that have a problem with the former name are going to find it everywhere online and in publications, so all Wikipedia can do is reflect the sources and not overuse the previous name. Graeme Bartlett (talk) 07:44, 9 June 2015 (UTC)

9. Support as a considerate compromise, with the awareness that like some of our other policies the persons most deeply affected will consider it a step short of what they would like, but only (as Funcrunch clarifies) for people who were in fact notable under the other name. --Orange Mike | Talk 23:55, 5 June 2015 (UTC)
10. Support per Funcrunch ForbiddenRocky (talk) 01:29, 6 June 2015 (UTC)
11. I support option 1, and I don't have a strong preference on whether "born" or "formerly" is used, which means I'm fine with this option, too. -sche (talk) 21:30, 7 June 2015 (UTC)
12. Weak Support I don't think we can definitely say in every case whether "Born" or "Formerly" is the most natural or illustrative for people that are notable prior to transitioning (and I'd argue of they aren't notable prior to transitioning, birth and former name are irrelevant in a BLP). I would use different names with Caitlyn Jenner depending on the style chosen. "Formerly Bruce Jenner" or "Born William Bruce Jenner" as "Born" seems to imply given name at birth and "Formerly" has some choice or common name associated with it. She was known as "Bruce Jenner" regardless of the legal name so that argument has no merit. As a general guideline, "Formerly" is okay though. Personally, I'm less attached to my full legal name than the shortened nickname, i.e. "Hi, I'm X" is an introduciton of who I call myself and is personal. - I am not sure whether the very formal birth name "William Bruce Jenner" is more or less offensive than the common name "Bruce Jenner" but I also don't see how we don't mention the previous common name of a famous person (and let's keep in mind the exceptional case makes poor precedent. A white, male, gold medal athlete is already one of the most privileged classes (is there a more privileged one?) and then going public with a gender transition that makes the cover of Vanity Fair in their sixties doesn't happen everyday. Gold medal athlete to Vanity Fair cover model is two things that rarely happen to one person, let alone the same person and are famous for both now. Jenner does not represent transgender people that generally have higher poverty rates, lower access to proper healthcare and much higher suicide and murder rates. Does anyone know a 60+ year old so comfortable with themselves they'd pose in their underwear for a national magazine for everyone to view/praise and criticize (or would be offered the opportunity? My airbrush has yet to be invented. This is an extraordinary case.) --DHeyward (talk) 19:34, 8 June 2015 (UTC)
13. Support Ed ^{[talk] [majestic titan]} 03:39, 14 June 2015 (UTC)
14. Support in part, sometimes if it's the birth name not a mid-life name, use #1; some former names are not birth names. The part I don't support is suppressing factual, verified information, if it's encyclopedically relevant.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  14:59, 14 June 2015 (UTC)
15. Weak support. I don't think that this aspect of the word-choice is really significant enough that we need to establish it via policy one way or the other, but I have no objections to 'formerly' if we are going to do so. --Aquillion (talk) 18:23, 15 June 2015 (UTC)
16. Support. If you are adopted, your birth name is erased and replaced on your birth certificate in the US. Fact is, that is your name - although you may have formerly been known by another name. Gmcbjames (talk) 20:23, 22 June 2015 (UTC)

General discussion 2

There is already an ongoing RFC about this issue above.amazingly similar discussion above sparked by the same news cycle item.-- TRPoD aka The Red Pen of Doom 19:42, 2 June 2015 (UTC)

I see the one above about using past names on other articles. I know they are similar, but I'm asking for a specific clarification to WP:BIRTHNAME. EvergreenFir (talk) Please ((re)) 19:48, 2 June 2015 (UTC)

• I'm not sure we need to suppress information in the public record, so I'd be fine with either option "born" or "formerly", the distinction there seems stylistic. The difference between how we write the narrative of a person's life (using their preferred identity) and noting the existence of facts in the public record which are not matters of dispute. I don't think we even need to suppress the facts for people who were not known under prior names. I don't favor treating this one particular thing differently than other name changes; for example Gerald Ford was never notable under any other name, but we don't suppress his prior names. We also never use any name except Gerald Ford (or variations thereof) in his article except where noting his prior names as plain facts in the public record. I don't see why this should be any different. The exact word used to indicate the prior name isn't important. --Jayron32 19:52, 2 June 2015 (UTC)

  My understanding of the difference is that Ford's name change did not result from a fundamental identity dissonance that persisted through his formative years. Powers ^T 18:31, 3 June 2015 (UTC)

That's a difference that matters to the subject, and to other parties in some other contexts, but not all parties in all contexts. Anyway, I also concur with Jayron32's take.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  14:55, 14 June 2015 (UTC)

• This is not about trying to suppress anything; this is a unique situation, involving the deepest questions of human identity, and in some ways a special sub-case of WP:UNDUE. The amount of sheer gratuitous nastiness and transphobia I'm seeing in some of the comments is deeply disappointing. --Orange Mike | Talk 00:00, 6 June 2015 (UTC)

  Actually I was thinking that almost all the comments were surprisingly reasonable and non-transphobic, and that this was going mostly smoothly. There are differences to be sure, there always are (just like with diacritics on wikpedia), and there are always a few on the extreme ends, but mostly things have been on an even keel and calm. Fyunck(click) (talk) 00:24, 6 June 2015 (UTC)

Aye. What's deeply disappointing to me is to see intelligent people assume that any disagreement with a premise they feel strongly about translates into fear/hatred somehow. (It happens on other issues too, not just this one. Hint: Never, ever XFD anything with "women" in its title unless you have a very thick skin, not matter how sensible your rationale is.) It's even worse when you consider that this kind of reaction is also treating any ignorance (which is reparable by discussion and reading and experience), or failure to follow one's argument exactly as one intended (which may have more to do with one's own writing or reasoning), as more fear/hatred. No thanks. See WP:Advocacy, WP:GREATWRONGS, WP:Assume good faith, and WP:Assume clue, for starters. A bit of self-education on both sides of this debate would be useful.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  14:49, 14 June 2015 (UTC)

There seems to be nearly unanimous support for options 1 and 3 (and opposition to option 2); given the nature of them and the comments made on each, I take that to mean articles can use either "born" or "formerly". Do we need an admin to close this, does the discussion need to stay open longer, or can we just modify WP:BIRTHNAME to say:

In the case of transgender and non-binary people, birth names should only be included in the lead sentence if the person was notable prior to coming out. One can use either "born" or "formerly".

• (from Laverne Cox, not notable prior to coming out) Laverne Cox (born May 29) ...
• (from Chelsea Manning, notable prior to coming out) Chelsea Elizabeth Manning (formerly Bradley Edward Manning, December 17, 1987) ...

? -sche (talk) 02:38, 19 June 2015 (UTC)

@-sche: Not sure if needs to stay open longer, but given the topic and its history on WP, might be smart to ask an admin to close. Just my opinion on it. I think the wording you propose is perfect given the outcome thus far. I'll wait until closed to add to BIRTHNAME (or if someone gets to it before me, that's cool too). EvergreenFir (talk) Please ((re)) 02:43, 19 June 2015 (UTC)

I went to WP:AN/RFC to ask someone to close this, only to find that it says "Many discussions do not need formal closure and do not need to be listed here. Many discussions result in a reasonably clear consensus, so if the consensus is clear, any editor—even one involved in the discussion—may close the discussion. The default length of a formal request for closure is 30 days ...; if consensus becomes clear before that and discussion has slowed, then it may be closed early."
It seems to me that consensus has become unusually clear and discussion has petered out, and discussion has been open for 1 month, so I am closing it.
With one exception, everyone who has expressed an opinion on option 1 supports it; the one person to express opposition says they don't think MOS:IDENTITY and WP:BIRTHNAME conflict in the first place, which is no reason not to clarify them. Everyone who has expressed an opinion on option 3 supports it, with several users pointing out that it is a compromise between not listing even notable birth names (option 2, which has no consensus behind it) and listing even non-notable birth names, an extreme no-one even thought to suggest as a distinct option. Some supporters of option 1 do note that they would also support listing even non-notable trans people's birth names, but they are balanced by supporters of option 2 who oppose listing even notable birth names. The consensus is that WP:BIRTHNAME should be updated to reflect (the existing norm) that birth names of trans and non-binary people should only be included in their articles' lead sentences if the people were notable prior to coming out. Birth names may be introduced by either 'born' (as suggested by option 1) or 'formerly' (as suggested by option 3).
-sche (talk) 07:21, 1 July 2015 (UTC)

I hereby submit a proposal to be reviewed by the community. The proposal is as follows: the essay titled Wikipedia:BOLD, revert, discuss cycle, commonly known as WP:BRD, should be elevated to the level of a Wikipedia guideline. The reasons for this proposal are simple. The essay in question has attained a level of currency across Wikipedia that punches above the weight of an "essay". It is commonly cited by administrators during the course of their duties to halt edit warring. It is the most apt tool that we have to encourage discussion. It is clearly an example of a Wikipedia "best practice", which is how guidelines are defined by the policy on such matters. As such, it has proven that it is worthy of guideline status. RGloucester — ☎ 00:55, 6 June 2015 (UTC)

Support: BRD elevated to guideline

• Support ::"Don't edit war" is ambiguous and vague, and differing opinions about the correct way not to edit war result in unnecessary friction and conflict. Most users will follow a process that is simple and clear, if it has community consensus. I've found that things go smooth as butter when all present agree to follow BRD. The minute someone shows up and says, I don't have to do that, it's only essay, things turn to shit in a hurry. Something about that tells me BRD is a good thing for Wikipedia. Can BRD be abused? Of course it can, anything we did could be abused. Fault the abuser, not the process. Should we can WP:IAR because it's routinely misused out of ignorance or abused in bad faith? No, because it's a net positive. The same applies here. I don't care much about all the ivory tower intellectual objections to BRD, generously sprinkled with WP:CRYSTAL, I'm a practical guy and I'm only interested in what I've found to work in real-world Wikipedia editing. ―Mandruss ☎ 01:44, 6 June 2015 (UTC)

Have you noted how most people who invoke BRD do it in violation of BRD, often with the same person reverting the article to its initial state three or four times, or reverting with the only reason being "let's discuss the change first"? (which BRD lists as an invalid reason) There's nothing simple in the procedure, and turning it into a guideline would only create a weapon for those who like to WP:OWN articles to wikilawyer. Conversely, the good faith editors who know how to make the best of BRD don't need it to have any legal weight, nor to force others to follow it; BRD only works well in such cases because it's optional. Make it mandatory and it will kill all the goodwill that it requires to be successful. Diego (talk) 18:16, 6 June 2015 (UTC)

Ok, scenario: Someone makes a controversial and unsourced change. May I assume that one revert is the right move, or must one of the others immediately start a talk thread? If the revert is good, the editor re-reverts. What's the proper next move? Is it bad to enforce the concept that a disputed edit must stay out until there is consensus for it? Where is the road map for this that has community consensus, that everyone can agree on? Simply stating general principles doesn't work, and has not worked, since that's over the heads of too many of the general editing population. Specific steps are needed, and this is the concept I have attempted to explore at #Discussion break 1 (BRD). As many have said many times, there is no possible solution that could not be used for bad-faith purposes. Bad-faith editors are experts at turning the rules around and using them as weapons, no matter what the rules are, so I really don't get the point of using that as an argument. We might as well throw out laws against rape because someone can falsely claim rape and use the laws to hurt someone they don't like. ―Mandruss ☎ 11:38, 10 June 2015 (UTC)

In your scenario the edit would be out because of WP:V, not because of WP:BRD. Counter-scenario: an editor removes a piece of gossip from a biography that is unsourced. Some editor reverts the removal arguing that it's a well-known fact, maybe adding a reference to a tabloid to satisfy WP:BURDEN. Should the sentence then remain in place until a consensus is arrived through discussion at the talk page? What if the fact is not about a living person, but still the reference provided is quite low quality and unreliable? The "defending the default version" rule is not desirable in that case.

Is it bad to enforce the concept that a disputed edit must stay out until there is consensus for it? Yes, because it undermines the core concept at WP:CONSENSUS that all editors should work towards a solution that all parts involved may accept. If you enshrine the idea that one side in a dispute gets to defend their preferred version of the article by default, that side no longer needs to negotiate any proposed improvement - they can just philibuster against any change, which we as a project haved agreed it's a bad idea.

Also BRD says that performing such edit is often acceptable. So enforcing BRD would not prevent that edit, and editors who want to undo the potential improvement would still need to provide a rationale other than "because BRD". Diego (talk) 12:39, 10 June 2015 (UTC)

Some points taken, but I'm having trouble grasping a lot of that after over 14,000 edits. I'm far from alone in that respect; in fact, out there in the real editing world I'm not seeing anyone showing the correct path in various situations, including editors with considerably more experience than I have. All I'm seeing is (1) edit warring, or (2) misinterpretations of BRD with "per BRD" in the edit summaries. Basically, nobody knows what the hell they're doing. That makes arguments such as the above fairly academic, wouldn't you say? The "right way" isn't much use if it can't be effectively communicated to the masses, and how much more evidence do we need that the existing written information is not getting that job done? ―Mandruss ☎ 13:29, 10 June 2015 (UTC)

• Weak support - I'm fairly ambivalent on this one. While I see the points of the first two oppose votes below, BRD is widely accepted and often treated as a guideline when discussing behavioral evidence on ANI and other forums. WP:PG states that guidelines are meant to outline best practices for following those standards in specific contexts. The specific contexts makes me think that WhatamIdoing's concerns are partially addressed. We have other guidelines (e.g., WP:BOLD, WP:POINT, that are similar and I see no major problem to adding this one to the bunch. Just to add, seeing the list of reasons against in past discussion, adding this as a guideline would not negate other guidelines like WP:OWN. I can concerns about status quo though. EvergreenFir (talk) Please ((re)) 02:04, 6 June 2015 (UTC)

I haven't seen WP:OWN enforced in the last seven years; no matter how painful the truth, I'm afraid it's a dead policy. Can you explain what benefit we would get by forcing editors to always follow the next step in the cycle? And how would you assess whether starting a new cycle with a BOLD edit after discussion does comply with the guideline or is disruptive? Diego (talk) 18:26, 6 June 2015 (UTC)

• Support as proposer – I also endorse the fine words of Mandruss. RGloucester — ☎ 02:10, 6 June 2015 (UTC)
• Support For the simple reason that it already is a de facto guideline. I've read the opposes and find them unconvincing. As a guideline it is still not a policy, just a ... wait for it... guideline. It applies in most cases but is not a hard and fast rule to be enforced on people. Beeblebrox (talk) 21:01, 6 June 2015 (UTC)
• Support I am in agreement with Beeblebrox's reasoning. Gmcbjames (talk) 06:54, 7 June 2015 (UTC)
• Support. BRD is something that happens sufficiently often for it to be elevated to 'Guideline'. The emphasis of the current essay is 'Discuss' which of course it should be and which, sadly, too many editors don't care to do. Promoting to Guideline would provide BRD with a note of authority while retaining the aspect that as Beeblebrox suggests, is still a GUIDEline. I find the oppose votes rather unconvincing however much traction they appear to have gained. In fact some of them I actually find very hard to follow. --Kudpung กุดผึ้ง (talk) 03:50, 10 June 2015 (UTC)

If you think the emphasis of the current essay is 'Discuss', you haven't understood it. The emphasis is on "balance discussion with juicious editing, don't let any one dominate the other". Which proves my point - no two editors will try to enforce it the same way, which is a bad idea for something supposed to carry any authority. I'll ask again: what is the benefit you expect by having this labelled with the word "guideline" instead of "essay"? Diego (talk) 12:39, 10 June 2015 (UTC)

I can't speak to anyone's internal motivations/expectation, but the result of it would be the effective end of WP:Be bold; might as well just go slap ((Historical)) on it.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  12:54, 14 June 2015 (UTC)

Oppose: BRD elevated to guideline

• Oppose, per my rationales seen at Wikipedia talk:BOLD, revert, discuss cycle/Archive 3#There is no such thing as a consensus version?. Making WP:BRD into a guideline or a policy would be like imposing WP:1RR (the one-revert rule) on articles and would cause more problems than it solves. For example, WP:Fringe content being added to a medical article and staying in the article until discussion settles the matter (after all, if a person finds WP:Fringe content in an article, is bold and removes it, and then an opposer comes along and restores it, that's a problem). Flyer22 (talk) 01:15, 6 June 2015 (UTC)

Note: I alerted the talk pages of WP:Policies and guidelines and WP:Edit warring to this matter, as seen here and here. The talk page of WP:BRD was already alerted. And with as many people participating in the Caitlyn Jenner/Bruce Jenner matter above, there might be no need for me to go around alerting a bunch of WP:WikiProjects like I did in the case of a WP:Lead discussion. By that, I mean that it's likely that editors voting on the Caitlyn Jenner/Bruce Jenner matter will also vote on this case. Flyer22 (talk) 01:49, 6 June 2015 (UTC)

I also see that this matter was discussed in 2014: Wikipedia:Village pump (policy)/Archive 116#WP:BRD as essay. Flyer22 (talk) 01:57, 6 June 2015 (UTC)

Another note: When alerting the pages that I did for this latest WP:RfC, I initially messed up the linking. Flyer22 (talk) 21:49, 6 June 2015 (UTC)

• Oppose A guideline should be something that (a) anyone can successfully follow and (b) is generally applicable. BRD, by contrast, directly says that this is a good practice for only some editors and some situations: "BRD is best used by experienced Wikipedia editors. It may require more diplomacy and skill to use successfully than other methods, and have more potential for failure. Using BRD in volatile situations is discouraged." WhatamIdoing (talk) 01:38, 6 June 2015 (UTC)
• Oppose. WP:TALKDONTREVERT is enough. Consensus can be established without WP:BRD, and forcing editors to use WP:BRD will just create more problems (aspersions, unnecessary arguments and what not). Esquivalience ^t 02:33, 6 June 2015 (UTC)
• Oppose. In a perfect world it would be a great idea. But BRD is regularly abused now, it'd be a real clusterf*ck if it were to be given more weight. Skyerise (talk) 03:23, 6 June 2015 (UTC)
• Oppose, per WhatamIdoing and Esquivalience. GregJackP Boomer! 17:50, 6 June 2015 (UTC)
• Oppose as impractical and a magnet for battleground. BRD may very well be the most misunderstood and controversial instruction set at the Wikipedia space. Half editors believe it to be a call for making bold edits any time debate becomes stalled in a gridlock, the other half swear that it's a reason to never ever touch the article again until talk pages have been crammed with every possible argument and counter-argument, and avoid edits unless everyone involved has endorsed even the smallest change. If we can't even agree to what it means, how can it become official? We'd have to rewrite it word by word before turning any part of it into a guideline, and by then all consensus would have evaporated. Diego (talk) 18:09, 6 June 2015 (UTC)
• Oppose per WhatamIdoing ForbiddenRocky (talk) 18:25, 6 June 2015 (UTC)
• Oppose per WhatamIdoing, Flyer22, and Diego Moya. The appropriate means to resolve issues over disputed content depends on the particulars, and trying to shoehorn everything into a singe process simply doesn't work. AndyTheGrump (talk) 18:37, 6 June 2015 (UTC)
• Oppose Sorry RG, the sound of a 1RR on every article doesn't bode well. It sounds like a good idea as BRD is used a-lot but in it's current wording wont make a good guideline. I suggest you look into BRD's wording and seek consensus to adapt it for a case by case basis. - Knowledgekid87 (talk) 19:06, 6 June 2015 (UTC)
• Oppose - I agree with Diego. In addition, I find BRD to be far, far too long. The core idea could easily be expressed in two paragraphs. Instead, it is needlessly overlong. Neutrality^talk 22:25, 6 June 2015 (UTC)
• Oppose - too vague and hard to follow. It's widely invoked because people perceive it as being so many things. It calls itself optional. Isn't an optional guideline an essay? Bryan Henderson (giraffedata) (talk) 22:34, 6 June 2015 (UTC)
• Oppose: I will take what Diego Moya said. I encounter editors who have no idea of even the correctly applied concept of BRD. This does not need to be escalated to carry greater weight of repercussions and punishment. Fylbecatulous talk 16:35, 7 June 2015 (UTC)
• Oppose I consider that we rely excessively on BRD, and that it is in many cases a direct invitation to unnecessary and undesirable conflict. DGG ( talk ) 22:20, 7 June 2015 (UTC)
• Oppose This is already what it should be, an oft-cited method of editing that works well in certain situations. Attempting to make it imperative will fail horribly. VQuakr (talk) 03:10, 9 June 2015 (UTC)
• Oppose per the above arguments: it isn't especially clearly written, it doesn't apply in all situations, I also see it as contributing to conflict rather than helping to avoid it, and it would effectively impose 1RR on all articles. That BRD is a useful approach in some circumstances and it's oft-cited are not enough reasons to elevate it to a guideline. Ca2james (talk) 05:11, 12 June 2015 (UTC)
• oppose as per WhatamIdoing and others above. BRD is oftne a good method to avpoid edit wars, but it is not a one-size fits all solution. It does not, for example, work well in a situation with multiple editors each of whom has a someehat different PoV on the issues. Other cases whre it is not a god fit have been mentioned above or in the discussion below. DES ^(talk) 05:55, 12 June 2015 (UTC)
• Oppose the current text says, "The "Bold–refine" process is the ideal collaborative editing cycle." If anything that should be made into a guideline. GregKaye 15:12, 12 June 2015 (UTC)
  • Better yet, copy-paste that wording into WP:Be bold policy. I may well do just that, after this RfC closes.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  12:58, 14 June 2015 (UTC)
• Oppose TL;DR: See first item at #Case studies, below. BRD, regardless of the fact that some have used it to good effect, is essentially a WP:POINT and WP:FILIBUSTER tool. Detailed rationale:
  Policy arguments: WP:BOLD is policy (along with WP:IAR), while WP:BRD is a voluntary (if fairly customary) agreement between editors to suspend pursuit of bold action in the interests of WP:CONSENSUS (including the avoidance of WP:EDITWARs). BRD is a behavior guidance essay that recommends one interpretation of and preference regarding how the BOLD and CONSENSUS policies interact. There are other interpretations, such as WP:DR (which is also a policy, and which helps resolve disputes instead of generating them, as BRD tends to do). Likewise, we have quite a large number of essays that provide other interpretations and recommendations (mostly along the "walk away and do another of the zillion things Wikipedia needs done, and spare your blood pressure" vein). These other views are at least as valid as BRD process, and usually less problematic. WhatamIdoing's observation that BRD itself says it's not for everyone is enough to derail this proposal anyway (and no, removing that wording won't get around that problem).

  Community and common-sense arguments: It's readily observable that many of those who cry loudest for BRD when they don't like an edit (or editor), are the least willing to engage in BRD when they think they won't win a protracted consensus discussion, or are right, by God. It's the same underlying psychology behind the old maxim "Everyone is for free speech, as long as it's their own." Diego Moya accurately described the two most frequent problematic results of reliance on BRD, and DGG among others is entirely right about this essay being practically invitational of strife. One of its most frequent uses is to WP:OWN a page or prevent inclusion of something that actually has consensus or wasn't really controversial, by WP:FILIBUSTERing until the opposition gives up. Another is WP:HOUNDING another editor by BRDing all of their major changes within an entire editing sphere (wikiproject scope, or whatever) until they go away. BRD shouldn't be sent to WP:MFD, but its successful application is much less frequent than its fans believe, and it is one of the top reasons WP's quality improvement has slowed to a crawl in the last few years. It needs to be clarified that it can't be abused for stonewalling or wikistalking. If the editor who made a change has a better rationale, then WP:BOLD clearly applies, without having to have an RfC about every editorial point. It's amazing how many editors today incorrectly believe that "you didn't discuss this first" is a valid rationale for reverting anything they want to, regardless of the rationales for the edit. But an increasing number of "differently clued" admins are actually siding with this terribly un-wiki misinterpretation.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  12:47, 14 June 2015 (UTC)

• Oppose I fully intended to support until I read the arguments against. Chris Troutman (talk) 11:26, 15 June 2015 (UTC)
• Oppose I don't mind having it as an essay that some people may want to use, I personally think it's not the best method of conflict resolution, and I absolutely oppose making it a guideline or policy. -War wizard90 (talk) 05:22, 16 June 2015 (UTC)
• Oppose. While BRD is an accepted practice, it is a practice requiring skill and experience, and the BRD essay fails to confer the skill and experience onto its readers. People who do not already know when to be bold, when to revert, when to discuss, and when to stop discussing are not the sort of people who should be encouraged to practice BRD. Instead, support tagging as historical with pointers to EDITCONSENSUS, BOLD, and 3RR. --SmokeyJoe (talk) 13:20, 23 June 2015 (UTC)
• Oppose - The three-revert rule is already in the edit warring policy and elavating the Wikipedia:BOLD, revert, discuss cycle to a guideline would almost impose a one-revert rule. Though it would only be a guideline (as opposed to the 3rr and 1rr policies mentioned in the previous sentence), guidelines have much more "weight" than essays. The Wikipedia:BOLD, revert, discuss cycle is a good suggestion/idea, but isn't a blanket cycle for all cases. It's fine as an essay.—Godsy^(TALK_CONT) 16:25, 23 June 2015 (UTC
• Oppose - BRD is good advice but inappropriate as a mandate. Rlendog (talk) 00:26, 26 June 2015 (UTC)
• Oppose It is good advise but I think making it into a rule sort of misses the point of the essay. Chillum 00:32, 26 June 2015 (UTC)

Neutral

• BRD is excellent advice and guidance, but not all that good in terms of being "the rules". Unfortunately, too many editors think that "guideline status" equates to "the rules". Blueboar (talk) 12:05, 8 June 2015 (UTC)

Blueboar, how does guideline status not equate to being a part of Wikipedia's rules? As you likely saw, I commented on guidelines being rules with my "22:07, 6 June 2015 (UTC)" post in the Discussion (BRD) subsection below; I pointed out that per WP:Policies and guidelines, guidelines are also rules. I don't understand the interpretation that only policies are rules because policies have to be followed. Like WhatamIdoing mentioned below, WP:Preserve is also policy...and editors routinely ignore it even while being aware of it. Flyer22 (talk) 06:45, 14 June 2015 (UTC)

OK, let me rephrase... One of the primary purposes of a Guideline is to outline "best practice"... but "best" practice does not mean "only" practice... and unfortunately as soon as we enshrine a "best" practice by giving it Guideline status, too many editors treat it as being the "only" practice allowed.

(as for WP:PRESERVE... remember that PRESERVE is balanced by WP:CANTFIX. I strongly suspect that, most of the time, when an editor appears to be "ignoring" PRESERVE, he/she is actually "following" CANTFIX.) Blueboar (talk) 12:40, 14 June 2015 (UTC)

Maybe it depends on what's in your watchlist, but I see reversions over typos in wikitext formatting, because the source is "only" a peer-reviewed journal article, things that ought to be moved to another article rather than blanked and lost, and other things that are obviously not CANTFIX territory. WhatamIdoing (talk) 23:46, 14 June 2015 (UTC)

Discussion (BRD)

• What effects, if any, would this proposal have on the encyclopedia? Winner 42 Talk to me! 00:57, 6 June 2015 (UTC)
  • It would enshrine WP:BRD as a "best practice", encouraging editors to take a more discursive approach to controversial topics. RGloucester — ☎ 01:01, 6 June 2015 (UTC)
    • That's one possibility, I suppose. BRD doesn't limit itself to controversial topics, however, so the best case scenario is that editors will waste a lot of time taking a more discursive approach to everything.
      IMO, another, and unfortunately more likely, possibility, is that more editors will go around saying that if you're reverted (by anyone, for any reason), that it's your duty to drop everything and go "discuss" with WP:Randy in Boise what the professional literature says about this subject, and why academic sources are preferable for those subjects, and that if you respond to reverting with either a reasonable revert or with another bold effort, then you are a dangerous editor who probably needs to be blocked for edit warring. TLDR: If we're going to set up a WP:0RR rule for bold editors, then let's be honest about what we're doing.
      Also, if this becomes a guideline, we're going to see an increase in reverters demanding that bold editors go start a discussion (because BRD puts the burden of starting a discussion on the bold editor, right? No, no, don't go read it or anything; you might discover that it doesn't actually say that), and insisting that BRD enshrines their right to revert anything and everything at least once, including edits they personally believe improves the page (an endemic problem at policy pages: "I agree, but I'm reverting this tiny change because you didn't say Mother, May I? on the talk page first").
      Basically, I think that BRD is a good idea for editors who are both experienced and have a certain degree of personal maturity, for disputes involving a small number of thoughtful people. Some editors aren't capable of it (they have other options, like learning WP:How to lose or deciding to WP:Let it go, or going through formal dispute resolution), and other times it's not the best choice. In short, it's good for people who can choose to voluntarily apply it to an appropriate situation, and to refuse to apply it in others. It's not good for everyone or every edit. WhatamIdoing (talk) 02:20, 6 June 2015 (UTC)

Guidelines, by definition in the Wikipedia policy on such classifications, are applied in appropriate situations. They are merely examples of best practice, and are not a dogma to adhere to with fervour. This proposal is not to elevate BRD to "policy" status, but to "guideline status. Please revise your remarks in accordance with the proposal as it was made, not with some imaginary proposal to make BRD a policy. RGloucester — ☎ 02:48, 6 June 2015 (UTC)

Hello, Theory, please meet Data.

"Mere guidelines" like WP:FRINGE and WP:MEDRS are enforced with a zeal much greater than some of our core policies (especially WP:IAR). Some essays even get cited as reasons for blocking editors. Everything, even policies, ought to be applied only in appropriate situations, but the fact remains that we have a sizable group of active editors who believe that every single "rule" must be complied with at all times, and that their POV is the only one that matters. You can see a perfectly reasonable, good-faith example of this around electronic cigarettes: is that a "health-related" article, and so WP:MEDMOS's suggested article structure applies, or is that a "manufactured consumer good" article, and so it doesn't? This community is slowly calcifying in its approach. There is a "right way" to do everything, and everyone must conform. This proposal—that a particular style of handling everyday editing disputes be elevated above all other styles—is actually an example of that systemic problem. WhatamIdoing (talk) 14:51, 6 June 2015 (UTC)

Indeed. I have to strongly agree with your observation that, if I may restructure it, BRD leads to two different kinds of problem: POV ownership of articles, when it's used to filibuster all "disagreeable" facts, and fossilization of Wikipedia-namespace pages like policies and guidelines, by reflexive reverts that lead to 20 screenfuls of noise generated by people who can't follow basic reasoning. I thank RGloucester for proposing this, since it's clearly going to fail, and this will dump icewater on the zeal of people to abuse this in such ways (and worse ways, like blocking people for not following an optional essay). If this snowballs as bad as I hope, we may actually get back to a productive, fast-paced editing environment like we had ca. 2008. Remember those days, and how much we got done? BRD is the #2 reason we don't any more. The #1 cause is, of course, the shrinking editing pool which despite all kinds of kooky theories is obviously primarily the result of the fact that in the very productive period we already wrote all the "sexy" articles, leaving only increasingly specialized and nerdy topics for people to get a fresh crack at. The frontier has disappeared, and WP is now in an intellectual "suburban sprawl" stage. The only way out of that to a new cycle of renewal is elimination of unnecessary process-mongering. Like BRD.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  13:19, 14 June 2015 (UTC)

• I feel that with "a more discursive approach to controversial topics" RGloucester misunderstands much of the intent of BRD, which is to encourage a new bold edit in response to unfocused discussion, to provide an exit to talkfests and filibusters. --SmokeyJoe (talk) 03:42, 6 June 2015 (UTC)

If only it actually worked that way. I generally just leads to reversion of the filibuster-breaking bold edit, and new cycle of BRD noise.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  13:20, 14 June 2015 (UTC)

It does work that way, you just don't see it. BRD is an excellent method for working with other editors, and required no invocation of BRD. (you make your edits, and if reverted you discuss before going back to editing) If you count attempted uses by the number of occasions that someone in a discussion or edit summary says "BRD" you'll be counting the people who don't understand. --SmokeyJoe (talk) 06:23, 18 June 2015 (UTC)

• Some of the opposers seem to be of the opinion that this would make a 1RR rule apply to all articles. That's a red herring/strawman argument that is just plain wrong. 3RR is a policy. If you break it, you are probably going to get blocked. You can't "break" a guideline, all you can do is choose to ignore it. If there are users or admins out there (and there most certainly are) that apply essays and guidelines as if they were rules or policies, that is a problem with those users, not with the guidelines and esays themselves, and not promoting this to a guideline isn't going to fix that problem. (I would actually support BRD being a policy for other policy pages only as nobody should just be changing policy on a whim, and if they are reverted they should obviously seek consensus for their changes, but that's another discussion for another day) Beeblebrox (talk) 21:12, 6 June 2015 (UTC)

Beeblebrox, as noted at WP:Policies and guidelines, guidelines are rules and editors should attempt to follow them. Do I always follow every guideline? No. There is a valid WP:Ignore all rules reason for some cases, but an editor should not be waving the WP:Ignore all rules policy around often as if that gives the editor a reason to ignore a guideline in every case. Guidelines are guidelines because they have generally been found to be best practices; there should be a valid reason for forgoing them; WP:IDON'TLIKEIT reasons are generally not what I call valid. Flyer22 (talk) 22:07, 6 June 2015 (UTC)

The difference between a policy and a guideline is not about blocking. People get blocked every day for "breaking" the guideline about WP:External links. And how many community bans have we seen for WP:IDHT, also a guideline? But when was the last time you saw someone blocked for "breaking" the WP:Editing policy? That policy gets violated every hour of the day, especially the WP:PRESERVE section, but almost no one gets blocked over it. I'm not sure that it's even possible to "break" WP:POLICY or WP:IAR. But people get blocked for "breaking" the mere essay on WP:Tendentious editing.

I believe that the actual goal here is to impose something like 1RR on articles (rather than on people): to stop edit warring by declaring that if you are reverted, your only acceptable course of action is to start a discussion. No more reverting the reverter (even if the reversion is clearly a mistake, clearly anti-policy, etc.) and no more trying a different, bold change: If I revert you, then you must start a discussion (or stop editing the article). WhatamIdoing (talk) 17:57, 9 June 2015 (UTC)

Re: Nobody should just be changing policy on a whim" – Um, policy (other than that handed down externally from WP:OFFICE) got written and developed mostly from people changing it boldly ("on a whim" is a dismissive, subjective value judgement that presupposes you can psychically know what's going on in the editor's mind). We need more of this, not less, all over Wikipedia, which has slowed to a crawl in virtually all areas, public-facing and internal. Most changes to policy don't stick, but they tend to lead to policy development far more than does going to the talk page first and trying to drum up interest in discussing how to maybe approach crafting an attempt to address something that maybe we should talk about exploring to see if it's sufficient concern to warrant addressing with ... blah blah blah. Just put in what you think it should say. If it makes perfect sense, it sticks. If it makes some sense, other people will help massage it into something useful. If it's stupid, it'll get nuked. If you habitually insert stupid stuff into polices and guidelines, you'll be asked to stop. If you don't, then noticeboards. This process worked perfectly fine for over a decade before BRD dumped a truck full of slowly hardening glue over everything. NB: All of this also applies to article content, not just Wikipedia-namespace editing, other than what you add to articles needs to also comply with the core content policies. The underlying process (and what makes it work well or poorly) is the same in both cases.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  13:30, 14 June 2015 (UTC)

Alternative: Do a better job of explaining the concept (and when to use it) at WP:CONSENSUS

ESSAY

An editor should not need to have a 130 I.Q. and three years of experience to know how to edit without edit warring. I don't know, but my guess is that most or all opposers of this promotion fit that description, and they are unconsciously assuming that most editors are like them. Not so, probably not even a majority, and therein lies the disagreement in this proposal. Guys, it may seem simple and clear-cut to you, with all your experience, but it's not. I've said it before in a different context: Wikipedia has become designed by the experienced, for the experienced, and we wonder why we can't keep new editors — and I got a bit of experienced support for that statement. I'm here as a representative, possibly the only representative present in this discussion, of Average Editors.

(I don't mean to imply that other supporters have an I.Q. under 130 or less than three years of experience. Don't overthink.)

Somehow, the wisdom of the elders needs to be translated into a somewhat simple process, a road map, for the rest of us. We don't need to know why, only how. Vast amounts of time are wasted arguing about who has the responsibility to start the talk thread, for example, and that could be avoided if a guideline process simply clarified that question. If it's true that one size can't fit all, or if it's true that any such guideline would be a net negative — and I'm not convinced of either — then we need to accept the fact that we will never be rid of widespread edit warring, that Wikipedia will forever be an acrimonious and chaotic battleground environment. Those are the two choices as I see it. ―Mandruss ☎ 17:38, 7 June 2015 (UTC)

• Alternative - rather than promote BRD itself to guideline status, I would do a better job of explaining the BRD concept (and when to use it) at WP:CONSENSUS.

If we do promote it, it will need some explanation of when not to use it. There are times when the BRD cycle is unnecessary... and times when it is. For example, BRD is not really necessary in brand new articles... as an article starts and grows, it is likely to change rapidly as editors add new bits of information, and freely rewrite sections with existing bits of information. These articles work best on an "Bold, revert, less bold, repeat" cycle. The discussion part of BRD isn't always necessary. A stricter BRD cycle works better for articles that have been around a while and are more stable. In such cases, it is fine to be bold, but if someone reverts it is usually best to the article and ask why the revert was made. For some articles (and especially our core policy pages) every paragraph, sentence and phrase has been discussed and discussed yet again... and we have reached the point that Bold edits are almost guaranteed to upset long standing consensus. The Revert part of BRD can be assumed if you attempt to make a bold edit... and so "Discuss first" is best. Blueboar (talk) 22:24, 7 June 2015 (UTC)

Let's ignore everything outside of mainspace for this discussion; relative to the entire editing population, I doubt many editors know they are allowed to update policy and guideline, feel competent to do so, and want to do so. Within mainspace, based on your comments, would it be at all feasible to produce, say, three different "editing models", with a road map for each? If that could be done, then the main area of process-related conflict would be which model to use at a given time on a given article, and any model change switch could be decided by local consensus. One of the models could be pre-designated for use with the more stable articles, which would avoid a problem when there aren't enough people around to form a consensus. It could be designed to work for a two-editor situation (a one-editor situation doesn't need a process because an edit war requires at least two). Perhaps three sizes could fit all? ―Mandruss ☎ 23:15, 7 June 2015 (UTC)

[[

File:Oversimplified flow chart for editing.png|thumb|This shows a possible decision-making path for editors on Wikipedia.]]

Thank you for keeping the less-experienced editors in mind. It's easy to lose sight of that perspective.

There are probably a dozen alternatives (some of which are listed at WP:BRD#Alternatives), but if you exclude anything that smacks of edit warring, then the basic categories might be these:

1. Bold, refine, rejoice
2. Bold, revert, discuss
   • with the editor that reverted your bold change (BRD is focused on talking to one or two objectors, not everyone)
   • with everyone/via formal dispute resolution processes
3. Bold, revert, try again (trying something else, maybe a less ambitious edit, not re-reverting)
4. Bold, revert, give up (or move on to another article: an ideal approach for cleaning up ((linkfarm)) problems)
5. Moderate edits (e.g., deliberately change one paragraph or other small piece a week until you're done)
   • Usual options of discussing, re-attempting, and giving up if you're reverted, but reversions are less likely
6. Discuss first (aka "timid" editing; wide range of options in this category)

Well, that looks like six. Probably other editors would produce different lists. WhatamIdoing (talk) 02:32, 8 June 2015 (UTC)

At over 14,000 edits, I don't understand a third of the above, or how I would use it in practice. Am I atypically stupid, or atypically lazy? Even if I understood it, that would be worthless unless most of the others present understood it, too; a majority agreement as to process is needed. Seriously, how are editors expected to stick it out long enough to understand all that? With road maps, we don't need to understand it; we just follow the instructions. We can drive our cars without being experts in auto mechanics, but only because automakers figured out how to isolate us from all that and "dumb down" cars.
Thank you for keeping the less-experienced editors in mind. It's easy to lose sight of that perspective. - sounds a bit like we're talking about a small minority that's easy to forget. Are we? My perception is that perhaps 10% of active editors are at a level capable of understanding the above, or anything close to it. Again, unless the majority present are in that 10%, their knowledge can't have any beneficial effect. ―Mandruss ☎ 05:23, 8 June 2015 (UTC)

Well, I've added a flowchart. To keep it on one page, I've simplified some of the options, but it's the general idea. Maybe that will make more sense than the rather jargon-y list.

IMO you don't need to know any of this to edit. You just need to click the 'Edit' button and have a go. You can figure out each step individually, as you go along, without any sort of roadmap. Just trying something out is how most of us get to the point of being able to identify all the different options. WhatamIdoing (talk) 03:00, 9 June 2015 (UTC)

Do we have statistics on number of active editors by edit count? Like a graph? ―Mandruss ☎ 11:29, 8 June 2015 (UTC)

Maybe, although I don't know where; however, it looks enough like this as to make no particular difference. Or, to put it another way, in the history of Wikipedia, there have been 25,369,760 accounts created, and your contributions put you in the top 0.02% for number of edits ever. If you ranked there in terms of American income, you would not only have been "a one percenter", but your income would have have ranked in the top 10% of American millionaires (using the definition of a millionaire as someone who earned at least a million US dollars last year, not those with lower incomes who have saved a total of $1M or more). WhatamIdoing (talk) 03:00, 9 June 2015 (UTC)

My sole objective is to achieve a dramatic reduction in edit warring. It is abundantly clear that the status quo is not working, and yet, most experienced editors say that no change is warranted. I can't get my head around that; if it's not working, a change is warranted, full stop. That would seem to be the first step on a path toward a solution. We are not going to repeal human nature any time soon, so it's not realistic to simply say that the required change is within us. ―Mandruss ☎ 09:28, 9 June 2015 (UTC)

I believe that everyone would like to see less edit warring. Speaking for myself, requiring BRD is neither a practical nor an effective way to build a good encyclopedia, and its effect on the more severe forms of edit will probably be zero. WhatamIdoing (talk) 17:57, 9 June 2015 (UTC)

What I'm talking about is that the elders don't say, "Promoting BRD is a bad idea, let's find a better solution to edit warring." Instead, most of them say, "Existing policy and guideline is all we need to prevent edit warring. People just need to use it correctly." My reply is, "How's that approach working so far, after years of use?" At that point they go silent. There seems to be a widespread reluctance to accept that some change is in order, and to be willing to take a look at alternatives like this one with an open mind. ―Mandruss ☎ 10:30, 10 June 2015 (UTC)

I agree that edit warring is a problem. I agree that we should try something different (or even multiple things). I disagree that we should try this different thing.

Since you seem to have a good grasp of the problem, I invite you to expand Wikipedia:Irregular verbs on Wikipedia to include a new section on edit warring. The last line will be "They edit war", of course, but what do you think that 'the elders' believe themselves to be doing when they are reverting? WhatamIdoing (talk) 19:22, 11 June 2015 (UTC)

• I'm strongly in favor of doing a better job of explaining the [original] concept behind BRD, at WP:CONSENSUS (specifically WP:EDITCONSENSUS), and beginning this with the outlining-alternative-approaches model given above. That would probably be most productively done at WT:Consensus, of course, but this is a nice start. With that page being a policy, it's unlikely that any of the bad aspects of BRD will survive such a vetting process, and we might get something very good out of it.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  13:40, 14 June 2015 (UTC) Rescinded. Just mark it ((Historical)). WP:CONSENSUS is fine as it is. (See first item at #Case studies, below, for why I changed my mind.)  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  06:14, 18 June 2015 (UTC)

Make Wikipedia:BOLD, revert, discuss cycle a redirect to Wikipedia:Consensus#Reaching consensus through editing

• Support making Wikipedia:BOLD, revert, discuss cycle a redirect to Wikipedia:Consensus#Reaching consensus through editing. The current WP:BRD essay rather muddies the waters than "supplement the Wikipedia:Consensus" policy. It causes more trouble than it solves, a sort of overcomplicated alternative ruleset to what is actually policy. Typically WP:BRD is invoked when a revert/discussion cycle has gone apeshit, and all parties contend that they were faithful to the essay, so "doing nothing wrong". Whether or not they adhered to the policy in the matter WP:EDITCONSENSUS and subsequent sections at WP:CONSENSUS seems not to bother them, as long as they can make themselves appear immaculate in the light of WP:BRD. And then indeed that essay is so complicated that anyone can defend almost any edit with it, using the sort of counterproductive "I did – no you didn't" back and forth as a replacement for consensus-seeking. --Francis Schonken (talk) 08:11, 8 June 2015 (UTC)
• Very hesitant about this. This proposal means making BRD "policy". Kneejerk reaction is a big NO, it means throwing away nearly all the documentation on BRD, and risking future editors believing that they "MUST" BRD. In fact, BRD is an advanced high speed method for fixing/building content, and the BRD rules, as they, are mark the boundary between bare minimum consultation and edit warring. However, there might be something serious to this idea. If the wording about BRD was correct, and was placed in the policy, it may give BRD a better grounding, and the essay page could remain to discuss DRB more lengthily. There is a problem that BRD is pseudo-policy, and that the essay is not written as policy. I'm pretty sure I will object to converting the essay to a redirect, but this is a very new and interesting idea. --SmokeyJoe (talk) 11:50, 8 June 2015 (UTC)
  • Re. "this is a very new ... idea": [2] – even then I don't claim to have invented the idea, I'm sure I read it many years ago already (around the time when File:Consensus Flowchart.svg was introduced at WP:CONSENSUS?) when it was decided to give WP:BRD the benefit of the doubt.

  Re. "BRD is an advanced high speed method for fixing/building content" – I challenge that summary: true, it is "advanced" in the sense that WP:BRD's File:BRD1.svg has more steps and complications than WP:EDITCONSENSUS's File:Consensus Flowchart.svg, but that can hardly be seen as increasing speed.

  There's no kneejerk in this: WP:BRD has had its chances for many, many years. It hasn't worked out. Now we can feel sorry for ourselves having let it absorb so much energy over the years. If I had foreseen this around the time when WP:EDITCONSENSUS was adjusted to the practical "high speed method for fixing/building content" it is now, sure, I had been more insistent to make WP:BRD a redirect then. I don't intend to lose further time with self-pity though. The practical guidance on the matter is policy, no need for the somewhat more bloated version that doesn't seem to really know where it is going. --Francis Schonken (talk) 12:47, 8 June 2015 (UTC)

• I'd rather re-write BRD to return it to something close to its original (which was advice for experienced, clueful editors who were trying to jolt unproductive discussions out of their ruts by giving an example of what could be done and working through the objections one at a time). WhatamIdoing (talk) 03:56, 9 June 2015 (UTC)
• Naw. Effective deletion of the essay and redirection of the many, many links to WP:BRD to a different target would be unhelpful. VQuakr (talk) 04:04, 9 June 2015 (UTC)
  • I could live with tagging it as ((historical)), pointing to WP:EDITCONSENSUS as the current applicable guidance, but then I don't know whether WP:BRD ever had guideline or guideline proposal status (demotion of an ineffective essay is usually deletion or redirection).

  Another solution is possible, and I could live with it too: it's the solution hammered out for WP:DEFINING after some intense discussions, with the same problem: it had been used historically as a shortcut in so many previous discussions, that re-redirecting the shortcut seemed impossible. The redirect goes now to a page that is framed as a how-to page that transcludes relevant guidance from applicable guidelines, including the one it originally redirected to. Instead of rewriting Wikipedia:BOLD, revert, discuss cycle (which doesn't seem very practical given the wide array of opinions on it), why not replace the "essay" template by a ((Howto)) template and, after a short introduction, quote (by transclusion, so that the content is automatically updated when the guidance is updated) relevant guidance from WP:BOLD (for instance the intro and the "... but please be careful!" sections), and WP:CONSENSUS (I suppose the WP:EDITCONSENSUS and "Reaching consensus through discussion" sections)? --Francis Schonken (talk) 21:20, 10 June 2015 (UTC)

• That looks like a highly sensible and useful solution, so it's not going to happen. Ever. Diego (talk) 15:50, 11 June 2015 (UTC)

*OpposeSupport: WP:BRD, as it stands, is way, way, way too bold. Reverting should be done on a case-by-case basis. Reversion can either foster discussion, or lead to constant arguing without any compromise on the horizon. Esquivalience (alt) (talk) 00:10, 4 July 2015 (UTC)

• • As far as application of guidance goes: WP:EDITCONSENSUS doesn't seem to have that trail record of problematic application, although it is applicable in the same circumstances as BRD. Maybe just because the former is better written, clearer, less prone to misinterpretation, and just more effective with less of the problems associated with BRD. --Francis Schonken (talk) 06:50, 11 June 2015 (UTC)
• Reluctant oppose: I agree entirely with all of Francis Schonken's rationales, but I wouldn't go that far. We tolerate a lot of really iffy essays, and BRD does sometimes get used to good effect. I think WhatamIdoing sums it up best: 're-write BRD to return it to something close to its original'.
  But strongly support tagging BRD with ((Historical)) as soon as WP:EDITCONSENSUS has been upgraded as proposed in the subthread immediately above this one.
  Then, rewrite BRD to observe and describe a mindset/approach/preference to dispute resolution and how/why it often works, not recommend a methodology/process/practice which often fails dismally. The entire problem with BRD is that it's been written as procedure you should follow, which some editors (including admins) increasingly see as something you can be punished for disobeying, rather than a more philosophical essay on how agreeing to stop and discuss can be used to resolve differences in place of revertwarring back and forth. The former is something to impose, the latter is something to mutually participate in. After a rewrite like that, restore the essay tag.>
   — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  13:54, 14 June 2015 (UTC)
• Strongly support tagging BRD with ((Historical)), but no redirect, per SmokeyJoe's observation. See first item at #Case studies, below, for why. BRD, regardless of the fact that some have used it to good effect, is essentially a WP:POINT and WP:FILIBUSTER tool. I've given it all the benefit of the "good faith" doubt that I can. I'm done.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  06:12, 18 June 2015 (UTC)
• Oppose WP:BRD is still frequently cited, so it is no historical. The essay could be rewritten, but not just redirected. Graeme Bartlett (talk) 22:29, 14 June 2015 (UTC)
• Oppose Regardless of whether it should be promoted to a guideline, the BRD essay is still quite useful and should not be paved over. Darkfrog24 (talk) 18:59, 18 June 2015 (UTC)
• Oppose converting to a redirect. WP:BRD is a Wikipedia historical fact. The incoming links, I bet there are a lot, need to arrive at what something reflecting what was intended at the time of writing. Support tagging historical with pointers to the WP:EDITCONSENSUS section, WP:BOLD and WP:3RR. --SmokeyJoe (talk) 13:14, 23 June 2015 (UTC)

Tag WP:BRD as ((Historical))

• Support per reasons given above and below. Under the ((Historical)) tag add a friendly reminder that the former essay has been replaced for all extents and purposes by the WP:CONSENSUS policy and additional guidance found in WP:BOLD. --Francis Schonken (talk) 07:56, 18 June 2015 (UTC)
• Support that. It would put an end to people using it as policy, and work as a reminder of what the real policy is. I would also add a link to "...additional guidance found in WP:3RR" (in addition to the link to WP:BOLD), to appease rollbackers. Diego (talk) 09:30, 18 June 2015 (UTC)
• Oppose It's a good essay, and still frequently cited. In many cases, it does represent best practices, even if it does not carry they weight of policy or guidelines. We should not mark historical those pages which are still widely supported and actively used. --Jayron32 07:11, 26 June 2015 (UTC)

Case studies - real discussions illustrating why BRD should be elevated or not

• Here's one going on right now (well, I just terminated my participation in it). This may well be best example in the history of Wikipedia of how BRD fails and can be abused: Wikipedia talk:Manual of Style#Improving examples in "Quotations": "Point of View" section. Short version (it's a text-wall, as BRD tends to lead to; it just seems nitpicky until round 2, when the "fun" starts): I opened a discussion in good faith, after a revert of a bold edit, showing my copyedit and insertion of some new content, plus a clear rationale. This was then nitpicked in virtually every possible way, in a circular WP:FILIBUSTER, WP:IDHT and WP:TROLL pattern, through three nearly identical cycles, while agreement to accede to the edit was withheld until conditions that are literally impossible are met, yet the D in BRD must continue! It borders on the unimaginable. I'm actually changing my !vote above, in favor of just redirecting BRD to WP:CONSENSUS on the basis of this abuse of (voluntary) process, and am unlikely to ever agree to BRD again.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  06:12, 18 June 2015 (UTC)

• Without having read you case throughout, I immediately note that it is not BRD (BRD is a cycle, after some D return to B, it is not BRDDDD...), and then note that the MOS pages are particularly troublesome places, and then note that BRD is intended for mainspace article editing where the common objective is more objective than a MOS page. --SmokeyJoe (talk) 06:30, 18 June 2015 (UTC)

• Good illustration of what's wrong with WP:BRD. Above I argued how WP:BRD is onworkable because of its many redundant complexities. When you're unsuccessful in proving your immaculateness with WP:BRD as written, sure, why not, invent a new unwritten rule, adding another redundant layer of complexity "...BRD is intended for mainspace article editing..." – way to go! Is that what you propose as a rewrite to salvage an essay that is steering for its own destruction? Is that making it more straightforward as argued above?

FYI, WP:EDITCONSENSUS doesn't have these complexities, works in all namespaces, and points to alternatives when getting stuck in a discussion. It's so easy to say "..., it is not BRDDDD..." – sounds good, but what does it actually say? Nothing, not a single idea offered on how to get out of an unproductive discussion (or was the idea: when being bored by "...DDDD", throw a few bold edits in, then you're immaculate for WP:BRD...?) In contrast, WP:CONSENSUS has direct access to all sorts of tools to bend an unproductive discussion in something with a clear outcome, either an edit or a status quo... without losing time with empty procedural discussion. --Francis Schonken (talk) 07:51, 18 June 2015 (UTC)

Francis, um yes. I take your point. Can I add something that may further make your point: People who use BRD well don't need the essay for guidance on how to do it, and people who need to read the essay, even if it were better written, probably should not be encouraged to claim they are using it. I also take someones point that the essay serves as an invitation to conflict, more than it helps. Maybe it would be a good idea to tag it as ((historical)), with a pointer to WP:EDITCONSENSUS. --SmokeyJoe (talk) 08:53, 18 June 2015 (UTC)

Was thinking along these lines as a replacement for the current ((essay)) template on top of the page:

This page is currently inactive and is retained for historical reference. For all intents and purposes this former essay has been replaced and is superseded by the WP:CONSENSUS policy (in particular its WP:EDITCONSENSUS section), by policies against edit warring (including but not limited to WP:3RR), and by additional guidance found in WP:BOLD.

Shortcuts WP:BRD WP:BRDC WP:CYCLE

--Francis Schonken (talk) 09:18, 18 June 2015 (UTC)

Updated per Diego's suggestion above. --Francis Schonken (talk) 11:05, 18 June 2015 (UTC)

Support this tag, but remove the 2nd and 3rd shortcuts from the linkbox. --SmokeyJoe (talk) 13:09, 23 June 2015 (UTC)

• I often correct errors or implement the result of RfCs on hundreds or even thousands of pages at once. Every time I do, I get a handful of reverts from IP addresses that have never edited Wikipedia before, with no edit summary. Rather than starting a talk page discussion that has a near-zero change of getting a response, I simply re-revert [2RR], and if it doesn't "stick" (which happens pretty much never), then I start a discussion. I don't think that changing 3RR to 1RR (which is what elevating BRD will do) is a good idea. --Guy Macon (talk) 07:30, 18 June 2015 (UTC)

Excuse me? "Abuse"? You proposed new text, got reverted, and then got all huffy when I asked you about sources! How is that abuse of BRD? A lack of desire to enter unsupported personal opinions into the MoS does not constitute abuse of process. As the sole other participant in the discussion that SmC is citing, BRD only came up when I defended SmC's right to add the disputed text in the first place. It was an expression of approval of SmC's choice to take the matter to the talk page. [3] I was trying to be nice and keep SmC's feelings from being hurt. It seems I failed. So this is one way in which someone might use BRD, but in this case it didn't work. Darkfrog24 (talk) 19:08, 18 June 2015 (UTC)

• This is not directed at anyone specific... just an observation. I have noticed a lot of hypocrisy when it comes to BRD... a lot of editors dislike the BRD cycle when they are the one editing BOLDly (and someone else reverts and wants discussion)... but support it when (someone else is editing BOLDly and) they are the one doing the revert and calling for discussion. Blueboar (talk) 15:41, 23 June 2015 (UTC)
  • True. Perhaps you could turn that into an entry for Wikipedia:Irregular verbs on Wikipedia. WhatamIdoing (talk) 23:12, 23 June 2015 (UTC)

Should we enable the creation of articles by IPs with safeguards? See Wikipedia:Village pump/technical#Where do we go from here? 156.61.250.250 (talk) 09:38, 27 May 2015 (UTC)

Some years ago, pending changes were introduced on an experimental basis. A subsequent RfC voted to end the experiment, but pending changes are still with us. Some administrators take advantage of this fact by putting more articles in. Most of the work on Islamic calendar, for example, is done by IPs, but since it was put in pending changes (for no good reason) editing has stopped. I suggest we enforce the RfC and that all articles currently in pending changes be taken out.

This will mean that pending changes reviewers (who I take to be everyone who is autoconfirmed) will have nothing to do. I therefore propose that IPs be given back the right to start articles for an experimental period of six months on a pending changes basis. That is to say, their articles would not be publicly visible until the text had been approved by an editor.

Technically, I suppose that what would happen would be that the article would be created and accessible as normal, with the usual edit and history tabs. The text created by the IP would appear in the edit box but would not be seen publicly (the article would appear as any page does when it has been blanked). Editing would be as normal for pending changes, with the first edit to be publicly visible being the first edit by an autoconfirmed editor. Normal deletion policy would apply.

Where an editor tags for CSD he may find it convenient to make the offending text publicly visible to assist those following up. Either way, if there are no objections an administrator will be along about fifteen minutes later to delete. Every article started in this way will automatically remain within pending changes for one month after creation.

There are two big advantages of this proposal. Article growth went well from inception until just shy of the five million mark, when it stalled. This proposal will put it back on track. It will also result in an infusion of new blood. Wikipedia is haemorrhaging editors. It desperately needs new ones. 156.61.250.250 (talk) 14:46, 6 May 2015 (UTC)

Isn't that essentially AfC? Kharkiv07^Talk 15:06, 6 May 2015 (UTC)

The difference is that you can put something in AfC and it hangs around for months so most people don't bother. Under this proposal you are in the driving seat so a lot more people will add worthwhile content. 156.61.250.250 (talk) 15:48, 6 May 2015 (UTC)

As is, most articles created by newcomers are deleted quickly without discussion, a situation which I believe to be very BITEy, and possibly is a significant cause of Wikipedia "haemorrhaging editors"; move the permission to create articles a bit farther back, and the situation will become worse, not better. עוד מישהו Od Mishehu 20:28, 6 May 2015 (UTC)

I'm confused by your proposal for a few reasons. First, IP editors can still edit with pending changes, in effect it is a weaker version of semi-protection which BLOCKS all IP editors. I would suggest moving many semi pages to pending changes actually and strongly oppose removal of pending changes. As for AfC, it works. Reviewing a new article is a process, more so than a simple pending changes button, and does take a little longer. And third, only users with the Pending changes reviewer can review the pending changes, even though any auto confirmed users edits will be accepted. EoRdE6^{(Come Talk to Me!)} 23:31, 6 May 2015 (UTC)

• You seem to have missed the series of RFCs that reauthorized the use of pending changes protection (level 1 only). Monty₈₄₅ 23:43, 6 May 2015 (UTC)

The last RfC decided that PC was wanted and it was up to editors to decide how to implement it. To date there has been no consensus on this so there is no mandate to put Islamic calendar (or any other article for that matter) into PC. PC seems to be very complex - there are at least two levels of it and SlimVirgin said she didn't understand it. I think it is too complicated. Given that here in March there was a consensus that PC should not operate for an extended period all that is needed is a week of semi - protection where necessary to drive the vandals away.

Od Mishehu says that "most articles created by newcomers are deleted quickly without discussion". That's a failure by the established editors. They should work to bring the articles up to standard, not delete them. This is why IPs should be allowed to create articles - they then get the benefit of all the other editors who know something about the subject adding sources and content. That is the essence of crowdsourcing.

Replying to EoRdE6, AfC takes months and is permanently backlogged. With direct article creation other editors can come in and get the article on the road to GA status in a few days. You see articles like the Charlie Hebdo massacre which within just a few hours of creation are full of content and sources. The system of creating stubs giving experts the opportunity to come in and build a full length article has worked well.

There is a proverb "If you want a job done do it yourself". AfC relies on getting other people to post the content to mainspace. It's a form of action by proxy which is proven to be inefficient. The British government in 2002 experimented with postal voting - included was the local council election in my area. There were no polling stations (no electronic voting here - today is the general election and everyone takes printed ballots, fills them in and posts them into the ballot box). The voters had to fill in the ballot papers then give them to the postmen who had to give them to the council. Needless to say the experiment was not repeated.

It's the same everywhere. We got supermarkets from America - before then shoppers queued at the grocer's while he picked their selections off his shelves. Now checkout operators have been done away with and customers scan their shopping themselves - no more queuing. No more queuing at the public library either - readers return and renew their books themselves at self - service kiosks, resulting in a more efficient use of their and the staff's time. Self - service machines are at railway stations - everywhere you can think of. Introduction of AfC was a retrograde step. 156.61.250.250 (talk) 11:21, 7 May 2015 (UTC)

I suggest you take a reread of Wikipedia:Protection_policy#Pending changes protection and Wikipedia:Pending changes as you are mistaken. The closing statement of the last RFC which dealt with the issue is quite clear Wikipedia:PC2012/RfC 3.

There was very strong consensus to enable the use of Pending Changes throughout all namespaces

and further

The consensus on this was fairly clearly against having any specific criteria, but a significant minority expressed concern that its use is less well-defined than is the use for conventional protection methods; if enormous inconsistencies with application are seen upon implementation, this may be a topic worth revisiting

and at the end

As with the previous RfC, assessing the usefulness of what gained consensus here will require some monitoring. The same time frames (1 month for obvious problems, more for subtler issues) seem to fit with everything in this discussion as well. It appears that after this and the previous RfCs, we have the necessary framework to roll out Pending Changes, and we know what aspects of its use will require the most monitoring and later attention.

So no we aren't waiting for the community to come to some sort of agreement on how to use it. (There were earlier RfCs which also dealt with when to use PC1.)

Of course, if you feel that PC1 is being in ways that are unhelpful in some instances, you're welcome to start a properly fleshed-out RfC on the matter, but I strongly urge you to talk to others about this before hand, and make sure you actually otherstand what the history is, otherwise your RfC is unlikely to do anything useful. (As it stands, you're failing to follow information I had sort of heard before, but to be honest had mostly forgotten by now and only properly relearned by actually reading the PC page and following the links to the RfC has lead to your proposal being sidetracked by this unnecessary discussion.) Now if you feel the admin's closing wasn't an accurate summation of the RfC consensus, or if you feel that the RfCs had insufficient participation compared to earlier RfCs, you could try to dispute that, but relitigating stuff after 2+ years rarely works well.

There were two followup RfCs, Wikipedia:Pending changes/Request for Comment 2013 and Wikipedia:Pending changes/Request for Comment 2014, which concerned PC2 and ultimately came up with criteria for the use of PC2, but no actual consensus to use PC2. These don't of course affect the use of PC1, for which in the absence of clear evidence consensus has changed, we stick with the older RfCs which showed there is consensus to use PC1.

Nil Einne (talk) 15:11, 9 May 2015 (UTC)

Your example also seems fairly poor.

Perhaps Islamic calendar may have had useful IP edits, but it also had many that were reverted (which look to be more or less the same edit from a persistent IP hopper). I didn't look in to these enough to say if the reversions were proper, simply that they happened therefore whether before or after PC, IP edits were being rejected.

More importantly perhaps, the time frame here is insufficient to tell us anything about pending changes, particularly if you look at the logs or edit history carefully. On 13 April, both PC1 and semi protection were applied with the PC1 due to expire on 13 July and the semiprotection on 27 April. My thoughts and a search confirmed via Wikipedia:Help desk/Archives/2015 March 18#Pending changes and Semi-protection simultaneously that this works and is evidently done sometimes when it's felt that there is an acute problem that needs to be dealt with via semiprotection for a short time, and a chronic problem that needs PC1.

Without commenting on whether this was the case for Islamic calender, this means it was impossible for IPs to directly edit from 17:36 13 April to 27 April. So there's a fair chance the absence of IP edits for this period had nothing to do with PC1.

So really all you're talking about is from 27 April until now. In that period, we had 3 IP edits. 2 were rejected, 1 accepted. Again without commenting on the appropriateness of any of these edits, unless we were getting an average of 1 useful IP edit on average every 3 days or so (which it doesn't look like we were), it's difficult to useful conclude things were so much better before PC1. You simply lack sufficient data to be able to make any conclusion about a reduction of helpful IP edits. And at the very least, the editor who kept making the same change which I think lead up to the semiprotections and PC1 seems to have left for now.

BTW, for the avoidance of doubt and confusion, I should mention I'm aware editors who haven't been auto/confirmed are affected as well, I just used IPs for shorthand and since it's also harder to spot such editors.

Nil Einne (talk) 15:59, 9 May 2015 (UTC)

I think that the proposal that an article should go into PC just because a lot of IPs don't edit it is misconceived. The Islamic calendar is hardly a mainstream subject. Your comments on PC generally are a joke. About twenty years ago the local council proposed to demolish a housing estate and being short of cash proposed to sell off the land to a private developer. To do that, it needed the consent of the tenants. It assured them that the estate would not be sold if the majority were opposed. The tenants kept asking for a ballot but the council ignored them. Finally the ballot papers arrived, and the tenants were dismayed to see that their votes would be rolled up among those of tenants on other estates which were going to be refurbished. This followed an "opinion poll" conducted by a survey company which doorknocked to ask the tenants what they wanted for their estate but did not ask the key question Do you want your estate to be sold or not? The council's ballot paper was craftily worded - not "Do you want your estate to be sold?" as discussed in literature and meetings but "Do you want your home to be sold, meaning that the tenants' views would be submerged amongst the views of all the tenants on other estates who were going to get new kitchens and bathrooms instead of seeing their homes reduced to rubble.

Same here, there was a lot of discussion about how pending changes might work, but no discussion of whether its reenablement would be a good or bad thing. Since pending changes is a dead loss, let me reformulate my proposal. IPs would be able to create articles just as before Siegenthaler with one exception - edits by non - autoconfirmed editors would only become publicly visible when the page was first edited by an autoconfirmed user. 156.61.250.250 (talk) 13:21, 12 May 2015 (UTC)

The claim "Some years ago, pending changes were introduced on an experimental basis. A subsequent RfC voted to end the experiment, but pending changes are still with us" is factually untrue. What happened is that PC was implemented with permission of the community with the restriction that it be removed after a set period, that promise was broken and PC remained, then all hell broke loose. Later, after it was removed and we put down the pitchforks and torches, a second proposal was made to implement PC permanently, and the decision of the community was yes for level one PC and no for level two PC. So the reality is that [A] the current PC policy is supported by the community and [B] we would be fools to ever again believe a promise like "let's try this for six months and then we will turn it off and evaluate how theexperiment went" after having been lied to in the past. --Guy Macon (talk) 13:34, 21 May 2015 (UTC)

Editors were given two alternatives: PC anywhere or PC in restricted areas. The third alternative, PC nowhere, was not presented. This is the same trick the council played when wording its ballot on council house selloffs. After John Prescott was told where he could stick his housing policy he came up with more alternatives:

• transfer to private landlord (and if you disagree there's no money to maintain your home so it will fall to pieces around you)
• private finance initiative (PFI) where developers get a long lease in return for financing the work
• arms - length management organisation (ALMO) where the council retains ownership of the homes but the management is farmed out to a quango (quasi non - governmental organisation).

The fourth option, stay as you are, was not presented.

Tenants were ballotted on the three options and - surprise - the council claimed 80% of them were in favour of option 3. In fact, hardly anyone voted, so the actual percentage in favour was tiny.

As for broken promises, anyone can start an RfC suggesting that PC be turned off, and if it wins a consensus that's more power to the community. Don't underestimate the power of public opinion - Prescott had a scheme to decimate (and I don't mean reduce by 10%) perfectly serviceable housing in Liverpool which was withdrawn in the face of strong opposition. 156.61.250.250 (talk) 16:30, 21 May 2015 (UTC)

156.61.250.250, I suggest that you read the discussions and RfCs in question and edit the above claims accordingly.

In particular, Wikipedia:PC2012/RfC 2 and Wikipedia:PC2012/RfC 3 clearly show that your your claim "The third alternative, PC nowhere, was not presented" has zero basis in reality. Did you really imagine that nobody would check? --Guy Macon (talk) 21:33, 21 May 2015 (UTC)

You've linked to eleven RfCs on this subject. I was given just two to look up, one of them being Wikipedia:PC2012/RfC3 which you also cite. I don't see anywhere in that wall of text where editors were asked to !vote on the proposition "Do you (a) want to enable PC or (b) switch it off. 156.61.250.250 (talk) 08:43, 22 May 2015 (UTC)

Actually you were given 2, which all have the header showing all the RfCs. More importantly, your original comment was "The last RfC decided that PC was wanted and it was up to editors to decide how to implement it. To date there has been no consensus on this".

I'm sure I wasn't the only one who assumed that this meant you were already aware of Wikipedia:Pending changes/Request for Comment 2012 (which had, we think at least 503 participants) where the decision had already been made that PC was wanted. It sounded like you only weren't aware about the following RfCs (together I think with the discussions on the policy page), where decisions were made and consensus reached on how to implement the existing consensus for PC.

I don't know that much about the history surrounding all the RfCs, but I presume the decision was made that there was no need to revisit the decision to implement PC since it had already achieved consensus in the earlier RfC. (Although opposition to PC wasn't ignored, it just wasn't made a specific question in the RfC.) Note that the consensus wasn't conditional on there being a final yes or no !vote (which is a silly concept anyway) on whether to implement PC after a policy a better policy was in place.

In fact the RfC itself didn't even find there was need for consensus for a new policy, the draft policy was sufficient but not ideal. Notably also, it looks to me like there were far more participants in the decision to implement PC, rather than the later discussions surrounding PC policy. (Only the 2013 RfC about PC/2 seems to have come close but also still quite far.)

However if you believe consensus has changed, you're welcome to open yet another RfC. It would of course pay to do your own reading in the hope you will show a far better understanding then you have here on the history. Rather then expecting to be spoonfed everything when you are the one making the proposal. If not, frankly your proposal is likely to fail as much as your one here.

Not to put a subtle point on it, but your original comments were bad enough. Now it sounds like you didn't even know about the major RfC despite being up in arms about how PC never had consensus (even if it wasn't the focus of your proposal). If you start an RfC where the focus is disabling PC saying there was never any consensus, and you say this partly because you weren't even aware of the RfC which had (we think) at least 503 participants, well expect to be ignored.

Nil Einne (talk) 17:01, 28 May 2015 (UTC)

Hello, here's my view on the subject. In a word, social issues can't be solved with technical solutions. --NaBUru38 (talk) 00:53, 2 June 2015 (UTC)

I think it's time to add a comment which has been sitting on 156.61.250.250's talk page for days waiting to be pasted over.

@Nil Einne:Would you please paste the following statement to the Village pump (policy) discussion.

I've been given confusing references - RFC 2012 (Sept.Oct.Nov), Wikipedia:PC2012/RfC 2, Wikipedia:2012/RfC 3, and now Wikipedia:Pending changes/Request for Comment 2012. Having read through this last I see that editors endorsed the use of PC in line with a draft policy. This draft policy explains the variations PC1 and PC2 but says nothing about which one is the more desirable or whether neither is desirable. After mentioning the above RfC you mention "the following RfCs ...where decisions were made and consensus reached on how to implement the existing consensus for PC."

@Nil Einne:RFC 2013 and RFC 2014 are by definition "following RfCs". RFC 2013 decided

There is only a consensus for implementation if and only if an rfc concerning criteria for its use gains community - wide consensus first.

So there is one more RfC to look at - RFC 2014 - and the close of that is a reiteration that PC will not be implemented until there is a consensus on how to implement it. If and when that discussion takes place it would be totally wrong to deny editors the opportunity to decide that they don't want PC at all. This is the principle of "no parliament can bind its successor". 156.61.250.250 (talk) 08:48, 30 May 2015 (UTC)

Since the link at the top of this section no longer works I'm adding the content here:

At a time when the long - term viability of Wikipedia is in doubt, editors have been discussing invigorating the community by enabling the creation of articles by IPs subject to safeguards. There have been no opposes. WMF have been asked to comment and have raised no objections. The mood of the community appears to be that the change should be implemented. Presumably it would involve reversing the post - Siegenthaler dev changes and moving onto a "level 3" pending changes regime in which pending changes would be turned off immediately an autoconfirmed editor edited the article. What is the procedure for turning an agreed change into reality? 156.61.250.250 (talk) 10:22, 21 May 2015 (UTC)

That change is far from agreed upon, I see more people rallying for complete removal of IP editing than this. We have WP:AfC that let's IP editors create an article, and that is all that has been agreed so far. NPP is badly backlogged, and it is well documented that most articles by new editors fail, no references, pure advertising etc. I can't see consensus on this anytime soon. EoRdE6^{(Come Talk to Me!)} 13:09, 21 May 2015 (UTC)

That's the whole point of allowing new users to do things, so they learn enough to become valuable contributors down the line. Checking the new pages feed I saw one article at the top of the list awaiting review. A few seconds later it had been patrolled. If PC is turned off, all the PC reviewers can turn their attention elsewhere.

If you think people are agitating for the removal of IP editing you're looking in the wrong place. The proposition in the March proposals RfC was to ban IP editing or never unprotect a semiprotected page. It was defeated nemo contradicente. Some quotes:

• Wikipedia is the encyclopedia that anyone can edit.
• There are plenty of people that come on Wikipedia reading, notice a problem and, as an IP, fix it.
• If we block IP editing, we'll move one step closer to being like Citizendum. With all due respect to Sanger's efforts, visit Citizendum's website and see how spotty their articles are. There are some very well - known topics that don't have articles there. That's what happens when you make it hard to edit a wiki. Do you want that to happen to us?
• 81.9% of edits by unregistered users were not vandalism. 156.61.250.250 (talk) 17:57, 21 May 2015 (UTC)

• Strong agreement with 156.61.250.250. If you want to count edits that occurred as a result of our IP editing policy, count all of mine, because I started as an IP editor and would have never started if this had been one more website that requires registration. --Guy Macon (talk) 20:56, 21 May 2015 (UTC)

Discussion has now slowed. There is a clear consensus that this useful change should be implemented. Can someone please close accordingly. 156.61.250.250 (talk) 08:12, 26 May 2015 (UTC)

I can count one person (Guy Macon) in both this discussion and the one at VPP who agrees with you. How is that clear consensus? --Ahecht (TALK
PAGE) 16:16, 26 May 2015 (UTC)

2 to 1 in favour = 66 2/3% majority. 156.61.250.250 (talk) 18:43, 26 May 2015 (UTC)

I am tempted to apply a close as you requested. My close would be NO CONSENSUS based on a majority of one, and NO CONSENSUS based on a participation of 3 being grossly inadequate to propose a major sitewide change. If you want to seek a consensus for change I suggest you slap an RFC notice on here. That will get you participation and a close. Alsee (talk) 07:18, 27 May 2015 (UTC)

Seconded. Not enough participation to ratify a major change. Samsara 07:23, 27 May 2015 (UTC)

I see that an RfC has been started at Wikipedia:Village pump (policy)/Archive 120#Proposal to change the focus of pending changes. 5.150.92.19 (talk) 11:36, 31 May 2015 (UTC) — Preceding unsigned comment added by 5.150.92.20 (talk)

I note that discussion has paused. Can we confirm that now this has been made into an RfC this discussion has legitimacy, irrespective of the participation? The proposer is an IP so is not in a position to advertise this at WP:CEN but if any editor feels it necessary no doubt he or she will do it him - or herself. I think the legitimacy of the decision here is a given taking into account that the removal of IP article creation powers was never authorised by the community. 5.150.92.19 (talk) 12:56, 10 June 2015 (UTC)

I just found out that this idea of starting an article out with a blank page is not new. At present, non - autoconfirmed editors do their articles in their sandbox, then an autoconfirmed editor creates the blank page and the first editor pastes the content from the sandbox. So I can say with confidence (correct me if anyone disagrees) that even if nobody contributes to this discussion in the remaining fifteen days we have the mandate to make this tweak in the software. 5.150.92.20 (talk) 14:21, 11 June 2015 (UTC)

• Strong Oppose AfC is the process for this, there is no reason to have a duplicate process. What we need is more AfC reviewers, not another backlog. In my personal opinion we should be going in the opposite direction, preventing unconfirmed users from creating articles at all and have them go through AfC. If I recall there was no consensus on this change in the past, but AfC is great for preventing bad articles from being created in mainspace and exists as a less bitely alternative to deletion. Winner 42 Talk to me! 14:42, 11 June 2015 (UTC)

I surveyed article creation in the fifteen minutes before 3 pm this afternoon. Within half an hour a third of them had been deleted. The percentage may be much higher, because after deletion articles no longer appear in the list. So your argument that putting everything through AfC is less bitey doesn't hold water. A lot of new articles are templated, and the creators (or others) then come along and do the necessary fix. Leaving a submission languishing in AfC for months is a sure way to create a backlog. And don't forget that all those AfC and PC reviewers will now be patrolling new pages, so all those backlogs will disappear. 5.150.92.19 (talk) 15:47, 11 June 2015 (UTC)

I'm not sure where you are getting your information. In the past 12 hours only 3 active AfC submissions have been deleted. Two were deleted for copyright infringement and one because it was created by a block evading user. If we look at articles created in mainspace in the same time frame, I see hundreds of deletions under A7 and/or G11 in the deletion log by unconfirmed users. If those unconfirmed users created their articles in AfC space, most if not all of those deletions could have been avoided. Additionally the idea that the AfC backlog goes on for months is misleading. Most articles are dealt with within the first week with difficult submissions finding their way to the backlog. The idea that new page patrol is doing better is inaccurate, it has a 764 day backlog compared to AfC's 4 week backlog. Winner 42 Talk to me! 16:22, 11 June 2015 (UTC)

I think you're comparing apples with pears. Those hundreds of deletions can't be articles by unconfirmed users because unconfirmed editors can't create articles. They must be articles by autoconfirmed editors, which proves my point. Since the work of unconfirmed editors isn't being deleted in AfC that shows that they are the ones who are clued up. So let's give them their head and get rid of AfC. It's win - win all round. 5.150.92.19 (talk) 18:55, 11 June 2015 (UTC)

That is incorrect, you do not require either form of confirmation to create articles. Winner 42 Talk to me! 23:42, 11 June 2015 (UTC)

• Oppose - Just because you can do something doesn't mean you should. Create an account, learn the ropes, then edit. Tarc (talk) 19:18, 11 June 2015 (UTC)

Tarc, how wrong can you be? This very issue is being discussed at the RfA talkpage and your view is a tiny minority. Here's an extract from a survey cited in the discussion:

According to this [4] most of the content comes from IPs.

This quote is revealing:

If Wikipedia is written by occasional contributors, then growing it requires making it easier and more rewarding to contribute occasionally. Instead of trying to squeeze more work out of those who spend their life on Wikipedia, we need to broaden the base of those who contribute just a little bit.

Unfortunately, precisely because such people are only occasional contributors, their opinions aren't heard by the current Wikipedia process. They don't get involved in policy debates, they don't go to meetups, and they don't hang out with Jimbo Wales. And so things that might help them get pushed on the back burner, assuming they're ever proposed.

Out of sight is out of mind, so it's a short hop to thinking these invisible people aren't particularly important. Thus Wales's belief that 500 people wrote half an encyclopedia. Thus his assumption that outsiders contribute mostly vandalism and nonsense. And thus the comments you sometimes hear that making it hard to edit the site might be a good thing.

"I'm not a wiki person who happened to go into encyclopedias," Wales told the crowd at Oxford. "I'm an encyclopedia person who happened to use a wiki." So perhaps his belief that Wikipedia was written in the traditional way isn't surprising. Unfortunately, it is dangerous. If Wikipedia continues down this path of focusing on the encyclopedia at the expense of the wiki, it might end up not being much of either.

Tarc, how wrong can you be? Well I suppose very much so, in any given circumstance. This is not one of them however, as IPs are not people, they are addresses. You under the guise of "5.150.92.19", have no more right to vote than my post office box downtown does. If you wish to participate in all aspects of this project, then make an account, and accumulate a significant number of edits to show that you're actually here for good and not here to push a certain agenda. Thank you for pointing out the RfA discussion, I have weighted in over there as well. Note that the IP who initiated this discussion...who may very well be you Mr. "5.150.92.19"...has been blocked for 6 months for disruption. Curious, that. Tarc (talk) 20:24, 11 June 2015 (UTC)

Show you're actually here for good and not here to push a certain agenda.

So everyone who states their views, and gives reasons, is up to no good?

Exactly right, Tarc. IPs are not people — they are random screeds of numbers with an uncanny ability to type out coherent thoughts as though they were somehow sentient like you or I. They are faceless, nameless entities whose mere presence creates a cognitive dissonance of sorts, in that there is something almost human-like about them. These mysterious beings lurk within the shadows of our community-based project, tainting its sanctity with their identities of integers. They have no business editing in non-IP namespaces, where only us real editors should be participating.

No wonder you're a topic banned editor. 5.150.92.19 (talk) 13:22, 12 June 2015 (UTC)

Winner 42, I just typed "The 2015 Tower Hamlets mayoral election" and a message came back

The page "The 2015 Tower Hamlets mayoral election" does not exist. You can ask for it to be created, but consider checking the search results below to see whether the topic is already covered.

I'd rather be a topic-banned editor than a fully-banned one, which is what you likely are, given the wiki-familiarity and the whiny rancor. This is why IP editors will remain exactly as they are now; barred from participation in some parts of the project and viewed with suspicion and disdain in the rest. So who is this, Russavia? Demiwit? Benjiboy? Tarc (talk) 13:42, 12 June 2015 (UTC)

• Can I vote to enable PC2 here? Cuz I like PC2, and I think it should be enabled. If not, then I guess I don't care that much about this RFC, because it seems like this is mostly just a bit ranting, and I don't want to read it all. I'm involved in enough drama as-is. NinjaRobotPirate (talk) 04:59, 16 June 2015 (UTC)

Courtesy break

There are two proposals being considered:

(1) To re - enable the creation of articles by non - autoconfirmed users per the community consensus which was ignored when the creation power was taken away. PC1 will apply to an article started by a non - autoconfirmed editor until an autoconfirmed editor edits it, when it will automatically come out of PC.

(2) To disable PC, per the original consensus (the only consensus we have ever had on PC) except for the limited use described above. 5.150.92.20 (talk) 19:16, 17 June 2015 (UTC)

Discussion is entering its final week. There have been efforts in the past few days by some high - placed editors in various venues to formalise a second - class status for IP editors. These proposals have been roundly defeated. We have seen that a vast number of articles started by autoconfirmed editors are being deleted. Articles started by IPs will not suffer this fate, since IP editors tend to be knowledgeable in the specific subjects they write about. The discussion so far shows that the community is not opposed to re - enabling IP article creation. From the very beginnings of the project there has been strong community support for tapping this rich lode of expertise, and Wikipedia's problems only began when this resource was switched off and editors' attentions were diverted from editing to nibbling at the backlog on AfC. The switchoff was done suddenly, without either warning or discussion - editors awoke one morning to be presented with a fait accompli. After a month of discussion we now have a clear mandate to restore the status ante quo. 5.150.92.19 (talk) 08:38, 19 June 2015 (UTC)