- User Since
- Mar 18 2017, 8:10 PM (325 w, 6 h)
- LDAP User
- MediaWiki User
- SPoore (WMF) [ Global Accounts ]
May 18 2021
Aug 20 2020
@Niharika @jwang @drochford It would be good for us to get this data out to the communities. Maybe a blog post?
Feb 21 2020
@DannyS712 I appreciate the work that you put into improving the logging of blocks. I agree with @Niharika that there needs to be a target wiki(s) that are interested in implementing this change. Through a Rfc or other type discussion, they will need to weight the pros and cons of this design and be ready to put into place by updating their their local policies about logging blocks. Special:Block is a widely used feature and it is important to have very broad input about the benefits of making the change.
Dec 10 2019
Good news. We just finished writing and proofreading the proposal. Voting phase has finally started!
Jul 19 2019
Apr 9 2019
@Niharika that sound like a good idea. Also, each of the test wikis has a page that describes pb and the questions that we are trying to answer with the testing. The talk page this page is likely to be where we will get the most feedback.
Apr 8 2019
Apr 5 2019
@MarcoAurelio @DerHexer Let me try to answer as to why the original plan was to remove partial blocks from Special:CentralAuth and also reassure you that your feedback is essential for having the block feature work well for all necessary workflows that use it. So thank you for commenting.
Apr 2 2019
@dbarratt the current steps reflect a combination of the conditions when it is normal practice (acceptable) to suppress a user account name and lists, and the usual workflows. that are used.
Mar 28 2019
Mar 26 2019
@Niharika another option is to have a special page for partial block feedback that is linked to from the main feedback page.
@Niharika that is a very good question. I suppose that we could link to the general page and ask for targeted feedback about partial blocks, but leave space for other feedback. https://meta.wikimedia.org/wiki/Community_health_initiative/Blocking_tools_and_improvements/Feedback
Mar 25 2019
@Niharika https://meta.wikimedia.org/wiki/Community_health_initiative/Partial_blocks/Feedback is the best one to keep the comments focused.
Mar 22 2019
@alanajjar you can describe what you found on Arabic Wikipedia related to the page freezing and not showing block message when adding a category with a gadget. I would appreciate you sharing the particular details and screenshots.
Mar 21 2019
Thanks @dom_walden Sounds good. Looking over the list I don't see any other beta sites that will give us extra information that we would use right away. So, from my perspective we're done for now.
Mar 20 2019
Jan 11 2019
It is intentional that only indef blocks allow for user names to be suppressed. We are using it only to suppress indef blocked troll accounts that meet a strict criteria for suppression. This is not needed for partial blocks even if time period was indef.
Jan 9 2019
I agree with Trevor that we should keep it for now
Dec 13 2018
Earlier I thought of the term Screening because it is a form of Assessment but better since it has a connotation that it is not exact or permanent. But there are other meaning that are really different and also I don't know if it would translate well. So, I rejected it.
Dec 11 2018
Judgement is a problematic name for all the reasons stated by others already and needs to be replaced before that it completely undermines the good that could otherwise come from this work.
Nov 30 2018
@TBolliger I see why you prefer option 1. It follows traditional on wiki values and is the safe approach. The only reason that I might consider including their talk page is that some users get stuck in a rut and spend all of their time ranting on talk pages, even their own. Block all talk page access might bring them back to productive editing again. I wouldn't be opposed to a wiki experimenting with this approach. to see if it helps some users.
-I have mixed feeling about talk namespace blocks that includes their user talk page. I lean toward not blocking it UNLESS the page is added as part of the actual partial block. And then pre-fill the checkbox.
-I would make them list it in the block itself not with a simple check or to assume a talk namespace block would include their talk page. This would take away errors that would be difficult to resolve if talk page access is gone. This would still allow for the flexibility to do a rare user talk page or namespace block that includes their talk page.
-That said, it is a corner case that we could eliminate by allows allowing them to edit their own talk page with all pb. There would be no big loss by eliminating it since it is not available now.
I agree that we need to re-think changes introduced with the patch.
@dmaza If a sitewide blocked user can edit their talk page, then the message needs to display. This is very common and expected result that we shouldn't change.
Nov 7 2018
@Trevor, agree that this ticket should not do the big change of stopping admin from unblocking their own account. And also the PB can not modify belong in another ticket, too.
Nov 6 2018
Nov 2 2018
Aug 30 2018
This something we need to more research around through user interviews or on wiki discussions. And then do testing around it as we roll it out on our first wiki.
I agree with Trevor's concern. Currently, Editing Restrictions as logged now are not easily found and not displayed when you look at user contributions or when you go to the user's talk page. It might be a disincentive to use partial blocks if there is a social stigma.
Aug 28 2018
I looked at a few of the other possible user action that might show up as admin actions but nothing showed up as obvious.
Aug 25 2018
Yes, it makes sense that it could be including non-admins with page move rights. https://en.wikipedia.org/wiki/Wikipedia:Page_mover#Suppressredirect
Aug 6 2018
Looks good to me.
Aug 1 2018
Strong preference for Share these results since a discussion might not be the appropriate context.
Jul 5 2018
Jul 2 2018
@alexhollender "There's a discussion happening about improvements to this blocking tool. Come check out the designs and join in" is perfect. There needs to be a link to discussion on meta at the end.
We talked about this last week and agreed that the wording needs to be changed to lose the "we" to make it more reflective of the participatory design and research approach that we're using.
Jun 29 2018
Jun 21 2018
@TBolliger In the discussion on Meta, some people are giving good reasons for why that the word "block" would be potentially damaging to reputations. More so than the current sanctions like editing restriction or a topic ban that the partial block will be replacing or enforcing. I also think it is definitely more harm if it is logged as a partial block if it is a replace for Full Protection on a page which carries no stigma for individuals.
Jun 20 2018
Track on Asana https://app.asana.com/0/364663766104026/timeline
Jun 13 2018
The most important piece of this will be the information that is prompted to be posted to make a report or supplement an existing report.
May 21 2018
@TBolliger Probably only want to look at full protection for the information we are trying to obtain. https://meta.wikimedia.org/wiki/Help:Protection
May 17 2018
Mar 28 2018
For the first release, let's only enable on meta, mediawiki.org, and de.wikipedia.
Mar 21 2018
Feb 14 2018
Pages created on EN WP https://en.wikipedia.org/wiki/Wikipedia:Community_health_initiative_on_English_Wikipedia/Improved_tools_and_workflows_to_report_harassment
Feb 12 2018
Yes, will get it done by end of the week.
Jan 4 2018
It was planned that accounts without edits should be able to receive email on their home wiki. If that is not happening, then something is wrong that needs to be fixed.
Dec 4 2017
Oct 11 2017
As Wpedzich says, the WMF Support and Safety team (my team) is aware of the long term abuse by Wikinger and it is not possible to keep Wikinger off WMF wikis.
Sep 26 2017
Jun 21 2017
Productivity would be useful to look at. Change in the number or type of edits.
May 11 2017
Apr 28 2017
Hi all, the Support and Safety team and the Anti-Harassment Tools team have been looking at this feature as an interesting way of addressing a concern. We had some questions come up in discussion. One of these is regarding the visibility of the blacklist to other contributors. As we understand it, the current configuration is that the blacklist is an openly-viewable subpage in userspace. We could see some problems there - e.g. the creation of “enemy lists” for instance, or the escalation of an interpersonal dispute because an editor notices their name on a blacklist. Is the userspace subpage the only option? Could, for instance, the list be a Special page only viewable by admins?