This page uses content from Wikipedia and is licensed under CC BY-SA.

Wikipedia:Village pump (policy)

 Policy Technical Proposals Idea lab Miscellaneous 
The policy section of the village pump is used to discuss proposed policies and guidelines and changes to existing policies and guidelines.
If you want to propose something new that is not a policy or guideline, use Village pump (proposals).
If you have a question about how to apply an existing policy or guideline, try one of the many Wikipedia:Noticeboards.
This is not the place to resolve disputes over how a policy should be implemented. Please see Wikipedia:Dispute resolution for how to proceed in such cases.

Please see this FAQ page for a list of frequently rejected or ignored proposals.

« Older discussions, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147


Removing warnings on one's own talk page

This has been open long enough and no one has supported the proposal. ~ GB fan 11:36, 3 December 2018 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

One thing that has frequently happened to me is that I would be looking through a user's talk page before giving a warning, lo and behold, they were given a level 4 warning and I didn't know it because they blanked their talk page. It is extremely inefficient to browse diffs to see what warnings they were given. Per WP:BLANKING, people can delete warnings as evidence that they read the warn. I would like to propose a change to that policy that allows users to remove warnings only if the warned user and issuing user come to an agreement or a set amount of time has passed (lets say 6 hours) which allows recent changes patrollers to see if the user is a persistent problem or just a one off incident. Kyle Bryant (talk) 02:31, 17 October 2018 (UTC)

Wikipedia:Perennial proposals#Prohibit removal of warnings. – Finnusertop (talkcontribs) 10:13, 17 October 2018 (UTC)
If the WMF wanted to help us with this, they could easily make it so that a person just reading the talk page doesn't see the deleted warnings but a special button makes them visible. They could allow anyone to push that button, only extended confirmed users, or only admins.
I wonder, would a script be able to automate most of the work of searching the history for deleted warnings? --Guy Macon (talk) 10:56, 27 October 2018 (UTC)
    • Support proposal for button, as the warnings easily get deleted and out of view so making problematic editing situations difficult to judge Atlantic306 (talk)
  • Meh... I don’t find it onerous to look in the talk page history to see if a user has received previous warnings. No big deal. Blueboar (talk) 14:14, 4 November 2018 (UTC)
  • Oppose; the purpose of a user talk page is to serve as a means of communication with that editor, not as a wall of shame documenting that editor's past mistakes. If the five seconds it takes you to click on "history" is too long for you, you're the one editing too quickly and without due care and attention. ‑ Iridescent 14:26, 4 November 2018 (UTC)
  • Oppose- If some chucklehead wanders by to plaster a frivolous warning on my talk page, of course I am going to remove it. Reyk YO! 14:33, 4 November 2018 (UTC)
    Urge to warn frivolously...rising...Deacon Vorbis (carbon • videos) 14:46, 4 November 2018 (UTC)
  • Oppose because it took all of my stockpile of self-control for the day not to go post a snarky warning on the OP's talk page and therefore it's all Wikipedia's fault I just ate a giant chocolate-chip cookie for lunch. Opabinia externa (talk) 21:37, 4 November 2018 (UTC)
  • Question, how difficult would it be to just make a user script that looks at the page history and displays a list of warnings, from say the last 2 days, or maybe a configured amount? If possible it would remove the need for policy changes while allowing people who want/need the information to get to it easily. zchrykng (talk) 22:04, 4 November 2018 (UTC)
  • Oppose, but I would support adding a separate log for user warnings, with a tab visible to admins showing recent warnings to a given user. bd2412 T 22:30, 4 November 2018 (UTC)
  • Oppose. I can't make much sense of the idea that if I give someone a warning I have to also have a discussion with them and come to an agreement about when they can remove the warning from their page. If I were an asshole, I could withhold that agreement indefinitely just to stick it to them. WP has plenty of assholes. More to the point, if I'm leaving someone a warning, I have way better things to do than have a pointless discussion with them about the archiving of their talk page. Especially since their disagreeableness and inability to work toward compromise with other editors may be the proximal cause of them receiving the warning. In short, WP:NOT#BUREACRACY.  — SMcCandlish ¢ 😼  10:31, 11 November 2018 (UTC)
  • Oppose - Would create more problem than it solves.
    The script ideas above aren't bad, but how often does a script-qualified editor who doesn't feel strongly about the need devote the time to create a script because there is a consensus among a few people at the Village Pump? I don't know. ―Mandruss  11:21, 11 November 2018 (UTC)
  • Snow Oppose This would discourage users who get a warning from editing Wikipedia. —Eli355 (talkcontribs) 22:11, 22 November 2018 (UTC)
  • Comment A separate log containing all warnings, bans, AE sanctions, etc. against a user would be a better solution. This isn't just a user talk issue; when an editor is quite active at noticeboards, it can be difficult to track down a "consider this your last chance" warning, especially when you don't know if it exists in the first place. Even formal restrictions such as topic bans and ibans aren't always documented clearly. –dlthewave 15:26, 23 November 2018 (UTC)
  • Oppose - Bureaucracy at its most pointy. — Maile (talk) 00:05, 28 November 2018 (UTC)
  • Oppose - since we're only talking about recent warnings, it takes only mere seconds to click on the history tab and see if anything has been recently removed from the page and if so, just a few seconds more to either click on the version just prior the removal edit, or to just look down the entries to see if any of them are warnings. I don't see anything too onerous, difficult or time-consuming about this. There is also nothing about this that warrants a change in policy that would further limit a user's ability to remove unwanted content from their user pages, nor necessitates a need for the WMF to create a button for an insta-list of previous warnings. - wolf 11:29, 3 December 2018 (UTC)

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

RfC on schools' inclusion criteria

Should Wikipedia have one set of criteria about articles on schools up to and including the high school level and a different set for articles on schools of higher education? (I.e. beyond high school, e.g. universities.) -The Gnome (talk) 12:46, 9 November 2018 (UTC)


This follows a series of discussions and RfCs in other pages, over the years. (See "Links to relevant threads," herebelow.) This RfC tries to take on the issue of school notability and inclusion of schools articles in Wikipedia slowly and piecemeal. It is posted here following the suggestion that the PUMP is the appropriate place for such a broad-policy question. Editors are encouraged to add to the link-sections below if they believe something is amiss.

List to relevant threads

List to relevant policies, guidelines, essays


Notifying editors who got involved in past discussions:


  • No need - Both types of institution should be covered by WP:ORG. Blueboar (talk) 13:09, 9 November 2018 (UTC)
  • No need every possible article which could ever be written is already covered by WP:42. If a SNG contravenes that principle, it is wrong, and if an SNG agrees with it, it is redundant. --Jayron32 04:55, 10 November 2018 (UTC)
  • Remove distinction: they should just comply to WP:NORG. I'd also support removing the pesky exemption from CSD for schools that are patently non-notable. StraussInTheHouse (talk) 16:08, 10 November 2018 (UTC)
  • Need: It is easier with some criteria that can be applied directly to avoid endless discussions about relevant articles that however gets a request for deletion or to avoid creating articles that are clearly not notable. Within sports there are criteria about which competitions or divisions give presumed notability to a player. For schools there are quite good criteria on Swedish Wikipedia (I know that each Wikipedia has its own rules.): sv:Wikipedia:Relevanskriterier#Skolor_och_andra_institutioner_för_lärande and sv:Wikipedia:Att_skriva_om_utbildning#Skolor_och_lärosäten. Hopefully Google translates them reasonable well, but here is a summary:
  1. Universities etc: Presumed to be notable
  2. Secondary schools: In some cases (old ..) presumed to be notable
  3. Primary schools: not notable (should be in the article about the administrative unit to which they belong, as well as the not notable secondary schools)
  4. School buildings: if built by some famous architect
The GNG is quite abstract, so there is need for concrete criteria. Per W (talk) 11:10, 11 November 2018 (UTC)
  • No need, using NORG for both, per Blueboar/Jayron32. I will point out there have been past attempts to have school-specific notability guidelines, but these never gained consensus (per what Per W is describing). --Masem (t) 06:32, 12 November 2018 (UTC)
  • Uncertain what to use for specific criteria, if any at all other than WP:GNG. I should however note that simply being verified to exist DOES NOT make any educational institution inherently notable enough to warrant a page. We shouldn't presume something is article-worthy just because it's a college/university/school. Perhaps WP:NSCHOOL could make a more explicit note of this. Snuggums (talk / edits) 06:36, 12 November 2018 (UTC)
  • I'm not sure if we do need a SNG for schools (I'm leaning towards yes), but I'd rather that we don't allow articles on every single secondary school. There has to be a cut-off somewhere. Narutolovehinata5 tccsdnew 06:40, 12 November 2018 (UTC)
  • Yes schools are not just ORGs they are a special kind of organization that attract articles. Everyone would like to see their high school and University on Wikipedia. Schools tend to produce notable graduates. They are important infrastructure like highways and town councils and they play an important role in building communities. Wikipedia does a public service by covering schools because it allows some verification that people are listing real schools on their resumes and not diploma mills. I believe every legitimate post sec degree granting school should have a page, while high schools and elementry schools should be covered within a page on their school district. If there is no school district (say an independant/private school) high schools should have pages and elementary schools not. I strongly favor a bright line rule like WP:GEOLAND rather than a fuzzy guideline that results in endless debates about the notability of this or that school, how reliable the sources are and so on. Why is school X notable while school Y across town in the same district is not? Sports and crime stories are going to decide notability if we have a fuzzy rule. Legacypac (talk) 06:41, 12 November 2018 (UTC)
  • "Everyone would like to see their high school and University on Wikipedia". While that may be true for most, I can recall cases at OTRS where teachers have contacted us asking for the article on their school to be deleted because it is a target for vandalism. Just the other day, I removed some highly derogatory content from Berachampa Deulia Uchcha Vidyalaya that had gone unnoticed for more than a year. This is partly why I think we should focus on quality over quantity with schools articles. Cordless Larry (talk) 08:09, 12 November 2018 (UTC)
  • I lean toward "no need" but am open to being convinced otherwise, mainly because of the years of dispute history involving this stuff. In the views of those who think we need special rules for schools, please explain a) why NORG isn't good enough, and b) why it can't just be fixed in NORG instead of in a probably pointless WP:POLICYFORK that we'd be likely to merge anyway. On the above detailed proposition, I don't agree with Per W's summary. No secondary schools are "presumed to be notable". If one is very old and has a richly detailed RS track record, it is notable because of the RS coverage – it is demonstrated not presumed to be notable. I don't think even universities should be presumed to be notable, since various things call themselves universities that are not one. If something with "College" or "University" or "Institute" in its name turns out to be notable it's because we verified the RS coverage of it and demonstrated it to be notable, not because we presumed it was notable. Mountain ranges and heads of state are presumptively notable because of what they are, of their scope in the grand scheme of things. I agree that primary schools are presumptively non-notable, i.e., that it's going to take really strong RS showing to demonstrate that one is. That said, NORG seems to already have all this covered.  — SMcCandlish ¢ 😼  06:53, 12 November 2018 (UTC)
    • Comment: Assigning qualitative attributes to higher educational institutions must be the work of sources considered by Wikipedia to be reliable; it's certainly not within an editor's scope of authority since that would be their own, personal judgement. In case no such third-party, independent assessors of higher-education quality exist, we have to decide what to do, in view of what SMcCandlish rightly points out above ("various things call themselves universities that are not one"). -The Gnome (talk) 12:11, 18 November 2018 (UTC)
      Definitely not an idle concern. I ran into this right before the wikibreak I just returned from (a religious, borderline cult thing that got permission to build a "university" in one country or another, but which is really an indoctrination farm and money-suction device). There is some coverage of it (though probably based on press releases by the religious group and/or the govt. that approved their permits and stuff); an editor unaware of the organization's nature might easily be fooled into assuming it really was an instititution of higher learning. This is very similar to all the charter schools being run by for-profit companies, just with a religious instead of commercial focus.  — SMcCandlish ¢ 😼  19:30, 18 November 2018 (UTC)
  • Clarification:
  1. Universities and colleges: Presumed to be notable
  2. Secondary schools (including defunct institutions): Presumed to be notable
  3. Primary schools: Some AfD's have been ridiculous and overzealous in squashing notability of some lower level schools that have achieved significant coverage. I am frequently astounded at the serial blindness of a certain class of editors who cannot see a long list of sources, obviously achieving the basics of WP:GNG. Instead they only see the hard gospel of a WP:SCHOOLOUTCOMES, with no room for reason.
Because we have that class of editor roaming the back pages of AfDs (looking to cause trouble), we cannot provide them any further ammunition for their arguments. No wiggle room, no further limitations they can misinterpret as an excuse to censor additional wikipedia content. I will note, on the many school articles I have tried to create or improve, I have not found the same consistent set of sources for school information that are available for other common subjects. Government lists are frequently years out of date and incomplete. Many sources are community generated and don't meet the standard of WP:RS. And the best sources for a specific school ultimately resolve back to WP:PRIMARY where your quality and consistency may vary. I know of probably a dozen or more large schools that have no articles and that have been that way for a decade. Why? The sources to create even the most cursory stub just aren't available to me or anyone else who looks. I've personally written to many schools suggesting they write their own article . . . make it a class project. Tell the world the story of your school and find the local sources to back it up. It has worked a few times, but most of the time it is ignored. With that inconsistency of sources, additional limitations to our criteria are not warranted or useful. Trackinfo (talk) 07:04, 12 November 2018 (UTC)
Please see my comment just above yours. It's highly dubious that any of these things are presumed notable, certainly not below the university level and even that's iffy because not everything with that word in its name is a legit institution. PS: Deletion is not determined by a conspiratorial cabal of roaming troublemakers, but by general community consensus at AfD. If someone makes compelling arguments for deletion and no one can mount a compelling reason to keep then the article should in fact be deleted. You seem to be making an argument against Wikipedia operating the way Wikipedia operates.  — SMcCandlish ¢ 😼  14:26, 14 November 2018 (UTC)
  • No need A key problem with having different rules for different tiers of education is that the institutions within those tiers differ wildly. For instance, while US high schools seem to be huge, Australian ones tend to be relatively small (hence a major issue I have with editors who argue that high schools are automatically notable - maybe they are in the US, but not in Australia). The size of higher education institutions in Australia varies from about 73,000 students at Monash University to dozens at some private sector tertiary education providers, so obviously the same rules can't apply to all. WP:ORG does a good job, and there's no need to treat educational institutions in a special way. Nick-D (talk) 07:17, 12 November 2018 (UTC)
  • Please close this before it becomes a huge mess like the last RfC on this issue some things are just best not talked about in a large RfC and are best found out through practice. Divisive issues where massive RfCs have consistently not reached any consensus are one of them. Also, NORG explicitly does not apply to schools as was part of the consensus adopting the new standards. TonyBallioni (talk) 08:38, 12 November 2018 (UTC)
  • No point. This is a battle that was lost over a decade ago, and the notion that secondary schools of whatever size or importance are exempt from any notability standards or sourcing requirements is about as set in concrete as any COMMONOUTCOME on Wikipedia. Waste of time and breath to hash it out yet again. Ravenswing 08:42, 12 November 2018 (UTC)
  • No. In actual fact, the criteria we usually use cover (a) primary and middle schools, and (b) secondary schools and tertiary institutions. We usually consider (b) to be notable and (a) not to be. -- Necrothesp (talk) 08:46, 12 November 2018 (UTC)
@Necrothesp: where are the criteria that are used? --Per W (talk) 12:41, 12 November 2018 (UTC)
  • No need - Both types of institution should be covered by WP:ORG. But it should be a good idea to get rid of SCHOOLOUTCOMES as it is too often misused as a policy to keep schools, even when horribly written and unsourced. The Banner talk 09:45, 12 November 2018 (UTC)
  • I agree with TonyBallioni, and I think the specific line he is referring to in WP:ORG is The scope of this guideline covers all groups of people organized together for a purpose with the exception of non-profit educational institutions ... (emphasis mine). Mz7 (talk) 12:34, 12 November 2018 (UTC)
The problem with that highlighted sentence is that the ORG guideline subsequently goes into some detail about schools... in fact it has an entire sub-section devoted to them... so (despite the highlighted sentence) it is obvious that schools ARE considered within the scope of the ORG guideline. I think that sentence will need to be removed, but that is for another discussion. Blueboar (talk) 17:05, 12 November 2018 (UTC)
Yeah, point taken. Mz7 (talk) 03:39, 13 November 2018 (UTC)
  • No per Necrothesp's comments. Over six years ago I perused 100s of high school AfDs which I compiled in an essay and concluded that no matter what anyone ever says and how many RfCs and dramafest discussions we have, verifiable high school articles that aren't just a one-sentence piece of crap are almost ALWAYS kept. --Milowenthasspoken 12:55, 12 November 2018 (UTC)
Good survey! So a well-written article (with enough verifiable content) about a high school should be kept. Couldn't we then state somewhere that high schools are presumed to be notable? Then we can avoid lots of discussions. --Per W (talk) 14:39, 12 November 2018 (UTC)
Note that the phrase "presumed to be notable" does not mean "is inherently notable". A presumption of notability simply means we should give a school article the benefit of the doubt... waiting to delete until we have done due diligence in searching for sources (per WP:BEFORE). Blueboar (talk) 17:05, 12 November 2018 (UTC)
Cordless Larry: See, and that's exactly what I was talking about below, about schools in non-English speaking countries. We delete them because we don't have or can't read the foreign-language sources. But I can guarantee you such schools would have been kept if they were in Anglophone countries. In effect, if we insist on GNG for high schools we are institutionalizing WP:Systemic bias. --MelanieN (talk) 10:07, 13 November 2018 (UTC)
But if we can't read the sources, then I don't see what we can base articles on. I'm also not sure that the issue is about not being able to read the sources, because we have some regular school AfD participants who have the language skills necessary to read local sources, but rather that the sources often don't exist online, so we can't access them. Cordless Larry (talk) 10:10, 13 November 2018 (UTC)
Cordless Larry: The only thing I've seen changing is that more articles are being created these days for high schools in far flung non-English speaking places without available online sourcing. Those have always candidates for deletion. When the "are high schools notable?!?" debate began 15 years ago with the VfD for Union County Magnet High Schools, editors were debating mainstream large American high schools. E.g., Jimbo Wales made the argument in November 2003 that Randolph School could have an article. No one would dream of sending something like that to AfD today. I screenshotted the article deleted via Wikipedia:Articles for deletion/Kishorchak Banamali High School, it was unsourced, there was no option but to delete. If someone wants to spend their time on wikipedia tracking down stubs to Indonesian and Indian high schools without sourcing, they will get them deleted.--Milowenthasspoken 14:01, 13 November 2018 (UTC)
Yes, true enough about Kishorchak Banamali High School, which was pretty much my argument there too, Milowent. Some editors will still argue for keep even in such circumstances, however - including admins, which worries me. Cordless Larry (talk) 14:39, 13 November 2018 (UTC)
  • Keep the current understanding: institutions of higher learning (degree granting) and secondary schools (diploma granting) should be presumed to be notable, if there is confirmation of their existence and status. This practice 1) prevents endless arguments because high schools and colleges, like professional sports figures, virtually always turn out in a search to have enough coverage to qualify, and 2) helps to get around our inherent bias against non-English-speaking countries, since even though coverage likely exists, it can be hard to find in the non-English press. MelanieN (talk) 17:24, 12 November 2018 (UTC)
  • (@MelanieN:, where is the current understanding? --Per W (talk) 18:52, 12 November 2018 (UTC)
  • I sincerely doubt that the "current understanding" is that all high schools and above possess inherent notability. But I could be wrong. -The Gnome (talk) 19:57, 12 November 2018 (UTC)
  • Keep as is. Agree with MelanieN on all issues. In fact I'd like to take her comment above and frame it somewhere. Hobit (talk) 18:08, 12 November 2018 (UTC)
  • Different set lower than GNG (Thus NOT NORG) - Secondary schools and definitely accredited universities should be presumed notable status. Classifying them in with WP:NORG is wildly OTT and also sets them a higher level of standards to meet when the circumstances for those stricter requirements is less likely to occur. I haven't marked this as "Keep" like MelanieN since there is such disagreement as well as partial rollback from this position that "Keep" is itself a level of dispute. Nosebagbear (talk) 18:21, 12 November 2018 (UTC)
  • No – GNG suffices. Nothing should be 'presumed' notable. If it doesn't meet GNG, it doesn't belong on Wikipedia. RGloucester 03:33, 13 November 2018 (UTC)
On the contrary, there are many traditional and accepted special guidelines at enwiki that define notability in ways other than GNG - for example, WP:NACADEMICS. This is not a new or startling concept, it is long-established practice; see WP:SNG. There are many special guidelines for specific categories of article that "presume notability" if certain criteria are met - for example, playing a professional sport at the highest level. The rationale behind this presumption is that such people will virtually always be found to have received coverage that meets GNG, so let's just accept that and not get into thousands of individual arguments about it. The nutshell at WP:NSPORTS spells it out very clearly: "An athlete is presumed to be notable if the person has actively participated in a major amateur or professional competition or won a significant honor, as listed on this page, and so is likely to have received significant coverage in reliable secondary sources that are independent of the subject." That is also the rationale behind presuming notability for high schools and colleges. --MelanieN (talk) 09:59, 13 November 2018 (UTC)
Did you ever consider that perhaps I do not agree with the way such guidelines are used? I'm being asked this question in the context of schools, and in the context of schools, I do not believe anything other than GNG is required. We can discuss sport when someone opens an RfC on that subject. If a school does not meet GNG, it does not need a Wikipedia article. Wikipedia is not a directory. In any case, like others here, I would also be satisfied by bringing schools formally under WP:ORG, if that's preferable. RGloucester 15:30, 13 November 2018 (UTC)
Um... folks... Schools already ARE covered formally under WP:ORG... See WP:NSCHOOLS. Blueboar (talk) 16:04, 13 November 2018 (UTC)
It seems somewhat ambiguous at the moment, given the "exception of non-profit educational institutions" caveat in the lead. What I meant is that I'd be fine with clarifying WP:ORG to the effect above. RGloucester 16:21, 13 November 2018 (UTC)
For the sports-specific notability guideline in particular, it does not define notability in a way other than the general notability guideline. It provides guidance on when it is highly likely that the general notability guideline can be met with a sufficient search for suitable sources. It was discussed last year in this venue, and the closing statement once again affirmed this in the context of WP:NSPORTS (as has been discussed many times since, the closing statement overstepped in its broader conclusions for all subject-specific notability guidelines). isaacl (talk) 17:13, 13 November 2018 (UTC)
That's correct, and also applies to virtually all other SNG (subject-specific notability guidelines). There are a handful of divergent ones, like WP:NACADEMIC, and the level of consensus they enjoy is disputed. For the record, I think we need them in some cases when facts about the real world make it otherwise more difficult to have the articles we need – e.g. the fact that mega-influential scientists in their field often get no mainstream news coverage of any kind, just get cited thousands of times by other researchers. But it's a rare divergence from GNG. It will take a lot of community input to figure out whether such a variance should apply to a topic, and will require a community consensus that something is quite different about that topic. We've been over schools so many times I don't think consensus is likely to change in favor of doing so. They aren't different in any salient way from other organizations, other than they inspire some Wikipedians to consider them "important". (Anyone new-ish around here: see WP:Notability/Historical and WP:ITSIMPORTANT for how "include it because it's important" has been received by the community for the last decade and a half.)  — SMcCandlish ¢ 😼  12:56, 17 November 2018 (UTC)
  • Yes: Need separate standards to facilitate discussion and consensus - Many of the comments above don't answer the question being posed, namely, whether there should be separate standards for high schools and post-secondary institutions. I think there should because it will facilitate a more focused discussion. Even for those think that WP:NOTABILITY, WP:ORG and other guidelines adequately cover the field, should recognize that others disagree and have reasons for that disagreement. Those reasons (and the objections to them) are, I think, different for high schools and universities, and it would be helpful to discuss them separately, acknowledging (at least) the possibility of different guidelines for each. My (admittedly brief) involvement and review of past attempts to reach consensus makes it clear that the differences make discussing any particular proposal more difficult.Federalist51 (talk) 21:36, 14 November 2018 (UTC)
  • Comment There may be some validity to "schools being an important part of the infastructure". However living in Detroit, Michigan I live in a place where there have been several fly-by-night charter high schools, so I am less convinced than some that all schools that are at the high school level are notable. I also have seen way too many articles that have only been sourced to show a place exists survive on the theory better sources could be found, while no one even tries to find such sources. We need much clearer policies.John Pack Lambert (talk) 05:22, 16 November 2018 (UTC)
    Agreed on both points. We have no policy or guideline suggesting that schools of any kind are presumptive notable, and a clear guideline (WP:NORG#Schools) stating the opposite, yet some AfD respondents persist in trying to presume their notability.  — SMcCandlish ¢ 😼  12:56, 17 November 2018 (UTC)
  • No need for yet more bureaucracy and instruction creep and oppose the desire and intent to override clear consensus at AFD by shovelling on more and more red tape Atlantic306 (talk) 17:30, 17 November 2018 (UTC)
    If, instead of vagueness, some kind of "clear consensus" exists either way, it would be most helpful for the conduct of AfD participants, as well as for this RfC's progress, to have hard, arithmetical data. -The Gnome (talk) 12:01, 18 November 2018 (UTC)
Of what? There's no doubt that we have a clear consensus; it's codified at WP:NORG#Schools. This is rehash is just another thing that needs to be listed at WP:PERENNIAL.  — SMcCandlish ¢ 😼  19:36, 18 November 2018 (UTC)
Atlantic306 claims that there is "clear consensus at AfD" (emphasis added], but this is previcely the root of the problem. Although WP:NSCHOOLS seems adequately clear (it's not entirely clear, since it asks for A or B or A&B), the recent historical record in AfDs shows that decisions can go, actually, every which way depending on who takes part in each discussion, what is the subject's nationality, etc. And this is how and why the quest for clarity started. The background is in the links in the Relevant Threads section above. It all has come down to whether or not the criteria should be the same for both high schools and colleges of any kind. And here we are. -The Gnome (talk) 13:59, 19 November 2018 (UTC)
  • Firstly, I find WP:NORG#Schools already bizarre - how on earth would a school (or anything) manage to pass standard WP:NORG while failing GNG? At the risk of partially duplicating my most recent comment at the bottom of the general discussion section the clash(es) between AfD !voters and the general editing body is fairly evident on this topic, as noted above. I'm aware of the marginally consensus RfC and choose not to go against it, but disagree with it - thus I don't cast a !vote on multiple instances. I don't think there is a slippery slope of "the AfD editors are dragging the community" to move the notability requirements to some level lower than GNG/bizarre NORG. Nosebagbear (talk) 15:02, 29 November 2018 (UTC)
  • Secondary schools not notable - These articles are a vandalism magnet and are all but impossible to check because sources are scarce and out of date. The articles contribute considerably to the OTRS workload and are a substantial share of the reverts performed by ClueBot and the various bot-assisted interfaces. There is little to suggest that they offer a meaningful draw to new contributors nor that the articles are themselves valuable to readers. Areas such as staff are particularly difficult, as it is common for the names of adminsitrators to be edited, and difficult to ascertain which of these edits are rare good-faith updates and which are students making themselves or their friends the new principal. The Uninvited Co., Inc. 02:31, 2 December 2018 (UTC)
I'm not sure how an increased vulnerability to a certain form of vandalism makes them warrant a lower or higher level of notability requirement. Nosebagbear (talk) 19:36, 3 December 2018 (UTC)

General discussion

  • FYI, pings don't go above the count of 50. I'd guess the above ping-o-mat didn't get every one (I wasn't hit). --Izno (talk) 13:53, 9 November 2018 (UTC)
Greetings, Izno. I'd appreciate any help from anyone in fixing this. I should note here that these were not pings per se but mere full-style usernames. Perhaps that helps. Thanks in advance. -The Gnome (talk) 14:02, 9 November 2018 (UTC)
Linking to userpage is a ping, the above did not go through because the count is above 50. Instead of trying to fix that I would advise to just remove the section, it's unnecessary. –Ammarpad (talk) 14:27, 9 November 2018 (UTC)
Would it work to break the list into smaller groups of pings? Blueboar (talk) 15:08, 9 November 2018 (UTC)
Yes, but even then not in one edit. Each smaller group if they'll add up beyond 50 in one edit, it won't work. My rough count shows there's around 120 editors above; so you can ping batch of 40 in 3 separate edits. –Ammarpad (talk) 15:25, 9 November 2018 (UTC)
Thanks, all. I'll get to it. Take care. -The Gnome (talk) 07:03, 10 November 2018 (UTC)
Sad to say, that probably didn't work. Each edit has to be signed - see WP:PING Note that the post containing a link to a user page must be signed; if the mention is not on a completely new line with a new signature, no notification will be sent. (Multiple mentions on the same new line with new sig are fine.) (talk) 22:05, 10 November 2018 (UTC)
Thank you, I did the multiple, signed edits. Take care. -The Gnome (talk) 06:28, 12 November 2018 (UTC)
Ammarpad, IMVHO the issue is quite important and participants in past discussions on it should be informed of this RfC's opening. Take care. -The Gnome (talk) 07:11, 10 November 2018 (UTC)
The Gnome's ping worked that time 8 mins ago. Graeme Bartlett (talk) 06:33, 12 November 2018 (UTC)
Thanks for the confirmation, Graeme Bartlett. -The Gnome (talk) 10:27, 12 November 2018 (UTC)
I don't know if all the pings worked (I was notified) I just think you should have called it pingamajig. Ivanvector (Talk/Edits) 10:33, 12 November 2018 (UTC)
Noted for next time, Ivanvector! Face-smile.svg -The Gnome (talk) 13:13, 12 November 2018 (UTC)
  • An obvious thing, maybe, but if language is changed, we need grandfathering of existing school articles , giving them say, 2-3 years of time before they are treated under NORG/GNG under this potential change. --Masem (t) 17:13, 12 November 2018 (UTC)
Indeed, 24 months is probably the way to go. My heart bleeds at the thought of having a deluge re-enter AfD. Nosebagbear (talk)
  • What is the driver in this discussion? What is the problem if a few less notable schools are included - are the servers running out of space? Policies and uniformity should support and enhance the information in the encyclopaedia, not reduce it. As a final aside; when I see the acres of text devoted to arguing fine (if not irrelevant) points I do wonder if the time could not have been better spent working on articles. Martin of Sheffield (talk) 08:31, 13 November 2018 (UTC)
Greetings, Martin of Sheffield. Wikipedia's policies and guidelines are evidently not driven by web space availability; otherwise, we would have significantly fewer rules and guidelines. The "driver" of this discussion is quite clear, as one could see by diving into past discussions on the issue, linked above. Take care. -The Gnome (talk) 09:44, 13 November 2018 (UTC)
You haven't explained why you feel the need to remove information though. It reads as if you are just trying to establish rules because you believe there need to be rules. Quoting conflicting policies as if they were reasons appears on the surface to indicate a bureaucratic rather than encyclopaedic approach. I would suggest that a better approach is only to disallow that which harms the encyclopaedia, and I have yet to be convinced that a few lines about an otherwise obscure school (which will of course be notable to many thousands of present and former pupils, parents and teachers) harms the encyclopaedia. Verifiability is important as a safeguard of our credibility but notability is a subjective assessment. Martin of Sheffield (talk) 10:02, 13 November 2018 (UTC)
Greetings, Martin of Sheffield. I did not express any kind of "need to remove information." Where do you get that? (If what you say comes from a hard inclusionist perspective I will not entertain it much, thank you. It simply does not pay to argue with editors who insist that all information has a place in Wikipedia, e.g. "Come on, some stub article about a non-notable subject does not harm the encyclopaedia".) But, more importantly, if the policies are indeed "conflicting", as you say, isn't this a reason to resolve the conflicts and get clarity? -The Gnome (talk) 05:51, 16 November 2018 (UTC)
  • This is a perennial subject of discussion, and has been for a decade or more. Looking at the list above I see that it has been discussed at least three times in the last year, and this is a fourth. In one of those discussions, namely this one, the closers decided that even though the opinions for-and-against NSCHOOLOUTCOMES were about equally balanced numerically, the conclusion was to overturn that longstanding practice. Then people seized on that one (out of dozens) discussion and its barely-supported* conclusion to change the wording at various guidelines to say that, hey, secondary schools aren't presumed notable after all. Looking at the discussion here, I see that opinion is still about evenly balanced, and that many/most of us were not even aware that the longstanding guideline had been overturned on the basis of one RfC. This is immensely frustrating. How are those of us who care about this supposed to keep up? If I wouldn't have known about this discussion, either, except for the ping-o-mat kindly sent out above (thank you, The Gnome). --MelanieN (talk) 10:33, 13 November 2018 (UTC)
*Quoting from the closure: "Based on the discussion, we find that the community is leaning towards rejecting the statement posed in the RFC, but this stops short of a rough consensus. Whether or not the community has actually formed a consensus to reject the statement posed in the RFC is a distinction without a difference." --MelanieN (talk) 10:45, 13 November 2018 (UTC)
  • I think we end up in the situation of the community as a whole is roughly evenly balanced, but of the AfD common editors there is a slight majority towards the "easier/assumed school notability" (by coincidence - I don't think the group is school obsessed). Now obviously AfD editors are supposed to follow community consensus, but at a minimum it discourages delete votes (I admit to sometimes just not casting a vote to avoid !voting in line with that RfC that I disagree with). Nosebagbear (talk) 14:54, 29 November 2018 (UTC)

"Increase" and "Decrease" in rank.

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 Positive decrease 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 Increase 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)

Standard usage seems simple enough;
Increase - eg: increase in net worth
Decrease - eg: decrease in net worth
Positive decrease - eg: decrease in traffic fatalities
Negative increase - 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 Positive decrease. But since it's widely considered an climb or increase in ranking, Increase 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 Decrease, it's considered a climb in the ranks, so Negative increase 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] Increase should be used". Paintspot Infez (talk) 17:32, 11 December 2018 (UTC)

RfC: Citation styles

Should Wikipedia:Citing sources have an explanatory guideline with a set of accepted citation/footnote styles, with the lists of allowed formats and structures to be decided by future RfCs? Jc86035 (talk) 18:12, 17 November 2018 (UTC)

Survey (RfC: Citation styles)

  • Tentative support. Allowing virtually any citation/footnote style to be used can be unnecessarily confusing for contributors, especially new users: while various citation formats are widely used in the English-language publications of many disciplines, and there is obviously good reason for different formats to be used in Wikipedia articles, obscure styles and little-used templates like {{ran}} can make it more difficult for contributors to add to the articles in which they are used. The lack of guidance has also resulted in a lack of consistency in reference group names, mostly for footnotes and primary sources ("note 1", "notes 1", "n 1", "‡ 1", "a", "A", ...). Jc86035 (talk) 18:12, 17 November 2018 (UTC)
  • Support as long as there is a documented mechanism to review adding additional styles as needed to the list. Ideally, certain more obscure formats should indicate which topic areas they should or should not be used on. --Masem (t) 18:26, 17 November 2018 (UTC)
  • Support, per Masem. If any style that is currently used in a topic area is being discussed for inclusion on the list then editors working in that topic area should be explicitly invited to take part in the discussion. Thryduulf (talk) 18:45, 17 November 2018 (UTC)
  • Support – there needs to be a centralized plan to learn how the different styles work, and to suggest not using odd variants. Dicklyon (talk) 18:49, 17 November 2018 (UTC)
Who determines whether a variant is “odd”? Blueboar (talk) 19:07, 17 November 2018 (UTC)
@Blueboar: per the opening post in the RfC, which styles are allowed, which are not allowed and which are allowed only in certain areas will be determined by consensus of future discussions. This RfC is only about establishing the framework so as to avoid objections to specific styles being on one or another list don't derail the whole lists (if there is a consensus for the lists) and/or to avoid wasting time discussing which should be where (if there is consensus against the lists). Thryduulf (talk) 20:52, 17 November 2018 (UTC)
  • This is a huge can of worms - while there is probably some benefit in reigning in some of the more "unusual" citing standards, this has the potential to result in a lot of bad blood and pain if not handled perfectly. We have WP:CITEVAR for a reason .Nigel Ish (talk) 21:00, 17 November 2018 (UTC)
  • Support The standards should be stated and a move made towards the preferred style, and all those variants can be gradually converted to something that looks and works in a consistent way. Failure to use the styles is not necessarily and problem for the editor or article, but instead an opportunity to get it done in a better way. Certainly for FA standard there should be a preferred citation style to use. Graeme Bartlett (talk) 09:36, 18 November 2018 (UTC)
  • Questions:
  1. is this meant to require citations being added in specific formats? We've always accepted plain text or bare URLs as references, as long as enough information is provided to identify the source;
  2. is this meant to be a sitewide requirement policy, or just a best practice/manual of style? I.e. are we going to start trying to sanction editors who use a different citation format? Ivanvector (Talk/Edits) 19:04, 17 November 2018 (UTC)
My impression is that we "accept" almost anything, but that we also advise converting to a recommended and consistent style. We even have bots trying to to that for bare URLs for example. Style guidance points the way to go, but doesn't hit anyone over the head for not going that way. Dicklyon (talk) 19:10, 17 November 2018 (UTC)
My reading of how this is proposed is when we are talking an article at GA or FA. An article is progress is going to likely have a lot of variation in style, include bare URLS, which is fine - our citation approaches are highly complex and not easy to parse. But once you start talking quality, then a consistent style, and ideally one supported by consensus should be used. Certainly early on in an article's development, editors should be aware of what citation style to go for to minimize the pain of updating all the styles at the point of GA/FA. --Masem (t) 21:05, 17 November 2018 (UTC)
  • @Ivanvector, Masem, and Dicklyon: No, this probably shouldn't be a requirement – the actual policy change might be something like "please use these styles and formats; if an article doesn't use a listed style or a listed format then the article may be changed so that it does". I've changed the RfC question (it originally said "include a list of", which would have been inappropriate for a policy). Jc86035's alternate account (talk) 11:25, 18 November 2018 (UTC)
Much better. As per Dicklyon we need to accept poor references, particularly from newbie editors, and then seek to improve them. It doesn't take much effort to bring up a bare URL and generate a {{cite web}} or {{citation}} and the associated <ref>/</ref> or {{sfn}} reference. Martin of Sheffield (talk) 11:39, 18 November 2018 (UTC)
I guess I don't know what's proposed to change. It's already recommended (and best practice for featured content) to be consistent within an article. Is the proposal just for making a list of suggested citation styles? Ivanvector (Talk/Edits) 18:24, 18 November 2018 (UTC)
  • Strong Oppose. WP:CREEP. Violates the spirit and principle of WP:CITEVAR. I use non-code Chicago Manual of Style footnotes. Honestly, we are lucky if bare URLs get filled out at all, and editors who use ReFill don't even give the date or publication of the citation. There are variety of stylebooks for citations, and even the more revered ones vary between themselves. There's no reason to force people to choose from a list of "allowed" styles. This is just going to lead to more trouble and edit-warring. We can certainly give examples/samples, but to enforce a list of "allowed" choices is just asking for trouble, and edit-wars galore. Softlavender (talk) 11:52, 18 November 2018 (UTC)
  • Even stronger oppose. We have over 2000 different citation templates, all of which are currently "approved", plus all the non-template hand-formatted citations. I would support it if we picked a single wiki-wide citation format and deprecated all others, as the short-term disruption of mass conversion would be justified by the long-term stability of an end to arguments over WP:CITEVAR and confusion about which style to use on any given article, but I can't see anything good coming of a proposal to allow whichever small handful of editors bothers to turn up to an RFC to unilaterally decide that some of those 2000 templates are "approved" and some aren't. (Aside from anything else, if there will still be more than one "approved" citation style, how do we decide to which of those we're going to convert all the articles using now-banned styles?) By causing the huge disruption of a mass-conversion, without the benefit of a unified citation style at the end of it, this is just going to cause a huge amount of bad feeling for no apparent benefit. And when I say "huge disruption", I mean it; the most commonly-used citation template, {{cite book}}, is used on approximately 1,000,000 articles, meaning that even if we settled on this as the standard going forward it would still mean 80% of articles would be non-compliant and need to have their references reformatted. ‑ Iridescent 12:10, 18 November 2018 (UTC)
    Most commonly used is actually {{Cite web}}, on 3 million pages. I think you're exaggerating the number of articles that don't use citation style 1 references - a lot of pages that don't use it have bare url references or simply don't have any. TBH I think we should settle things down to using CS1 for formatting references - it is the de facto standard and what visual editor and reftoolbar use - and a choice of citing references using <ref>...</ref> or using {{sfn}}; but the acrimony generated through doing that is probably more work than worth it. Galobtter (pingó mió) 13:43, 18 November 2018 (UTC)
    Also, Iridescent, vast majority of the "2000 citation templates" are just {{Cs1 wrapper}}s (or external links templates like {{Britannica}} and other things that are not really citation templates) - not a different style. Galobtter (pingó mió) 13:55, 18 November 2018 (UTC)
    I'd think it obvious that we're talking acceptable citation template families. There's probably a dozen plus variations of "cite web", but that's all one family. Same with CS1 references. --Masem (t) 05:46, 19 November 2018 (UTC)
  • Oppose per Softlavender. We are still not at a position where references are provided when they need to be. Laying down standards of reference formatting will exacerbate the situation as new editors will give up rather than jump through what they see as unnecessary hoops. Nthep (talk) 13:30, 18 November 2018 (UTC)
    99% of new editors if they are formatting references, use Citation Style 1 (which of course will be an allowed style); nobody is suggesting that new editor's edits should be rejected or that the first thing that new editors should be explained to is what citation style to use. Like with the MOS, it would be mainly experienced editors who fix edits to make them conform with the style. New editors are anyways explained how to/told to use {{cite web}} etc. Galobtter (pingó mió) 13:49, 18 November 2018 (UTC)
    New editors would continue to drop in bare URLs as they do now, most of them being unaware of or apathetic about any relevant guidelines. What we're debating is what happens if and when those are cleaned up. The effect on new users is thus zero. ―Mandruss  18:23, 18 November 2018 (UTC)
  • Oppose per Iri and SL. Ealdgyth - Talk 13:36, 18 November 2018 (UTC)
  • Support Getting rid of obscure styles to make it easier for new editors editing those pages and for consistency across Wikipedia. This really wouldn't affect the vast majority of edits, editors, or pages, but only the few thousand pages that use things like {{ran}} or in text parenthetical citing (which are IMO very reader unfriendly); at-least initially, we can allow a broad range of styles with the exception of some obscure ones. The amount of articles that use things other than Help:CS1 and Help:CS2 and such is quite small. Galobtter (pingó mió) 14:25, 18 November 2018 (UTC)
  • Oppose - The purpose of a citation is to point the reader to a source which verifies our content. As long as a citation does this, it is acceptable. The style is irrelevant. Blueboar (talk) 15:24, 18 November 2018 (UTC)
  • Support wp:citing sources is a guideline not a policy so it doesn't force anything at all, those arguments don't make sense. Guidelines are routinely ignored if editors wish. The purpose of a guideline is to show best practice. A list of best practice citation styles is not only a good idea, why isn't it there already. -- GreenC 15:37, 18 November 2018 (UTC)
  • Strong oppose. A wide variety of citation styles is in use in the academic and publishing worlds, and we accommodate that here relatively peacefully. We have help pages on referencing for newcomers and these can be improved. But forcing an "approved list" of citation styles on Wikipedia seems like a recipe for creating conflict where there is little at the moment. I feel the proposed RfCs on which styles to "allow", with the goal of eliminating some editor's favorite ways of citing sources, would create an Infobox-like situation. StarryGrandma (talk) 16:36, 18 November 2018 (UTC)
    Comment. Adding or linking Wikipedia:Citing sources to a guideline clearly explaining the easiest ways add references with the current state of our tools would be a good idea. (Visual Editor has improved considerably for example; one can now see the references in the reference list after entering them.) A single RfC could be held to decide which methods to recommend there. StarryGrandma (talk) 17:04, 18 November 2018 (UTC)
  • Oppose: The purpose of citations is to make it possible to verify content. Consistency within an article is much more important to that end, and also good for other reasons. Yes, we can speculate styles that are strictly speaking consistent but totally absurd (say, Bluebook in a non-legal article, in CamelCase, encoded with ROT13, and all the punctuation swapped for emojis) but I'd assume that good-faith editors don't do such a thing. As for obscure citation styles hindering the addition of content out of fear of messing up with the existing WP:CITEVAR (yes, merely a guideline as pointed above, but one with a super strong consensus and observance)? I'm not sure if I buy that argument. Editors are supposed to WP:BEBOLD and add content and let others iron out the wrinkles that they don't know how to fix. I see (and fix) articles with slightly inconsistent CITEVAR all the time precisely because editors have added content even if they didn't know all the intricacies of that article's citation style. On the contrary, I've never seen anyone actually complaining about not contributing content because they didn't know how a citation style works. – Finnusertop (talkcontribs) 17:53, 18 November 2018 (UTC)
  • I think this RFC might be the wrong question--I don't need to make an RFC to get permission to ask certain questions, I should just ask those questions. I would rather see us start to chip at the problem instead of a massive RFC to ask about giving carte blanche to deprecate or retain certain citation styles (and I'll throw "formats" in too). Why don't we figure out whether we should use vertical citations first? (And if we do, where we should, or could.) That seems like an easier question to answer. --Izno (talk) 18:58, 18 November 2018 (UTC)
    Sigh... We have had that discussion (over horizontal vs vertical) multiple times in the last few years... the result was consistently that both are acceptable. Blueboar (talk) 19:14, 18 November 2018 (UTC)
    Not really, and certainly not at that page. A handful of "format versus kind of citation" type discussions, but never anything which would give concrete guidance to "use vertical citations for everything" or "use only in WP:LDR" or "do not use within prose". I'm not looking for "can we use it?" only, I'm looking for "when?", and that's never been answered, though I think there's a common sense answer at this time that everyone probably would settle on and agree to add to the guideline if they would only discuss the point. --Izno (talk) 19:31, 18 November 2018 (UTC)
    Either way, that's just one example. There are other questions we could sensibly ask of the same sort that still bypass this overarching RFC that just don't need permission to be asked. --Izno (talk) 19:38, 18 November 2018 (UTC)
  • Support - It's quite possible for the community to establish a minimum set of citation styles that will suffice for most known cases. More freedom than that doesn't decrease edit-warring, it increases it. Most editors will respect a content guideline even if they disagree with it, for the sake of site-wide consistency. The project has established an arbitrary "Wikipedia way" for everything from article titles to order of article elements, I see relatively little edit-warring in those areas (except in edge cases not clearly addressed by the PAG), and there is little question that the encyclopedia has benefited from that consistency. Editors accustomed to using title case in titles and headings adapt to sentence case when editing Wikipedia, and so on, and this is not an excessive burden for members of the most adaptable species on the planet. This situation is no different.
    There are PAGs that are obsolescent, and many that are unnecessarily complex. If the community would put some ongoing effort into reduction and simplification of existing PAGs, WP:CREEP would be far less of an issue; we would simply trade bad PAGs for better PAGs. I support that. ―Mandruss  19:16, 18 November 2018 (UTC)
  • Oppose, per Nigel Ish. As he said, we have CITEVAR for a reason. SarahSV (talk) 22:05, 18 November 2018 (UTC)
  • Oppose per everyone above - If the source is adequate and does the job in verifying whatever that claim is then that's perfect in my books - The style is all but irrelevant. –Davey2010Talk 23:18, 18 November 2018 (UTC)
  • Oppose per Softlavender and Iridescent. Beyond the obvious WP:CITEVAR issue, implementing this would be a nightmare. There are literally thousands of different citation styles in common use around enwiki, just a list of them all would be a massive undertaking, let alone a brief guide for every single one. And, frankly, I'm just glad when an article has citations, even if they're just bare URLs. Nathan2055talk - contribs 08:14, 19 November 2018 (UTC)
  • @Izno: If anyone wants to close this RfC early for asking the wrong question I'm fine with that, although I'm not sure what should happen afterwards. Jc86035's alternate account (talk) 08:38, 19 November 2018 (UTC)
  • Oppose for now per WP:CREEP. I haven't seen a situation where this policy would be needed. --Jayron32 12:05, 19 November 2018 (UTC)
  • Question The proposal does not appear to me to be a change to policy, but a mere suggestion that preferred methods by presented. The !votes seem to be addressing something much stronger. Would this explanatory guideline require of particular formats? Would it prohibit the use of some formats? Jacona (talk) 15:35, 19 November 2018 (UTC)
    • The proposal appears to suggest a "suggestion" now, with more detailed and prescriptive controls coming later as a result of follow-up RFCs. Of course one danger is that editors will take any suggestions, however mild, as policy and use it to force changes through.Nigel Ish (talk) 15:48, 19 November 2018 (UTC)
  • Oppose - Solution looking for a problem. Beyond My Ken (talk) 19:54, 22 November 2018 (UTC)
  • Strong Oppose This will make editing Wikipedia much harder. —Eli355 (talkcontribs) 22:15, 22 November 2018 (UTC)
  • Oppose per WP:CREEP, and the eloquent arguments above.--Esprit15d • talkcontribs 23:57, 26 November 2018 (UTC)
  • Oppose per Iridescent; unless we're establishing one house reference style based on CS1 (possibly with the option for WP:HARVARD referencing) this is a lot of work and extra policy for no benefit. The exact details of MLA v. ASA formatted refs don't need to be established anywhere on-wiki; if somebody really cares they can check the official book. This also seems like a bad way to try to deprecate some of the 2000 ref templates; if that's your goal I'd advise a separate thread at WP:VPI. power~enwiki (π, ν) 05:22, 28 November 2018 (UTC)
  • Absolutely yes, but in specific terms: Namely, either WP:CS1 or WP:CS2, or any citation style codified in a reliable source on citation styles. But no more people making up their own weird nonsense, the personal pseudo-style. (Or, they're fine to make one up, but others are fine to change it to something legit).  — SMcCandlish ¢ 😼  12:39, 1 December 2018 (UTC)
  • Strong oppose - per CREEP. Beyond My Ken (talk) 23:42, 8 December 2018 (UTC)
  • Oppose per WP:CREEP and WP:CITEVAR. rchard2scout (talk) 10:10, 11 December 2018 (UTC)

Bans imposed as unblock conditions

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)
  • @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 (utc) 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)

Proposal to tighten administrator inactivity procedure

Yeah, I know, WP:PERENNIAL. But after yet another compromised inactive admin account ran amok over the project today, I feel like this should be revisited. The account in question did not have a logged action in over 2 years, and had made only 5 edits in 2017 and one in 2018. The policy as currently worded reads:

Administrators who have made neither edits nor administrative actions for at least 12 months may be desysopped.[1] Subject to the lengthy inactivity consideration below, this desysopping is not to be considered permanent, or a reflection on the user's use of, or rights to, the admin tools. The admin must be contacted on their user talk page and via e-mail (if possible) one month before the request for desysopping and again several days before the desysopping goes into effect. Desysopping on inactivity grounds should be handled by English Wikipedia bureaucrats. The summary in the user rights log should make it clear that the desysopping is purely procedural.

I propose modifying this to:

Administrators who have made no logged administrative actions for at least 12 months may be desysopped.[2] Subject to the lengthy inactivity consideration below, this desysopping is not to be considered permanent, or a reflection on the user's use of, or rights to, the admin tools. Desysopping on inactivity grounds should be handled by English Wikipedia bureaucrats. The summary in the user rights log should make it clear that the desysopping is purely procedural.


The change removes the notification requirement, and the "edits" criterion. The effect is that admin accounts which don't use admin tools for 12 months will simply have the bit silently removed as a matter of security. We won't tell them we're about to do it, and then they won't log in and make one nonsense edit to hang on to the bit. Removal will just happen when they've been away long enough, and if they come back some time later and want to go back to adminning they just ask at BN and go through the 24-hour hold like anyone else whose bit has been voluntarily removed. In fact admins should be actively discouraged from "holding on to the bit" in this manner, but let's at least do this. Ivanvector (Talk/Edits) 17:51, 22 November 2018 (UTC)


  • Support Given the length of time the inactivity policy has been around for now, I think it's reasonable to assume every active admin has heard of it, and nobody will be surprised if their rights expire, so provided this gets enough publicity in the right places, we should just do it. Also, as I just said on another thread, I think it would also be helpful to make two factor authentication mandatory for all admins, and desysop those who do not turn it on. It would stop this kind of disruption. Ritchie333 (talk) (cont) 18:09, 22 November 2018 (UTC)
I agree with the idea of desysoping (or at least warning) people for not using 2FA, but there would have to be some kind of cool-down period. Earlier this month, I had to get my phone replaced, meaning I went a day or so without 2FA. It simply wouldn't have been efficient to remove the bit for only 24 hours (especially because I was still active). Perhaps existing admins should get a month or two to set it up, all new admins get one week post RFA closure, and all admins that need to temporarily disable it also get a week. Anarchyte (talk | work) 23:12, 22 November 2018 (UTC)
I strongly disagree with any forced 2FA idea. Forcing editors to have a certain device in order to be admins runs contrary to our most basic principles. There is no rational reason to preclude people unwilling or unable to use such additional devices from being admins. Especially since 2FA is still a hassle as Anarchyte points out and any problem with the device might render an admin incapable of editing at all. Plus, how many active admin accounts have been compromised? Regards SoWhy 11:58, 23 November 2018 (UTC)
I also strongly oppose mandatory 2FA. Benjamin (talk) 01:12, 25 November 2018 (UTC)
Which part of our basic principles is it that requires insecure login methods?  — Scott talk 15:42, 3 December 2018 (UTC)
  • Support though I fear that this is symbolic as all the inactive admins will come out of the woodwork to oppose. --Rschen7754 18:15, 22 November 2018 (UTC)
  • Oppose obviously seeing as not all admin actions are "logged" (for example edits to protected pages, statements in admin function such as WP:AE posts, "Stop this or I'll block you" threats and so on). Other projects which have such inactivity policies have had drama centered on whether non-logged admin actions count and there is the additional concern that such a policy would create an incentive to perform inappropriate but logged actions instead of appropriate but not logged actions. That, and I am sure we can count non-logged admin actions... Jo-Jo Eumerus (talk, contributions) 18:13, 22 November 2018 (UTC)
    In that scenario (eg: "Hey, I was busy promoting DYKs from prep to queue, now I can't!") I think they should be able to get the tools back ASAP if they just ask at WP:BN. I'm not anticipating a rush. Ritchie333 (talk) (cont) 18:17, 22 November 2018 (UTC)
    Yes, but if they're actively doing things that don't get logged for twelve straight months they clearly not actively using the tools, and as Ritchie said they can just ask for them back. It's not a disincentive to adminning, it's purely a security feature. Ivanvector (Talk/Edits) 18:53, 22 November 2018 (UTC)
    @Ivanvector: be careful not to set up loop here as well - example: don't log anything for 12 months, then say "hey I'm back resysop me", then they don't use it right away - do we just pull it again? — xaosflux Talk 19:19, 22 November 2018 (UTC)
    Process-wise we would likely only review these once a month, for what it's worth. — xaosflux Talk 19:20, 22 November 2018 (UTC)
    Well, I'm not a 'crat, but I would say yes, create that loop. It's slightly better (security-wise) than the current loop of notify admin, "hey i'm not idle", then they spend another year idle with admin access. Ivanvector (Talk/Edits) 19:57, 22 November 2018 (UTC)
    @Ivanvector: perhaps you have considered this already, but significant areas of admin activity are not logged. Anything main page related, and anything related to editing restrictions other than blocks, will not appear in the logs. I know several admins who stick to main-page work. Vanamonde (talk) 05:58, 23 November 2018 (UTC)
    @Vanamonde93: yes, that has come up, there's a discussion about actions that aren't logged below. It is a very good point. Ivanvector (Talk/Edits) 13:12, 23 November 2018 (UTC)
  • Support both this proposal and the additional requirement for 2FA by Ritchie333 above. Bradv 18:19, 22 November 2018 (UTC) Striking 2FA comment, as that is not part of this proposal. Bradv 20:26, 23 November 2018 (UTC)
    • I agree with the 2FA requirement, but should that be a separate proposal? Jack N. Stock (talk) 18:34, 22 November 2018 (UTC)
    • Yes, that should be a separate proposal and has been a few times. As I understand it 2FA is still considered "beta", and there has been significant pushback whenever anyone suggests it be required for any level of account. (The functionaries email list blew up over this very recently, and that's only a few dozen users) Ivanvector (Talk/Edits) 18:55, 22 November 2018 (UTC)
      WP:INTADMINs are required to have 2FA but that is only because of a mandate from the WMF Galobtter (pingó mió) 19:01, 22 November 2018 (UTC)
    • Yes, the 2FA requirement should be a separate proposal. And it probably is premature, as 2FA is not even available to non-admins yet. Bradv 19:02, 22 November 2018 (UTC)
  • Support. We need to do something about all the hat collectors who refuse to give up their unused permissions. It's a security risk, and they can ask for their permissions back if they're actually doing something useful. NinjaRobotPirate (talk) 18:27, 22 November 2018 (UTC)
  • Support - TNT 💖 18:52, 22 November 2018 (UTC)
  • I'm curious how many administrators presently meet this criteria? –xenotalk 18:58, 22 November 2018 (UTC)
    @Xeno: 288 per this list (including 4 'crats). — xaosflux Talk 19:05, 22 November 2018 (UTC)
  • Ivanvector this should be an WP:RFC, and also on WP:CENT. Galobtter (pingó mió) 19:02, 22 November 2018 (UTC)
Good point. RfC banner added, and I'll advertise on CENT as soon as I figure out how that works. Ivanvector (Talk/Edits) 19:09, 22 November 2018 (UTC)
  • Strong support This should be done to any account with advanced permissions, such as rollbackers and reviewers, not just admins. funplussmart (talk) 19:05, 22 November 2018 (UTC)
  • I suggest that this proposal should also modify the lengthy inactivity section to clarify that the clock for the three years of uninterrupted inactivity always starts with the last edit, and not with the last administrative action. isaacl (talk) 19:05, 22 November 2018 (UTC)
  • Support the original proposal per the nominator, oppose making 2FA mandatory. I'm presently unable to use it as my only compatible second device is away being repaired (due to an obese battery). There is also insufficient capacity at the WMF to handle users who have problems with it. Thryduulf (talk) 19:31, 22 November 2018 (UTC)
  • Oppose if you're going to get rid of the edit requirement then you need to have some sort of protection for admins who perform non-logged actions. We've had admins who only take part in admin actions that don't generate logs, such as editing the various bits of the main page. Such an admin would be desysopped even though they're still performing admin actions. Yes, they could ask for the admin tools back, but I don't see why they should have to every month just because of a badly drafted policy. Strictly this would also allow new admins and recently resysopped admins to be desysopped as well. Hut 8.5 21:01, 22 November 2018 (UTC)
    • I imagine the bureaucrats would just skip that admin each month, knowing that they are performing non-logged administative actions. As long as the number of these are low, it should be manageable. isaacl (talk) 22:47, 22 November 2018 (UTC)
      • They might skip them, they might not. There would be no policy basis for doing so and bureaucrats tend to be keen on sticking to procedure. The more of these admins there are the harder it is to justify not desysopping them. The whole issue could be avoided by striking one word from the proposed policy change. Hut 8.5 20:37, 23 November 2018 (UTC)
        • @Hut 8.5: I have no problem with that personally, but then we're asking the 'crats to take on the non-trivial work of judging which admins are active. There's a proposal below to implement a log for editprotected actions, so that editing a protected page will be a logged action and count toward activity with this wording. And viewdelete has come up but as I understand how filters work just looking at a deleted page is not something that can be logged, but so far a theoretical admin who only uses viewdelete is an extreme edge case. Ivanvector (Talk/Edits) 20:55, 23 November 2018 (UTC)
        • Sure, I don't have an issue with removing the word "logged" from the proposed text. "may be desysopped" leaves the door open for judgment, but I agree that there isn't a need to limit the range of applicable administrative actions. isaacl (talk) 21:00, 23 November 2018 (UTC)
          • I'd be happy to support this if the activity requirement was defined in terms of admin actions, where an admin action is something which can only be done by an admin and which shows up in your contribution history somewhere. That would include editing fully protected pages, closing discussions which have to be closed by admins, imposing discretionary sanctions and probably a few other things. I agree viewing deleted pages isn't enough and we can't verify it anyway. "Logged action" will be interpreted as something which shows up in Special:Log, which is more restrictive. Hut 8.5 21:42, 23 November 2018 (UTC)
    That's the intent, really: by "logged action" I mean "some action that requires admin permissions". Up until very recently (see below) I was under the impression all admin actions were logged in one way or another. Logging everything admins do is good for accountability, and also has this side benefit of being an indicator (by absence of log entries) of which admins are not actively adminning, and so I went with "logged action" for the policy wording. But it's just as well if it's wording meaning "any administrative action" as long as we have an unchallengeable definition (i.e. editing a protected page is, closing an RfC is not; it's something non-admins cannot do, not just something they shouldn't) and some way to measure it (i.e. logging, or maybe a bot to do the check, or calling on the 'crats to do it). Ivanvector (Talk/Edits) 22:06, 23 November 2018 (UTC)
  • Sounds like a use case for Wikipedia:Interface administrators. If an admin exclusively edits interface pages and has no interest in performing logged actions, then in the interest of security, they should not retain the entire administrator tool set -FASTILY 21:48, 22 November 2018 (UTC)
  • Interface admin allows people to edit interface pages, not ordinary full-protected pages. Furthermore interface admins can do a lot more damage than admins and you have to be an admin to be an interface admin. Hut 8.5 22:04, 22 November 2018 (UTC)
  • Support, and Support 2-factor authentication as well. I'd prefer 6 months, but as some admins seem to think 12 months means one month, that would only confuse them. DuncanHill (talk) 21:05, 22 November 2018 (UTC)
  • Strong Support. As Wikipedia's reputation and popularity continue to grow, it's imperative that we take security/user access controls more seriously. -FASTILY 21:51, 22 November 2018 (UTC)
  • I support this too. Taking out the notifying part is a good idea. BTW Esanchez7587 should have lost the bit a year ago. Drmies (talk) 21:57, 22 November 2018 (UTC)
  • Oppose The Administrators are still using their account. —Eli355 (talkcontribs) 22:19, 22 November 2018 (UTC)

*Support - We're not in 2006 anymore and this isn't a small fairly unknown website, We're currently the 5th visited website in the world and as such in this day and age account compromises really shouldn't be happening, But compromises can and do happen everywhere so we're not always going to be tiptop in that respect, Anyway I support the modification/update. –Davey2010Talk 23:02, 22 November 2018 (UTC)

  • Support - Not sure what I was going on about above .... but anyway admins logging in and making one logged-edit simply to keep their tools is ridiculous - If you're not actually going to help here then what's the point in keeping the bit ? .... so the silent removals (instead of notifications first) will hopefully stop this, As the saying goes: Use it or lose it. –Davey2010Talk 12:37, 2 December 2018 (UTC)
  • Support it’s not that difficult to make the trip to CAT:EX or CAT:G7 so the inevitable “people will make dumb actions just to keep the bit” thing falls flat. Opppse anything about mandatory 2FA. I use it, but we would lose several functionaries if we required it not to mention countless admins. TonyBallioni (talk) 23:07, 22 November 2018 (UTC)
  • Support - Not sure how long it should be, but the constant gaming by inactive−but technically active−admins is counterproductive. Anarchyte (talk | work) 23:12, 22 November 2018 (UTC)
  • Oppose. We want inactive admins to resume helping if and when they want to; there are life reasons someone may step away from the project, and not all will be willing to run the RfA gauntlet again as Opabinia regalis was. We don't want to encourage someone disaffected with the project but unwilling to surrender their tools to delete something or block someone just to keep them, even if it's an unquestioning response to a noticeboard request. Admins who do things like editing fully protected pages (not only DYK, but ERRORS comes to mind) are as useful as those who specialize in deleting and/or blocking, but the former don't appear in the easy to check log. (Nor does checking deleted contributions in evaluating how to speak to an editor, for that matter.) On the other hand I got lots of log entries for moving my own drafts to main space "without leaving a redirect". It's not a fair metric of admin activity. Desysopping for inactivity is also not an efficient way to protect against admin abuse: I recall one case where an admin ran wild including posting a philosophical musing to the Main Page. Emergency desysopping is the best strategy and less likely to lose us useful admins. And we already have that. I also recall seeing something about functionaries periodically testing admins' passwords for strength, but given other cases I recall, I doubt that's been being done. That would help (and would encourage those who don't have serious problems with two-factor authentication to take the step to get out of the resulting demands they change their single password). Also, admins are expected to have e-mail turned on; has any thought been given to bureaucrats' e-mailing those who don't appear to be using their tools, asking whether they would consider handing them in voluntarily? Yngvadottir (talk) 23:17, 22 November 2018 (UTC)
    • There is no need to run the RFA gauntlet again if you return with 2-3 years, that bit wont change. Thryduulf (talk) 23:22, 22 November 2018 (UTC)
    • (edit conflict) Yngvadottir, I think you're misunderstanding the proposal. This isn't "anyone who doesn't use their admin tools for a year has to re-run RFA", it's "anyone who doesn't use their admin tools for a year has to post a request at WP:BN for them to be turned on if they decide to start admin-ing again, and the crats will automatically do so". ‑ Iridescent 23:23, 22 November 2018 (UTC)
  • I would prefer to increase the requirement on what constitutes as "active". An editor who has six edits over two years should not be considered active enough to keep the tools. Mkdw talk 23:35, 22 November 2018 (UTC)
  • Support Use it or lose it. The current requirement of needing a single edit in a calendar year is routinely gamed and far too low of a bar for retaining advanced permissions that can cause wide-spread disruption. Having read through previous related discussions I have never seen anyone present a compelling argument against implementing more stringent requirements.-- Jezebel's Ponyobons mots 23:43, 22 November 2018 (UTC)
  • Support We have nearly 80 admins who have edited in the last 12 months but haven't performed a logged admin action for over five years (in a few cases, ten). All of those, unless they're performing a large amount of non-logged actions - which I doubt - need to lose the bit. There's even a few there who have never passed an RfA .... Black Kite (talk) 23:59, 22 November 2018 (UTC)
  • Support per nom and above supports. ZettaComposer (talk) 00:53, 23 November 2018 (UTC)
  • Support this system is easier to implement, prevents gaming, and has good rationale as per nom. --Tom (LT) (talk) 01:08, 23 November 2018 (UTC)
  • I don't like the idea of -288 admins and -4 crats. I do like the idea of 2fa being mandatory. SQLQuery me! 02:34, 23 November 2018 (UTC)
  • Support. Removing privileges from admins who don't engage in any admin activity is a "paper loss", but a compromised account with privileges causes real harm. The standard proposed is still conservative and easy to meet. By comparison, some other WMF projects have requirements for admin actions every 6 months. (See meta:Admin activity review/Local inactivity policies for more information on other projects' policies.) --RL0919 (talk) 02:44, 23 November 2018 (UTC)
  • Support. Re-requesting the bit if it's been removed is no big deal; compromised admin accounts meanwhile pose a much larger issue to the project. Home Lander (talk) 04:18, 23 November 2018 (UTC)
  • Oppose. First off - This is very premature. Difficult cases make bad law; it's always a bad idea to respond to an event by immediately trying to create a policy that will prevent its recurrence. There has not yet been an analysis of what was going on here. We don't actually know if this is a compromised account; really, what we have is an admin account that acted in an unacceptable manner. Conclusions have been leapt to, and they have not yet been proven. Second - there's no evidence that this change will prevent future similar episodes. The vast majority of administrator accounts that required their privileges to be yanked were those of administrators who would easily have met these more stringent standards, let alone the current ones. Come back in a month, with greater research and good evidence that the proposal will likely prevent rogue administrator actions, and then we can talk. Risker (talk) 04:40, 23 November 2018 (UTC)
    We do know that the account was compromised (related phab task) but otherwise agreed that knee-jerk reactions aren't the way forward here. -- Ajraddatz (talk) 05:14, 23 November 2018 (UTC)
(Unfortunately the task is not visible to the public.) — regards, Revi 05:17, 23 November 2018 (UTC)
What we do know is that the same person has compromised (or at the very minimum, abused) 16 other accounts.[1] Personally I've no doubt about it. -- zzuuzz (talk) 07:20, 23 November 2018 (UTC)
Well, since Ivanvector below has indicated that this proposal isn't really about the recent admin account hackings, and it seems to now be understood that this wouldn't prevent hacking in the first place, I'd be willing to consider an increase in the activity levels of admin accounts. However, I do see lots of useful admin activities that are not logged. If there is to be a change in threshold for de-adminning, I'd go with any combination of X number of edits and Y number of logged admin actions within the previous 12 months, where the total of X+Y equalled some specified number; for example, there must be a minimum of 10 actions (either edits or logged admin actions) within the past year. I strongly believe, however, that the notification of a user that they are on the verge of losing their admin tools is absolutely mandatory; I actually don't understand why anyone would think it was okay not to do so. And it seems there is an agreement that 2FA is off the table too, which is a good thing, since it's really out of the control of a single project. Risker (talk) 02:25, 24 November 2018 (UTC)
It is about the recent hackings, but not meant to be a solution to that problem, just mitigating risk. If the idle hacked accounts had not had admin access then probably the hack would have just taken another form, the vandal has also been hacking accounts that only have rollback permissions. As for the notification requirement, my rationale for changing it is that in the policy's current form we let admins be entirely idle for an entire year, then we tell them to make one single edit if they want to hang on to the bit for another entire year, and in my view that entirely defeats the purpose of suspending the rights of inactive accounts. We might as well just not have this policy at all. If we alter the activity requirements instead, that could be an alternative to this proposal, but given that so many have already commented here on the original I think it would be a good idea to break that out into another subsection. Ivanvector (Talk/Edits) 14:58, 24 November 2018 (UTC)
Well, since it *is* about the recent hackings after all - and given the fact that as I write this I am currently investigating the most recent compromised admin account (of an administrator who is highly active)....this entire discussion is moot. This isn't going to stop the vandal involved, and I don't think it reduces risk whatsoever. Risker (talk) 20:33, 24 November 2018 (UTC)
  • Oppose Having to ask for my bit back every month because I only edit protected pages is not an ideal scenario. Stephen 05:08, 23 November 2018 (UTC)
  • Oppose - As a semi-active admin (but not one who would currently be desysopped under this proposal), I can't support this. I don't believe that the risk of rogue admin actions outweighs the harm to the project that would be caused by driving away semi-active admins who have put in a lot of time and edits, even if real life is preventing them from logging admin actions right now. In addition, desysopping without even a notification is cruel. -Danaman5 (talk) 05:39, 23 November 2018 (UTC)
"Cruel"? I had my admin rights on Monochrome BBS removed without asking sometime around 2002 (I couldn't even pinpoint the year, which is kind of the point) because of inactivity. All I said was "it's a fair cop". Ritchie333 (talk) (cont) 12:05, 23 November 2018 (UTC)
  • Support Not really about security, because I feel that's a non-issue overall. But I have long thought this policy needed tightening up to stop people "playing the game". I would change it slightly though, to remove the word logged, so removals should be based on any edit or log which required admin status. Aiken D 06:37, 23 November 2018 (UTC)
  • Oppose I was going to say what Risker said, but she already said it, so I can just say "what Risker said" ;) We can't just stop informing people of changes that concern them because we don't want them to actually act on that information. Adding to that, I always have a negative reaction to the tone of some of the comments in admin-activity discussions - there's always a lot of snippy posts about "gaming the system" and "hat collecting" and whatnot. Every time I point out that that was me at one point, I almost certainly would have done the "log in and make an edit or three" thing if I'd seen the messages while I wasn't active, and it would have been entirely due to thinking "oh yeah, it's been awhile, I should get back into that when I get some spare time" and then not following up due to, well, lack of spare time. And based on that the same stuff gets posted every time, it seems that pointing out that there's a perfectly reasonable good-faith thought process behind this behavior has exactly zero demonstrable impact on people's willingness to make kind of mean-spirited assumptions. That's not a reason to oppose on its own but it's a weird and off-putting pattern. *shakes fist at cloud* Opabinia regalis (talk) 07:10, 23 November 2018 (UTC)
  • Question: What's the escalation plan for two years or so from now, when the new moral panic is about admins who create and then speedy a page in their userspace once a year? —Cryptic 08:25, 23 November 2018 (UTC)
  • Support By definition, by not editing/doing an admin log in 12 months means they are not an admin! Lugnuts Fire Walk with Me 08:54, 23 November 2018 (UTC)
  • Oppose, far too many "things only admins can do" don't appear in the logs. We need more admins not less. Fish+Karate 09:25, 23 November 2018 (UTC)
    And I will note this RFC has not been written neutrally. "Yet another admin account" implies this happens frequently; per Wikipedia:Former_administrators/reason/compromised, the accounts of Denelson83 and Esanchez7587 have both been compromised this year, but the last one prior to these two was in 2012. Nine compromised admin accounts in 12 years is not frequent. "Ran amok over the project" - they made zero edits and 12 administrative actions, 10 of which were blocks, all of which were undone within 33 minutes. Emotive language doesn't help anyone. Fish+Karate 09:44, 23 November 2018 (UTC)
    In 2016 quite a few admin accounts were hacked by OurMine (see [2]) and they're not listed there in former administrators because they recovered their accounts (see e.g this for locking and unlocking) Galobtter (pingó mió) 10:03, 23 November 2018 (UTC)
    And in 2015, a few accounts were compromised by an attack elsewhere, including two admin accounts. I can agree with the wording being a little iffy, though it's a little more understandable after these are factored in. Anarchyte (talk | work) 10:11, 23 November 2018 (UTC)
    Thanks both, I was not aware of these. This takes it to 14/15 or so admin accounts in 12 years, unless there's others still unlisted, which still doesn't strike me as a regular occurrence to the point 2FA has to be imposed on everyone. Fish+Karate 10:52, 23 November 2018 (UTC)
The reason they didn't appear to "run amok" after indef-blocking two long-standing users who tried to stop them is that a bunch of people scrambled around to get the issue fixed ASAP. As Anarchyte has mentioned, The page above does not document the incident where Salvidrim and OhiaUnited were compromised, or when Jimbo Wales' account was cracked and ran amok, for example. We need a full set of figures to be able to look at the facts correctly. Ritchie333 (talk) (cont) 10:20, 23 November 2018 (UTC)
These stats also don't count the several steward and functionary accounts that were also hacked recently, which could have caused serious actual harm (but AFAIK didn't). Not that this proposal would do much for those levels of permissions, I'm just saying this is quite far from an isolated incident. Ivanvector (Talk/Edits) 13:11, 23 November 2018 (UTC)
  • Support- regardless this latest trigger issue. Not one iota of valid argument in any of the opposes so far. Leaky Caldron 10:15, 23 November 2018 (UTC)
  • Support Everyone can edit, but only admins can make admin actions. Thus their level of activity should be judged by the amount of admin actions they make. I fully understand that some of these actions are not logged, but I don't view this as a reason to oppose. talk to !dave 11:15, 23 November 2018 (UTC)
  • Conditional Support on the basis that an edit filter like the one Xaosflux proposes here (or some other solution) is adopted, so that all major onwiki admin actions are logged. IffyChat -- 11:37, 23 November 2018 (UTC)
    @Iffy: These could be logged for bot review (see example on testwiki. — xaosflux Talk 14:45, 23 November 2018 (UTC)
  • Support protection of the project clearly outweighs putting a legacy admin to the trouble of requesting their tools back occasionally. ——SerialNumber54129 11:48, 23 November 2018 (UTC)
  • Oppose I wish people were pouring effort and creativity into keeping the editors and admins we have. Rogue accounts are easily dealt with. Making people go through any kind of hoop at the end of inactivity is an unhelpful additional barrier to their return. --Dweller (talk) Become old fashioned! 12:25, 23 November 2018 (UTC)
  • I'm all for increasing the activity requirement for security purposes. At the moment it's anything greater than 0 activity. I'm not sure that greater than 0 admin activity is the right way to go - I'd be more keen to look for say, 50 edits per year. It will stop those who keep dormant accounts alive by making a single edit, yet should be easy to reach even at 5 edits per month, which is our definition of "active". Perhaps have 50 edits per year or 1 admin action per year? Regarding mandatory 2FA, I oppose. largely per Risker's diversity concerns. WormTT(talk) 12:28, 23 November 2018 (UTC)
  • Oppose. (Disclaimer; this provision would have caught me out on multiple occasions.) The whole "reduce the potential for compromise" thing, I'm assuming is a complete red herring, unless anyone can provide any actual data to indicate that "admins who have edited within the past 12 months but haven't performed a logged admin action in that period"—the only group which would be affected by this proposal—are at any more risk of compromise than any other account. I'm a strong opponent of the current setup which allows legacy admins from the early days of Wikipedia to periodically emerge and start trying to enforce the standards of a decade ago, and would support some kind of periodic reconfirmation, but I don't see how this proposal would address either the security or the legacy admin issues. (What's to stop either a compromised account, or an incompetent legacy admin, from heading over to WP:BN and asking for the sysop bit back?) In all honesty, whatever the good intent of the proposers it looks more to me like an attempt to cull the number of admins via the back door. ‑ Iridescent 12:32, 23 November 2018 (UTC)
I don't particularly disagree with anything you've said here, but let me try and clarify my view on this. As I vaguely mentioned above, the inactivity standards here seem to be far higher than anything else I've personally witnessed - I've been the equivalent of desysopped for inactivity elsewhere without complaint (but perhaps I'm just the sort of person who shrugs shoulders and moves on) and when I was a regular on Monochrome BBS in the 1990s, policy was that if you didn't use any account (ie: basic user privs) for three months, it was deleted. Is that a good or bad thing, or just different? Secondly, I do think "culling the number of admins via the back door" is a fair point, and I think part of that is due to the dissatisfaction over "legacy admins" because it's too hard to pass RfA these days. Indeed, one of the reasons I went looking for admin candidates over the past 12 months was simply to try and dilute some of that, so that we had a fresh corpus of new admins bringing new ideas into the place, rather than having to rely on people with a grandfather clause. As for what else can do about that, I don't know. Ritchie333 (talk) (cont) 12:49, 23 November 2018 (UTC)
  • I'm in a weird place here — In a vacuum I don't dislike the proposal, but a few of my "always agree with" editors have opposed, so per usual I'm in agreement with them. I like the policy change, if only because it will increase the churn and make it clear that +sysop isn't that big of a deal. I'm not concerned about unlogged sysop actions (although regardless of this the edit filter may be a good idea) because it should be easy to head over to BN and say "Yo, still sysoping here" and get the required bit back. That does, however, belie my real issue with this, which is that it doesn't solve the problem of compromised accounts. A user who is occasionally editing without any logged actions is no less likely to be compromised as they are indeed still using the account. I can support more stringent activity requirements, but I can't support this on the grounds of trying to solve compromised sysop accounts. Put more succinctly by Eli355, [t]he Administrators are still using their account. ~ Amory (utc) 13:18, 23 November 2018 (UTC)
  • Yes, but Only if DYK/Protected Logged - we frequently see DYK as a primary reason for suffering going through RfA, and protected edits must also count. I am in favour of this but at a minimum we need DYK logged and probably any protected edit tagged. Nosebagbear (talk) 13:49, 23 November 2018 (UTC)
  • While I don't want to be one of those "old" admins coming out of the woodwork to reflexively oppose, I think I'm going to oppose. De-adminning for inactivity makes sense to me - if you don't log in for a long time, you may not know what's going on, and you may not be paying enough attention to your account to be sure it's secure. I could support reducing the window of inactivity in the project at all, but I'm not convinced that de-adminning for disuse is the right way to go. What the project needs isn't fewer admins - it's fewer inactive admins. So rather than quietly taking about the tool, why not nudge people to use them more? Something like a bot message that says "you have not made a logged admin action in the last 6 months. Here are some clean-up tasks you could help with". Maybe after a year, up it to "you haven't made a logged admin action in the last 12 months. Please drop by BN to confirm that you still want the tools". Sure, some people are going to make some logged actions just to hold onto the tools, but for every one of those, there would probably be 10 or 20 people who would say "you're right, let me help out a bit". At the very least, I think we should try to nudge people into activity instead. See if that works, before we go ahead with a proposal that, let's be honest, assumes bad faith on the part of inactive admins. Guettarda (talk) 14:17, 23 November 2018 (UTC)
  • To be honest I'm surprised that so many editors are commenting here that this RfC is an attack on inactive admins. It's not, not at all, and I'm a little bit offended that it's being interpreted that way. It's purely patching a security vulnerability. Think of it like the front door of your house (apartment, dwelling, whatever). You have some friends over, you have a good time, eat some food, drink some beers, play some games, whatever. Then everyone goes home, and you close the door. You're still friends (presumably), they're still welcome in your home, but you don't just leave the front door open for when they come back (or you don't in this climate anyway). When they do come back, you look out your window or peephole or whatever, confirm it's your friend knocking on the door, then you welcome them back, eat some beers, drink some food, whatever it is you do for fun. That's all that this is. If an admin has been away for a while, they're still an admin, we just take their mop and hang it back in the closet while they're not using it. It's their mop, and when they ask for it back we gladly hand it back over, and then a bunch of people drop by WP:BN and leave notes like "hey welcome back! we missed you!" It's not a back-door desysop at all.
As for solving compromised admin accounts, of course this doesn't, it doesn't even really try to. As long as we have admins we're going to have hackers trying to crack admin accounts; some of them are inevitably going to be successful, and that is not the admin's fault. All this does is cut down on the number of doors left open to Wikipedia's house. And sorry for the crude analogy. Ivanvector (Talk/Edits) 15:29, 23 November 2018 (UTC)
  • CommentI am not an admin so maybe there is something I am missing, but how does this helps security. Is there any difference in using your account to make admin actions or edits in terms of judging activity and the likelihood of an account to be compromised. Using Ivans open door comparison, you are just as likely to open your door to a friend who has come over for an informal chat as you are to your same friend who comes on some formal visit. They have still visited, even if it is only once a year. If it really is necessary to tighten security via counting actions I feel it would be better to shorten the time of inactivity or increase the minimum number of edits per year. AIRcorn (talk) 17:34, 23 November 2018 (UTC)
    I think the main goal is to reduce the attack vector; less admins means less accounts vulnerable to be compromised, and accounts largely inactive are likely that of users who may not be around to get the reminders and improve their passwords (noting another admin just got compromised..last admin action in 2014) Galobtter (pingó mió) 19:45, 23 November 2018 (UTC)
  • Support, seems like a sensible reform. GABgab 18:20, 23 November 2018 (UTC)
  • Oppose the change per Risker and Iridescent. Particularly with the attempt to backdoor force 2FA for admins. ♠PMC(talk) 19:55, 23 November 2018 (UTC)
Oh, hey, just back from another cleanup from another compromised admin account. There is no "attempt to backdoor force 2FA for admins" going on here. I don't know how to more clearly or bluntly state that 2FA enforcement is not going to happen. If it does it will come from the WMF and we'll have no say in the matter. It's just not part of this proposal at all. Ivanvector (Talk/Edits) 20:19, 23 November 2018 (UTC)
@Ivanvector, the very first comment in the thread is make two factor authentication mandatory for all admins, and desysop those who do not turn it on. You can legitimately say that you don't agree with the attempt, but don't try to claim the attempt isn't being made. ‑ Iridescent 12:55, 24 November 2018 (UTC)
There is always some background minority push to do some thing that is widely not supported or technologically impossible. Mandatory 2FA for admins is one of those rare things which is both not widely supported and difficult technologically to implement (WMF's implementation, not necessarily 2FA in general, see Risker's comments among others). I view the attempts to wedge mandatory 2FA into this completely unrelated proposal as hijacking the thread, and I wager I am more angry about it than you are. Ivanvector (Talk/Edits) 14:13, 24 November 2018 (UTC)
  • Oppose - Some form of removal notification is due, and it is possible to use the tools for the benefit of the community without logging any administrative action (e.g. viewing deleted page history). — Godsy (TALKCONT) 20:08, 23 November 2018 (UTC)
  • Support If you are not using the tools, you will not miss them. If you do want to use them, all you have to do is ask for them back. It's a small hoop to jump through for the sake of fewer sysop account with the potential to be compromised. The benefits to the project outweigh the inconvenience to any very infrequently active admins that this would affect. Natureium (talk) 20:27, 23 November 2018 (UTC)
  • Comment - We've had another cracked admin account this evening, no logged activities for four years, vandalised the main page, deleted today's featured article and indeffed a bunch of admins. Does this influence anyone's opinion? Ritchie333 (talk) (cont) 20:33, 23 November 2018 (UTC)
  • Support The base proposal without requiring 2FA. It should remain a strong recommendation though. Also support "logged actions" being extended to use of editprotect and tracked via the edit filter mentioned above. — AfroThundr (u · t · c) 20:49, 23 November 2018 (UTC)
  • Support The time for pearl clutching is OVER. 2 compromised accounts in a few days is unacceptable. Furthermore it will make the Mop Holder "Put up or Shut Up". Either they do have a need for the admin toolset (or can relatively easily get it back) or they don't need the tools any more. I agree with the provisos regarding certain unlogged items that should count as activity (though why we couldn't get those logged as admin activities is annother question). I note that previous attempts to get admins to maintain secure passwords (or 2FA) were turned down as beyond scope, however the outbreak of compromised administrator accounts requires us to exercise the more painful choice. Hasteur (talk) 22:27, 23 November 2018 (UTC)
  • Support Long overdue. The counterargument that not all admin actions are logged, while technically true, is a red herring. If you are only using adminship as a status and to peek at deleted material, you aren't doing an admin work. With two inactive accounts compromised in as many days it should be abundantly clear that this is needed. The policy will still be quite lax. Beeblebrox (talk) 23:46, 23 November 2018 (UTC)
  • Support - There are too many Admins gaming the system by making one edit a year to keep hold of their Admin bit when notified, and not making one Admin action for several years. It is about time we use common sense and stop this charade. JMHamo (talk) 00:23, 24 November 2018 (UTC)
  • Oppose When I first started reading I was intending to support. However, after reading some comments above, specifically Cryptic's about there still being a very easy loophole to keep the tools. The only counter to that is not telling admins that there tools are about to be yanked might work the first time, but, after that it won't be difficult to add a yearly reminder to create then speedy delete a userspace page. This would be especially easy to circumvent if edits to protected pages count as admin actions for this proposal, as one edit per year is still all that's required, it'd just need to be to a protected page instead of any page. Perhaps it might be better to increase the number of edits and/or logged actions are required to keep the tools. Callanecc (talkcontribslogs) 01:04, 24 November 2018 (UTC)
  • Support - Per nom, remove irresponsible "gaming the system" and just plan account security. - FlightTime (open channel) 02:44, 24 November 2018 (UTC)
  • Support The comments about unlogged admin actions, moral panic, and suggestions of how an admin could game the system miss the point which is that reducing the attack surface is the first principle of security. That's all. Unlogged admin actions can be solved with a cratchat to establish an exception for a particular case. Concern about biting inactive admins can be solved by crafting a good message thanking them for their work and letting them know they can easily regain the right. That process should emphasize the need to have a unique password. Almost certainly the hacking of several admin accounts in the last couple of years was done by people matching the list of admins with lists of user accounts hacked on other websites and finding cases where the hacked password was reused at Wikipedia. Admins who are genuinely active are much more likely to have thought about security and we can hope they use a unique password. Johnuniq (talk) 03:03, 24 November 2018 (UTC)
  • A further suggestion: how about not calling it "desysopping", but something like "suspension of administrative rights"? The admin in question is not being removed from the administrator corps, and can continue to do all the same administrative actions as before that do not require administrative rights (including deciding not to take any actions). Should the admin wish to take an action that requires the administrative rights, an extra step of requesting that administrative rights be re-enabled is needed. isaacl (talk) 03:21, 24 November 2018 (UTC)
  • Support This is a political question, and I'm strongly in favor of there being more situations where admins have to say hello at WP:BN after a moderate duration absence from regular activity, or re-RFA after a longer one. I do agree with the concerns that editing the various full-protected transclusions of the Main Page should be tracked as admin actions for inactivity measurements if this is implemented; the case that an editor only edits other full-protected pages is unlikely enough to be ignorable. power~enwiki (π, ν) 03:30, 24 November 2018 (UTC)
    I must note that I don't see the security concerns as a good reason to support this, though it's a plausible excuse to re-start this perennial discussion. A more effective way to handle security concerns would be to inform all admins who haven't changed their password since 2013 that they have 30 days to change their password to one that meets security guidelines, or they will lose their admin privileges. Simply reducing the number of admins does nothing good (I concede we could completely avoid the risk of hacked admins by having no admins at all); this proposal acts as a (weak) proxy for reducing the number of admins who have insecure accounts, which is what is needed. power~enwiki (π, ν) 03:30, 24 November 2018 (UTC)
    Is there a way to force password change, maybe in LocalSettings.php, say every 90 days or whatever span of time ? - FlightTime (open channel) 03:47, 24 November 2018 (UTC)
    I note you're both making an assumption that passwords created in 2013 or earlier don't meet current security guidelines, or assuming that the security guidelines should include mandatory password changes. You may want to read [] about the latter. (P.S. Yes, mw:Manual:$wgPasswordExpirationDays exists) Anomie 15:49, 24 November 2018 (UTC)
I'm no assuming anything, I was merely asking a question. - FlightTime (open channel) 23:25, 24 November 2018 (UTC)
  • I don't assume that all early passwords are weaker, but I believe the software-enforced minimum password strength has increased over time (if you believe all the comments here, at one time 1-character passwords were allowed, and that certainly should not be allowed). Forcing everyone to do a one-time password rotation might be a better option. I don't support a mandatory 90-day expiration period; in my professional experience in the technology industry rotation periods of less than 1 year are almost always harmful in improving security. power~enwiki (π, ν) 16:15, 24 November 2018 (UTC)
  • Oppose - As others have said, there are admin actions which are not logged. There are a lot of permissions in the admin toolkit, and most are not logged, and many are of indirect, rather than direct use. This has been stated in every one of these discussions. that fact hasn't changed. Plus there are things admins do which require access to certain tools, but which may not need their actual usage in that specific instance. Such as closing a deletion discussion. Also, we prefer admins to embody restraint in regards to tools. This sort of proposal will just cause people to think they shouldn't act with restraint. And besides that, we'll start seeing logs bloat with barely accountable actions. Want an example? Handing out rollback is something an admin can do. And hey, it's even logged! So every admin just goes and gives rollback to someone. And to really make it fun, give rollback to an inactive admin... Tell me what's been solved? And finally, the moment an admin account has been compromised, wouldn't the compromiser immediately do an admin action? And so wouldn't that pretty much void the justification for this proposal? This may be a well-meant proposal, but it just really is a bad idea. - jc37 04:38, 24 November 2018 (UTC)
  • Support - Given recent events, this proposal is more than necessary. A year without a logged action is an enormous window, and any affected admin can just pop over to WP:BN and ask for the bit back. Nathan2055talk - contribs 05:23, 24 November 2018 (UTC)
  • Strongest possible oppose Does it ever occur to you that not all of us have smartphones and never plan to have them, so not all of us have the option of 2FA? I don't really have an opinion on changing the activity requirements, but don't take away my user rights as long as I'm using them in a proper fashion. Period. Nyttend (talk) 05:45, 24 November 2018 (UTC)
    Nyttend, 2FA isn't actually part of this proposal. I apologize for my earlier comment conflating the two ideas, but this is only about the activity requirements. Bradv 05:47, 24 November 2018 (UTC)
    And 2FA doesn't need a smartphone anyway - there are 2FA apps for computers too. Boing! said Zebedee (talk) 08:15, 24 November 2018 (UTC)
  • Support. - There are a few pretty egregious individuals, basically NOTHERE administrators, if you will, who do a couple bland edits a year to retain tools. We need to get a handle on how many or few administrators there actually are, and these phantoms impede an accurate assessment. Carrite (talk) 07:57, 24 November 2018 (UTC)
Just wondering - what's wrong with that? --The Cunctator (talk) 15:17, 4 December 2018 (UTC)
  • Support. As others have opined, if you're not going to use the admin tools then you shouldn't have them. And it's easy enough to restore the bit to someone who is genuinely going to use it. I'll just add that my opinion is not related to the recent hacks, it's a view I've held for a long time. Boing! said Zebedee (talk) 08:18, 24 November 2018 (UTC)
  • Support disabling inactive rights is basic risk management in any it organisation. Doing one or two dummy edits a year is WP:GAMING of the inactivity rule and shouldn't be encouraged. --Pudeo (talk) 09:04, 24 November 2018 (UTC)
  • Agree that gaming the system is a problem. Disagree with the proposed solution to the problem of not notifying the inactive admin. The right way to deal with this is like we do with 3RR: an editor who repeatedly waits until just after the 24 hours is still treated as an edit warrior. Likewise, we can treat any pattern of dummy edits that are clearly designed to avoid the inactivity rules as we would treat any other inactivity. --Guy Macon (talk) 09:41, 24 November 2018 (UTC)
  • Support any proposal to tighten admin standards and accountability. feminist (talk) 09:55, 24 November 2018 (UTC)
  • Oppose This proposal as drafted risks exacerbating a bigger problem than it seeks to address. Our problem of admin retention is much much more serious than any problem that the current proposal is hoping to mitigate, and auto desysopping makes Wikipedia less welcoming for returning admins. I would be more relaxed if this was a more nuanced reform with the period of time that old admins could return after increasing and the introduction of a meaningful test for such returnees. For example one day of renewed activity (not necessarily contiguous) per year of absence, up to a maximum of ten years since being desysopped for inactivity. That would give the community a reasonable chance to assess if the returnee had remembered/refreshed and updated themselves about Wikipedia, and showed enough commonality and experience that they were likely the same person. ϢereSpielChequers 13:43, 24 November 2018 (UTC)
  • Why do we need to retain an admin who performs 1 admin. action a year? They are not productive in any meaningful way and simply inflate a headline Admin. count which does not reflect true productivity in anyway. Rather like many of the stats. you churn out from time to time, it is a meaningless total when a large number do next to nothing. Leaky Caldron 14:27, 24 November 2018 (UTC)
  • Actually I'm not interested in retaining as admins those who only ever do one or two admin actions a year. I'm interested in retaining and keeping an open door for formerly active admins who might become active admins again in the future. such as retaining/reactivating more of the formerly active admins who return here after long periods of time. The problem is that once someone has dropped to a very low or zero level of activity we currently have few tools to tell who might return in the future and who will never return. So I've no problem assuming that those who have died won't be back, but with the project not quite 18 years old we have no way of knowing how many adolescents who go inactive after less than a decade of activity will return once they have retired, or before. We don't yet have anything close to a figure such as "after x years of inactivity the chance of return approaches zero". ϢereSpielChequers 17:07, 24 November 2018 (UTC)
  • Support This is a simple, non-punitive way to keep our admin roster at least a little bit up to date. Powerful tools should not be attached to inactive accounts, that's all. If people aren't using WP at all, they should not have admin tools. If they are only logging on once a year because they got an email warning, they should also not have admin tools. I agree with the proposal as written, with the one addition that a note should be put on their user talk page, AFTER the desysop, explaining what happened and why, with the assurance that it is just a security measure and does not reflect any wrongdoing on their part, and they can get their tools back via a simple request at BN. -- MelanieN (talk) 15:23, 24 November 2018 (UTC)
P.S. I very much like Isaacl's suggestion that such action be called "suspension of administrator rights" rather than "desysop". -- MelanieN (talk) 15:31, 24 November 2018 (UTC)
  • Oppose the wording as written above. There are plenty of times where I have been an active administrator even though I didn't use "logged administrative actions". Especially when I'm engaged at WP:AE, my preference is to do unlogged actions such as warnings, rather than blocks. I'm not opposed to tightening up the policy in other ways, like if someone has fewer than 10 edits per year, that might be reasonably viewed as inactive. Then again, if those edits are at administrator pages such as WP:ANI, WP:AE, comments at ArbCom pages, or anything in the Wikipedia space (as opposed to user/article pages), then I would see that as being more active. --Elonka 22:25, 24 November 2018 (UTC)
  • Support, sans 2FA and with the "suspension" wording. I've thought about this very carefully, particularly because I take the oppose comments by Risker and Opabinia very seriously. And I would be opposing if, hypothetically, the proposal were to require a new RfA. But posting a message at BN and waiting 24 hours – that's hardly a burden. I do agree with Ivanvector's analysis of partially reducing security risks (no need to let the perfect become the enemy of incremental improvement), and also with the view that we really expect active admins to be able to easily satisfy the revised requirements. Wikipedia is simply not the website that it was a decade ago. In some ways, we should expect more "professionalism" from all editors, but certainly this isn't an imposition on those users who want to have advanced permissions. --Tryptofish (talk) 22:46, 24 November 2018 (UTC)
  • Support - Regardless of the recent activity, this would be a good policy. "Retaining" admins who do not participate isn't retention.Onel5969 TT me 23:18, 24 November 2018 (UTC)
  • Oppose per Dweller. Kaldari (talk) 00:46, 25 November 2018 (UTC)
  • Weak Support As the incident involving Killiondude demonstrated, this can happen to anyone, and isn’t only limited to inactive admins. I support this only for the fact that it might be a more effective deterrent to a black hat trying to get access to vulnerable admin accounts. OhKayeSierra (talk) 01:03, 25 November 2018 (UTC)
  • Support tightening desysopping (or "suspension") rules though there is probably a better way to get around admins who may attempt to "game the system" by speedying a bullshit page they create in their userspace so they've technically logged an "admin action". Of course, if an admin just wants to keep the tools for fun rather than to use them constructively to improve the project, it reflects poorly on their suitability for having the bit in the first place, not to mention the security concerns discussed many times above. IntoThinAir (talk) 01:40, 25 November 2018 (UTC)
  • Support The potential for an admin who performs non-logged actions being de-sysoped is a non-starter for me. All it takes to stop that from happening is to do a 2-minute drop-in at requests for page protection once a year. The amount of time expense to do that is less than the amount of time expense to clean-up after a compromised account. Chetsford (talk) 05:26, 25 November 2018 (UTC)
  • Strong Oppose - I find the removal of a notification requirement to be a non-starter and contrary to our basic principal that someone should be notified before an action is taken against them. If someone is inactive, it does not mean that they will not come back nor that they cease being a member of the community. As someone who tends to come and go (and is also an admin) even if I'm not fully active at a given period, I do make occasional edits, maintain a strong, secure, and unique password, and see all messages (via notification and email) especially because I run a few bots. Further, the requirement for a "logged administrative action" as opposed to just editing seems to go against the spirit of us being here to build an encyclopedia and the goal that the appurtenant bureaucracy should just be ancillary. If someone is editing without using the tools it does not make them any less trusted or capable of using them responsibly them when they do need to use them. Further, administrators can, and do, add value by helping at WP:DYK (where I personally do quite a bit of work), WP:EDITREQ, and in other places where the tools are of value or essential even if their use is not formally logged. Finally, I agree with Risker's comments above and do not believe that this will meaningfully increase security. If we want to increase security, the strength of your password, it not being reused elsewhere, and 2FA (current technical issues and lack of support notwithstanding) are much, much more important to look at than activity. Regretfully, it looks like the group targeting admin accounts has enough sophistication to understand a bit of our inner workings, if an outside actor were to compromise a highly active admin account (as has happened before), all they would need to do is wait for the user to be offline or asleep to act. Our default edit counter (shown at the bottom of each user's contributions page) even has a "timecard" feature (see here for mine) which graphically shows a time distribution of your edits. Even if we were to disable this feature, it is not hard to figure out when I, or any other user, is almost never online. While I strongly agree account security, especially for accounts with advanced permissions, is essential, I cannot support this as I do not believe it helps us move towards additional security and am deeply concerned it could drive away valuable and respected editors and make it harder for them to return (similarly as Dweller pointed out above). Best, Mifter (talk) 06:27, 25 November 2018 (UTC)
  • Weak Oppose I want a solution that 1. fixes this problem and 2. doesn't feel punitive to good-faith admins who for whatever reason are inactive for a while. I'm not sure this proposal does either of those things. If we want to prevent hackable accounts causing problems, require ALL admins to change their password regularly. And is there any way to show on the password reset page the results of that little handy tool Guy Macon links to below? If admins are told when they reset their password how hackable their password is, and just how attractive a target WP is, I would assume good-faith admins would go ahead and create an unhackable phrase rather than coming up with yet another version of pa55w0rd. And if after that they still do create a crap password and get hacked, THEN they get punished lol valereee (talk) 12:21, 25 November 2018 (UTC)
  • The tool at [] might be a better choice. That checker is The code is licensed under the GPL, so we are free to use it. --Guy Macon (talk) 16:33, 25 November 2018 (UTC)
  • Support. Inactive bits must be frozen. But given the number of administrators who are not convinced that security issues could be more than a "set-up to thwart Ivanka" ... we will probably have to wait for a big drama, followed by panic countermeasures imposed by SanFran. Pldx1 (talk) 14:43, 25 November 2018 (UTC)
  • Support. I would want admins to be actively using their tools, but I disagree "logged actions" being the cut-off. Instead, I would want to extend this to any activity that could not be performed by a non-admin. I would want to have a notice given for admin accounts that are performing edits on a semi-regular/regular basis for the impending removal of rights, but for completely inactive accounts the notices seem unnecessary. Only providing notices to accounts with more than just a couple of edits a month would help to circumvent the problem of admins hogging their admin privileges when they are inactive. Dreamy Jazz 🎷 talk to me | my contributions 16:52, 25 November 2018 (UTC)
  • Oppose. I have been an admin for over ten years. I am an active editor; I'm on pretty much every day. My understanding always was that admin privileges are intended to be used sparingly. I try to warn vandals rather than block and I don't waste effort blocking IP accounts that appear to come from public terminals in schools. Usually after being warned and reverted a couple of times vandals just go away. I try to help settle disputes where I can and that often makes me an "involved editor" so I sometimes have to rely on other admins if my efforts fail and blocks are needed. A few times when I did use my bit, it just made a bad situation worse. Nonetheless, there are times when I do use it and often having to wait for permission to get it back would allow damage to persist too long. I would not object to tighter authentication requirements for admins, perhaps re-authentication when the bit is used after an absence from editing (rather than relying on "keep me logged in"). But I don't think admins who are active on the project should be incentivized to use their privileges any more than they deem necessary.--agr (talk) 17:35, 25 November 2018 (UTC)
  • Support If you do not use your administrator rights you do not need them but i oppose the requirement of 2FA as not all admins have phones and the way Wikipedia uses 2FA has issues Abote2 (talk) 22:20, 25 November 2018 (UTC)
  • Oppose. Wikipedia is becoming more punitive. People should always be notified when things are planned that affect them. There seems to be a trend toward trying to make people do things in a particular way or in a particular time frame recently. I contend that this attitude is driving users away. As a volunteer organisation we should be doing everything we can to retain and encourage users. Also rushing to change policy in reaction to a specific situation is never a good idea. Morgan Leigh | Talk 22:28, 25 November 2018 (UTC)
  • Oppose. This is security theater. We are going to have compromised accounts and do need processes in place to prevent it, mitigate the damage, and allow recovery. The reduction in the size of the attack surface that would result from this policy change is simply not significant, and the consequences for editor engagement over time are considerable. The Uninvited Co., Inc. 00:22, 26 November 2018 (UTC)
  • Conditional support on the condition that any former sysop who hasn't fallen short of the 3-year lengthy inactivity rule can regain the sysop flag anytime via WP:BN. In other words, I would support this proposal for as long as it only removes the technical permission of an admin who still edits occasionally but hasn't used any admin privileges, but retains the policy permission for those admins to regain their technical permission whenever they need it back. Also strong oppose requiring the current implementation of WMF 2FA per diversity issues raised by Risker et al and the technical issues raised on phab:T172079. Deryck C. 16:05, 26 November 2018 (UTC)
  • Strong Oppose -- This won't solve any problems. Just see the recent temporary desysop of Killiondude. The account was compromised and the real editor had edited the day before. I would much rather see an actual activity requirement of say 25 logged actions per year (edits; blocks; user right changes; whatever). -- Dolotta (talk) 16:47, 26 November 2018 (UTC)
  • (edit conflict) Support the bit can be returned on request. There shouldn't be mandatory 2FA for all admins, as it might be too difficult for some. Besides, how would one get 2FA before, since if I recall users without advanced rights (admin, CheckUser, oversight, etc.) can't use 2FA. SemiHypercube 16:51, 26 November 2018 (UTC)
  • Support -- as long as it is easy enough to reinstate in extenuating cases (which seems to be the case here) no harm no foul.--Esprit15d • talkcontribs 00:02, 27 November 2018 (UTC)
  • Strong Oppose, ah, here we go yet again down the slippery slope. I've always seen admin activity requirements as unhelpful for a number of reasons, including but not limited to the effect that this would have to de-diversify the admin population, effectively shutting down the possibility of adminship to those who may not have reliable secure internet for long periods--military deployment, missionary work, humanitarian aid, and the like. Not even requiring notification adds an addition slap in the face for those who frankly have donated a lot of their free time to the project already. Andrew Lenahan - Starblind 18:54, 27 November 2018 (UTC)
  • Oppose – Right spirit; wrong proposal. Normal edits should count toward admin activity, since by editing actively, admins, who are of course all virtuous and knowledgeable, can show by example so admin actions don't have to be performed. Inform people that the bit is about to be taken away, especially because real admin activity, such as DYK actions, aren't even being counted. However, I'd make the activity requirement higher, like average one action a day, not a year. How does someone who does less vandal fighting in a year than I'm apt to do in a day get to keep their key to the executive broom closet? Dhtwiki (talk) 07:47, 28 November 2018 (UTC)
  • Support but I agree with Dhtwiki that this should just be about keeping your account active in general, not about making demonstrably 'admin' actions. To me, the point of de-sysopping inactive admin accounts is to maintain security of an account that has no one on the other end of it. If an administrator is active in any way, that means he or she is logging in regularly, (hopefully) changing the password and keeping it secure, etc. If we want to de-sysop an otherwise active sysop for lack of admin-specific activity, that's fine, but we should be doing so for all advanced permissions and separately from this proposal. CThomas3 (talk) 19:53, 28 November 2018 (UTC)
  • Oppose both requiring logged admin actions and the removal of the notice requirement. While I understand the concerns, I don't think that they outweigh the problems of tracking unlogged admin actions (I think of closing AfD's as "No Consensus" as a good example) and the discourtesy of finding your account deadminned unexpectedly even when you have been making regular if infrequent contributions to the encyclopedia. I probably came close to a year without logged actions when I was an admin, and I would have hated to have lost the bit without even a warning. Eluchil404 (talk) 23:08, 28 November 2018 (UTC)
  • Support the first part. I don't, however, see a defensible rationale to deleting the notice/contact provisions.  — SMcCandlish ¢ 😼  12:44, 1 December 2018 (UTC)
  • Oppose. I see the problem, but this is too extreme. I might support some more complex formula such as (<n admin actions in last 12 months, and <n admin actions in last 2 years), but I'd prefer to see some human discretion applied, partly to avoid setting a target for the hat collectors. Any numerical threshold risks encouraging hat-collecting admins to make un-needed admin actions simply to game a threshold.
Most of my admin actions involve editing protected pages, and AIUI those are not logged as admin actions. Unless they are included in the total counted, the numbers will be misleading.
And I strongly oppose mandatory 2FA. I am sure that I am not the only admin who is a smartphone refusenik (a phone which needs to have a "phone" button pressed before it can be used as a phone is a portable identity crisis which I don't need in my pocket; plus my fossil-phone is way cheaper, more robust and has a 1-month-on-standby battery life) .. and 2FA basically relies on having a smartphone. Instead, I change my password frequently using my own obscure formula, and I would support an enforced requirement for non-2FA admins to change password every 3 or 6 months or so. --BrownHairedGirl (talk) • (contribs) 04:01, 3 December 2018 (UTC)
  • Support. All users are responsible for securing their accounts. Accounts with sensitive privileges should be subject to additional security measures to reduce disruption to Wikipedia. Disabling inactive privileges and requiring two-factor authentication are measures that are widely implemented in companies with strong computer security policies. As the fifth-most-popular website in the world, Wikipedia is more important than many of these companies, and should tighten its security to prevent embarrassing breaches like the ones from last month. — Newslinger talk 04:57, 3 December 2018 (UTC)
  • @Newslinger: Wikipedia is not a company, and cannot be run like one. Its editors and admins are a much more diverse set, and your comparison seems to assume that en.wp editors have the same sort of access to resources as an employee of a major tech company.
Its editors are unpaid and receive no equipment from Wikipedia. They may not own a computer, and do their editing on someone else's machine or on some sort of public computer (e.g. library, school, university, work, housemate, family).
So any requirement which presumes ownership of particular equipment merely reinforces the already-massive systemic bias in en.wp's admin base, and erects a further barrier to editors on lower incomes, editors from remote areas or developing nations, editors with disabilities etc. --BrownHairedGirl (talk) • (contribs) 07:40, 3 December 2018 (UTC)
Two-factor authentication doesn't require any additional equipment beyond what is needed to edit articles on Wikipedia. If an editor can run a web browser or a Wikipedia app on their own device, then the editor can also run a free authenticator app (list) or password manager (list) on their device (regardless of whether it's a desktop, laptop, or smartphone). For editors without their own devices, there are web-based password managers (such as KeeWeb) that also provide two-factor authentication at no charge. — Newslinger talk 08:54, 3 December 2018 (UTC)
  • @Newslinger: there may indeed be workarounds for the tech-savvy. But those workarounds increase the technical burdens on admins who are mostly chosen for their editorial judgement and understanding of policy, rather than for technical skills.
You really don't seem to get my point that Wikipedia is not a company and its editors and admins are not employees. This is a wholly different sort of organization, and these attempts to import corporate processes don't recognize that crucial distinction. I know some truly wonderful editors who would make brilliant admins, but who are so non-techie that they only ever use the visual editor. They would run a million miles from the complexity of 2FA, but they precisely the sort of people whose social and editorial skills are much needed in the admin corps. I would love to see more of them becoming admins; the role should not be the sole preserve of tech-heads. --BrownHairedGirl (talk) • (contribs) 09:07, 3 December 2018 (UTC)
I made the "company" comparison to show that Wikipedia's security practices are weaker than those of less important organizations. This was not an assertion that Wikipedia is like a company, or that its editors and admins are like employees. In my opinion, two-factor authentication is much easier to learn than wikitext, and is a reasonable requirement for sensitive privileges on a very important website. — Newslinger talk 09:34, 3 December 2018 (UTC)
Newslinger, comparisons with a company have led you down a path where you are applying inappropriate measures of reasonableness, and looking at the perceived importance of the organisation rather than the extent of potential harm and the impact on users. Please do not underestimate the extent of the barrier which is placed in the way of many very productive editors and admins by technical measures which a tech-savvy person like yourself would find trivial.
As a voluntary group, en.wp editors include very many people who would never be remotely acceptable to the personnel depts of any corporate. Their contributions are valuable, and their needs are very different to those of a corporate employee.
Most of the potential for damage has been removed by [], which prevents a blocked admin unblocking themself. A hijacked admin account can now be securely blocked until the issue is resolved.
And do remember that this is "the encyclopedia which anyone can edit". Our security is social rather than technical. --BrownHairedGirl (talk) • (contribs) 11:29, 3 December 2018 (UTC)
  • Oppose. Tweaking the activity requirements every time someones account with bad password gets compromised is just security theater. Also strong oppose requiring the immature WMF 2FA per diversity and editor retention issues raised by Risker, Andrew Lenahan and others, and the technical issues raised on phab:T172079. jni (delete)...just not interested 06:27, 3 December 2018 (UTC)
  • Oppose, forcing admins to have logged actions and not telling them they have forgotten to do so doesn't strike me as helpful. It is trivial to fulfil the logging requirement (delete and undelete your sandbox) so this is useless as a measure of activity. And anyway, what jni says. —Kusma (t·c) 11:18, 3 December 2018 (UTC)
  • Oppose, hard cases make bad law. Stifle (talk) 15:20, 3 December 2018 (UTC)
  • Oppose - per Risker, pretty much. Also, I'll join the list of people opposed to compulsory 2FA, at least while using it requires people to retain one-time keys indefinitely. The Land (talk) 15:40, 3 December 2018 (UTC)
  • Strong support. Best proposed modification to this policy in quite some time. As usual the opposition is a storm in a teacup around something that will pose no threat to the project's operations. It will on the other hand shut down the yearly charade performed by people who have no good reason to continue calling themselves administrators.  — Scott talk 15:48, 3 December 2018 (UTC)
  • Strongly oppose: this doesn't reduce risk, per Risker, so it's pointless. It's also counterproductive. We need more experienced admins, not fewer, and admins are usefully so even without logged actions. Much of what we do as admins isn't logged. Jonathunder (talk) 02:24, 4 December 2018 (UTC)
  • Oppose A solution for a nonexistent problem. We need more admins not fewer. Λυδαcιτγ 09:57, 4 December 2018 (UTC)
  • @Jonathunder: Believe it or not I wrote that before noticing your comment. Great minds, eh? ;-P Λυδαcιτγ 09:58, 4 December 2018 (UTC)
  • Oppose I don't use my admin abilities that often, much less frequently than I edit. And I am one of the most experienced admins on Wikipedia. Does reviewing deleted edits count as an administrative action? Other people have made excellent points in opposition about the broader implications. --The Cunctator (talk) 15:15, 4 December 2018 (UTC)
  • Mildly oppose the 12 month limit. Deactivation of inactive accounts must be done somehow (and BTW, we need to think about reusing user names, if we do not already; if WP last for decades I hope someone will be the next Nabla :-). But legislating in a hurry is bad (as Risker said), the rule is too simplistic, and no warnings feels like punishing. Strongly Oppose 2FA, when it came up I gave it a look, it was almost impossibly convoluted, wikipedia is less and less a wiki (as in easy to edit) let's not make it something only for the special ones. Note I am an almost inactive admin, I edit once in a while, I have made none or almost none administrative action in the last ya«ear or so, mostly because I went back to college so I *am* busy. I have been considering temporary resigning, because I do not want to fool the statistics; and I would not mind a *friendly* reminder in that sense, but this is not it at all. - Nabla (talk) 23:02, 4 December 2018 (UTC)
  • Support, but strongly Oppose mandatory 2FA. Kudpung กุดผึ้ง (talk) 02:15, 5 December 2018 (UTC)
  • Support As an editor and former admin who has returned to the project very recently, I was initially surprised to find that administrative work had become a "very big deal," mostly on the basis of these identity hacks. So, I have to support any resolution which would seemingly improve the security of editors in general and admin accounts particularly. In that many of the identity hacks have been perpetrated by inactive admin accounts, I should thank @xeno in this space, for his diligence in deactivating my account when he did. I should also note that as far as editing the project, I don't miss the extra tools very much at all. I think See Recent Changes would be useful to me as I could be doing more cleanup editing. Most of you are doing excellent work, and it is appreciated by me. Hamster Sandwich (talk) 04:22, 5 December 2018 (UTC)
  • Oppose If they aren’t active enough, they wouldn’t even know they got a admin revoke. No-go. We should get a better criterion to keep adminship, for example 100 admin actions and 500 edits in a year, etc.. Oshawott 12 ==()== Talk to me! 12:44, 6 December 2018 (UTC)
  • Oppose Ugh, no just no. Whispering(t) 15:48, 6 December 2018 (UTC)
  • Oppose. Airbornemihir (talk) 10:44, 7 December 2018 (UTC)
    The case of Revolving Bugbear is somewhat pertinent here. I'm really not fond of the way they were singled out for attention, and specifically asked to "at a minimum" justify their retention of the administrative toolset. I think that's an undue "minimum" ask to make. I also disagree with the judgement call to remove their permissions after their ambivalent-at-best statement at the bureaucrats' noticeboard. This proposal is trying to codify the same kind of judgement call on an automatic (or semi-automatic, since it's done by individual bureaucrats, not software) basis, hence I am opposed. I note the amount of tedious work made for admins, and the harm done to the 'paedia, when an admin account is compromised. I would suggest searching for another solution to solve that problem. Airbornemihir (talk) 19:39, 7 December 2018 (UTC)
  • Oppose per Risker. -- Tavix (talk) 19:17, 13 December 2018 (UTC)

Questions about admin actions that are not logged as such

  • Comment - In theory, I support tighter guidelines on whether or not an admin is really making use of their tools. However, as pointed out above by Jo-Jo Eumerus and others, there are certain actions that require admin access, but are not logged as admin actions. DYK is a prime example, as some editors have become admins specifically for helping out on that project. There are some admins I see using their tools at DYK, and don't run across them elsewhere, but are vital to assisting that project. Devise a tool that logs ALL admin usage of tools, and I might be more willing to support this. — Maile (talk) 19:50, 22 November 2018 (UTC)
    DYK has come up a couple times. I'm not so familiar, but what do admins do at DYK that requires admin access but isn't logged? IMO it should be logged, or it should not require admin rights. Ivanvector (Talk/Edits) 19:58, 22 November 2018 (UTC)
    They use editprotected. --Izno (talk) 20:01, 22 November 2018 (UTC)
    Ah I see. Surely we could (should?) log edits to protected pages? Maybe that's a separate discussion too. Ivanvector (Talk/Edits) 20:10, 22 November 2018 (UTC)
    @Ivanvector: technically they are already logged, just not in any manner that is easy to find. Obviously "group" edits (like MediaWiki:, .json files, etc) are easy to filter, but the other ones are not. I wonder if this is a red herring though (i.e. how many admins are completely inactive in all logged actions but still routinely use editprotected?) — xaosflux Talk 20:43, 22 November 2018 (UTC)
    Does it require admin tools to create and maintain bots and scripts? That's also a key part of DYK. — Maile (talk) 20:37, 22 November 2018 (UTC)
    I don't believe so, I think anyone can operate a bot if it's approved, unless it's a bot with admin rights. Scripts might require interface admin now, I'm not sure. Ivanvector (Talk/Edits) 21:08, 22 November 2018 (UTC)

The last 10 humans, and the operator of the last bot, to edit Template:Did you know, made their most recent logged admin action this long ago:

Admin Last logged
admin action
Days ago
Alex Shih 2018-11-18 4
Anarchyte 2018-11-22 0
Art LaPella 2018-07-13 132
Shubinator (operator of DYKUpdateBot) 2018-03-26 241
Dumelow 2018-11-05 17
Fish and karate 2018-11-21 1
Fram 2018-11-22 0
Gatoclass 2016-09-22 791
Huon 2018-11-21 1
Mike Peel 2018-11-09 13
Vanamonde93 2018-11-19 3

As you can see, Gatoclass is the only one who would lose their adminship with this proposal. Thryduulf (talk) 22:51, 22 November 2018 (UTC)

Thryduulf of the ones you list above, Shubinator is unique in that his bots keep the process running. He's the only one who would know what admin actions he's taken that don't show on his normal logs - but I think DYK would be up a creek without him behind the scenes. You don't list Wugapodes, and his logs look pretty active, but he operates WugBot that is also essential to the DYK processes. The others are directly involved in the edit protected areas of DYK that directly affect what appears on the Main Page. — Maile (talk) 01:34, 23 November 2018 (UTC)
I believe I wasn't listed because I'm not an admin, only pending changes and (recently) new page reviewer. WugBot doesn't have editprotected rights and doesn't need them as the approved page isn't under full protection, just the Queue for the mainpage. Wugapodes [thɑk] [ˈkan.ˌʧɹɪbz] 02:47, 23 November 2018 (UTC)
  • Regarding the questions about logging, while it's not as easy of a log, we could make an edit filter such as ((action = edit) & (page_restrictions_edit = sysop)) to "log" protected edits such that they could be "counted" by any inactivity bots (which really is how we would look for inactives in practice). — xaosflux Talk 05:28, 23 November 2018 (UTC)
  • Example of logging the use of protected edits. — xaosflux Talk 12:55, 23 November 2018 (UTC)
Although my understanding of logging administrator actions is dim, I believe I could have been desysopped for one year of miscalculated inactivity from Sept. 15, 2014 to Sept. 25, 2015, and also Sept. 26, 2012 to Apr. 22, 2014. That's logged actions only. Realistically, I'm far from inactive; I proofread everything on the Main Page, not just Did You Know. So it isn't just Gatoclass. But if you'd rather fix typos without me, my business could use more attention. Art LaPella (talk) 06:03, 23 November 2018 (UTC)
  • This is another example of a fully protected page which requires editing by administrators on a regular basis.--Ymblanter (talk) 07:55, 23 November 2018 (UTC)
  • The fact that just in the last 10 admins to have processed a DYK already 1 of them would be removed means that clearly DYK is a necessary tagging. In preference, any edit of a protected page should also count. Nosebagbear (talk) 13:46, 23 November 2018 (UTC)
  • So, if I'm understanding correctly, the only admin action we've identified so far as definitely an admin action and definitely not logged is edits to protected pages, yes? Let's set up a log for that. I don't think anyone here yet has said we shouldn't, and lots of us have said we should. Ivanvector (Talk/Edits) 14:50, 23 November 2018 (UTC)
    @Ivanvector: I'm working on one (Special:AbuseFilter/942) - there is another admin action that isn't logged at all: viewing deleted versions. Note, those 'actions' are not currently counted toward activity. — xaosflux Talk 14:54, 23 November 2018 (UTC)
I saw that filter you're working on, it looks good so far. As for viewdelete, are there really that many admins that only look at deleted pages and do nothing else? Ivanvector (Talk/Edits) 15:02, 23 November 2018 (UTC)
Indeed, while you can have admins look just to answer individual's questions (why was it deleted etc), usually I'd expect it to be associated with one of:DELREV, CSD, Salting/Unsalting, copyvio, block discussions. Nosebagbear (talk) 15:21, 23 November 2018 (UTC)
I mean I'm sure there are cases where you just look at a deleted page and then do nothing else. But does anyone only look at deleted pages, but never do anything with them, or any other logged actions? That seems unlikely to me, but then again I was wrong about DYK and editprotected, so as it turns out I don't have all the answers. Ivanvector (Talk/Edits) 18:25, 23 November 2018 (UTC)
Personally, I feel viewing a deleted page to be something that an administrator is authorized to do, but not an administrative action in itself. Using the knowledge gleaned from this to weigh in on a discussion would be an administrative action. However I don't see any way to log this automatically. isaacl (talk) 23:17, 23 November 2018 (UTC)
  • Also noting that I oppose counting non-logged admin actions that is next to impossible to track after the fact. Seriously, it really isn’t that difficult to do one completely non-controversial logged action a year, and handwringing over something that is easily reversed and can be easily fixed for a year isn’t justified, especially given the extra work that would be required. I would support keeping the one year notice, though. TonyBallioni (talk) 22:35, 23 November 2018 (UTC)
  • It does appea that DYK is the single exception where an admin is actually doing useful admin work without logging any actions. As demonstrated above thsi would impact only one single admin's rights. That doesn't seem sufficient cause for not doing this, we can just IAR for that one admin. Beeblebrox (talk) 02:09, 24 November 2018 (UTC)
    At least two admins. And probably Shubinator. And it's the complete Main Page, not just DYK. Art LaPella (talk) 03:49, 24 November 2018 (UTC)
    I actually provided another example in this very thread.--Ymblanter (talk) 08:24, 24 November 2018 (UTC)
  • I think that one of the most valuable things that administrators do is say no....say no to blocking someone, say no to protecting a page, say no to deleting... And yes, there's lots of work happening in places like Arbcom enforcement and even admin noticeboards by admins who don't need to take logged admin actions in order for them to be effective as administrators. If someone is actually around and doing things, it really doesn't matter whether or not they're doing logged admin actions. I will make a proposal above. Risker (talk) 02:17, 24 November 2018 (UTC)
    • But do you think it is reasonable for an administrator to say no to literally everything? All they have to do is say yes one time (or however many actions the limit is determined to be). If we have a sysop that is saying no to every request, I would find it very hard to believe it is not a WP:POINT situation, and they should not be an admin anyway. Natureium (talk) 13:46, 24 November 2018 (UTC)
  • As I understand it, there is currently no logging of the use of admin accounts to view deleted edits. This is one of my most common uses of the tools, for example in checking out a candidate or potential candidate at RFA. I'm actually a little uncomfortable about the idea of an admin account quietly lurking and occasionally being used to view deleted edits, but we have in the past had a very active nominator who made little or no use of the tools apart from viewing deleted edits. So I would welcome some sort of log that at least recorded when an admin had last looked at deleted edits, provided it didn't log what specifically they viewed. ϢereSpielChequers 13:32, 24 November 2018 (UTC)
    I've created a AF log for "protected edits" that can be seen here: Special:AbuseFilter/942 - a 'viewdelete' log would require software changes so its a bit hard. For example @WereSpielChequers: can you point out any specific admins who have gone a year with no protected edits, no logged actions - that you think are still using viewdelete usefully? — xaosflux Talk 15:52, 24 November 2018 (UTC)
    Great, thanks.--Ymblanter (talk) 16:09, 24 November 2018 (UTC)
    @Xaosflux Thanks. As I said we had an active nominator in the past who as I remember it had not otherwise used the tools for some time. I don't know if there is such an admin at present. But there are plenty of occasions where view deleted is useful, if you are about to recreate a previously deleted page sometimes the only way to know that the previous A7 deletion was of a "14 year old professional skateboarder" and unlikely to be the same person as the diplomat or academic of the same name who you are writing about. ϢereSpielChequers 16:42, 24 November 2018 (UTC)
    Will this filter be automatically disabled if it matches more than 5% of edits, or does this wiki have a different setting for $wgAbuseFilterEmergencyDisableThreshold? I don't see anything about this on Wikipedia:Edit filter. I've run into that problem a lot on other wikis where I've worked with abuse filters, and I'm guessing the restriction was put in place to prevent situations like this incident that occurred here. Or is this not a concern because there are so many edits to English Wikipedia that it would never reach 5%? ekips39 (talk) 22:23, 24 November 2018 (UTC)
    @Ekips39: the sheer amount of other edits should keep this down, it is currently running at about a 0.02% hit rate against edits. — xaosflux Talk 04:20, 25 November 2018 (UTC)
    @Xaosflux: Is there any way to make meaningful statistics out of the filter log - which pages are most edited, and who are the administrators with the largest numbers of edits (and possibly smth else)? --Ymblanter (talk) 17:12, 6 December 2018 (UTC)
    @Ymblanter: these can be queried programmatically live (example - click SUBMIT) , from the database, or off of dumps, so someone could make a bot generated report (request at Wikipedia talk:Database reports). — xaosflux Talk 18:00, 6 December 2018 (UTC)
    @Xaosflux: Thanks, I will try to follow up when I have a bot more time.--Ymblanter (talk) 19:02, 6 December 2018 (UTC)
  • Creatimg new logs is overkill - all Admins can just accept the occasional CSD which IS logged. Legacypac (talk) 22:41, 24 November 2018 (UTC)

Alternative ideas

This has been a very good discussion and I'm very impressed with the diversity of comments, thanks everyone. I've definitely learned some things and had my assumptions challenged. Based on the key points raised up to this point I have an alternative suggestion:

  • An account is considered inactive when it has no presence on the website at all (no edits, no logged actions) for 91 days.
  • When an account is flagged inactive, we force a password reset and send the accountholder instructions to change their password, by email (if the account has email enabled) and with a notice on their user talk page. (The current password reset instructions are here)
  • If/when the user wants to resume using their account, with all its previous permissions, all they have to do is reset their password.
  • Since the password must be reset before the account can be used again, no permissions are changed (unless the account becomes subject to the lengthy inactivity policy)
  • I believe requesting a password reset counts as a logged action; it's present in the Checkuser log at least but of course that's not public, and it rotates after 90 days anyway. At any rate, the accountholder resetting their password should reset the 91 day clock, and if someone wants to string along keeping their admin access by resetting their password every three months, that's not really a security issue.
  • 91 days is just an illustrative number I pulled out of my ass, it could be any reasonable number.
  • Two admin accounts (at least) and several others with other advanced permissions have been compromised while we've been talking about this.

I think that this catches all of the concerns raised about admins who are active but don't log actions, about automatic removal of permissions, and about accounts being hacked due to old reused password hacks on other websites. Some issues are:

  • Accounts that don't have email enabled or accountholders who lose access to the email they provided on sign-up could be locked out. I think these situations can be handled by contacting Arbcom but I've never had to so I don't really know.
  • Accounts that are active will never be required to change their password, but that's already the case.
  • There is nothing in this alternative (nor in the original) that requires strong passwords or extra authentication factors, other than having an email address.

Any thoughts on something like this? Ivanvector (Talk/Edits) 15:52, 24 November 2018 (UTC)

The WMF security team is actively working to introduce technical measures that will prevent future attacks along the same vector that compromised the most recent two admin accounts. I'd argue that they are the experts and should be the ones making the call in this area. Us debating the pros and cons of each potential security measure not only exposes all of their cons in public, making it easier for an attacker to work around, but also is far less effective because most of us aren't experts in the area.
My suggestions is to limit discussion on this topic to what would generally promote account security, without getting into detailed technical solutions. De-flagging inactive accounts is good because it reduces the attack surface. I feel like any of these discussions are more about punishing the barely-active admins who dare to have other things going on in their lives than editing Wikipedia rather than actually being about security best practices, but I guess it's at least being considered. -- Ajraddatz (talk) 16:59, 24 November 2018 (UTC)
I disagree pretty much with everything you've said. "The office is working on it" is no substitute for community discussion on local policies, especially since the security team does things in a silo, slowly, with no accountability to the actual users of this project. There is no sinister ulterior motive here to punish anybody, or drive anyone away, or ... anything, I apparently can't anticipate the bullshit schemes people are going to insist on reading into this. It's about security best practices, and responding to an actual and ongoing security threat in any way that the local community is capable, because the security team has not. You seem to think that this hacker is an idiot and isn't already aware of all the things being discussed here, like these are brand new ideas that haven't already been implemented by security-conscious websites pretty much everywhere in the world for years now. The website has been tracking security breaches for five years of exactly the sort of info that's very likely being used to hack idle accounts here, and the best innovation we've had from the WMF in that time is a beta 2FA implementation that's problematic for many users, if the WMF allows them to use it at all. We don't need more vague promises that the under-resourced WMF has "top men working on it", we need a response now. Anything less is grossly irresponsible. Ivanvector (Talk/Edits) 18:47, 24 November 2018 (UTC)
I think the hacker is aware of discussions like this, or at least able to find them. I'll email you about some of the other points. -- Ajraddatz (talk) 18:55, 24 November 2018 (UTC)
Just to note that how we are having admin-account vandalism has been publicized (even though it would take just a bit of reading on to figure out what's been happening). This basically means that the security hole due to the ability hack into admin accounts could get worse. --Masem (t) 01:48, 25 November 2018 (UTC)
Would it help to send an e-mail to all administrators alerting them on the incident and asking to evaluate the strength of their password and to change it if necessary? Those who do not have e-mail enabled can get a talk page message.--Ymblanter (talk) 10:41, 25 November 2018 (UTC)
  • A simple alternative While not having much of the finesse of Ivanvector's latest proposal in this section, using recent-ish changes it would (I believe) be trivially simple to assign the bit as a temporary (365 day) permission, with an expiry on the anniversary of the admin's initial grant of the bit. Perhaps a 24hr pause before re-granting to anybody who had absent for a significant period. Simple to do, no new infrastructure needed, no advertising of inactive accounts - I think this meets the requirements. Cabayi (talk) 14:28, 27 November 2018 (UTC)

Separate section for comments that are only about 2FA

  • Regarding 2FA, I don't remember (or just don't now, really) if anyone has access to stats on which accounts have it turned on or not. If we do, and we're not yet comfortable requiring it to be turned on for admins, maybe we can do something like enforce periodic password resets for admins that don't opt in. That's not part of this proposal, I'm just throwing out ideas. (I have 2FA turned on, ftr) Ivanvector (Talk/Edits) 19:27, 22 November 2018 (UTC)
    Well, I have a password which can not be broken. I do not want to turn on TFA because I (almost) do not use a cell phone. I am not sure why WMF thinks they are more clever than I, and I am already unhappy with 2FA requirement for interface admins - I will possibly have to resign my interface admin rights, but if RFA is required for all admins, I am not sure what I am going to decide. If you want to lose admins with zero benefit, this is probably the way to go.--Ymblanter (talk) 19:33, 22 November 2018 (UTC)
Neither a data plan nor a smart phone is required. All 2FA processing is done off-line, using a seed number and the current time to generate a key. Apps such as Google Authenticator and FreeOTP can run on any Android or iOS device without a data connection (and FreeOTP can be downloaded on your PC from here and sideloaded onto an Android device if WiFi isn't available for installation). If you do not have a smartphone/pda/media player that runs Android or iOS, you can get PC-based programs to generate the codes (WinAuth and Authy seem to be the most popular, and there are more options available for Linux-based computers such as gauth and oathtool). --Ahecht (TALK
) 19:46, 26 November 2018 (UTC)
This is a good discussion, but I've broken it out from the main proposal so as not to distract too much. I like our 2FA implementation because I always have my phone with me, and because my phone is also my authentication device for my office email, but of course it's not perfect for everyone. We could fall back on the "email you a code" type 2FA that some other sites use (Steam is one, and I hate it, my email server is slow) if it were possible to choose different authentication methods. Again, just a thought. Ivanvector (Talk/Edits) 19:55, 22 November 2018 (UTC)
In light of the number of reset requests I am wondering if the current 2FA methods run too high a risk of getting locked out of one's account. Besides, not all people are tech savvy enough to work with one device 2FA or have more than one device available at any time. Jo-Jo Eumerus (talk, contributions) 20:36, 22 November 2018 (UTC)
  • You would have lost me as an admin if you'd required TFA. Not only is it far beyond my level of technical comfort, and makes it all too easy to get locked out, I'm not going to spend $400 plus data plan for a smartphone for Wikipedia or anybody else. Massive imposition for little gain to the project in terms of security. Yngvadottir (talk) 22:55, 22 November 2018 (UTC)
  • Ditto. I act as an admin as a favour to Wikipedia, sysop status isn't a favour Wikipedia does to me. I have no intention of committing to permanently owning—and having permanent access to—an expensive piece of technology which requires a permanent and expensive subscription. purely because Wikipedia is having one of its periodic bouts of security paranoia, and if that means someone else has to clean out CAT:EX instead of me I believe I can live with the loss. ‑ Iridescent 23:01, 22 November 2018 (UTC)
@Iridescent: I can understand where you, Ymblanter, and Yngvadottir are coming from in relation to having 2FA be a requirement, but it's not as much of a commitment as the ghastly WP:2FA leads on. The most popular applications for this process are for mobile (namely Google Authenticator and Authy), but PC-based applications exist too. There are a few listed here, and there are others, like WinAuth for Windows. If you use Google Chrome, Authy has an available plugin. Unfortunately, I was unable to find any for Mac (that were not already listed) or Firefox. I didn't bother looking for Safari ones, and Brave, along with Opera I believe, primarily use Chrome extensions. Internet Explorer/EDGE are both a mess, so I'd recommend to anyone using those to swap browsers anyway. If losing the codes is what your worry about, scratch codes are generated when you enable 2FA. Email these to yourself and you'll never lose access to your account, even if you lose or change device. Anarchyte (talk | work) 23:33, 22 November 2018 (UTC)
gauth is available for Firefox. I should also note that Google Authenticator does not require a "perminant and expensive subscription", and it doesn't even require any internet acess beyond the initial installation (which can be done via WiFi). Used android devices are readily available cheaply ($10-$20) without a data plan if you don't need the latest and greatest flagship model. --Ahecht (TALK
) 19:53, 26 November 2018 (UTC)
  • Just noting as I did above that there are multiple functionaries that do not have 2FA, and for a variety of reasons, I would not even want to force this on CheckUsers or Oversighters, including but not limited to the fact that the security paranoia that Iridescent describes is very real and there are some plain insane ideas on functionary account security out there and there is a part of me that fears making this a requirement would be a slippery slope to some really dumb measures that would make a lot of people quit (yes, slippery slope is a bad argument, but WMF projects tend to make technical changes all at once if they ever happen.)
    That was all about functionaries, who I think should have a higher level of account security than admins because of the ability to access personal data. If we currently don't require CU/OS to do it, and I don't think we should, we certainly shouldn't extend the requirement to admins without those tools. TonyBallioni (talk) 01:36, 23 November 2018 (UTC)
    @TonyBallioni: it is being discussed see phab:T197160. — xaosflux Talk 05:55, 23 November 2018 (UTC)
    Xaosflux, thanks. -revi pointed me to the CU one and one for changing user rights. My general view on this is what I said in the CU one: there is no world where it should be more difficult to run a CU than it was for me to wire money to buy a house, which is an accurate description of some of the suggestions that have been made re: 2FA and the CU tool. TonyBallioni (talk) 06:17, 23 November 2018 (UTC)
  • Wikipedia, and the entire Wikimedia movement, is committed to creating and maintaining a diverse community. That means including people who have limited access to technology (in some cases, even limited access to software), people who do not have a lot of money, people who live in countries where it is not legal to own certain types of technology (or could result in significant state surveillance if owned). This is not an abstract concept - I personally know administrators who live well below the poverty line, some of whom don't even own their own computers; others who can't afford to maintain a second piece of technology like a mobile phone; and still others who live in countries where using 2FA would probably result in their being incarcerated. Frankly, there's almost nothing that an admin account can do that will result in any real level of off-wiki scrutiny. Admin accounts that go rogue are pretty easily globally locked. I also completely and fully endorse everything that Iridescent said. This is security theatre and is completely out of proportion to the problem it's trying to solve. Risker (talk) 04:51, 23 November 2018 (UTC)
    • Risker, not to mention that the most recent confirmed account compromises involving stewards (which *actually* could have had real life implications given the potential access to CU data on multiple projects) could not have been stopped by 2FA. TonyBallioni (talk) 04:59, 23 November 2018 (UTC)
      • @TonyBallioni: Would you be able to link me to these compromises involving stewards? I haven't been keeping up, but I don't entirely understand how 2FA couldn't have stopped it (unless their computers were infected, in which case nothing would have prevented it as they were already logged in). Anarchyte (talk | work) 05:05, 23 November 2018 (UTC)
I can confirm it has happened, but currently there is no on-wiki postmortem. — regards, Revi 05:10, 23 November 2018 (UTC)
And I can confirm that even those stew with 2FA were compromised. I can't talk about the details per BEANS (and other security constraints). — regards, Revi 05:12, 23 November 2018 (UTC) [ Clarification: The stew with 2FA compromised is NOT related to this incident. I'm talking about the past incident. — regards, Revi 03:42, 25 November 2018 (UTC) ]
Thank you for the (albeit restricted) clarification, -revi, though I can't help but think that something else must have also played a role in the compromising of the accounts. Having two separate devices prevents malware from getting to both the username and password, and the ever-generating 2FA code (I could give you my current 2FA code and it would be useless by the time you read this message). This is especially true given the major authenticators do not use accounts and are wiped if they're reinstalled (and, in the case of iPhones at least, are not saved to iCloud or iTunes when backed up to a computer). If someone's LastPass or 1Password are hacked and their 2FA system is compromised, then its not the fault of the system but rather the poor security employed by the account holder. This is all under the assumption that all the issues were at the user's end and that someone didn't just walk up to a computer with a logged in account (in which case ∞FA wouldn't have prevented it). Anarchyte (talk | work) 05:30, 23 November 2018 (UTC)
Requiring someone to own two separate pieces of expensive technology in order to be an administrator on a Wikipedia project is completely inappropriate and extremely exclusionary to anyone who doesn't have the ability to pay out thousands of dollars a year. We choose administrators because they are sensible, not because of their bank accounts or geographic location. Americans in particular seem to find it shocking that in a lot of countries, the phone that costs $200 in the US costs six months' wages, and that in other countries the typical internet connection costs 10-15 times as much as the average American family will pay. I pay about 3 times as much as the average American for considerably less access. Risker (talk) 05:55, 23 November 2018 (UTC)
@Risker: I noted this in a response above, but you do not need to devices to enable 2FA. Sure, it's more "secure" to use more than one, but downloading WinAuth for Windows (which has an extra layer of protection through a password and locking the data to your Windows user account) or Authy for Chrome accomplishes the exact same task. The only thing preventing someone from installing those pieces of software (or a Mac equivalent on this list) would be if the device has restrictions preventing non-vetted exes from running or if they are locked to a clean web browser.
I tested WinAuth while writing this response and it was very intuitive. See here for an image gallery explaining the process. Anarchyte (talk | work) 06:45, 23 November 2018 (UTC)
Good on you for trying to find a solution, Anarchyte; I do appreciate the effort. But again, it is entirely dependent on the user owning certain technology. It does not address the person who edits from school or public libraries, for example; as I've worked my way through the Wikimedia world, I've learned that what we take for granted here in the "Western" world is not the norm in the rest of the world. The WMF has already identified increased diversity as a critical goal in the coming decade, and so solutions need to be developed that not only accommodate but are actually focused on ensuring that people who don't own computers/smartphones can actively participate in our projects, and there are quite a few projects of languages from the poorest countries in the world. I'd like to encourage you to think more about how we can ensure that those projects can have their own admins - because we all have seen that once rules like this get applied to enwiki, they go through all of the Wikimedia projects unless there's an extremely concerted effort by a very big player (like German Wikipedia, for example). Risker (talk) 09:13, 23 November 2018 (UTC)
@Risker: Hmm, yeah. I didn't consider the precedent this would set. 2FA is a very loose term and doesn't have to be auto-generating 30-second-life-span codes accessed through secondary devices. An idea Ivanvector mentioned above, that I've also had experience with, is having codes emailed to a user. These will last longer (a few hours), have basically the same effect (prevent people from entering an account through a username/password breach), but will be slightly less secure due to the account's standing being entirely dependent on one outlet (the email address). Another idea that Steam and a few other applications use, like Facebook and Google, is remembering devices rather than browsers. I have literally no idea how this could be implemented (especially as it's a website rather than an app), but the gist is to have it so the user sets a device as being "okay" and then when the user logs in from these devices, it won't ask for verification. This prevents easy log-ins from hackers with one's username and password but doesn't hinder the account holder (usually). Anarchyte (talk | work) 10:03, 23 November 2018 (UTC)
"Remembering devices rather than browsers" is a total non-starter. As Risker says, it's easy for the core "relatively wealthy middle-aged people in Five Eyes countries" editor base to lose sight of the fact that sizeable chunks of the editor base don't operate on the same "home computer and a cellphone" basis. We have people who edit from work where they might be using a different terminal each day; people who edit from public libraries where it will obviously be inappropriate to install software; people who live in places China and Belarus where using any kind of secure system will make the authorities assume you're up to something and start prying into your private life; a fairly large contingent of serving military who edit Wikipedia as a hobby in their downtime on base and for whom installing unauthorized software on the computers or suspicious activity on their personal devices would likely get them locked up… If there were a genuine, serious issue to address then it would conceivably be justifiable to de facto ban particular chunks of the editor base from becoming admins, but since nobody's demonstrated any problem more significant than "a handful of admins used the same password for Wikipedia and Twitter and failed to change it when Twitter's password database leaked", that would seem to be a sledgehammer/nut situation. ‑ Iridescent 10:31, 23 November 2018 (UTC)
You're right, Iridescent. The email idea was the one I was going with to resolve the issue of not having a designated device and the "remembering devices rather than browsers" was to try to alleviate the concerns of those who think 2FA is too much of a hassle. Apologies if this wasn't clear. Anarchyte (talk | work) 10:48, 23 November 2018 (UTC)
(edit conflict) Without saying too much, this really wasn't a 2FA problem. I'm not anti-2FA (I use it myself and recommend anyone with advanced permissions where it is practical do so), but I also recognize there are valid reasons not to have it. Some financial. Some personal. Some just ease of using the technology, which can be an issue. It isn't a silver bullet and while it does provide an added layer of security, the fervor with which it is promoted when a high-profile compromise happens can miss the point that it is simply one tool for protecting your account, and that people should take reasonable steps to have a secure account as fits their particular situation. Mine allows for 2FA. I know of several functionaries where their situation doesn't allow for it. They all take reasonable precautions with their accounts, which is really all we can ask of them. What I would really like to see is a WMF password audit, as that would likely be a much more high yield activity, but I suspect that isn't happening anytime soon. TonyBallioni (talk) 06:53, 23 November 2018 (UTC)
Mandating 2FA would impose additional hassle on hundreds of administrators. And what problem would it solve? We had a compromised admin account. It made 8 or 10 admin actions, it was globally locked, the actions they had made were reverted, done. Pragmatically in terms of "person hours" it is much quicker to resolve such issues in the way we currently resolve them then it would be to make every administrator jump through 2FA hoops, all the additional hassle for stewards resetting passwords when people bodge up their login or lose their phone, and so on. Mandating 2FA would be an overreaction to a very infrequent problem. Fish+Karate 09:21, 23 November 2018 (UTC)
  • For what it's worth, I'm also opposed to mandatory 2FA for any level of account. I use it myself because it works for me, but I absolutely understand that there are technological and financial challenges with WMF's implementation (and/or in general) for many users. Strong passwords and good password hygiene are also important, but we can't really mandate those things, we can only advise and recommend. Just to add info to the pile, I use a password manager along with 2FA wherever it's available, I use passwords generated by the manager or xkpasswd for things I really need to remember, and I've moved money out of accounts with banks that still use a six digit number as an internet password. Ivanvector (Talk/Edits) 14:59, 23 November 2018 (UTC)
  • Given the problems that come with it (both inherent and any via a flawed system) then I wouldn't say anyone short of a steward or IntAdmin should need it. In its ideal form I am neutral to obligating it for admins - but certainly not at this time. Nosebagbear (talk) 15:23, 23 November 2018 (UTC)
  • With the second administrator being compromised today (3rd one this year) it is time to make having 2FA be a mandatory component for all new Admins (passing a RFA), all Admins requesting simple Resysoping, and all advanced privilege (Requiring identification to Foundation) holders. We've seen what a compromised admin and oversighter can do. Fundamentally the 2FA is one of the least intrusive ways to make the attack surface more difficult to succeed at. Hasteur (talk) 22:39, 23 November 2018 (UTC)
    • Hi, Hasteur. The WMF does not require identification of advanced permission holders, and has not required this for several years. There are many reasons for this; amongst the more important is that they do not have a method of securely storing the identification information, and the simple fact that they will not be able to verify that the identification documents sent to them truly belong the the person behind the account. Instead we are all required to read and sign a confidentiality agreement with our logged-in user accounts. Risker (talk) 04:28, 25 November 2018 (UTC)
  • I oppose mandatory 2FA: a proper password is plenty secure, while with 2FA it's too easy to lock yourself out of your account. Imposing 2FA would also effectively mean requiring admins to maintain committed identities and so on to convince sysadmins to unlock their accounts. BethNaught (talk) 10:14, 24 November 2018 (UTC)
  • As others have pointed out 2FA is fine for a real world organisation where employees work several hours at a time and are identified to HR and company IT/Security. It isn't such a good fit for a volunteer organisation like this, and can actually militate against editor retention, specifically editors returning after multi year holidays - not a common issue for corporate IT. If password protection for admins needs to be improved, then set some software in place to force a password reset on any admin account with a password shorter than 16 digits. ϢereSpielChequers 13:05, 24 November 2018 (UTC)
  • I won't be using 2FA. 3 reasons: (1) I have a unique, long, password (as does the email account I use only for Wikipedia) (2) Having seen the results of an organisation I did some consultancy work for when they introduced 2FA ... yeah, you can probably guess the rest... (3) You seen the mobile reception round here? Black Kite (talk) 23:32, 24 November 2018 (UTC)
    @Black Kite: just to clarify, our 2FA solution is not "on line", that is no connectivity is required between the authentication device and anything else, not for enrollment and not for use. — xaosflux Talk 20:26, 25 November 2018 (UTC)
  • Heh, I accidentally locked myself out of my own account this morning. I logged out to use one of my alts, forgetting that I had just started a system update on my phone and couldn't access my authenticator app. I could've looked up my scratch codes to get back in but I didn't have anything urgent to do so I just waited for the update to finish. I'm just saying 1) it happens to people who think they know what they're doing, and 2) you can recover your account if you do something dumb like this, but it's a hassle (it's supposed to be a hassle). Ivanvector (Talk/Edits) 17:14, 25 November 2018 (UTC)
  • Just a comment on forced periodic password resets (not entirely just about 2FA, but I can't see a better section). It's been largely debunked as a means to security, and it often just makes people change to passwords that are easier to remember (and therefore easier to hack). One place I worked briefly enforced monthly changes to passwords, and a significant number of people started using "January", "February" etc. That can be prevented by insisting on strong passwords, but with strong passwords you avoid any need for periodic changes anyway. If someone is victim to a brute force attack, all a periodic change really does is eliminate the passwords already tried and force the hacker to start again. So with a good strong password, a forced 3-month reset might reduce the mean time to hacking from, maybe, 50 million years to 49,999,999 years and 9 months. Strong passwords are the way to maintain security (and by that I don't mean nonsense like 8 characters including 1 digit and one upper case letter, I mean proper strong passwords), coupled with login attempt throttling, and maybe a good 2FA system where something extra might be needed (but 2FA isn't the real answer). Boing! said Zebedee (talk) 12:47, 3 December 2018 (UTC)
    I've just used a "Check the security of my password" site to check a few passwords. I did *not* check any of my real passwords on the possibility that it's a fake password-grabbing site! (though I used one at Russia's Kaspersky Lab, so that should be fine ;-) The results were interesting, with estimated computer-based cracking times...
    "January" - 4 seconds
    "Jan" - 7 microseconds
    "January1947" - 8 minutes
    "TomatoTrinket" (two random words) - 21 days
    "toMatOtRINket" (same two words with random caps) - 20 years
    "_QPZ#~pGww:6Q,7\" (from a random password generator) - 10,000+ centuries
    A password of similar length and format to my Wikipedia password - 8,763 centuries
    Some sites will offer a false sense of security, so be wary of any results. One, for example, reckoned "January1947" would take 41 years to crack, and I presume that's just doing a brute-force random-character attempt rather than trying any "Hmm, I wonder if it's when they were born?" connection of months and years. But I think it makes my point about strong passwords being the crux of it. Boing! said Zebedee (talk) 13:09, 3 December 2018 (UTC)
    I changed my password the other day as it seemed like good advice. My old password would have taken a pitiful 2,000 years to brute force. Lame! My new one, a far safer 552 quadrillion years. I think the bigger risk these days isn't your password being brute forced, it's your password being used on multiple sites. I had this issue once when LinkedIn dropped a bollock and gave away everyone's passwords. It wasn't the same password I used here, that's always been unique, but I did have to change passwords on about 40 different sites and learned a valuable lesson. NEVER REUSE PASSWORDS ANYWHERE EVER. Fish+Karate 13:46, 3 December 2018 (UTC)
    Definitely, yes, never reuse passwords between sites. Boing! said Zebedee (talk) 14:36, 3 December 2018 (UTC)
    Looking at my results again, I suspect the site I used got "_QPZ#~pGww:6Q,7\" wrong - it's only 16 chars from the printable ASCII set, and "10,000+ centuries" seems way too optimistic. Boing! said Zebedee (talk) 14:38, 3 December 2018 (UTC)
  • I support all the comments above by @Fish and karate, Iridiscent, and Risker. This is a security panic, which is entirely un-needed now that admins no longer have the power to unblock themselves. A hijacked admin account be be spotted, blocked, and the damage cleaned up quickly.
As others noted above, 2FA also imposes burdens on admins which they may not be able to meet for a whole variety of reasons: financial, logistical, state security policy, neurological diversity, etc etc. It is sad to see how some editors simply assume that because their life circumstances make 2FA easy for them, the same applies to everyone else.
If there was en.wp decided to take just one step to further reduce our already appallingly low levels of diversity, this would be near the top of the list. Luckily, en.wp's policies are aimed at increasing diversity. --BrownHairedGirl (talk) • (contribs) 13:37, 3 December 2018 (UTC)
  • An observation: it appears that what's written in this month's administrators' newsletter is the WMF's entire response to these hacks: they're not doing anything at all about vulnerable accounts, they're just passing the buck to users to secure their own accounts. Of course, their message will not get to inactive admins, so be vigilant for more hacks. Ivanvector (Talk/Edits) 14:19, 3 December 2018 (UTC)
    • That's a very poor observation. It's standard practice among security professionals to not publicly discuss the details of every mitigation strategy, to make it a bit harder for the attacker to adapt. Anomie 13:09, 4 December 2018 (UTC)
  • Agree with Boing! said Zebedee - my last job had us changing password every month - a lot ended up using a "core" password and added a 2 digit number to the end of it (and then writing the 2 digit number on the back of the PC...) FWIW, I do have 2FA installed, only because of c:Commons:Administrators'_noticeboard/Archive_69#URGENT:_CHANGE_PW_/_ENABLE_Two-factor_authentication, since I'm an admin on commons as well, and there was no great oppose to not implementing it (but there are only about 250 of us). In the end it cost me nothing to implement - I wrote a short python script User:Ronhjones/2FA for my PC - I just run it when I need a code (and it gives me my adminbot code as well). Ronhjones  (Talk) 18:45, 3 December 2018 (UTC)
    Ah yes, I remember now - I just added "Jan", "Feb", etc to my existing password (which was already quite strong). Previous ones couldn't be reused, but they gave up on the scheme long before 12 months and the need for a new root. And while we're doing password anecdotes, I had to try breaking into a colleague's account once (as he'd left some broken jobs clogging up the overnight batch queue - I'm showing my age). His username was just his first name, so the first thing I tried was his surname, and I was in - and his surname, appropriately, was "Hack". Boing! said Zebedee (talk) 19:01, 3 December 2018 (UTC)

Mandatory 2FA considered harmful

Allowing 2FA is fine, as long as the scheme uses meets the requirements of [ [] ]. Encouraging 2FA is also fine. Requiring' 2FA is a really, really bad idea. It is security theater, and in general is less secure than simply using a long, easy-to-remember-but difficult-to guess passphrase.




--Guy Macon (talk) 07:38, 23 November 2018 (UTC)

I'll note that the articles you provided counter your point of passphrases being good enough. "And remember, any 2FA is better than no 2FA. Yes, it might take you an extra 10 seconds to log into certain apps, but it’s better than sacrificing your security." "the few minutes it takes to set up an authenticator app are more than worth the benefit". Here are three articles that support the use of 2FA:
Calling it a security theatre is subjective, and the article from The Stack is contradicted as "anywhere computing" relates to syncing information across devices, and these applications don't do that (at least Google Authenticator and WinAuth). I can understand possible situations in which someone cannot enable 2FA, but I see little reason to not if you can. So what if it takes someone an extra two minutes to log in? I'd much rather have to do that every so often than wake up to find my account compromised because Wikipedia or the connected email was hacked. And that goes for most sites that offer 2FA (I might not use a site's 2FA if I rarely use the site, but if someone's an admin+, it's hopefully safe to assume they're somewhat dedicated). Anarchyte (talk | work) 08:23, 23 November 2018 (UTC)
Just to comment - it is pretty clearly security theatre to suggest that the way to prevent compromise of admin accounts is to apply 2FA, when the last two reported admin or higher account compromises would not have been prevented even if the compromised accounts had had 2FA. It is also pretty clearly security theatre to suggest that removing admin permissions at a lower threshold will prevent situations where the accounts need to be blocked/locked/desysopped, when the overwhelming majority of admin accounts that have been desysopped would have met just about any activity criterion the community could reasonably come up with. So yeah. Security theatre. Risker (talk) 09:24, 23 November 2018 (UTC)
We hear about the successful attacks to compromise accounts, but never the unsuccessful ones. While I'm doubtful it has occurred, we would never be able to know if someone managed to guess the password to an admin's account who had 2FA enabled. There's a ping if they get it wrong a certain amount of time, but nothing for getting 66% of the way there (33% each for username, password, and 2FA). If that's an example of a security theatre, so is requiring CVVs for credit cards. It's simply a fail-safe to prevent people from giving away all their information. You could take a photo of the front of your card and no one could purchase anything online. I could give you my password and you wouldn't be able to access my account. I'm not saying 2FA is the be-all-end-all; just like CVVs aren't. If they were, we would never have a breached 2FA-enabled account and we would never have to worry about people using someone else's credit card. It's an extra layer of protection. Anarchyte (talk | work) 09:47, 23 November 2018 (UTC)
That's a false analogy. Compromise of a credit card causes the real loss of real money. Compromise of a Wikipedia account—even an admin account—causes someone to be a mild nuisance for a couple of minutes before having their contributions rolled back. Even assuming every editor had access to the technological means to use 2FA, an additional 10 seconds per day adds up when you multiply it by 1000-ish admins (not to mention the opportunity cost of "I've just noticed a problem, but I won't bother logging in to fix it because it would mean going downstairs, finding the phone and turning it on"). There are theoretical ways a compromised account could do genuine damage and force the WMF to perform a database rollback, but they've never once happened. The risk from a genuine holder of advanced permissions leaking data or systematically disrupting is orders of magnitude greater than the risk from a potentially compromised account, and even installing iris recognition on the computers of every admin would have zero impact on admins becoming disgruntled, drunk, involved in personal vendettas, or just bored. ‑ Iridescent 10:46, 23 November 2018 (UTC)
Fraud is usually intercepted by the bank and the account gets locked with the money spent being charged back, when possible. With this said, the analogy wasn't to give perspective to the connotations, rather that fail-safes like 2FA are all around us. I agree with your other points, though. Anarchyte (talk | work) 11:01, 23 November 2018 (UTC)
Going off of Iri’s point, this just happened, and while the account claims compromise, that is unlikely and in every likelihood we had a CheckUser on another WMF project (who at one point had access to data that was stored on CU-wiki) was operating a goodhand-badhand sock situation on multiple wikis. Compromise is a concern obviously, but the chance of admin socking or a functionary going rogue is actually a much greater risk in my view. Again, I am not anti-2FA, but I do think we need to have a realistic view of actual risks. TonyBallioni (talk) 22:45, 23 November 2018 (UTC)
Sure, but did we ever had breach of an account with say 20+ character password which was not reused on any other sites? Ideally if the recovery mail is also protected by a 20+ character password which has never been used elsewhere?--Ymblanter (talk) 11:17, 23 November 2018 (UTC)
People haven't been going around revealing their compromised passwords. Length isn't the defining factor, complexity is. See this 8-10GB file of hacked passwords and you'll see that while less common, accounts with randomised passwords still get hacked. These sites may not be Wikipedia (some are actually bigger: 150 million Adobe and 165 million LinkedIn accounts, for instance) but we'd be ignorant to assume we can't be hacked. Anarchyte (talk | work) 12:05, 23 November 2018 (UTC)
I kinda get the feeling that if we make 2FA mandatory, that will just become the next target. If we don't make it mandatory but everyone on the site still used 2FA (except me because my password would take "4.06 hundred million trillion centuries" to crack and isn't listed in any dumps) then passwords remain the more visible option (even if they only get my password well after homo sapiens is no longer a thing). If someone is not going to use 2FA, they need to check for their passwords on Have I Been Pwned? and if there's any chance it might have leaked, change it to something that will outlast the site. Ian.thomson (talk) 17:00, 25 November 2018 (UTC)
If credential stuffing is what's going on here, a better idea is to use a unique password on Wikipedia which you do not use and have not ever used on any other website. If it's a brute force attack then Macon's Principle is a good guide. And then there's session hijacking, and for that I don't know, but I do know if you log out of Wikipedia it logs out all of your sessions on all devices. Ivanvector (Talk/Edits) 17:10, 25 November 2018 (UTC)
In my experience, if you log out once you are logged out of all sessions at all devices. (Though I must confess I was this years in a situation on my ipad when I was logged on the English Wikipedia but not on Commons or Wikidata).--Ymblanter (talk) 17:41, 25 November 2018 (UTC)
Correct. Logging out of any Wikimedia site logs you out of all of them. Additionally, changing your password logs you out of all sessions besides the one used to change the password. In light of the recent events, I decided to changed mine (and my 2FA secret key) to verify this. I recommend other people do the same even if you think your password will take aeons to crack. Anarchyte (talk | work) 04:35, 26 November 2018 (UTC)
Ian.thomson, How do you know [] wasn't hacked at the time and you haven't given hackers your password by checking it there? ;-) Boing! said Zebedee (talk) 13:31, 3 December 2018 (UTC)
Because the calculation takes place client side, not server side (you can load the page, disconnect from the net, and still check passwords). Also, I checked different scrambled forms of my password (substitution cipher on all the characters and then either swapped the front half and back half or then put the characters in alphabetical order). Ian.thomson (talk) 19:14, 3 December 2018 (UTC)
@Guy Macon: I disagree that enforcing 2FA for everyone would be security theatre. One of the nice things about 2FA is it is very hard for a person to screw up. During the enrolment phase, users are given a barcode of the master secret to scan into their phone (or other device). The barcode is generated by the website, which means it is complex enough, and unique to the website. Compare this to a password - the user is expected to come up with a unique complex password that they never reuse. It is much easier for a user to screw this up. In fact the path of least resistance is to simply use an easy to remember word for every website. Hence the problem of people using the same password on multiple websites. Now sure, people could also post their 2FA barcode to twitter or something like that, but that would be really odd behaviour and the user has to go out of their way to compromise the security of 2FA in that manner. In my opinion, user security is much like any other thing in the world. You have a certain small number of people who are really good at it, a large group of people who are in the middle, and a small number who are really terrible. Education can of course shift the mean to the right, however when you have a group of 1200 people, I am doubtful you can ever educate people enough so that there isn't a single person using a poor (or shared) password. Attackers of course don't care if 1199 admins have good passwords, they only attack the 1 person who has a poor password. This is why mandatory 2FA would be an effective security solution - people have very little freedom to do it poorly, so if everyone is forced to use it, then everyone has a base level of security, and the attacker cannot simply choose the weak leak. (I should of course clarify that 2FA is not a panacea. It won't prevent phising attacks. It won't stop your younger sibling from going on to your computer and deleting the main page while you are in the bathroom. It will however stop one of the most common ways website accounts on the internet are compromised: People using the same password on a different website that got hacked. I also want to acknowledge that 2FA is not without its costs. I'm only arguing that it is a measure with actual benefits and definitely not security theatre. Like any security measure it has costs and benefits; it has things it protects against and things it does not). BWolff (WMF) (talk)
I oppose forcing people not to use 2FA and I oppose forcing people to use 2FA. I support giving them a choice (possibly with stern warnings). What you described above (mandatory 2FA) would prevent me from logging into Wikipedia when I work in China. I bring along the stupidest possible flip-phone (can't run any programs, no camera), and I run the TAILS operating system on a cheap computer I buy locally and leave behind. I have no way to scan in a barcode while in China, and any barcode that is in my luggage must be assumed to be copied by my opponent (industrial espionage by a Chinese toy manufacturer who has full cooperation from the Chinese government). Again, the user should be given a choice.
If you *really* want to stop Wikipedia users from using the same password on a different website that got hacked, give the user a pronounceable four or five character string and tell him he must start his 12-or-more character password with it. Not that I recommend such a scheme, but it would accomplish your stated goal. --Guy Macon (talk) 00:44, 5 December 2018 (UTC)
All I am saying here is that mandatory 2FA has real security benefits in many realistic threat scenarios (including the 3 most recent admin compromises), and thus is categorically not Security theatre. Security theatre is usually a term used to talk about security initiatives that are very visible but have essentially no benefits against realistic attackers. Whether or not the security benefits of mandatory 2FA outweighs the costs in the context of enwikipedia admins, is a different question, and one that requires very different arguments than establishing whether or not it would be pure theatre. (As an aside though, I'll note that its surprising the types of devices that support 2FA. For example totp-me works on many basic flip phones). BWolff (WMF) (talk) 03:49, 5 December 2018 (UTC)

Macon's Principle

(If the following is too long for you, just read [] and [] ) and skip to the next section.)

Two factor authentication has its uses, but it is no substitute for a passphrase that is easy to remember and hard for a high-speed offline passphrase-guessing program to guess. I have decided to call this "Macon's principle" so that I don't have to type "choose a passphrase that is easy to remember and hard for a high-speed offline passphrase-guessing program to guess" again and again.

If you follow Macon's principle, 2FA or any other form of add-on security is not needed.

As explained at Kerckhoffs's principle and Security through obscurity, we are not to rely on anything other than having a sufficiently long (See Brute-force attack) passphrase without any easy-for-a-computer-to-guess patterns in it.

We are to assume that the attacker knows every byte of information on the WMF servers (and in fact the attacker may actually be someone who knows every byte of information on the WMF servers -- If a nation-state offered a key WMF employee millions of dollars if he complied and made a credible threat to torture and kill his family if he didn't, there is a 99%+ chance that they would end up knowing every byte of information on the WMF servers.)

We are not to assume that the attacker cannot perform a high-speed offline passphrase-guessing attack.

We are not to assume anything about the amount of cleverness and computing power that the attacker has, other than arguments based upon basic math and physics (The attacker cannot spend more time than the age of the universe, he cannot have more memory available than the size of the universe will hold -- that sort of thing).

The WMF does not store your passphrase anywhere. When you enter it it a cryptographic hash is performed and the result compared with a stored hash. This means that an attacker who knows every byte of information on the WMF servers can perform a high-speed offline passphrase-guessing attack, but cannot simply look up your passphrase and use it to log on.

So according to Kerckhoffs's principle, you should choose a passphrase that is easy to remember and hard for a high-speed offline passphrase-guessing program to guess. The passphrase should only exist in your mind; never write it down, never say it out loud, never store it on any computer or online system.

Bad ways to follow Macon's principle

  • Passwords instead of passphrases (single words instead of strings of words with spaces between them).
  • Random gibberish.
  • Short passwords or passphrases. 8 is awful, 16 is marginal, 24 is pretty good, 32 is so good that there is no real point going longer.
  • Character substitutions (Example: ch4r4ct3r sub5t|tut10ns)

Good ways to follow Macon's principle

  • Use a standard English sentence with proper grammar, spelling, and punctuation.
  • Make it longer than 32 characters and have it contain at least three (four is better) longish words plus whatever short words, capitalization and punctuation are needed to make it grammatically correct.
  • Make sure that sentence has never been entered anywhere on your hard drive (including deleted files) or on the internet. "My Hovercraft Is Full of Eels" is bad because a dictionary that contains every phrase used in Monty Python's Flying Circus would find it.[3]
  • Make it meaningful, easy to remember, and something that generates a strong mental image.
  • Make it meaningful to you, but unguessable by others (don't use your favorite team, first kiss, mother's maiden name, etc.)

An example of a good passphrase that follow Macon's principle would be:

 Sherwood painted his Subaru pink so that it would blend in with his flamingos.

(This assumes that you actually know someone named Sherwood and that he owns a non-pink Subaru. To make it easy to visualize and remember, you should use a name/car from among your acquaintances)

That's 78 characters that nobody in the history of the earth ever put together in that order until I wrote it. Typos really stand out (Sherwood paibted his Subaru pink so that it would blend in with his flamingos.) and are easy to correct. The sun will burn out long before the fastest possible passphrase-guessing program completes 0.01% of its search. And yet it would be far easier to remember than the far easier (for a computer) to guess HZn?m+jW1 would be.

(Side note: When I say "Use a standard English sentence with proper grammar, spelling, and punctuation." I mean use what you consider to be a standard English sentence with proper grammar, spelling, and punctuation. If, you, overuse, commas, and, kant, spel, that's fine as long as you do it the same way every time. And if you are better at Spanish, use what you consider to be a standard Spanish sentence with proper grammar, spelling, and punctuation. Just write your passphrase in whatever way you normally write. If you are handicapped in such a way that you cannot type the same thing every time, sorry, but you are hosed on Wikipedia or on any other system that requires a username or password. My advice also doesn't work if you are in a coma or are Amish and not allowed to use a computer. None of this applies to Wikipedia users.)

I could walk you through the math, but Steve Gibson has already done it for us. See [ [] ]. Just type in your current password/passphrase and it will tell you how well it does against a brute force password guessing attack. The calculation is done locally, using JavaScript, so the password doesn't leave your computer.

If you don't want to risk typing in your password, try these 8-character test passwords (Generated from an atomic decay true random number generator):

  • HZn?m+jW (chosen from the 95 ASCII printable characters (01...89abc...xyzABC...XYZ `[email protected]#$%^&*()-_=+[{]}\|;:'",<.>/?) - 7.66 hours to crack.
  • PhBixXL4 (chosen from the 62 ASCII a-z/ABC-Z/0-9 characters (01...89abc...xyzABC...XYZ) - 36.99 minutes to crack.
  • qza7nm3g (chosen from the 36 ASCII a-z/0-9 characters (0123456789abcdefghijklmnopqrstuvwxyz) - 29.02 seconds to crack.
  • pgupwmxn (chosen from the 26 ASCII a-z characters (abcdefghijklmnopqrstuvwxyz) - 2.17 seconds to crack.
  • 54606559 (chosen from 10 ASCII 0-9 characters (0123456789) 0.00111 seconds to crack.

Try it with 12 characters, 16 characters, etc.

Now try "Sherwood painted his Subaru pink so that it would blend in with his flamingos." on the GRC calculator. The time to crack goes from minutes or seconds to ten billion trillion trillion trillion trillion trillion trillion trillion trillion trillion trillion centuries.

I should also mention dictionary attacks. My collection of cracking dictionaries is getting big enough that I will likely have to buy a bigger drive to hold them soon. (No, I am not a malicious hacker. Some companies hire me to evaluate their security. Or at least that's the story I am telling now... :) ) The good news is that if you use two words in a dictionary separated by a space, the time for an exhaustive search is squared, and with three it is cubed. The example I made up above "Sherwood painted his Subaru pink so that it would blend in with his flamingos." has 14 dictionary words. Even if the dictionary was really tiny (say, 1000 words), that's 10^42 guesses. And such a tiny dictionary is unlikely to contain "Sherwood" (with the capitalization) "Subaru", or "flamingos." (with the trailing period). So "Sherwood painted his Subaru pink so that it would blend in with his flamingos." is also ridiculously resistant to dictionary attacks.

--Guy Macon (talk) 17:21, 23 November 2018 (UTC)

How about also randomizing the sapces? E.g, S herwoodp aintedh isS ubarup inks ot hati tw ouldb lendi nw ithh isflamingos? ——SerialNumber54129 14:29, 24 November 2018 (UTC)
That would take exactly as long to brute-force crack, and how are you going to remember where you randomized the spaces? Ivanvector (Talk/Edits) 15:53, 24 November 2018 (UTC)
Exactly so. Randomizing the spaces violates one of my suggestions (Use a standard English sentence with proper grammar, spelling, and punctuation) and adds zero benefit. More importantly, Serial Number 54129 should have entered his suggested passphrase into [ [] ] and compared it with "Sherwood painted his Subaru pink so that it would blend in with his flamingos." That would have told him the relative strength of the two passphrases against a brute force password guessing attack. --Guy Macon (talk) 22:13, 24 November 2018 (UTC)
Hm, just mentioning here that a very short phrase -- the names of my best friend's weirdly named cats -- shows as taking at minimum 38 centuries to crack. Which would actually protect me in every case except someone who knew me well enough to make that educated guess. Thanks for this info, Guy Macon. --valereee (talk) 12:06, 25 November 2018 (UTC)
Sherwood painted his Subaru pink so that it would blend in with his flamingos.
Trouble is, after a period of non-use, this could easily be misremembered as containing any one of
  • so that it would match
  • so that it blended in with
  • so that it would go with
  • so it would blend in with
et cetera. And that's just one part of the sentence: Sherwood might have sprayed his Subaru, or had it painted, or....
The XKCD suggestion is better, I think: just four words.
The next problem is that the Wikimedia websites require just one among perhaps fifty passwords that are required of me (many of them used only once a year or so). If I'm not to store them on my hard drive, then how should I remember them? -- Hoary (talk) 12:18, 25 November 2018 (UTC)
Remember, you should create a mental image Sherwood painting his Subaru pink and of it blending in with his flamingos. If the language first comes to your mind is "matching his flamingos" use that language, and create a mental image of him putting them next to each other and seeing if they match.
Last "problem" first: Use a password manager that keeps all of your passwords in an encrypted container so you only have to remember the one macon's-principle-compliant passphrase that accesses the rest. This also soles the "seldom used" problem; you end up using it a couple of times every day.
For most people Passsafe[4] is a good choice for a password manager. I often do engineering work inside of a factory in China in an industry (toys) where the threat of industrial espionage is high, so for me every webpage gets a password like this: weO'5QvWH6oeRjKQ;EU/[email protected]#<0CJ5a/&FmHrV>/}O5]p{+Km}gJ~^e9'5=tznK and all of the passwords are stored as text files on a thumb drive that is encrypted using Veracrypt using multiple algorithms. Most people don't need that level of protection.
Next, it is not true that the XKCD advice is better than mine. That comic was written as an example showing that "correct horse battery staple" is easier for a human to remember and harder for a computer to guess than the "Tr0ub4or&3" alternative -- which it clearly is. Note that he assumes 1000 guesses per second, which violates Kerckhoffs's principle. We are not to assume that the attacker cannot perform a high-speed offline passphrase-guessing attack. We are not to assume anything about the amount of cleverness and computing power that the attacker has, other than arguments based upon basic math and physics (The attacker cannot spend more time than the age of the universe, he cannot have more memory available than the size of the universe will hold -- that sort of thing).
If you apply Macon's principle to the XKCD comic, you get the following very strong passphrase:
      The horse said "That's a battery staple". I replied, "Correct!"
Randall Munroe knows all of this, but I challenge anyone to fit all of the details needed to apply Macon's principle into a six-panel comic.
Here is a discussion of the math behind that particular comic:
Or, as Bruce Schneier wrote: "This is why the oft-cited XKCD scheme for generating passwords [...] is no longer good advice. The password crackers are on to this trick."[5] --Guy Macon (talk) 16:18, 25 November 2018 (UTC)
Bruce is wrong about this, as several of the comments on his page point out. As long as the words in the passphrase are chosen uniformly randomly from a list or dictionary, the entropy of the passphrase can be computed from the number of words in the passphrase, N and the number of words in the list, L, as entropy = N*log2(L). If the entropy is high enough, cracking is not going to work. It doesn't matter that the cracker knows how your are doing this. One way to get uniformly random words is using dice. See Diceware. (COI alert, I'm the developer.) Your method, by contrast, requires people to exercise judgement on what is random enough, and there is plenty of experience to show that most people fail miserably at that. Also passphrases generated your way can easily be longer than many systems will accept. The latest NIST SP800-63b guidelines, linked above, require only 64 characters to be accepted. Your pink flamingo password is longer than that. And many (most?) systems do not even meet the NIST requirements. (Does Wikipedia?) And of course typing a passphrase that long without error, especially on mobile devices, is not easy. Making up a sentence using the random words is a great idea as a memory aid, but there is no need to make the sentence the passphrase.--agr (talk) 18:02, 25 November 2018 (UTC)
The diceware method is an excellent way of constructing a passphrase. I highly recommend it, especially if you use the EFF's long word list for five dice (or one die rolled five times).[6] Anyone using the diceware method instead of my method will also be insanely secure against both dictionary attacks and against brute-force guessing attacks. I have never heard of anyone or any computer program ever guessing a Diceware passphrase.
That being said, as you yourself pointed out in 2014, the four words that XKCD mentions (note that Randall Munroe never actually says that "correct horse battery staple" is sufficient, only that it is easier for a human to remember and harder for a computer to guess than "Tr0ub4or&3" is) are a couple of words too few:
"For the average user I now recommend a passphrase with six Diceware words, or five words with one extra character chosen and placed at random. This is a change from my previous advice [five words]..." --Source: The Diceware Security Blog
In my opinion (and this is a judgement call - I may be wrong), compared with my method Diceware is much more resistant to the well-known human tendency to make non-random, guessable choices, but (also IMO) my method gives you a passphrase that is easier to memorize and remember after a long time of not using it compared to a Diceware passphrase. --Guy Macon (talk) 07:02, 26 November 2018 (UTC)
Not intending to get into an argument with you, Guy Macon, just testing my understanding ... by, um, arguing. (Sorry!)
The horse said "That's a battery staple". I replied, "Correct!"
is clearly superior to
correct horse battery staple
(or whatever it was), all things being equal. But not all things are equal, it seems to me. If I want to log in here via my phone (which BTW is something I don't remember ever having done, and would be very reluctant to do), then I'd have to (i) remember the former precisely, (ii) paste it from text copied from elsewhere in the phone's memory (bad!), or (iii) read it off a piece of paper (bad!). As for my own computer, it's rare that I need to specify my password; when this happened, I wouldn't remember if I'd had "replied", "responded" or "answered" (etc etc); and if I'm reading it out of some file I might as well copy
correct horse battery staple bismuth fortuitous banana
(or whatever) out of it and paste that as do the same with the two sentences -- which are indeed hugely more easy for short-term human memory but I imagine [disclaimer: I am not a cognitive scientist] just about as hard, or possibly even harder, for precise memorization over a long period. (Or possibly the problem is that my memory is unusually crappy.)
I don't think what I'm saying contradicts what I understand as your main point, for which I'm grateful (and according to which I intend to upgrade some of my passwords). -- Hoary (talk) 01:40, 26 November 2018 (UTC)
I am in basic agreement with you. It is significantly harder to compose a passphrase that doen't have significant "I replied\I said" memorization problems when you start with a list of words someone else chooses. I should modify my advice to talk about that. --Guy Macon (talk) 07:02, 26 November 2018 (UTC)
While I do recommend a six-word passphrase, a four word passphrase like correct horse battery staple is still far stronger than what most people use and is unlikely to appear in a list of previously hacks passwords. I don't disagree that The horse said "That's a battery staple". I replied, "Correct!" is stronger. The question is whether the improvement is worth the added typing. Your passphrase is 61 characters long, vs 28 for the original. I'm not aware of any way to quantify how much more entropy your passphrase gains over XKCD's original, but most people do fairly predictable things when given open-ended advice like make up a sentence with these words. My metric is bits of entropy per keystroke. In my view, entering passwords accurately is the biggest cost to users. Very few people are going to memorize more than a few strong pass phrases. That's why I recommend writing them down or using a good password manager with a strong master pass phrase. The threat these days is not someone stealing your wallet, it's lists of hashed passwords being stolen and cracked offline at very high speed, billions per second. My Diceware list was chosen to minimize word length, and hence passphrase size, for any chosen level of security. The EFF uses much longer words, which I think is silly, but it's a personal choice. Again making up a sentence from a random passphrase as a memory aid is fine, but using the sentence as as the passphrase itself is a very inefficient way to increase security. For what its worth, I also have a tool for generating mnemonic sentences from any random 10-letter string. Random letter strings may be a better choice for mobile devices, which are becoming more common than PCs as an Internet access tool. The best path forward, I believe, is stronger ways for storing password validation data so that stolen lists are much harder or infeasible to crack. That's been the focus of my recent research. How does Wikimedia store its passwords?--agr (talk) 17:08, 26 November 2018 (UTC)
To partially answer my own question, I found a page [] that describes the Wikimedia default which is pbkdf2 with 10000 iterations of sha256 and salt. That's not bad, but a memory intensive algorithm like scrypt of argon2 (or my RockSalt) would be better. Still, the default shifts the likely threat to using a password that has been cracked before and is high on a list of common passwords.--agr (talk) 17:30, 26 November 2018 (UTC)
@ArnoldReinhold: Just a minor correction to your comment, we are currently using PBKDF2 with 128000 rounds sha512 (and salt). [7]. BWolff (WMF) (talk) 06:31, 5 December 2018 (UTC)
Guy Macon, I'm not clear about the advantage of including word spaces rather than using a continuous string. Is it just that it makes it longer without increasing the difficulty of memorization? DGG ( talk ) 20:01, 27 November 2018 (UTC)
Itdoeslittletomakethingsharderforanattacker(anyreasonablycompetentattackerwilluseadictionarythattrieseveryphrasewithandwithoutspaces,d1fferentc|-|aractersub5titutions,etc.),butitishardertorememberandeasiertomakeatypowhenyourpassphrasedoesn'tusestandardspelling,punctuation,andgrammar. Guy Macon (talk) 23:59, 27 November 2018 (UTC)
I'd like to endorse Guy's principle, with one small addition: make sure your passphrase incorporates at least one unusual word – maybe one of your friends has an unusual name, or you know a place with a strange name, etc. Since the strength of a passphrase is directly related to the size of the dictionary needed for a dictionary attack, you can force an attacker to use a very large dictionary, and massively increase the time required to crack the passphrase by that means. Try something like My family and I stayed 14 days in Betws-y-Coed. HTH --RexxS (talk) 22:18, 29 November 2018 (UTC)
That's a very good adddition. Increases passphrase strength even more without making it harder for a human to remember. It would be a large dictionary indeed that contains "Betws-y-Coed". Thank you from the bottom of my parasagittal circumduction. --Guy Macon (talk) 00:03, 5 December 2018 (UTC)

2FA is not just about "cracking" passwords

There's a huge amount of text here so I'm not sure whether the point has been made elsewhere, but I think it's worth calling out explicitly.

All the stuff about "Macon's principle" is fine, if the only thing you have to worry about is whether a password can be brute-forced. Unfortunately it isn't.

What happens if you need to log in from a public library or a Kinko's? There's probably no keylogger installed on the machine. But there could be. Are you going to come up with another seven-word meaningful and unguessable sentence and change your password?

With 2FA, you can go ahead and log in and not worry about it too much. Probably no one captured your password. But even if someone did, he/she will have a hard time using it. It isn't theoretically perfect, but it's pretty good, which in real-life situations sometimes has to be good enough. --Trovatore (talk) 19:56, 25 November 2018 (UTC)

  • You just have an alt with a different password in those situations, which is what most admins do. TonyBallioni (talk) 19:58, 25 November 2018 (UTC)
    OK, fine. What about if someone forges an SSL cert? You won't know when that might happen. --Trovatore (talk) 20:08, 25 November 2018 (UTC)
    Trovatore, An alternate account with 2FA on it as well? In any event when I go out, I never login to public devices. My laptop always comes with me. —CYBERPOWER (Chat) 20:15, 25 November 2018 (UTC)
    Someone might use a forged cert to impersonate Wikipedia even when you're logging in from home, and capture your password. Look, the details aren't important. The point is that there are lots of ways passwords can be captured, not just brute-forced. If you have 2FA, you can accept these risks and relax a little bit. If you don't, you can try to figure out all the attack vectors, which is a full-time job for highly paid people, or you can accept the risks and just hope. --Trovatore (talk) 20:21, 25 November 2018 (UTC)
    Would the alt have admin privileges, even if clearly identified as a second account? --Masem (t) 17:13, 26 November 2018 (UTC)

Trovatore makes some very good points. There are indeed more ways to attack your login than just a brute force or dictionary guessing attack. Even the "In any event when I go out, I never login to public devices. My laptop always comes with me" method desribed above could be vulnerable to a hidden camera attack or an Evil maid attack. There was a case where an Israeli counter-terrorism unit hired a magician to do a quick swap of a cellphone sitting on a desk with the owner right next to it, some other spies in the next room quickly cloned everything on the cell phone into another one with some special hardware built in, then the magician did another quick switch. Also see: 11 ways to hack 2FA and Security News This Week: Oh Good, Hackers Beat Two-Factor to Rob Bank Accounts

In our case, we aren't terrorists or spies and are extremely unlikely to receive such individual attention. For us, the most likely attack is someone trying multiple Wikipedia accounts looking for a guessable password. A less likely but still plausible threat is someone bribing/threatening a key WMF employer, gaining access to our list of password hashes, and doing a high-speed brute force password-guessing attack.

2FA is fine, until someone concludes that 2FA means they don't have to choose a passphrase that is easy to remember and hard for a high-speed offline passphrase-guessing program to guess. --Guy Macon (talk) 07:42, 26 November 2018 (UTC)

Account security is only as good as its weakest point. Anarchyte (talk | work) 08:30, 26 November 2018 (UTC)
...usually. If either guessing your passphrase OR faking your fingerprint will give the attacker access, then both your passphrase and the fingerprint reader have to be resistant to attack -- the system is indeed only as good as its weakest part. but if guessing your passphrase AND faking your fingerprint are needed to give the attacker access, the system is at least as good as its strongest part. --Guy Macon (talk) 00:10, 28 November 2018 (UTC)
2FA is a "both" scenario, though. If I turn on 2FA and make my password "password", an attacker still needs my rapidly-rotating and device-dependent 2FA token to log in to my account. Ivanvector (Talk/Edits) 17:06, 6 December 2018 (UTC)

Parallel discussion

Trying to kick this thing back awake, and also noting that there are several other discussions regarding nearly-inactive admins at WP:BN right now that have some very interesting points, including lists of admins who have hung on to the tools despite not using them for 5-10 years or longer. Beeblebrox (talk) 05:34, 6 December 2018 (UTC)

For the record, the WMF's own "make 2FA mandatory for admins" discussion is over here. Jo-Jo Eumerus (talk, contributions) 07:05, 7 December 2018 (UTC)

Alternative better idea than mandatory 2FA

Admins would upload a .XYZ file when logging in. This file contains a 2048-bit public key that will be checked against Wikipedia's own Central Authority (for verifying Wikipedia admin account login purposes only), where each admin account has their own private key in PKCS 12 (.p12) file and a Certificate, on the server. Wikipedia would e-mail the public key files to the admins via the e-mail address registered to their account.

When the file is uploaded, the an internal verification server will decide by seeing if the public key provided in the file would be able to decrypt a message if it were to be encrypted via the private key on the server linked to the admins account. If it passes the verification, the login process is successful. If it fails, the verification server will request the Web host server to inform the client to display a access denied error message. Aceing_Winter_Snows_Harsh_Cold (talk) 23:49, 8 December 2018 (UTC)

This is essentially still a 2FA: something you know (your password), something you have (this certificate; with the challenge of certificate management across many devices to worry about. — xaosflux Talk 17:23, 9 December 2018 (UTC)

Announced that

Sonw close Just Fix it - FlightTime (open channel) 20:57, 27 November 2018 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

There needs to be stricter, or more visible, policy on the use of the sentence "On (date), (source) announced that" to start every new piece of information. For example, in Chevrolet Volt, "announced" appears 24 times. I found WP:ANNOUNCED, which is an essay by User:HuffTheWeevil. It is basically what I had in mind, but just shows the limited efforts of one inactive user. There is also WP:PROSELINE, which is another essay with the same basic idea, but does not include "announced" specifically. I feel like there are some users who just believe this is the right way to add new information to Wikipedia articles, rather than just stating the info as fact with a reference. A user warning/note template might help. --Vossanova o< 20:38, 27 November 2018 (UTC)

"Wikipedia articles should have compelling, well-written prose" is sufficient. We don't need to have a separate policy page for every possible kind of shitty writing out there. If you come across shitty writing; make it less shitty. WP:SOFIXIT is all the policy you need. You don't need pre-approval. --Jayron32 20:44, 27 November 2018 (UTC)
  • My gut instinct tells me to close this to save this onslaught that will happen but unfortunately I've been hung, drawn and quartered for closing here so shan't bother, Instead I'll repeat Jayron and say If you find an article that to put it bluntly is shit then FIX IT. –Davey2010Talk 20:48, 27 November 2018 (UTC)

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

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)

Proposed amendment to WP:LISTPEOPLE regarding the inclusion of lists of non-notable victims in articles about tragic events

Propose to add the following text to WP:IINFO (or some close facsimile should we decide to tweak the wording at any point):

5. Lists of victims In articles about tragic events, such as crimes or disasters, where people are killed or injured, bare lists of victims, which only compile names and basic information (age, birthplace, occupation, etc.) are to be deprecated. Victims of crimes and disasters and other tragic events may be named as a normal part of a quality prose narrative, but lists of victims names with no context are not useful to most readers anymore than lists of names are in other Wikipedia articles, and advice for creating lists of names of otherwise non-notable people are as applicable to victim's lists as anywhere else in Wikipedia. Victims lists are not accorded any special exemptions from the normal practices of creating lists of otherwise non-notable people.

Such changes are intended to avoid having to re-litigate the constant debates that happen over and over on various article talk pages. The matter has been under discussion at WP:VPIL for some time now, and there seems to be a general consensus to bring forward, for public consideration, the above addition. There was some concern over where to put this guidance, but WP:IINFO seems to be the place where it is most applicable. For the sake of organization, let's do the three section voting: Support, Oppose, and Discussion, where we can discuss tweaking the wording, make comments on our own or other's votes, change the target guidance page, etc.


  1. As nominator --Jayron32 19:40, 28 November 2018 (UTC)
  2. Absolutely - FlightTime Phone (open channel) 19:48, 28 November 2018 (UTC)
  3. Support - there is no need to include the names of non-notable victims at all in list form, and not in prose either, unless they played an active, notable role in the event (aside from dying) and they're participation is well sourced. Other than that, simply put; (with the one caveat) non-linked (red or blue) names do not belong. - wolf 03:31, 29 November 2018 (UTC)
  4. Support As per Wolf. I will make some other points in the discussion section. In particular I think we should establish that the default position is no non-notable names. Lyndaship (talk) 09:51, 29 November 2018 (UTC)
  5. Generally support, modulo the comments of Andy Mabbett and Iridescent, below. We definitely do need to avoid listing non-notable people, and we definitely do need to avoid having to re-re-re-re-re-fight this out page by page. We don't actually need to have the wording copyedited perfectly right here and now, so massaging like they want to do with it is fine, and is something we'd end up doing anyway over time.  — SMcCandlish ¢ 😼  13:12, 1 December 2018 (UTC)
  6. Support with a minor qualification. Whatever we do, I think the status quo is not working. The lack of clear guidance on this subject is leading to numerous, lengthy, and often acrimonious local debates. It's time we resolve this issue one way or another. IMO lists of non-notable victims is a form of unencyclopedic bloat that is contrary to both NOTEVERYTHING and, at least in spirit, NOTMEMORIAL. The only exception I would concede is in some rare cases a mass casualty EVENT may involve a number independently NOTABLE victims whose role in the EVENT was largely limited to their dying. In such circumstances a short list of such NOTABLE victims might be justifiable. Long lists of such, unless they are stand alone articles, should be avoided. -Ad Orientem (talk) 14:28, 3 December 2018 (UTC)
  7. Support seems to me a general rule is needed, but a list of non-notable victims seems to fail WP:NOTMEMORIAL. No problem with changing the copy edit to reflect only people who are not otherwise notable. SportingFlyer talk 22:20, 6 December 2018 (UTC)
  8. Support. It is Indiscriminate Info to include random names from the phonebook in an article, without a clear and significant encyclopedic-rationale for each individual name to be included. "They died" is not a reason. I'd like to draw attention to a specific phrase from the proposed text: may be named as a normal part of a quality prose narrative. It is my rationale and intention that a "quality prose narrative" equates with a clear and individual rationale why each name is necessary to adequately explain the events and coverage. Examples: A criminal who caused the events is always a core figure in any coverage. If there's one or two victims, the media typically provides in depth coverage of the individualized-victims in the narrative. If a killer hunts down a single targeted victim and also kills a bunch of random bystanders, the target invariably receives in-depth individualized coverage as part of the media narrative. If a celebrity was among the victims, that's invariably a major element in the reporting. If a responding police officer is killed while attempting to save people, they invariably receive unique coverage in the media narrative. If a victim preforms heroic efforts during the crisis, the reporting will give them individualized coverage as a significant player in the narrative. However we should not list random names merely because they died, merely because they were listed in reporting, merely because news report provided some routine info about each victim in systematic and indiscriminate manner with no real significance to the narrative of events. If twenty people die, and a random Jane Doe is a 28 year old mother of two, that sucks but it doesn't add any encyclopedic information. Twenty random people died, obviously they had families and loved ones. Random names and random personal details of random victims generally don't have historical significance. Alsee (talk) 02:57, 8 December 2018 (UTC)
  9. Generally support also, given the caveat expressed by Andy Mabbett. Bare lists of otherwise non-notable names do not add to the understanding of the topic. If the victims played some substantial role, for example due to their actions during the event, then it would be appropriate to include them in the description of the event. But I agree that they otherwise run afoul of NOTMEMORIAL and NOTDIRECTORY (#7). CThomas3 (talk) 07:25, 8 December 2018 (UTC)


  1. Unless "bare lists of victims" in the first sentence is changed to something like "bare lists of non-notable (i.e. not blue-linked) victims". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:39, 28 November 2018 (UTC)
  2. Oppose as worded; I agree with the principle that we shouldn't include long lists of non-notable people involved in any incident (victims or not), but having a flat-out rule that victims can only be listed in prose would have far too many false positives. If those voting support really think otherwise, feel free to turn Wikipedia:Articles for deletion/Emergency workers killed in the September 11 attacks, Wikipedia:Articles for deletion/List of victims of the Bazar de la Charité fire, Wikipedia:Articles for deletion/List of investors in Bernard L. Madoff Investment Securities or Wikipedia:Articles for deletion/List of victims of Nazism blue and see what happens. (The last time AFAIK that this principle was seriously tested was Wikipedia:Articles for deletion/List of victims of the Babi Yar massacre; yes, that was a long time ago and consensus can change but I find it unlikely it will have changed to that extent.) ‑ Iridescent 22:49, 28 November 2018 (UTC)
  3. Simple Oppose per WP:KUDZU. Should be decided on article Talk pages. Some of those who have largely refused to engage in dialogue on article Talk pages are now pushing for a top-down solution to their issue with lists of non-notable victims of disasters. Let them use the article Talk page to actually engage in dialogue with those editors with whom they disagree. Bus stop (talk) 15:20, 29 November 2018 (UTC)
  4. This topic has been discussed to death, a general consensus is that this is to be handled on a case by case basis. - Knowledgekid87 (talk) 16:24, 29 November 2018 (UTC)
  5. Victims should be included only if there is a reference for them. —Eli355 (talkcontribs) 01:02, 30 November 2018 (UTC)
    @Eli355: If we know a name, there is a reference (source) for it. That's where we get the name. Thus your argument as written is that all reported names should be included in the Wikipedia article. For every modern-day mass killing, there is at least one source for the names of all of the dead, as here. Thus your position as stated is that all modern-day mass killing articles should list the names of all of the dead. Is that what you intended? ―Mandruss  04:03, 8 December 2018 (UTC)
    "Thus your argument as written is that all reported names should be included in the Wikipedia article." No, I think you are drawing an unreasonable derivation from what was stated, Mandruss. A more conservative conclusion would be that "all reported names could be included in the Wikipedia article." Bus stop (talk) 05:00, 8 December 2018 (UTC)
    Thanks, but please let the editor speak for themselves. ―Mandruss  05:07, 8 December 2018 (UTC)
    There is a difference between "victims should be included only if there is a reference for them" and "victims should be included if there is a reference for them." And it is as absurd to think we must include the names as to think we must not include the names. Bus stop (talk) 05:52, 8 December 2018 (UTC)
    "Thanks, but please let the editor speak for themselves." - seems pretty straight forward, yet you keep posting. How about not posting and just wait for Eli355 to respond to the question that was asked of them? - wolf 06:24, 9 December 2018 (UTC)
    thewolfchild—User:Eli355 wrote that "Victims should be included only if there is a reference for them." They did not write that it is mandatory that reliably-sourced, non-notable victims be included in an article. You might consider asking all editors that oppose a community-wide ruling whether or not they feel it is mandatory that reliably-sourced, non-notable victims be included in an article. This discussion is degenerating into a badgering of one editor on a flimsy if not entirely inapplicable point on something they may or may not have said. Bus stop (talk) 14:37, 9 December 2018 (UTC)
    Jeee-zzuz... you just just can't help yourself, can you? Two editors have now asked you to stop replying for Eli355 so that they will hopefully clarify their answer. So please, just stop already. - wolf 19:17, 9 December 2018 (UTC)
    @Mandruss: That is what I intended. —Eli355 (talkcontribs) 20:46, 9 December 2018 (UTC)
    Which interpretation does "that" refer to?  — SMcCandlish ¢ 😼  06:52, 12 December 2018 (UTC)
    @SMcCandlish: All modern-day mass killing articles should list the names of all of the dead.Eli355 (talkcontribs) 01:10, 13 December 2018 (UTC)
    A fresh trout has been delivered[8].  — SMcCandlish ¢ 😼  01:37, 13 December 2018 (UTC)
    SMcCandlish—policy-level decisions should be implemented when there is an important issue at stake. But there is no important issue at stake in this discussion. I have heard the argument that there are debates. So what? In my opinion debates are commonplace and potentially constructive. And I'm not aware of any article that has suffered from either the inclusion or the omission of non-notable victim names. Bus stop (talk) 02:59, 13 December 2018 (UTC)
    I'm not aware of any article that has suffered from either the inclusion or the omission of non-notable victim names. You've made that statement before. The obvious logical fallacy has been pointed out to you before, but I'll point it out to you one more time. You're not aware of any such article because you disagree with the arguments against the lists. Thus you're essentially saying that you're right because you're right. That is not an argument, and I hope you will stop presenting it as one. ―Mandruss  03:30, 13 December 2018 (UTC)
    Mandruss—the burden is on you to tell us not only why non-notable victims should not be included in articles but also why policy should be enacted to curtail the inclusion of information pertaining to non-notable victims. A question of this nature is obviously resolvable on an article Talk page. Why are you trying to enact policy to curtail the inclusion of information pertaining to non-notable victims? That isn't a rhetorical question. That is a question for you to actually attempt to address. I think the burden is on you to present the case for the policy you are trying to enact. Bus stop (talk) 14:34, 13 December 2018 (UTC)
  6. The individual talk pages should be used to work this out case by case. I agree that references are needed and that it is better to use prose. But a bare list is a transition from nothing to paragraphs of writing. So if we make a blanket rule we placing a higher hurdle to get over to improve the articles. Graeme Bartlett (talk) 07:35, 3 December 2018 (UTC)



As I indicated at VPI, the effect for random mass killings articles will be that editors who want the victims named (for any of a number of reasons, not always openly stated) will simply write "quality prose narratives" that include every victim. The necessary material is almost always gathered by a handful of news organizations who have a different mission (and a profit motive), this CNN article being a typical example. This tactic will defeat the spirit of the guideline and, far from putting an end to the endless battle in this area, will merely change its nature. At VPI I said I would suggest an improvement after sleeping on it, but I have failed to come up with anything. I think we just need more and better minds thinking about it.
It would be easy to say that nobody should be named who doesn't have a Wikipedia article, but I'm not sure that's not too high a bar. It's higher than at WP:BLPNAME, which in my opinion shares the presumption of privacy with this issue. I wonder whether the test should be something more like "a substantial active role in the event". We would still differ on the definition of "substantial" (and maybe there's a better adjective) but we would clearly exclude the vast majority of names of victims, who had no active role. Trying to hide and running away are not active roles. Staying behind to hold a door open for fleeing students is borderline in my opinion. Physically attacking the shooter would be a substantial active role. ―Mandruss  23:51, 28 November 2018 (UTC)

This is an ongoing and continuous bone of contention. I feel that although the inclusion of non notables can be discussed on a case by case basis on article talk pages the default position should be no non notables unless agreed by consensus, ie the burden for inclusion should always fall on the proposer, with no squatters rights. Therefore I would support Generally victims should not be mentioned by name unless they were otherwise notable or had significant and substantial involvement in the incident (beyond being a victim). If challenged consensus must be established to include Lyndaship (talk) 10:01, 29 November 2018 (UTC)
as opposed to a non-continuous bone of contention? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:08, 29 November 2018 (UTC)
LOL ok. I suppose I could argue there have been breaks? Lyndaship (talk) 16:31, 29 November 2018 (UTC)
I have a feeling that while I would support this, we need to have a guidance page of how to handle naming victims of a crime/event when you omit the list (too much to cover in an policy page). --Masem (t) 17:16, 29 November 2018 (UTC)
  • @Pigsonthewing and Iridescent: and Lyndaship, if you actually agree with the principle, or the basic initiative here, then why 'oppose'? How about 'support with a condition (or caveat)? Or post a "neutral" !vote (unfortunately there wasn't a 'neutral' section, that's been rectified). It would be unfortunate if this died because of a perceived consensus to oppose when really some of you actually support, but just want some kind of minor wording change. - wolf 10:23, 3 December 2018 (UTC)
    • I had supported the proposal Lyndaship (talk) 10:52, 3 December 2018 (UTC)
      • @Lyndaship: Yup, I see that now. Sorry about that, I don't how your name got added there, other than I was trying to do too much in a single edit and goofed up. Mea culpa, ambo te ignosce me. - wolf 15:51, 3 December 2018 (UTC)
    • For the reason I gave in my !vote. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 00:49, 4 December 2018 (UTC)
  • @Eli355:, can you clarify your position on here? The very brief wording of your "oppose" give the impression you might actually 'support' this proposal. Thanks - wolf 10:23, 3 December 2018 (UTC)
    • @Thewolfchild: People should be included in these lists if there is some reference for them. —Eli355 (talkcontribs) 00:58, 4 December 2018 (UTC)
      • @Eli355: Uh, yeah... I saw that the first time you posted it. Like Mandruss pointed out above, we only know about names if there listed in a source. That's the point of this proposal, that shouldn't be the only basis for entry to an article. There should be a more encyclopedic reason. Do you understand that? - wolf 06:36, 9 December 2018 (UTC)
        • "that shouldn't be the only basis for entry to an article" That is correct, thewolfchild. Verifiability is not sufficient for inclusion. WP:VNOTSUFF: "While information must be verifiable in order to be included in an article, this does not mean that all verifiable information must be included in an article." But should we be deciding whether or not to include this information at the Village pump? Or should we be deciding this at individual article Talk pages? Bus stop (talk) 16:33, 9 December 2018 (UTC)
          • Seriously... not even reading your posts anymore. - wolf 19:17, 9 December 2018 (UTC).
            • @Thewolfchild and Bus stop: Whether the victims names should be included in the article should depend on the number of victims. If an event kills a few people, all of them should be listed, but if an event kills thousands of people, than only the more notable people should be included. —Eli355 (talkcontribs) 20:51, 9 December 2018 (UTC)
              • @Eli355: You made a rather vague a comment about names being added if there is a reference for them, you're asked to clarify it, and in response you make an equally vague comment about names being added based on numbers? Can you provide a more substantive reply to support your position on this issue? Thanks - wolf 21:15, 9 December 2018 (UTC)
                • thewolfchild—I made the same point that Eli355 is making when I said to you "My opinion is that victim identities belong in articles on disasters where practicable." It is practicable to add a small number of victims; it is impracticable to add a large number of victims. We also know that policy states: "While information must be verifiable in order to be included in an article, this does not mean that all verifiable information must be included in an article. Consensus may determine that certain information does not improve an article, and that it should be omitted."[9] Therefore without this proposal being passed the victim names can be omitted. Bus stop (talk) 22:45, 9 December 2018 (UTC)
  • This discussion started on WP:VPIL where back on 30 Novemebr I posted "Short numbers of names (as proposed by Herostratus above take up a handful of bytes and don't seem too out of place (users read articles, not policies). For longer lists why not simply create a page "List of victims of XYZ" and hat-note to it?". Whether that opinion is right or wrong, it is depressing that nearly three weeks later exactly the same point is being vehemently argued over. Martin of Sheffield (talk) 23:19, 9 December 2018 (UTC)
  • Okay... Eli, whether this is deliberate bullshit or just a WP:CIR issue, either way I don't care. I don't want you to clarify your opinion as I'm no longer interested in it. Have a nice day. - wolf 04:36, 13 December 2018 (UTC)
  • @Bus stop, Knowledgekid87, and Graeme Bartlett: - each of you had stated in some form that this should be handled on individual talk pages, but one of the reasons why we're here is because that approach has failed over and over again, for years. And even in the odd cases where there was an agreement on particular article talk pages, that has just led to conflicting local consensuses, which in turn leads to wp:ose arguments in this project-wide dispute that has carried on for years without resolution. That is why we need a project-wide policy/guideline to (hopefully and finally) help settle this once and for all. (or for the most part, for awhile, at least). - wolf 10:23, 3 December 2018 (UTC)
thewolfchild—this is not a question that should be addressed on a community-wide basis. My opinion is that victim identities belong in articles on disasters where practicable. Any time you come up with a one-size-fits-all solution you run the risk of deadening the creative abilities of editors that are champing at the bit to write better articles. Why not just let editors write articles and engage in debate as needed? There shouldn't be a "default" position on something that does not have a consistent identity across all articles, namely "victim lists". And by the way, I do not distinguish between "lists" and "prose" as concerns the mention of victims in articles on disasters. Whichever form fits the specifics of that particular article at that particular stage in its development should be used. And if WP:CONSENSUS is to omit the names—that's OK too. The interested editors are not the same at the article in question as the editors weighing in here. Why devise nonsensical policy here to tie the hands of editors at the articles that will inevitably be affected? Bus stop (talk) 15:44, 3 December 2018 (UTC)
Yes... BS, we're all well aware of your opinions on this, but you've adding nothing new here with your latest repeat posting of them. (Question, why all the wiktionary links? And, despite using said link, how does one still manage to misspell the word they're actually linking to said dictionary?)
Anyway, you made some grossly misleading comments here. Should this proposal be added to WP policy, in no way will it "deaden the creative abilities of editors that are champing at the bit to write better articles.".
First of all, adding obituary-type lists of meaningless, non-notable names of mass-death-event victims, does not make for "better articles". Second, no one's "hands are going to be tied". If at some point, some editor has a burning need to add an obituary-type list of meaningless, non-notable names of mass-death-event victims to some article, they can always come here and seek a community-wide consensus to change the policy. If the need to add said list is that great, and it will make said article that much better, then I'm sure the community will see that and support said editor.
As for editors who are not currently here to take part in this process, that just sounds like you're trying to create some kind of pre-emptive excuse. This forum is open to everyone. This subject has been discussed on numerous pages, for months, from the USS Fitzgerald and MV ACX Crystal collision talk page, to numerous other article, project and AfD discussion pages, leading to the idea lab and finally here. If these editors that you apparently don't know, and yet you're so concerned about them missing out on this proposal do in fact miss out... oh well. Can't expect everybody to be everywhere, everytime. - wolf 18:14, 3 December 2018 (UTC)
thewolfchildhere is a good explanation of "champing" vs. "chomping". From your aloof perch here at the Village pump you are in no position to dictate to editors whether they should include or omit names and other brief pieces of information on non-notable individual fatalities resulting from an article's topic. This is an instance of Wikipedia trying to shoot itself in the foot. You've yet to tell us why we should not speak of non-notable decedents. Bus stop (talk) 19:10, 3 December 2018 (UTC)

─────────────────────────"thewolfchild — here is a good explanation of "champing" vs. "chomping". Bus stop 19:10, 3 December 2018 (UTC)"

  1. Erm, BS... surely you realize that was a rhetorical question? (as this one is)
  2. You clearly missed the point of that question.
  3. I am already familiar with the expression.
  4. I am already aware of the alternative spellings.
  5. I have no idea why you think I would be interested in any further reading or discussion about this expression, it's meaning, or it's alternative spellings.
  6. I take it you're aware that your comment is both meaningless, and completely off-topic.
  7. I take it that by posting such a meaningless and completely off-topic comment, you are declaring you have nothing new or meaningful to add to the topic being discussed?
  8. Oops, nevermind. I see that while I was typing out my reply, you have since added more to your comment. While your remarks are somewhat snarly and accusatory, I suppose it could be considered "on-topic" (saving your initial comment (quoted above) from being deleted). I'm not on a "perch", I behind a keyboard, just like you, and you seem to have a bizarre definition of "aloof", (here, happy to help out).
I am not "dictating" anything. I'm taking part in a straw-poll and discussion regarding a policy proposal, just like you. (though I'm just being nicer than you are) If I'm not "in a position to dictate to others" that they can't include names... how is it that you seem to think you are "in a position to dictate to others" that they can't omit names?
"This is an instance of Wikipedia trying to shoot itself in the foot." - Umm... ok. Maybe you should take that up with Wikipedia. (I, otoh, am not trying to shoot anything)
"You've yet to tell us why we should not speak of non-notable decedents." - You've yet to explain how adding a list of non-notable names, of mass-death-event victims, who played no role in the event, except for dying, with no meaning to anyone except perhaps for family & friends, will in any way lend to the reader's understanding of the event. If 10 non-notable people died, what more is needed, than to state that 10 people died? Relevant, supporting information such as how they died, when they died (immediately vs later in hospital, etc. notwithstanding, how does adding a list of names add anything remotely encyclopaedic to the article? What insight can that possibly provide to the reader?
Now, this is the part where you don't actually answer questions, you counter them, with a revolving repertoire of circular logic, IDHT & IDLI tautological arguments, off-topic rants, and demands for answers that have already been provided to you, multiple times by multiple editors. Then lather, rinse, repeat... do the whole thing all over again with whoever is willing to respond to you.
As I said earlier, we are all well aware of your opinion on this. Unless you have anything new to add, (about the topic, not me, not some idiom, not about some pair of neat-o shoes you saw at the mall... ), then please stop pinging me. Thank you. - wolf 21:12, 3 December 2018 (UTC)
thewolfchild—you say "how is it that you seem to think you are in a position to dictate to others that they can't omit names?" I didn't say we "can't omit names". I said "if WP:CONSENSUS is to omit the names—that's OK too." And I said that there shouldn't be a default on this. Let the editors decide on the article Talk pages. And I don't recall referring to some pair of neat-o shoes I saw at the mall. And if you scroll up you will see that you pinged me before I pinged you and you have pinged me a total of two times. Have I pinged you more than 2 times? Maybe, for which I apologize. Bus stop (talk) 22:00, 3 December 2018 (UTC)

Question for Jayron32: The section heading says you want to put this text in the guideline WP:LISTPEOPLE. The proposal says that you want to put this in the policy WP:IINFO. Can you pick one or the other, and fix the proposal? WhatamIdoing (talk) 03:39, 8 December 2018 (UTC)

Succession boxes

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

Replace succession boxes with template navboxes

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)

Proposal: changes to the Rollback policy

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 [11]. Sure enough, see [12]. 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. –Davey2010Talk 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. –Davey2010Talk 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 (utc) 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 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)
    Rollback and Twinkle diff.png
    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 (talkcontribs) 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)

Interaction between Page Mover and File Mover

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? GMGtalk 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 CarteletTalk 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. GMGtalk 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. GMGtalk 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. GMGtalk 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.) GMGtalk 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". GMGtalk 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. GMGtalk 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. GMGtalk 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)
  • 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
    ) 15:01, 13 December 2018 (UTC)

RfC: authority control

This RfC concerns the function of {{Authority control}}.

  1. Should the authority control template link to websites that are not primarily databases (i.e. websites where the primary content is not a database structure)?
  2. If non-databases should be linked to, should any particular groups of external identifiers be excluded from the template based on the type of content (e.g. news, open wikis, TV broadcasters' listings, social media, ...)?
  3. Should the template link to databases/websites where anyone can edit or add content without a moderator's permission, such as MusicBrainz, IMDb and Discogs (and including sites like Twitter, where the relevant identifiers are user account IDs or post IDs)?
  4. Should the template link to websites which are not operated by governments or non-profit organizations, such as YouTube, AllMusic, Quora and the New York Times?
  5. (added afterwards) Should a new template be created to show other external links (those not to be included in the authority control template) from Wikidata?
  6. (added afterwards) If such a template is created: (a) should it be a navbox, a bulleted list, or a comma-separated or horizontal list (like fr:Modèle:Bases musique); (b) should it group links by their content type; (c) should it only show selected groups of links based on a parameter's input (e.g. news websites, social media, ...); (d) should it accept local values for external identifiers (as opposed to only allowing Wikidata data); (e) should the format "Website: ID" or the format "Website" (or a different format) be used to display links?

Jc86035 (talk) 09:26, 7 December 2018 (UTC) (edited 12:12, 12 December 2018 (UTC))


{{Authority control}} is Wikipedia's authority control template, and is used on about 900,000 pages. Most identifiers are automatically transcluded from Wikidata. Wikidata has about 3,443 external identifier properties, and {{Authority control}} uses 54 (1.6%) of them.

In previous years, there has been some discussion on Template talk:Authority control regarding adding other types of external links. However, none of those discussions have resulted in changes to the template.

Currently, all identifiers except those for MusicBrainz are (to my knowledge) for non-commercial authoritative bibliographic databases. I (Jc86035) added identifiers for MusicBrainz, Discogs, AllMusic and IMDb last week, on the grounds that there was already a MusicBrainz identifier (which was added in 2013 by Legoktm). I was able to do this because I am a template editor and did not get reverted by another template editor. The four aforementioned databases are either user-generated or commercially operated, and are less clearly "authority control" than the other linked databases. KokoPhantom contested my addition of the Discogs identifiers on the talk page. (I have since removed the new identifiers except for the MusicBrainz ones.)

The Russian Wikipedia's version of the template ("Template:External links") has a rather larger variety of external links, including identifiers for Twitter, GitHub, Anime News Network, IGN, Find a Grave and Encyclopædia Britannica Online. (However, they are all shown separately to the "authority control" section.) As an example: Judi Dench#External links (on this wiki), and on ruwiki. (The Russian Wikipedia's template groups identifiers into "social media", "photo, video and audio", "thematic sites", "dictionaries and encyclopedias" and "authority control". On Dench's article only the latter three are shown.)

Survey (authority control)

Questions 1, 3, 4 and 5 are intended to be yes/no questions. It might also be appropriate to answer "only noncommercial websites" for question 3 and "only user-generated websites" for question 4.

If consensus is in favour for questions 1, 3 or 4, then the template would most likely be changed to show non-authoritative links in different sections (as in the Russian Wikipedia's template), and new identifiers would be added for those categories based on the results of the RfC, and based on further discussion (likely at the template's talk page). The template's name may stay the same to avoid confusion. Depending on the consensus for questions 2 and 3, the MusicBrainz links may be removed.

Question 1 (linking to non-databases)

  • Yes. There are many valuable websites (e.g. news websites) which organize their content by topic, and showing these links would enable readers and editors to find more information than Wikipedia has, if desired. Also, many websites with a more specific focus may already have their own Wikidata identifiers, such as World of Physics identifier (P5064). Jc86035 (talk) 09:26, 7 December 2018 (UTC)
  • No there should be a separate external links template if this is planned.Otherwise it sounds like we are trying to provide a box for the "organised internet" which could conceivably go on almost forever. The AC boxes are already monstrous and we should keep them narrow and focused for the benefit of readers. --Tom (LT) (talk) 01:15, 8 December 2018 (UTC)
  • No The purpose of authority control is the organization of bibliographic data, and so the template should link to databases which can give bibliographic information and additional information. It's an organizational tool, not a list of links to sources. Wugapodes [thɑk] [ˈkan.ˌʧɹɪbz] 02:14, 8 December 2018 (UTC)
  • No per both of the above. I'm not particular hostile to the idea of a separate template for this expanded use, especially if it might reduce the actual footprint of "External links" sections, and regulate their input in some way so that the output is more consistent. If it were templated, it might even help in some future ways in patrolling for spam (e.g. auto-detect inclusion of certain domain names that are often junk or copyvio links, etc.)  — SMcCandlish ¢ 😼  06:11, 10 December 2018 (UTC)
  • No. We're not a directory, and this template is intended for authority control not "everything on this topic anywhere on the internet". Nikkimaria (talk) 03:30, 11 December 2018 (UTC)
    • What a tiresome straw man argument. No one is asking to link to "everything on this topic anywhere on the internet". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:17, 13 December 2018 (UTC)
  • No. AC should be an understandable tool for providing reliable bibliographic data. The linkfarm monstrosity in the Russian example is not something to emulate. KokoPhantom (talk) 16:30, 12 December 2018 (UTC)
  • No. Out of scope for this template. --Ahecht (TALK
    ) 17:05, 12 December 2018 (UTC)
  • No. AC is for bibliographic data, not link farming. Kaldari (talk) 20:49, 12 December 2018 (UTC)
  • No. The template should link to a small group of reliable, high quality, relevant, non-commercial, non-wiki databases. Even without things liks musicbrainz, it has way too many useless links (for enwiki readers) already, links from national libraries which are not in English and not in a language or country relevant for the subject, but which happen to be an authority control. Links which are added by default should be very, very limited. Wikidata is the perfect location to function as linkfarm for all these, from the truly authoritative to the near-junk ones (Quora?); enwiki should restrict this to much less than we have now, and excluding the "not primarily databases" is a good start. Fram (talk) 11:09, 13 December 2018 (UTC)
    • The language or location of the target site is irrelevant to the purpose of comparing authority control identifiers. I do believe that this has been explained to you previously. Your reference to Quora is a straw man, as it is not included in {{Authority control}}. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:17, 13 December 2018 (UTC)
      • This has been explained to me previously, and I still disagree that "the purpose of comparing authority control" is something enwiki should be used for. We have Wikidata for these kind of purposes, that's the difference between that general platform and a text encyclopedia like enwiki. Wikidata is multilanguage, enwiki is single language, so the "language or location of the target site" is immediately relevant. We have general rules not to include similar non-English links when we have comparable links in English, but for AC this may not apply? Why? Quora is not a strawman, it is included in Wikidata as an identifier. What should be included in the template authority control is exactly what we are discussing here, and giving examples of identifiers which are available on Wikidata and could easily be added to the template, but which I (and most of us) do not want to see included in enwiki, is definitely not a strawman argument. Please don't answer to me if you have nothing constructive to add. Fram (talk) 16:42, 13 December 2018 (UTC)
  • No - Agree with Fram. This is not what the AC template is for. Blueboar (talk) 13:57, 13 December 2018 (UTC)
  • Comment: The questions is badly phrased What does "not primarily databases" mean? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:17, 13 December 2018 (UTC)
  • No That would be stretching the point of the authority control template a bit far. — AfroThundr (u · t · c) 01:21, 14 December 2018 (UTC)

Question 2 (exclusion of particular groups of identifiers)

  • None that I can think of, although it's worth noting that it would be technically possible to e.g. only show Facebook ID (P2013) if there are no other identifiers to be shown (in its section or overall), as it may be considered unnecessary or even dubious if other identifiers are readily available. Jc86035 (talk) 09:26, 7 December 2018 (UTC)
  • Yes the AC template should point only to items relevant to the subject matter of the article, regardless of the technical means to achieve this, and not a potpourri of every available item. --Tom (LT) (talk) 01:17, 8 December 2018 (UTC)
  • Non-databases shouldn't be linked to. I agree with Tom above, it should point to things relevant to the subject not every possible item about them (hence why the links should only be to databases). This template shouldn't turn into a database of databases. Wugapodes [thɑk] [ˈkan.ˌʧɹɪbz] 02:14, 8 December 2018 (UTC)
  • Maybe. I'm not entirely clear what this is asking and what use-cases might be, so I'm not willing to say "no" to the very possibility of being exclusive. I do agree with the "not a potpourri of every available item" reason offered immediately above.  — SMcCandlish ¢ 😼  06:13, 10 December 2018 (UTC)
  • Yes, see my answer above. Fram (talk) 11:09, 13 December 2018 (UTC)
  • Yes - Completely agree with Tom, Wigapodes and SMcCandlish. If Wikidata wants to be a database of databases, fine... but that isn’t appropriate for WP.en Blueboar (talk) 14:04, 13 December 2018 (UTC)
  • No. The question is vague, and this is not something that can be decided at a general level. Whether or not a specific site should be linked to by the template is a matter for discussion at Template talk:Authority control. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:26, 13 December 2018 (UTC)
  • Yes In a general sense, not every identifier is likely to be appropriate or should be displayed, but that is a case-by-case decision. — AfroThundr (u · t · c) 01:21, 14 December 2018 (UTC)

Question 3 (openly editable and user-generated websites)

  • Yes; we've already been linking to MusicBrainz with this template for more than five years. Even if we're not going to use them as sources there is nothing inherently wrong with supporting other open wikis, and linking to user IDs is already done on many pages through the numerous external link templates (e.g. {{Instagram}}, which uses Instagram username (P2003)). Authoritative identifiers are also not error-proof, so being able to corroborate information from more sources would be valuable. (Of course, the relevant data has been present in Wikidata for some time, but almost no one actually reads Wikidata items.) Jc86035 (talk) 09:26, 7 December 2018 (UTC)
  • No The template should point to reliable bibliographic data. User generated and openly editable information is not that. Wugapodes [thɑk] [ˈkan.ˌʧɹɪbz] 02:14, 8 December 2018 (UTC)
  • Yes. We're already doing it, and these are not reference citations or anything like them. This is an external links template, so anything that would qualify to be in an articles's EL section is permissible here (possibly with the "databases only" limitation in question 1 above, which is a utility matter not a "who wrote it and do I like them" matter). Various sites like MusicBrainz,, and IMDb are plenty reliable enough to be useful as ELs, we just don't cite them as sources because they are WP:UGC.  — SMcCandlish ¢ 😼  06:06, 10 December 2018 (UTC)
    • Expanding this to include "anything that would qualify to be in an articles's EL section" would be the result of a "yes" result on the first question, but for the moment that's not what this template is actually for. Nikkimaria (talk) 03:30, 11 December 2018 (UTC)
      • That's why I clarified with 'possibly with the "databases only" limitation in question 1 above'.  — SMcCandlish ¢ 😼  01:57, 12 December 2018 (UTC)
  • As a general rule no, although it may be warranted in specific cases. If this does pass it should be implemented only (a) in accordance with WP:EL and (b) with explicit per-link consensus. This passing shouldn't be taken as open license to add every wiki under the sun. Nikkimaria (talk) 03:30, 11 December 2018 (UTC)
  • No. AC is defined as links "to bibliographical records on worldwide Library catalogs". Readers have a rightful and reasonable expectation that such links will be reliable. KokoPhantom (talk) 16:49, 12 December 2018 (UTC)
  • Yes it's a delusion that worldwide library catalogs are perfectly reliable. They copy from each other, and they copy from WP. Other sources can be just as reliable. DGG ( talk ) 02:17, 13 December 2018 (UTC)
  • No, see my answer above. The reasoning that because the Library of Congress is not perfectly reliable, we should also include open wiki's is rather alarming. Fram (talk) 11:09, 13 December 2018 (UTC)
  • No - not reliable. Blueboar (talk) 14:07, 13 December 2018 (UTC)
  • Yes. In the case of MusicBrainz, for example, it's common throughout the industry, and bodies as August as the BBC use and link to it. It is not as though this is being used to assert notabilty. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:11, 13 December 2018 (UTC)
  • Yes In general and especially for MusicBrainz. Identifiers aren't meant to serve as reliable sources, and other community-driven projects can provide valuable additional info on a topic. — AfroThundr (u · t · c) 01:21, 14 December 2018 (UTC)

Question 4 (commercially operated websites)

  • Tentatively, yes, since we already do this through a large number of other templates, and automating it through {{Authority control}} would allow this to happen more effectively for the appropriate identifiers. Not every corporation's website counters the Wikimedia movement's goals, and we happen to use some of them very often as sources anyway. Jc86035 (talk) 09:26, 7 December 2018 (UTC)
  • Meh Only when necessary. Wugapodes [thɑk] [ˈkan.ˌʧɹɪbz] 02:14, 8 December 2018 (UTC)
  • Yes. Not being a charity doesn't magically translate to "untrustworthy". The publishers of about 99.999% of what we cite as reliable sources are for-profit entities. (And being governmental doesn't make something magically trustworthy either.)  — SMcCandlish ¢ 😼  06:05, 10 December 2018 (UTC)
  • no, see my answer above. Adding such links individually on articles, okay, sometimes. Adding such links by default to every article possible, no thanks. We should limit the links of external links, not try to maximalize these, and certainly not add commercial websites by default. Fram (talk) 11:09, 13 December 2018 (UTC)
  • It depends - Fram has it right. That said... The real question isn’t governmental vs commercial... the question is automated linking vs manual linking. Blueboar (talk) 14:12, 13 December 2018 (UTC)
  • Yes of course. We - rightly - have no general prohibition on linking to or citing commercial sites, and this template should be treated no differently to rest of Wikipedia in that regard. Whether or not a specific site should be linked to by the template is a matter for discussion at Template talk:Authority control. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:22, 13 December 2018 (UTC)
  • Yes Just because a site is primarily commercial doesn't mean it's somehow untrustworthy as a source of authority control info, but this is also a case-by-case decision. — AfroThundr (u · t · c) 01:21, 14 December 2018 (UTC)

Question 5 (separate Wikidata external links template)

  • Yes, if those links shouldn't be shown in the authority control template. This would allow us to better organize external links and have useful links be displayed on more articles. Jc86035 (talk) 12:12, 12 December 2018 (UTC)
  • Yes, conditional on Questions 3 and 4, of course. – Jonesey95 (talk) 14:57, 12 December 2018 (UTC)
  • No. We're still not a directory, and blanket linking of this sort would not be in accordance with the external links guideline. With the possible exception of official websites, links should be considered on an article-by-article basis; even links that are commonly used may not be universally appropriate. Nikkimaria (talk) 01:47, 13 December 2018 (UTC)
  • In theory, per Jc86035, and if it would help limit indiscriminate link-dumping into articles. We have needed to re-think our approach to "External links" sections for some time now.  — SMcCandlish ¢ 😼  03:43, 13 December 2018 (UTC)
    • if it would help limit indiscriminate link-dumping into articles - how do you anticipate it would do that? I don't think it's feasible for example to say that only ELs in this template could be included, as there will always be some ELs that are useful but not covered by properties on Wikidata. If anything a template of this type would increase indiscriminate link-dumping. Nikkimaria (talk) 04:29, 13 December 2018 (UTC)
      @Nikkimaria and SMcCandlish: Presumably there wouldn't be too many external links not allowable in Wikidata (given that official website (P856) can be and is used)? Usually the reasons for not allowing identifier properties (and it seems very rare for there to be no consensus for them) are "this identifier isn't stable", "this website enables copyright infringement" or "this is a search string and not an identifier", which seem broadly in line with our external links policy. There are also described at URL (P973) and described by source (P1343), which the proposed template might or might not handle (the ruwiki template uses P1343 for some Russian-language encyclopedia articles which have their own Wikidata items, and possibly some other sources). Jc86035 (talk) 10:11, 13 December 2018 (UTC)
      Passing through "described at" as a catch-all would definitely increase indiscriminate link-dumping, and EL definitely excludes more than just copyvio and search strings. Nikkimaria (talk) 12:28, 13 December 2018 (UTC)
      I meant more that in a navbox-style template the material would be compressed, so if someone added the same thing in big, long form to the EL section we'd delete it. We'd likely also have grounds to delete similar links that don't add anything useful (e.g. if the template already produces something for looking up a book at Worlcat, we'd delete any additional book-lookup links).  — SMcCandlish ¢ 😼  13:33, 13 December 2018 (UTC)
  • No, please no. Something like Find-a-Grave or Quora is acceptable for WD, but almost never for enwiki. Creating a template that adds these automatically if they are included in Wikidata would be terrible. Fram (talk) 11:09, 13 December 2018 (UTC)
    Yeah, that does seem a bit over-broad.  — SMcCandlish ¢ 😼  13:33, 13 December 2018 (UTC)
    @Fram and SMcCandlish: Of course there would be some editorial discretion (there are hundreds of sports websites that I've never visited which have Wikidata properties, for example), but if something is the only available external link for an obscure topic then we might want to use that anyway (e.g. have a group of websites to be used on every page, and if none of those are available then use whatever other websites are in the template). Bear in mind that despite the existence of thousands of identifier properties, even important topics will only have a few dozen at most, mainly because of identifiers being specific to a given field; Douglas Adams (Q42), for example, only has 84, and we might preemptively exclude many of those for (e.g.) not being in English and/or being redundant to an entry in a better database. Jc86035 (talk) 13:42, 13 December 2018 (UTC)
  • No - A better solution is to simply have a linkbox pointing to wikidata, similar to what we have for wiktionary. Blueboar (talk) 14:16, 13 December 2018 (UTC)
  • No. More clutter for readers. A single link to Wikidata would suffice, while editors continue to add and remove external links by consensus. KokoPhantom (talk) 16:09, 13 December 2018 (UTC)
  • No I don't believe it should be necessary to make a completely separate template. Separate sections in the existing one, like ruwiki does, would be best. — AfroThundr (u · t · c) 01:21, 14 December 2018 (UTC)

Question 6 (design and function of external links template)

  • I'm not sure about these so far, but yes to (b) and (d). I'm not sure about (c) but it might make sense, for example, to manually disable social media links for those who aren't alive (although as with a lot of other facets of the template it might be more appropriate to do this automatically based on the data). Jc86035 (talk) 12:12, 12 December 2018 (UTC)
  • Premature firstly, we haven't agreed this should occur. Secondly, I think it's best that this is brainstormed a bit more on a local venue rather than a site-wide RfC. --Tom (LT) (talk) 12:54, 12 December 2018 (UTC)
  • Premature. Let's just decide if the template should exist. Bike shedding it will drag down the whole process. – Jonesey95 (talk) 14:56, 12 December 2018 (UTC)
  • Premature. Nikkimaria (talk) 01:47, 13 December 2018 (UTC)
  • Premature.  — SMcCandlish ¢ 😼  03:44, 13 December 2018 (UTC)
  • Premature, see my answer above. Fram (talk) 11:09, 13 December 2018 (UTC)
  • Premature - Per the above Blueboar (talk) 13:52, 13 December 2018 (UTC)
  • Premature Don't count your chickens... — AfroThundr (u · t · c) 01:21, 14 December 2018 (UTC)

Discussion (authority control)

A comment: I think that if we do expand the scope of the Authority control template here at en.WP, or implement a parallel "External links" template based on Wikidata, we would do well to consider dividing it into sections, similar to the ru.WP example given above. It does not make sense to me to jumble up links to Worldcat with links to Twitter, for example; links of different types should be separated into sections. – Jonesey95 (talk) 13:39, 7 December 2018 (UTC)

@Jonesey95: Yes, this would most likely happen (as I think I mentioned somewhere up there), since it wouldn't really be accurate to call the new identifiers "authority control" anyway. Jc86035 (talk) 14:08, 7 December 2018 (UTC)
I agree with above. Split into two. --Tom (LT) (talk) 01:18, 8 December 2018 (UTC)
That works for me, too.  — SMcCandlish ¢ 😼  06:07, 10 December 2018 (UTC)
The implementation of a parallel EL template isn't a question in this RfC at the moment, so I think we're getting ahead of ourselves here. Nikkimaria (talk) 03:34, 11 December 2018 (UTC)
@Jonesey95, Tom (LT), SMcCandlish, Nikkimaria, and Wugapodes: I've added questions 5 and 6 to address this. Jc86035 (talk) 12:12, 12 December 2018 (UTC)
@Jc86035: Please also ping the people who've already opined on the previous questions, to make them aware of the additions. Nikkimaria (talk) 01:47, 13 December 2018 (UTC)
@Nikkimaria: I believe I notified everyone who actually commented in the RfC before I added the questions; regardless: notifying Izno, Fram, Deryck Chan, KokoPhantom, Littleolive oil and Pigsonthewing that there are now two more questions. Jc86035 (talk) 09:43, 13 December 2018 (UTC)

Invitation to RfC

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

RfC on capitalization of the names of standardized breeds

Should the names of standardized breeds of domesticated animals be capitalized on Wikipedia, to match the published breed standards? They presently are, with near uniformity, and the practice is almost universally followed in breeds-specific writing, but notably less often in more general writing (except where a breed name is or contains a proper name like "Ennstal Mountain" or "Siamese").

I've been neutral on the question for several years (though arguing at WP:RM to follow a particular pattern in the interim, for WP:CONSISTENCY policy reasons). I have collected every single pro or con argument I've encountered on this question, at WP:BREEDCASE, immediately below which is an index of previous discussions. This may be worth a skim before you respond to this RfC. My interest in seeing the question answered by clear community consensus is to close the gaping hole in MOS:LIFE (it needs to either state that standardized breeds are an exception, or that they are not), and to complete the MOS:ORGANISMS in-depth guideline, which has been stuck in draft state for over six years due to this one question not being resolved (though it is followed aside from the breeds question).
 — SMcCandlish ¢ 😼  20:41, 9 December 2018 (UTC)


  • The MOS:LIFE guideline has us lower-case all names of generic groupings of animals and plants (including landraces, dog and horse "types", feral populations, breed groups, show/competition classes, and some other things sometimes called "breeds" in the broadest sense of that word). Standardized breeds – a very narrow sense – were left out of MOS:LIFE on purpose, as a point of contention to be settled later. Later has now arrived, overdue.
  • An RfC (WP:BIRDCON, one of Wikipedia's longest ever, and following about eight years of constant dispute) concluded in 2014 to lower-case the vernacular names of species ("Collared Dove" and "Mountain Lion" to "collared dove" and "mountain lion"). But standardized breeds are distinguishable from them on a number of bases, and need to be considered separately.
  • Cultivars, the plant equivalent of standardized breeds, are capitalized but are subject to a formal, international convention that makes them part of the scientific name, whereas zoology recognizes no infraspecific taxa below "subspecies". And not every vernacular term for a cultivar is capitalized (botanists do not write "Broccoli Rabé"), only those registered with ICNCP, plus any trademarked trade designations. So, cultivars are not some "automatic answer" either.

Potential consequences:

  • This RfC would have no effect on anything that is not a standardized breed of domesticated animal (a breed with a published breed standard from a reputable organization). In particular, it can't affect whether an alleged breed is less or more easily able to pass WP:GNG; it's about nothing but a very narrow orthographical matter in Wikipedia's own text. It would have no effect on cultivars, on landraces and other domesticated-animal groupings, historical animal populations, or non-domesticated animals (there's no such thing as a "breed" of wild animal).
  • Continuing with them capitalized would essentially change nothing, other than forestall some future arguments, and codify a particular variance from a more general style rule. There is some potential for "If this can have an exception, so can [insert my personal peccadillo here]" disputation, but MoS codifies many exceptions for many things, and it generally hasn't been much of a problem when the exceptions were not arbitrary and did serve reader-facing purposes (variances that did not have not survived).
  • De-capitalizing these names as a general class would require a non-trivial amount of research into which ones are or contain proper names or adjectives derived from them (not always obvious, especially for breeds with names from non-Western languages), a series of mass-move RMs, quite a lot of copyediting over time, and (as with the lower-casing of species common names) increased care in writing to avoid ambiguity. But we're collectively good at these things already.

 — SMcCandlish ¢ 😼  20:41, 9 December 2018 (UTC)

Retain capitalization

  • Support.Seems sensible. Martinevans123 (talk) 20:46, 9 December 2018 (UTC)
  • Support, at least for the most part: I'm basically saying that the status quo should pretty much stay as it is. Before commenting here, I read all of the background information, and I want to thank SMcCandlish for such thorough explanation. I'm finding it difficult to conceptualize a generalized rule of thumb that satisfies me. Obviously, for Genus species, we capitalize the genus and generally do not capitalize the species. For garden plants, I think it's Rosa filipes 'Kiftsgate' and Brassica oleracea 'Calabrese', with cultivar names capitalized, which I think should remain standard, but hybrid tea rose, cherry tomato, and 'Big Boy' tomato, for categories of cultivated plants. For domestic animal breeds, German Shepherd dog, without capitalizing "dog", looks right (and that may be a change), and that's consistent with 'Big Boy' tomato. For aquarium fish, pearlscale goldfish and flowerhorn cichlid 'Golden Monkey' correction: flowerhorn cichlid Golden Monkey. --Tryptofish (talk) 23:03, 9 December 2018 (UTC)
    • "German Shepherd dog" would be right, under this orthographic system, unless capitalized "Dog" is included in the breed's formal, published name in the breed standard because it's intolerably ambiguous without it. There are only a few cases of that, such as the American Quarter Horse ("American Quarter" would be mistaken for a coin), and the Norwegian Forest Cat ("Norwegian Forest" would imply not a purring critter but a Scandinavian woodland). The vast majority of breeds simply have names like Siamese, Argentine Criollo, American Buff, etc., with "cat", "horse", or "goose" only tacked on when necessary as natural disambiguation. Actual breeders do that, and WP does as well, following a years-long series of WP:RM discussions (catalogued at WP:BREEDDAB). PS: If aquarium fish breeders have picked up the 'Foo' convention from horticulture, I have to note that this hasn't spread further (no one writes "Canis lupus familiaris 'Golden Retriever'", or "dog 'Golden Retriever'").  — SMcCandlish ¢ 😼  00:14, 10 December 2018 (UTC)
      • Thanks for those clarifications, which make sense to me. (And thanks for taking a close look at Flowerhorn cichlid.) About aquarium fish, I put it that way just above because it looks right to me. (There are very few editors who work routinely on those pages.) But if I think about websites that sell or discuss aquarium fish, I can't say that I actually see the single quote marks ('Golden Monkey' as opposed to Golden Monkey), nor any really consistent pattern of usage. The one area where I'm aware of some organized and scholarly attention to nomenclature is with respect to guppies. I've never paid much attention to guppies, but I'll look into it and let editors here know what I find. --Tryptofish (talk) 22:12, 10 December 2018 (UTC)
      • I looked into that information about guppies: [13], [14]. Definitely no 'single quote' marks, about which I was incorrect. Although there is some within-source inconsistency, it ends up as Poecilia reticulata, fancy guppies, snakeskin guppies (lowercase for a group containing multiple strains), and Yellow Mosaic Snakeskin guppy (for a specific strain). --Tryptofish (talk) 01:12, 12 December 2018 (UTC)
        • That's about what I would have expected, following the same pattern as better-written material (i.e. not "capitalize all our jargon just to make to it look special and important") on livestock and mammalian pet breeds.  — SMcCandlish ¢ 😼  07:00, 12 December 2018 (UTC)
  • Support, generally. Without capitalization, "thoroughbred" is widely used as a synonym for purebred, and has a host of other connotations. Capitalized, it unambiguously refers to the breed of horses. I imagine there are many other such instances. Jlvsclrk (talk) 23:35, 9 December 2018 (UTC)
  • Comment. The section on the culivars in background above suggests a solution. It says "only those registered with ICNCP, plus any trademarked trade designations" are capitalised. A similar rationale would support capitalisation of the breeds that are registered with the bodies that standardise the breeds.   Jts1882 | talk  11:35, 10 December 2018 (UTC)
    @Jts1882: the problem here is that the ICNCP says that for every kind of cultivated plant there will be one registrar, who then determines the definitive list of cultivars of that kind of plant. But there's no one organization that says who is the registrar for, say, dogs. So there are different national bodies that have, at least historically, failed to agree. So if we agree to the proposal, we will need to make clear exactly how to determine what counts as a "standardized breed". Peter coxhead (talk) 16:32, 12 December 2018 (UTC)
  • Support It makes sense (that is how breed standards, breed encyclopedias, magazine articles do it). Also, "abyssinian cat" looks ridiculous.--SilverTiger12 (talk) 13:04, 10 December 2018 (UTC)
    (1) That's an example of SMcCandlish's "specialist style fallacy". (2) No-one would suggest "abyssinian cat"; it would be "Abyssinian cat" if we did de-capitalize. Peter coxhead (talk) 22:20, 11 December 2018 (UTC)
    Yeah, "abyssinian" would be out of the question, and the RfC is already clear on that: "except where a breed name is or contains a proper name". The WP:SSF stuff I addressed below in more detail. Capitalizing breeds veers towards one, but seems to stop just short, because a) plenty of non-specialist sources do it, and b) it is consequently common enough that it is not "weird" to the reader. If you see WP:BREEDCAPS and look below the for/against arguments and the list of previous discussions, there's some sourcing (N-grams, etc.). The capitalization tendency varies widely (even wildly) by various factors, though the one consistent thing was that no major dictionaries do it (except where a proper name occurs). News sources were all over the place, though they lean a bit lower case.  — SMcCandlish ¢ 😼  01:21, 12 December 2018 (UTC)

Sorry, the Abyssinian cat is just one of the first breed-names that came to mind for me. Yeah, breed-names that are derived from proper nouns would still be capitalized. However, there are also made-up breed names (Ocicat, Cheetoh, Toyger, etc.) that are rather ambiguous on that point; and I still think those would look ridiculous in lower-case: I went to a cat show and saw an ocicat win first prize, and a toyger and cheetoh tied for second place. Also, what about the Savannah breed? In lower-case, it appears to refer to an African grassland: I went to a cat show and the savannah was gorgeous.
Point two, books about cat breeds tend to capitalize; and people coming to Wikipedia to read about a cat breed is likely to be at least somewhat interested in cat breeds. Personally, if I saw one of the two sample sentences I just wrote, I'd have a wtf? reaction.--SilverTiger12 (talk) 15:25, 12 December 2018 (UTC)
@SilverTiger12: re your point two, this is precisely the argument that has repeatedly been rejected in previous discussions. Almost all the books on my shelves about plants capitalize their English names, and I originally came to Wikipedia to read about plants. Although I'm more used to de-capitalization now, it can still look wrong to me. But the community's reaction to this has been "so what?" Peter coxhead (talk) 16:19, 12 December 2018 (UTC)
  • Support in general – this the invariable practice in reliable sources, and there's no reason to even consider trying to establish something different here. Reservations: (1) this applies to all domestic breeds, not just those that are "standardised", and also to lines and strains – ISA Brown is capitalised though it is neither standardised nor a breed, but a commercial hybrid. (2) (a question): does the same apply uniformly to plant cultivars? Justlettersandnumbers (talk) 22:10, 11 December 2018 (UTC)
    • It's clearly not the "invariable" practice in reliable sources; the National Geographic, to give just one example, does not capitalize breeds – see, e.g., [15].
    • Plant cultivars are a quite different matter. The International Code of Nomenclature for Cultivated Plants defines how their names should be written. There's no such equivalent for domesticated animals. Peter coxhead (talk) 22:20, 11 December 2018 (UTC)
    • And there's already the hard-won MOS:LIFE consensus - reaffirmed by the BIRDCON RfC – to not capitalize groups of animals at all. We're contemplating here one single, possibly palatable, very narrow exception for standardized breeds, primarily because they are published standards. They're as close as zoology is willing to get to the cultivar concept; all they lack is a slot in the scientific name. This "standardization of definitions and naming" rationale does not apply to vague overuse of the word breed to mean "named group of dogs/pigs/whatever mentioned in medieval sources", or "landrace", or "feral population", or "backyard-breeders' experiments in cross-breeding and making up names like 'pitsky'", or "naturally occurring wild–domestic hybrids" or "distinct populations of wild animals", or "coat variant I prefer and really like to capitalize because it looks more impressive that way", or "something I think is a breed but which every organization in the field refuses to recognize as one", or anything else. All those are already covered by MOS:LIFE as lower-cased, without.  — SMcCandlish ¢ 😼  01:21, 12 December 2018 (UTC)

      • I understand this point, but the problem then is defining what is meant by "standardized breeds" and "published standards". "Standardized" by whom? "Published" where and by whom? In the article at Irish Setter, I see that "Red Setter" is or is not the same breed as "Irish Setter" depending on whose definition you accept. So should it be capitalized or not?
        The one really powerful argument in favour of lower-casing in Wikipedia is that it's a simple rule, easy to follow. Once you start capitalizing some breed names, but not others, as you propose, it gets very complex and open to endless arguments. It also doesn't solve the "wtf" reaction if you do end up with sentences like "There are different opinions as to whether the Irish Setter and the red setter are the same breed".
        The Irish Setter article also raises some other issues that need to be clarified. Should "Working Red Setter" be capitalized, as it is in the article? My answer is "no", as it isn't a standardized breed, so I assume it should be "working Red Setter". The article (like others on breeds) uses the second part of the name alone sometimes, as a way of referring to all breeds of setter (?Setter), and then generally capitalizes it. However, this seems like starting with "Sutton Park" and then using "the Park", which I do in my own writing, but which we don't do here. Peter coxhead (talk) 16:19, 12 December 2018 (UTC)
        Addressed most of this below. In the setters example, if we were going with capitalized breeds, then Red Setter would be capitalized since at least one breed registry has it defined as a breed. But "setter" isn't a breed; it's a general class of breeds (like poodle, scenthound, etc.) And, no "working Red Setter" wouldn't have a capital W, any more than we'd write "Jones is Employed at the post office". A short form might be capitalized if exclusive, but "setter" isn't exclusive (i.e., it's the same case as "I like Sutton Park and Peasholm Park, but I'm not really sure which of the Parks is more relaxing, and the Park I spend the most time at is Sutton". Not many people write like that any more, and WP doesn't. We do have a tremendous amount of over-capitalization in breed articles, because most of them were written by breed fans in WP's early days before we even had much in the way of an MoS, and they were created in the same style as breeder magazines and newsletters (capitalize everything related to breeds and breeding, for signification emphasis). Cleaning them up is a slow process, with not many editors involved in it, so many of them still read like that.  — SMcCandlish ¢ 😼  13:44, 13 December 2018 (UTC)
  • Support per Martinevans123. Ealdgyth - Talk 15:19, 13 December 2018 (UTC)
  • Support - For me, this ultimately comes down to “what will cause the least amount of disruption and avoidable drama”. Lowercasing may well be the “correct” action in terms of grammar and style, but doing so will upset far more of our editors than retaining the capitalization will. Trying to “correct” the capitalization will simply result MORE disruption, and MORE endless arguments. Blueboar (talk) 16:11, 13 December 2018 (UTC)

Change to lower-case

  • Support All I can see from the sources cited so far is that 1) sources differ from each other and 2) sources are internally consistent. Point 1 means that we can cherry pick whatever sources we want to defended whatever position we want, which means it isn't very useful, and we should therefor default to our own style guide. There MOS, as noted, is generally conservative on capitalization, and I see no reason why this is any different. Readers are unlikely to be confused by such a difference in style, so I lean towards treating these as any other common nouns.--Jayron32 00:17, 13 December 2018 (UTC)
  • Support lowercase per Jayron. There's too much uncertainty in deciding which breeds to cap, which organizations to take guidance from, etc., otherwise. Dicklyon (talk) 05:05, 13 December 2018 (UTC)

Neutral / other

  • Neutral: I'm going remain on the fence about this, barring some amazing argument I've not see before.  — SMcCandlish ¢ 😼  20:41, 9 December 2018 (UTC)
  • Better arguments needed I'm generally neutral on this matter (I'd like to see more capitalization in the English Wikipedia, but consistently so); however, there are some weak arguments being put forward.
    • There is no grammatical difference between the scientific names of breeds and the scientific names of species. All the arguments at User:Peter coxhead/English species names as proper names apply equally if a breed name is substituted for an English species name. In particular, a determiner is required with the singular (I saw German Shepherd is wrong) and plurals are fine (I have three German Shepherds), so that a breed name is not a proper noun phrase and hence is not capitalized for that reason.
    • The MoS is generally against capitalization; there should be strong arguments as to why this is an exception. Merely trotting out arguments that equally apply but failed to support the capitalization of the English names of species, such as "it's ambiguous without the capitals", is not enough.
    • If the capitalization of breed names is accepted, then the MoS will be recommending sentences like "A bald eagle has been recorded as having killed a Rough Collie" or "The zoo has specimens of red cardinals and Red Setters". I have to say that these produce a "wtf" reaction in this reader – I can't claim to know what the typical reader would think.
    • The argument from prevalence in sources is more nuanced than sometimes claimed, especially if you discount specialist sources. There's a strong tendency to continue capitalization, so that breed names are more likely to be fully capitalized if the first word is (derived from) a capitalized name or location. Thus Google Ngrams clearly favour "German Shepherd" over "german shepherd" but they also favour "border collie" over "Border Collie", albeit less so. (The same effect is found for species names if you check the Ngrams for "bald eagle"/"Bald Eagle" and "American robin"/"American Robin".) My tests suggest that if the first word isn't capitalized, Ngrams generally favour lower case throughout. I'm also influenced by magazines like National Geographic which regularly discuss both wild and domesticated animals and use lower case for the English names of both (see e.g. [16] for dog breed names).
Peter coxhead (talk) 14:27, 10 December 2018 (UTC)
Syntax is the main but not only reason to capitalize in English; simple convention is often enough if not confined to specialist writing (what MoS advises isn't universally followed in RS or we wouldn't actually need a style guide; e.g. "Aids" and "Nato" are common in the British press, journalists often write things like "Homo Sapiens" instead of of "Homo sapiens", units are very often given with wrong capping, like "DB" for "dB"). The question raised by this RfC boils down to whether there's enough of a convention with regard to standardized breeds, across multiple sorts of writing, and by way of analogy to other standards, to support it on WP. So your second point is very pertinent. After gathering and balancing the arguments at WP:BREEDCAPS, it seems to me a very open question (and, yes, many of the arguments are weak, but that applies to both sides). I addressed the "conflicting consistencies" problem in more detail below. We actually do have a pretty clear idea of reader reaction, because capitalizing species caused a constant stream of complaint, but capitalizing breeds does not (though that is hardly an actual reason to do it). And the fourth point is certainly true; over here I put together over 60 evidentiary links (including some new ones at the bottom showing that the "keep capitalizing if we started capital" effect only applies to breeds). They mostly support lower-casing but indicate a tendency to capitalize when uncertain, and show confusion even among alleged language authorities like The Chicago Manual of Style and a popular English-usage website.  — SMcCandlish ¢ 😼  08:51, 12 December 2018 (UTC)

Extended commentary

  • A case can be made that capitalizing breeds is a specialized-style fallacy, but as the primary author of that essay, I would disagree, because it's not sharply at odds with general English-language practice (writing "Gloucestershire Old Spot pigs" or "Doberman Pinscher" does not produce a "WTF?" reaction in the typical reader, while writing "Wild Boar" or "African Elephant" would – readers are already aware that usage is mixed, in everyday sources, with regard to breeds). While we default to lower-case when usage in RS is mixed, we make many exceptions to this (especially at MOS:NUM on units of measure), for cases where a particular upper-case usage is subject to published standards. But an exception being permissible doesn't make it mandatory. This comes down to a community cost-benefit analysis, which is why I've opened this RfC.  — SMcCandlish ¢ 😼  20:41, 9 December 2018 (UTC)
    "run you mother run". Martinevans123 (talk) 20:47, 9 December 2018 (UTC)
    [FBDB] That was a joking reference to this thread.  — SMcCandlish ¢ 😼  00:02, 10 December 2018 (UTC)
    But "my Red Setter chased a red cardinal" does produce a "wtf" reaction in me. You need to show that non-specialist sources that regularly discuss both wild and domesticated animals have a different capitalization style for breed names and the English names of species (and also for standardized and non-standardized breeds). Peter coxhead (talk) 14:32, 10 December 2018 (UTC)
    That sort of thing is always going to happen in English (versus in German, which capitalizes all nouns and noun phrases simply because they're "nouny"). Being neutral on this, I don't have to show anything; but supporters of the caps should do so. There's already a repeatedly, deeply tested consensus at MOS:LIFE against capitalizing groups of animals, but a quiet "we're not sure about this one category" hole was left open primarily to not dive immediately into an ugly fight right after BIRDCON when emotions were still running high. Four years is long enough to cool. Personally, I'll be perfectly happy with lower-case if things swing that way. It would be easier in some senses and harder in others. But anyway, in style matters there are always conflicting rationales, conflicting uses from different excessively topical writing, and even conflicting consistencies that are orthogonal to each other (e.g. capitalize cultivars to be consistent with genus and grex, at the cost of consistency with more familiar names like "broccoli" and "Brussels sprouts"). "Can't please everyone, especially in English" should be a real saying. :-)  — SMcCandlish ¢ 😼 , 01:42, 12 December 2018 (UTC)
    Well, on your last point we can certainly agree! Peter coxhead (talk) 16:27, 12 December 2018 (UTC)
  • Please try to stay on-topic when commenting here. No one ever suggested anything like lower-casing "german". And trying to leverage or misread the very circumscribed RfC question into a case for over-capitalizing everything anyone ever uses the word "breed" about, is never going to fly. The fact that horse, cat, etc., fanciers and breeders like to capitalize all those not-really-breeds clusters of animals (ferals, landraces, cross-breeds with no recognition as new breeds in their own right, etc) is immaterial. Other sources generally do not, while their treatment of standardized breeds is much more mixed. The same fanciers and breeders also like to capitalize coat colors, eye colors, head shapes, breed clusters, training regimens, breed-development intents ("Beef Cattle", "Herding and Livestock-Guardian Dogs", "Ships' Cats"), and everything else to do with their hobby or livelihood. This is the very essence of the specialized-style fallacy, and is covered, guideline-wise, in the first rule of MOS:CAPS: do not misuse capital letters to emphasize, signify, or highlight in "grocers' capitalization" style. All of those not-really-breeds are already covered by MOS:LIFE, on purpose (and unmistakably, by the selection of terms and breadth of examples given). The only thing it leaves out, pending a discussion like this, is standardized breeds.
     — SMcCandlish ¢ 😼  01:42, 12 December 2018 (UTC)

    • What I just don't see is a clear definition of "standardized breeds" that can be used by editors with a wide range of experience and that will not cause nit-picking arguments about what bodies count as being able to standardize. Peter coxhead (talk) 16:25, 12 December 2018 (UTC)
      Would depend on what the claims are, and what the sourcing for them amounts to.
      • For a breed being developed from a semi-consistent, and somewhat or entirely free-breeding population, like a landrace or a feral group, publication of any breed standard (or studbook, see below) under a unique name should actually be sufficient to capitalize that name.
        • Without evidence of such establishment, the claim that it's a beed is WP:OR. The recent WP:Articles for deletion/Double-nosed Andean tiger hound (which was created at a more capitalized title), concluded that this is basically a cryptid, there's no credible evidence of breed establishment, and that the article should be trimmed and merged into something on bifid noses in dogs (merge hasn't happened yet, though is under discussion at WT:DOGS).
      • Same goes for attempts to establish breeds from new mutations (e.g. a short-legged cattle variety or whatever, though this sort of breeding is more common in pets). As this is just a capitalization question, the notability/reputability of the breeders isn't really an issue. E.g. everything at List of experimental cat breeds is capitalized, though the entire page may not really be encyclopedic (we don't have a corresponding list for horses, geese, rabbits, goats, or anything else, and we probably would not have "List of garage bands in Singapore" to retain non-notable entries, either).
        • If it's just four guys with 15 pigs, the alleged breed would fail WP:Notability and WP:NOT#INDISCRIMINATE and WP:UNDUE, so WP wouldn't cover it anyway (WP:NFT summarizes this).
        • Given a notable feral/landrace population, and a handful of breeders who didn't even bother to change the name when they attempted to purebreed a standardized breed out of them for fixed characteristics, our article would still be about the notable feral population. We might write "Southwestern desert pigs are a population of feral pigs in [Where ever] ...", retaining that style throughout, except somewhere in a section below (or maybe even in the lead), include something like "A small group of breeders in [Where ever] and [Where ever else] are, since 2008, attempting to establish a standardized breed, named Southwestern Desert Pig, from the feral population." – if we thought it necessary to mention the standardization effort in the first place (how much weight does it have in the RS?), and mention what its name is.
        • This is the approach already taken at our articles in such cases. Four examples I can think of off the top of my head: Kiger mustang (with two competing breed-establishment efforts under different names); Cyprus cat; Aegean cat (doesn't mention any breed name – we don't seem to have any RS on what name the breeders are using for it anyway, which would probably be in Greek and need to be translated); and Van cat, just going by recent memory. A fifth is Iron Age pig, being RMed to boar–pig hybrid, because the alleged breed being developed from them under the "Iron Age pig" name is not the main subject of the article but UNDUE promotion by one cluster of intentional breeders in the lead section (such pigs as ferals are a major agricultural and environmental problem in North America and Australia, and that's the encyclopedic topic).
      • Crossbreeds should remain lower-case unless a notable breed registry accepts them as the establishment of a new breed. That's a WP:NOR, WP:V, WP:UNDUE, and WP:NOT#PROMO matter; any time a breeder produces an interesting-looking mongrel they have an incentive to slap a cute name on it for marking purposes, but RS still tell us these are crossbreeds not breeds. Most new breeds that major organizations accept, with sufficient proof of long-term true-breeding of characteristics and a lack of recent outcrossing, originated as crossbreeds of course, but it's a lengthy process (often decades). RS tell us when that process has been completed. For crossbreeds it is more than a typographic matter.
        • We also have a tertiary sourcing problem, where various breed encyclopedias are indiscriminately over-inclusive and try to include every single group of animals they can find a name for as a "breed" without any distinction (the larger the work is, the more comprehensive it looks to buyers). Similarly, the DAD-IS database accepts and uncritically republishes every "breed"-related claim submitted to it by any government or national organization, and thus includes erroneous data. E.g., if there's a common landrace of cattle in Elbonia, the Elbonian agriculture ministry may put the name "Great Elbonian cattle" on it (whether people there and any independent sources have ever used such a name) and claim it's a breed (and may be seeking protected designation of origin status for products made from it, etc. – this stuff may be a mixture of economic concerns, national pride, etc.). The exact same animals across the border in Kerblachistan may get reported to DAD-IS as "Kerblachian Blacheaded cattle" and also be claimed to be a breed, and DAD-IS will report them as separate breeds, without any indication that they're the same animals and are just free-breeding landrace livestock in herds no one is performing much selective breeding on, but simply trying to have enough cows to survive. Tertiary sourcing isn't sufficient to establish analytic, evaluative, or interpretative claims, nor to establish notability, yet we have numerous articles, including content forks for different names for the same animals, which were written in a wave in the 2000s, apparently in an attempt to replicate DAD-IS in Wikipedia, with no sourcing other than DAD-IS, primary (marketing) sources, and iffy breed encyclopedias (at least one of which is known to take paid entries, i.e. advertising).
      Some attempts to address issues like this were drafted at WP:Notability (breeds); while it stalled a while back and hasn't gone through a WP:PROPOSAL process, it was put together by regulars in the topic area, and seems to accurately reflect WP best practices on the topic. I've also summarized, mostly for new editors, how our WP:P&G apply to this topic, at WP:Writing about breeds. (It presumes standardized breeds should be capitalized, since that's the current majority practice here, though of course would have its wording changed if this RfC went the other direction.)
       — SMcCandlish ¢ 😼  03:41, 13 December 2018 (UTC)

On standardized breeds. I have some experience with cattle, horses, dogs and cats in respect to the subject. I have followed the links associated with this and find them to be unhelpful in resolving the question of what a standardised breed is. "Breed standards" are used in the context of showing dogs and cats, where show placings are determined by point scoring against a breed standard or "ideal". There are various national showing associations (ie by country) but in some cases, there may be more than one national association for a species. There are then, individual breed associations. For dogs, there are also working dog associations which do not use breed standards but rely on performance. The H|huntaway is an example of a registered breed for which there is not a breed standard. Cattle and horses do not (in my experience) use breed standards - or certainly not in the same way as dogs and cats. Cattle are judged pragmatically - and without reference to individual breed standards, though they may be judged against others of the same breed. They are judged on the basis of purpose. Led horses are judged on fitness for a particular task, which is a matter of conformation. These are not, in my observation, the same as breed standards for dogs and cats, which are about "form" and have essentially nothing to do with "function". My experience is that the distinguishing feature of a breed is the maintenance of a stud registry. I am not certain how this might apply to other "breeds" of other species (specifically birds) which are outside my experience. I suggest this issue might need to be addressed/clarified for this to be a workable proposal. Regards, Cinderella157 (talk) 01:29, 13 December 2018 (UTC)

A stud registry for these purposes would count as a breed standard. Selection for meatiness, ability to do work, wool production, etc., is still regularized artificial selection for true-breeding characteristics, just different ones than the kind pet breeders care about. Kind of self-enforcing; farmers don't want crappy, low-value livestock no one wants to buy or use as breeding stock, and which produce insufficient or inferior product. Something selected, without regard to ancestry, based on performance under training or the intent to which the animal would be put to use isn't a breed of any kind, but a type, e.g. sled dog, draught horse. Anyway, lots of livestock breeds do in fact have breed standards in the more usual sense (standards of points, conformation standards). Here's one for the American Quarter Horse [17]. Because vastly more money is involved, and commercial predictability and homogeneity of livestock traits is important, breeders are also taking a cue from the development of laboratory strains, and have started issuing genetic standards, which would also qualify as breed standards (the most stringent kind); here's one for Holstein cattle [18].  — SMcCandlish ¢ 😼  03:41, 13 December 2018 (UTC)
If a breed standard is the criterion, we would have "huntaway" but by the national stud registary we would have "Huntaway". Note, (if I have this right) unregistered champion dogs can be added to the registry? IMO, providing clear and unambiguous guidance on the criterion|a to establish the basis for capitalisation (and exception to the general guidance of MOS:CAPS) is pretty important. I think it would be appropriate to amend to both criteria or to foreshadow it. It is also probably appropriate to make the amended guideline explicit wrt capitalising the species (eg pig) or type (eg terrier) unless these are specifically part of the breed name as documented. This is touched upon in the opening discussion. Regards, Cinderella157 (talk) 06:23, 13 December 2018 (UTC)
Huntaway cites a breed standard. But I get your point; there will be livestock breeds for which there's a studbook registry organization, but no conformation standard; we should treat them as equivalent for this question. Really, the whole point is if there's reasonable evidence it's an actual breed, in an encyclopedically meaningful sense and within reader expectations of what that word means, then capitalize it (if we continue with the caps at all), but otherwise use lower case per MOS:LIFE and MOS:CAPS more generally. If it's just some local landrace, or dogs mentioned in 1329, or some random yahoo's crossbreed of a German Shepherd and a Great Dane [the awkwardness of "great Dane" indicates one of the reasons some people lean toward caps on this], then it's not a breed, and nothing like a proper name in any sense that WP should care about. It's not a matter of "capitalize breeds, and define that loosely", but of "do not capitalize groups of animals, our long-extant rule, but perhaps make a very narrow exception for standardized breeds, because we're already doing it." I don't mean even that various articles not substantively edited for years and full of over-capitalization of all sorts of things are doing it; I mean that 4+ years of RM decisions have consistently done it (and not done it for things that are not such breeds, but are feral populations, crossbreeds, etc.). Whether to capitalize the species at the end is already de facto settled, exactly as you describe, so if MOS:LIFE had a breeds exception that would be included. PS: The people (two editors that I know of) who want to capitalize everything anyone ever calls a breed are weirdly also very insistent on whether or not to capitalize something like "dog" or "horse" at the end. They're all about very strictly following the exact wording of the breed standards when it suits their preferences, then flipping around and denying that breed standards matter at all to the capitalization question when they want to over-capitalize something like mustang or Van cat (named after Lake Van, not vans in the driving around sense).  — SMcCandlish ¢ 😼  13:59, 13 December 2018 (UTC)

When you know something, but no sources say it

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