Wikipedia:Village pump (policy)/Archive 148

Hi all. I invite you to participate an RfC on English variety and date format. Szqecs (talk) 07:27, 8 December 2018 (UTC)

Administrators often impose or suggest editing restrictions on blocked editors, either of their own accord or accepting suggestions from the editors themselves, as "conditions" to accepting an unblock request. We sometimes log these (see Wikipedia:Editing restrictions) as "voluntary" bans or as "unblock conditions" (or sometimes not at all). I think these sorts of unblock conditions are a good use of admin discretion, but I've realized recently that there does not actually seem to be any support for these sorts of ban in the banning policy. According to the policy (see #Authority to ban), bans may be imposed either by community consensus, or by admins acting under authority of the arbitration committee in designated topics (discretionary sanctions). They can also be imposed by Jimbo or the WMF but let's not get into that.

I propose that a bullet be added to this section, specifying that an administrator acting under their own authority may impose a relevant editing restriction (a ban) as a condition to a user being unblocked, if the administrator believes that such a sanction will prevent disruption related to that user's block. This would bring the banning policy in line with the blocking policy (see #Conditional unblock). Ivanvector (^Talk/_Edits) 19:00, 17 November 2018 (UTC)

Support if and only if the same with the agreement of the blocked user wording from WP:CONDUNBLOCK is included. Otherwise, you're giving individual admins the power to unilaterally decree what other editors may and may not do, which is a Really Bad Idea; except in the cases of the most blatant vandalism, it's rare to find any situation in which every admin will agree on what does and doesn't constitute disruption, so what you'd effectively be doing is giving a massive first-mover-advantage incentive for every self-appointed social engineer to impose their personal standards of what constitutes 'disruption' every time a ban appeal comes up. ‑ Iridescent 19:27, 17 November 2018 (UTC)

Just copy the appropriate text from CONDUNBLOCK, which is where this authority comes from. No need to reinvent the wheel. Also, agree with Iri on not giving individual admins the authority to ban without consent or ArbCom authorization. TonyBallioni (talk) 19:41, 17 November 2018 (UTC)

• (edit conflict)Support with Iridescent's qualifier. It's de facto (and not a bad idea) so might as well make it de jure (with Iridescent's restriction to prevent it from becoming a bad idea). This would be useful in separating users who are WP:NOTHERE vs those who just cannot safely handle a particular topic at the moment. Even if this practice did not already exist:
  - If they don't agree to the topic ban then they must not be interested in contributing to the encyclopedia in general but specifically engaging in whatever behavior got them blocked.
  - If they agree to the topic ban and break it, then we have enough WP:ROPE to block them and let God handle their appeals.
  - If they agree to the topic ban and then give up on all activity (as sometimes happens after TBANs), then there's no difference between that and leaving them blocked -- except that we're not "punishing" them.
  - If they agree to the ban and abide by it, they have a chance of becoming productive editors, which should be the primary goal for any interaction with other editors.
  In any case, it is a net gain for the site. Ian.thomson (talk) 19:46, 17 November 2018 (UTC)

• @Ian.thomson, I don't agree with If they don't agree to the topic ban then they must not be interested in contributing to the encyclopedia in general but specifically engaging in whatever behavior got them blocked in the slightest. If they don't agree to the topic ban, they may just feel that its scope is too broad or inappropriate, and may well feel that for good reason; I've seen some truly goofy topic ban proposals in my time, and having a single admin make the call rather than an AN/ANI discussion means the checks and balances of the rest of the community explaining why the proposed topic ban is unworkable won't be there. ‑ Iridescent 19:59, 17 November 2018 (UTC)

@Iridescent: Ok, what about the specification "if they don't agree to a perfectly reasonable topic-ban"...? Like, yeah, if someone is being disruptive at just (clicks random article) Paromitar Ek Din, a proposal to ban them from all articles relating to either India or movies would be extreme, but (depending on the kind of disruption) "movies by Aparna Sen" or "movies starring Rituparna Sengupta" or even just a topic ban relating to that one movie would probably be a good indication whether or not the user is too hyper-focused on that topic to want to be useful elsewhere. Ian.thomson (talk) 20:07, 17 November 2018 (UTC)

Sure, but it's fair to see their side as well, and if they have a reasonable objection to the topic ban we should treat it as such, even if we don't necessarily accept their proposed wording. To take a fictional but eminently plausible hypothetical, imagine editor Foo has spent most of their editing career writing about old cowboy movies, but then got sucked into Trumpian edit-wars and eventually got banned under WP:ARBAPDS. They appeal their ban, and the admin Bar agrees to unblock subject to a topic ban using the standard wording of all pages related to post-1932 politics of the United States and closely related people, broadly construed. Editor Foo complains that they can't accept this, since this definition will include Ronald Reagan and Clint Eastwood, making it impossible to return to their favorite topic of cowboy movies even though their edits there were universally accepted as uncontroversial. In this case admin Bar's initial complaint is completely reasonable since it's using standard Arbcom-mandated wording, but there wouldn't be anything vexatious about editor Foo refusing to accept it. (This kind of thing used to come up all the damn time back when The Troubles was still a hot topic—since virtually every person of consequence in Northern Ireland was linked to the conflict in some way or another, topic bans had the de facto effect of banning editors from anything historical or biographical.) ‑ Iridescent 20:22, 17 November 2018 (UTC)

I can't recall a wording for it (other than WP:COMMONSENSE) but I've been given mixed messages as to whether pages that cover multiple topics are treated as divided territory or the worst possible topic. There's some city that's a sister city to Jerusalem. When an edit war broke out in that article over whether Jerusalem is in Israel or Palestine, I got fussed at for citing the Arbcom DS for the Palestinian/Israeli conflict, even though everyone (except a few WP:SPAs) agreed that locking the page was necessary to stop the edit war (though I still don't understand why I was the first to lock the Two-state solution article!). Still, I've also seen plenty of cases where someone got in trouble for editing part unrelated to a DS of an article that was partly covered by a DS. If the topic ban is being implemented through this and not through discretionary sanctions and the editor has a proven history of improving cowboy movie articles (or whatever), the hypothetical admin should be willing to say "ok, you can still edit the parts of the Eastwood and Reagan articles from before they entered politics, except when they made political statements during their acting careers." (Looking a non-cowboy Arnold Schwarzenegger, acting careers after entering politics might too much of a gray area, though, IMO). Ian.thomson (talk) 20:46, 17 November 2018 (UTC)

• Support with Iridescent's qualifier per everything Iridescent has said in this discussion. Thryduulf (talk) 20:48, 17 November 2018 (UTC)
• Oppose Too big a grant of authority to individual admins. Topic bans should require a community process. --Trovatore (talk) 20:56, 17 November 2018 (UTC)
  • This is already policy. All Ivanvector is suggesting is what amounts to a cross-reference in the banning policy. Opposing this wouldn't stop conditional unblocks. TonyBallioni (talk) 21:46, 17 November 2018 (UTC)
• What Iri and Tony said. ~ Amory (u • t • c) 21:44, 17 November 2018 (UTC)
• This is already policy, no harm cross referencing it at the banning policy as well. If the blocked editor is unwilling to accept the proposed unblock conditions, they have the option of waiting out their block (if not indefinite) or not agreeing, which will result in their appeal being declined, at which time they can request further review (whether indef or time-limited). Seraphimblade ^{Talk to me} 21:50, 17 November 2018 (UTC)
  • Indeed, unblock conditions can result from a negotiation of the details - e.g. tweaks to boundaries, clarifications, etc. (e.g. I recall one user suggesting a slightly different wording to avoid potential confusion between the plain English meaning of a word and the more specific meaning of that word as a term of art in the topic area concerned) and this is a Good Thing as restrictions both 'sides' are happy with are far more likely to be adhered to. Thryduulf (talk) 23:07, 18 November 2018 (UTC)
• Support Iridescent's version, to ensure this does not get out of hand. — AfroThundr ^{(u · t · c)} 05:45, 19 November 2018 (UTC)
• Good points everyone! I think we're all pretty much in agreement with Iridescent. One last sticking point is that bans are meant to be community sanctions, but in this situation we have a ban imposed by an agreement of two editors (the blocked user and the unblocking admin). In my view such a ban should still require a discussion at a community noticeboard to lift the ban, the same as with other bans enacted by the community. That's basically current practice anyway, I'm just thinking about how to update the banning policy to match. Is there any opposition to that? Ivanvector (^Talk/_Edits) 13:23, 19 November 2018 (UTC)
  • @Ivanvector: I assume you mean adding a sentence along the lines of appeals should be made at AN? If so, what about time-limited bans? Thryduulf (talk) 13:43, 19 November 2018 (UTC)

• I'm thinking of adding a line item under "authority to ban" describing this situation, and in that case the appeal method is already in the policy. I guess the line item would need to specify that this sort of ban is to be considered a ban imposed by the community. Reviewing just now, maybe it's better for this to be a separate subsection (e.g. "unblock conditions") like how we have a "bans for repeated block evasion" section. As for time-limited bans, I don't think a distinction needs to be made. I personally don't do time-limited bans, the way I see it if there's consensus for someone to be banned then they need to actively convince the community to unban them in the future, but I do know that time-definite bans are a thing we do. Ivanvector (^Talk/_Edits) 13:52, 19 November 2018 (UTC)

• Support Iridescent's but not community ban lifting - I disagree in thinking that a community agreement should be required to remove the conditional partial bans. If nothing else, it makes no logical sense because of the existence of time-limited bans (as they'd be removed without any involvement of the community along the way so there's no fundamental community link to the bans). I would say the individual is entitled to appeal to either the admin or the community to remove an indef T-ban (et al) but that's their choice. I suppose any admin doing this could say "indef requiring community removal" but that would seem a bit iffy. Nosebagbear (talk) 19:22, 20 November 2018 (UTC)
• Support with Iridescent's qualifier. We should never tolerate a WP:POLICYFORK once one has been identified.  — SMcCandlish ☏ ¢ 😼  12:41, 1 December 2018 (UTC)
• Support. Ivanvector's proposal seems to be a no brainer. I'll trust the community on the wording. - FlightTime (open channel) 13:10, 1 December 2018 (UTC)
• Support' per Iridescent's version. Beyond My Ken (talk) 23:43, 8 December 2018 (UTC)

Just a note, we have the same problem with "However...". But we can't regulate that tightly. FIXIT is the right response. If I see a bunch of sentences all starting with "However," then per wp:however, I remove all the "howevers", and rewrite as needed. That's pretty much all we can do. - wolf 06:55, 9 December 2018 (UTC)

The constitutional start date for gubernatorial terms in Alabama is the Monday after the second Tuesday in January. For 1911, this was January 16. However, the Alabama Supreme Court ruled that, in their reading of the constitution, the current governor holds their office throughout the entire last day, i.e. until midnight. The next governor's term thus begins on Tuesday.

This is a pretty obscure ruling, but it does appear to be in force - a much more recent election's news coverage noted it: [1] In 2011, "Bentley under state law won't officially be governor until just after the stroke of midnight Tuesday morning.".

So, we have the constitution. We have this apparently still-relevant ruling. The problem is, no one seems to know about it. Apart from labeling the governor in 1911 as taking office on Tuesday rather than Monday, almost no sources bump the inauguration date to the Tuesday, always having it on Monday. Which would make sense, since that's what the constitution says, that's when the parties are, that's when the official swearing in ceremonies are... but technically, no matter what they do on Monday, the governor's term does not begin until midnight Tuesday.

So, when we have something that appears to be true - that in Alabama, gubernatorial terms end on Monday and begin on Tuesday - but no sources actually back this up (either because they're unequipped to, assuming that the end and start dates are the same; or, they are unaware of the court ruling), what am I to do? I shouldn't have the governors marked as taking office on Monday because that appears, legally, incorrect. But it would also technically be original research, right? Or at least unsourced? It also seems wrong to only do it for the two governors that I have explicit sourcing on this (1911 and 2011).

Any suggestions? --Golbez (talk) 21:50, 10 December 2018 (UTC)

How do you know the Alabama Supreme Court made this obscure ruling? -- GreenC 22:17, 10 December 2018 (UTC)

[2] specifically page 496. --Golbez (talk) 22:30, 10 December 2018 (UTC)

(edit conflict)Before anyone asks, I'm a Brit and haven't ever visited Alabama. That said, from your description and from the Birmingham News article there appear to be two separate things happening: inauguration day and the start of the gubernatorial term. Why should "sources bump the inauguration date to the Tuesday", the inauguration day appears to be Monday, it is the legal start of the term that is the Tuesday. I think you just need to be careful how you word things; be clear about the disjoint between the events. I'm assuming you are talking about List of Governors of Alabama, so I would suggest one or both of:

• Add "The term of office starts on the day following inauguration." immediately above the table.
• Add an extra column "Inauguration day" just before "Term in office". Possibly just use "Term" for the second heading?

Provided you are clear and reference your sources then this should not fall foul of WP:OR - all IMHO of course! Martin of Sheffield (talk) 22:31, 10 December 2018 (UTC)

"Inauguration" is just ceremonial, especially in this case. And this would double the number of sources I need, the problem isn't Inauguration being separate, the problem is lack of sourcing for the legal term start. I don't mind having one term end one day and the next term begin the next - that's how it's done in New York. The problem is, 99% of sources don't realize this, and have everyone's terms start and end on Monday. Literally the only sources I've found otherwise are: That news link; the supreme court judgment; a transcription of some newsletter from 1943; and the fact that Emmet O'Neal is always noted in sources as having taken office on Tuesday, not Monday. Yet, it does appear, legally, to be true - it's just that the people who write the sources don't know about it. --Golbez (talk) 22:37, 10 December 2018 (UTC)

As I've always understood it. Among the 50 states, it's only the New York governors & lieutenant governors, who begin their terms of office at midnight. GoodDay (talk) 22:41, 10 December 2018 (UTC)

And, apparently, Alabama. The difference is, New York makes a big deal of it (it being a new year's thing doesn't hurt), whereas Alabama seems to have forgotten pretty quickly about it, except for a couple reporters. --Golbez (talk) 22:43, 10 December 2018 (UTC)

Here's another 'strange' one, North Carolina governor Roy Cooper's term began (private swearing-in) on January 1, 2017, but his inauguration (public swearing-in) was on January 7, 2017. GoodDay (talk) 22:49, 10 December 2018 (UTC)

• Am I missing something? You actually DO have a few sources... You just don’t have a lot of sources. I am not sure what the problem is. Cite the sources you have. Blueboar (talk) 23:02, 10 December 2018 (UTC)
  • I have sources for two specific governors. The thing is, this almost certainly applies to all governors since 1911 - but no sources know that, they all have the Monday. So if I put in what I believe to be the correct date - the Tuesday - doesn't that technically count as original research? --Golbez (talk) 23:25, 10 December 2018 (UTC)

  If you're planning on changing all those 'taking office' dates for post-1911 Alabama governors & lieutenant governors? Such a change would include the bios articles of those individuals. A huge undertaking, which would likely be difficult to maintain across so many articles. You may want to start an Rfc on this matter, at a place you think best. GoodDay (talk) 23:29, 10 December 2018 (UTC)

• Given the pg.496 source and two other sources for 1911 and 2011. The Constitution has been amended and there is verifiable evidence per WP:V. Worse case include two dates with a "Note" explaining why the second date. Although unclear how encyclopedic it is, except for 1911 and 2011 since they were reported. -- GreenC 00:06, 11 December 2018 (UTC)
• Yes, we do have sources (at least three, two primary government documents and one secondary news source), and what's clearly going on is what was Martin said: "two separate things happening: inauguration day and the start of the gubernatorial term", and which Golbez themself pointed out in different words later. Inauguration is a ceremony; being able to issue gubernatorial orders and have them enforced is a legal matter. It's a bit like the "when does a century or millennium really start?" confusion (caused by lack of a year 0). People who paid attention knew that 2000 was not the actual most recent millennial year.  :-)  — SMcCandlish ☏ ¢ 😼  01:54, 12 December 2018 (UTC)

As discussed in Template talk:Infobox website#AlexaRank, currently some Wikipedia use "decrease" to indicate improvement in rank. For instance, If a website was previously ranked #10 in certain ranking, and it now become the #1 site in the world, then editors would put a symbol next to the rank to indicate its ranking have been "decreased" from #10 to #1. However to me it seems like the interpretation doesn't make sense, as the ranking of the website was actually increased from the #10 to #1. Wouldn't it be better to use the symbol to show the website gained places in ranking? C933103 (talk) 07:26, 13 November 2018 (UTC)

Why not simply use “rise” and “fall”? Blueboar (talk) 12:27, 13 November 2018 (UTC)

The OP is saying that it's counter-intuitive to indicate an improvement with a "down" arrow. I would tend to agree. Not sure whether this qualifies as forum shopping, maybe a discussion notice here would have been better? ―Mandruss ☎ 13:12, 13 November 2018 (UTC)

Strongly concur with C933103 and Mandruss. Furthermore, this is against MOS:ICONS. We never use icons in ways that can be misleading to readers.  — SMcCandlish ☏ ¢ 😼  14:20, 14 November 2018 (UTC)

Yeah it would probably be better to link the discussion back from the original talk page so that the discussion would be linked to anyone who are interested. The lack of people to discuss the matter (as well as actually talking about what can be done) on the template talk page was the reason for me to start this section to talk about this issue here. C933103 (talk) 16:35, 20 November 2018 (UTC)

"High rank" means a small number, and "top rank" means the first in rank. --NaBUru38 (talk) 20:31, 16 November 2018 (UTC)

• I recall having a discussion about this before;
  Wikipedia:Help desk/Archives/2013 July 14#Infobox Symbols & Template talk:IncreaseNegative#Guidance.
  There has been confusion in the past about the direction and color of indicators, as well as increase/decrease in numeric value =/≠ decrease/increase in rankings.

Standard usage seems simple enough;

- eg: increase in net worth

- eg: decrease in net worth

- eg: decrease in traffic fatalities

- eg: increase in traffic fatalities

More than 5 years later and there still seems to be problems however. It seems that rankings, such as Alexa, were an issue then and still are now. In most rankings, a numerical decrease is considered an improvement, or an 'increase' in the rankings. Going from #10 to #4, for example is considered an improvement, so a green indicator, or arrow, is used. As some see it as numerical decrease, they will use . But since it's widely considered an climb or increase in ranking, will be used. This can lead to confusion. The same can be found with other types of rankings, say "List of unsafest cars". An change from #8 to #3, is considered a downgrade or decline. A red arrow is used, and while it is again a numerical decrease, leading some to use , it's considered a climb in the ranks, so will be be used by many others. Another example that may cause problems is golf scores. Whereas in most other sports, the higher the score, the better, the opposite is true in golf. Anyway, short answer; I agree with the OP. (jmho) - wolf 13:51, 3 December 2018 (UTC)

• Agree with C933103 and Thewolfchild, etc. ...While you could kinda see "#10 to #1" as a numerical decrease - on these rankings "it's widely considered an climb or increase in ranking, [so] should be used". Paintspot Infez (talk) 17:32, 11 December 2018 (UTC)

How can we gather a general consensus about it for the entire English Wikipedia about all these different types of ranks? I am not really familiar with all these procedures... C933103 (talk) 16:49, 15 December 2018 (UTC)

Turns out, in order to suppress the redirect on a file move, you must also be a page mover. Page movers can't move files, and file movers can't move files without leaving a redirect. This doesn't seem terribly intentional, especially given that we haven't accounted for it at WP:FNC. (Actually, this is accounted for at WP:PMRC apparently.) So either:

1. We should amend guidance at FNC, and do nothing.
2. We should add the ability to suppress redirects to file movers.
3. We should revoke the ability of page movers to suppress redirects of files.

Page mover don't really have all that much to do with file mover, so I don't really see a compelling reason they should have such a serious interaction. They're governed by a totally different set of policies. Thoughts? GMG^talk 23:23, 6 December 2018 (UTC)

There's 403 file movers and 254 page movers. Seems page moving is the more exclusive right. But, take away the overlap (editors with both rights) and how many page movers are there that aren't file movers? How big a deal would it be to give them file mover? If an editor can be trusted with one, why not the other? Given the situation you've just outlined, it seems that perhaps the two should be bundled anyway. JMHO - wolf 23:49, 6 December 2018 (UTC) (non-file mover/non-page mover)

Personally I think that option 1 or 2 would be the best ones. Option 3 will only prevent page movers from cleaning up page move vandalism and thus make them no different than any other non-admin editor when dealing with that situation. Sakura Cartelet^Talk 23:56, 6 December 2018 (UTC)

I'm a page mover, but not a file mover. Aside from a spree when I found and uploaded some missing music covers, I edit files so infrequently that it didn't strike me that I couldn't move them. In my opinion, bundle the two rights. Users who can be trusted with page moves beyond thresholds and subsequent redirect suppression should be trustworthy enough to move files as well. Plus, in this day and age when file vandalism seems to be growing (yes, I know much of it is linked from Commons), it cannot hurt to be able to rename local files. Say a sysop-protected noteworthy page has a redlinked file somewhere in the source (say, an infobox), and a vandal decides to upload something to get it to display there. Being able to drag the vandal file elsewhere before a sysop comes along could be useful in preventing this type of vandalism from displaying. Home Lander (talk) 04:08, 7 December 2018 (UTC)

I'd endorse merging the two rights and renaming the permission 'content mover' or similar (ideally as the start of an effort to streamline some of our permissions) but in the absence of that, I'd endorse the addition of the suppressredirect feature to the file mover group. Nick (talk) 08:53, 7 December 2018 (UTC)

Deletion of redirects is a bad thing to be doing, particularly in the case of files. External sites link to our pages, often to provide attribution required under copyright licences, and this attribution becomes lost when a page is deleted after a move. Deletion should have been restricted to abusive names. Thincat (talk) 09:35, 7 December 2018 (UTC)

I mean, in the case of moving a file that mirrors another file on Commons, getting rid of the redirect is the whole point, and it's generally preferable to move local files only used by one project, rather than to move global files potentially used by many projects. At least in theory, all non-free local files should eventually get replaced by free alternatives, the vast majority of free local files should be moved to Commons, and if they're using non-free content from Wikipedia, then they're using the same fair use rationale that we are, and so attribution to us doesn't matter anyway. GMG^talk 11:15, 7 December 2018 (UTC)

• Meh, anyone who is active in both these areas should have no issue having a request approved at WP:PERM. — xaosflux ^Talk 17:12, 7 December 2018 (UTC)

Question is, how many people are active in both these areas? I presume "I am a file mover and would like to suppress redirects on moves" would not be a sufficient reason for granting the PM flag. So I'm not sure why we should restrict a substantial bit of functionality and make those who don't qualify go and hat collect their way to a flag they may not want or use, in order to get a functionality on a tool they do.

I'm not sure there's really any other example of an interaction like this between unbundled rights. Although I have been trying to think of one. Best I can come up with is the god awful mess between extended uploader and file reviewer on Commons, where EU gives you the technical ability to upload and "review/not-review" files you can't review. GMG^talk 17:33, 7 December 2018 (UTC)

Should have realizes how easy this would have been to Ctrl-F. Only 67 users are both file movers and page movers. GMG^talk 18:43, 7 December 2018 (UTC)

Under what circumstances does someone need to move a file without leaving a redirect? Is the a common problem? Natureium (talk) 17:39, 7 December 2018 (UTC)

Any WP:FNC#9 move where the file on Commons doesn't itself meet c:COM:MOVE. (Instances where the file on Commons met COM:MOVE would be happenstance and extremely rare. Normally the name is duplicated because they are both reasonable policy-compliant file names.) GMG^talk 17:44, 7 December 2018 (UTC)

Another common case where you want to do this is where the file name mis-identifies the subject. In this case you want to rename without a redirect. Hawkeye7 (discuss) 18:45, 7 December 2018 (UTC)

• @GreenMeansGo: This issue is simple but I think you complicated it by basing it on incidental interaction of two completely separate permissions. Let me simplify it: You found that the file mover group doesn't have (suppressredirect) and in some cases it's needed in moving file process. Then simply make a proposal to add the (suppressredirect) permission to the file mover group. With simple consensus, the change can be made within a short time. Cf. Recent addition of tboverride to page movers. But instead, you relied on incidental interaction to imply that page movers who are also file movers have unfair advantage over other file movers who are not page movers, because the former can suppress redirect in File namespace while the later cannot. While this superficially looks true, it's factually not true. The filemover+pagemover user is able to do that because they followed two separate processes (by requesting each permission independently) and then 'accumulates' right which allow them to move file and suppress redirects. –Ammarpad (talk) 20:19, 7 December 2018 (UTC)

Well Ammarpad, you'll never hear me claim that I am not a functioning computer illiterate. Other than that, not really that it's "unfair", so much as it just doesn't make any sense. More so, since only 67 out of 403 file movers have page mover, I presume most don't even realize it's a thing. Only reason I noticed it is because I'm used to moving files on Commons where non-admins cannot suppress redirects, and I went "that's a pretty looking button I'm not used to seeing". GMG^talk 20:34, 7 December 2018 (UTC)

I agree it makes sense and I am not really blaming you. But just to clarify things. For instance, among the 3 options you proposed above, the last one one reads: 3. "We should revoke the ability of page movers to suppress redirects of files.". Now, what that shows? It means a user who have file mover and also page mover rights, they gained an "unfair" advantage over file mover who is not a page mover. And now here is a proposal to "correct" that by removing suppress direct(file) from them so as to "level" users who are only file movers and any one who gained both two permissions. (Please explain what that point means if I am not correct). That's why I told you it's incidental and I believe if you're to studiously compare each permission against one another you'll find more than this. Compare sysop and bureaucrat groups for example. A bureaucrat cannot grant IP block exemption but they can remove it. A sysop can grant it and also remove it. But if you're both admin and bureaucrat (what we normally have) then the rights will accumulate which now gives our bureaucrats ability to both add IPBE and remove it. But the abilities are coming for separate reasons. But I know this is just technical quibble, many users may not even know which permission allow them do this or that. So as I said, the simple solution is to make a proposal to add (suppressredirect) permission to the file mover group, then you give reasons why, but don't say because page movers have it and it's giving them power to suppress file redirects when they also have page move permission. They have that because they followed two processes, and any filemover-only can do so, or a proposal can gain consensus to add the right to the group entirely. –Ammarpad (talk) 21:13, 7 December 2018 (UTC)

Honestly, when I noted that it wasn't documented at WP:FNC, my thought was that it may have been an unintended side effect of the both flags, and that there may not have been an explicit consensus to allow suppression of file redirects in the first place. I see now that I am wrong in that regard, and it was documented (counter-intuitively) at WP:PMRC. GMG^talk 21:18, 7 December 2018 (UTC)

• Option1 sounds to be the way to go. File movers should be able to get the page mover right to suppress redirects on request. However they should prove that they know the policy and how its use can cause copyright infringement, and therefore how to avoid this problem. Some comments above sugggest that some people do not understand the requirement of licensing. Graeme Bartlett (talk) 08:01, 9 December 2018 (UTC)
• "Option 4": Page-mover is the far more dangerous bit and harder to get approved for. Any page-mover will qualify for file-mover, but not vice-versa. So, make page-mover include file-mover. Also do Option 1, and instruct file-movers who are not page-movers that they won't be able to suppress redirs (why would they normally need to?), but if there's a case where it needs to happen (e.g. because the image should be kept but its filename is a blatant policy violation), they should have a PM or an admin do the file move. That said, I have no objection to Option 2 if it's possible to limit FMs' redirect suppression to the File namespace; if it's not, then it would make FM and PM equivalent, and we don't want that.  — SMcCandlish ☏ ¢ 😼  06:26, 10 December 2018 (UTC)
• Option 4 as suggested by SMcCandlish - I agree as regards comparable authority/risks of roles. Nosebagbear (talk) 20:07, 10 December 2018 (UTC)

  @SMcCandlish and Nosebagbear: Okay, Option 4 is not in the original proposal, if I understand you both want the single (movefile) permission to be added to extended mover group. If that's the case may be there's need to make a separate proposal with clear details. There's request to make (movefile) available to all autoconfirmed users just like how move is but the bug stalled due to lack of interest. Limiting redirect suppression to the File namespace probably needs to be written from the scratch, as it doesn't seem any wiki is using redirect suppression which is restricted in one namespace.–Ammarpad (talk) 06:26, 11 December 2018 (UTC)

  Nah, people add missing options to proposals all the time, and they're often the compromises that end up gaining consensus. WP:NOT#BUREAUCRACY, and all 'at.  — SMcCandlish ☏ ¢ 😼  09:58, 11 December 2018 (UTC)

  Okay, that's fair. –Ammarpad (talk)15:28, 11 December 2018 (UTC)

• Support Option 1, but Option 4 is ok too. Really, if you need to do both, ask for both perms. It shouldn't be a problem if you have a legitimate need. Natureium (talk) 15:37, 11 December 2018 (UTC)
• I'm not sure I agree that any page mover should qualify for file mover, as evidenced by the fact that less than a quarter of page movers are also file movers. There is simply no requirement for PM that a user have any experience at all working in file space, and file space is among the least-worked-on name spaces.

On the technical side, if I understand correctly, we cannot easily give FMs limited technical access to suppress only moves in file space, but if we add (suppressredirect) to FM, then that would give them the ability to suppress all redirects, which isn't really desirable either.

I mean, it might be a compromise to go with "Option 4.1" - add a policy exception that requesting PM for the purpose of suppressing redirects via FM is a legitimate need for the tools, and sufficient to grant them. GMG^talk 15:10, 12 December 2018 (UTC)

That would be effectively merging the PM bit to FM, at FM's lower threshold for editor cluefulness, responsibility, and need.  — SMcCandlish ☏ ¢ 😼  01:42, 13 December 2018 (UTC)

@SMcCandlish: What I was implying is that if it was technically feasible to incorporate the suppression of redirects into file mover, that they should only have the ability to suppress redirects in file space. Otherwise yes, it would largely be a merger of the two roles. While page movers also have the technical ability to override the title blacklist and automatically move sub-pages, to be honest, I've had PM for two and a half years, and I don't know that I've ever actually used either of these features. GMG^talk 14:54, 18 December 2018 (UTC)

• Option 4, with the caveat that some sort of mass message go out to page movers who were not file movers reminding them that file moves must generally meet one of the 9 criteria at WP:FMV/W, that one needs to check for conflicts with Commons file names, and that all uses of the old file name must be updated. (Disclaimer: as a Page Mover who is not a File Mover, I admit a small bit of bias on this issue) --Ahecht (TALK
  PAGE) 15:01, 13 December 2018 (UTC)

I think having a screenshot to demonstrate how an application looks but essentially rendering it at an atrocious resolution is basically pointless. It's just a blurred image as far as a demonstration is concerned. I think we should lift the NFCC criteria from at least this particular case. --QEDK (後 ☕ 桜) 17:10, 15 December 2018 (UTC)

@QEDK: There is nothing to lift, is there? WP:NFCC just says use the smallest resolution possible, not a specific. If you want to stop the bot from resizing, tag the image with {{Non-free no reduce}}. Regards SoWhy 15:26, 17 December 2018 (UTC)

@SoWhy: DatBot reduces the quality as well as ensures there is no version to revert to, this means the only way is to upload a new version, essentially enforcing this, instead of it being a guideline. --QEDK (後 ☕ 桜) 16:35, 17 December 2018 (UTC)

You can either request a WP:REFUND (ask an admin to revert the removal of the larger image) or reupload the image at larger size, then tag with the non-free no reduce tag. Do keep in mind there has to be good justificaton for the larger resolution (greater than 0.1 MP). If we're only using the image of the application to help identify how the application looks as part of the infobox or top of the article, it doesn't need to be pixel-perfect clear. --Masem (t) 16:45, 17 December 2018 (UTC)

@QEDK, have you any examples of an image tagged as {{Non-free no reduce}} which the bot is still reducing? If so, this sounds like a malfunctioning bot issue rather than deliberate enforcement. ‑ Iridescent 16:47, 17 December 2018 (UTC)

@Iridescent: I'm not sure if it did have the tag. @Masem: I'm okay with reducing the size insofar that the details of the image are visible, but if the resolution is reduced to an extent that it's essentially a tiny blurred picture, I don't think there's a value to adding the screenshot at all. What I was asking through this thread is that the screenshots be excluded from the NFCC criterion of reducing its size, since it basically takes away the entire point of having a screenshot in the first place. --QEDK (後 ☕ 桜) 17:50, 17 December 2018 (UTC)

NFC only requires minimal use. The bulk of non-free images on WP are fine with a resolution that is less than 0.1 megapixels, and the bots that tag and reduce those are working on that principle. But we don't require all non-free images to be that small, and allow for larger versions as long as you have reasonable justifications for why the larger resolution is needed. You aren't going to be able to justify a 1080p full size screencap of WordPad, for example. The only problem here is that the bots will target any image > 0.1MP that does not have the above template on it; the bots are indifferent to the type/use of the work. --Masem (t) 18:04, 17 December 2018 (UTC)

NFCC does require minimal use, my point is it's not that we are using the UI for any other purpose other than demonstration, so it's still basically minimal use. What's required is a consensus to not have 200x300 screencaps with faded bits of green or blue act as a "demonstration". --QEDK (後 ☕ 桜) 18:28, 17 December 2018 (UTC)

That's not my point. Ignoring the function of the bots, if you upload a fairly large screenshot of a program and include in its rationale that it is larger than 0.1MP to be able to identify some of the discussed user elements/etc. within the article, that's fine, that meets with NFCC. The bots only come into play as they work invariant to what the type of image is (they aren't scanning the categories for example). If its over 0.1MP, they will tag and later scale down, because for 99% of the images on WP, this smaller size is fine. The bots are enforcing NFC without the wisdom of humans to recognize when it is a problem and hence why the "non-free no reduce" tag was made to allow humans to block the bot's automatic actions. But as for saying the whole class of screenshots should be except, that's just not true, because, again, a 1080p image of WordPad is excessive, so it doesn't make sense to tell the bots in general to skip over screenshots like this. --Masem (t) 18:35, 17 December 2018 (UTC)

An example of what a screenshot under NFCC looks like I'm not talking about an one-off example like WordPad in 1080p first of all. My reasoning is fairly simple, if screenshots are to be reduced in size, the least we can do is to have it in a resolution where the UI elements are distinguishable. It's not excessive to want a picture to be legible, I believe. --QEDK (後 ☕ 桜) 06:17, 19 December 2018 (UTC)

• Lots of our WP:NFCC is foundation-level policy, and not necessarily open to change by local Wikipedia. Some of the policy is locally enacted, but are we sure this is? That is, is this the kind of thing there is no point in discussing, because the lawyers for the Foundation have already set this where it is to be set, and that we are unlikely to be able to change? --Jayron32 17:59, 17 December 2018 (UTC)

Just to clarify, using a screenshot (even at its best quality) to simply demonstarte its interface is still fair-use. Secondly, WMF policy is to have a proper EDP (Exemption Doctrine Policy) and it has legal consideration, but is still changeable depending on community consensus, especially since it does not break EDP guidelines to do so. --QEDK (後 ☕ 桜) 18:28, 17 December 2018 (UTC)

Why we should be using data from Wikidata (and in particular, Listeria) more; see Magnus' blog post: The Hand-editor’s Tale. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:20, 19 December 2018 (UTC)

Has anything changed about how Wikidata operates since the last time this was asked about? If not, then I would still oppose. For all the reasons outlined many times before. Wikidata’s policies simply do not match our own. Blueboar (talk) 19:52, 19 December 2018 (UTC)

Oh good! Are we going to have an RFC to reduce/eliminate use of Wikidata? I'm on board for that. Alsee (talk) 21:35, 19 December 2018 (UTC)

Shouldn't we just remove that entire list ? I mean it's not as if the quality of it is any higher being maintained here locally. Also it sort of goes against WP:DIRECTORY and WP:SALAT doesn't it ? —TheDJ (talk • contribs) 21:56, 19 December 2018 (UTC)

• Please read the top of this page. The policy section is for discussing proposed policies and guidelines, or changes to existing policies etc. It is not for chitchat about or promotion of other projects. What is the policy or guideline you wish to discuss? Only in death does duty end (talk) 22:28, 19 December 2018 (UTC)

Is there any support for creating an A7 like criterion for the speedy deletion of drafts such as Draft:Yara's club,Draft:Computub,Draft:Rapper Salh,Draft:Robert W. Forrest ? — fr ⁺ 10:55, 19 December 2018 (UTC)

Short answer: no. Last discussion about that on WT:CSD was in July 2018 iirc. Regards SoWhy 11:08, 19 December 2018 (UTC)

I've tagged the Computub page as G6 ("Housekeeping"). Note also that G13 ("Page in draft namespace or userspace AfC submission, stale by over 6 months") can be applied if drafts are old enough. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:25, 19 December 2018 (UTC)

G6 is incorrect in these cases. The community has explicitly created rules when to delete stale drafts (in G13) and G6 should not be used to circumvent these rules just because one or two editors feel like it. Regards SoWhy 09:08, 20 December 2018 (UTC)

Are there any guidelines for when to use succession boxes, or more pressingly, when to not use succession boxes? As an example, Sam Rayburn has 10 succession boxes and George H. W. Bush has 16. I can't find any policy or guideline that can justify removing them, no matter how trivial. The relevant wikiproject (Wikipedia:WikiProject Succession Box Standardization) is largely dormant, and the few remaining editors are unlikely to support measures to limit succession boxes, no matter how reasonable. Are we destined for a massive pile of cruft? Is there any end to this webring-inspired madness? power~enwiki (π, ν) 03:27, 30 November 2018 (UTC)

I would support the abolishment of succession boxes. The infoboxes can handle such political office tenure information, as can the Info templates. GoodDay (talk) 03:31, 30 November 2018 (UTC)

Stuff like oldest president, state of Union addresses, is just too much trivia. GoodDay (talk) 03:34, 30 November 2018 (UTC)

• I don't think doing away with succession boxes is the solution, and we really don't need to start another infobox war. I wonder if, for some of the larger pages, a collapsible succession box can be used instead. The {{s-start}} template can be replaced with {{s-start-collapsible}}. Would that help resolve the issue? Bradv🍁 03:35, 30 November 2018 (UTC)
• The same issue exists with navboxes. It gets unwiedly when any and every succession sequence or list gets plopped down under ELs. I'd argue that if the position, award, etc. would not be expected to be mentioned in the leads of most bios, it does not warrant a succession/navbox.—Bagumba (talk) 03:48, 30 November 2018 (UTC)
• " I can't find any policy or guideline that can justify removing them, no matter how trivial." There isn't a Wikipedia policy that articles shouldn't be shitty? If something makes an article shitty, then take it out. The policy that justifies the removal of shitty things from articles is WP:BOLD, which IIRC, can be summarized as "If something is shitty, make it less shitty. Please." You don't need permission to make things better. --Jayron32 13:09, 30 November 2018 (UTC)

  @Jayron32: Re a single case removal, I assume the OP seeks policy basis to win consensus in the inevitable BRD discussion; otherwise the BOLD edit would be a waste of their time. Re widespread removals of widely-used and long-standing content without prior community consensus, the opinion that you were making things less shitty will be a weak defense in a disruptive editing complaint. But feel free to prove me wrong, go forth and make things less shitty yourself. Show us how it's done. ―Mandruss ☎ 23:02, 30 November 2018 (UTC)

• Succession boxes... do people actually use these things? Do they even look at them? I never saw a need for them, they just seem to be needless clutter. - wolf 18:39, 30 November 2018 (UTC)
  • (1) yes. (2) yes. (3) Agreed if excessive. The two examples shown look to me to be excessive, and that for Bush is so well hidden that it serves no useful purpose. Consider though George VI where it helps clarify the "Emperor of India" and "Head of the Commonwealth". Even there though, I'm not so sure about the Masons and certainly the ATC and the Olympics could go. Martin of Sheffield (talk) 19:00, 30 November 2018 (UTC)
    • I've often found succession boxes to be an enjoyable and informative way to navigate the Wikipedia. Hawkeye7 (discuss) 00:54, 2 December 2018 (UTC)

  They are useful in some cases. For example, I have been known to use them when navigating a chronological list of things, like if I was working my way through a band's discography, it helps me to work through the list in order fairly easily, without having to flip back to the discography article itself. HOWEVER, some restraint needs to be shown for trivia sake. I mean, for George H. W. Bush, having a succession box for presidents of the United States seems like a reasonable navigation aide; perhaps someone is reading through the list in order, to learn something about the evolution of the office. I get that. But my goodness, there's an entry there for "Oldest living Vice President of the United States". That's not even remotely useful, and just clutters up the article. We have to draw the line somewhere. --Jayron32 19:01, 30 November 2018 (UTC)

  • Generally they're useful but "Chair of the Group of Seven", "Response to the State of the Union address" and "Republican nominee for U.S. Senator from Texas (Class 1)" probably aren't. There's a line to be drawn between excluding cruft and acknowledging that some people have done a lot of stuff. I think the guiding policy here is WP:COMMONSENSE Cabayi (talk) 19:17, 30 November 2018 (UTC)
    • If everyone had commonsense, we wouldn't be having this discussion. We probably need some hard limit, or guidance for what sorts of things we want, like "No more than 3 boxes per article" or "Highest office held only" or something like that. --Jayron32 19:19, 30 November 2018 (UTC)
    • If only we could persuade people not to do more than 3 significant things in their lives... ;-) Cabayi (talk) 19:25, 30 November 2018 (UTC)
      • Significance is only relative. We can simply narrow it down to the three most significant things. --Jayron32 19:49, 30 November 2018 (UTC)
        • I've always thought the succession boxes biggest usefulness was for following the sequence of office holders. Under your proposal the chain breaks anytime an officeholder has held 3 more significant positions. For example John Major was Prime Minister, Chancellor, & Foreign Secretary - so his constituency would have a gap in its succession of MPs between David Renton & Jonathan Djanogly?? Cabayi (talk) 20:02, 30 November 2018 (UTC)
          • Fair enough, a hard limit of 3 is probably not the best implementation, but we also want to stop someone from adding "President of Washington High School Chess Club" into these, which is what is happening. Having flexible standards appropriate to the article in question is not the same as having no standards, and there needs to be some reasonable way we can keep useful succession boxes and eliminate the crap ones. And to be more specific than "don't use crap succession boxes". --Jayron32 18:51, 6 December 2018 (UTC)

            I have to completely agree witt that.  — SMcCandlish ☏ ¢ 😼  02:05, 12 December 2018 (UTC)

• I'd personally get rid of them. The vast majority I see duplicate information in the navigation templates directly below. Number 57 19:40, 30 November 2018 (UTC)

@RainbowSilver2ndBackup: has been adding Olympics material to the succession boxes of world leaders, concerning opening/closing ceremonies. IMHO, this is going to clog up things more. GoodDay (talk) 19:46, 30 November 2018 (UTC)

• I'd support getting rid of them altogether. It seems that this is an outdated style still left in the system, which is better handled with either infoboxes, nav templates or in prose. --Gonnym (talk) 20:10, 30 November 2018 (UTC)

  Agreed, succession boxes have gotta go. GoodDay (talk) 20:12, 30 November 2018 (UTC)

• I have been using succession boxes from day one and honestly hate it when I find nobility, royalty, and politician pages without them. Infoboxes often only have a person's highest or most prominent title but not lesser titles that may be mentioned in the article, but not in any easy-to-see way. Also, article-only mentions for lesser titles often don't mention predecessors or successors, and there is sometimes no organic way to do so. For this reason alone, I think they should stay. As a historian, succession boxes can be much more helpful than navboxes, too. Not all noble titles have navboxes and even the ones that do can often appear very messy if there are a lot of people in them. I prefer the easy flow of a succession box to the often messy, incomplete, and less informative nature of a navbox. With all that said, I think they have become rather overused and they are also often used for non-successive items, which obviously is an unnecessary use. Many of the examples above prove that they have been misused and need some course-correction, but I don't think we should throw the baby out with the bath water. They serve a good and useful purpose, and their placement at the bottom of the page means that for many articles users do not have to scroll up to the top in order to navigate to the next item in the sequence (or the previous). I know I will continue to use them regularly and continue to add them to aristocratic articles when I make them, even if they have a navbox, because they do serve a useful purpose. – Whaleyland (Talk • Contributions) 21:57, 30 November 2018 (UTC)

  We need an Rfc on this matter. At the very least, these succession boxes need restrictions on their content. GoodDay (talk) 22:02, 30 November 2018 (UTC)

• I think succession boxes should only be used when we are talking a unique position that only one thing can hold at a time. So an elected position like the US president is ripe. On the other hand, Best Picture of the Academy Awards doesn't make sense, since the previous year's Best Picture doesn't lose that status; that's where a Navbox is better suited. --Masem (t) 23:19, 30 November 2018 (UTC)
• I also think they've been surpassed by infoboxes in most cases (and can be in all of them, except articles were a local consensus has staunchly resisted an infobox, which might call for a vestigial, lingering use of succession boxes – we don't want to lose the navigation entirely, just usually move it out of a clunky, ugly, early-2000s template). I note that succession boxes have already been deprecated for various purposes, like singles and album chart "successions" at song and album articles (and were deprecated and removed by RfCs, not by some rando going on a deletion spree). But, yes, to get at this more broadly, it would need to be an RfC, and this is surely the venue for it, though it should also be on WP:CENT because it would affect at least tens of thousands of articles.  — SMcCandlish ☏ ¢ 😼  13:17, 1 December 2018 (UTC)

• Oppose, but with caveats. The project is relatively inactive, because succession boxes have been fairly stable for years and there hasn't been any great need to change their format. The idea that they are redundant because of infoboxes is terribly misguided. This was discussed long ago, and the problem with that is that it either *increases* the visual clutter by moving it towards the top of the article, or will re-ignite the infobox wars by generating thousands of little squabbles over which offices are worthy to be placed in the infobox, or why the infobox needs an exception to whatever arbitrary universal guideline gets laid down for it. (Or to put it another way, if there's a comprehensive succession box out of the way at the bottom of an article, there's much less of a valid argument for trying to jam a bunch of trivialities into the infobox.) If we're looking to reduce clutter in that location, I'd argue that we should be trying to trim down navboxes instead. Looking at William de Bromley, for instance, the succession box links out to three thing for each office; the office he held, his immediate predecessor, and his immediate successor, all of which are likely to be relevant to the article subject. It's not at all clear why he should be linked to fifty-some other Deans of St Patrick's Cathedral, including Jonathan Swift, with whom he's never likely to be associated. His article is also an example of "proselist". (Really, in a sense, the article hasn't been written; what we're told about him is just his presence of various lists of office-holders.) Dissolving succession boxes is likely to return a lot of this proselist to articles; and for someone wanting to review an individual's political career, it's easier to look over a large succession box than to either read proselist or pick out appointments here and there throughout the prose of a well-written article. In short, they are less obtrusive than trying to put their information in infoboxes, more easily comprehended in this form than by dispersing records of office held throughout prose, and more focused and relevant than navboxes.

That said, I'm strongly in favor of restricting their uses to something closer to the original intent: tracing the succession of individual office-holders to an office that is more or less continuous. Cabayi and Masem make good arguments here. I think Masem's formulation is an excellent one, and I agree that a lot of the "unofficial" offices (things like Father of the House of Commons), or United Kingdom precedence (where being immediately adjacent to someone else isn't the usual point of comparison) aren't really worth tracking in these succession boxes. I've been leaving these along because I thought people wanted them (even through I don't find them useful); if that may not be the consensus, I'm happy to participate in RfCs removing elements like those from succession boxes, and I'd encourage doing so as a means of paring them down.

"Clunky, ugly, early-2000s template" isn't really an actionable aesthetic critique, but the succession boxes do have a lot of whitespace and full-sized text. I think all of us would be grateful for any suggestions and CSS examples that would make them more attractive. Choess (talk) 17:24, 1 December 2018 (UTC)

• I would also endorse deprecating or restricting succession boxes. Most of those in the articles listed are duplicated in the infobox or text, are accessible in the relevant article to those interested, or simply aren't that important (like the order of precedence for current US officeholders - pointless and needs frequent updates). On the other hand, are the successor and predecessor always necessary in the infobox? That can get cluttered and putting them at the bottom may be better if we discourage them at the top. Reywas92^Talk 00:57, 4 December 2018 (UTC)
• I say get rif of succession boxes and replace them with template navboxes. Far more useful. GiantSnowman 19:14, 9 December 2018 (UTC)
• I support the use of succession boxes, especially when they give some idea of context, in addition to illustrating a line of continuity. An example of this came to my attention with a recent removal [[3]] at Rosa Parks. In that case, Ms. Parks was listed in "Succession of people who lay in state at The Capitol Rotunda." In this case she was preceded by Ronald Reagan and succeeded by Gerald R. Ford. A singular honor for a civilian at any rate... The now missing succession box provided that context. I am not sure why the editor who removed it was so entrenched in their position, but I was not willing to argue about it. Hamster Sandwich (talk) 02:24, 12 December 2018 (UTC)
• Oppose per Choess, above. I, too, not only appreciate presentation of this info discretely in succession boxes, but also use them a lot to quickly locate successors to an office prior to or after the individual whose page I'm on. If their use is reduced it should not be for offices that have a statutory or well-known traditional period of incumbency: "following" and "succeeding" are not synonyms for this purpose, and succession boxes should focus on the latter. Nav boxex serve too many purposes for this function to become an add-on.

Template navboxes are more informative & aren't limited to immediate predecessors/successors of the bio's subject. GoodDay (talk) 05:10, 13 December 2018 (UTC)

• Oppose Being "informative" isn't just about the quantity of information delivered to the reader, but its relevance, which is why policies like WP:INDISCRIMINATE exist. The relationship between an office- or title-holder and their immediate predecessor and successor is much stronger and more relevant than that between holders of the same office a century apart. The typical navbox sacrifices an important piece of information (the dates during which a person held office) to make a large number of mostly irrelevant connections to temporally distant people.

To give an example, if I've been learning a bit about Sir Thomas More, some of the questions that might naturally arise are "Who preceded him as Lord Chancellor? Did his official performance contribute to More's high reputation for judicial efficiency?" and "Who replaced More, and how did he accommodate the King's religious policy?" The links provided by a succession box facilitate answering these questions. I can't see how to justify linking from More to, say, Lord Brougham without an incredibly contrived and unnatural question. Choess (talk) 17:37, 15 December 2018 (UTC)

• Question Does anyone have a handy example of where a navbox provides the same information as the succession box? I wouldn’t be opposed to the change if we retain the ability to navigate as Choess outlines above. I, too, use succession boxes this way, and like Hawkeye7 I find it an enjoyable way to train-of-thought my way around interesting articles. I wouldn’t want that functionality to be lost, but if we can provide that in a more modern format then I would be okay with that (but I don’t also have no problem with them staying as-is, either). CThomas³ (talk) 04:25, 16 December 2018 (UTC)

Here's an example of a template navbox. GoodDay (talk) 16:41, 16 December 2018 (UTC)

• Oppose. In many cases, a simple succession box is better than a template navbox. Sometimes a navbox would be small enough that it would be mostly whitespace. Consider Charles Lawrence, 2nd Baron Trevethin, who has a succession box for his title of Baron Trevethin and Oaksey, a title with only five holders. Also, sometimes a succession box is less confusing. Consider the fourteenth-century king Eric Christoffersen of Denmark; the relevant navbox has four sections with a total of fifty-six individuals, which means that you take a little bit to find Eric and his successors, while the succession box for King of Denmark makes it trivial to know who preceded and followed him. Even worse for Emperor Go-Uda, the 91st of 125 Emperors of Japan; the template is necessarily huge, while a succession box showing nobody except Emperor Kameyama and Emperor Fushimi is nice and simple. And finally, as noted above, succession boxes typically provide a little extra data, such as dates in a position (1274-1287 for Emperor Go-Uda), that generally doesn't appear in a template. I'm not saying that succession boxes are always needed ("Latest born Vice President to die" seems extraneous, for example), but getting rid of all of them would be a bad idea. Nyttend (talk) 20:10, 20 December 2018 (UTC)

• Wikipedia:Rollback (edit | talk | history | links | watch | logs) - okay, it's a behavioural guideline, not a policy, but I still think this should be here.

I am proposing to remove the fourth (edits by blocked or banned users) and fifth (widespread edits judged to be unhelpful) bullets from the "when to use rollback" section of this guideline, and replace with explanatory text explaining that such reverts are permitted if an edit summary is provided, and strongly discouraged otherwise. The rationale for removing the two bullets is slightly different but very closely related, so this is one RfC rather than two. 17:33, 6 December 2018 (UTC)

For the blocked or banned users bullet: many sockpuppets of banned users make edits which are not clear vandalism (see WP:BANREVERT) and it may not be obvious to the majority of our editors that any particular user is subject to a ban. Allowing no-edit-summary reverts in these cases invites drama, whereas if the reverting editor instead uses an edit summary such as "reverting edits of banned user so-and-so", that's easily justifiable and avoids the drama.

For the "judged to be unhelpful" bullet: nobody should be using the rollback function to mass-revert "judged unhelpful" edits anyway, the policy already dictates that an explanation must be provided but does not mandate an edit summary, which is counterintuitive. Why are the edits "judged unhelpful", and how is the average user to determine that an editor engaging in mass rollback is reverting "unhelpful" edits versus just repeatedly pushing the button indiscriminately? This also invites entirely avoidable drama.

Both of these are certainly cases where reversion is allowed by various policies and guidelines, but in both cases the guideline already advises editors to explain or be prepared to explain what they're doing. The Rollback function should only be used in cases that don't need to be explained, like vandalism that everyone knows is vandalism including the vandal (within reason). When a editor does have a legitimate need to mass-revert many edits under one of these criteria, admins and non-admins alike can install a script similar to User:Writ Keeper/Scripts/massRollback.js which allows semi-automated mass-reversion with an edit summary. In these cases, the edit summary needn't be anything more complicated than "reverting edits by banned user <username>", or for widespread unhelpful edits, "please see <page where a general explanation is provided>". For users not comfortable installing/using a script (which is not complicated at all), they can ask someone who is; we could make a userbox for this purpose.

• Support as proposer - I expect that the text to replace these two bullets will be debated throughout this discussion so I haven't proposed any text specifically. Ivanvector (^Talk/_Edits) 17:33, 6 December 2018 (UTC)

  Related to the last bit I've created Category:Wikipedians who use mass rollback. I don't have graphics software on this computer but I can do up a userbox later. Ivanvector (^Talk/_Edits) 18:35, 6 December 2018 (UTC)

  Wasn't massRollback.js originally written by someone who was banned for sock puppetry? Hawkeye7 (discuss) 04:01, 7 December 2018 (UTC)

  Not as far as I know, but a fun bit of wiki-trivia if true! Ivanvector (^Talk/_Edits) 04:10, 7 December 2018 (UTC)

  Ivanvector, the code shows the original is at [4]. Sure enough, see [5]. Home Lander (talk) 04:13, 7 December 2018 (UTC)

• Support - Per nom. - FlightTime (open channel) 18:05, 6 December 2018 (UTC)
• Oppose - The problems come when there is no explanataion anywhere. I don't think there's anything wrong with using rollback and explaining the decision on an appropriate talk page. I don't think we've ever had a problem because someone explained their rollback somewhere other than in an edit summary. UninvitedCompany 18:13, 6 December 2018 (UTC)
• Support yes, if we have to tighten the criteria—by writing it down—then so be it. ——SerialNumber54129 18:14, 6 December 2018 (UTC)
• In the interest of denying recognition, personally I would prefer that any edit summary not require the name of a banned user to be included when mass rollbacks are being done. Perhaps editors performing these rollbacks could create a section on their talk page and link to it? isaacl (talk) 18:39, 6 December 2018 (UTC)

  Or just "revert edit by banned user" without a username, in cases where WP:DENY is preferred. Ivanvector (^Talk/_Edits) 18:43, 6 December 2018 (UTC)

• Support - Completely agree with this proposal and the tightening of the criteria, It's all common sense really or it should be anyway. –Davey2010^Talk 19:01, 6 December 2018 (UTC)
• Oppose as per the below - I was under the impression we were talking about 1-2 socks who's made a few edits but if we're talking about someone who's racked up hundreds of edits then no a summary shouldn't be used and it's the same for when someone uses the Twinkle unlink button, There's pros and cons to this policy but if we're looking at a bigger picture then yeah I can't see it working. –Davey2010^Talk 17:29, 7 December 2018 (UTC)

  Just to clarify, you're saying that when mass-reverting prolific socks, don't use an edit summary? At all? I know DENY is a thing, but no summary at all is desirable? (Noting that if you use standard rollback, an automatic summary of "undid revision <diff> by <username of sock> will be generated anyway) Ivanvector (^Talk/_Edits) 17:34, 7 December 2018 (UTC)

• Oppose there is nothing wrong with either of those bullets, and nothing to be gained by making it harder to revert widespread actions that did not have consensus. Headbomb {t · c · p · b} 20:02, 6 December 2018 (UTC)
• Oppose, certain banned editors can rack up hundreds or even thousands of bad edits before being noticed. Cleaning up after them should not be made more tedious as a knee-jerk response to one admin being overzealous with mass rollback. —Xezbeth (talk) 20:29, 6 December 2018 (UTC)
• Oppose #5. I recently cleaned up after someone who accidentally used Twinkle's unlink feature inappropriately; there were ~100 reverts to do. I didn't bother trying to learn how to use mass rollback, but having the option to just click a bunch of rollback links made life a lot easier. I could have used Twinkle to do it, but then I would have had to muck about with my settings so that I didn't get a bunch of junk added to my watchlist. Having extra rules about it that would have restricted its use would have been no bueno. But Neutral on #4. –Deacon Vorbis (carbon • videos) 20:48, 6 December 2018 (UTC)
  • Same example I was going to point out. I think judged to be unhelpful to the encyclopedia is too broad and could be open to misinterpretation, but there's a clear use case for this sort of thing. Perhaps replacing it with disruptive to the encyclopedia? Likewise with item #4, and but be prepared to explain this use of rollback when asked to isn't particularly helpful. ~ Amory (u • t • c) 21:19, 6 December 2018 (UTC)
• Oppose Keeping edits by a banned user encourages further disruption. The only thing worse than that would be to glorify their name by putting it in the page history—a quick WP:DENY is the best response. People will find ways to be unhelpful regardless of what the rules say. Johnuniq (talk) 22:14, 6 December 2018 (UTC)
• Support - all sorts of good reasons already noted above. As for the comment about recognition... wp:deny is just an essay, and not a particularly good one, so I don't see why some people tend to treat it as gospel, but I don't see it as being significant factor in this proposal. - wolf 22:19, 6 December 2018 (UTC)
  • As I said in my comment, it is my personal preference to deny recognition of problematic editors. I did not claim that this is a policy. My suggestion is that this preference be accommodated in any modifications to the guidance on using rollback. isaacl (talk) 03:48, 7 December 2018 (UTC)
    • Okay, but you weren't the only one to mention "deny". Don't make this about you. - wolf 07:00, 9 December 2018 (UTC)
      • My apologies for any poor wording. I was expressing a personal opinion in response to your statement, without making any claim to holding a definitive opinion. isaacl (talk) 18:20, 9 December 2018 (UTC)
• Oppose - While I understand the desire to tighten up the policy, I don't think this is the best way to go about it. Rolling back edits of banned users disincentivizes sockpuppety, and in many cases, reverses damage that is done by those editors. In the case of edits judged to be unhelpful to the encyclopedia, there are cases where a rambunctious new editor makes a large volume of the same type of unambiguously bad edit (for example, a style change contrary to the MOS). In those cases, it is economical to simply rollback all of the edits. I've actually used that one myself, after posting my explanation and my intent on the misguided user's talk page. The current policy seems to work pretty well, but it's not designed to work in gray areas cases.- MrX 🖋 22:29, 6 December 2018 (UTC)
• Oppose - I oppose any change in any policy which makes it more difficult to delete the edits of banned or blocked users. I also see this as a slippery-slope which will eventually end up in de-fanging rollback, a very useful tool. Beyond My Ken (talk) 00:56, 7 December 2018 (UTC)
• Oppose: a solution in search of a problem. --K.e.coffman (talk) 01:25, 7 December 2018 (UTC)
• Oppose. For #4 we already have policy/guideline "be prepared to explain this use of rollback when asked to". I don't see evidence that this is being flaunted so badly we need to revise the guideline. And others have spoken well to #5, plus its text includes "you [must] supply an explanation in an appropriate location, such as at the relevant talk page"; again, this covers the reasons given by the proposer without necessitating the awkward proposal. ☆ Bri (talk) 03:08, 7 December 2018 (UTC)
• Oppose. In cases when block-evading accounts are rapidly making edits, rollback can be a very useful tool in counteracting them quickly, even in non-vandalism cases. Requiring an edit summary in these cases only slows down the reversion of disruption. Home Lander (talk) 03:22, 7 December 2018 (UTC)
• Oppose I hope you don't take this personally, but @Ivanvector: as a CU you should know how many LTAs and sockpuppets go through SPI and make edits that have to be reverted en masse (think spam, promotional fluff, POV-pushing socks that aren't "vandalism" necessarily). I can also tell you that many m:Global rollbackers and stewards will likely be caught up in this proposal as rollbacking edits like this across wikis from cross-wiki LTAs is generally accepted. --Rschen7754 07:27, 7 December 2018 (UTC)
  • I don't know why you'd think I would take offense to your comment, but thanks. Yeah, I've been around SPI for several years, and I've had enough editors land on my talk page demanding explanations or threatening blocks that I don't take anything for granted with respect to rollback. These "grey area" rollbacks are not as universally acceptable as we think they are. For folks who do work in these areas and mass-revert often, using one of the scripts is far more convenient than individually rolling back what can be hundreds of edits, plus it allows an edit summary. In fact there are many ways to execute a rollback with an edit summary these days. I do realize there are users who won't or can't install a script, and situations we can't anticipate, that's why I suggested the change to "discouraged", not "prohibited".

  As for DENY since it came up: when I'm reverting socks I don't want to tag I use an edit summary like "rv sock". It's a trade-off, though. Over the years I've had numerous messages like this: "I see you reverted an edit as so-and-so's sock, well a new account made a similar edit, can you take a look?" Whereas if I do a mass revert with a blank summary I just get "turn off your bot".

  Anyway we might as well leave this open for a bit even though there are flurries in the forecast, there are good comments here. Ivanvector (^Talk/_Edits) 11:36, 7 December 2018 (UTC)

  I'd agree the scripts are better (Writ Keeper's in particular is wonderful), but to use the WK script example, even though it allows one to enter an edit summary, it is still a use of the system's rollback feature, and would arguably be caught up in this change. I've never user Twinkle rollback for anything so I can't speak to that one. TonyBallioni (talk) 17:43, 7 December 2018 (UTC)

• Oppose with the deepest respect for Ivanvector, I unfortunately disagree with him here. MassRollback of socks is sometimes necessary, and depending on the case, going through every contribution individually simply isn't a good use of time (I have an xwiki sock at ar.wiki who adds uncited BLP data to soccer biographies that I'm thinking of right now.) Rollback is extraordinarily useful in these circumstances. It doesn't have to be automatic, admins and editors should use their judgement, but it is a legitimate use. TonyBallioni (talk) 17:35, 7 December 2018 (UTC)

  I don't think we actually disagree, TB. I haven't suggested that massRollback shouldn't be used in these situations, only that an edit summary should be provided. Ivanvector (^Talk/_Edits) 21:29, 7 December 2018 (UTC)

  You can't provide edit summaries with rollbacks. Headbomb {t · c · p · b} 23:34, 7 December 2018 (UTC)

  FYI you can't provide an edit summary with a single edit rollback. Mass rollback (or at least the one I know of) does come with an edit summary option before saving the edit. MarnetteD|Talk 23:39, 7 December 2018 (UTC)

  

  MarnetteD and Headbomb, actually per Wikipedia:Rollback#Additional_tools one can provide a summary with an individual rollback, but in a way that I find convoluted compared to just using the middle Twinkle rollback option and typing a reason. Home Lander (talk) 00:41, 8 December 2018 (UTC)

  Thanks Home Lander. I wondered if that was possible. As I read about it convoluted is a good word for it. MarnetteD|Talk 00:54, 8 December 2018 (UTC)

  Various things are called "rollback" but if they allow an edit summary they are imitations and are not really rollback. Johnuniq (talk) 01:25, 8 December 2018 (UTC)

• Comment - I've reflected on this over the past few days and read the views above. I'm not sure what other tools/scripts are available, but the 'mass rollback' allows an edit summary when mass reverting, and use of that should be encouraged/obliged. That also literally zaps everything on the contribs page (last 50, last 100, last 500 etc.) However, not everyone will use that - others will use traditional rollback (one click) when, for example, perhaps an editor has made a series of goodfaith but poor edits interspersed with good edits, meaning mass rollback is not appropriate. That doesn't allow a bespoke edit summary. In those cases, I think a talk page post explaining why is sufficient. GiantSnowman 12:12, 9 December 2018 (UTC)
• Comment: It seems to me that much of this discussion would become moot if there was an (optional) edit summary (pop-up?) box available when the Rollback button was clicked… Useddenim (talk) 01:16, 10 December 2018 (UTC)
• Support. I don't find the arguments against this compelling at all; they boil down to "give me convenience or give me death". For the first of the sorts of cases, we do not generally auto-rollback every single thing that a sock does, but it does happen sometimes, especially when it's too much work or too iffy to determine which 1% of what some disruptive editor did might not be disruptive. It really can be very unclear to "sideline" editors why something got reverted if no edit summary is provided. I've ended up dis-reverting some edits for this reason. In the second kind of case, it really is too grey-area to be going around silently using the rollback tool. The proposer is correct that having to use an edit summary is already implicitly in the rule anyway, since "explanation" is required, but there is no other means of providing it.  — SMcCandlish ☏ ¢ 😼  06:40, 10 December 2018 (UTC)
• Support. Rollback should not be used when an edit summary is needed. —Eli355 (talk • contribs) 01:15, 13 December 2018 (UTC)
• Oppose I usually use Rollback in combination with Twinkle warnings for the fifth criterion. I would find it a big haste to have an edit summary for every single revert. funplussmart (talk) 13:22, 13 December 2018 (UTC)
• Oppose - rollback is not something that is used lightly and is needed at times, when dealing with socks or editors who are only here to be disruptive (especially in mass). Good judgment is to be used. Further, if someone, whoever these unknown sideline editors are, ask, then it can be explained to them. And one can always leave a message on someone's talk page as to why it has been done. Kierzek (talk) 21:48, 20 December 2018 (UTC)
• Oppose if someone has to revert a hundred obviously inappropriate edits then it isn't reasonable to expect the editor to write out an edit summary for each one, and people aren't going to. As long as it is obvious why the edit qualified for reversion then rollback is reasonable. For reverting edits made by a banned user the account has typically been blocked indefinitely as a sockpuppet, so it will be obvious to anybody who checks. Hut 8.5 22:48, 20 December 2018 (UTC)

I’ve opened an RfC at Wikipedia_talk:Blocking_policy#RfC:_blocking_the_admin_who_blocked_you. All are invited to participate. TonyBallioni (talk) 07:37, 21 December 2018 (UTC)

An RFC is open at Wikipedia talk:WikiProject Rivers#NRIVER proposal regarding notability policies for rivers. power~enwiki (π, ν) 17:26, 21 December 2018 (UTC)

 You are invited to join the discussion at Wikipedia talk:Naming conventions (television)#RfC on using US or U.S.. -- Whats new?^(talk) 05:38, 23 December 2018 (UTC)

Hi everyone, I just wanted to flag this discussion I just started, since it seems like an important unresolved policy question that could use some attention from experienced editors. Any thoughts are appreciated! - Sdkb (talk) 22:19, 24 December 2018 (UTC)

This is not yet a fully-fledged idea but I want to spitball a little bit here. Current policy is vague or non-existing on when to move articles from mainspace to Draft-space without consent of the article's creator. The current explanatory supplement's whole guidance (WP:DRAFTIFY) reads:

The aim of moving an article to draft is to allow time and space for the draft's improvement until it is ready for mainspace. It is not intended as a backdoor route to deletion. As a matter of good practice the editor moving a page to draft should mark its talk page with the tags of any relevant projects as a means of soliciting improvements from interested editors.

While there are instances when this is beneficial to the project, preserving content that might otherwise be deleted, in many instances such moves can result in a "stealth" deletion of content, especially if the original creator is no longer active. As such, I wondered if it might not be better if we integrated the process into WP:DEL, specifically WP:ATD-I (or better WP:ATD-D). A possible new wording might be:

Articles which have potential, but which do not yet meet Wikipedia's quality standards, may be moved to the Wikipedia:Drafts namespace, where they may continue to be collaboratively edited before either "graduating" to mainspace or ultimately being deleted. As a matter of good practice the editor moving a page to draft should mark its talk page with the tags of any relevant projects as a means of soliciting improvements from interested editors. Draftification may occur if

1. The creator requests it and no other editors have significantly contributed to the article (same threshold as with WP:G5),
2. as a result of a deletion discussion,
3. at the discretion of any uninvolved administrator after an article was tagged for proposed deletion for a week, or
4. at the discretion of any uninvolved administrator if the article is eligible for speedy deletion; any uninvolved editor can request this using the {{db-draftify}} template.

In my mind, editors would no longer move the article to draft themselves but instead use a template (db-draftify) to alert admins to potential articles that could be draftified immediately or tag them for PROD and the reviewing admin can decide to draftify instead if they believe the problems could be overcome by editing. This ensures that only articles are draftified that would otherwise be eligible for deletion, eliminiting the "stealth deletion" risk that exists under the current (lack of a) policy, while still allowing potentially useful articles to be kept in draftspace.

The db-draftify template could work similar to {{db-move}}, also providing admins a quick link to perform the move, e.g.:

Admins could still decide just to delete the article if they believe the problems cannot be overcome by editing. This might slightly increase the workload for admins but decrease the BITE-risks associated with unilateral draftifications by ensuring a second pair of eyes before any move occurs. Again, this is all very raw and not a complete, RFC-worthy proposal, so feel free to explain to me why this is a stupid idea. Regards SoWhy 15:22, 17 December 2018 (UTC)

How often does it happen that a draftified anything becomes useful again? What is the maintenance overhead from all the draftified articles? Jo-Jo Eumerus (talk, contributions) 15:26, 17 December 2018 (UTC)

I do think something needs to be done about draftification. Scripts make it easy, and without a submitted AfC tag, there's no guarantee anyone will see it again. The hidden deletion is an issue, especially as it can be done by a single editor; most of R2 is "cleanup" after draftifying. My first instinct was concern about swinging too far the other way, that nothing can be main->draft without qualifying for deletion, but this is really just the default way things were done for ages: CSD delete, author wants to improve it, sysop puts draft in userspace. I can't say I've thought too deeply about this as written, but it looks good for the most part. Some numbers would help get an idea for what this would entail. I presume most would be A7 stuff, but certainly not all of it, so this (and associated templates) would need to be flexible. ~ Amory (u • t • c) 17:26, 17 December 2018 (UTC)

BTW, by "G5 standard," do you mean to exclude banned editors or is it a typo for G7? ~ Amory (u • t • c) 17:28, 17 December 2018 (UTC)

By G5 standard I meant thew "no other editors have significantly contributed to the article" part, i.e. creators shouldn't be able to request draftification if the article has been edited by others significantly (the same way that banned user's pages can't be G5 deleted if they are not the sole (significant) contributor. Regards SoWhy 18:40, 17 December 2018 (UTC)

I think that we could benefit from a more clear standard on what state an article should be in to be eligible for draftification, but the template proposal requiring an admin to move it to draft is a step backward. Natureium (talk) 00:01, 18 December 2018 (UTC)

• As a new page patroller, I use draftify a fair amount when I come across articles that do not clearly pass notability requirements but that likely could have sources available to improve them that I wouldn't be able to find in a brief internet search. I try to be careful to not draftify articles whose initial editors appear to be inactive, but this is hardly a foolproof system, and more importantly this isn't official policy so it does bear amending. My concern is that this proposal will add unnecessary work in the form of more articles going to AfD when they could have been resolved without bureaucracy. As a potential counter-proposal or amendment, I'm wondering if we could create a workflow where draftify procedure continues as it exists now, except that draftified articles which are not edited in X amount of time get automatically sent to AfD. This would prevent articles from slipping through the cracks, without frontloading work at AfD in scenarios where editors are available to work on the article. _signed, Rosguill ^talk 00:13, 18 December 2018 (UTC)
• I don't see improvements here. We don't need admins approving every draftification. Draftification is fundamentally a WP:BOLD move, and the editor can undo it if they wish by recreating in mainspace or by moving it back. The only thing that needs to be clarified is that it is for pages that don't meet mainspace criteria yet, but might in the future (don't draftify junk). If a reviewer makes a mistake, nothing is deleted and can be easily reverted by anyone with autopatrolled status (the minimum privileges allowed to create articles anyway). As for 'stealth deletion' concerns, only pagemovers can move without leaving a redirect, and the bar for getting pagemover privileges is reasonably high and generally given only to trusted users. In all other cases an R2 redirect will be left behind where it will be brought to an admin's attention who can review the action. — Insertcleverphrasehere ^{(or here)}_{(click me!)} 00:43, 18 December 2018 (UTC)
  • R2 (as with all SD criteria) should be used for clearcut cases that fit the bill. R2 is not "delete this but only after reviewing this other page for notability and deciding whether you think it'd survive A7, prod, or AfD." If you think an article needs an admin's attention who can review the action, draftifying and R2-ing is not the way to get that. ~ Amory (u • t • c) 02:06, 18 December 2018 (UTC)
• The current system is very exploitable. Draftification, in practice, is effectively non-admin backdoor deletion. I'd support this proposal as written. At a minimum, I think we need a mechanism to ensure that every draftified article either meets a CSD criterion, or has an opportunity to be discussed formally. I'd also like to see a clear set of standards for draftification. In fairness, draftification has not usually been a problem, and has cut down on some bureaucracy. I'd love to see a percentage of how many draftified articles get re-established into mainspace. If that number is in the low single digits, we can regulate draftification as deletion. If it's more than say, 20%, we can carve out a unique ruleset for it. Tazerdadog (talk) 01:09, 18 December 2018 (UTC)
• I strongly support an option for draftification of articles that have potential to be improved and exist as regular articles. For articles that are reasonably subject to improvement, this is the place to do it. For articles for which some set of editors believe they should be kept because improvements will be made, this gives them an opportunity to basically put up or shut up. bd2412 T 01:26, 18 December 2018 (UTC)

  If the alternative to draftification is deletion, then draftification often makes sense. If the alternative to draftification is retention, then the article is a net positive in mainspace, and should not be draftified. Is this a reasonable line to draw? Tazerdadog (talk) 02:48, 18 December 2018 (UTC)

  If, in an AfD, there is no consensus to change the status quo with respect to an article in mainspace, then I would agree that the article generally must be retained. bd2412 T 03:24, 18 December 2018 (UTC)

• I don't see that much of an issue with the current status. I do a bit of work on NPP, and if I've draftified 50 articles over the last year I'd be surprised. In my mind, WP:DRAFTIFY isn't that ambiguous. It points to a particular, very specific, set of circumstances, which if met, can lead to draftifying. There are two roads which lead to draftifying, the first of which includes 3 steps, and the second of which is pretty specific regarding COI. I think that if the community feels that there is abuse the solution is to be more stringent in giving out the right, than by changing the existing process.Onel5969 ^{TT me} 02:06, 18 December 2018 (UTC)

  The wording is imho clearly ambiguous. "it is ready for mainspace" can be interpreted as "contains a bare minimum to survive" as well as "looks like a good Wikipedia article". Since draftifying currently does not require any oversight, problems with mistakes that happen usually are not caught. For example, on my daily CAT:CSD browsing, I found this move (I am deliberately not pinging the editor in question because it's not about their action but the underlying problem). Coordinated care organizations are a type of government-created organization that is clearly notable in one form or another with a lot of sourcing easily available through Google (e.g. "Coordinated+Care+Organization" "Coordinated+Care+Organization" "Coordinated+Care+Organization" "Coordinated+Care+Organization"). Yet, this was now a draft, not even tagged with {{draft}}, lounging in Draftspace.

  Wikipedia's main reason for success always was and is that such articles were seen by casual readers who then felt compelled by the "edit" button to fix some problems they identified. This can only continue to work if draftifying is restricted to cases where such editing is not likely, which at minimum requires oversight over such moves. Regards SoWhy 08:41, 18 December 2018 (UTC)

  (edit conflict) Hi SoWhy - not trying to argue, but while your quote above, "it is ready for mainspace", is in the lead of section 1.5 in Wikipedia:Drafts, if you look at the detail of the section, it goes far beyond that simple statement. "The page is obviously unready for mainspace", is then backed up by the 3 examples, each of which drills down in specificity. In looking at the current guidelines, it must meet 1, 2 and 3 in order to warrant draftifying, or #4 all by itself. 1, 2 and 3, in turn are further expanded upon. Is this as airtight a case as some of our notability criteria? In some cases, no, but in many cases, much more so. In the example you reference above (the original of which I can't see because of the RevDel), the move to draft was warranted, as the stub clearly qualified for G12 deletion (as shown by the RevDel, although I agree that was not the move that editor cited when making the move). Moving it to draft, allowed the editor to work on the article and remove the copyvio, as opposed to simply having the article deleted. I would posit that your example actually shows the value of draftify, as there was an issue with the article, it was draftified, the issue was resolved, the article was improved and then moved back to mainspace. I will say this, the editor who moved the article does not have pagemover rights, hence they would to have had to manually add the draft template (it is automatically down when you use the pagemover tool). Perhaps moving to draft should only be allowed to those who do? This would provide some modicum of oversight, while not adding to the existing backload of admins. Onel5969 ^{TT me} 10:46, 18 December 2018 (UTC)

  The problem, however, is that Wikipedia:Drafts is not a guideline or policy but essentially a type of essay. And the criteria it stipulates are partly the problem, as it stipulates that draftification for example can occur if the topic is "plausibly notable", the creator is inexperienced and not actively working on it, which basically amounts to removing notable topics from mainspace that no one is likely to care about anymore before G13 comes. It also says articles can be draftified in cases of COI editing which is not backed by the policies the page claims to explain.

  Moving something to draft the creator is still actively working on for a copyvio is imho not warranted because it adds another unnecessary step (that said, removal of the copyvio would have left a viable stub anyway). As for workload, as I noted above, this was only a rough idea. The point is to add a second pair of eyes to the process, so requiring a pagemover to check the article might work as well. Regards SoWhy 11:11, 18 December 2018 (UTC)

• Draft space was created as a staging area for new contributors who were unable to create pages in the main article space. It should be tightly restricted to this because it is already overloaded, with a process time measured in weeks/months, and so can't cope with any more. 99% of the articles in Wikipedia's mainspace are of less than good quality and so the idea that imperfect articles should be moved into draft space is absurd. See the recent GCTA AfD for an example of this. That's a complex technical topic which has been in mainspace for over two years. It has about 50 sources and yet several editors wanted to push it into draft space to resolve a dispute about supposed synthesis/OR. Draftspace has no special properties which would facilitate such dispute resolution and would tend to make matters worse by limiting discussion to the warring parties, contrary to WP:OWN. As the topic is notable, the likelihood is that another entry would be made in mainspace and then you'd have a content fork. Draftification in such circumstances is clearly disruptive and contrary to Wikipedia's fundamental principles. It should be forbidden. Andrew D. (talk) 10:28, 18 December 2018 (UTC)

• As for the OP's proposed text, note that this is suggested as an update to WP:DRAFTIFY. That page is described as "...an explanatory supplement ... This page is not one of Wikipedia's policies or guidelines ..." So, it's like WP:BEFORE – a counsel of perfection which is widely flouted and ignored because its status is unclear. Having such multiple levels of policy and process is complicated, confusing and counter-productive. Multiplying these levels makes matters worse and so should be resisted per WP:CREEP and KISS. As such developments tend to harm the project by exasperating incumbents and deterring novices, they should be deprecated and dumped. Please delete draft space in its entirety and save us all a lot of grief. Andrew D. (talk) 10:54, 18 December 2018 (UTC)

  Actually, it is suggested as an update to WP:ATD which is part of the deletion policy precisely to make the status clear. Regards SoWhy 11:12, 18 December 2018 (UTC)

  I didn't grasp that on a first reading and so take your point. But I am quite well versed in deletion policy. If I have difficulty following this, imagine how hard it will be for newcomers. Wikipedia has become overcomplicated and we should be rolling this back, not refining it. Andrew D. (talk) 11:27, 18 December 2018 (UTC)

• Draftification is a flawed concept. It should never have been introduced. Either an article is non-notable or notable (by your judgement). I am sure nobody thinks that a article is both notable and non-notable at the same time. In case it is notable, improve it, tag it for improvement, if it isn't, PROD it or AfD it. Why consign it to eternal oblivion and deletion just because you are too lazy to open a few more windows, but still want to review more articles ? No article is perfect and even our featured articles cannot be called perfect (in the literal sense) so, should all articles be draftified ? The draft namespace is a fig leaf, a broken process which allows Wikipedia to still use the tagline 'the free encyclopedia that anybody can edit'. It should never be used as a holding-cell for these so called 'im-perfect' articles and I absolutely oppose any attempts to formalise this informal non-admin deletion startegy — fr ⁺ 11:13, 18 December 2018 (UTC)

  I'm happy to support any such proposal but so far the community has not been in favor of that, so this proposal attempts to at least minimize the problems. You are welcome to start an RFC to forbid draftification altogether. Regards SoWhy 11:31, 18 December 2018 (UTC)

  I am aware that I am probably in the minority regarding this idea..... — fr ⁺ 10:47, 19 December 2018 (UTC)

• I find myself strongly in agreement with Andrew Davidson and FR30799386; but not adopting the proposal leaves us with a status quo where articles are being moved to draft and "stealth deleted". We need to do something about that. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:21, 18 December 2018 (UTC)
• "Stealth deletion" is a tricky phrase here, because it easily runs the risk of our words confusing our meanings. Deletion is deletion, and not BOLD editing, because of the bureaucratic barrier to undo the action. Draftifying on the other hand is BOLD editing, because it's a decision that can be made by pretty much anybody (although with more mess if not a page mover or sysop), and can then be undone by pretty much anybody (although with more mess if the XNR isn't suppressed or deleted).

The problem in my mind with drafts is that, while anyone can work on them and improve them, people seldom do, because by virtue of the fact that we do not allow XNRs from mainspace, no one really knows they exist. What I would prefer as a solution to that problem is a system that incorporates some implementation of "draft-space-WikiProject-categories", that function as a marker so that something like AAlertBot can notify relevant WikiProjects of pages within their scope that have been created or moved to draft space. This would function the same as AAlertBot already notifying projects of relevant articles that have been nominated for deletion/GA/DYK. (I believe User:Ritchie333 already implemented something similar for Women in Red, but I'm not sure where the link is.)

Overall, I think it we want to implement a solution, we should prefer something like this, a technical addition with the goal of facilitating collaboration, rather than erecting another bureaucratic barrier that makes more busy work (i.e., work other than creating and improving content), and at the end of the day, serves to make our system even more esoteric and increases the knowledge-based barrier-to-entry for new editors. GMG^talk 11:55, 18 December 2018 (UTC)

But is moving viable content to a different namespace with different rules and no easily visible access not the very definition of making "our system even more esoteric and increases the knowledge-based barrier-to-entry for new editors"? Regards SoWhy 12:01, 18 December 2018 (UTC)

There are always going to be edge cases where draftifying seems like the best alternative. Obviously, if someone is draftifying clearly appropriate content ready for mainspace, or if someone is sending copyvios and attack pages to draft space, that's a COMMONSENSE problem that needs to be addressed on an an individual level.

But thinking about the issue tactically, if "stealth deletion" is the hill you aim to take, you can attack the "deletion" part, and try to implement substantial new sets of rules that place a substantial additional sustained burden on admins and patrollers (both groups that are in short supply already tasked with constant backlogs), and which requires substantial changes in organizational culture to succeed.

Alternatively, you can attack the "stealth" part. This requires technical implementation for sure. Categories for drafts need to be created and populated, AAlertBot needs to have the ability to sort them, and the AfC script needs to be updated to automatically remove them upon acceptance. However, once implemented there is comparatively little sustained burden to support. Categorization only takes a few seconds and pretty much the whole process can be automated or semi-automated.

But what you buy for that implementation is first accountability for patrollers who are draftifying articles, since project members are presumably in the best position to judge whether content is appropriate or not. You provide a useful tool for WikiProjects to improve existing drafts (and potentially avoid another Donna Strickland), and you also provide a tool for content creators to be directly involved in page patrolling and AfC, both areas where process-editors (for lack of a better term) generally dominate, and content creators have little regular participation. GMG^talk 13:51, 18 December 2018 (UTC)

• I don't see any benefit of requiring admin approval for moving incomplete drafts to draft space, but I see plenty of downside like reducing the quality of main space, added bureaucracy, and consolidation of power by the few. As I have said before when similar proposals were floated, if six months is not enough time for an article to be improved to our minimal stub standards, then it's doesn't belong on Wikipedia. We will survive it's absence. I am also concerned that this would be used to inappropriately decline draft moves by a couple of admins who routinely decline CSDs citing an essay that they wrote. (I guess we could call that stealth decline). We have to remember that admins do not necessarily have better judgment than non-admins. They have simply passed a review of some self-selected editors in the RfA process.- MrX 🖋 12:22, 18 December 2018 (UTC)

  When people are saying that incomplete articles are "reducing the quality of main space", one should remember that's how most, if not all, articles started. For example, these are the first versions of some of the TFAs recently featured on the Main Page: [6], [7], [8]. I'm pretty sure that if draftspace had existed back then, someone might very well have draftified one of those citing "not ready for mainspace" despite the fact that, as Andrew points out, policy explicitly says that lack of quality is not a reason for removal from mainspace (which draftification is). The point was this: Since moving to draftspace removes a page from the view of 99% of people (i.e. casual readers with no understanding of how Wikipedia's processes work), such a move is, from an outsider's perspective, a deletion. As such, the decision to perform such a move should lie with those who are also tasked with the deletion of pages. Vague concerns over "admin abuse" are not a valid argument either since, like with deletion taggings, editors can always nominate an article for XFD if the draftification is declined (nothing stealthy about it, since the article is still visible in mainspace unlike when moved to draftspace). Regards SoWhy 13:19, 18 December 2018 (UTC)

  You seem to be assuming that readers primarily access article to improve them. What about readers who access article to learn from them, or to get verifiable, factual information? The latter's needs are often unmet. We're not talking about article that are incomplete in the sense of not being GA or FA; we're talking about articles that are not written to a minimum standard to even know if they are about verifiable, notable subjects. I dispute that an article about an obscure, probably non-notable, subject would be improved in any meaningful way if it were left in article space. It sounds nice, but I don't think it would bear scrutiny. I made a similar argument here, with some evidence. For the record, I did not mention admin abuse. My concerns are about a small handful of admins who have opinions about deleting articles that I believe doesn't align with the norm. That's OK. They should have a voice to, but so should editors who have demonstrated sound judgement in this area. - MrX 🖋 17:24, 18 December 2018 (UTC)

  As I noted above, many articles started off as sub-par but were improved over time because anyone could contribute. While I admit that this happens less than say 10 or even 15 years ago, it still happens. And I don't assume that most people access articles for that reason; I assume that a significant number of people will, when faced with an obvious error and a large edit button, fix the error. We have tags to warn casual readers that an article might not be helpful in all regards already, so removing the article from the view of those, whoever many, editors who would want to improve the article is not within the spirit of the project. As for "obscure, probably non-notable" subjects, I made this proposal with subjects in mind. Anything about a clearly notable subject should not be draftified anyway, however bad the article is, because WP:IMPERFECT is longstanding policy. Your link talks about edits to pages moved to draft; my point is that moving to draft is exactly what slows down or prevents such edits to occur in the first place.

  As for "admin abuse" (note the quotation marks), the whole point of the proposal of codifying draftification into a policy is to have a widely supported rule that will make it easier to identify and handle problematic actions. Regards SoWhy 20:45, 18 December 2018 (UTC)

• Definitely support the idea in principle, too many articles are draftified due to "experienced users" misinterpreting WP:MINREF as somehow requiring references for all articles, or inline citations for all BLPs (when it only requres them for direct quotes and contentious material), and then what usually ends up happening is that the page creator forgets about the article (as either they've stopped editing or they think they've already done their job in creating the page), and then nobody else is informed of the draftification, and then who knows whether the admin that sees the eventual G13 thinks its worth saving or not. Many of these draftifieed articles would be kept at AFD and would be better off in mainspace, where they will eventually be improved. Iffy★Chat -- 13:01, 18 December 2018 (UTC)
• I would oppose the proposal as written, as a solution in search of a problem. Being part of NPP / AfC gives one a different prospective on draftifying. Actually, NPP is the project that's more backlogged, at ~4000 articles (Wikipedia talk:New pages patrol/Reviewers), while the AfC backlog is ~1250 drafts / 3 weeks: Category:AfC pending submissions by age/3 weeks ago. Regardless, I would invite editors here to join either of these projects and help out with the backlogs. Draftifying is really an insignificant tool in the "toolkit"; I'm not seeing a lot of issues from its use. --K.e.coffman (talk) 04:33, 21 December 2018 (UTC)

Does a draftyfing add any sources? Certainly not. A page in the main space may be developed, a draft will perish. An AfD may mobilise coauthors, draftyfing won't.

Why existing unsourced pages are acceptable, new ones are moved to Draft space without any control?

I have started to create pages linterlinking existing pages. I believe that such pages are better than red links or nothing. Their references exist in linked pages and copying the references isn't creative, anyone is able to check them. But I have been criticised, so I don't any more.

Xx236 (talk) 10:15, 21 December 2018 (UTC)

• Oppose - There is a nasty tendency where admins basically bully new article creators during the drafting phase to improve their articles to their own idea of what a good article is, rather than just to meet the basic criteria (WP:GNG, WP:NOT etc.), and if the editor then boldly moves their article to the article space the admin then responds by AFDing the article. If you want to see an example of this happening see these six AFDs 1 2 3 4 5 6 all of which were raised by the same admin against articles started by the same editor and then boldly moved to article-space by the editor. The result of the AFD process for all but one of these articles was "Keep", with the remaining one being a likely merge. I have no faith in the draft process if this is representative of what goes on there. The article space allows for the involvement of other editors at an early stage and is a much healthier environment for article creation.

An additional point is that a very important thing about AFD is that AFD is NOT clean-up. If it is possible to save an article then you should just go ahead and do so. Indeed, if it is possible to save an article it won't be deleted at AFD because of WP:NEXIST. Draftifying an article subverts that by turning AFD back into a clean-up process. FOARP (talk) 09:24, 27 December 2018 (UTC)

The latest Daily Mail RfC is about to close. If anyone reading this has input on this, now is the time to participate in the RfC.

See Wikipedia:Reliable sources/Noticeboard#2nd RfC: The Daily Mail. --Guy Macon (talk) 17:48, 27 December 2018 (UTC)

Wikipedia:Conflict of interest/Noticeboard#2nd RfC: Do alternative medicine practitioners have a conflict of interest? --Guy Macon (talk) 19:01, 30 December 2018 (UTC)

Okay, this is somewhat related to the proposal/idea above (#Workshopping: Integrate draftification into the deletion policy) but since I keep seeing it more and more, I hope we can clarify this regardless of the outcome of that discussion. I'm referring to moves (using the MoveToDraft script) that cite as reason "Undersourced, incubate in draftspace". From my understanding of the editing policy and the core notability guideline, articles about notable subjects should be kept in mainspace if improvement is possible. Yet, I keep seing moves like this (just a random example), where clearly notable subjects with literally thousands of easily accessible sources are removed from mainspace (with some admins then blindly removing the redirects without checking the move's validity). Is this really consensus now? Because then we should change those policies and guidelines I mentioned to reflect that. Regards SoWhy 12:15, 20 December 2018 (UTC)

Since the random example, that you presented here, is the draftify move that I did 18 days ago, I would like to take part in this discussion. The article, that is moved from mainspace to draftspace on the grounds of undersourcing, is valid in my opinion and as per WP:DRAFTIFY because draftspaces are meant for improving the articles that can survive an AfD. The burden to demonstrate verifiability lies with the editor who adds or restores material and the draftspaces give them total opportunity and space for the draft's improvement until it is ready for mainspace. Moving an article to draftspace does not indicate that the subject is non-notable. An article shouldn't be moved to draft space on the grounds of notability. WP:NEXIST is irrelevant here as notability is never questioned. Regards Hitro talk 15:15, 20 December 2018 (UTC)

WP:DRAFTIFY is not a policy or guideline. It claims to explain policies but contains language contrary to policy, including WP:FIXTHEPROBLEM which says we (including you) should fix problems, not remove them from view. Any article about a notable subject, no matter in which state the article is, should survive a correctly argued AFD because surmountable problems (like missing sources in the article) should never be grounds for deletion. But, as I said, I noticed such moves often (not just by you, which is why I didn't mention you by name, to not single any one editor out), so I'm beginning to wonder whether the policy and guideline I cited still reflect consensus when people violate them constantly without reproach. Regards SoWhy 16:04, 20 December 2018 (UTC)

Yes, it is one of many possible reasons for moving something to draft space, but it shouldn't be the only reason if a cursory search shows that the subject may be notable, or if the article otherwise conforms to minimal article standards. Isolated examples in which editors judge the content differently does not really make the case.- MrX 🖋 20:53, 20 December 2018 (UTC)

I would only move a clearly notable article to mainspace if it was clear the article was an unsourced BLP that seemed clearly notable, but that I couldn't easily source, OR if the BLP was an attack piece that couldn't easily be cleaned up. In other situations where notability hasn't been established but notability is likely, for instance, a WP:TOOSOON article, I'd have no problem moving it to draftspace. Not sure what the general consensus is at the moment, though. SportingFlyer talk 22:34, 20 December 2018 (UTC)

BLPs that are unsourced are pretty likely going to get PRODded; I really encourage you to move them (back) to draft space until they're sourced. If they're supposedly easily sourced, then source them immediately before moving them to mainspace. Risker (talk) 04:02, 21 December 2018 (UTC)

Unsourced BLPs should not exist in mainspace at all. There's a reason we have a special deletion procedure for them. TonyBallioni (talk) 04:09, 21 December 2018 (UTC)

To be fair, I don't think I've ever moved an unsourced BLP to draftspace. Just pondering the scenario where, for example, there's say a sports player who clearly passes a SNG but has no references in the article and the references are likely to be in a foreign language. SportingFlyer talk 04:25, 21 December 2018 (UTC)

If it's in mainspace, it should be deleted under WP:BLPPROD (I would actually prefer this to moving to draft for a few reasons with a BLP). If it's in draftspace, it should be kept there until referenced. TonyBallioni (talk) 04:27, 21 December 2018 (UTC)

If it's in mainspace and a quick Google search finds sufficient reliable sources, shouldn't adding these sources be preferable to both deletion or draftification? Regards SoWhy 08:26, 21 December 2018 (UTC)

Very obviously yes. Wikipedia is the Encyclopedia that anyone can edit, including you. If you can see a way of keeping an article, then do so. The default should not be draftify or delete. FOARP (talk) 08:39, 22 December 2018 (UTC)

My example is Draft:Świdnicka Street, Wrocław. The street is one of the most notable ones in Poland.[9] I haven't found English language sources. Will the Polish langauge sources help you?Xx236 (talk) 10:26, 21 December 2018 (UTC)

Foreign language references are still references, there is no requirement that references be in English.FOARP (talk) 08:39, 22 December 2018 (UTC)

• Comment unfortunately, in my experience of doing NPP, people wanting to write new articles can be very lazy and the number of top-quality NPPers is limited. While in an ideal world NPPers would finish off other people's articles when they're notable topics, and I do genuinely try (you can see my patrol log for examples), we do just have to say to people "it's up to you to put the references in" or they're just going to do it again and again. However, one problem with draftifying is that people may not know how to un-draftify and just lose interest. As a third way to try to reduce conflict (and this is just me) my approach basically is to play good-cop and say something like "you know, if you don't finish it off, I'm worried that someone might delete this". You can read some template messages I have ready to go for this kind of situation here. Blythwood (talk) 00:27, 2 January 2019 (UTC)

Hello, there is a discussion open at Wikipedia_talk:Requests_for_permissions#"confirmed"_users_can_no_longer_create_articles regarding a technical configuration that is preventing manually confirmed new users from authoring articles. Please follow the existing discussion if you are interested in this or especially if you are aware of any prior discussions where this access change was requested. — xaosflux ^Talk 04:15, 5 January 2019 (UTC)

Wikipedia talk:Did you know#RfC: Commas in DYK --DannyS712 (talk) 23:49, 6 January 2019 (UTC)

I am not sure if this is the right place for my question, but as this is basically a policy question, I'll try here: Is there a policy concerning church names and how to write the "St."?

Like: Do we write "St. John's" or "St John's" or "Saint John's"?

I would assume that the way the church itself spells its name should generally be first and foremost as a guiding rule, but what about church names from other languages which have been translated into English?

Like here we've got a muddle of St John's (Norwegian: Johanneskirken), St. James's (Norwegian: St. Jakob kirke), and also Saint Paul's (Norwegian: St. Paul kirke).

To make matters worse, it's not being handled consistently within the articles either. The article St John's Church, Bergen, for instance, uses St. John's Church throughout the text. --87.150.15.136 (talk) 17:24, 7 January 2019 (UTC)

Wikipedia:Manual of Style/Abbreviations is the guidance on this. Excepting cases where reliable sources use another format, follow MOS guidance. The MOS states that both St. and St are common, though have a close tie to one or another version of English. It also recommends spelling out the full word in most cases to avoid having to decide between styles. --Jayron32 17:41, 7 January 2019 (UTC)

Thanks for your reply... but to be honest, I find neither of those pages very helpful. The MOS seems to allow all three, so the long and short of it seems to be "do whatever you like". Which means we end up with pages like those I linked to above where all three appear within one page, and some are even used interchangeably for the same church in the same article.

I don't really see how the varieties of English come into play here since we are talking about non-English churches. To me at least, it doesn't seem to make much sense to say "we should use American English for this one and British English for that one". Or does that depend on who happens to write the article? --87.150.15.136 (talk) 18:04, 7 January 2019 (UTC)

What spelling and style appears in an article at any specific time often depends on who is workin on it - which can indeed mean that spelling and style can become inconsistent. Most editors simply write - without worrying about style or spelling - leaving it to others to follow on after them and fix any errors they might make. Yes, we do want consistency within an article, so feel free to follow on and fix things to make it consistent. Most of the time no one will object. If someone does object, then go to the talk page and discuss it. Don’t insist... see if you can find compromise. Blueboar (talk) 18:47, 7 January 2019 (UTC)

O.k., I made a suggestion on the talk page of the article with the inconsistency within the article.

Seems like there isn't anything we can do about the blatant inconsistency on the categories page then? --87.150.15.136 (talk) 19:33, 7 January 2019 (UTC)

Well, you could discuss it at the relevant project pages, and see if a consensus can be formed to be consistent at those specific articles ... but policywise, no. We accept all the variants. Blueboar (talk) 20:36, 7 January 2019 (UTC)

O.k., thanks. No, that is definitely more fuss than I would want to go through.

I just happened to hit on that page and thought it looked sort of ugly, but I certainly don't intend to spend a major part of my time fighting over those kinds of purely cosmetic changes. :-) --87.150.15.136 (talk) 21:51, 7 January 2019 (UTC)

Yeah, the general principles are 1) Be consistent within the article (use the same style in the title and everywhere in the text) 2) Use the style appropriate to the variety of English being used in the article (in articles about British subjects, use BrEng, in American subjects, use AmEng, for all others just keep it consistent and obey whatever was there when you showed up) and 3) If a specific Wikiproject wants to harmonize all the articles of a certain type with a consistent style, they can set up their own reasonable style that usually follows an existing style tradition. However, excepting those cases, rules #1 and #2 are the only guiding principles. --Jayron32 13:36, 10 January 2019 (UTC)

Oh, and Rule #0: WP:BEBOLD. If something bothers you, fix it, and if no one objects, you're fine. It's only if someone else thinks you did it wrong that you need to fall back on the other principles. --Jayron32 13:37, 10 January 2019 (UTC)