Wikipedia:Village pump (idea lab)

 Policy Technical Proposals Idea lab WMF Miscellaneous 

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

The idea lab section of the village pump is a place where new ideas or suggestions on general Wikipedia issues can be incubated, for later submission for consensus discussion at Village pump (proposals). Try to be creative and positive when commenting on ideas.
Before creating a new section, please note:

• Discussions of technical issues belong at Village pump (technical).
• Discussions of policy belong at Village pump (policy).
• If you're ready to make a concrete proposal and determine whether it has consensus, go to the Village pump (proposals). Proposals worked out here can be brought there.

Before commenting, note:

• This page is not for consensus polling. Stalwart "Oppose" and "Support" comments generally have no place here. Instead, discuss ideas and suggest variations on them.
• Wondering whether someone already had this idea? Search the archives below, and look through Wikipedia:Perennial proposals.

« Archives, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60

Drafting a partial blocks RfC

A few weeks ago, I started a discussion on MusikAnimal's talk page regarding partial blocks and whether the English Wikipedia had any interest in adopting this feature. As a result of the discussion, I created a draft RfC which is now at Wikipedia:Requests for comment/Partial blocks. I wanted to push this here to get more input on the draft. Is the format too messy? For "Option B", the limited implementation, should we include more subcases to start? Should we allow users to add their own suggested subcases during the RfC? Mz7 (talk) 21:35, 10 April 2019 (UTC)

@Amorymeltzer: In response to your question re. enforcing vs. recording editing restrictions, I was mostly trying to put into word the proposal about recording restrictions that MusikAnimal had suggested – presumably part of the purpose would be to help enforce editing restrictions, with the caveat that the restriction might apply to pages not covered by the block. I've added the word "enforcing" to B.3 to clarify this. Mz7 (talk) 21:39, 10 April 2019 (UTC)

I would like to ping SPoore (WMF) to this discussion, since she has information about how other Wikipedia (e.g. Italian Wikipedia) have used partial blocks. Perhaps we might choose to follow the lead of other projects in deciding how to implement this. Mz7 (talk) 21:39, 10 April 2019 (UTC)

Mz7, I'm working on getting metrics and use cases for partial blocks for the wikis that are using them now during the testing phase. SPoore (WMF), Strategist, Community health initiative (talk) 20:00, 15 April 2019 (UTC)

What would the most common use cases for admins be if they had free-reign (Option C)? Tazerdadog (talk) 00:00, 11 April 2019 (UTC)

It seems to me that the way you've structured the RFC with respect to option B would get messy quick. I think as the RFC progresses people would add more use cases to B, and people who !vote early on may not come back to evaluate the later added options. It might be better to make it a two part RFC, and if option B (allow partial blocks in specific use cases) passes, then have a second RFC on what use cases people want. While discussion of the first part progresses, there should be a sub section for discussion (but not !voting) of possible use cases to be added to the second part. ~ ONUnicorn^{(Talk|Contribs)}problem solving 16:21, 12 April 2019 (UTC)

@ONUnicorn: Right, I had that thought as well. Your two-parter RfC idea did cross my mind, and I think I will change the draft to that format. Thanks! Mz7 (talk) 02:05, 13 April 2019 (UTC)

I don't know if Sydney's got all the information together, but I hear that there are some cultural differences, partly based on how a community feels about blocking established editors/vested contributors. At some wikis, blocking a "regular", regardless of how bad the behavior is, brings down wrath on the admin, because now there will be a permanent badge of shame in the user's block log. Blocking anyone except newbies is seen at some wikis as an insult, rather than a technical means to interrupt some bad behavior. But since what they're calling "partial blocks" aren't regular blocks, and therefore aren't recorded in the regular Special:Log/block, some communities feel like this is a more appropriate way to deal with established editors – more like a technical way of saying "Hey, we like having you here overall, but you need to take a break from this particular page for a couple of days".

I don't know that we'd see the same dynamic in this community, but I think that team will have interesting things to say as they analyze what's been going on. Whatamidoing (WMF) (talk) 19:25, 23 April 2019 (UTC)

@Whatamidoing (WMF): I'm not sure I understand. The current guidance seems to indicate that these are recorded in the block log as normal. GMG^talk 11:00, 1 May 2019 (UTC)

I'm sure that it's logged somewhere, but I can't find any specifically in Special:Log/block. The feature's under active development, so they may have tried different things at different times. Whatamidoing (WMF) (talk) 15:18, 3 May 2019 (UTC)

Not sure if this is off-topic or not, but is it technically possible to block a user from editing a page and all its subpages, or pages that contain a particular string in their names? For example, would it be possible to block a user from editing all subpages of Wikipedia:Articles for deletion? feminist (talk) 10:26, 29 April 2019 (UTC)

@Mz7: does this feature allow an admin to block a user from editing a particular set of pages (subpages, etc.)? feminist (talk) 10:03, 1 May 2019 (UTC)

@Feminist: As far as I am aware, partial blocks only prevent editing on specific pages – I don't think you can block the user from a set of subpages, but you can block access to namespaces (e.g. can't edit articles, but can edit talk pages). Adding the ability to block over subpages sounds like something we can suggest to the developers of the feature if it is something we're interested in. Mz7 (talk) 21:37, 1 May 2019 (UTC)

OK then. It seems like an important feature to me, e.g. if someone is problematic at AfD we should be able to block her from editing AfD discussions, while continuing to allow her to edit, say, RFPP. But what we have is better than nothing. feminist (talk) 05:21, 2 May 2019 (UTC)

• As a variant of B, can we have as an option preventing the use of them under WP:DS? As its not a current power, I don't feel we're revoking any authority that would otherwise require another ARBCOM amendment. I very strongly agree that B should be done in a distinct RfC - this is just a suggestion for "if and when B is selected" Nosebagbear (talk) 21:53, 1 May 2019 (UTC)
  • Maybe some day, but not yet. One of the ideas is to allow partial blocks to operate via categories. The use cases look something like:
    • Keep the editor out of 1 to 10 named pages (currently available) – good for routine disputes.
    • Keep the editor out of this namespace – imagine being able to block a paid editor from the mainspace entirely, or stopping someone from breaking templates.
    • Keep the editor out of a large group of pages – routine POV pushing across more than 10 pages or imposing discretionary sanctions.
  • The last one is the category idea. You could create hidden categories for each of the ArbCom discretionary sanctions areas, or a specific list for an individual, and block the user from anything in that category. You'd have to watch additions/removals from the cats closely, but there are tools to do that, and it might reduce the number of problems with accidental TBAN violations (e.g., if a subject is connected to the TBAN area, but the connection is not apparent to the editor). Whatamidoing (WMF) (talk) 15:30, 3 May 2019 (UTC)
• @Mz7: - in your initial discussion you raised basing it off the ECP discussions board (which seems reasonable enough). Having read that, since it predates my active existence by 19 months, the closer mentioned an ECP review to take place 3 months after. Did that occur? And in either case, I would say a 3 month review to discuss how it was working would seem wise here, too. (I don't mean on the ACTRIAL/ACPERM level of requiring re-authorisation, just a mandated discussion of how it was working for en.wiki). Nosebagbear (talk) 14:13, 5 May 2019 (UTC)

  Nosebagbear, I'm not sure whether the specific ECP review that was mentioned in the closing statement was ever conducted, but there have been several discussions since then about the role of ECP if you scroll through the archives of WT:PP. We also had a follow-up RfC that proposed expanding the scope of ECP at Wikipedia:Requests for comment/Extended confirmed protection policy 2. Going back to partial blocks, I would be unopposed to a review after 3 months to evaluate how it's going. Mz7 (talk) 20:34, 6 May 2019 (UTC)

• Comment - timed article t-bans work and serve the same cool-down purpose. Unfortunately, we now have admins using sole discretion to impose indefs and broadly construed t-bans. I'm not convinced that doing so best serves the project. When there is edit warring, and/or disruptive behavior on an article TP, all of the involved edit warriors/disruptors (be it 2 or 5+) should receive the same t-ban. Doing so further relieves the acting admin of having to choose sides or delve into content issues that spawned the disruption and eliminates any appearance of bias on behalf of the admin, perceived or otherwise. It will also encourage a more collegial environment. ^Atsme _Talk 📧 11:03, 23 May 2019 (UTC)
• Personally, I think we can experiment, and use the RFC to discuss best practices. By experimenting we can see where the tool would become useful in practice, and we can make changes and discussion and understand the logic behind the admin and the feedback from the target and other editors. I have been waiting a while for something like this (partly because historically I have caused problems that could have been stopped with a partial block, and partly because I see full blocks as an invitation to create sockpuppets that last for years such as User:Scibaby), and I think the RfC should have a few sections:

• no partial blocks, full blocks only
• partial blocks only by arbitration decision
• partial blocks only by either arbitration decision or community consensus
• partial blocks only when an editor has been edit warring (in addition to ArbCom and CBAN)
• partial blocks when an administrator has determined that a full block may cause more problems, such as sockpuppetry or WP:DONTBITE.

I would also have a section designed to formulate the partial block message which can be commented on by community consensus (relevant interface pages include MediaWiki:blocked-email-user and MediaWiki:blockedtext-partial). But I have been waiting for something like this because sometimes full blocks may not be super appropriate. If a user only causes disruption to Wikipedia processes, only block them from the Project: namespace. If a user makes bogus edit requests, only block them from talk pages. If a user cannot stop criticizing Donald Trump, only block them from Donald Trump and related pages. Full blocks prevent otherwise useful edits elsewhere from happening, and that is why I see this RFC as important.

I also have a question: when will this RFC open? Awesome Aasim 05:49, 3 June 2019 (UTC)

Currently we are still waiting for SPoore (WMF) to send over her research on how this functionality is being used on other projects, but I recognize that it has been several months now since we started talking about this. I'm thinking we'll start the RfC "sometime this summer", maybe in July if SPoore hasn't gotten back to us by then. I'm also starting to dislike the current structure I have for the RfC (see Wikipedia:Requests for comment/Partial blocks). Maybe the RfC should be in two phases: phase 1 would be "yes" or "no" to "should we enable partial blocks?", and phase 2 would be "what restrictions, if any, should we place?". Mz7 (talk) 20:06, 10 June 2019 (UTC)

• @Mz7: - that all seems reasonable, both in terms of timing and split of RfC. July seems a good wait - partial blocks are currently getting an unfair blowback from the Fram saga, and it'd be nice to give them a fair hearing. Do we need extra discussion about the specific options for the "what restrictions" bit? Should that be now, or, if/when it's conceptually passed, we ask editors to suggest what they'd like to see? Nosebagbear (talk) 20:56, 15 June 2019 (UTC)

Hello! I'm Niharika, the product manager on Partial blocks (working alongside Sydney). I reached out to our data analyst to see if there was some preliminary data about partial blocks usage that we can share. Partial blocks is enabled on 17 websites at the moment. Many of these have only recently received partial blocks, so we don't have data to share for them all. Here is a handy table showing number of partial blocks imposed per month on some wikis with the caveat that it only counts blocks made on registered users and not IP addresses. Partial blocks are requently made for IP addresses but due to technical limitations we are not able to record them here.

Italian wikipedia was among the first to receive partial blocks and thus shows most usage of the feature so far. It is worth noting that all of these sites are much smaller than English wikipedia, so don't focus too much on the number itself. We are going to be updating that data periodically as we get more stats. Our data analyst (Morten aka Nettrom) will be sharing more about these numbers in the Research showcase next week that I encourage you all to attend, if you are interested. Happy to respond to any concerns or questions you might have on this! -- NKohli (WMF) (talk) 22:26, 19 June 2019 (UTC)

The possibilities of a custom magic word variable to get the number of watchers on a page

I recently discovered {{User Centijimbo calculator}}. I assumed that it could automatically calculate the number of Centijimbo's a person had, but this was not the case. I discovered that to keep templates such as this one up to date, an editor has to periodically update the number of watchers on Jimbo Wales userpage. It also requires editors who use the templates to update the number of watchers on their userpage periodically.

An idea I have to alleviate the amount of maintenance needed for these templates is, to either add a new magic word variable into mediawiki or define a custom magic word variable for enwiki, which could return the number of watchers for the current page or a specific page. I envisage this would work similarly to the magic word variable {{PAGEID}} which either returns the current page's ID or the ID of a named page. This magic word may have more applications than just keeping a users Centijimbo count up to date, however, currently I am unsure what else it could be used for. I would appreciate any opinions and thoughts on this idea, including other ways such a magic word variable could be used. Thanks, Dreamy Jazz 🎷 ^{talk to me | my contributions} 10:08, 7 June 2019 (UTC)

What conceivable use could this have other than to allow a handful of WP:NOTHERE types to goof around with userboxes? (The userbox you mention is currently used by a total of four people.) I struggle to think of any legitimate reason for ever wanting to know that the number of watchers of any given page has changed; there's arguably a case that on a handful of topics it might be useful to track spikes in the numbers of watchers over time, but those would be vanishingly rare as the pageview numbers will almost invariably be a better indicator of levels of interest (the majority of watchers of any given page are virtually without exception long-departed accounts which never unwatched the page before they retired or were blocked). ‑ Iridescent 10:14, 7 June 2019 (UTC)

Iridescent, there are other templates. The most popular (I think) is User:Audacity/centijimbo (however this only has 149 uses). I do see that this magic word variable would have little use apart from counting Centijimbo's. Thanks, Dreamy Jazz 🎷 ^{talk to me | my contributions} 10:22, 7 June 2019 (UTC)

Indeed, and Template:Annual readership (and the like) covers any relevant uses of page views, which is as you mention the more interesting and useful metric. Watchers are vanity, pageviews are coverage. ~ Amory (u • t • c) 11:00, 16 June 2019 (UTC)

Button for the opposite of "minor" edit?

I suspect something like this has probably been proposed before, but I couldn't find it.

The "minor" button is useful for editors to flag their edit to be (in their opinion) unlikely to be of interest to other editors to review. That helps other editors focus their efforts elsewhere, where it's more likely to do some good. It's a great button (except when misused, but that's a different subject).

Now, how about the opposite? I make an edit that's a needed improvement, well and good, but compared to average kind of changes I make, rather than unlikely, I think this is one more likely to benefit from review. Maybe it's a bit complicated, might have some possible consequences or side-effects, or maybe it could be just a start for other editors to come and expand upon.

Okay, "that's what the talk page is for", I'd bet I'd hear. From what I've seen on talk pages, almost all the sections (except for bot-generated ones) are about issues that demand discussion. I don't see how there's an obvious bright line between those issues that absolutely need discussion and those that don't; so it seems we err on the side of not discussing things on talk pages. That's understandable; no one wants to go through the whole process of formalizing a new discussion on the talk page, just to find that (as they suspected but weren't certain) no other editor finds its worthy of any notable response. Talk pages are basically used as the last resort for editing, and I wouldn't change that. I'm sure we don't want to try forcing editors to start more discussions on the talk page when they may not be needed; that's a lot of additional effort, and the talk page would get cluttered with unimportant issues obscuring the important ones.

This button fills the gap between those edits requiring discussion and those that might benefit from it. The editor clicks this button on their edit of interest, and if any other editor, seeing the button's tag on the edit, reviews it and thinks it should be discussed, they can start a discussion, knowing for certain that there's a discussion to be had. If none do, everyone's happy, and there was no wasted effort.

Although the opposite of "minor", rather than calling this proposed button "major", I think I'd go for something like "interesting".

And, interestingly enough, this could be the default button for all new users. After the user has become savvy enough to know how and why, the user can remove this default setting in preferences.

Oh, and at least some of that bot-generated discussion clutter could be eliminated by those bots simply using this button instead.

--A D Monroe III^(talk) 22:45, 14 June 2019 (UTC)

@A D Monroe III: can you describe the problem you are seeing with bots a bit more? Bots can already pick normal/minor AND bot/not-bot flags on each edit. Most routine bot edits are marked 'bot' already to avoid bothering watchlists and recent changes. — xaosflux ^Talk 23:07, 14 June 2019 (UTC)

I don't have any problem with bots that warrant specific attention; I only mentioned bots here as sort of an allegory. But since I mentioned bots, I'll respond, but I don't want this whole idea to center on bots; this button's value isn't based on bots.

Yes, bots can and do use the "minor" or "bot" flags, and that's fine. The "bot" flag means "automated edit", and the "minor" flag means "small and obvious change", with both indicating less review is needed. But, again, I'm talking about the opposite kind of edit. Say there's a bot that, despite its excellent massive contributions, can sometimes cause additional work to be done depending on the article's current detailed context, which only the article's current editors can know. So the bot must alert those humans to review its work. This is currently done by the bot adding a new section to the talk page. (Being bots, their template-driven context-free overly-formal talk page entries, by necessity, are... um... let's say "less than thrilling".) Only a couple bots now running do this; I suspect there could be more bots like this, but we're reluctant to have a lot of bots cluttering talk pages, so we reluctantly decide to not let them run, loosing their potential great mass of good contributions. But this new button could do much of the same job to urge review without the annoying talk page clutter. More bots!

(I haven't heard of this, but guess that a bot that uses "bot" flag but not the "minor" flag could be interpreted as "please review this bot's edit". Is that true? If so, great, we should announce this better, but more importantly, where's my button for the same thing?)

Again, bots are not the main point here; I bought it up as an example of the kind of edit that could use this new button. --A D Monroe III^(talk) 15:13, 15 June 2019 (UTC)

@A D Monroe III: thanks for the updates, just looking for ways we can improve bot interactions even if this doesn't go anywhere. In general bots making content-related edits that should be reviewed should not use the "bot" flag on that edit. These should be uncommon at best, but if you have some good examples we can look at that behavior (and feel free to bring it up at WP:BOTN. — xaosflux ^Talk 16:43, 15 June 2019 (UTC)

(edit conflict) Not a bad idea, but what is wrong with putting something to the effect of "please review" in the edit summary? There's also the mw:ORES review tool, which flags "potentially damaging" edits. Eman235/talk 23:11, 14 June 2019 (UTC)

("Potentially damaging" is, I hope, not applicable to an "opposite of minor" edit; I don't think editors should be encouraged to have their edits cross this line just to get some attention.)

I agree that edit summaries are the best way to do this right now. Edit summaries are limited, so this works best if the indication is terse, right? To be most effective, we could advise people to have the edit summary include the phrase "please review" (as suggested) or "interesting" or whatever we decide. If we go that way, to be sure they get it correct, we should have some way to have this phrase generation automated, like with a button. And then we could have reviewing tools search for this exact phrase.

Taken together, that's identical to my proposal here. I think a tag is better than a phrase, though. But, maybe we could start implementing this by just a new guideline on edit summaries? --A D Monroe III^(talk) 15:45, 15 June 2019 (UTC)

• Don't we already have the opposite of "This is a minor edit" with the "Watch this page" box? Vorbee (talk) 15:03, 16 June 2019 (UTC)

Watchlist is similar, but it works the other way around. Putting something on my watchlist means I want to review other editors' changes. If I want other editors to review my edits, I can't force it onto others' watchlists. And, watchlist is per page, not per edit. --A D Monroe III^(talk) 14:32, 17 June 2019 (UTC)

• Is it possible to mark content which changes a fair percentage of an article as major automatically? I think as we already have the diff size, this could be easily done by tweaking the ui. Viztor (talk) 21:23, 16 June 2019 (UTC)

We kind of have a weak version of this already, as edit history gives the size of each edit (it's the delta size, so not perfect in this respect). I'm okay with enhancing tools to automate finding edits to review based on various criteria, but that wouldn't address what I'm asking for here. I want a tag that I decide to attach to one my own edits, indicating that despite any and all superficial characteristics of this edit, it still might be good for others to double-check it. --A D Monroe III^(talk) 15:07, 17 June 2019 (UTC)

Process ideas for improving civility and avoiding harassment

Some recent events have highlighted that, as a community, we may not always deal as effectively as we might with issues of civility and (perceived) harassment. I don't want to rehash those events here (as they're already being discussed in enough fora), but I wanted to discuss how we could tweak our processes so we might encounter such issues less often in the future. I have three suggestions. I would appreciate some assistance in transforming these ideas into concrete proposals. I'm sure that my ideas are not wholly original, so I would also appreciate pointers to prior discussion of similar ideas.

Firstly, it is my perception that a lot of incivility and other conduct issues arises from content disputes that spiral out of hand between a small number of editors. By the time others get involved, battle lines have been drawn up and the conduct issues require administrators to use their tools. What I would like to see is a system that encourages earlier involvement of other editors in content disputes before they escalate into conduct issues. Looking around at our existing processes, Third opinion does this to some extent; I like that approach and I think it can work well. I particularly like the facts that it is aimed at content not conduct and that the third parties are discouraged from joining the fray by editing directly. This allows the disputants to work together to resolve the issue instead of simply taking sides and holding grudges. The two main drawbacks to 3O (in my view) are that people don't (know about it or think to) invoke it, and 3O requests may not be handled very promptly. If we could find ways to make 3O better known, both for editors in content disputes and for potential third parties, then I think it would work even better.

Secondly, in cases where we have a problem editor, I think it would help to have more people involved in the response. It is perfectly valid, on finding one problem edit, to dig into a user's contributions to see if the problem is chronic. Similarly, the imposition of sanctions does not make an administrator involved. Nevertheless, I think there are a number of reasons why it is better to have many experienced editors dealing with a specific problem editor. For close calls, opinions may differ on how best to handle a situation, and someone may have a creative idea on how to turn a problem editor into a productive contributor. I think that it makes a big difference to users if they can see a broad consensus against their problem behaviour rather than repeated criticism and sanctions from a single editor, no matter how experienced or privileged. This is a particular problem for highly-focussed noticeboards where most of the work is done by a small number of editors/admins. Could we find a way to make it easier to pass investigations and long-term monitoring on to other editors? Could we somehow make it so that we don't put administrators in the position of repeatedly imposing sanctions on the same editor? Remember, if it's the right thing to do, then someone else will do it.

Thirdly, users faced with intractable content disputes or conduct issues often respond poorly, whether by retaliating with their own bad conduct, or by bringing the issue to a noticeboard in a way that ultimately does not work out well for them. Perhaps we could have some system whereby experienced editors can act as sympathetic advisors to users facing such problems. These advisors could discuss how the conduct of all participants aligns with policy and guidelines, give suggestions on how to de-escalate the situation, assist the user in reporting the situation, and give a candid assessment of the likely outcome. While the advisor may communicate their perspective to other users on talk pages, similarly to third opinion, they should not directly involve themselves in content disputes and administrator advisors should avoid using their tools (or threatening to do so). The advisor can withdraw at any time and is explicitly not committing to represent the client or advocate for them in any proceedings. The client can, within reason, seek another advisor if they are not happy with the advice. It is possible that OTRS serves this purpose to some extent, but I have no experience of it.

Bovlb (talk) 04:05, 21 June 2019 (UTC)

I've just one comment at this point: all editors need to be aware of linguistic and cultural differences. Jocular terms in one context may be seen as insulting to another reader. This goes beyond modes of address and includes terms that are acceptable in some areas but seem as obscene and blocked by edit filters in others. Random examples:

• "Hey dude" – So you are starting by assuming I'm an incompetent greenhorn.
• "WTF" (particularly if spelt out) – Blocked by businesses. Also include "MFs" and "SoB".

I'm sure you see the pattern. Use of any of the above will be seen as a light hearted attempt to diffuse a situation in some areas but act as a red rag to a bull in other areas. Regards, Martin of Sheffield (talk) 08:03, 21 June 2019 (UTC)

Bovlb, your second idea sounds like a proposal to revive Wikipedia:Requests for comment/User conduct. WhatamIdoing (talk) 17:49, 21 June 2019 (UTC)

@WhatamIdoing: Hmm. I see this as serving a rather different purpose from RFC/U, although I agree they are both intended to bring in a wider audience. RFC/U was intended to provide a one-time examination of a user's history by many users. I'm talking about diffusing responsibility for ongoing handling of (potentially) problem users over time. In general, a specific edit only requires one experienced editor to look at it; I'm trying to find a way to reduce the extent to which he same editor deals with multiple edits by the same user over time.

Currently we have a system whereby some editors will find themselves dealing with the same users repeatedly, either because they continually encounter them, or because they choose to monitor their contributions over time. In the latter case, we are clearly being very inconsistent because most editors do not do this sort of long-term follow-up, and it is understandable that users targeted for such follow-up would feel unusually scrutinized and, perhaps, harassed.

I held back from being too specific about solutions, partly because I wanted to get agreement about the general principle and partly because I felt my text was already too long, but here are a couple of specific examples to illustrate what I intend with my second point:

* We create a process for a centralized "user watchlist". Any administrator can add a user to the watchlist for some specific length of time (a week, a month, a year). We might have separate watchlists for different types of problem, such as civility, copyright, unsourced BLPs, and promotional spam. We provide a way for any editor to see recent contributions by users on the watchlist. Edits by these users will therefore be temporarily subject to increased scrutiny by many editors. This is a lightweight way to protect the encyclopedia from long-term problem users without imposing direct sanctions or restrictions, and without putting the burden on a single editor.

* We change the guidelines for administrators to discourage them from imposing sanctions on the same user repeatedly except in the most clear-cut of cases. We emphasize this guidance and expand on it in the context of specific noticeboards. This ensures that repeated and escalating sanctions have many hands on them rather than falling within the discretion of a single admin.

Bovlb (talk) 19:28, 21 June 2019 (UTC)

• T&S themselves turned down the desire for such a user-watchlisting system in the past. I agree that it avoids 1 user being accused for harassment concern, but I would personally say this is something most users would find more problematic to be on. A similar concern "feels like a gang rather than 1 pursuing editor" applies to the second one (however (un)reasonably). Both are absolutely good ways of resolving the original concern, but I'd just be concerned that these methods could be implemented and we'd actually get more complaints. I think if we opted for one we'd need a T&S signoff saying that they'd accept it. Nosebagbear (talk) 13:53, 22 June 2019 (UTC)

@Nosebagbear: Thanks. I'd rather discuss whether it would be a good idea for the community than speculate about whether T&S would permit us to do it, but do you have a link for where they turned it down? Also, I agree that users might find it stigmatizing to be on such a list, but perhaps less so than being blocked, and we could use it as a softer alternative to blocking. Being on a user watchlist only affects you to the extent that you want to continue making problem edits without interference. And if there are complaints, the diffusion of responsibility makes them complaints against the community rather than against one editor/admin. Cheers, Bovlb (talk) 19:48, 22 June 2019 (UTC)

phab:T2470 has been where a chunk of discussion was; there was also the CommTech wishlist item. I don't know where T&S rejected the task, but CommTech did so. --Izno (talk) 20:43, 22 June 2019 (UTC)

On that page it notes at the top that the safety and support team (the precursor to T&S, I believe) were involved in saying no. Elsewhere I remember reading that CommTech had some initial concerns and raised it with the safety team who were distinctly against it. There is something to not letting our T&S fears stop us from thinking of ideas, I definitely concede. Nosebagbear (talk)

Thanks for the links. The set of proposals described there all differ slightly from my suggestion, although some of the same concerns still apply. I was envisioning that the project would have a handful of user watchlists maintained by admins according to specific criteria similar to WP:BLOCK. As with blocking, being put on a watchlist could be appealed and admins held responsible for abuse, but the whole process is less interference to a user's activity than blocking. But my key point here is that is better all around if problem users received feedback from many other users instead of repeated feedback from one, and this was just an example of something that might achieve it. Bovlb (talk) 02:33, 23 June 2019 (UTC)

I have sometimes wondered about rotating duties, such as working a limited shift at a busy noticeboard. For example, you'd sign up to be the primary person (or one of them) to deal with ANI for whatever discussions begin on Mondays from 14:00 to 15:00 UTC, and the rest isn't your problem. And after a while (somewhere between a month and a year), you rotate out to a different area, with our grateful thanks and the hope that you'll really enjoy RSN or CCI or whatever it is that you decide to pick up next. The system by which some people spend all their volunteer time, for years on end, semi-OWNing a drama board isn't good. That kind of situation means that the community is in trouble if certain editors leave (and all editors will eventually die, so we shouldn't design for the opposite), and the editor gets a skewed view of the whole project (everything's self-promotion if you live at NPP long enough, everything's an interpersonal war if you live at ANI long enough, etc.). Of course we can't force volunteers to show up on a particular schedule, but I think we could do somewhat better than we do now with encouraging people to learn new skills, train their future replacements, and engage in a balanced variety of activities. WhatamIdoing (talk) 17:15, 22 June 2019 (UTC)

Indeed; if we had an admin who was particularly experienced in something really complicated and thankless where few people wanted to get involved, such as conducting bulk contributor copyright investigations for historic pages where the bots are useless as the pages are already mirrored, or monitoring the new pages feed for spammers, they could help train… Oh. Wait. ‑ Iridescent 19:55, 22 June 2019 (UTC)

@WhatamIdoing and Iridescent: - both of your points here are accurate, which somewhat combine into a "there are a handful of extremely technical, tedious, tasksets (WP:ACC is another tough one). Perhaps as a method of alleviating multiple problems at once, we should look to see what can be done to encourage individuals to do a few hours each week on a less standard area. I imagine it'd be a nuisance start-up, but it only needs partial success to help with both succession-planning and avoiding apparently-but-not harassment from all corrective edits coming from 1 person. I'm sure this has been tried before, but there's probably more community attention now than there was. Nosebagbear (talk) 20:56, 22 June 2019 (UTC)

A few hours a week for a long time, or follow it for a month (and then walk away)? Maybe pick "a major and a minor". We could probably come up with multiple ways to conceptualize it. Even making (updating?) a list of 'service areas' could help. WhatamIdoing (talk) 21:39, 24 June 2019 (UTC)

@Aquillion suggested an anonymous reporting system that hits my first and second points: it makes it easier to get help earlier; and it is likely that different admins would respond to reports about a specific user over time (and it could even be made a constraint of the system). Bovlb (talk) 22:53, 27 June 2019 (UTC)

Add a "changes since previous editor" link to diffs

Often when I'm patrolling for vandalism, I'll find an edit that is the second or third sequential edit that user has made to the article. Here's an example of what I mean. In order to determine whether contributions are vandalism, I like to view all of the sequential changes the user made to the article, like this. In order to get to that diff view however, I need to go to the revision history, select the previous editor's contribution, and click "compare selected revisions". It would make my work a lot easier if in the diff view there was a single link you could click that showed all of the sequential changes a user made to the article. Thoughts? Anne drew (talk) 15:37, 27 June 2019 (UTC)

Hmm...I distinctly remember having this feature for a while, through some gadget or script. I think it also had a "changes since my last edit" button. Eman235/talk 17:22, 27 June 2019 (UTC)

If that editor's edits are the latest revisions, you can use the "cur" link from the most recent edit by a different user. That's maybe not the shortcut you're looking for. Something like this is already implemented into pending changes, it's probably trivial for someone to design a script for you. Ivanvector (^Talk/_Edits) 17:37, 27 June 2019 (UTC)

Is it really a problem if it takes a couple of seconds longer than it could to display this? It would be a good idea if people such as vandal fighters slowed down a bit to think rather than produce immediate sub-second reactions to edits. Phil Bridger (talk) 18:16, 27 June 2019 (UTC)

Of course efficiency matters – especially if you're evaluating dozens of edits every day. If diffs took ten seconds to load that would also be a problem. Anne drew (talk) 18:39, 27 June 2019 (UTC)

Efficiency only matters when things are got right. Those ten seconds, if you spend them thinking, go some way to giving you time to get things right. Phil Bridger (talk) 18:59, 27 June 2019 (UTC)

Hm—might the revision slider help at all? Eman235/talk 18:56, 27 June 2019 (UTC)

Yes, thank you. Anne drew (talk) 19:10, 27 June 2019 (UTC)

We need to severely discourage use of Social Media Corporations for Wikipedia and Wikimedia business

In the course of the Fram debacle over the last week, we have seen two cases of WMF insiders Twitting at each other about how contemptible the community and community matters are: [1] [2] These should not be taken as one-off or two-off problems: the use of Twitter is inherently incompatible with Wikipedia business. Here are some reasons why:

1. These Twitter conversations are, first and foremost, a theft from the community. We have talk pages, we have Meta, we have mailing lists, we have Bugzilla, we have countless ways to communicate freely and without having to submit to the terms, conditions, and censorship of a private monopolistic corporation. Using "social media" steals our right to be involved, to respond, for many sites even to read what is going on, unless we submit to outsiders' legal terms.
2. Twitter is prone to manipulation by armies of bots or legions of biased outsiders with agendas, making it far less viable as a means of gauging support than the signed comments of experienced editors.
3. Twitter creates Minimum Prosecutable Units, devoid of context or details, which are prone to be used to damage the reputations of those who use them.
4. Twitter conversations are nearly impossible to follow very far.
5. Twitter usage inspires insiders to try to ram unwanted formats -- like Flow -- and unwanted dictatorial ideas and structures -- like Superprotect and the desysop of Fram -- against the will of a more democratic community.

For these reasons, we need a formal proposal to STRONGLY DISCOURAGE the use of Twitter accounts for anything other than the original expedient reason given for creating them, which is to say, for "outreach". Outreach means those innocuous little bot-like messages about our articles and events. Not decision making, not debate, not snide comments about editors or news stories!

The text I'm thinking of is something like:

Editors with advanced positions or holding positions of trust in the community or Wikimedia organizations are STRONGLY DISCOURAGED from using privately owned social media to conduct conversations of relevance to Wikipedia decision making, policy, or software design. Conversations of relevance to the work of Wikipedians properly belong on forums within our network of organizations.

I could use some advice on how better to put this. But we need something, and we need it last week. Wnt (talk) 11:12, 28 June 2019 (UTC)