Wikipedia:Village pump (policy)

"WP:VPP" redirects here. For proposals, see Wikipedia:Village pump (proposals).

 Policy Technical Proposals Idea lab WMF Miscellaneous 

• Table of contents
• First discussion
• End of page
• New post

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.

« Archives, 177, 178, 179, 180, 181, 182, 183, 184, 185, 186, 187, 188, 189, 190, 191, 192, 193, 194, 195, 196, 197

Proposal to tighten administrator inactivity procedure

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.

---

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

References

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)

Survey/discussion

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

As much as I think 2FA is a good idea, the fact is that requiring it would violate WP:5P3 (Wikipedia is free content that anyone can use, edit, and distribute). Administration is an essential part of running the project, and thus the ability to participate in administration needs to be available to anyone. Some people cannot afford to purchase the hardware required for 2FA. Some people are physically incapable of operating such hardware. Some people are not technically savvy enough to master its use. I would not be surprised if there were places in the world where possession of such hardware would be a crime, or at least expose you to unwanted government scrutiny. -- RoySmith (talk) 00:38, 19 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? –xeno^talk 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 (talk • contribs) 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. –Davey2010^Talk 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. –Davey2010^Talk 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)
    • @Thryduulf and Iridescent: Ah. Thanks for clarifying. I've done some striking at the start. Yngvadottir (talk) 23:32, 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 Ponyo^{bons 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. SQL^{Query 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. Iffy★Chat -- 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. Worm^TT(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 (u • t • c) 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. GAB^gab 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 ^(TALK_CONT) 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 (talk • contribs • logs) 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 https://www.ftc.gov/news-events/blogs/techftc/2016/03/time-rethink-mandatory-password-changes 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. Nathan2055^{talk - 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 http://rumkin.com/tools/password/passchk.php 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. ^Semi_Hypercube ✎ 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 • talk • contribs 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. CThomas³ (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 https://phabricator.wikimedia.org/T150826, 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)
• Oppose as written. I am not against this in principle, but the proposal is problematic in a number of ways. Not notifying is unforgivable. If a notification prompts a user to come back and do some admin work, that is a good thing, not a problem. Also, as others have pointed out, there are a number of tasks that require admin rights but do not get logged. DYK has already been mentioned, OTRS volunteers are another example. They need to read deleted pages. SpinningSpark 09:56, 15 December 2018 (UTC)

• Oppose- for this to be a good idea, the accounts of admins who edit but no longer use their tools would need to be easier to compromise than completely inactive admins and admins who do use their tools. So far, there has been no evidence presented that this is the case. Reyk _YO! 10:07, 15 December 2018 (UTC)
• Support - seems reasonable.--Staberinde (talk) 11:30, 15 December 2018 (UTC)
• Support - Cleanly reduces the security risk in admin accounts, while retaining anyone who is adminning. Tazerdadog (talk) 19:38, 17 December 2018 (UTC)
• Strong Oppose - I strongly oppose both the changes to the Administrator inactivty requirements and the forced 2FA authentication. There are many admins and editors who do not edit Wikipedia regularly, but that doesn't mean that they are less valuable than those who edit here regularly. Any action and decision that concerns any editor or administrator should always be informed to the concerned person on their talk page. Removing the administrator rights or any other userrights of an established editor without any valid reason and information is completely unacceptable. TheGeneralUser (talk) 23:36, 18 December 2018 (UTC)
• Support - Inactive admins, and indeed editors in general who are inactive in the article space, are a problem. If you're going to go through RFA then you've got to commit to working on this project. My only proviso is that there should be an easy mechanism for re-instatement, and that people absent for parental leave/illness should be taken into consideration. FOARP (talk) 07:59, 22 December 2018 (UTC)
• Oppose The current proposal failed to consider unlogged admin actions. Viewing deleted pages is certainly one that falls within the scope of unlogged action. Correcting Main Page errors is another (yes, you can check edits under WP namespace which is considered "logged", but this isn't the first place people go check your log activity and if you make plenty of WP namespace edits, it's almost impossible to notice it). OhanaUnited^{Talk page} 01:16, 24 December 2018 (UTC)
• Strong Oppose Wrong problem. The problem is trying to retain the admins we're losing, not make us lose more admins. --Dweller (talk) Become old fashioned! 19:26, 27 December 2018 (UTC)
• Oppose mainly per Dweller - this is not helping security and has the potential to lose wikipedia more editors. Cas Liber (talk · contribs) 19:57, 27 December 2018 (UTC)
• Support: inactive admins are not admins, per se. It's not that hard to perform one logged admin action per year. --K.e.coffman (talk) 20:05, 30 December 2018 (UTC)
• Support per User:Johnuniq Smallbones_(smalltalk) 23:53, 30 December 2018 (UTC)
• Support Wiki is always changing. Inactive admins will not be up to date. Ronhjones  ^(Talk) 23:48, 1 January 2019 (UTC)
• Support per User:Johnuniq.Pharaoh of the Wizards (talk) 12:39, 4 January 2019 (UTC)
• Support. I've always thought telling them beforehand that the bit is about to be removed seemed unproductive and defeating the purpose. This proposal makes sense to me. But I do think that User:Hut 8.5's comments need to be taken into consideration. -- œ^™ 06:41, 6 January 2019 (UTC)
• Support per User:Johnuniq. --B dash (talk) 10:30, 10 January 2019 (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 [t^hɑ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)

• I don't think this is just DYK. Another group that has come up in previous proposals of this sort is the OTRS volunteers. A necessary part of their work is to read deleted articles when they are queried. Reading a page, even a deleted page, is not logged anywhere, so I don't see how a bot could make an exception here, unless it automatically excepted all OTRS volunteers. There are bound to be other edge cases that haven't come to light, which is why I think silently desysopping without notification is not acceptable. Not only must there be notification, but there needs to be a formal channel to appeal so the desysop can be cancelled before it takes effect. SpinningSpark 10:09, 15 December 2018 (UTC)
• There's a few more examples of "somewhat logged" but not in the exact way. Correcting Main Page errors is "logged" but in the forms of edits and if you edit a lot of WP namespace, it can easily escape detecting the logged action. Same for requiring an admin to close a deletion discussion. OhanaUnited^{Talk page} 01:10, 25 December 2018 (UTC)
• The issues which I can come up with of using one's admin bit without an obvious way of finding it:
  1. Unblock review - while some of these require either an unblock action or a block change to disable talk page access, most don't; any which don't have no obvious log to find.
  2. Viewing deleted edits, apparently an issue for OTRS users.
  3. Editing protected pages. While the edit is clearly logged in the page history, seeing several days, weeks or months later that the page was protected at the time isn't self-evident.
  4. Moving a page to an existing title other than reversing a redirect with no history - while the deletion itself is logged, so is a redirect-reversal move done by a non-admin.

עוד מישהו Od Mishehu 13:32, 9 January 2019 (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 haveibeenpwned.com 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 en.wiki 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)

• @Ivanvector: Way back in Feb '17, "203 out of the 1274 admins on English Wikipedia [had] enabled two-factor auth". Other tasks exist asking for a similar thing - TNT ^💖 19:37, 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
PAGE) 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
PAGE) 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 [ https://pages.nist.gov/800-63-3/sp800-63b.html#sec5 ]. 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.

https://www.makeuseof.com/tag/two-factor-authentication-sms-apps/

https://www.wired.com/story/two-factor-authentication-apps-authy-google-authenticator/

https://thestack.com/security/2016/04/08/anywhere-computing-makes-2fa-insecure-on-ios-and-android/

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

• What Is Two-Factor Authentication, And Why You Should Use It - MakeUseOf
• What Is Two-Factor Authentication and Why You Should Use It - Motherboard
• Two-factor authentication: How and why to use it - CNet

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 en.wiki 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 https://www.grc.com/haystack.htm 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 https://xkcd.com/936/ and https://xkcd.com/538/ ) 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 [ https://www.grc.com/haystack.htm ]. 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 `~!@#$%^&*()-_=+[{]}\|;:'",<.>/?) - 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 [ https://www.grc.com/haystack.htm ] 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/I@alk#<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:

http://security.stackexchange.com/a/6096/33

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 https://www.mediawiki.org/wiki/Manual:User_table 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)

The problem with a passphrase is that the risk of a typo is too high; and since I can't see the text I'm typing in, I can't even confirm that I typed it in correctly before clicking on the login button. In a passphrase of 40 characters, my chances of a typo are close to 100%; and in a password field, I can't even see it. עוד מישהו Od Mishehu 13:39, 9 January 2019 (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)

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.

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.

Support

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). CThomas³ (talk) 07:25, 8 December 2018 (UTC)
10. Support not listing non-notable victims, who should appear only contextually where their inclusion is specifically necessary to understand the event and its aftermath, per previous discussion here and elsewhere and elsewhere and elsewhere. The principle isn't even really specific to victims -- the same should apply for participants in any notable event (eg Trinity (nuclear test)). ^~Hydronium^~Hydroxide^~(Talk)~ 00:25, 15 December 2018 (UTC)
11. Support – Wikipedia is not a memorial. There are certainly personal motivations both for and against listing victims, but if we remove those emotional elements, our encyclopedia should focus on its core values, such as WP:Notability and WP:Neutral point of view. Full lists of individual victims who do not stand out for anything else do not qualify for inclusion. Of course discussion on talk pages should be encouraged and honored, but an enormous amount of time will be saved if the general guideline gives a clear indication of the criteria under which people should be listed. — JFG ^talk 04:48, 15 December 2018 (UTC)
12. Support we should only list or mention people who are noteworthy, that have a wikipedia article or are notable enough that a stand-alone article could be created. MilborneOne (talk) 19:44, 17 December 2018 (UTC)
13. Support - definitely an improvement Llammakey (talk) 13:31, 18 December 2018 (UTC)

    Llammakey—I see you work on articles such as Passengers of the ships Anne and Little James 1623. Just out of curiosity, do you distinguish between the passengers on those ships and the individuals under consideration in this discussion and if so in what way? Thank you. Bus stop (talk) 15:52, 18 December 2018 (UTC)

14. Support this wording. I think that all objections fail to take into account the part saying "without context". If there is any context to be had, even if tiny, this would not apply. wumbolo ^^^ 08:45, 20 December 2018 (UTC)
15. Support: Listing not-otherwise-noteworthy people just because they were unlucky enough to be at the wrong place at the wrong time is unencyclopaedic, and frankly, boring to the general reader. An encyclopaedia should give me information I might want to know. I cannot imagine a circumstance where I would want to know the names of everyone who just happened to luck out on the day. If this were to occur, the information could be quite adequately provided by way of a reference or even an external link to a full listing somewhere else. The arguments in opposition below mostly reinforce my conviction that this should be specifically stated in guidance or policy. Special cases can be proposed, and where there is clear local consensus based on the exceptional merits of the case, decided on article talk pages before including in the article. · · · Peter (Southwood) ^(talk): 09:56, 20 December 2018 (UTC)

    You are assuming that what you want to know is what everybody wants to know. Consider someone researching family history or doing sociological research into workers in a particular activity; they might find a list of names, addresses and families something that they "might want to know". Information such as this may be verifiable, but if the source is off line in the bowels of a university library it is not available to any readers "general" or not. To take a specific example: I have recently been working on the Clifton Hall Colliery disaster of 1885 where 178 were killed. A list in the text would be entirely inappropriate, but a separate article listing the name, age, address, occupation, by whom identified and marital/family status might be of use. Martin of Sheffield (talk) 14:35, 20 December 2018 (UTC)

    WP:INDISCRIMINATE provides for the existence of information that is true, verifiable, and potentially useful to someone, but whose potential audience is too narrow for it to be considered encyclopedic. That last point is the one you'd need to refute for these lists. —swpb^{T go beyond} 16:45, 20 December 2018 (UTC)

    Abolish WP:INDISCRIMINATE. Well, maybe not abolish, but reduce. Wikipedia is written for the benefit of its readers, and is not paper. All reasonably potentially useful information should be included. Benjamin (talk) 18:42, 4 January 2019 (UTC)

16. Support. Thanks to Cunard for pinging in people (like me) who've been in previous discussions on this matter. I agree with the proposal, in general we should not be including such lists, they add no value to the encyclopedic understanding of the topic. There may be relevant exceptions, but things like Schoharie limousine crash and Sandy Hook Elementary School shooting look like examples where there is no good reason to include a list, and hopefully this clarification of the policy will lead to them being removed in those cases.  — Amakuru (talk) 11:14, 20 December 2018 (UTC)
17. Weak support I agree wit those who say that including notable (I.E. notable in their own right) is acceptable, but also fail to see why it would be a list rather then prose. But articles should not become memorials to victims. So I am bit on the fence on this, I could just as easily vote weak Oppose for the same reason.Slatersteven (talk) 11:16, 20 December 2018 (UTC)
18. Support - Alsee has articulated the reasoning quite well. --Khajidha (talk) 11:35, 20 December 2018 (UTC)
19. For non-notable people, per WP:NOTMEMORIAL, and also because these were normally non-public figures who merit privacy even shortly after their death. There is little bona fide educational interest in reproducing lists of names. The wording needs editing for conciseness. Sandstein 12:05, 20 December 2018 (UTC)
20. Support I've taken part in a number of related discussions and have consistently opposed inclusion of victim lists. It may sound heartless, but I see no useful purpose to naming victims unless adding their name significantly adds to understanding the event. Such discussions typically take place in the immediate aftermath of some gut-wrenchingly awful event, often involve new editors, and unfortunately often involve accusations of bad-faith against those of us who wish to exclude ( insert name of other tragic event has a list so why not this event? You wouldn't be arguing that way if the victims were/weren't white/black/hispanic heterosexual/gay adults/children). A clear default position would be helpful and that shold be exclude IMO - whilst I perfectly understand the desire to 'honour' the dead by recording their names, no useful encyc purpose is achieved by doing so IMO - it isn't what we do. Pincrete (talk) 12:20, 20 December 2018 (UTC)
21. Support again. These lists provide value to exactly nobody, and create work to maintain. Any notable victims should be worked into prose. —swpb^{T go beyond} 14:57, 20 December 2018 (UTC)
22. Support. Somehow, these lists often end up linked, creating either permanent red links, disambiguation links, or redirects back to the article on the event containing the link. bd2412 T 16:58, 20 December 2018 (UTC)
23. Support, since most of the time these lists are of people notable only for being victims of the tragedy. There aren't notable people - if they are notable, mention them in prose. Kirbanzo (talk) 18:04, 20 December 2018 (UTC)
24. Support generally. (responding to ping) I would suggest this belongs in WP:NOTMEMORIAL and should be more explicit and give a basis. The wording proposed should simply identify the WP guidance instead of a vague “normal practices of creating lists of otherwise non-notable people.” Alternative guidance might be “avoid listing names in mass deaths unless the individual names are commonly listed in accounts, or are otherwise notable.” Guidance might mention that in larger events it is infeasible, and that if accounts generally did not do so it would fail WP:V or WP:WEIGHT. Cheers Markbassett (talk) 19:16, 20 December 2018 (UTC)
25. Mostly support, with the caveat that lists provided in secondary sources are reasonable. (Passengers of the RMS Titanic is an appropriate article, because the list can be derived from secondary sources, particularly books.) But most lists of victims of major disasters are inappropriate, because we simply don't know if there will be secondary coverage of the individuals involved (and there isn't, in most cases), and we shouldn't pretend that issues appearing in primary source coverage, like news reports, will necessarily be reflected in the secondary sources. News reports are fond of adding victim lists, both because people want to learn if they know anyone involved, and because it's an easy way of filling up space, but the solid sources we need to use are the actual indication of whether these individuals' place in the disaster be great enough that we need to mention many or all of them by name. Nyttend (talk) 19:48, 20 December 2018 (UTC)
26. Support Not a memorial. valereee (talk) 14:56, 21 December 2018 (UTC)
27. Support A list of people killed in an incident is, on the encyclopedia level, trivia. Wikipedia is neither a memorial site, nor an indiscriminate collection of information; it is an encyclopedia. עוד מישהו Od Mishehu 13:24, 26 December 2018 (UTC)
28. Support Lists of non-notable individuals do not further the reader's understanding of the topic. –dlthewave ☎ 13:28, 30 December 2018 (UTC)
29. Support under the premise established in WP:BLP#Presumption in favor of privacy. --Izno (talk) 18:23, 30 December 2018 (UTC)

Oppose

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)

   Iridescent, you might wish to see this AfD. And, the Babi Yar AFD was a decade back (which is close to a century in wiki-time). ∯WBG^converse 09:12, 3 January 2019 (UTC)

   The 9/11 list was an exceptional case. The numbers involved were huge (the raw text of the names alone came to 120kb); consequently, to source it to Wikipedia's standards would have involved 3000 references (or one reference linked 3000 times) which would have crashed the servers, even had it been split to separate out the four aircraft, three impact sites, and emergency services. I repeat my comment above; if you think consensus has changed, I've given you a bunch of redlinks above any one of which you can turn blue as a test case. ‑ Iridescent 19:34, 3 January 2019 (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)

   Appeal to prior consensus is not a strong argument. Even if that was the old consensus, it seems to be going the other way here. —swpb^{T go beyond} 14:59, 20 December 2018 (UTC)

5. Victims should be included only if there is a reference for them. —Eli355 (talk • contribs) 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 (talk • contribs) 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 (talk • contribs) 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)

   We have a cleanup tag for that: {{prose}}. Nothing about the proposal suggests ignoring WP:NORUSH. —swpb^{T go beyond} 16:26, 20 December 2018 (UTC)

7. Oppose - Can we please just let editors decide things? FOARP (talk) 09:00, 20 December 2018 (UTC)

   That's exactly what we're doing here. —swpb^{T go beyond} 15:03, 20 December 2018 (UTC)

   No, no it isn’t. The people who will vote here will be a vanishingly small sub-set of editors, the most active ones, not in anyway representative of the whole. It will be decided, not based on an actual article, but on what people think in general should be done in a discussion largely detached form the actual subject matter which includes these lists.

   Editors deciding means exactly that - the editors of Wiki, the hundred thousand plus most of whom have never read a policy, deciding whether the articles they edit should include the list or not on a case-by-case basis.

   I mean there’s people !voting here who haven’t started an article in years and whose edits overwhelmingly aren’t in article space. Does that look like “editors deciding” to you? FOARP (talk) 15:36, 21 December 2018 (UTC)

8. Oppose. Rules creep. It's entirely down to the context. Lists of victims may or may not be relevant. -- Necrothesp (talk) 09:38, 20 December 2018 (UTC)
9. Oppose listing names of victims is a useful and natural part of articles on many events.E.M.Gregory (talk) 11:19, 20 December 2018 (UTC)
10. Oppose (pinged here) until last sentence is removed^Thanks, L3X1 ◊distænt write◊ 12:40, 20 December 2018 (UTC)
11. Oppose in many articles the name and residence of the victims provides valuable context for the event itself; but not in all of them. It should be up to each page editors' to figure out what is best for each case. This is, in any event, the general conclusion drawn from TP discussions. This proposal looks rather like an attempt to engineer a top-down solution, one-size fits all. Besides, do bureaucrats want to drown editors in a morass of WP:CREEP? That's one nice way to drive away beginners from this project. XavierItzm (talk) 13:26, 20 December 2018 (UTC)

    In my experience, lack of explicit guidance, and the arguing that results, pushes away far more users than being decisively reverted with a summary that points to MOS, so that one can learn something and quickly move on. —swpb^{T go beyond} 16:18, 20 December 2018 (UTC)

12. Oppose because history has taught us that this will not end up being implemented uniformly. We will still end up with articles including the names of victims of American mass shootings in list format, and Bloody Sunday (1972)#Casualties will not be touched (because there's a huge amount of "relevant detail" in that "narrative" list!); but Remembrance Day bombing and Omagh bombing will never have all victims' names added. Policy will be quoted as to why one article can (must!) have them, and why one can't. Bastun^{Ėġáḍβáś₮ŭŃ!} 14:28, 20 December 2018 (UTC)

    The proposal accounts for your example. Bloody Sunday (1972)#Casualties is not a "bare list" of "names and basic information" – the detail it gives on how these victims died is academically relevant to someone studying the nature of the event. The line created by the proposal is pretty sharp (I'm sure there are edge cases, but these aren't them). Moreover, the mere division of cases by a line, a "non-uniformity" as you'd have it, is the opposite of a problem: it is the sole means of handling diverse cases objectively, and is the basis of the entire MOS! —swpb^{T go beyond} 15:19, 20 December 2018 (UTC)

13. Oppose See Discussion. DonFB (talk) 14:49, 20 December 2018 (UTC)
14. Oppose providing they are named in at least two national reliable sources and are therefore in the public domain so privacy is not an issue. Also this is an example of instruction creep, regards Atlantic306 (talk) 14:55, 20 December 2018 (UTC) (pinged by Cunard)
15. Oppose Instruction creep. SparklingPessimist ^{Scream at me!} 15:02, 20 December 2018 (UTC)
16. Odd oppose. Yes, the bare lists of victim names are bad. But the reason why they are bad is that they should be full descriptions of the people killed. Even though victims obviously play a larger role in any massacre than the killer(s), there is a cult on Wikipedia that believes that victims are nameless sheep unworthy of recollection, while mass murderers are change agents who have earned their place in Valhalla by virtue of the souls they have extracted into their bloodstained blades, raising them to superhuman experience levels. The "bare lists" are often bad compromises between these cultists and the people who want to tell the whole story -- what was really lost in the massacre, rather than just that it happened. But my feeling is that to put a ban on the compromise in this "indiscriminate information" collection will be taken as a victory for the cult and a defeat for the encyclopedists, so I won't have it. Wnt (talk) 15:17, 20 December 2018 (UTC)

    You're challenging a much more fundamental consensus than the one largely at issue here. We're talking about whether victims generally agreed to be non-notable should be listed; you're arguing that all victims are inherently notable, as notable even as the killers. While you can make that case if you want, it's going to be a very uphill push: WP:NBIO confers notability through sources, not as a celebration or reward. —swpb^{T go beyond} 16:13, 20 December 2018 (UTC)

    I don't think anybody has argued that "non-notable" people are notable. "The notability guideline does not determine the content of articles, but only whether the topic should have its own article."[9] Bus stop (talk) 16:35, 20 December 2018 (UTC)

    It's actually worse than that. Wnt's rationale is blatantly opposed to the principle that Wikipedia is not a memorial. Not to mention the name calling directed at the supporters of this motion.--Khajidha (talk) 16:21, 20 December 2018 (UTC)

    "Memorial" seems like a very pliable phrase. If multiple news sources profile the victims of a massacre, then when editors summarize what these sources say as part of the article, just as we would summarize intricate details about the car he mowed them over with or the magazine and bullets he shot them with, that is said to be a "memorial", because Everybody Knows they are nobodies not worth remembering. Whereas the killer, of course, should be covered in lavish detail, as he is an Emissary of Father Death, a deity incarnate, on whose words we hang to know the nature of morality and humanity and to decide what things to ban or mandate for all the ordinary little people. That's not a memorial, no ... maybe it's a shrine. I dunno. I'd just rather let editors summarize all the facts from all the articles printed about a topic. Wnt (talk) 04:46, 25 December 2018 (UTC)

17. Oppose because I think it's poorly written (Could the OP at least make up his mind about whether this new rule is supposed to go in the LISTPEOPLE guideline or in the IINFO policy? The section heading says one and the RFC question says the other), not going to achieve goal of stopping these disputes, and because it doesn't represent the discussions. In particular:
    • It talks about "Victims of crimes and disasters and other tragic events", but the conversation is frequently focused specifically on random mass killings (which, unlike this proposed rule, requires a minimum of four people being killed – this rule is written to apply to all crimes, including those with no fatalities or only one victim).
    • Some supporters of this rule oppose only including these names when they're formatted using unordered bulleted * list formatting, but not opposed to otherwise including these names. As a result, I cannot tell from this proposed text whether the first paragraph in Chicago Tylenol murders#Incidents, which "lists the victims" but does not use "list formatting" to do so, is acceptable, and I don't think anyone else can, either.
    • Then there's the whole thread about whether only "passive" victims should be excluded, so that you exclude the names and locations of the passive victims in the Tylenol murders and most of the non-violent protesters in Peterloo Massacre#Victims, but you include the names of people who did something, and you fight over whether victims of domestic violence or non-resistant martyrs are truly "passive" in the events leading to their murders.
      In short, this rule doesn't seem to get us any closer to actually documenting what the community usually prefers to do. Finally, given the lists below of dozens of articles that contain victims' names, I begin to wonder whether this rule might actually be the opposite of what experienced editors have been doing these last few years. Perhaps those lists aren't representative; I haven't checked for counter-examples (but there sure are a lot of them there...). WhatamIdoing (talk) 16:59, 20 December 2018 (UTC)
18. Oppose as list vs prose illogical - I could get behind the base logic of "don't include all the names of non-notable victims" or some variant of that. I cannot however understand why this should be suitable in prose and not in lists - or at least reliably so. I can understand a top-down policy approach for an all or nothing approach, but if the dispute is going to be formatting based, then it should be left to the editors. Nosebagbear (talk) 18:09, 20 December 2018 (UTC)
19. Oppose (summoned by a ping). I have found lists of victims names useful in the past -- both in terms of human interest and as an aid in further research on the topic. It might not be relevant to you, but it will be relevant to somebody. Often the victims are commemorated with annual events or plaques. There should be some common sense guidelines -- like making sure the names are widely available, providing as much relevant info on the victim (manner of death, any actions taken during the event, any special honors like state funeral after) or limiting/pruning the lists of the number of victims exceed x. There is nothing inherently evil of individually "non-notable" items. Just because it is not a blue link, does not mean that the info is not valuable. Renata (talk) 18:29, 20 December 2018 (UTC)
20. Oppose whether or not some information is encyclopedic has nothing to do with the format the information is in. If a list of five names is unencyclopedic in list format then it is also unencyclopedic in prose format. I don't think it is necessarily unencyclopedic to include these names, and the lists presented below demonstrate that the proposal isn't merely confirming existing practice on this issue. Media organisations do sometimes devote substantial coverage to the victims of an attack, and while that doesn't make them notable it is accepted practice to include coverage of people only known because of one event in the article about that event. Lists of victims may also be useful for other reasons, e.g. Columbine High School massacre has a list of victims presented inline with the text to illustrate the narrative. Hut 8.5 18:40, 20 December 2018 (UTC)
21. Oppose - Handling this on a case-by-case basis is preferable to an outright prohibition. Beyond My Ken (talk) 03:42, 21 December 2018 (UTC)
22. OpposeVictim lists should be the default in articles about mass shootings. First, these articles exist because people were killed in a mass shooting; the identities of these people are an important component of the shooting. If you leave out names and descriptive details, you are omitting key information. Second, the victims of shootings tend to receive substantial news coverage. While we are not required to include everything covered by the news media, the fact that they receive so much coverage (and not just the occasional offhand reference) indicates that their identities are in fact significant. Third, NOTMEMORIAL prohibits creating articles about non-notable people (i.e. its an applied restatement of notability requirements). It says nothing about neutrally worded lists of victims within articles. Spirit of Eagle (talk) 04:31, 21 December 2018 (UTC)
23. Oppose This has long been contentious. The archive at Wikipedia talk:What Wikipedia is not shows the meaning WP:NOTMEMORIAL has been up for grabs ever since it was first written in 2014. Any time the not-memorial policy is cited, half the editors dispute whether or not it is pertinent because there is no consensus as to what the policy even is.

    The false premise hiding behind all this confusion is that the names of dead people are supposedly special facts, requiring special treatment apart from names of pop songs or symphonies, or the names of products, or events in a timeline, or any other fact or piece of data. Recently deceased people can fall under the extra restriction of the WP:BLP policy, under WP:BDP. But if someone has been dead more than 6-12 months or so, their name is not a special fact. Featured articles like Sex Pistols have embedded lists of singles, about two dozen of them, with only 10 or so bluelinked, notable songs. The rest are just listed because they are facts that enhance the article, based on context and editorial judgement. See the list of non-notable works in the FA Franz Kafka. Non-notable stuff is contained in articles, facts or names in prose or list form, like the works in the FA bio Michael Woodruff, or lists of patents or inventions. If an article happens to have names of casualties or victims or whatever associated with it, it's no different than a band that might have names of band members, producers, managers, etc, associated with it. They're just facts. Do the belong in a particular article? It depends. We don't need a special policy just because the facts in question are the names of dead people.

    If you think a given list or article about an event is worse because it lists the names of deceased people, you should be able to make your case without leaning on a special policy that puts a blanket restriction on the names of the deceased. If editorial consensus is that a given page is better because it includes non-notable casualties, or song titles, or articles written, or patents issued, then you should respect that local consensus. Policy can't intervene and tell editors you disagree with that they're wrong. --Dennis Bratland (talk) 05:58, 21 December 2018 (UTC)

    Well said, Dennis Bratland. Renata (talk) 17:24, 22 December 2018 (UTC)

24. Oppose: This is clearly an example of a class of editorial decision that ought to be made as a matter of WP:LOCALCONSENSUS by evaluating the merits of each individual case, taking into account the full encyclopedic context of the event being covered and the nature of the content being considered. Creating a default rule here is unnecessary and indeed the most unwieldy, counter-intuitive, and potentially problematic route to contemplate. I try to stay away from the term "rule creep" where possible (as I personally do not view robust policy as per se negative in most instances) but I have to say it would seem to apply in this instance. Snow ^{let's rap} 07:23, 21 December 2018 (UTC)
25. Oppose per WP:CREEP, WP:NOTLAW and the opposes above. Andrew D. (talk) 09:10, 21 December 2018 (UTC)
26. Oppose This proposal is well-meaning and sounds good in theory, but when I look at article like this,[10] I don't see a problem. A Quest For Knowledge (talk) 21:28, 21 December 2018 (UTC)
27. Oppose {{infobox criminal}} is one such example where a |victims= parameter allows for lists such as these. In light of what Bratland said above about treating facts all the same, it seems arbitrary to say a fact can't come in through the front door when other facts already enter through the side. If this were to become a blanket rule, then all of these other doorways for victim list-inclusion ought to be sealed up as well, shouldn't they?  Spintendo  22:55, 23 December 2018 (UTC)
28. Oppose. I think the local page is often the best place to decide, as I said previously. At the same time, it would be helpful if we had some guidance as when it is and isn't a good idea to include a list. A hard rule isn't the same as guidance. Before we can really reach a consensus on that guidance, or this current rule, I think we need to discuss when it is and isn't a good idea to have lists of names, and develop a criteria that has consensus. Even if it is nothing more than a widely accepted Essay. (like WP:BRD). Also, there needs to be enough wiggle room to deal with what we can't anticipate, which is a lot. A straight up or down vote on disallowing them is never going to pass, and with all due respect, a waste of time. Dennis Brown - 2¢ 16:39, 27 December 2018 (UTC)
29. Oppose First, I dislike having a blanket rule. --Dweller (talk) Become old fashioned! 11:57, 28 December 2018 (UTC)
30. Oppose as extreme WP:CREEP, this should be decided case by case as to what is appropriate for each article, rather than by abstract rule without regard to sources, circumstances, or subject. postdlf (talk) 00:49, 7 January 2019 (UTC)
31. Oppose In a number of articles listed below, the lists seem appropriate. Also WP:CREEP, etc. Hobit (talk) 15:45, 13 January 2019 (UTC)

Neutral

1. LOOKING FOR A THIRD WAY: In a print source, lists like this are often included in footnotes or in an appendix. That's print's way of striking a balance between including all possible information that might be useful to someone later, and keeping the narrative readable. My suggestion would be to look for a "third way" to tidily meet both concerns. FOR EXAMPLE, what if there were a template to use on TALK PAGES to list people involved in an event? OR something similar to the template for succession boxes that could be added to the bottom of pages, and only expands if you click on it? Mary Mark Ockerbloom (talk) 16:37, 24 December 2018 (UTC)

There are emotional reasons why people want to include such lists, and generally they do not improve the quality of the narrative. People trying to get around a new rule won't improve the narrative either, just result in article bloat. There are historical reasons to want to include such lists, and they don't always improve the readability of the narrative either. But the information involved can be useful and a standard technique for handling it would be a way to more easily resolve conflict. Mary Mark Ockerbloom (talk) 16:37, 24 December 2018 (UTC)

1. This should be handled on a case by case basis depending on the article and type of violent incident. If describing the manner/ages/details of how or which victims died would provide additional understanding, a list with explanations of the deaths would be appropriate. For example, the article on the Columbine High School massacre lists the victims, their ages, and how they died, which provides significant understanding as to what people might have been peers of the perpetrators, what people might have been teachers, as well breaking down what parts of their massacre were lethal. This is also demonstrated in the article on the Sandy Hook massacre where distinguishing the teachers, students, and the shooter's mother helps provide understanding of the death toll versus just saying "28 people including the perpetrator were killed".

In contrast, the article on the Lockerbie Bombing provides a detailed breakdown of victims by nationality, as well as notable victims, plus an explanation of which people died on the plane and who died on the ground. This is because providing a detailed list of people who died on the plane like in smaller events would be unwieldy due to the scale of the disaster, and the pertinent information is the nationalities of the victims who have died and groups that the bombing had an outsize influence on (Syracuse University having 35 students die). However, there is a list of people who died on the ground, as while a list of people who died on the flight would not provide too much information to the reader beside a cross section of America/UK/other parts of the world, a list of people who died on the ground allows the reader to understand which houses in Lockerbie were destroyed, as well as how the town was affected by the plane crash.

Honestly, in conclusion, I believe a one-sized fits all policy on lists of names would do more harm than good. Tragedies with large death tolls occur on a spectrum of differentiation that requires a unique assessment of every article in order to see how much detail should be provided in covering the victims of such events. Sometimes it's useful to detail every single person who died and how, in other cases such as plane crashes it might only be useful to detail nationalities, notable people, and specific groups affected. In some cases such as the Mississauga restaurant bombing there's no need to detail specific victims at all, as there's not much to be said about minor injuries. We need to take a case by case basis on every article talk page to see how much detail is appropriate to provide, so I'm !voting neutral instead of oppose as "oppose" would seem to imply that I am definitively in favor of lists, which I am not. Grognard Extraordinaire Chess (talk) Ping when replying 10:39, 27 December 2018 (UTC)

Discussion

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 (talk • contribs) 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 (talk • contribs) 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."[11] 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)

• @Thewolfchild: What makes my comment vague? —Eli355 (talk • contribs) 01:12, 13 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)

thewolfchild—here 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)

Hydronium Hydroxide—you are mentioning Trinity (nuclear test). There were no fatalities in that event and it took place in 1945. You are sort of comparing apples to oranges, aren't you? How does "Trinity (nuclear test)" compare to Stoneman Douglas High School shooting, Sandy Hook Elementary School shooting, Pittsburgh synagogue shooting, Orlando nightclub shooting, Santa Fe High School shooting, Charleston church shooting—to name just a few of our articles in which non-notable victims are mentioned? Why would a decision at "Village pump (policy)" overrule the WP:CONSENSUS of the editors that wrote those articles? I thought WP:CONSENSUS was sort of sacrosanct. Bus stop (talk) 02:58, 15 December 2018 (UTC)

Bus stop: Participants-in-an-event-that-is-tragic and Participants-in-an-event-that-is-not-tragic are both Participants-in-an-event and (from my perspective) should be treated similarly with regards to standards of determination for inclusion in an article; the comparison is of Red delicious apples vs Granny Smith apples. Trinity (nuclear test) is of significantly more impact than any of those events, and led to far more deaths -- thankfully individually unlisted in en-wiki. Non-notable participants (presumably since they are unlinked) are included within that article, but it includes neither indiscriminate lists of those actually involved in the conduct of the test, nor all those who witnessed (part of) it, nor all those present, nor any other indiscriminate list. I'm a little surprised by your final two questions, as you are an editor of so many years experience: Global consensus, where determined, trumps local consensus. If it didn't, then RFCs, AFDs, reasonable adherence to MOS, etc, wouldn't be able to be implemented. This proposal is an attempt to get global consensus on an area where the process of obtaining consensus on a page-by-page basis is deemed by some to be duplicative. Consensus for global consistency and consensus for page-by-page inconsistency may well both lead to groups of unhappy editors, but living with an imperfect standard appears to eat less editor/admin time than page-by-page debates. I understand, for instance, that we're on Infobox Wars part 167 and Cite Wars part 183, though the significant difference is that those are both stylistic preferences, whereas this intersects with actual content policies and guidelines. ^~Hydronium^~Hydroxide^~(Talk)~ 05:01, 15 December 2018 (UTC)

Hydronium Hydroxide—a global consensus in this instance would be running roughshod over a clearly established consensus spread over many articles. We are not talking about 1945. Though unstated, I think we are discussing a more recent period. I listed Stoneman Douglas High School shooting, Sandy Hook Elementary School shooting, Pittsburgh synagogue shooting, Orlando nightclub shooting, Santa Fe High School shooting, Charleston church shooting in my post above. Add to those 2016 Oakland warehouse fire and Columbine High School massacre. Please search the Talk page archives on those articles for the term "victims". Debates took place and a consensus was reached to include the victim names. We shouldn't be enacting policy to curtail the inclusion of victim names because the more broad-based consensus favors the inclusion of victim names. Bus stop (talk) 16:27, 15 December 2018 (UTC)

I don’t disagree... However, we also need to keep in mind that “consensus can change”. It isn’t wrong to occasionally ask whether a previously established consensus is still reflecting what the community thinks. Blueboar (talk) 16:49, 15 December 2018 (UTC)

Bus stop You are being selective by only mentioning articles which have formed a consensus to include. Can I remind you on Talk:USS Fitzgerald and MV ACX Crystal collision the vote is 11 to 5 AGAINST inclusion. I do not understand why you cannot support my suggestion that the issue should be decided on individual article talk pages through consensus but the default position should be no names until that consensus is established. Given the consensus to include (albeit by some very small margins) reached on the articles you have quoted why do you doubt the ability of your fellow editors to come to the correct decision Lyndaship (talk) 16:51, 15 December 2018 (UTC)

I am definitely being "selective", Lyndaship. I am trying to prove a point. And you are trying to prove a point. Therefore you mention the Fitzgerald/Crystal collision article. I can name one more to support your point: Thousand Oaks shooting. Consensus there was to omit. But in the majority of instances consensus has been in favor of inclusion. My evidence is merely anecdotal. I admit that. But another point has to be made: there is no reason the same conclusion has to be reached at all articles. This is not unlike the construction of all articles as concerns the inclusion of content. These are editorial decisions left to editorial discretion. I don't think victim names are all that different from a variety of other pieces of information. I happen to favor the inclusion of the names of fatalities resulting from notable incidents. I think this helps to write a complete article. And I find the deliberate omission of this information to be an uncalled-for truncating of the article. But it is not such a terrible thing if in some instances editors decide by means of our consensus-reaching process to omit these names.

Blueboar—this discussion is not "reflecting what the community thinks". The truest reflection of what the community thinks is seen in consensus at individual articles at which this question has had an airing-out. Bus stop (talk) 17:40, 15 December 2018 (UTC)

• Below is a partial (?) and non-chronological list of this years' other discussions that deal with listing non-notable people. Anyone is welcome to add ones I've missed. ^~Hydronium^~Hydroxide^~(Talk)~ 12:41, 17 December 2018 (UTC):

• Talk:USS_Fitzgerald_and_MV_ACX_Crystal_collision#WP:NOTMEMORIAL_edit
• Talk:2017_Las_Vegas_shooting#Victims_list
• Wikipedia:Village_pump_(proposals)/Archive_149#WP:NOTMEMORIAL_Victim_lists_in_mass_tragedy_articles_-_Round_2
• Wikipedia:Village_pump_(policy)/Archive_138#WP:NOTMEMORIAL_and_victim_lists_in_tragedy_articles
• Talk:Stoneman_Douglas_High_School_shooting/Archive_6#Victims_list_revisited
• Talk:Santa_Fe_High_School_shooting#List_of_victims'_names
• Talk:Schoharie_limousine_crash#List_of_victim_names
• Talk:Humboldt_Broncos_bus_crash#Victims
• Talk:Childers_Palace_Backpackers_Hostel_fire#List_Of_Victims
• Talk:2017_Washington_train_derailment#Follow_WP:BRD_(Bold,_Revert,_and_Discuss):...
• Talk:American_Airlines_Flight_191#Deaths
• Talk:Pittsburgh_synagogue_shooting/Archive_3#Should_names_of_victims_be_listed?
• Talk:Stoneman_Douglas_High_School_shooting/Archive_2#Removed_list_of_victims
• Talk:Umpqua_Community_College_shooting#Names
• Talk:2018_Leicester_helicopter_crash#names
• Talk:Marjory_Stoneman_Douglas_High_School#Shooting
• Wikipedia_talk:WikiProject_Death/Archive_3#Victims_by_Name
• Wikipedia_talk:WikiProject_Ships/Archive_56#Discussion_at_Talk:USS_Fitzgerald_and_MV_ACX_Crystal_collision
• Wikipedia_talk:What_Wikipedia_is_not#NOTMEMORIAL_discussion
• Talk:Tham_Luang_cave_rescue/Archive_2#Naming_the_boys (not dead)
• Talk:2018_Gaza_border_protests/Archive_1#List_of_Palestinian_civilian_deaths_in_Prior_violence
• Talk:2018_Gaza_border_protests/Archive_2#List_of_victims
• Talk:Dunblane_massacre#List_of_victims
• Talk:Thousand_Oaks_shooting#New_Details_On_Injuries_and_a_link_to_the_victims
• Talk:Passengers_of_the_RMS_Titanic/GA2
• Talk:December_2013_Spuyten_Duyvil_derailment
• Talk:Schoharie_limousine_crash#List_of_victim_names
• Talk:Stoneman_Douglas_High_School_shooting/Archive_5#No_consensus_for_victims_list

• It is plainly obvious that in the vast majority of instances consensus supports the inclusion in the article of all the victim names whether notable or not. Please see below. Bus stop (talk) 01:31, 18 December 2018 (UTC)

• Humboldt Broncos bus crash—all victim names included.
• Tham Luang cave rescue —victim name (there is only one) included.
• Stoneman Douglas High School shooting—all victim names included.
• Santa Fe High School shooting—all victim names included.
• Schoharie limousine crash—all victim names included.
• Pittsburgh synagogue shooting—all victim names included.
• Stoneman Douglas High School shooting—all victim names included.
• Umpqua Community College shooting—all victim names included.
• 2018 Leicester helicopter crash—all victim names included.
• Dunblane massacre—all victim names included.
• December 2013 Spuyten Duyvil derailment—all victim names included.
• Schoharie limousine crash—all victim names included.
• Virginia Tech shooting—all victim names included.
• 2012 Aurora shooting—all victim names included.
• Sandy Hook Elementary School shooting—all victim names included.
• Orlando nightclub shooting—all victim names included.
• Charleston church shooting—all victim names included.
• 2016 Oakland warehouse fire—all victim names included.
• Columbine High School massacre—all victim names included.

• It is plainly obvious that in the vast majority of instances consensus supports the inclusion in the article of all the victim names whether notable or not. Please see above. Bus stop (talk) 01:31, 18 December 2018 (UTC)
• Comment: I added notifications to Wikipedia talk:Stand-alone lists (link) and Template:Centralized discussion (link). Cunard (talk) 08:19, 20 December 2018 (UTC)

Its plainly obvious that most of these all American shooting and fairly recent events and hardly reflect the range of articles that potential could have lists of non-notable vicitims. In particularly these type of recent events have a high readership from those interested in these news type events so they expect to see victim names as if this was a newspaper which can slew the voting. So these recent events are not really a reflection on the thousands of articles about tragic events that dont or have never included names of non notable victims. MilborneOne (talk) 08:38, 20 December 2018 (UTC)

It is also plainly obvious that the more gut-wrenchingly awful the event, the more likely the event is to acquire a victim list. I would not be human if I did not sympathise with such a response (Dunblane massacre involved infants and is one of the few UK events listed above) - but is the awfulness of the event really a valid criteria for inclusion/exclusion of names? Because this is what actually happens when 'case by case' is the only guideline (no one has ever articulated how the names serve any useful encyc pupose - the intention, and effect is to 'honour' the victim, by individualising them, which may be an understandable wish, but isn't our mission IMO). Pincrete (talk) 12:33, 20 December 2018 (UTC)

• Many people use NOTMEMORIAL to argue against inclusion of names. As some editors have explained, NotMem does not apply to the individuated contents of an article; it applies to the subject matter of the entire article. (Probably for another full discussion: the NotMem text should be revised to make explicitly clear that it refers to a full article, not to just some of its content.) Properly read, NotMem is not a valid argument for excluding victim names from an article about a crime or calamity. I ask: why do mainstream news sources include names? The answer is because they want to provide comprehensive information. Though Wikipedia is NotANewspaper, it shares that goal: to be comprehensive (but not Indiscriminate or Trivial). As the NY Times is said to be the newspaper "of record," Wikipedia is--or should be--the encyclopedia of record. Having said that, I recognize it may be impractical to include names if the list is very long. A decision can be made at the article Talk page. In the interest of encyclopedic coverage, I believe we should not enact a policy or guideline that attempts to make exclusion of names the default choice. I would flip this proposal on its head (or perhaps, sideways) and say we should add an instruction at WP:Victim or WP:Listpeople to say: "Wikipedia does not encourage or discourage inclusion of names of victims in articles about a crime or calamity. Decisions about the encyclopedic value of such names may be made on Talk pages of articles." Such instruction might or might not reduce chronic debates about this issue, but it could prevent the encyclopedia from working against itself as authoritative and as the place at or near the top of people's choices for information of interest to them. DonFB (talk) 14:49, 20 December 2018 (UTC)

• Pinging the participants of the related discussion Wikipedia:Village pump (policy)/Archive 138#WP:NOTMEMORIAL and victim lists in tragedy articles: SkyWarrior (talk · contribs), Ivanvector (talk · contribs), Softlavender (talk · contribs), Masem (talk · contribs), Pincrete (talk · contribs), SparklingPessimist (talk · contribs), Davey2010 (talk · contribs), Snow Rise (talk · contribs), Nabla (talk · contribs), Mandruss (talk · contribs), swpb (talk · contribs), NinjaRobotPirate (talk · contribs), agnosticaphid (talk · contribs), Seraphimblade (talk · contribs), Dennis Brown (talk · contribs), Eggishorn (talk · contribs), Agathoclea (talk · contribs), postdlf (talk · contribs), HastyBriar321 (talk · contribs), A Quest For Knowledge (talk · contribs), L3X1 (talk · contribs), Coretheapple (talk · contribs), Graeme Bartlett (talk · contribs), Hawkeye7 (talk · contribs), Nihlus (talk · contribs), Rich Farmbrough (talk · contribs), Necrothesp (talk · contribs), Carwil (talk · contribs), Dicklyon (talk · contribs), Renata3 (talk · contribs), FOARP (talk · contribs), Knowledgekid87 (talk · contribs), Atlantic306 (talk · contribs), E.M.Gregory (talk · contribs), Patapsco913 (talk · contribs), BU Rob13 (talk · contribs), gidonb (talk · contribs), Sławomir Biały (talk · contribs), Huggums537 (talk · contribs), Flyer22 Reborn (talk · contribs), DonFB (talk · contribs), Herostratus (talk · contribs), Markbassett (talk · contribs), SMcCandlish (talk · contribs), Blueboar (talk · contribs), IJReid (talk · contribs), Hydronium Hydroxide (talk · contribs), and Abductive (talk · contribs).

  Cunard (talk) 08:52, 20 December 2018 (UTC)

• Pinging the participants of the related discussion Wikipedia:Village pump (proposals)/Archive 149#WP:NOTMEMORIAL Victim lists in mass tragedy articles - Round 2: Bohbye (talk · contribs), Spirit of Eagle (talk · contribs), Bastun (talk · contribs), Wnt (talk · contribs), WhatamIdoing (talk · contribs), Khajidha (talk · contribs), Edibobb (talk · contribs), No such user (talk · contribs), Alsee (talk · contribs), Zchrykng (talk · contribs), Slatersteven (talk · contribs), K.e.coffman (talk · contribs), Kierzek (talk · contribs), Ad Orientem (talk · contribs), Beeblebrox (talk · contribs), Bus stop (talk · contribs), Richard0612 (talk · contribs), Legacypac (talk · contribs), Amakuru (talk · contribs), WikiVirusC (talk · contribs), RileyBugz (talk · contribs), Hut 8.5 (talk · contribs), Cullen328 (talk · contribs), Bellezzasolo (talk · contribs), Javert2113 (talk · contribs), Nyttend (talk · contribs), Pbsouthwood (talk · contribs), Bagumba (talk · contribs), and Cesdeva (talk · contribs).

  Cunard (talk) 08:54, 20 December 2018 (UTC)

Even the below represents only a small fraction of the number of articles mentioning identifying information pertaining to fatalities including name. This list, I believe, could be expanded many times over. The conclusion that I reach is that inclusion of such information is standard practice. I am posting this despite the fact that it takes up so much room because I don't think many participants in this discussion appreciate just how widespread the practice is. We generally allude in one form or another to deceased individuals. It is hard to say whether this is "memorialization" or not. I strongly believe it is relevant to an article. But in some instances editorial consensus is to omit identifying information for decedents. But the point is that in most instances such information is included. Bus stop (talk) 14:04, 20 December 2018 (UTC)

I only looked at a handful of the articles below (mainly UK IRA events), but in no case was there a bare list - including names in prose, where the individual had a significant role in the event is precisely what is proposed. In many/most cases that I looked from this list, this is what has already happened. Pincrete (talk) 20:27, 20 December 2018 (UTC)

Standard practice is for inclusion. In the vast majority of the articles that I've looked at, some degree of allusion is made to the identities of the deceased. I have not made a distinction between list and prose as concerns this discussion. I don't consider one preferable to the other. As concerns depth of identity of decedents, I have encountered a wide range—from just the name to more extensive background information. In a small number of the articles I've looked at, the identities of the deceased are absent entirely from the article. Those sorts of articles are not included in the list below. I am at this moment adding a considerable number of articles to the below list. I hope I haven't added any articles twice, and I apologize if I have. Bus stop (talk) 14:16, 21 December 2018 (UTC)

• West Ham station attack—all victim names included.
• 1975 Piccadilly bombing—all victim names included.
• Walton's Restaurant bombing—all victim names included.
• Scott's Oyster Bar bombing—all victim names included.
• Kings Arms, Woolwich—all victim names included.
• Columbine Mine massacre—all victim names included.
• University of Texas tower shooting—all victim names included.
• Red Lake shootings—all victim names included.
• Oikos University shooting—all victim names included.
• Northern Illinois University shooting—all victim names included.
• Rancho Tehama Reserve shootings—all victim names included.
• 2013 Santa Monica shooting—all victim names included.
• West Nickel Mines School shooting—all victim names included.
• University of Iowa shooting—all victim names included.
• Mitchell Johnson and Andrew Golden—all victim names included.
• Marysville Pilchuck High School shooting—all victim names included.
• Thurston High School shooting—all victim names included.
• Lindhurst High School shooting—all victim names included.
• Kent State shootings—all victim names included.
• Mercy Hospital shooting—all victim names included.
• Tallahassee shooting—all victim names included.
• Capital Gazette shooting—all victim names included.
• Jacksonville Landing shooting—all victim names included.
• 2018 Scottsdale spree shootings—all victim names included.
• Burnette Chapel shooting—all victim names included.
• Yountville shooting—all victim names included.
• Marshall County High School shooting—all victim names included.
• Rancho Tehama Reserve shootings—all victim names included.
• 2017 Plano shooting—all victim names included.
• Clovis library shooting—all victim names included.
• San Francisco UPS shooting—all victim names included.
• Eaton Township Weis Markets shooting—all victim names included.
• Sandy, Utah attack—all victim names included.
• Orlando factory shooting—all victim names included.
• 2017 Schofield/Rothschild shootings—all victim names included.
• Cascade Mall shooting—all victim names included.
• 2016 Citronelle homicides—all victim names included.
• 2016 Mukilteo shooting—all victim names included.
• 2016 shooting of Baton Rouge police officers—all victim names included.
• St. Joseph courthouse shooting—all victim names included.
• 2016 shooting of Dallas police officers—all victim names included.
• 2016 Maryland shooting spree—all victim names included.
• Pike County, Ohio shootings—all victim names included.
• 2016 Wilkinsburg mass shooting—all victim names included.
• Hesston shooting—all victim names included.
• 2016 Kalamazoo shootings—all victim names included.
• 2015 San Bernardino attack—all victim names included.
• Colorado Springs Planned Parenthood shooting—all victim names included.
• 2015 Harris County, Texas shooting—all victim names included.
• 2015 Lafayette shooting—all victim names included.
• Mercy Hospital shooting—all victim names included.
• Tallahassee shooting—all victim names included.
• Capital Gazette shooting—all victim names included.
• Jacksonville Landing shooting—all victim names included.
• 2018 Scottsdale spree shootings—all victim names included.
• Burnette Chapel shooting—all victim names included.
• Yountville shooting—all victim names included.
• Marshall County High School shooting—all victim names included.
• Rancho Tehama Reserve shootings—all victim names included.
• 2017 Plano shooting—all victim names included.
• Clovis library shooting—all victim names included.
• San Francisco UPS shooting—all victim names included.
• Eaton Township Weis Markets shooting—all victim names included.
• Sandy, Utah attack—all victim names included.
• Orlando factory shooting—all victim names included.
• 2017 Schofield/Rothschild shootings—all victim names included.
• Cascade Mall shooting—all victim names included.
• 2016 Citronelle homicides—all victim names included.
• 2016 Mukilteo shooting—all victim names included.
• 2016 shooting of Baton Rouge police officers—all victim names included.
• St. Joseph courthouse shooting—all victim names included.
• 2016 shooting of Dallas police officers—all victim names included.
• 2016 Maryland shooting spree—all victim names included.
• Pike County, Ohio shootings—all victim names included.
• 2016 Wilkinsburg mass shooting—all victim names included.
• Hesston shooting—all victim names included.
• 2016 Kalamazoo shootings—all victim names included.
• 2015 San Bernardino attack—all victim names included.
• Colorado Springs Planned Parenthood shooting—all victim names included.
• 2015 Harris County, Texas shooting—all victim names included.
• 2015 Lafayette shooting—all victim names included.
• 2015 Chattanooga shootings—all victim names included.
• 2015 Waco shootout—all victim names included.
• 2015 Tyrone shooting—all victim names included.
• Montgomery County, Pennsylvania shootings—all victim names included.
• Marysville Pilchuck High School shooting—all victim names included.
• 2014 Harris County, Texas shooting—all victim names included.
• 2014 Isla Vista killings—all victim names included.
• 2014 Fort Hood shooting—all victim names included.
• 2013 Los Angeles International Airport shooting—all victim names included.
• Washington Navy Yard shooting—all victim names included.
• Ross Township Municipal Building shooting—all victim names included.
• 2013 Hialeah shooting—all victim names included.
• 2013 Santa Monica shooting—all victim names included.
• 2013 South Valley homicides—all victim names included.
• 2012 Empire State Building shooting—all victim names included.
• Wisconsin Sikh temple shooting—all victim names included.
• Chardon High School shooting—all victim names included.
• 2011 Seal Beach shooting—all victim names included.
• 2011 IHOP shooting—all victim names included.
• 2011 Tucson shooting—all victim names included.
• Hartford Distributors shooting—all victim names included.
• University of Alabama in Huntsville shooting—all victim names included.
• 2010 Appomattox shootings—all victim names included.
• ABB plant shootings—all victim names included.
• 2009 Fort Hood shooting—all victim names included.
• 2009 Collier Township shooting—all victim names included.
• 2009 shooting of Pittsburgh police officers—all victim names included.
• Binghamton shootings—all victim names included.
• Carthage nursing home shooting—all victim names included.
• Geneva County massacre—all victim names included.
• Covina massacre—all victim names included.
• 2008 Skagit County shooting spree—all victim names included.
• Northern Illinois University shooting—all victim names included.
• Kirkwood City Council shooting—all victim names included.
• 2007 Colorado YWAM and New Life shootings—all victim names included.
• Westroads Mall shooting—all victim names included.
• Trolley Square shooting—all victim names included.
• West Nickel Mines School shooting—all victim names included.
• Capitol Hill massacre—all victim names included.
• Goleta postal facility shootings—all victim names included.
• Red Lake shootings—all victim names included.
• Chai Vang—all victim names included.
• Marcus Wesson—all victim names included.
• Lockheed Martin shooting—all victim names included.
• John McDonogh High School shooting—all victim names included.
• D.C. sniper attacks—all victim names included.
• Appalachian School of Law shooting—all victim names included.
• Charles Andrew Williams—all victim names included.
• 2001 Nevada County shootings—all victim names included.
• Xerox murders—all victim names included.
• Larry Gene Ashbrook—all victim names included.
• Mark O. Barton—all victim names included.
• Thurston High School shooting—all victim names included.
• Mitchell Johnson and Andrew Golden—all victim names included.
• Pearl High School shooting—all victim names included.
• Bethel Regional High School shooting—all victim names included.
• Frontier Middle School shooting—all victim names included.
• Wickliffe Middle School shooting—all victim names included.
• 1993 Aurora shooting—all victim names included.
• 1993 Long Island Rail Road shooting—all victim names included.
• 101 California Street shooting—all victim names included.
• Wayne Lo—all victim names included.
• Lindhurst High School shooting—all victim names included.
• University of Iowa shooting—all victim names included.
• Luby's shooting—all victim names included.
• James Edward Pough—all victim names included.
• Las Cruces bowling alley massacre—all victim names included.
• Cleveland Elementary School shooting (Stockton)—all victim names included.
• Oakland Elementary School shooting—all victim names included.
• Old Salisbury Road shooting—all victim names included.
• Richard Farley—all victim names included.
• Ronald Gene Simmons—all victim names included.
• Edmond post office shooting—all victim names included.
• San Ysidro McDonald's massacre—all victim names included.
• Tyrone Mitchell—all victim names included.
• George Banks—all victim names included.
• Carl Robert Brown—all victim names included.
• Oregon Museum Tavern shooting—all victim names included.
• Greensboro massacre—all victim names included.
• Cleveland Elementary School shooting (San Diego)—all victim names included.
• Golden Dragon massacre—all victim names included.
• James Ruppert—all victim names included.
• Olean High School shooting—all victim names included.
• Ronald DeFeo Jr.—all victim names included.
• Jackson State killings—all victim names included.
• Orangeburg massacre—all victim names included.
• University of Texas tower shooting—all victim names included.

• It seems simple to me. JUST FOLLOW THE CITES. If most sources list the victims then WP should. If most sources do not then WP should not. Do not OR up a list, do not add prose that is UNDUE or OR. Just follow whatever the sources do and how they do it. Cheers Markbassett (talk) 19:25, 20 December 2018 (UTC)
• I used to be strongly against memorializing the victims in these sorts of articles, but I have come around to an abide-by-the-consensus-of-secondary-sources position, with an important caveat that the sources be in English. One should be careful to avoid sources that are biased or are attempting to gain political victimhood for an ethnic group. Abductive (reasoning) 05:18, 21 December 2018 (UTC)
• It would concern me that if we allow listing of non-noteworthy victims then we would have a lot of work in hand as some maritime disasters would need in some cases 1000 or more names to be added all of which are available in reliable sources, or is this one rule for recent and particularly American events but doesnt apply to ones outside of memory. It would be good to list the millions of victims of tragic events particularly in wartime but why should they be treated differently to an American school shooting with ten vicitms. MilborneOne (talk) 13:44, 25 December 2018 (UTC)
• That's a good point about accessibility. Where there is an easily accessible list on line (which is likely to remain accessible) then lengthy lists would seem to be a waste of time. In some cases however the list of names many not be available on line and therefore as the world's principal "go-to" reference we should consider including them. It doesn't need to be mandatory, but perhaps the deletionists might allow lists to remain, particularly if they were stand-alone lists which did not dominate the main article. Martin of Sheffield (talk) 15:37, 25 December 2018 (UTC)

(edit conflict) MilborneOne—you say "It would concern me that if we allow listing of non-noteworthy victims then we would have a lot of work in hand". Wouldn't we have a lot of work in hand rewriting the hundreds of articles that presently include all victim names? In my estimation 90% of the articles I've encountered include all victim names.

You didn't mention "memorialization" but let me point out that the information on victims is severely limited therefore it may not constitute memorialization. At most we find name, age, role-in-life, such as cop, teacher, student, and maybe home-town. Bus stop (talk) 16:20, 25 December 2018 (UTC)

Clearly not looking at the same set of articles as me as very for example maritime tragic events do not have lists of victims (an those like Titanic that do are subject to some bickering), loads of other examples. We dont list the 2,259 victims of the Bhopal disaster as one example or the 1012 victims of the RMS Empress of Ireland. MilborneOne (talk) 17:33, 25 December 2018 (UTC)

I believe that where practicable our standard practice is to list all victims both notable and non-notable. A large number of victims presents a case where it is impractical to list all victims. You may be right that maritime events may show a lower incidence of inclusion of victims. I haven't looked at those sorts of articles in great numbers so I just don't know. Editors have by-and-large been exercising good judgement over the years, judging by the articles I have looked at. "Bickering" is not a good enough reason for enacting new policy. "Bickering" goes on in many places on the encyclopedia. What we want are good articles. In my opinion it is unlikely that we can enact policy that has the twin effect of reducing bickering and producing the best possible articles because collaborative editing inevitably involves dissension and disagreement. Talk pages properly used result in good articles where a high degree of collaboration is involved, that is, when a lot of editors are involved in the writing of one article. Bus stop (talk) 17:58, 25 December 2018 (UTC)

By extension of the reasoning in your first paragraph, this encyclopedia should never have been started because it was too much work. Even if your dubious 90% were 100%, we are allowed to decide to change the encyclopedia's direction without "appeal to status quo" like that. Wikipedia is a work in progress. (Of course my comment applies to any argument about amount of work, including MilborneOne's if that's what they meant. Amount of work should be extremely low on our priority list, on any issue.) ―Mandruss ☎ 16:32, 25 December 2018 (UTC)

Mandruss—was the editorial judgement that went into the writing of all of the articles containing victim names somehow flawed? As FOARP has perceptively said "The people who will vote here will be a vanishingly small sub-set of editors."

If you feel that my "90%" figure is "dubious" I am willing to stand corrected. I have taken the time to pore through many articles that seem to fit the criteria that would make them candidates for this discussion. And I have listed those that support my position. It is true that I did not list the articles that might support your position. I can do little more than state in complete honesty that my crude impression is that 90% of the articles I looked at included all victim names. And it is not only the percentage that matters to the discussion we are having. It is also the total number of articles involved—it is a huge number of articles. I think the list of articles could be expanded several times. I have not attempted to do so because I'm not nuts. Bus stop (talk) 16:56, 25 December 2018 (UTC)

• Comment I see above it has been said that no rationale has been provided for including the list of victims. Put simply the rationale for including a list of victims is 1) it is a relevant fact about the incident, equally as relevant as the number of victims, we know that it is relevant because reliable sources treat it as such. 2) It aids with the understanding of the incident - consider how you might actually describe what happened in this incident without using the names of the victims: you would be left saying "his first victim was killed doing X, then his second victim was killed doing Y", and the reader would be easily confused as to which victim was being referred to if they were only described as numbers.
• WP:NOTMEMORIAL has been raised above, but people really need to read what that policy says. It says: "Memorials. Subjects of encyclopedia articles must satisfy Wikipedia's notability requirements. Wikipedia is not the place to memorialize deceased friends, relatives, acquaintances, or others who do not meet such requirements." (emphasis added). It is clear that NOTMEMORIAL is about the subject of the article being notable, and not a ban on lists of people who died in any particular incident. Where the article is about a notable event NOTMEMORIAL falls by the wayside. FOARP (talk) 23:08, 26 December 2018 (UTC)

To be fair not memorial is used as it reflects the views of some users that the only reason we would be adding lists of hundreds or in some cases it could be thousands in one article of not noteworthy individuals would be to memorialise them, so far not other valid reason has been raised why a simple link to an external source is not good enough. So yes the policy may not apply but the spirit does. MilborneOne (talk) 13:29, 27 December 2018 (UTC)

There really aren't articles containing hundreds of victims, at least not to my knowledge. You are talking about the spirit of WP:MEMORIAL. The spirit of WP:MEMORIAL is that we don't create articles on non-notable individuals. I would say that the application of WP:MEMORIAL to this discussion is a misapplication of policy. We can give the benefit of the doubt and say that the reference is to the dictionary definition of memorialization. But the limited amount of information we are providing shows this is not the case. True memorialization involves more extensive information than name, rank, and number. True memorialization involves the presentation of vignettes from the deceased person's life that tug at the heartstrings with their poignancy. We do not indulge in that sort of thing. The sole purpose of our editors is an informational purpose. This is part of explicating a subject. Can you point to an article engaging in sentimentality in the presentation of the identities of fatalities? Bus stop (talk) 16:25, 27 December 2018 (UTC)

Yeah, this appears to be a big misunderstanding on the part of the people in support of this proposition. We are not naming/listing those killed out of sentiment. We are doing so because - particularly in the context of terrorist attacks and mass shootings - it is an important part of describing what happened AND it's information that reliable sources treat as important. FOARP (talk) 21:12, 27 December 2018 (UTC)

Break (victims)

Except that in most cases, the bombers/shooters/etc don't really care about who dies. The point is to attack "location X", who exactly is at location X doen't figure into it. If an individual is specifically targeted (if the shooter says "I'm gonna kill you Mitchell!) then that person should be named. If a specific group of unnamed individuals is targeted (say, if the shooter says "all you cheerleaders are bitches who deserve to die") we should state that he targeted that group - without specifically saying that Brittany, Megan, and Rebecca were killed. Absent something like that we should just identify what the general group or location targeted was. For example, "the perpetrator rammed his car into a crowd outside the theater, killing 17" or "the bomb was placed in Monomonee Falls High School, the explosion killed 4 teachers and 9 students" or "the shooter fired into his place of employment, killing 12 people". List people who were explicit targets but not those who are basically collateral damage. --Khajidha (talk) 22:43, 28 December 2018 (UTC)

When a psychopathic murder kills John Smith first, then John Doe, then Jane Smith, then Jane Doe, and reliable sources state that this is what happened, then we should say exactly that in our article because that is exactly what happened. To advocate anything else is to advocate making this encyclopedia less accurate without good reason, and to ignore what the reliable sources themselves state was important about the event. It doesn't matter what format this is stated in. FOARP (talk) 17:18, 29 December 2018 (UTC)

There's a difference between specifically killing John Smith, John Doe, Jane Smith, and Jane Doe and going on a random spree that just happens to end in those people's deaths. In the first, the names are relevant, in the second they aren't. --Khajidha (talk) 19:13, 29 December 2018 (UTC)

You're saying we should first determine the intent of the killer before writing the article. Intent is something that the police, prosecutors, and courts themselves struggle mightily to determine and often get wrong. It clearly is relevant to discuss who was killed when in an article about a massacre or a serial killer since the murderer is progressing from one victim to the next. Indicating victims by numbers or letters ("Victim 1", "Person A"), rather than by their names - something we would have to do if we were not allowed to name victims - is a form of editorialising and requires us to ignore something that reliable sources find important (the identities of the victims).

I find the problem in these discussion is that they are divorced from the reality of the actual subject matter of the actual articles that are discussing. It is useful, then, to consider concrete cases. Please tell me, therefore, how would you describe this incident without naming the victims? FOARP (talk) 10:55, 30 December 2018 (UTC)

"Dunlap entered the restaurant at 9:00 p.m., where he ordered a ham and cheese sandwich and played an arcade game. He then hid in a restroom at about 9:50 p.m. He exited the restroom after closing at 10:05 p.m. and shot five employees with a .25-caliber semiautomatic pistol.

The first victim was shot while cleaning the salad bar. She was hit from close range in the right ear and was mortally wounded. Another victim was fatally shot near the left eye as he was vacuuming. A third pleaded for her life and sunk to her knees, but Dunlap fatally shot her once through the top of her head. Bobby Stephens, 20, the lone survivor of the shooting, returned to the restaurant after taking a break by smoking outside, thinking the noise he heard from the restaurant when he was outside were children popping balloons nearby.

As he walked into the restaurant and unloaded utensils into the dishwasher, Dunlap came through the kitchen door, raised the handgun at him, and fired a shot that struck Stephens in the jaw. He then fell to the floor and played dead. Dunlap then forced the store manager to unlock the safe. After she opened it, Dunlap shot her in the ear. As he was taking the cash out of the safe, Dunlap fired a second fatal shot through her other ear after he noticed she was still moving.[2] The manager who fired Dunlap was not present at the restaurant.

Stephens escaped through a back door and walked to the nearby Mill Pond apartment complex, where he pounded on a door to alert someone that he and others had been shot at the Chuck E. Cheese. Stephens was hospitalized at Denver General Hospital in fair condition. As authorities arrived on the scene, they found two bodies in the restaurant's hallway, a third in a room off the hallway, and the fourth in the manager's office. The initial victim was sent to Denver General Hospital, where she was declared brain dead.[2] She died from her injuries the next day at Aurora Regional Medical Center.[3]

Dunlap fled the scene with $1,500 worth of cash and game tokens he stole from inside the restaurant. Dunlap was arrested at his mother's apartment twelve hours later.[ " --Khajidha (talk) 16:16, 30 December 2018 (UTC)

Khajidha—we are here to provide information. Reliable sources exist to provide information also. It is not that everything that is reliably sourced must be in an article, but the determining factor as to whether to include something or not is the consensus reached at an individual article. I don't think blanket rules are arrived at, at the Village pump as to whether or not to name fatalities. This is a decision that is best made at an individual article. If we arrive at a "blanket rule" here, the consequence will be the tying of the hands of individual editors for no good reason. Dialogue is essential to reaching the correct conclusions on issues of disagreement, but with the existence of a "blanket rule", dialogue would effectively be suppressed. The sort of reasoning you are presenting—that non-targeted victims should not be mentioned—could be presented by you or any other editor on an individual article's Talk page. Other editors may agree with you and others may disagree with you. No doubt other editors will raise additional factors that they feel should be taken into consideration. But that dialogue is eliminated when you devise "blanket rules" that do not serve serious purposes. What is the important principle at stake here? There is no important principle at stake here. We are discussing facts that are clearly within the scope of the article. Whether or not to include them is an editorial decision. Dialogue is essential to reaching the right decision on whether to include or omit. Bus stop (talk) 15:28, 30 December 2018 (UTC)

The good reason is that these names are unencyclopedic. --Khajidha (talk) 16:16, 30 December 2018 (UTC)

You're not defining "unencyclopedic". This is reliably sourced information that is within the scope of the article. I understand that we do not include all reliably sourced information, even if it is within an scope of the article. But what is the big deal with this information that would suggest that we should enact new policy to curtail its inclusion in articles? We use Talk pages to resolve all sorts of disagreements all the time. Would you argue that we cannot use the Talk pages of individual articles to resolve questions like this?

Khajidha—the version you wrote for "1993 Aurora shooting" is fine—if editors agree with you. Which editors? The editors at the Village pump? No—the editors at "1993 Aurora shooting". That is where consensus should be formed because that is where that specific article is being discussed. Bus stop (talk) 16:38, 30 December 2018 (UTC)

Precisely. Let's look at what an article rewritten to this standard looks like: "The first victim was shot while cleaning the salad bar. She was hit from close range in the right ear and was mortally wounded." So, the gender of the victim is important, the fact they were standing next to the salad bar when shot is important, the fact they were shot in the right ear is important - but who they actually were is not relevant information to include? Instead identifying them by the order in which they were killed - which may not always be clear? — Preceding unsigned comment added by FOARP (talk • contribs) 17:35, 30 December 2018 (UTC)

Actually, I'd be fine with even less detail.--Khajidha (talk) 18:43, 30 December 2018 (UTC)

This thread is missing the point: This is not a proposal to prohibit naming victims entirely, in fact it specifically states Victims of crimes and disasters and other tragic events may be named as a normal part of a quality prose narrative. Narratives like this one would still stand. As an aside, my personal opinion is that 1993 Aurora shooting is far too detailed. The description was pulled from an exhaustive court transcript, while other sources simply say that he shot the victims in the head and one survivor escaped through the back door. –dlthewave ☎ 19:08, 30 December 2018 (UTC)

Dlthewave—it doesn't matter if victims are listed in prose form or list form. OK, it matters, but it matters to those writing the article. They are in the best position to decide on one form or the other. More than one of the sources already in the "1993 Aurora shooting" article include the names of all of the fatalities. It is up to the editors at an article, after weighing all of the applicable factors, to decide whether to use "prose" or "lists". Neither way is preferable to the other in a general sense. These are alternative ways of presenting information. We should not be trying to come up with a formula at the Village pump for articles that have a particular array of applicable factors known best by those trying to write those articles. I should also add that omitting the names of the fatalities is also acceptable. In a minority of articles it was decided to omit the names of the fatalities. These should be considered decisions best left to editorial discretion. Those working on the article are the best ones to make these decisions. Bus stop (talk) 20:49, 30 December 2018 (UTC)

As I said in my comment further up the chain "It doesn't matter what format this is stated in". I am aware that the proposal makes a distinction between prose and tables, but there is no basis for limiting the editor's choices as to how to describe an event in this fashion. FOARP (talk) 21:51, 30 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))

Background

This subsection was written by the RfC initiator (Jc86035) and drafted with input from others. You may prefer to read other opinions first.

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

Should the authority control template link to websites that are not primarily 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 ID (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 [t^hɑ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
  PAGE) 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)
      • Then you are in the wrong venue. Good luck taking {{Authority control}} to TfD. Interesting, though that you - wrongly - seem to think this is about Wikidata. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:39, 14 December 2018 (UTC)
        • Please don't answer to me if you have nothing constructive to add. Fram (talk) 11:06, 14 December 2018 (UTC)
          • I am happy to state categorically that I won't ever answer to you, under any circumstance. I take it you've not taken the template to TfD, after all? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 23:42, 14 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)
  • @Pigsonthewing: I tried to write it somewhat succinctly. Some websites (like MusicBrainz) are "primarily databases" in that what Wikidata links to is more data; and some websites (like Twitter) are not "primarily databases" in that what Wikidata links to is a page hosting something else that is not easily parseable or not primarily or particularly useful as data. Jc86035 (talk) 09:00, 15 December 2018 (UTC)
    • Twitter is a database. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 00:52, 18 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)
• No As per Fram above. Not in scope. Only in death does duty end (talk) 21:09, 14 December 2018 (UTC)
• No, generally. Certain exceptions may apply; see store for details. --Izno (talk) 22:57, 15 December 2018 (UTC)
• No. Please read Authority control#Authority records and files: this template is meant to contain an article's record in various authority files, and non-databases can't possibly be authority files. Nyttend (talk) 22:49, 17 December 2018 (UTC)
• Comment how do we feel about things like ODNB IDs? And for heritage buildings, their listings on their country's heritage listing website? I think both would be great things to drive off the authority control template, as those links are already uploaded onto Wikidata but nobody knows it's there. Blythwood (talk) 00:16, 2 January 2019 (UTC)

Question 2 (exclusion of particular groups of identifiers)

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?

• None that I can think of, although it's worth noting that it would be technically possible to e.g. only show Facebook username (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 [t^hɑ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)
• Yes Per Tom/Wugapodes. Only in death does duty end (talk) 21:10, 14 December 2018 (UTC)
• Not generally, no. Local consensus for this template seems fine. --Izno (talk) 22:57, 15 December 2018 (UTC)
• Yes. If we do this, every instance of the template should have one non-database link: https://www.loc.gov/rr/print/resource/228_authfile.html, which will teach users what an authority file is, what it does, and what one does with it. Nothing else, because this link will demonstrate the foolishness of linking anything other than authority records in such a template. Nyttend (talk) 22:52, 17 December 2018 (UTC)

Question 3 (openly editable and user-generated websites)

Should the template link to databases/websites where anyone can edit or add content without a moderator's permission?

• 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 [t^hɑ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, Discogs.com, 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)
  • As do ISNI... Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:53, 14 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)
• Comment. The Yes votes all say that AC links don't need to meet the requirements of WP:RS. But does the reader see it this way? The special box, the restricted template editing, the very name "Authority Control": these all convey a level of confidence in these links that is betrayed if they turn out to include amateur databases and Wikia-style sites. Not only will readers be confused, but think how hard it would be to convince editors not to cite user-gen/amateur material when it's attached to the bottom of every page. We need to hold on to the concept of "library catalog" as it is commonly understood, or else drastically revise all the AC documentation to make clear what it means on Wikipedia. KokoPhantom (talk) 17:30, 14 December 2018 (UTC)
• No per Nikkimaria As a general rule it should be no. With scope for specific exceptions after appropriate discussion. Only in death does duty end (talk) 21:12, 14 December 2018 (UTC)
• If there are any such sites which actually meet the definition of an authority control, sure. Color me skeptical, however. --Izno (talk) 22:57, 15 December 2018 (UTC)
• No. Something like Findagrave or IMDB would be useful, and on principle I'd want to include them, but the problem is that anyone can repurpose the page completely and thus cause our link to be wrong. Consider a page on such a database for "Theodore Roosevelt"; one person might write it to cover Theodore Roosevelt, Sr., the U.S. President, but another might replace it with data for Theodore Roosevelt, Jr., his son, and move the president somewhere else. If we found the president and linked his record to our article on him, and then he got replaced with the son, our record would be linking to the wrong individual, and we'd have no way to know that it was wrong until someone followed the link and detected the error. (This is why it's important that we have a feature that automatically updates Wikidata when a page gets moved.) We should only be linking databases that have a reputation for stability. Nyttend (talk) 23:01, 17 December 2018 (UTC)
• Probably yes-although I'm well aware of the limits of external databases, I think that readers can understand that when they leave Wikipedia they're moving to a different website that may have different content and moderation standards. Ultimately, most articles on movie people do have an IMDB template, so what that means is ideal practice is to have 1) an IMDB link on Wikidata that nobody knows about, 2) an IMDB link on Wikipedia that everyone is going to click on anyway but has to be created separately. I think it's too much: one authority control template is so much simpler. Blythwood (talk) 00:12, 2 January 2019 (UTC)

Question 4 (commercially operated websites)

Should the template link to websites which are not operated by governments or non-profit organizations?

• 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 [t^hɑ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)
• Whether a site is commercial in nature is irrelevant to whether it is an authority control. See also my answer to question 3. --Izno (talk) 22:57, 15 December 2018 (UTC)
• Yes. If it's a standard authority file and it's stable, why not? Nobody suffers if a solid commercial authority file is linked, and leaving out a link to such an authority file would be harmful (at least to a small extent). I can't think of anything immediately that I'd suggest linking, but maybe that's because I'm not a cataloguer. Nyttend (talk) 23:04, 17 December 2018 (UTC)
• No This question is malformed and any consensus on it should be nonbinding: The quality type of authoritative database is academic, not governmental or nonprofit. As for commercial databases, they should only be used when no equivalent source from the other types are available. Free-market commercial databases are prone to giving undue weight to valued clients and products while suppressing competitors and dead weight. Though they may have utility in certain situations (decided on a case-by-case basis), it's unrealistic to think sales-based databases like Amazon or iTunes can be considered the same as a real library catalog. KokoPhantom (talk) 20:22, 31 December 2018 (UTC)

Question 5 (separate Wikidata external links template)

Should a new template be created to show other external links from Wikidata?

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

    I agree that the links displayed would be more compressed; I don't agree that in most cases there would be fewer of them overall. Far more likely we'd end up including multiple similar links that don't add anything useful, as part of the template. Nikkimaria (talk) 04:25, 14 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)
• No Not a link farm. Only in death does duty end (talk) 21:13, 14 December 2018 (UTC)
• In the same vein as {{authority control}}? No. Our current sampling of external links templates is sufficient for today. (At some point in the future, there may be a better way to provide links on English Wikipedia.) --Izno (talk) 22:57, 15 December 2018 (UTC)

Question 6 (design and function of external links template)

If such a template is created: (a) should it be a navbox, a bulleted list, or a horizontal list; (b) should it group links by their content type; (c) should it only show selected groups of links based on a parameter's input; (d) should it accept local values for external identifiers; (e) what format should be used to display links?

• 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)
• As above, not like {{authority control}} or other navboxes. (Particularly, the mobile exclusion of navboxes seems like a decent reason to reject the navbox format for external links.) As for the other items in (a), it should be either bulleted or horizontal. (b) Generally. (c) No? It is not obvious to me what is in mind here. (d) No. That's 0 value. (e) I favor removing the ID. It's not value add for most (heck, not value add for anyone). Bots should be consuming Wikidata and human readers don't care about anything except the website of interest. --Izno (talk) 22:57, 15 December 2018 (UTC)
• Premature but this is definitely something that should happen sooner rather than later. Wikipedia articles currently have an extremely awkward mix of ways of linking to sister WikiProjects and other websites and databases, some of which display on mobile and some of which don't. We need a standardised way, especially for mobile users, to make sure that these links are displayed in a coherent way and easily understandable. Blythwood (talk) 06:48, 2 January 2019 (UTC)

Discussion (authority control)

• Notifying Nikkimaria, Izno, Fram, Deryck Chan, KokoPhantom, Littleolive oil and Pigsonthewing, who commented on Template talk:Authority control and gave feedback while I was drafting this RfC. Jc86035 (talk) 09:26, 7 December 2018 (UTC)

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)

Note that the issue of using MusicBrainz IDs in this template has already been discussed, recently, where there was no consensus to cease using them. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:05, 14 December 2018 (UTC)

• Delete the authority control template. We don't need it, as we now have Wikidata, and if WMF adopts Curlie (former DMOZ), then we won't even need external links sections anymore. Kamafa Delgato _(Lojbanist)^{Styrofoam is not made from kittens.} 18:01, 15 December 2018 (UTC)
• Comment I think that, at a minimum, it would be good to widen the authority control template's role to link to relevant entries on respectable, respected sources and directories. An obvious one is the Oxford Dictionary of National Biography ID, for instance. You can cite this in the sources for an article, of course, but this makes it much harder to find. The authority control template is very useful for research and not well-known enough. Many new articles I review, even ones from experienced contributors, don't have it when it would be a benefit. Blythwood (talk) 00:07, 2 January 2019 (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)

Background

• 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: [12], [13]. 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)

Another part of that is a specious point for WP purposes, because we would never write "the savannah was gorgeous" in reference to a cat (even aside from emotive wording – I mean that we'd use a clearer construction, like "savannah cat"). The "it's necessary for disambiguation" argument completely failed in the WP:BIRDCON RfC, remember. A chief argument in favor of things like "Little Crow" was "If we use 'little crow' people will think we mean any crow that is small", and no one bought this argument, because obviously we'd simply write sensibly: "One crow species, the little crow (Corvus bennetti) is ...". Also, made-up breed names are not magically special. Every name for everything is made up, by someone at some point, yet that are not all proper nouns. E.g., we do not capitalize "carbine rifle" or "surfactant" or "durometer" or "exoplanet". The fact that people reading cat articles here are statistically more likely to be interested in cats and in turn more likely to expect capitalized cat breeds is meaningless; that argument could be used to push every strange style ever encountered in specialist writing, and push it harder the more obsessive the expert/fan base is; it would be a recipe for constant non-stop conflict, and for capitalization of virtually everything subject to any kind of literature of its own (dance steps, surfing and skating moves, videogaming terms, you name it).  — SMcCandlish ☏ ¢ 😼  18:14, 20 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., [14].
  • 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 exception.  — 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)

  That's a slippery slope argument about a slope that isn't slippery. We know it's not because this didn't happen after the species de-capitalization. Indeed, it's the making of topical exceptions which leads to more endless arguments (for more exceptions). If the readership don't care, and only some breeds-focused editors do care, then there's actually little potential for drama in going lower-case. I know I sound like I'm advocating lower case when I'm supposed to be neutral, but this just seems like a weak argument to me, bordering on 180 degrees reversed.  — SMcCandlish ☏ ¢ 😼  18:30, 20 December 2018 (UTC)

• Support per WP:NOTLAW and WP:CREEP. Andrew D. (talk) 09:38, 18 December 2018 (UTC)
  • Technically, this option is the one on the CREEP side, since it involves codifying a special exception – that some people will not understand or remember – to a general rule. The anti-CREEP option is "do not capitalize terms for groups of animals, period."  — SMcCandlish ☏ ¢ 😼  18:01, 20 December 2018 (UTC)
• Oppose. It would frankly be embarrassing to make a rule requiring capitalization for every breed when there is no reputable, general-subject manual of style that does so, and universal prescription in dictionaries that many if not most breeds be lower cased. As discussed below, I support a general rule to lower case (except proper nouns) with exceptions for specific breeds when there is dictionary support to capitalize. But, barring that, I would rather have no general rule and just an instruction to do what any reputable dictionary supports than a rule requiring capitalization. --Bsherr (talk) 19:15, 20 December 2018 (UTC)
• Support for formal breeds with a documented breed standard. They're like models of cars in that they're a brand name of sorts, one that indicates it's specific category while at the same time not designating a specific individual. oknazevad (talk) 12:19, 23 December 2018 (UTC)
  • @Oknazevad: could you clarify what you mean by a "documented breed standard"? It's largely the ambiguity over this with the consequent opportunity for edit-warring over what does and does not count as a "documented breed standard" that deters me from supporting the proposal, although I'm often on the side of more capitalization. Peter coxhead (talk) 12:29, 23 December 2018 (UTC)
    • I mean that the breed has a published breed standard from a organizing body such as the AKC, UKC, CFA, TICA, and so forth. Now that may be easier to do for some animals, like dogs which have well-established governing bodies, and there's bound to be discussion about whether a particular organization is reputable, but those discussions already exist to a certain extent in deciding whether a breed even gets an article. But the publication of such a standard is itself the formalization as a brand or model that is a proper noun. oknazevad (talk) 12:39, 23 December 2018 (UTC)
• Support per Oknazevad's logic, and per other points in the discussion. Randy Kryn (talk) 13:02, 23 December 2018 (UTC)
• Support both "standardized" breeds and landrace breeds. Not all animal breeds or nations have "standardized" protocols, nor is one nation's standards the same as another, so trying to split out which is which would be a nightmare. Montanabw^(talk) 22:28, 26 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)
• Support: Sources are mixed and Wikipedia's style generally tends toward less capitalization. It seems strange to put species in lower case, but then capitalize the lower rank of breed. That being said, I acknowledge the status quo and don't feel like fighting about it. If we do change to lower case, I'd be happy to help clean things up.  SchreiberBike | ⌨  00:07, 15 December 2018 (UTC)
  • Breeds aren't actually taxonomic ranks, but their plant equivalent, cultivars, are in fact capitalized (by standardized convention, in ICNCP). But since breeds aren't actually ranks, this may be irrelevant. I covered both sides of this argument in WP:BREEDCAPS. The gist is that it's not weird to capitalize below species, since botany does it programmatically, but they're doing it for a formal-code reason that's not applicable here. And other for/against arguments outlined there also apply more clearly to standardized breeds.  — SMcCandlish ☏ ¢ 😼  10:08, 20 December 2018 (UTC)
• Support. I thank SMcCandlish for his thorough analysis. I agree the The Chicago Manual of Style's §8.128 is rather confused in its examples, but it also prescribes normal proper and common noun capitalization rules. The two examples SMcCandlish calls out from CMS, Rhode Island Red and Maine coon (lower case in CMS) are both capitalized by Oxford dictionary.[15][16] However, MLA, not mentioned yet, is more clear in insisting on lower case, and criticizing those that capitalize, although it also acknowledges that "other breed names are capitalized according to convention and for clarity". But I ultimately think the dictionary results on "German shepherd" highlighted by SMcCandlish are the most damning. Not one capitalizes both words. Then there's the matter of consistency with species names. Bottom line to me is we should lower case (except for proper nouns) unless a reputable dictionary indicates otherwise, and then treat it as we do other spelling variants (keep consistent within article, but otherwise do not change). --Bsherr (talk) 19:03, 20 December 2018 (UTC)
  • Well, the partial counter-evidence was that various non-specialist, non-dictionary sources (e.g. news articles) do capitalize them fairly frequently (then again, this doesn't address the "default to lower case when sources are mixed" point by Jayron32, et al., higher up this section). It's just one of those judgement-call things. Do we risk more strife in permitting an exception for breeds, which is apt to inspire more demands for exceptions and which irritates some readers and editors, or by not permitting it, which is apt to irritate breeds-focused editors and also some readers, and which requires more care in writing? We'll always have a consistency issue either way, because probably around 75% of breed names will be capitalized anyway for containing proper names or adjectives derived from them (Hungarian, Nicastrese, etc.). Is it worse to have "a cross between the Nicastrese, pygmy, Russian white, and Norwegian goat breeds" or "a hybrid between the domestic Russian White goat breed and its wild relative, the kri-kri (a subspecies of ibex)"?  — SMcCandlish ☏ ¢ 😼  18:14, 21 December 2018 (UTC)
    • Between news articles and dictionaries, I'd think we'd go with the dictionaries. There's a difference between a source that merely encounters the issue and one that has likely considered it. To me, capitalizing breed names containing proper names isn't a consistency issue, it's consistency. Thus, as to your last example, the latter, oh the latter, is much worse. Finally, in the words of Sherlock Holmes: "I never make exceptions. An exception disproves the rule." --Bsherr (talk) 04:02, 26 December 2018 (UTC)
• Support I started out with a bias towards capitalization. (Disclosure: I supported allowing the capitalization of the English names of species, and would support it again if it became an issue.) However, I've seen no arguments that convince me that breed names are different from the English names of species, and that issue has been decided. No-one has produced a clear definition of what constitutes a breed name, and some supporters of capitalization want to take a very wide view, including landraces, for example. If we were going to recommend sentences like "a bald eagle has been recorded as having killed a Rough Collie" or "the animals portrayed included a Red Setter and a red cardinal", there should be a very convincing case, and there just isn't. Peter coxhead (talk) 09:52, 31 December 2018 (UTC)
• Support lowercase for general consistency with the WP:BIRDCAPS decision. --Izno (talk) 05:03, 13 January 2019 (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)

  Update: As of this writing, I see that the capitalization is more popular, among regular editors of breed articles, and people who frequently criticize MoS (two very different kinds of vested interest), but most of their rationales are fallacious. The few (so far) comments in favor of lower-case have no such problems, and are firmly grounded in policy and precedent. It's also not clear that we can even establish what "standardized breed" means in a clear enough way to make the capitalization case viable.  — SMcCandlish ☏ ¢ 😼  18:37, 20 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. [17] 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)

• Neutral General comment, no skin in this game: The rationales concerning what is capitalised remain elusive to me, the name of One-horse Town is never queried because it indicates a title recognised by a government or has some … what, 'cultural' value? English texts have slowly moved away from capitals, and that has been generally adopted as an improvement and way of avoiding the select use of them (eg. libraries rigidly using sentence case for book titles), but wikipedia should play no part in changes to current styles in english English; the solution is to skirt suppressing or encouraging a trend away from capitalisation. Or go the whole hog and suppress its in any and every name to avoid the implicit pov. cygnis insignis 07:45, 13 January 2019 (UTC)

Above, the Ngram is given supporting "German Shepherd" over "german shepherd", but this is not the correct comparison, since "German" is always capitalized anyway. The most popular is the mixed "German shepherd". [18]. For an example of a common breed where this confusion isn't happening, "fox terrier" beats "Fox Terrier" and "toy poodle" beats "Toy Poodle". On the other hand, "Chow Chow" beats "chow chow". A hard and fast rule overruling WP:COMMONNAME may not be best solution here, just go with the common name instead? Fram (talk) 08:01, 18 December 2018 (UTC)

COMMONNAME is not a style policy and has nothing to do with capitalization; never has. Even if that were to change, it would be completely unworkable, since it would result in breed A (a common and popular breed) being lowercase because it commonly shows up in non-breeder sources and in lower-case, but breed B (an obscure one) being uppercase for no reason other than it not being mentioned except in breeder-oriented publications, which always capitalize. Imagine the chaos. "Johnson has four dogs: a dachshund, a Hygenhund, a golden retriever, and a Cantabrian Water Dog." No, an across-the-board decision is exactly what we need here (other than of course to continue to capitalize proper names like "New Zealand" in a breed name).  — SMcCandlish ☏ ¢ 😼  18:25, 20 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)

  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 [19]. 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 [20].  — 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 [update: it doesn't actually, just extremely basic description; see new note below]. 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); updated: 10:59, 20 December 2018 (UTC)

New note: On huntaway dogs, a more detailed page here (British) suggests some additional average traits, but specifically states "Huntaways are not recognised by kennel clubs as a 'true' breed, but as only working dogs". But then it also contradicts itself, with statements like "The Huntaway breed is about 100 years old." Digging around further, one finds that this is just a general class of sheepdogs from New Zealand; it is primarily a training regimen, not a breeding programme. However, the British club are clearly trying to develop a standardized breed, in England, from NZ dogs of this sort, and are basing these efforts on the standardisation of the Border Collie (a recognizable general landrace since the mid-19th c. after standardisation of the Smooth and Rough Collie breeds, but itself only standardized as a breed in the 20th c.). So, for now, huntaways are a mongrel dog type (albeit of insularly limited stock) raised and trained for a particular purpose, not a breed (i.e., it's like "police dog" and "draught horse"), but there's a British group trying to turn them into a breed, which no major kennel club yet recognizes, and (WP:NOT#CRYSTAL) maybe never will. Hat-tip to Cinderella157 for pointing out the "not recognised by kennel clubs" point). Even the recognition it has in the NZKC is as a working dog type which can be registered for dog trial competition (a training test), not as a breed.  — SMcCandlish ☏ ¢ 😼  17:37, 20 December 2018 (UTC)

Clarification - dogs winning trials are admitted to a register (stud book as I understand it). My reading re NZKC is that it is a "recognised" breed but without a "breed standard". Hence my point that maintenance of a studbook or breed register by a national association may be more definative of a breed than a "breed standard" in many or most situations. This is certainly true of livestock, cats and dogs but may not be true of breeds in others species, such as poultry. Regards, Cinderella157 (talk) 22:12, 20 December 2018 (UTC)

There's more than one reason to maintain a studbook, though, so we'd have to use clearer language. One is breed maintenance, another is the hopefully heritable performance traits of a specific award-winning animal. Both are also done in horse breeding and various other spheres. There are studbooks for the continuity of a specific horse breeds, and for the (often very high-priced) privilege of siring new foals from a consistent race-winner. I'd be willing to grant benefit of the doubt to [h|H]untaway, since NZKC doesn't have a separate section for breeds and non-breeds, and the UK group is trying to establish a standardized breed, but it's an iffy case and this borders on original research (specifically, making WP:AEIS decisions based on nothing but personal interpretation of a primary source). If all that's at stake is whether to capitalize the name or not, it's not a big deal, but the article should not claim this is actually a breed without more evidence. What we have so far is classification of them as working dogs permitted for competition in training, not conformation, shows; and a different group on the other side of the world from where the dogs originated who are attempting to establish a breed but admitting that no major organizations accept it as one yet, which is rather damning on the breed question from an encyclopedic perspective. Especially so if one considers the nature and history of British (and American, and Canadian, and – going in the reverse geographical direction – Australian and New Zealander) breed establishment efforts: they frequently use extremely limited foundation stock, sometimes cross-bred, and produce something markedly different from the local population from which [most of] that stock was taken.  — SMcCandlish ☏ ¢ 😼  12:18, 23 December 2018 (UTC)

The length and detail of this discussion simply confirms my view that there's no clear definition available as yet of what would count as a standardized breed for the purposes of capitalizing, so adopting this proposal would be a recipe for confusion and edit-warring. Peter coxhead (talk) 12:36, 23 December 2018 (UTC)

• My take is that this was an itch that didn't need to be scratched. My take is trying to eliminate capitalization of breed names is going to lead to endless editing wars. Assorted style guides intended for general audiences will always be a problem where there is technical language, and specialist style does, in fact, actually have a place. Montanabw^(talk) 22:42, 26 December 2018 (UTC)
  • Well, aside from the question being indefinitely open having the effect of keeping MOS:ORGANISMS in perpetual draft state, the last time we had an "unofficial maybe-exception" anywhere near this sphere, it led to the worst WP:DRAMA outbreak I've ever seen on WP aside from crazily heated topic areas like Israel–Palestine. If we're to make an exception to MOS:LIFE it should be codified (and within bounds pretty much everyone will accept, namely the de facto ones we already mostly use). Otherwise someone will eventually just undo it. The WP:BIRDCON "RfC of doom" happened because someone opened a WP:RM about one bird article, and the RM closed in favor of lower-case, not finding any rule that would say otherwise, and finding that usage in RS was mixed. Exactly the same scenario. The WP:MR that followed that didn't find any fault with the RM's consensus assessment and closure, so the RM was endorsed. No MoS people were involved at all at that point. Someone from WP:BIRDS immediately opened a third discussion about it, at WT:MOS, I put an RfC tag on it to draw in more eyes and brains and get a better consensus record, and a month later we decapitalized all the vernacular names of species, and various editors quit in a huff. Having three consensus debates about it back-to-back put everyone on edge, digging trenches, and even resorting to meat puppetry in one case. It turned into a WP:WINNING contest. I don't want to see anything like that happen again. We should just decide there is an upper-casing exception or there isn't one, and write it down clearly, either way. Not leave a presumptive exception that's not specified and which anyone can challenge as illusory. The only thing in favor of caps right now, on the policy-arguments side, is that MOS:LIFE doesn't specifically mention breeds in its list of examples of not capitalizing groups of animals (which isn't much in the face of a general rule to not capitalize groups of animals, and another general rule to use lower-case when sources' usage is mixed).  — SMcCandlish ☏ ¢ 😼  07:39, 31 December 2018 (UTC)
  • @Montanabw: where there is technical language ... specialist style does, in fact, actually have a place – I agree with my reformulation of your point, but the crucial issue is what is, and is not, "technical language". As an example, the MoS is clear that the scientific names of organisms should be written in the style required by specialist sources (e.g. capitalized down to the level of genus). Scientific names are clearly technical language, and reliable generalist sources accept this. There are other clear examples, e.g. how SI units should be written.
    Having started out with a relatively open mind (actually with a bias towards capitalization), I have become convinced that this argument does not apply to breeds. No-one can produce a clear, workable definition of what constitutes a breed; there is no convincing evidence that reliable generalist sources consistently treat the naming of breeds as technical language. I hesitate to keep referring to one particular publication, but the National Geographic is very relevant, I think: it's somewhat specialized, but not overly so. It treats the scientific names of organisms as technical language, but not the names of breeds. On the basis of the discussion to date, and given the previous rejection of arguments for capitalization in the case of the English names of species, I conclude we should not capitalize breed names. Peter coxhead (talk) 09:38, 31 December 2018 (UTC)

RFC on capitalization of prepositions

Should we change the wording at MOS:CT to explicitly allow capitalization of prepositions containing four letters? Calidum 12:56, 23 December 2018 (UTC)

• Support change. Currently, the MOS states "prepositions containing four letters or fewer (as, in, of, on, to, for, from, into, like, over, with, upon, etc.); but see above for instances where these words are not used as prepositions," should not be capitalized. However, multiple move requests in recent years have been decided decisively in favor of capping four-letter prepositions, because our policy on article titles requires the use of commonly recognizable names, and four-letter prepositions are commonly capped in the real world. See past move requests concerning Star Trek Into Darkness, Spider-Man: Far From Home, Girls Like You and Hurts Like Heaven for examples. Note, I am not suggesting we require four-letter prepositions be capped in all instances, merely that the MOS be silent on the matter per WP:COMMONNAME and WP:CREEP, to avoid having repeated RMs on the matter. Calidum 12:56, 23 December 2018 (UTC)
  • @Calidum: could you please clarify exactly what new wording you are proposing? Is it just changing "four" in the existing wording to "three" (and then fixing the examples)? Peter coxhead (talk) 10:19, 24 December 2018 (UTC)
    • @Peter coxhead: that would probably be the easiest way to do it. Alternatively, we could add a third bold heading along the lines of may/may not be capitalized depending on common usage and include only four-letter prepositions in there. Calidum 13:39, 24 December 2018 (UTC)
      • @Calidum: these aren't quite the same; there needs to be a clear and precise proposal if there is to be a clear and precise decision. Peter coxhead (talk) 20:08, 24 December 2018 (UTC)
        • My preference would be to determine capitalization on a case-by-case basis instead of having a strict rule, per CREEP. So, to clarify, I would propose including “Four-letter prepositions may be capitalized depending on usage in independent, reliable sources” in the MOS. Calidum 16:42, 27 December 2018 (UTC)
  • This is basically a proposal to invalidate WP:CONSISTENCY policy. And "to avoid having repeated RMs on the matter"? That's backwards. This proposal would guarantee constant RM re-litigation of long-settled article titles. It is not possible for it to work any other way. The fact that we have a tiny handful of exceptions to an MoS rule is not a "problem"; it's implicit in what guideline means here, in contrast to a policy. To quote from WP:P&G: "guidelines ... are best treated with common sense, and occasional exceptions may apply." MoS itself re-iterates this. Opening thousands of RM discussions to try to do original research to prove "from" or "From" on a case-by-case basis by doing iffy statistical analyses on source usage of every title with that word in it would basically just be lighting editorial productivity on fire to watch it burn. I've addressed the other problems with this (misrepresenting RM results, trying to convert WP:UCRN into a style policy, etc.) in other comments below.  — SMcCandlish ☏ ¢ 😼  14:22, 28 December 2018 (UTC)
• Support - I generally feel that MOS has a range of bonkers views on capitalisation that clashes with general usage, of which this is one subset. We almost always go for "most popular (unique) name" for titling, so this seems a logical change. There doesn't seem to be an actual substantive (in the sense of improving user functionality) on the other side. Nosebagbear (talk) 10:00, 24 December 2018 (UTC)
• Support - We should always use the common name, and it the common name is capitalised then so should the article name be. FOARP (talk) 10:47, 24 December 2018 (UTC)
• Support as per Calidum's rationale. The Drover's Wife (talk) 11:20, 24 December 2018 (UTC)
• Support per the nom and all of the above. This would solve the odd-looking article of Stephen King's Four Past Midnight - Four past Midnight - which has been a point of contention regarding this topic. Randy Kryn (talk) 11:43, 24 December 2018 (UTC)
• Support, with one important caveat... when determining commonname based style, we must always base it on usage in reliable independent sources. Blueboar (talk) 14:04, 24 December 2018 (UTC)
  • Agreed, though this is already spelled out at WP:COMMONNAME. Calidum 14:28, 24 December 2018 (UTC)
• Strong oppose changing the status quo for 19–34 prepositions without good reason for each of them. We need more than an "example" for three prepositions that are the most controversial. Listed below are all four-letter prepositions in the English language with examples of enwiki articles, according to Wiktionary, without those present in zero articles. The rare ones that I didn't bother to check because of too large number of occurences are strike-through'd. wumbolo ^^^ 15:57, 27 December 2018 (UTC)

Click "show" on the right to open.
ajax amid anti bout came come down from gain gone half hoff into less like near onto (maybe not) outa over pace past plus post sans save than thro thru till unto upon vice vpon with

• • Your concern is noted, but I’m not proposing a hard and fast rule for all prepositions. Rather, I’m proposing to eliminate a hard and fast rule and allow flexibility. Calidum 16:42, 27 December 2018 (UTC)
    • Should we change the wording at MOS:CT to implicitly allow capitalization of prepositions containing four letters? — Preceding unsigned comment added by Jacknstock (talk • contribs)
• Oppose in favour of the proposal below. Peter coxhead (talk) 08:35, 29 December 2018 (UTC)
• Oppose in favor of the alternative proposal below. The nominator's premise is quite false; the vast majority of such RMs have done exactly the opposite of what Calidum suggests, and have instead followed MOS:5LETTERRULE, as expected. We do have a handful of RMs that have gone against 5LETTERULE (which is okay, since it's a guideline not a policy). Most have been bloc votes by fans of the works in question to favored four-letter-preposition capitals, to mimic the cover of the work; these are results that conflict with WP:CONSISTENCY policy and which are probably temporary and would be erased in later RMs (though see alternative proposal). In a few cases, there are genuine exceptions for special WP:IAR-worthy reasons, as in Star Trek Into Darkness, where "Into" is serving simultaneously as the beginning of a subtitle and as a mid-phrase preposition, a play on words. The above proposal would impose a style found in almost zero style guides other than those for news journalism (and WP:NOT#NEWS policy is clear that WP is not written in news style). The alternative, selective, and sourcing-based proposal below does not have this problem, and is consistent with how we already settle matters where RS, for a particular subject (e.g. a specific work), are at odds with the MoS default. Nor will the alternative lead to an explosion of RM relitigation of thousands of titles of our articles on published works with any four-letter preposition in their names.  — SMcCandlish ☏ ¢ 😼  19:24, 27 December 2018 (UTC); revised: 14:22, 28 December 2018 (UTC)
• Oppose. The reason we have this nightmare is that we have a length rule for prepositions in the first place. The Chicago Manual of Style's rule is that prepositions that are used adverbially or adjectivally are capitalized, all others uncapitalized. Only a grammatical rule will solve this problem. Adjusting the number of letters is arbitrary. --Bsherr (talk) 19:59, 27 December 2018 (UTC)

  CMoS uses "academic style". That is, all prepositions – even huge ones like "alongside" and "throughout" – are not capitalized "when used as prepositions" if you want to put it that way. This is the style used in many academic journals; it's virtually never used outside of them. Far more editors would object to it than to shifting from the five-letter rule we adopted from mainstream book publishing, to either the compromise proposal below, based on source usage for particular topics, or another arbitrary rule like the four-letter rule used by many news publishers. Then again, our extant "just use the five-letter rule" position is WP:NOTBROKEN in any way, it's simply not the personal preference of a handful of editors who don't seem to read anything other than entertainment news. I.e., they don't appear to frequently encounter or notice titles of much other than pop-culture stuff like Four Past [sic] Midnight and "Do It Like [sic] a Dude" (and some of them even want it to be "Do It Like A Dude" to mimic the single cover). If they read more broadly they would know that most publishers do not capitalize that way, but they never seem willing to absorb this fact. De-capitalizing every preposition will simply make them lose their minds and go to war about it perpetually until the end of F'ing time.  — SMcCandlish ☏ ¢ 😼  20:40, 27 December 2018 (UTC)

  Our rules already permit capitalization of short prepositions if they are used in a verb phrase, which is often the same as used adverbially. So that's good. I'm generally concerned about deferring to "common usage" on style matters, because it turns every copy edit into a poll, and while I see the value in compromising contested decisions that way, I don't know how one can efficiently make everyday editing decisions without a talk page discussion on every capital letter. I have to think about this. --Bsherr (talk) 22:46, 27 December 2018 (UTC)

  In more precise wording, a word that is sometimes a preposition is not a preposition when used as a particle in a phrasal verb or as an adverb. It's the same issue as the "preposition when [not] used as a preposition" wording above. Not understanding that a word can serve multiple grammatical functions and isn't one function masquerading as another (a linguistic impossibility) is much of why typical RM respondents have difficulty understanding how to apply MOS:5LETTERRULE.

  Anyway, this common-usage fallacy is problematic for the very reason you point out (and thus contrary to WP:CONSISTENCY policy). It's mistaking WP:COMMONNAME for a style policy, when it says nothing about style, has never been interpreted as a style policy except by editors who wish it were one (including the opener of this RfC). WP:AT and the naming conventions guidelines defer to MoS on style matters in at least a dozen places, and RM decisions are made every single day based on application of MoS. Every attempt to elevate any style matter to the policy level has been met with stern opposition by the majority of the community, so "basement conversion" of AT into a style policy while no one is looking would never be accepted. The entire CONSISTENCY policy, for one thing, would be nullified, because every single article title on WP would be re-styled to match the stylization preferred in a bare majority of the RS identified for it at any given time. This would also thwart WP:AT's central purpose, which is title stability; people would continually be cherry-picking different sources to try to re-style the titles of thousands of articles, and whoever that week had more patience for digging up sources that preferred their stylization for this topic or that would WP:WIN that week. I'm hard pressed to think of a more disruptive and editorial-productivity-wasting alley to wander down. And it would spawn an entire class of "style warrior" editors who did little constructive on WP but devoted all of their time to picking subjective style fights. We already have too many of those (about half a dozen, not counting the ones already topic-banned or indeffed).
   — SMcCandlish ☏ ¢ 😼  13:36, 28 December 2018 (UTC)

• Too vague – I get that there's some sentiment to "allow capitalization of prepositions containing four letters". But where's the guidance in this? Does every four-letter preposition now generate an RM discussion to see how many editors want to change it, or should we rely on some consensus guideline, as we usually do, to make most cases uncontroversial? The handful of exceptions we have seen should be carefully considered, and a guideline that captures the logic behind them should be formulated. I think that's what SMcCandlish is trying to do below, so let's study and see if we can accept or improve that instead of jumping on the vague one. Just saying let's let sources vote (through editors) is certain to give rise to uncountable numbers of preposition debates. Our typical strategy is to articulate a preferred style (e.g. as we have done with lowercasing four-letter prepositions) and then articulation a rather tight rule for exceptions, such as when sources consistently or overwhelming avoid doing it as our style would suggest. Then hopefully most prepositions won't need to be discussed. Dicklyon (talk) 00:34, 28 December 2018 (UTC)
• Oppose—per Dicklyon. Tony (talk) 01:31, 28 December 2018 (UTC)
• Oppose as this would mean "from" would be capitalised, which is not current usage. Graeme Bartlett (talk) 01:48, 28 December 2018 (UTC)
• Oppose very strongly (and in preference to the below). Making it too vague as in here would create more disputes not less (every instance of a four letter preposition in a title would be allowed to be litigated), while more explicit guidance for an exception as in below would only allow disputes in narrow cases. Galobtter (pingó mió) 05:16, 28 December 2018 (UTC)
• Oppose as contrary to English usage. What advertisers and Hollywood flacks do is of no concern. Hawkeye7 (discuss) 05:25, 28 December 2018 (UTC)
• Oppose – We are under no obligation to replicate corporate abuse of the English language, or other forms of puffery. The proposed change is asking for trouble, is vague, runs contrary to the principles of this project, and compromises the integrity of our MoS. On the other hand, I find Mr McCandlish's proposal quite sensible. RGloucester — ☎ 06:03, 28 December 2018 (UTC)
• Oppose per SMcCandlish et al. · · · Peter Southwood ^(talk): 15:42, 2 January 2019 (UTC)

Alternative proposal: selective capitalization

I was coincidentally already drafting this and running it by some MoS and AT regulars:

• Apply our five-letter rule except when the vast majority of RS capitalize a significant majority of current, reliable sources that are independent of the subject consistently capitalize, in the title of a specific work, a word that is frequently not a preposition, as in "Like" and "Past". Continue to lower-case common four-letter (or shorter) prepositions like "into" and "from".

The consequences of this, both pro and con:

1. MOS:TITLES would need an edit to integrate this exception.
2. We would have less WP:CONSISTENCY between article titles.
3. Titles of particular works would be rendered in a style that matched more sources about those works. However, this would almost always apply only to pop-culture topics – the entire source of capitalization of prepositions like "past" and "like" in titles of works is entertainment journalism, mimicking the "marketing capitals" on the album covers and movie posters; the same works' titles as rendered in academic journals will still use "past" and "like").
4. We will not throw out the baby with the bathwater, as the original proposal does. That proposal would force the minority and fandom-based preference for "Into" and "From" over the lower-case preference of the majority of editors here, and of the majority of real-world professional writers, and of most style guides, and of the majority of RS about particular works which are not recent pop-culture product.
5. We lose one distinction: "like" or "past" versus "Like" or "Past" in a title clearly indicated that the lower-case versions are prepositions and the upper-case ones are not ("Like" would generally be a verb, and "Past" either a noun or adjective, depending on construction). Hopefully context will make it clear which is which.

The original proposal would simply guarantee continual dispute about this rather arbitrary bit of style trivia for the foreseeable future. This alternative proposal's basis is that it's better to end the dispute with a sourcing-based compromise about a certain subset of words, in specific titles where the sourcing backs a variance from the default rule.
 — SMcCandlish ☏ ¢ 😼  19:24, 27 December 2018 (UTC); point 5 added: 13:46, 28 December 2018 (UTC); wording revised to address issue raised below: 01:04, 29 December 2018 (UTC)

• Support, as the kind of compromise that's already compatible with MoS's "vary from what MoS's default is when the sourcing consistently does so for a particular case" approach.  — SMcCandlish ☏ ¢ 😼  19:24, 27 December 2018 (UTC)
• Support—seems the best way. Tony (talk) 01:28, 28 December 2018 (UTC)
• Support as solving quite a few RM disputes, with I believe "like" to be the single-most disputed word. Still leaves cases like Spider-Man: Far From Home, but those are rarer. Galobtter (pingó mió) 05:16, 28 December 2018 (UTC)
• Support in principle, but it might be nice to not exclude the "Into Darkness" thing. Dicklyon (talk) 06:01, 28 December 2018 (UTC)
  • That one's already covered by a footnote at MOS:TITLES, as a special case. It doesn't apply to Spider-Man: Far from Home, which has simply been over-capitalized with "From".  — SMcCandlish ☏ ¢ 😼  13:17, 28 December 2018 (UTC)
• Support – As above. RGloucester — ☎ 06:03, 28 December 2018 (UTC)
• Support, yes, this seems to be the best way forward, and the most likely to avoid prolonged disputes (although clearly nothing will ever appease a determined minority). Peter coxhead (talk) 13:31, 28 December 2018 (UTC)
• Almost Support but the word vast should be changed to large. Vast means very large, like an elephant compared to a mouse, while large still gives room for consensus to form. Spider-Man: Far From Home is probably the one well-known example that would stand out most (as long as the Four Past Midnight short story collection is finally given its correct title, what an incorrect way to use the term 'consistency' - for in fact there are no sources which lower-case it yet still some editors have claimed it should be lower-cased). The unreleased Spider-Man film's title still must stand the test of after-release sources, but using "vast" in any new RM will give a likely-to-be-ignored, thus misuse, of this wording. Randy Kryn (talk) 14:06, 28 December 2018 (UTC)
  • My original wording above was "pseudocode" of sorts, a statement of the general principle. I hadn't word-smithed it into guideline language yet. I've injected a revision to make it more like the wording MoS already has about when to make exceptions (it's especially important to be compatible with the wording at MOS:TM, since both guidelines are going to apply simultaneously to any major pop-culture work, e.g. a superhero or sci-fi franchise movie; we can't have two guidelines contradicting each other about the same subject). [Pinging previous commenters who commented between the original and the revision, in case the revision doesn't suit their views: @Tony1, Galobtter, Dicklyon, RGloucester, Peter coxhead, and Randy Kryn:.] Re tying this to specific titles like Four Past Midnight and Spiker-Man: Far From Home: I do not accept that condition. Under the current MOS:5LETTERRULE, the Spider-Man RM's closure in favor of "From" was a mistake, a violation of WP:CONSISTENCY policy, and I have absolutely no doubt that it would be overturned in a later RM (because we've been over this before, e.g. with "Do It like a Dude" and many other cases; when a fannish bloc vote is absent or weak, the RM always goes in favor of what the guideline says). However, the entire point of this alternative proposal is actually to permit variances like that, simply to avoid repeated, time-sucking editorial dispute over trivia that no one really cares about. The idea that there's any kind of WP:RECOGNIZABILITY problem is of course absurd, and some would prefer "like" across the board, and some would prefer all four-letter prepositions capitalized. This is a reasonable compromise to end some strife we don't need to pursue. That said, I refuse to tie it to any specific article title and the community's ultimate consensus about that one work; that would just be petty and subjective, and I will not go there. It would be especially silly in this case, because the Spider-Man film's title may well change by the time it is released, and it may never be released.  — SMcCandlish ☏ ¢ 😼  14:48, 28 December 2018 (UTC)

I would suggest using the wording of MOS:CAPS: 'consistently capitalized in a substantial majority of independent, reliable sources'. RGloucester — ☎ 16:18, 28 December 2018 (UTC)

A good write-up and intent, and anything to eventually get rid of the Stephen King monstrosity (he'll probably write a 1,200 page novel about the RMs someday). I can't sign on to 'consistently' if it means always, as there are usually outlier sources who can keep a name lower-cased here just by the lack of long-time professional copy editors who may miss an incorrect name now and then (a friend who worked on the copy desk of a major newspaper for 30 years is now driving a cab after "cutbacks", i.e. "let's hire the recent high school graduate at a fifth of the salary", but I digress). Randy Kryn (talk) 17:50, 28 December 2018 (UTC)

I tweaked it again, to use the exact wording from MOS:TM, plus the word "current" (because we've had attempts to WP:GAME things like this with obsolete sources). It's the same meaning as the main MoS wording, though uses "significant" instead of "substantial". I don't think anyone's ever tried to argue for them to be interpreted differently. If they ever do, we can just edit them to all use the same word and nip that silliness in the bud.  — SMcCandlish ☏ ¢ 😼  01:04, 29 December 2018 (UTC)

• Comment: I fear that the proposal would not result in fewer discussions, just in different discussions: Is word X frequently not a preposition? Is source Y reliable? Is source Z independent?

Nevertheless, I think the proposed change is acceptable for "like" and "past", but what about other prepositions, e.g. "over"? It is frequently not a preposition (think of all the phrasal verbs: carry over, freeze over, hand over, pull over, take over etc.), and I'm sure there a many sources that capitalize "over" in titles like Bridge over Troubled Water or Bullets over Broadway. Should we thus capitalize "over" in these titles, but at the same time lowercase "into" and "from"? That doesn't make sense to me. Darkday (talk) 12:22, 31 December 2018 (UTC)

No proposal about this sort of thing will make sense to everyone in every situation and please all parties. What we really should do is probably stick to the simple five-letter rule, being a compromise that's served us well. However, it may be worth trying out this alternative compromise to see if it reduces dispute. It will not be possible to erase all dispute, only reduce or increase it.  — SMcCandlish ☏ ¢ 😼  18:36, 5 January 2019 (UTC)

Discussion: capitalization Of prepositions

Looking at one example of the rule being applied, searching "four past midnight" in "four+past+midnight" Google Scholar one finds that every academic source there has "Four Past Midnight" not "Four past Midnight", which would definitely point towards removing this as a rigid rule as one argument for it is that academic sources do lowercase things much more often; if nearly no sources whether in books, journalism, or academia use certain capitalization then that makes Wikipedia stick out and look strange. Galobtter (pingó mió) 12:13, 24 December 2018 (UTC)

I was unaware of the previous discussions concerning the King novel, but those discussions are a great example of the "But the MOS!" mentality some have that this RFC is attempting to address. Calidum 14:35, 24 December 2018 (UTC)

Self-promotion

Has anyone else received an email like this, which I found profoundly disturbing? What can be done about this?

From: Lauren <lauren@worldresearchernews.com>
Subject: Get Featured in Wikipedia

Have you ever wondered of having a Wikipedia page for yourself or your company? We can help you get a Wikipedia page for yourself or your brand.

Usually Wikipedia only accepts pages on celebrities and famous companies, if you are looking to get one for your self, we can help you with that. Having a page for yourself in Wikipedia, brings you more credibility and makes you more famous.

We have been editing on Wikipedia for 7+ years and We've created tons of pages for companies, people, brands, products, and of course for academic purposes as well.

We own multiple accounts on Wikipedia with page curation and new page reviewer rights, so i can create and moderate pages with almost zero risk of another mod taking it down.

There are few wikipedia editors who are willing to create a page for money, and most of them are scared to offer this service directly, so they do it through their trusted sellers who markup the price to $1500 - $2500 per page.

Because you're buying directly from an experienced wikipedia editor and mod, you'll get your page a lot cheaper, faster and with more reliability.

Let me know if you are interested
Regards
Emily

--Michael Goodyear ✐  ✉ 20:22, 4 January 2019 (UTC)

Reply to the email and ask for a portfolio of their past work. GMG^talk 20:46, 4 January 2019 (UTC)

Have done so. It is possibly a scam, but a little searching turns up a lot af advertisements offering Wiki pages for money. --Michael Goodyear ✐  ✉ 00:08, 5 January 2019 (UTC)

Michael Goodyear, it seems you're not the only one. https://pastebin.com/vZphqd4A Vexations (talk) 22:37, 4 January 2019 (UTC)

I'm sure I'm not! This would be a mass mailing to a harvested or purchased list of email addresses. --Michael Goodyear ✐  ✉ 00:08, 5 January 2019 (UTC)

OK here it is:

Thanks for your interest in our services. Our service fee for Wikipedia page creation is $999 per profile, and it will take around 4 weeks to complete.

Here is our recent work for Dr. Ayman Al-Hendy from the University of Illinois.

Let me know if you would like to proceed.

Regards Lauren.

--Michael Goodyear ✐  ✉ 23:16, 7 January 2019 (UTC)

Pretty lame article, too. Many citations, mostly neither establishing notability nor supporting the statements they're attached to. And the heading capitalization suggests an inexperienced editor. And it's a unique account for the one article, so that's a pattern to watch out for. Dicklyon (talk) 23:27, 7 January 2019 (UTC)

I would care very little about this. These articles probably will never gain too much attention, and even if they gain significant attention, they would be proposed as candidates for deletion in accordance with WP:NOTE. User:AnUnnamedUser (talk) —Preceding undated comment added 00:39, 8 January 2019 (UTC)

@Atlantic306: – Another editor who goes around polishing up reputations and removing notability tags from such articles is Atlantic306. Probably the experienced ring leader. Dicklyon (talk) 03:06, 8 January 2019 (UTC)

• • Absolute rubbish Atlantic306 (talk) 12:49, 8 January 2019 (UTC)

I don't have much admiration for A306 but that's a blatant unsubstantiated PA.∯WBG^converse 07:46, 8 January 2019 (UTC)

The "experienced ring leader" part was kidding. The point was just that he needs to be more careful about removing notability tags based just on number of cites. Dicklyon (talk) 23:02, 8 January 2019 (UTC)

• Comment: I've had an email from a similarly named account quite recently (I'm mindful of Oversight) so I don't want to put the full thing here. Mine's slightly different from Michael Goodyear's and Vexations' in that instead of advertising their services they tried to recruit me. I won't post the whole email here but if a functionary is interested, leave a message on my talk page and I'll send it over. Basically it was "I see you're an Articles For Creation reviewer, would you like a PayPal payment to accept some drafts?" Needless to say, I told them, in more diplomatic language, to get stuffed. If there's one thing I despise it's undisclosed paid editing, and anyone who knows my account history will know that I'm not exactly the bastion of morality myself. I'd also be willing to send this over to admins active at AFC, pinging Primefac to see if he's interested. I echo Winged Blades of Godric's comment, I don't always see eye-to-eye with Atlantic306 but to suggest he's an undisclosed paid editor without any proof whatsoever is tantamount to a personal attack and I would advise Dicklyon to withdraw it. Many thanks, SITH (talk) 20:27, 8 January 2019 (UTC)

  StraussInTheHouse, forward it to the functs; we don't "officially" handle these requests but if it's a case of UPE there might be a sock ring involved. Primefac (talk) 20:38, 8 January 2019 (UTC)

• Sent SITH (talk) 20:52, 8 January 2019 (UTC)

To be clear, Atlantic306 accepted this draft, that does not necessarily make this editor a paid contributor, since the article was the product of Nocturnal911. In this case, remedial action has been taken, and that contributor blocked. The real issue, is how widespread is the practice? And how can it be rooted out.--Michael Goodyear ✐  ✉ 22:56, 8 January 2019 (UTC)

If you look at where Atlantic306 removed the noteability tag, and look for other edits with similar summary, it doesn't look like a good behavior. He needs to be more discerning. Dicklyon (talk) 23:36, 8 January 2019 (UTC)

• • • Dicklyon (talk · contribs) you are wrong again as I have not removed a notability tag on that article, check the edit history. I commented on the notability on the talk page but that was nothing to do with a tag. On other articles I sometimes remove inappropriate tags which can be added by 4 year olds, as per WP:Overtagging and as for your joke ... Atlantic306 (talk) 22:32, 13 January 2019 (UTC)

Dicklyon, I agree with you, but it's best, even if you're joking, to avoid casting aspersions because that can get you on the wrong side of ArbCom. SITH (talk) 23:40, 8 January 2019 (UTC)

Please bear in mind that it is quite possible that the sender of the e-mail (or of anything similar) is not entirely honest, and had nothing to do with creating Ayman Al-Hendy, or any other article they claim to have created. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:23, 9 January 2019 (UTC)

Point well taken and we have seen examples of that before but in this case the article was created by a sock puppet who was subsequently blocked. --Michael Goodyear ✐  ✉ 22:58, 9 January 2019 (UTC)

Manually confirmed new users are prevented from creating articles

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

Treat surname pages like disambiguation pages?

There are several discussions about whether surname pages are disambiguation pages, and there is a lack of full consensus, although the question may be semantic in some regards. It's not a simple yes or no question.

Some of the issues are:

Should surname pages be included in Category:Disambiguation pages? As discussed below in the second question, if editors should not link to surname pages because they should disambiguate links, then it may be helpful to categorize them as dab pages so that the links to them can be flagged for repair WP:DPWL. The template {{surname}} apparently does not automatically include them as disambiguation pages, and the Talk page discussion seems to suggest they are not to be considered disambiguation pages. There is a {{Dmbox}} template Talk page discussion about whether bots are behaving correctly in how the classify surname pages (apparently they don't). A Village Pump discussion there touches upon whether the various language wikis handle the issue the same way (apparently they don't).

After some additional research I concluded that surname pages are actually Set Index Articles and not disambiguation pages. SIAs are article pages consisting of lists of things in the same category (such as people) with the same name. Disambiguation pages are non-article pages that link to article pages for the various meanings of a term, i.e., they are navigation aids. The template {{surname}} is a Set Index Article template for surnames and can be used to categorize surname pages. The {{surname}} usage notes provide additional guidance on how to classify disambiguation pages that include a list of people with a certain surname along with other entries. Coastside (talk) 04:49, 8 January 2019 (UTC)

Should surname pages follow policy guidelines for disambiguation pages? I think they should. For example, WP:DABPEOPLE and WP:DABRED provide important guidance. Some disambiguation pages include surname sections, in which case it is rather clear that they should conform to policy under WP:DAB. These pages are (or should) be categorized with the template {{Disambiguate:surname}}, which puts the page in Category:Disambiguation pages with surname-holder lists. In any case, there is a question of whether the policy guidelines for surname lists in disambiguation pages is the same as for surname pages along with guidance about surname language categories.

I found policy guidance on this point at WP:SIA. It says: "An SIA need not follow the formatting rules for disambiguation pages, although many SIAs do. Unlike disambiguation page guidelines, an SIA is allowed to contain red links to help editors create articles on notable entries." Applied to surname pages, this means it's ok to add entries for notable people regarless of WP:DABRED. Coastside (talk) 05:31, 8 January 2019 (UTC)

Can and should you ever link to surname pages? It is a general guideline that you should not to link to disambiguation pages for article pages, but if surname pages aren't disambiguation pages, then is it ok to link to them? I would argue that links to surname pages should be disambiguated when possible. As a matter of fact, it is helpful for these pages to appear as pages needing fixing such as WP:DPWL so that the links can be fixed. Then again, some surname pages are written as if they article pages about the name itself, in which case it might reasonable to link to them, for example Bernard. There is some relevant guidance about when to include people in lists of people under standalone-lists. This seems to apply to surname lists. Stand-alone lists are considered a type of article page, not disambiguation pages.

Again, after research, I determined that it is ok to link to surname pages. This is because they are article pages. They may be standalone-lists, or they may include content about the surname such as historical information. Regardless, wikilinks that are meant to point to an article about a specific individual should link to the article page and not the surname page.Coastside (talk) 05:01, 8 January 2019 (UTC)

Should you always use the "(surname)" qualifier in surname page titles? This has been asked and discussed, and I think it's rather clear that surname pages do not always need the qualifier. If there is no main article for the surname, you just use that and redirect from the qualified name to the main page. I just mention it here for completeness.

Another possibility is to use the article name List of people with surname 'name' for cases when the surname article already exists and there is reason to separate the list from the list page (such as because of length). For example there is a surname article page Jenkins (surname) as well as a list page List of people with surname Jenkins. Notably, both of these pages use the {{surname}} template.Coastside (talk) 05:22, 8 January 2019 (UTC)

I would suggest we create a page specific to defining how surname pages should be handled.

Well, seems I answered my own questions. :) Coastside (talk) 05:31, 8 January 2019 (UTC)

Coastside (talk) 00:57, 6 January 2019 (UTC)

• I have made a start at Wikipedia:Surname index articles. I note that WP:SURNAME redirects to the section of the style manual describing how articles on individuals should address those individuals in text. bd2412 T 15:49, 8 January 2019 (UTC)

Excellent! I will join the conversation in the talk page.

• Has anyone checked WikiProject Anthroponymy? WP:APODAB and WP:APOSURNAME have good guidance on this already. I tend to agree these behave more like set indices than straight disambiguation but there's no clear lines. Ivanvector (^Talk/_Edits) 15:59, 8 January 2019 (UTC)
  • I had not considered the WikiProject pages, but my aim is more to describe how these pages should be approached in terms of incoming links and distinguishing them from disambiguation pages. Elements of my draft could be worked into the Anthroponymy project page. bd2412 T 17:21, 8 January 2019 (UTC)

APODAB and APOSURNAME does not handle the things WP:MOSDAB do, namely, the format of lists List of people with surname Spencer, and people lists present in nearly all Surname (surname) pages. While "article-type" texts are controlled vy our WP:V, the lists are sometimes in random format, which IMO must have strict rules similar to MOSDAB. Staszek Lem (talk) 18:38, 11 January 2019 (UTC)

A question came across recently, while creating the bot Noref (to add {{unreferenced}} tags) is if Set Index Articles require references. It seems silly to me to require references. They are essentially dab pages, IMO, the requirement for references being the defining difference. -- GreenC 19:30, 11 January 2019 (UTC)

Set Index Articles are not required to have references, but they are allowed to have them. bd2412 T 04:36, 12 January 2019 (UTC)

Set index articles are subject to guidance for standalone list articles at WP:LISTVERIFY. If the surname SIA is only a list of persons with the name, I think merely meeting the inclusion criteria for the list would satisfy verifiability that the person has the surname. Redlinks might need to meet some additional criteria. I'm not sure a surname-equivalent of WP:DABMENTION would be enough -- I think redlinks would need to meet some sort of notability criteria -- else surname lists could turn into a phone book listing. And of course, any non-list content (such as name origin, meaning, distribution, etc.) needs to be verifiable and supported by reliable sources. I'd be wary of a bot performing this sort of assessment. older ≠ wiser 10:27, 12 January 2019 (UTC)

• I created a how-to guide on Surname pages which addresses these issues. It includes examples and links to the governing policy guidelines.Coastside (talk) 23:48, 12 January 2019 (UTC)

RfC announce: Commas in DYK

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

Church Names

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Columns in reflists

• Proposal: Make unwritten rule written.

First an option, now compulsory. Some people fancied columns and now no one is allowed to use the existing parameter. And I am accused of working against a 'consensus', also exceptionally bloody unpleasant. I disagree it is an improvement, and don't think I'm the only one who find them hard to read and naff, but if it is now compulsory the documentation and policy should outline that no one is allowed to continue using the single column function and they can be reverted to 3RR if they try. This should be VERY clearly stated in policy and documentation for the template. cygnis insignis 02:56, 8 January 2019 (UTC)

This is presumably about Template talk:Reflist#column default, where after much not-getting-it-ism, the OP was pointed to the means to set all columns to whatever width, or non-width, he pleases. --Izno (talk) 03:14, 8 January 2019 (UTC)

Izno, no, this is about stopping anyone else getting the same run around and being insulted for having a different view (not uncommon outside this place) and reverted to that preference. This is not the place for debate, or thug someone you disagree with. I'm asking that the pollicy and documentation reflect the result of consensus / fait accompli. cygnis insignis 03:51, 8 January 2019 (UTC)

Clarify that 'the means to change' is to change my own display, not use the existing parameter because apparently I am the only person who ever objected and not liking this is weird. It is shit design for digital documents, my opinion, it is very bad to have a unwritten rule that allows content creators to think they are contributing in an unobjectionable way and is distracted by yet another a claim by swaggering edit warriors that something undocumented at the template or MOS is compulsory. Clearly that needs to be documented, the unwritten rule be written, because I have better things to contribute than opposing what a clan of wikithugs staked out as their territory. I surrender, they won, change the documentation to stop giving ammo to the otherwise disinterested talk page goons who fight this out from article to article. cygnis insignis 07:06, 8 January 2019 (UTC)

Stub and CN on user pages

Are stub and citation needed tags allowed on user pages? RetroAsgardian (talk) 15:32, 8 January 2019 (UTC)

It depends... are you are talking about using these tags on a draft located in user space... or using them in some other way? Blueboar (talk) 16:01, 8 January 2019 (UTC)

@RetroAsgardian: I don't think so, as they add categories that user pages shouldn't be in. See WP:USERCAT, which says that User pages and user categories do not belong in mainspace categories such as Category:Living people or Category:Biologists, which are reserved for articles of the encyclopedia (in mainspace). This applies also to user subpages that are draft versions of articles. --DannyS712 (talk) 21:54, 9 January 2019 (UTC)

Stub categories aren't included on userspace pages; however, they should only be there on a page draft, not simply because they can. Same goes for the categories of {{Citation needed}}, which categorizes pages via {{fix}}, which in turn does it using {{Category handler}}'s "main" parameter. עוד מישהו Od Mishehu 12:27, 13 January 2019 (UTC)

• Yes, since people draft articles in userspace, and (for WP:CREEP reasons) well never have a list of templates "forbidden" in userspace. The fix is to install a namespace test in the template so it doesn't categorize non-articles into article categories.  — SMcCandlish ☏ ¢ 😼  19:31, 15 January 2019 (UTC)

No-indexing

The article Rahaf Mohammed al-Qunun was nominated for deletion almost as soon as it was created. It is thus no-indexed.

The fact that the AfD is overdue to be snow-closed aside, why is this well-written article on an important topic hidden from search engines?

Is it right that any article can be hidden - effectively irreversibly so, for several days - on the whim of a single editor? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 00:13, 10 January 2019 (UTC)

Yes, because the opposite is allowing articles that definitely should not be indexed in (which is tricky to undo). Better a temporary delay for positives, which has very minor negatives vs some major negatives that could come from the opposite. Additionally, multiple incorrect AfD nominations or incorrect patrolling will ultimately lead to the removal of the rights to do either. Nosebagbear (talk) 00:19, 10 January 2019 (UTC)

Yes. No-indexing CSDs and AFDs is appropriate. There is no rush to index good new articles, whereas there are strong reasons to avoid indexing the worst cases. Until an AFD is resolved, we aren't going to run down the rabbit hole of assertions that "article-X is an obvious_keep/obvious_delete" and "obviously_should_be_indexed/obviously_should_not_be_indexed". Alsee (talk) 09:13, 10 January 2019 (UTC)

Current NPP practice is to index AfD - it's going to be decided one way or another by the community and if someone finds something non-notable in the interim the big "this might be deleted" serves as a warning. Current practice is to not index PROD or CSD until that has been dealt with since those could be removed more easily. Best, Barkeep49 (talk) 23:09, 10 January 2019 (UTC)

I think Pigsonthewing is talking more about Template:Article for deletion/dated which automatically injects NOINDEX to the page than about whether we need to manually review the page or not. Same as what's being discussed at #NOINDEXing all nominated articles. –Ammarpad (talk) 05:52, 11 January 2019 (UTC)

Putting aside the question whether readers need to be protected from AFD-ed content (almost certainly not; most of the world knows that Wikipedia's content is of variable quality and the biggest problem - incorrect information - isn't helped by NOINDEXing at all) is it really a good idea to hide away articles that could be improved? Jo-Jo Eumerus (talk, contributions) 06:58, 11 January 2019 (UTC)

Yes. I'd encourage you to use your imagination here. Short-term no-indexing (which would last no more than 7 days) is really pretty irrelevant; it's either going to be in the encyclopedia or it isn't, and by "encyclopedia" I mean a resource that is designed to exist for the long term. Just think, ten years ago Google only sent its crawlers through about once a week. Now it is including pages less than an hour old in its results. It can be devastating to the article subject who really shouldn't have an article, and subjecting those article subjects to an additional week of agony is highly inappropriate and fundamentally unencyclopedic. Risker (talk) 19:57, 15 January 2019 (UTC)

Auto-confirmations

Auto-confirmations and extended confirmed should be tied to mainspace edits, not all edits.

Btw, I'm surprised this isn't perennial.

Benjamin (talk) 02:06, 13 January 2019 (UTC)

@Benjaminikuta: - two main reasons against this:

1) Almost all of auto-confirmed edits and a strong majority of EC edits will be in mainspace - making more than a small fraction of edits in other namespaces is usually something we see arise later on. Edits aren't the main barrier - so this somewhat risks being a solution in search of a problem

2) This proposal also is somewhat rude - it suggests that only mainspace edits are productive or at least contribute to knowing if an editor is sufficiently authentic to be trusted with wider access. I could understand ruling out the two user-spaces, but participating in the others can be just as beneficial. Nosebagbear (talk) 13:59, 13 January 2019 (UTC)

I agree with Nosebagbear. Just about any participation in a discussion anywhere other than the user's own talk page is likely to be productive (this includes some pages in the Wikipedia: namespace); as would participating in categories and templates which are used for the mainspace. עוד מישהו Od Mishehu 14:03, 13 January 2019 (UTC)

"Deletion" -> "Unpublish" and "Warning" -> "Final caution"

Moved to Wikipedia:Village pump (idea lab)

WP:MEDRS policy ?overemphasis on reviews

Hi. In my opinion there may be many medical experts in the short term future contributing to wikipedia. Several I know are reading our policies in detail as we speak. Medical experts now are only now starting to realise its importance. Wikipedia is not a place for medical reviews. However, as an expert, when we are reviewing we are repetitively taught to NOT to cite reviews, ever, rather primary sources. In Wikipedia, we need to give new studies their weight (please note I have never tried to cite my studies, only my review, which I consider should never be cited in medical literature - but it was, thats the point). But under WP:NPOV when making encyclopedic articles we should, in my opinion cite an important singular study, so the content is up to date. And then neutralise it with an expert opinion commenting it on its relevance, and experts that say it is irrelevant. I think that Wikimedia foundation may assist with the replication crisis in medicine in this regard. The reason I feel strongly about this is because experts such as myself find it hard to contribute, but are starting to realise that it may be more important than submitting to the New England Journal of Medicine sometimes. What do we think? E.3 (talk) 07:01, 18 January 2019 (UTC)

Re primary V secondary: If the explanation at WP:MEDRS isn't enough, see Wikipedia:No original research#Primary, secondary and tertiary sources. Wikipedia is based on reliable secondary sources, so while there is a place for primary, peer-reviewed research, reviews are much better because they help to establish the topic's notability and to avoid novel interpretations of primary sources. All analyses and interpretive or synthetic claims about primary sources must be referenced to a secondary or tertiary source, and must not be an original analysis of the primary-source material by Wikipedia editors. An encyclopedia and a scientific manuscript are very different creatures. ~ Amory (u • t • c) 11:21, 18 January 2019 (UTC)

You and other academics are taught to cite primary sources and offer your original thoughts on a topic: after all, if you have nothing original to say, what is the point in publishing your review, or giving you course merit. Citations in academic circles are not only there as evidence of source material to back-up a point, but also as part of the scientific courtesy of giving credit to the preceding science that established a fact. These are not Wikipedia's concerns and we do not want original thought. We need to publish the consensus opinion of experts, and the best way to do that is to read and cite the secondary literature rather than primary research papers. If a particularly study is exceptionally notable in its own right, then it can be mentioned in article text and for some facts, cited as a source about itself (e.g., number of patients recruited). But for conclusions (was it efficacious, safe, cost-effective, etc) we prefer to use secondary literature. For most facts, the reader is not interested in the study that established it.

There is a particular problem with editors who wish to promote a point of view at odds with the expert consensus. It is easy to cite individual research studies to back up claims that are not in fact considered robust or even truthful by experts. By writing "A scientific study ... found that ...." they appear to give scientific evidence for their POV. We would rather, in most cases, the article text just stated the fact, and cited a high quality secondary source. A good example of such are the systematic reviews performed by medical organisations to make clinical recommendations. They may grade the evidence into levels of quality and may even dismiss studies that fail to meet certain standards. This is the original research we want to build upon rather than doing ourselves. In contrast the authors of those research studies may over-inflate the robustness of their claims and merit of what they have achieved. Review papers are not the only alternatives, of course. For many topics, a professional-level and topic-specific textbook may be more comprehensive, though perhaps not so up-to-date. -- Colin°^Talk 12:51, 18 January 2019 (UTC)