Wikipedia:Village pump (proposals)/Archive 152

Source: Wikipedia, the free encyclopedia.

User-right that allows non-admins to Semi-protect 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.



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

💸
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)
💸
17:50, 3 July 2018 (UTC)

  • Another update I'm fine with NielN's proposal (I will admit this is a broad proposal, I ain't offended)
    💸
    02:22, 4 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.
    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.
    π, ν
    ) 18:15, 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)
  • Oppose. If we can trust users with the protect button, then we can trust them with the admin toolset. -FASTILY 18:24, 3 July 2018 (UTC)
  • Ehhhh... - Ehhhh... Ian.thomson (talk) 18:29, 3 July 2018 (UTC)
  • Wildly open to improper use, and likely to just inflame editors prevented from editing. Plenty of RFPP items get declined, and probably more should. Additionally, as per Rob above, it helps to have all the tools in order to use the right one where appropriate. ~ Amory (utc) 18:40, 3 July 2018 (UTC)
  • Oppose God no. I'm in favour of unbundling some abilities from the admin toolset, the ability to lock down pages at will is not one of them. Only in death does duty end (talk) 20:21, 3 July 2018 (UTC)
  • Support I do see the possibility of abuse of such a user right, but I think if it was abused somebody (e.g. an administrator) could remove those privileges, just like with any other user right. This does sound like it could be a good idea if executed right. On a side not, what would this user right be called? SemiHypercube (talk) 22:54, 3 July 2018 (UTC)
    • @
      💸
      23:06, 3 July 2018 (UTC)
      • @
        pending changes protection to pages, since it's essentially just a weaker version of semi-protection. SemiHypercube (talk
        ) 13:34, 4 July 2018 (UTC)
        • @SemiHypercube: Pending changes is a nightmare for editors to deal with when there are rapid-fire changes to an article so I would not recommend offering that option. --NeilN talk to me 13:45, 4 July 2018 (UTC)
        • Also, I'm OK with NeilN's proposal (except maybe allow it on any page undergoing sustained vandalism, not just BLPs). SemiHypercube 01:01, 10 July 2018 (UTC)
  • Support. This is completely consistent with the unbundling of other admin rights, and if the power is only to semi-protect (meaning that experienced editors would still be able to edit the page), there is very little in the way of lasting mischief that can be done with it. bd2412 T 00:30, 4 July 2018 (UTC)
  • I agree the original proposal is too broad. But I think the following would be of great value to the project:
  • 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 Coletc 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
    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)
@
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)
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
    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.

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. 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
    talk
    ) 23:32, 20 July 2018 (UTC)
  • 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.
talk
) 17:22, 21 July 2018 (UTC)
Hmm. Looking at one right now, a request to protect
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

 – 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

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)
  • Oppose: There's already enough lead section clutter from templates, and this would just impose another permanent addition. Praemonitus (talk) 22:04, 25 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.
talk
) 20:54, 2 August 2018 (UTC)

Restrict Wikinews links in articles

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

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

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 --S Philbrick(Talk) 15:59, 17 July 2018 (UTC)
  • Support: This proposal is well-argued, very much limited in scope (which I like), and follows policy, so far as I can tell. I will add that "Wikinews links in the middle of articles" is jarring to the reader (at least when I read articles). Javert2113 (Siarad.|¤) 19:12, 17 July 2018 (UTC)
  • Support These would be better placed at the bottom in the external links, not in the middle of the article. — AfroThundr (u · t · c) 19:40, 17 July 2018 (UTC)
  • SupportJc86035 (talk) 08:50, 18 July 2018 (UTC)
  • Support. I would think that the general WP:SISTER stuff covers this, but if people are ignoring it then we need to be specific.  — SMcCandlish ¢ 😼  10:10, 18 July 2018 (UTC)
  • Support per SMcCandlish: I had understood the WP:SISTER guideline to include Wikinews by omission (i.e. only Wiktionary and Wikinews are explicitly mentioned as suitable for inclusion in the main body of article), but if clarification is required, then so be it. In the specific case of the EastEnders article you mention, then my first instinct would be that a Wikinews category (if such a thing exists) would have a box link in the External links section. — Sasuke Sarutobi (push to talk) 12:13, 18 July 2018 (UTC)
  • Support. --Guy Macon (talk) 15:39, 18 July 2018 (UTC)
  • Support. I agree that the existing language should imply this, but there are enough examples in violation of this rule it's worth making this explicit.
    π, ν
    ) 20:37, 18 July 2018 (UTC)
In total consent with Pi zero. --Abhinav619 (talk) 10:10, 27 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.

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

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 (utc) 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.

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

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)

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)

@

b
} 15:48, 11 August 2018 (UTC)

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

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)

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

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:

  • 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: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
    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 {{
    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
    "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)
        • I think you are attributing to me something that I did not say. --Tryptofish (talk) 19:27, 6 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
    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 (utc) 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)
  • 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
      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. 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: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. —
    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)
    • @
      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)
      • @
        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)
      • @
        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)
        • @
          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
    π, ν
    ) 04:57, 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,
    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)
    • @
      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)
  • 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: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:ARCA. In my view, just doing away with the alert requirement would be better. Sandstein
    14:59, 3 July 2018 (UTC)
    @
    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)
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)
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 (talkcontribs)
  • 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
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 great idea. --Tom (LT) (talk) 10:41, 12 August 2018 (UTC)
  • Strongly Support Things should be kept as simple as possible, so the unnecessary words should be removed. —Eli355 (talk | contribs) 23:17, 14 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)
  • This is fairly cosmetic, can you drop an exact edit request at MediaWiki talk:Histlegend. If no other admin picks it up I'll do it in a couple of days. — xaosflux Talk 02:27, 15 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. ) 04:11, 29 August 2018 (UTC)
We have a project to check for Wikipedia:WikiProject Missing encyclopedic articles – Finnusertop (talkcontribs) 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
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.

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 (talkcontribs) 17:10, 6 September 2018 (UTC)