Community Wishlist Survey 2022/Anti-harassment

Anti-harassment
11 proposals, 291 contributors, 476 support votes
The survey has closed. Thanks for your participation :)



UserBlind mode

  • Problem:
    • Many users have a hard time commenting on the content and not the contributor in certain situations, and often find themselves biased in certain ways towards or against certain users.
    • The occasional need for contributors to pass judgement on the conduct and actions of their peers can lead to interpersonal conflict. The possibility of such consequences often leads to difficulty in fairly judging others' actions, when associated with particular reputations.
  • Proposed solution: An opt-in mode to allow users to navigate and participate without seeing others' usernames. When the mode is enabled, the usernames of other editors are hidden from oneself behind an anonymizing token (e.g., every comment from the first editor named on that page is from "User 1", every comment from the second editor named on that page is from "User 2", etc.) for as long as the mode is on. (The underlying page content is not affected, nor is the appearance altered for anyone other than the person viewing through the mode.).
    • Example:
      • What everyone sees:
        BobTheEditor's actions are in violation of policy. --FredTheEditor (talk) 07:59, 23 January 2022 (UTC)
        No, they are not. --BobTheEditor 07:59, 23 January 2022 (UTC)
      • What you see while you have UserBlind mode enabled:
        [User #1]'s actions are in violation of policy. --[User #2] 07:59, 23 January 2022 (UTC)
        No, they are not. --[User #1] 07:59, 23 January 2022 (UTC)
  • Who would benefit:
  • More comments: Proof of concept, Village Pump post, 2021 wishlist proposal
  • Phabricator tickets:
  • Proposer: Yair rand (talk) 07:36, 23 January 2022 (UTC)

Discussion

This sounds good, but there are some practical problems: 1) When one of users mentions and misspell (even if deliberately) name of second user, script will not be able to recognize it. (FredtheEditor, Fredetc., BoobTheEditor). 2) In languages with declination would be the usernames in different form ((Czech)Viděl jsem BobaTheEditora (English)I've seen BobTheEditor...). So the practical impact will be limited JAn Dudík (talk) 08:06, 24 January 2022 (UTC)

It doesn't have to be perfect to be useful. In fact, merely replacing names in the signatures/links could be useful.
In the case of an RFC, there are comparatively few mentions of others' usernames, and editors in most communities put a high importance on evaluating the arguments impartially, without regard to the person's reputation. (In other instances, you definitely want to know who's posting, in which case you turn it off.) WhatamIdoing (talk) 16:43, 24 January 2022 (UTC)
  • My reading of the examples is that this is something you'd want to function on free-form text everywhere (hopefully only in non-content namespaces). But usernames can be anything, for example look at how this statement would be modified if working on free text:
    ORIGINAL: Many users have a hard time commenting on the content and not the contributor in certain situations, and often find themselves biased in certain ways towards or against certain users.
    MODIFIED: Many [TOKEN1] have [TOKEN2] [TOKEN3] time commenting on the [TOKEN4] and [TOKEN5] the contributor in [TOKEN6] situations, and often find themselves biased in [TOKEN6] [TOKEN7] towards or against [TOKEN6] [TOKEN1].
  • xaosflux Talk 19:43, 24 January 2022 (UTC)
    • @Xaosflux: The idea is to try to hide only things that are actual references to users, not accidental name overlaps. For implementation: The proof-of-concept I threw together works by recording the names of all users for whom the page has any links to their userpages, talk pages, contribs, logs, etc., and also remembering which strings refer to users for the rest of the session. In practice, that method seems pretty reliable, though it could probably be improved upon. Things could become difficult if users with usernames identical to very common words were to comment on the discussion page being read, but that kind of thing really doesn't happen often. --Yair rand (talk) 21:06, 24 January 2022 (UTC)

It seems that some people (Роман Рябенко, Phyrexian and Mannivu) have misunderstood this proposal. It's not about "anonymous editing"; it's about an optional mode that lets people who have enabled it hide others' usernames so that they can focus on those people's arguments rather than their identities (en:Wikipedia:No personal attacks, meatball:ForgiveAndForget). Kleinpecan (talk) 15:23, 3 February 2022 (UTC)

@Kleinpecan Ok so I understood this the way around. However, I think that this isn't something really useful. I mean: if the user disable the gadget they will still have some bias towards the users they're talking to; so this doesn't resolve the problem (having bias and not being able to deal with those biases) and I don't think it's useful. --Mannivu · 17:04, 3 February 2022 (UTC)
@Kleinpecan I understood it just as you explained. I still believe that it is "anonymous editing". People edit less responsibly if they evaluate only the arguments and do not take into account who is the author. There are even user pages which may declare what some people dislike or how they should be addressed to with respect. The user of the gadget can even attack an argument more than if they knew who the author is. There is also the risk of losing context in a discussion which may span multiple talk pages. Moreover, the users of such gadget can post something harsh intentionally and, when confronted with it, just say that they had the gadget enabled and it wasn't a personal attack. When people put their signature next to the post, they already want to take credit and responsibility for the statements they make. If they do not want that, they can resort to anonymous editing, which is already available. Even more, when nicknames are used, they already provide anonymity which without sock-puppeting allows consistency of discussions across talk pages. So, I see more harm than value in the proposed self-blinding gadget because it breaks the natural flow of discussion and gives potential for reducing accountability.--Роман Рябенко (talk) 08:10, 4 February 2022 (UTC)

L736E: Because the proposed user-blind mode is optional, there would be no need to engage in stylometry if you want to find out who wrote what. And the proposal is not about "bias in contents"—see my comment above. Kleinpecan (talk) 15:30, 3 February 2022 (UTC)

@Kleinpecan: I understood the proposal, but I think it's not a good idea. We should not spend energies because some users can not control their own biases, based on what they think they know about other users. It is their own responsability to deal with that, not ours. --Phyrexian ɸ 15:46, 3 February 2022 (UTC)

Voting

  •   Support I have bias, you have bias. Less bias means better discussions. Lectrician1 (talk) 06:00, 29 January 2022 (UTC)
  •   Oppose Gamekiller0010 (talk) 08:33, 29 January 2022 (UTC)
  •   OpposeAca (talk) 12:16, 29 January 2022 (UTC)
  •   Oppose Not quite a good idea. Thingofme (talk) 14:11, 29 January 2022 (UTC)
  •   Oppose Helen(💬📖) 20:11, 29 January 2022 (UTC)
  •   Oppose Anonymous editing reduces responsibility. Anonymous editing is already available. --Роман Рябенко (talk) 09:14, 30 January 2022 (UTC)
    I think you're misunderstanding. It is not anonymous editing. It is an optional feature a user can enable on their account to 'anonymize' usernames across the platform. You will still see their username unless you enable the feature. Detsom (talk) 21:58, 7 February 2022 (UTC)
  •   Support too much depends on user names and perceived reputation userblind mode seems like a good thing to try. Sasha7272 (talk) 11:12, 30 January 2022 (UTC)
  •   Oppose easy cryptography, heavy exception to general principles --g (talk) 15:00, 30 January 2022 (UTC)
    Can you expand? Other people seem to be taking your lead in opposing without much explanation. This is an optional feature that allows users who desire so to obscure the usernames of others, not sure what general principle is being excepted. It's no different than taping over your screen so you don't see usernames. Detsom (talk) 22:02, 7 February 2022 (UTC)
  •   Oppose Bias in contents is not username dependant, blinding the username is useless. BTW, there are many ways to "recognise" some known editors (phrasing style, typical arguments), adding opacity is not the solution.--L736Etell me 15:05, 30 January 2022 (UTC)
  •   Oppose i don’t think that it’s a good idea. --LittleWhites (talk) 15:10, 30 January 2022 (UTC)
  •   Oppose Exactly because it's irrelevant who performs those actions, there is no need to conceal the name. --.mau. ✉ 17:40, 30 January 2022 (UTC)
  •   Support Khoshhat (talk) 19:47, 30 January 2022 (UTC)
  •   Oppose per Роман Рябенко and Gianfranco (g). --Phyrexian ɸ 21:20, 30 January 2022 (UTC)
  •   Oppose --Havang(nl) (talk) 15:05, 31 January 2022 (UTC)
  •   Oppose per Роман Рябенко, Gianfranco (g) and L736E. --Mannivu · 09:20, 31 January 2022 (UTC)
  •   Oppose I don't think this would really help. Günther Pabst (talk) 08:58, 1 February 2022 (UTC)
  •   Support Of course I support this. It's an optional gadget and that enables us to see how neutral we are in reality. Paradise Chronicle (talk) 04:41, 2 February 2022 (UTC)
  •   OpposeSvārtava [tcur] 04:48, 2 February 2022 (UTC)
  •   Oppose KingAntenor (talk) 06:00, 2 February 2022 (UTC)
  •   Support per en:Wikipedia:No personal attacks and meatball:ForgiveAndForget. Kleinpecan (talk) 15:23, 3 February 2022 (UTC)
  •   Support --Ciao • Bestoernesto 02:33, 6 February 2022 (UTC)
  •   Oppose Per L736E, not really good for CU & OSes, probably another tool better than UserBlind should be developed. --Liuxinyu970226 (talk) 03:45, 6 February 2022 (UTC)
  •   Oppose unnecessary overcomplication. SpinningSpark 12:36, 6 February 2022 (UTC)
  •   Support: although it often helps to know where each comment is coming from, there certainly are situations where it's better if you don't. Uanfala (talk) 15:21, 7 February 2022 (UTC)
  •   Support Supporting only because this is an opt-in feature. Some of the above comments seem to indicate people might not understand the intent. It's not anonymizing posts publicly, it's only changing the UI of a user if they choose to enable the feature. Detsom (talk) 21:54, 7 February 2022 (UTC)
  •   Support As an opt-in feature I would support this, but not as a default. Euphoria42 (talk) 02:06, 9 February 2022 (UTC)
  •   Support There should be a minimum edit count to use this feature tho. SHB2000 (talk | contribs) 07:51, 10 February 2022 (UTC)
  •   Support: WMF plan to hide ip as anon+hash, why not see others as user+hash, for the same reasons as hiding ip. Sunpriat (talk) 22:09, 10 February 2022 (UTC)
    • @Sunpriat and SHB2000: I think you may have misunderstood the proposal. UserBlind would not hide the user's identity, it would just allow one to read pages without seeing the other people's usernames at the same time. --Yair rand (talk) 23:34, 10 February 2022 (UTC)
      That's what I'm talking about - while reading the discussion, all the names shown are equalized by a not-so-individual visible hash number. Yes, it doesn't hide anything, it just makes the discussion read more neutrally. It's just that the appearance of this is similar to how the anons in that WMF-proposal will look, and hiding so deeply is not required here. Sunpriat (talk) 23:51, 10 February 2022 (UTC)

Deal with Google Chrome User-Agent deprecation

  • Problem: Google Chrome, the most widely used browser on the internet, will soon start limiting the information it includes on HTTP requests about the client (also known as the user-agent string). User-agent, along with IP address, is an important piece of data used by CheckUsers to fight sockpuppetry.
  • Proposed solution: See phab:T242825
  • Who would benefit: All projects in which CUs are run and a substantial group of users edit from internet providers who own wide IP ranges and frequently hop the user's IP within this broad range (which I understand is more common in developing countries than in some developed countries like the US in which static IPs are more common).
  • More comments: This is already on people's radar, but submitting it here, on behalf of the CU community, is an attempt to bring it up the list of priorities.
  • Phabricator tickets: phab:T242825
  • Proposer: Huji (talk) 21:34, 17 January 2022 (UTC)

Discussion

  • It is very useful for CUs to have useragents to rule out or further connect two users who share the same IP / similar ranges. Especially on busy ranges or for proxies two accounts being on the same or similar IPs doesn't necessarily technically link two users to each other. Having alternatives such as UA Hints provided in the tool would be better than having non-descriptive UAs (which is what Google Chrome plans to have). Dreamy Jazz talk to me | enwiki 22:07, 17 January 2022 (UTC)
  • Could you explain to someone with no experience with CheckUser to what extent anything this could be dealt with/what could be done to deal with this? ~~~~
    User:1234qwer1234qwer4 (talk)
    19:25, 7 February 2022 (UTC)

Voting

Access log of oversighted contents

  • Problem: Oversighted revisions often contain non-public personal information, which can be accessed to arbitrarily by oversighters. There is a risk of oversighters being bribed to search for oversighted information, in order to dox someone.
  • Proposed solution: Each access to oversighted contents should generate a private log entry, and thus abnormal information collections could be detected. It's not applied to recent oversighted contents for review convenience.
  • Who would benefit: People who have personal information oversighted.
  • More comments:
  • Phabricator tickets:
  • Proposer: Lt2818 (talk) 15:23, 14 January 2022 (UTC)

Discussion

  • I agree. However, I think that checkuser log, and oversight log should be publicly logged in order for normal users to find abnormal actions of the checkuser or the oversighters. Thingofme (talk) 15:33, 15 January 2022 (UTC)
    That request is not feasible under the privacy policy today. Izno (talk) 00:23, 17 January 2022 (UTC)
  • IP access is soon going to be logged, so this seems like a reasonable request. Pretty sure it's not what I would want the team to spend time on though. --Izno (talk) 00:22, 17 January 2022 (UTC)
    And maybe, logging any deleted view access? I still do not think arbitrary people would be able to see the logs per the privacy policies... that said, not sure of the size of this request. Izno (talk) 00:24, 17 January 2022 (UTC)
    @Izno I don't think logging any deleted views would be useful, since they don't generally contain any sensitive data (unlike oversighted material and IP addresses after they are masked). ~~~~
    User:1234qwer1234qwer4 (talk)
    20:14, 7 February 2022 (UTC)
  • A public OS log would not be permitted - and at times would be actively counterproductive. In regards to Thingofme's comment, a public CU log would be catastrophically counterproductive - think how orangemoody would have done if the editors in question could have known the noose was tightening. Nosebagbear (talk) 13:15, 18 January 2022 (UTC)
The CUs on enwiki have explained quite well why the CU log is private: they check some accounts and decide that there was a violation. They then check all the accounts' IP addresses to look for additional socks, and any account they find on the said IPs for confirmation that it is in fact a sock (and frequently decide some aren't). If the check log were public, that would be a huge amount of private data revealed to the public. 2.55.185.246 18:52, 22 January 2022 (UTC)
Could you give an example of such private data? ··gracefool 22:13, 4 February 2022 (UTC)
yeah, sure... /s ~~~~
User:1234qwer1234qwer4 (talk)
20:11, 7 February 2022 (UTC)
  • In case of legal need, I am pretty sure HTTP access logs already allow WMF or legal authority to check all log accesses. -- Pols12 (talk) 13:44, 29 January 2022 (UTC)
    I'm not sure how long the HTTP access logs are kept. This proposal will let other volunteers (oversighters & stewards) be aware of permission abuse, before a WMF investigation. Lt2818 (talk) 16:05, 29 January 2022 (UTC)
  • To respond to those saying we should "trust functionaries" - that attitude is simply naive. "Who watches the watchmen?" It's a basic principle of human nature that oversight needs oversight. Everyone needs accountability, no-one is perfectly trustworthy, and even if they were, it doesn't hurt to prove it. ··gracefool 22:13, 4 February 2022 (UTC)
    We should trust them, because they have got to where they are by showing that they are suitable for the role by many years of work and have earned the trust granted to them over years, and often more than a decade of service. They will have been through community approval (such as Request for Adminship), likely several times over. Their real identities are all known by the WMF as well. Mako001 (talk) 03:16, 5 February 2022 (UTC)
    I don't think access logs imply distrust of functionaries, but just in case. Do you think CU logs are unnecessary too? Lt2818 (talk) 05:10, 5 February 2022 (UTC)
    This, essentially. It's not like there haven't been cases of CU abuse/misuse either, and viewing oversighted material certainly has potential for abuse. ~~~~
    User:1234qwer1234qwer4 (talk)
    20:22, 7 February 2022 (UTC)

Voting

  •   Support --NGC 54 (talkcontribs) 22:55, 28 January 2022 (UTC)
  •   Oppose OOS for Community Wishlist, why not just report via ca wikimedia.org for abusing of Oversight rights? --Liuxinyu970226 (talk) 07:50, 29 January 2022 (UTC)
  •   Support After my edit suggestion, I think I do not understand about the proposal. It would mean to limit the abuse, with the abuse reported to ca wikimedia.org. Thingofme (talk) 14:09, 29 January 2022 (UTC)
  •   Support As a rule, where abuse is possible some method of review/oversight should be available. François Robere (talk) 11:56, 30 January 2022 (UTC)
  •   Oppose Per Liuxinyu. If we can't trust functionaries then no one else. NguoiDungKhongDinhDanh 12:01, 30 January 2022 (UTC)
  •   Oppose Per Liuxinyu --g (talk) 14:51, 30 January 2022 (UTC)
  •   Oppose Do we trust people chosen by ourselves or not? --L736Etell me 15:07, 30 January 2022 (UTC)
  •   Oppose Liuxinyu said well. --LittleWhites (talk) 15:12, 30 January 2022 (UTC)
  •   Oppose Hors sujet Bub's (talk) 20:35, 30 January 2022 (UTC)
  •   Support Theamigakiller (talk) 09:00, 31 January 2022 (UTC)
  •   Support JuanGLP (talk) 15:02, 31 January 2022 (UTC)
  •   Support XavierItzm (talk) 20:07, 1 February 2022 (UTC)
  •   Support I think it can be usefull.--Andriy.v (talk) 23:53, 1 February 2022 (UTC)
  •   Support KingAntenor (talk) 05:59, 2 February 2022 (UTC)
  •   Support ··gracefool 21:45, 4 February 2022 (UTC)
  •   Support ·addshore· talk to me! 22:37, 4 February 2022 (UTC)
  •   Support Mere good sense. - Darwin Ahoy! 01:56, 5 February 2022 (UTC)
  •   Oppose This and any derivative of it, would, first, risk undermining the privacy policy (and could actually expose the WMF to legal issues). Second, functionaries have got to where they are by years of valuable contributions, and have earned the community trust over many years. They will have been in the hotseat to obtain community approval several times, and are by far the most universally trusted users. This is at best, unnecessary, and at worst, harmful. Mako001 (talk) 03:26, 5 February 2022 (UTC)
  •   Support Ayumu Ozaki (talk) 23:45, 5 February 2022 (UTC)
  •   Support --Ciao • Bestoernesto 02:31, 6 February 2022 (UTC)
  •   Oppose for the privacy reasons raised above, but also because we don't need our CUs hesitating over every action in case they get dragged to some noticeboard by a disgruntled troll. SpinningSpark 12:48, 6 February 2022 (UTC)
  •   Support Trust is good, control is better Bas dehaan (talk) 23:08, 6 February 2022 (UTC)
  •   Support I'm surprised this doesn't exist yet. A private list that logs views of oversighted data makes sense for the same reason that a private list of CU views. There have been cases of checkusers loosing the tools because of misuse, so the argument that no-one needs to watch the watchmen doesn't apply even in practice. Uanfala (talk) 15:47, 7 February 2022 (UTC)
  •   Support I was quite surprised recently when I found out that this didn't exist yet, and Uanfala pretty much sums up what I was going to say. Also, "no need to watch the watchmen" is objectively not consistent with procedures of projects having an arbcom or comparable institution. ~~~~
    User:1234qwer1234qwer4 (talk)
    20:30, 7 February 2022 (UTC)
  •   SupportTheDJ (talkcontribs) 22:02, 7 February 2022 (UTC)
  •   Support a private log of views of OS data. We have had cases of private information misuse by editors in very high positions in the past. A tool for accountability is not the same thing as distrust. — Bilorv (talk) 12:29, 9 February 2022 (UTC)
  •   Support Prawdziwy Mikołajek (talk) 17:39, 9 February 2022 (UTC)
  •   Support Sunpriat (talk) 22:55, 10 February 2022 (UTC)
  • I can't tell whether this is suggesting that the log (including info on if a lookup happened at all, not just the contents) would be only visible to the relevant functionaries. If so, then   Support and I'm also surprised this doesn't already exist. --Yair rand (talk) 23:39, 10 February 2022 (UTC)
  •   Oppose We trust our institutions for a reason ;). Nadzik (talk) 13:54, 11 February 2022 (UTC)

Expose more detailed diff information to the AbuseFilter

  • Problem: The level of "diff" information accessible in AbuseFilter is too crude. Therefore, many forms of vandalism cannot be correctly captured. An example is word-swapping vandalism where the same word may exist elsewhere in the same line or paragraph.
  • Proposed solution: Some proposal has already been proposed in phab:T220764
  • Who would benefit: Wikis using AbuseFilter to fight vandalism
  • More comments: This is a rather specific proposal, so those who are unfamiliar with AbuseFilter and its limitations may not fully appreciate it. Fewer supporters may exist for this compared to some more generically defined proposals. I hope that is considered when comparing proposals.
  • Phabricator tickets: phab:T220764
  • Proposer: Huji (talk) 00:58, 11 January 2022 (UTC)

Discussion

  • I recently stumbled on an unusual interaction in the AbuseFilter extension which resulted in an accidental block. When moving a link around from one paragraph to another, the link is added to added_lines, but is not added to added_links. Improvements to AbuseFilter are most welcome! —Ivi104 02:21, 11 January 2022 (UTC)
    AbuseFilter in enwiki and some wikis have the block options disabled, as community consensus think that the filter hits should be reviewed by a human for vandalism. However, this feature is sometimes too crude and can't be watched. I also think AbuseFilter should have more types of conditions. Thingofme (talk) 02:51, 11 January 2022 (UTC)
  • As an admin who reviews filter reports a lot at AIV, I would say that the best opportunity for improvement lies with those who write the individual filters, not the extension. Daniel Case (talk) 05:28, 11 January 2022 (UTC)
  • I just wrote Community_Wishlist_Survey_2022/Admins_and_patrollers/Expose_ORES_scores_in_AbuseFilter. While there is no overlap, I believe the two proposals are closely related.--Strainu (talk) 16:21, 11 January 2022 (UTC)
    Agreed; they are closely related, and I find that to be a good idea too. The distinction is, this is something for which we have a clear path forward, but the ORES proposal has some timeliness issues for which we don't have a good answer yet. Huji (talk) 01:40, 12 January 2022 (UTC)
  • @Huji: Thank you for proposing this. In order to better understand what you are saying I have a few questions I would like to ask you. Please keep in mind that I don't write abuse filters myself:
  1. Wouldn't word swapping be easily identifiable by looking at the diff size?
  2. If the problem you are trying to solve is to better identify what was changed that triggered the filter, wouldn't looking at the diff itself be more helpful instead of sifting through the variables table?
  3. The phab task proposes a solution by adding new variables (words added/removed). How will this be useful in edits that expand multiple lines when trying to identify word swapping?
  4. Is there any other use case that is not covered by the current variables/functions that will benefit from these variables? If you can provide examples that would be great
Also, could you please update the phab task with a working link? The current one does not work anymore. DMaza (WMF) (talk) 16:55, 14 January 2022 (UTC)
@DMaza (WMF): great questions!
  1. Not necessarily. An example is the swapping of words "Kurd" and "Turk" (well, actually, the Persian words کرد and ترک respectively) which happens a lot on fawiki. They are same length words, so diff size is 0. Using logic like added_lines rlike 'Kurd' & removed_lines rlike 'Turk' won't cut it either because the rest of the paragraph could (and often does) include the words Kurd and Turk as well. We have vandals who specifically do word swaps. In a diff, we can see exactly which word was swapped (this diff shows that "a" was replaced with "some") but in AbuseFilter we don't have a corresponding variable. What I am thinking is something like added_words or added_characters, in addition to the line-level added_lines which we already have.
  2. Yes, except the diff-related variables in AbuseFilter are also at the line level, not the phrase level. Further below, I have pasted what edit_diff's value would look like for the diff I linked above; you will note that even in these variables, you still don't see the words "a" and "some" distnguished in anyway that can be used programmatically in an AbuseFilter. Essentially, we have capabilities in MW diff which we don't expose in AbuseFilter at all.
  3. In the diff example above (or the Kurd/Turk actual example) you could look for added_words contains 'Kurd' & removed_words contains 'Turk' (here I assume added_words and removed_words are arrays.
  4. Many of the use cases that are currently using added_lines or removed_lines may benefit from using these new proposed variables in addition to or instead of the existing variables. Huji (talk) 19:17, 14 January 2022 (UTC)
; edit_diff
'@@ -1,1 +1,1 @@
-Here is a word in a sentence.
+Here is some word in a sentence.
'
  • The team that is now working on IP hiding was working on edit filter improvements. Not sure where those went or if they simply finished what they were working on. --Izno (talk) 00:26, 17 January 2022 (UTC)
    If I recall correctly, they stopped improving edit filters in favor of the partial blocking feature. In the meantime, some improvements were done by Daimona and me. We were close implementing this, but we did not do it: phab:T220764#6806614. --Matěj Suchánek (talk) 10:44, 17 January 2022 (UTC)
  • As I wrote on Community Wishlist Survey 2022/Archive/Purely adding keywards on Abusefilter, diffs in detail (e.g. words) would help us. However, splitting a sentence into words could be difficult in some languages, especially which doesn't use spaces to split words. So I worry about the quality of the algorithm. We wouldn't use the new variables for wording diffs if they give us many false positives/negatives.
    Here, I strongly recommended implementing an alternative method to accurate detection at the same time you implement the algorithm to extract word diffs. One idea is just making contains_any() support array of keywords as its arguments (i.e. keywords := ["keywordA", "keywordB", "keywordC"]; contains_any(added_lines, keywords), which currently supports only variadic arguments contains_any(added_lines, "keywordA", "keywordB", "keywordC"). This simple method is enough to detect added words with checking the diff between added_lines and removed_lines (i.e. contains_any(added_lines, "A") & !contains_any(removed_lines, "A") can detect adding word "A"). --aokomoriuta (talk) 03:59, 29 January 2022 (UTC)

Voting

Allowing user to change own userpage or user subpages content model

  • Problem: Currently, no one other than the administrator can change the content model of a page, if a user wants to change the content of his or her own user pages or subpages, then he/her has need ask a administrator to do it. If given the opportunity to do so, it will be possible to do various tasks including template development through user namespace page. This feature can only be added to Autoconfirmed users to avoid abuse.
  • Proposed solution: Allowing user to change own userpage or user subpages content model
  • Who would benefit: All users
  • More comments:
  • Phabricator tickets:
  • Proposer: MdsShakil (talk) 05:01, 14 January 2022 (UTC)

Discussion

  • @MdsShakil: Could you explain a bit more about what the problem is? You mention being able to develop templates in the user namespace, but this should already be possible via transcluding an absolute page name (e.g. {{:User:MdsShakil/TestTemplate}}). Also, content models of certain pages are already set correctly: if you try to create a .css or .json subpage for instance, it'll be of the correct content type. As for changing the content model of a user page itself, I'm not sure I see the point of that; could you explain more? Thanks! — SWilson (WMF) (talk) 07:37, 14 January 2022 (UTC)
    @SWilson (WMF) Yes, using .css starts CSS pages but sometimes they need be changed to Sanitized CSS. Also, this will help create MassMessageListContent in the user namespace and creating Json pages without .json. -- MdsShakil (talk) 08:35, 14 January 2022 (UTC)
    Regarding the massmessage content model, phab:T92795 is looking to solve that part. — xaosflux Talk 00:22, 15 January 2022 (UTC)
    Agreed: more detail, please (and example/s?) --Aboudaqn (talk) 20:22, 28 January 2022 (UTC)
  • phab:T85847 seems relevant and maybe should be done instead (for autoconfirmed users maybe). I know that some wikis like English Wikipedia have gotten consensus to add change content model right to non-admin user groups (like template editor). But both this proposal and the task are maybe just consensus needed.... not sure if this one just needs a push or not. --Izno (talk) 22:50, 22 January 2022 (UTC)
    agreed but i think all users with AutoPatrol level-access is better, to avoid misuse/abuse; cuz getting autoconfirmed user right is easy and it doesn't take much for anyone to get it. 🌸 Sakura emad 💖 (talk) 17:52, 29 January 2022 (UTC)
    @Sakura emad: Lots of wiki has no user group like as autopatrol, this right is only able to change own userpage or user subpages content model so i think that is not necessary. --MdsShakil (talk) 04:01, 5 February 2022 (UTC)
  • Potential for abuse should be considered, since autoconfirmed is easy to get and personal JS/CSS can only be edited by interface administrators. Current AbuseFilters might apply stricter conditions to pages based on their titles (such as matching \.(js|css)), which would not work if arbitrary userspace pages' content models could be changed by their owners. ~~~~
    User:1234qwer1234qwer4 (talk)
    19:58, 7 February 2022 (UTC)

Voting

Styling for globally locked users

  • Problem: (1) Given a category of user or user talk pages, determine which have or have not been globally locked. (2) Given a page (e.g. a sockpuppet investigation page), somehow highlight accounts that have been globally locked.
  • Proposed solution: It is not possible to determine efficiently whether a list of accounts has been locked. It is now one API request per user, instead of the 1 request for 50 or even 500 users. Solve the API problem and gadget writers can do the rest.
  • Who would benefit: Stewards, those dealing with cross-wiki sockpuppets and spam, admins who deal with block appeals, etc. Also a small reduction in the amount of cross-wiki abuse.
  • More comments:
  • Phabricator tickets: phab:T261752 phab:T237505
  • Proposer: MER-C 19:56, 13 January 2022 (UTC)

Discussion

  • Personally, I think we should have a blocklist and a lock list of all globally blocked IPs and locked users. The list can't be found in any special pages. And I think we need to have the ability to lock users with an expiration (so a lot of proposals about global blocking for accounts). Thingofme (talk) 08:44, 14 January 2022 (UTC)
    @Thingofme: Special:GlobalBlockList is a list of all global blocks. — xaosflux Talk 19:10, 14 January 2022 (UTC)
    What about list of global locks? The list only represent logs, not represent like the list of local blocks, and so it's not having a table-styled list. Thingofme (talk) 09:43, 15 January 2022 (UTC)
    I didn't say it solved all the problems :) — xaosflux Talk 12:37, 15 January 2022 (UTC)
    There is a phabricator proposals about only global blocking the accounts, and that mean users can log into the account and receive an error of not able to edit in Wikimedia wikis. Can't log in is too much. We want to prevent editing, not logging in. Thingofme (talk) 15:35, 15 January 2022 (UTC)
    @Thingofme: we who? Locking exists explicitly to prevent logging on. If you want to talk about creating "global blocks" for accounts - please open another item, and reference phab:T17294. — xaosflux Talk 01:04, 17 January 2022 (UTC)
  • A user script for this exists already at en:User:GeneralNotability/mark-locked.js, no? --Izno (talk) 00:28, 17 January 2022 (UTC)
  • Highlighting locked users should not be added as a regular feature if highlighting blocked ones isn't, and both are currently already implemented by well-functioning user scripts/gadgets (see Izno above and mediawiki:Gadget-markblocked.js respectively). ~~~~
    User:1234qwer1234qwer4 (talk)
    19:33, 7 February 2022 (UTC)

Voting

Add variables in AbuseFilter to detect/block thanks

  • Problem: There is no way in AbuseFilter to detect uses of the "thanks" feature. This feature can be abused in order to harass editors. It is possible to mute a spectific account, but when the harasser uses a lot of accounts, the editor targeted by harasser has no other choice than disabling the whole thanks feature.
  • Proposed solution: Create thanks feature related variables, which could be "thanks sender username" and "thanks recipient username" for example.
  • Who would benefit: AbuseFilter editors, harassed editors
  • More comments:
  • Phabricator tickets: phab:T235873
  • Proposer: — Jules* Talk 10:14, 23 January 2022 (UTC)

Discussion

  • Erratum: I wrote in the proposal that variables "could be thanks sender username and thanks recipient username". We already have a user_name variable in AbuseFilter (for the user who does the action), so we only need a thanked user variable. This would allow to prevent harassment using thanks feature. — Jules* Talk 09:34, 30 January 2022 (UTC)
  • How are users harassed using the thanks feature? Just curious. AWESOMEDUDE0614 (talk) 16:17, 31 January 2022 (UTC)
    Multiple accounts (sometimes with identity theft, insults, threats, etc. in their username) are created to thank multiple times an editor. — Jules* Talk 13:06, 1 February 2022 (UTC)
    For clarification: spamming notifications. ~~~~
    User:1234qwer1234qwer4 (talk)
    19:35, 7 February 2022 (UTC)

Voting

  •   Support KylieTastic (talk) 19:15, 28 January 2022 (UTC)
  •   Support CrystalLemonade (talk) 19:40, 28 January 2022 (UTC)
  •   Support Not sure if AbuseFilter is right tool for this, but thanks-spam should be handled somehow Zache (talk) 20:43, 28 January 2022 (UTC)
  •   Support Using 'thanks' feature was a mean of harassment in pl.wiki before. Something should be done to limit the possibility of using this feature to harass other users. Wostr (talk) 20:46, 28 January 2022 (UTC)
  •   Support — Draceane talkcontrib. 22:57, 28 January 2022 (UTC)
  •   Support --𝑇𝑚𝑣 (𝑡𝑎𝑙𝑘) 00:42, 29 January 2022 (UTC)
  •   Support Lectrician1 (talk) 01:56, 29 January 2022 (UTC)
  •   Support Aca (talk) 12:08, 29 January 2022 (UTC)
  •   Support Thingofme (talk) 14:04, 29 January 2022 (UTC)
  •   Support BSMIsEditing (talk) 15:00, 29 January 2022 (UTC)
  •   Support NguoiDungKhongDinhDanh 15:10, 29 January 2022 (UTC)
  •   Support Ali Imran Awan (talk) 07:09, 30 January 2022 (UTC)
  •   Support —— Eric LiuTalk 07:51, 30 January 2022 (UTC)
  •   Support A09090091 (talk) 07:57, 30 January 2022 (UTC)
  •   Support Also blocking "thanks" in the block options could be useful for those users that abuse it. Ruthven (msg) 15:02, 30 January 2022 (UTC)
  •   Support Titore (talk) 17:01, 30 January 2022 (UTC)
  •   Support KevinL (aka L235 · t) 20:48, 30 January 2022 (UTC)
  •   Support I noticed this about the "thanks" feature a while back -- it seems like you can just send an arbitrary number of them to someone, with nothing beyond a rudimentary ratelimit, and I don't think there is any way for someone to block them (aside from disabling the feature entirely, I think). They're great, and they have improved my editing experience, but I think that this vulnerability should be fixed. JPxG (talk) 00:26, 31 January 2022 (UTC)
    @JPxG As stated in the description, muting the account sending the thanks from your preferences will stop the notifications. ~~~~
    User:1234qwer1234qwer4 (talk)
    22:47, 9 February 2022 (UTC)
  •   Support Trizek from FR 11:56, 31 January 2022 (UTC)
  •   Support Dreamy Jazz talk to me | enwiki 14:21, 31 January 2022 (UTC)
  •   Support Sargento - A sus órdenes 21:08, 31 January 2022 (UTC)
  •   Support H78c67c (talk) 04:18, 1 February 2022 (UTC)
  •   Support LD (talk) 13:02, 1 February 2022 (UTC)
  •   Support Thanks, EDG 543 (message me) 14:31, 1 February 2022 (UTC)
  •   Support LTAs clearly abuse this feature. Thibaut (talk) 15:47, 1 February 2022 (UTC)
  •   Support --Andriy.v (talk) 23:51, 1 February 2022 (UTC)
  •   Support ~ Amory (utc) 20:38, 2 February 2022 (UTC)
  •   Support DannyS712 (talk) 03:05, 3 February 2022 (UTC)
  •   Support Bibeyjj (talk) 20:06, 4 February 2022 (UTC)
  •   Support - Darwin Ahoy! 21:31, 4 February 2022 (UTC)
  •   Support paul2520 (talk) 02:31, 5 February 2022 (UTC)
  •   Support JavaHurricane 10:39, 5 February 2022 (UTC)
  •   SupportThanks for the fish! talkcontrib (he/him) 17:35, 5 February 2022 (UTC)
  •   Support Ayumu Ozaki (talk) 03:02, 6 February 2022 (UTC)
  •   Support --Liuxinyu970226 (talk) 03:41, 6 February 2022 (UTC)
  •   Support Estoy de acuerdo con la propuesta Windows 77770 (talk) 02:46, 7 February 2022 (UTC)
  •   Support Untitled.docx (talk) 15:25, 7 February 2022 (UTC)
  •   Support Em-mustapha talk 17:47, 7 February 2022 (UTC)
  •   Support ruwiki has an advanced bot to automatically block accounts abusing this feature, but having this as an AbuseFilter action would be way easier. (There might be more actions that would be useful if added to the extension.) ~~~~
    User:1234qwer1234qwer4 (talk)
    19:41, 7 February 2022 (UTC)
  •   Support ~Cybularny Speak? 20:01, 7 February 2022 (UTC)
  •   Support Barkeep49 (talk) 22:28, 7 February 2022 (UTC)
  •   Support KnowledgeablePersona (talk) 23:20, 8 February 2022 (UTC)
  •   SupportBilorv (talk) 12:17, 9 February 2022 (UTC)
  •   Support Juan90264 (talk) 13:51, 9 February 2022 (UTC)
  •   Support evrifaessa ❯❯❯ talk 15:40, 11 February 2022 (UTC)
  •   Support Nehaoua (talk) 16:23, 11 February 2022 (UTC)

Split up blockedtext into different messages for username block, and IP block and for an IP range block

  • Problem: All blocked users are displayed the same block message (MediaWiki:Blockedtext) regardless of whether they are registered or unregistered contributors. This is problematic and does not allow to give blocked users specific instructions based on the block they're facing.
  • Proposed solution: Split up MediaWiki:Blockedtext into different messages for unregistered contributors and registered contributors.
  • Who would benefit: Blocked users, giving them the right directions based on the block type (e.g., it makes no sense to advertise for unregistered contributors that they can "email $1" when they can't technically do so).
  • More comments: Partly done for composite blocks (multiple blocks affecting an IP/IP range) and for partial blocks. See system messages. Done already for global blocks. For Wikimedia wikis, if needed, they could probably be further customised via WikimediaMessages overrides (if there's a need to do so).
  • Phabricator tickets: task T60858
  • Proposer: —MarcoAurelio (talk) 10:41, 20 January 2022 (UTC)

Discussion

  • FYI, this is also already done on enwiki; we show different text for IP blocks and user blocks by parsing the string for what is blocked ({{#if:{{#invoke:IPAddress|isIpOrRange|{{{7|$7}}}}}). Best, KevinL (aka L235 · t) 20:50, 30 January 2022 (UTC)

Voting

Notifications for user page edits

  • Problem: If your user page is modified by a malicious user, you may not notice if your watchlist is overflowed. Unlike a normal article, it is very unlikely that another user will revert or warn about the malicious changes for you. Unlike article vandalism, user page vandalism can affect the unwitting user's standing in the community.
  • Proposed solution: Generate notifications for user page modifications by other users, just like user talk notifications work now. Another solution would be to protect user pages from modification, but some edits may be friendly and even useful.
  • Who would benefit: Users whose user page has been vandalized.
  • More comments: It could be made configurable per user.
  • Phabricator tickets: phab:T3876
  • Proposer: Error (talk) 10:49, 13 January 2022 (UTC)

Discussion

  • Related to phab:T176351 (for the protection part). Note, some projects use abusefilter to add some protections to base userpages already as well. — xaosflux Talk 11:37, 13 January 2022 (UTC)
    Yes, however blocked users, new users should have the userpage editable as, I think to mark sockpuppets and banned users. Meta already has this, but I have problems when marking problematic userpages for deletion. Thingofme (talk) 10:48, 15 January 2022 (UTC)
  • This is a nice wish which should be very easy to deploy and should ease our fight against harassment. A single notification when someone, whoever, modify your user page seems fairly reasonable. Xavier Dengra (MESSAGES) 00:01, 22 January 2022 (UTC)
  • I'm not a fan of blocking such edits entirely (many may be in good-faith, even if by IPs, e.g. in user space TODO or cleanup lists) but getting a notification should definitely be the default. I would add that page creations in another user's user space should also generate a notification for that user. Fytcha (talk) 18:48, 25 January 2022 (UTC)
  • A notification would be nice, certainly. I'm not sure I'd want it to be the orange bar of doom, though. A few times in the past, I've done something like fixing a typo on someone else's userpage, and I might be less likely to do that if I knew it'd give them a big dramatic alert. {{u|Sdkb}}talk 18:50, 28 January 2022 (UTC)
  • Or: redo the watchlist so that pages can be categorized, sorted, or assigned levels of importance. This is an important tool for editors - why should so many find it unusable? François Robere (talk) 12:01, 30 January 2022 (UTC)
  • This proposal inspire me an idea for the watchlist, as per the idea above, a kind of levelled watchlist, with different level of notifications. E.g. it would be useful in the case of overflowed watchlists to chose some pages of which we want a more visible notification within the watchlist when these have been modified. By showing the corresponding notifications in the current watchlist with an additional section "pages to monitor first", or "important pages" or "priority pages", ect... Christian Ferrer (talk) 12:03, 30 January 2022 (UTC)

Voting

Allow all registered users the right to semi-protect their own user and talk pages

  • Problem: Vandals, and other disruptive users, sometimes maliciously edit the user and talk pages of individual users who have reported them or otherwise dealt with them. Those who are administrators have the ability (and some of us have used this) to semi-protect their personal pages. But users without this right must ask for it to be done, which can lead some of them (I think) not to do it at all because they may not want to wait, and may be afraid their request would be denied.
  • Proposed solution: Allow registered users past a certain number of edits the right to semi-protect their user and talk pages as they see fit.
  • Who would benefit: All users, as it would really make for safer personal space for everyone.
  • More comments:
  • Phabricator tickets:
  • Proposer: Daniel Case (talk) 03:21, 23 January 2022 (UTC)

Discussion

  • User talk pages should get protected only for limited durations to deal with actual instances of vandalism or harassment. We can't expect all users to be aware of the expectations around page protection, so we shouldn't be giving them the tools to do it. For user pages, on the other hand, this seems to make sense, but I'm wondering if it won't be better to have it as a feature that's default for everyone, so that, for example, only registered users will be able to edit user pages. Uanfala (talk) 15:34, 7 February 2022 (UTC)
    @Uanfala Is this a vote? If so please use the {{support}} or similar template if you want your vote to count :) Thanks! MusikAnimal (WMF) (talk) 16:52, 7 February 2022 (UTC)
    It was more a neutral comment. Is it in the wrong section? Uanfala (talk) 21:04, 7 February 2022 (UTC)
    Ideally it's better put in the "Discussion" section if it's just a comment. I've moved it there. Hope that's okay :) Thanks, MusikAnimal (WMF) (talk) 15:47, 8 February 2022 (UTC)

Voting

  •   Support MrMisterer (talk) 18:37, 28 January 2022 (UTC)
  •   Support --Mpnader (talk) 18:52, 28 January 2022 (UTC)
  •   Support Meditating (talk) 18:53, 28 January 2022 (UTC)
  •   Support Taivo (talk) 19:10, 28 January 2022 (UTC)
  •   Support Franzekafka (talk) 19:37, 28 January 2022 (UTC)
  •   Support CrystalLemonade (talk) 19:38, 28 January 2022 (UTC)
  •   Support sounds great! Aboudaqn (talk) 20:23, 28 January 2022 (UTC)
  •   It is doubtful --Kusurija (talk) 20:54, 28 January 2022 (UTC)
  •   Support User pages, yes, talk pages, no. IP editing remains a large portion of WIkimedia editing, and not allowing them to contact other users could pose a serious issue. If needed, they could always request talk page protection, but I don't think it should be given out like free candy. Sea Cow (talk) 22:09, 28 January 2022 (UTC)
  •   Oppose potential for abuse and sets a precedent for non-admins doing admin actions. You can always request protection. Sea Cow's comments are also relevant. EpicPupper (talk) 22:34, 28 January 2022 (UTC)
  •   Support LevandeMänniska (talk) 22:47, 28 January 2022 (UTC)
  •   Oppose Never talk pages! — Em-mustapha talk 23:01, 28 January 2022 (UTC)
  •   Support But only on the user page. --𝑇𝑚𝑣 (𝑡𝑎𝑙𝑘) 00:45, 29 January 2022 (UTC)
  •   Support Betseg (talk) 01:58, 29 January 2022 (UTC)
  •   Support Gamekiller0010 (talk) 07:25, 29 January 2022 (UTC)
  •   Support For user pages only,   Oppose for user talk pages per EpicPupper. --Liuxinyu970226 (talk) 08:02, 29 January 2022 (UTC)
  •   Oppose for user talk pages. Graham11 (talk) 08:33, 29 January 2022 (UTC)
  •   Support for user pages (semi protection), as the only two reasons why non-autoconfirmed people would edit someone's elses userpage is either if they are trying to leave said user a message but are on the wrong page (this should be done on user talk: instead) or if they are a vandal and try to deface the userpage.   Oppose for user talk pages, as that can be used to hide from legitimate discussion, particularely if you edit in RC or other areas with many new editors. Victor Schmidt (talk) 09:23, 29 January 2022 (UTC)
  •   Strong oppose (on talk pages) – this has enormous potential to be used abusively or incorrectly, and for it to be used usefully by a user requires more knowledge and experience than most registered users (excluding sysops) have. Since this involves a permission change, would it not need global consensus? Giraffer (talk) 10:25, 29 January 2022 (UTC)
  •   Neutral Supporting for user pages and opposing for talk pages as per Victor Schmidt's reasons. DeeDeeEn (talk) 11:11, 29 January 2022 (UTC)
  •   Support Celerias (talk) 11:11, 29 January 2022 (UTC)
  •   Oppose in this version. But maybe some ideas will prompt my talk page in ruwiki. NBS (talk) 11:31, 29 January 2022 (UTC)
  •   Support Supporting for user pages and   Oppose opposing for talk pages — SHEIKH (Talk) 12:11, 29 January 2022 (UTC)
  •   Neutral – Support for user page locks, and oppose for talk page locks. — Aca (talk) 12:12, 29 January 2022 (UTC)
  •   Support for user pages (and subpages) and   Oppose for user talk pages. In metawiki and some wikis, there is an edit filter to ban standard users from editing others' user pages. Thingofme (talk) 14:06, 29 January 2022 (UTC)
  •   Support for user pages only lil-✝V!wanna talk?` 14:42, 29 January 2022 (UTC)
  •   Support BSMIsEditing (talk) 15:01, 29 January 2022 (UTC)
  •   Oppose as a cross-wiki patroller who don't have GR. NguoiDungKhongDinhDanh 15:18, 29 January 2022 (UTC)
  •   Oppose. Not talk pages. — Jules* Talk 18:05, 29 January 2022 (UTC)
  •   Support for User-Pages only 🌸 Sakura emad 💖 (talk) 18:07, 29 January 2022 (UTC)
  •   Support for user pages (and subpages). However, I   Strong oppose user talk pages— I see an opportunity for abuse from vandalism-only accounts. Helen(💬📖) 20:06, 29 January 2022 (UTC)
    It would be semi-protection, not full. Long-term users and admins would be able to issue warnings, and new users (like the majority of VOAs) would be unable to do it. You could also make the semi-protection automatically revoke when blocked. Daniel Case (talk) 23:08, 1 February 2022 (UTC)
  •   Support Douglasfugazi (talk) 21:05, 29 January 2022 (UTC)
  •   Support User pages only though. Waddles 🗩 🖉 21:08, 29 January 2022 (UTC)
  •   Support Tonnegrande (talk) 05:20, 30 January 2022 (UTC)
  •   Oppose Reducing interaction reduces possibilities for community effort and consensus. Wikipedia is no one's private space. If someone violates rules, an admin can block them or restrict page editing.--Роман Рябенко (talk) 09:25, 30 January 2022 (UTC)
  •   Support all initiatives that help deflect harassment are welcome, and this one will make users feel 'locally empowered', which is good. But just for user pages, not talk page Sasha7272 (talk) 11:06, 30 January 2022 (UTC)
  •   Oppose abusable and, before that, only sysops evaluate and decide on the extraordinary exceptions to the freedom-of-editing principle; and yes, the principle is still valid even with vandals wandering into the projects and hordes of trolls wasting sysops' time --g (talk) 14:49, 30 January 2022 (UTC)
  •   Strong oppose This would be a way to encourage write-only behaviour, paves the way to easy abusing. --L736Etell me 15:08, 30 January 2022 (UTC)
  •   Oppose Is this the way we want pursue? Really? --LittleWhites (talk) 15:13, 30 January 2022 (UTC)
  •   Oppose do we have real hints this is a problem? I.e. the current system doesn't work? --Vituzzu (talk) 17:11, 30 January 2022 (UTC)
  •   Oppose per Роман Рябенко and L736E. --Phyrexian ɸ 21:15, 30 January 2022 (UTC)
  •   Strong oppose per L736E. --Mannivu · 11:51, 31 January 2022 (UTC)
  •   It is doubtful I see some harassment issues that could be resolved with this, but there is still this risk of a given user deliberately blocking their page to avoid others to tell them that they are doing things the wrong way. Trizek from FR 11:55, 31 January 2022 (UTC)
    Again, with semi-protection only, they're not going to be able to prevent most users from issuing warnings or giving friendly advice. Daniel Case (talk) 23:09, 1 February 2022 (UTC)
  •   Support For user pages Hb2007 (talk) 13:16, 31 January 2022 (UTC)
  •   Support only for userpages.   Oppose for user talk pages. Dreamy Jazz talk to me | enwiki 14:23, 31 January 2022 (UTC)
  •   Support only for userpages.   Oppose for user talk pages. --Havang(nl) (talk) 15:11, 31 January 2022 (UTC)
  •   Strong oppose Talk pages en:WP:IPAHT IAmChaos (talk) 17:54, 31 January 2022 (UTC)
  •   Strong oppose - this is a perennial proposal on enwikipedia. PorkchopGMX (on the go) (talk) 18:42, 31 January 2022 (UTC)
  •   Weak support only for userpages Glerium (talk) 12:16, 1 February 2022 (UTC)
  •   Support Thanks, EDG 543 (message me) 14:31, 1 February 2022 (UTC)
  •   Oppose Talk pages must be editable as long as that's the wiki way of communicating with users. User pages, OTOH, should by default be editable only by the respective user and administrators. Silver hr (talk) 16:33, 1 February 2022 (UTC)
  •   Support but user pages only Andriy.v (talk) 16:36, 1 February 2022 (UTC)
  •   Support but ONLY for EXTENDED CONFIRMED users and user pages only. NOT talk pages. InvadingInvader (talk) 17:36, 1 February 2022 (UTC)
  •   Support Akme (talk) 17:46, 1 February 2022 (UTC)
  •   Oppose There is risk of a given user deliberately blocking their page to avoid others to tell them that they are doing things the wrong way. XavierItzm (talk) 20:02, 1 February 2022 (UTC)
    Again, as I said above, that's why I'd limit this to semi-protection. It's not going to offer that kind of user much of a shield, if any, against that kind of contact. Daniel Case (talk) 23:11, 1 February 2022 (UTC)
  •   Support For user pages only. Nosferattus (talk) 02:30, 2 February 2022 (UTC)
  •   Support User pages only, not talk pages Specter Koen (talk) 05:23, 2 February 2022 (UTC)
  •   Support KingAntenor (talk) 05:56, 2 February 2022 (UTC)
  •   Support Kenyan105 (talk) 11:26, 2 February 2022 (UTC)
  •   Support for user page,   Oppose for user talk page. Clog Wolf (talk) 12:29, 2 February 2022 (UTC)
  •   Support for user page,   Oppose for user talk page. --Hampcky (talk) 15:03, 2 February 2022 (UTC)
  •   Support for user page,   Oppose for user talk page. — MrDolomite • Talk 04:40, 3 February 2022 (UTC)
  •   Support Good self police proposal makes sense Downspec (talk) 04:55, 3 February 2022 (UTC)
  •   Oppose for user talk pages. DanCherek (talk) 16:28, 3 February 2022 (UTC)
  •   Support for user page,   Oppose for user talk page as it is meant for communication. In case of harassment, the user can report to ANI noticeboards, and in case of persistent vandalism, the user can request for protection, which should only be done by an admin DaxServer (talk) 09:36, 4 February 2022 (UTC)
  •   Support Trkgs (talk) 10:06, 4 February 2022 (UTC)
  •   Support Good idea. AndreiK (talk) 18:44, 4 February 2022 (UTC)
  •   Oppose for talk pages.- Darwin Ahoy! 19:44, 4 February 2022 (UTC)
  •   Support Yoshi24517 (talk) 20:05, 4 February 2022 (UTC)
  •   Oppose Bibeyjj (talk) 20:08, 4 February 2022 (UTC)
  •   Support for user pages, Template:Oppose for talk pages: there is no need for an IP, or anyone else except an admin removing problematic content, to alter a user page, but plenty of reason for them to ask questions or comment on a user talk page. PamD (talk) 16:19, 5 February 2022 (UTC)
  •   Support Ayumu Ozaki (talk) 02:58, 6 February 2022 (UTC)
  •   Support Nkon21 (talk) 03:26, 6 February 2022 (UTC)
  •   Support for user pages Vulp❯❯❯here! 03:34, 6 February 2022 (UTC)
  •   Strong oppose for talk pages, that defeats the whole purpose of them.   Oppose for everything else. Editors don't own the pages in their userspace. Sometimes user pages need tagging for deletion for instance, and there's no reason to prevent IP editors from doing this. SpinningSpark 12:22, 6 February 2022 (UTC)
  •   Support Davidzundel (talk) 15:34, 6 February 2022 (UTC)
  •   Support Annablazeprobable (talk) 00:37, 7 February 2022 (UTC)
  •   Support Vamooooos Pablo131415 (talk) 11:02, 7 February 2022 (UTC)
    Perdón me refiero a que apoyo el proyecto y me parece fatal lo que hacen de editar maliciosamente. Pablo131415 (talk) 11:03, 7 February 2022 (UTC)
  •   Support Only user page, no talk page Ryse93 (talk) 12:20, 7 February 2022 (UTC)
  •   Support Fraguando (talk) 21:45, 7 February 2022 (UTC)
  •   Strong oppose In agreement with comments from EpicPupper, Giraffer, g, L736E, Роман Рябенко, Silver hr, Vituzzu, XavierItzm. Seems like a non-problem at the moment, has there been an issue with harassment via user/talk pages? Detsom (talk) 21:47, 7 February 2022 (UTC)
  •   Strong oppose for talk pages Suonii180 (talk) 19:15, 8 February 2022 (UTC)
  •   Support Only User Pages, not talk pages. KnowledgeablePersona (talk) 23:12, 8 February 2022 (UTC)
  •   Support Yes, but only for user pages - not user talk page. Euphoria42 (talk) 02:04, 9 February 2022 (UTC)
  •   Support 🙆, cool!~GѦrLξn JѲ (talk) 15:30, 9 February 2022 (UTC)
  •   Support Prawdziwy Mikołajek (talk) 17:40, 9 February 2022 (UTC)
  •   Support only for userpages.   Oppose for user talk pages. Andrei Romanenko (talk) 01:44, 10 February 2022 (UTC)
  •   Support This is the way. Havarhen (talk) 08:46, 10 February 2022 (UTC)
  •   Oppose This is clearly another form of IP Editing Restriction. This will worsen the overall situation by the fact that more often they will think that this is their own page and that no one should edit it at all (be more hostile to the edits of others on their pages. Because they put up protection themselves, they are already setting themselves up to be hostile to others. This is different from when there is some kind of global namespace protection or protection set by another). A few infrequent cases are not worth it. Sunpriat (talk) 22:31, 10 February 2022 (UTC)
  •   Oppose This would be a way to encourage write-only behaviour, paves the way to easy abusing Nadzik (talk) 13:53, 11 February 2022 (UTC)
  •   Oppose for user talk pages (more or less indifferent regarding userpages); "I don't need to talk to IPs" are already too common, and I fear this would exacerbate that problem. Blablubbs (talk) 14:44, 11 February 2022 (UTC)
  •   Oppose for talk pages. IP editors are human too.--evrifaessa ❯❯❯ talk 15:39, 11 February 2022 (UTC)

Further interaction blockers.

  • Problem: Currently, in MediaWiki, it is possible to mute someone's mention, and to block someone from sending email to personal email account, however there are no ways to prevent additional user interactions, for example writing on user talk pages, editing userspace drafts, or be pinged or be quoted on Phabricator.
  • Proposed solution: It is desirable to 1.) enhance the muting in these aspects, and 2.) integrate options of different form of interaction blocking to a single one for easier control.
  • Who would benefit: All users with an account and participate in editing behavior.
  • More comments:
  • Phabricator tickets:
  • Proposer: C933103 (talk) 03:54, 17 January 2022 (UTC)

Discussion

  • @C933103: It is currently possible for an administrator to block a user from editing a wiki (either specific namespaces or all pages), see mw:Help:Blocking_users. It is also possible to modify your Phabricator email preferences to decide when you get emails (see https://phabricator.wikimedia.org/settings/user/<username>/page/emailpreferences/). Are these satisfactory? Is there anything more you wanted? DWalden (WMF) (talk) 11:24, 17 January 2022 (UTC)
    Not really, as the proposal is to ask for additional ability on allowing users control who they do not want to interact with, as well as collecting these controls together in some accessible places like user preference, and neither of the two options can achieve this (they are either tools for administrators only or tools that do not focus on only some specific users. C933103 (talk) 21:57, 17 January 2022 (UTC)
    I would say this isn't really useful as it violates our Vision. Liuxinyu970226 (talk) 03:40, 20 January 2022 (UTC)
    How so? Regards, HaeB (talk) 14:45, 23 January 2022 (UTC)
    For context, see the list of interaction types that the English Wikipedia currently considers as covered by interaction bans (which are aimed at reducing conflict between two particular users). Regards, HaeB (talk) 14:45, 23 January 2022 (UTC)
    Such suggestions are very like some years ago, German Wikipedia's suggestion that to automatically remove the "Thanks" log, then, not only that suggestion is rejected, but also results the first entry of Limits_to_configuration_changes#Prohibited_changes. Liuxinyu970226 (talk) 12:26, 28 January 2022 (UTC)
  • Is it actually desirable to enable muting? It seems to me that pervasive blocking features make social media a more antisocial place, because so many people block others for mere disagreement, or for calling them out for breaking rules or actual trolling etc. This will absolutely be abused. ··gracefool 22:01, 4 February 2022 (UTC)
    Most social media site allow users to block spam or harassing message at the same time the behavior is reported to platform administrators. I think it make sense that on non-content and non-public-discussion pages, parties with behavior who the user feel undesirable can block those on private pages. I am not and would not suggest this to replace the full interaction block as outlined in wiki punishment as that would also be impossible to enforce and hurt cooperation, however 1-to-1 interactions should be optional.
    If there are concern on system abuse by spammer who block people from warning them on bad behavior, then perhaps exemption can be created for administrators and bureaucrats and make them unblockable from such system.C933103 (talk) 14:59, 5 February 2022 (UTC)
    @C933103 That's why however we shouldn't do so on MediaWiki, as per w:WP:SNS. Liuxinyu970226 (talk) 05:11, 7 February 2022 (UTC)
    I would like to add that my comment was about the model of which interaction can be deal with, not that Wikimedia projects should function like social media sites. As I have specifically suggested the limitation in scope of the wish.C933103 (talk) 13:01, 7 February 2022 (UTC)
  • Question. Why do you want to reduce interaction in such form? There is a frustration behind this request that should be understood. What are the kind of contents you do not like to see? --Valerio Bozzolan (talk) 14:29, 11 February 2022 (UTC)
    It takes time for abusive behavior from one user against another on Wiki to be dealt with by administrator, and such tool would be needed by the target user to disable such sort of abusive behavior before administrators can finish processing relevant cases of abuse. Otherwise such form of abuse could continues until no ends. C933103 (talk) 00:04, 13 February 2022 (UTC)

Voting

  •   Support - STSC (talk) 04:57, 29 January 2022 (UTC)
  •   Oppose Explaned above, MediaWiki isn't a platform for transparency. --Liuxinyu970226 (talk) 07:49, 29 January 2022 (UTC)
  •   Oppose Only for Phabricator admins can block them from editing. You can contact other admins in wikis, or contact stewards at SRG. Thingofme (talk) 14:03, 29 January 2022 (UTC)
  •   Support OwenBlacker (Talk) 21:57, 29 January 2022 (UTC)
  •   Oppose Reducing interaction reduces possibilities for community effort and consensus. Wikipedia is no one's private space. If someone violates rules, an admin can block them or restrict page editing.--Роман Рябенко (talk) 09:21, 30 January 2022 (UTC)
  •   Support MW is used, among others, as a social network, so it needs to have a centralized interface and more configuration options for controlling potentially-disruptive interactions. François Robere (talk) 11:49, 30 January 2022 (UTC)
    @François Robere MediaWiki isn't a social network, please, don't be a jerk. Liuxinyu970226 (talk) 03:36, 6 February 2022 (UTC)
    @Liuxinyu970226: I didn't say it is, I said it is used as one. Watchable user pages, pings and personal messages are characteristic of social networks, and editors do use them for social purposes in addition to "professional" ones. François Robere (talk) 11:04, 6 February 2022 (UTC)
  •   Oppose the most likely effect imho would be good faith patrollers being forbidden to leave their warnings in vandals'/trolls' talk page (in case sysops are block-exempt, which is not yet clear) --g (talk) 14:40, 30 January 2022 (UTC)
  •   Oppose If someone violates the rules, we have enough tools to react. This is useless if not dangerous as users before me already pointed out.--L736Etell me 15:02, 30 January 2022 (UTC)
  •   Oppose per L736E. --LittleWhites (talk) 15:15, 30 January 2022 (UTC)
  •   Oppose per Роман Рябенко. --Phyrexian ɸ 21:13, 30 January 2022 (UTC)
  •   Oppose per Роман Рябенко. --Sannita - not just another it.wiki sysop 11:58, 31 January 2022 (UTC)
  •   Oppose --Havang(nl) (talk) 15:09, 31 January 2022 (UTC)
  •   Oppose per L736E. --Andriy.v (talk) 17:01, 1 February 2022 (UTC)
  •   Oppose as explained above. ··gracefool 22:01, 4 February 2022 (UTC)
  •   Support --Ciao • Bestoernesto 02:29, 6 February 2022 (UTC)
  •   Oppose This would enable users to prevent warning messages and other vital communications. Other editors would lose visibility that the editor had been disruptive. Harrasment should be dealt with directly, not by muting. SpinningSpark 12:15, 6 February 2022 (UTC)
  •   Support Havarhen (talk) 08:48, 10 February 2022 (UTC)
  •   Oppose per above. --SHB2000 (talk | contribs) 11:57, 11 February 2022 (UTC)