User talk:TBolliger (WMF)

Added new script version (truncate edit summaries with ellipsis)
Replied. --Gryllida (talk) 01:56, 5 March 2018 (UTC)

A barnstar for you!

 * Thank you! I'll share your appreciation with the whole Community Health Initiative team. :) — Trevor Bolliger, WMF Product Manager (t)  10:58, 12 March 2018 (UTC)

Thanks
Thanks for your work on the edit summary length discussion at Village pump (proposals). The relationship between WMF and the en:wp community is not always a smooth one, but this was a great example of constructive two-way engagement. Let's do more of that! Shock Brigade Harvester Boris (talk) 17:39, 14 March 2018 (UTC)
 * My team is happy to know that our involvement is appreciated. :) It's difficult to make a diverse group of 250,000 people happy but we're sincerely trying our best to stay involved and collaborate. — Trevor Bolliger, WMF Product Manager (t)  19:12, 14 March 2018 (UTC)
 * The thanks are richly deserved as you have a magic touch with wording that some others have lacked. Johnuniq (talk) 22:55, 14 March 2018 (UTC)

Editing restrictions wireframe feedback
> that admins be able to set complex blocks in one go (e.g. block a user from a category and a few specific pages.) Agreed.

I don't agree with putting everything on the same form -- you've got functionality that serves two different social purposes and solves two different problems. I would call partial blocks "editing restrictions", not blocks. I would place them in a new tool with a new log type (block log stigma is a thing). Special:Editingrestrictions would be the Special:Blocklist equivalent.

Build one interface that solves exactly one problem, and does it well. The four options under the entire site don't make sense for editing restrictions (email can be made a global option). Where does the prevent editing to the relevant talk pages checkbox belong? Now picture adding a few more editing restrictions -- e.g. cannot send notifications globally and to $LIST_OF_USERS, cannot send email to $LIST_OF_USERS, prevent user from creating pages (in these namespaces) -- and options -- e.g. notify me when this block/restriction is about to expire, RevisionDelete this username from public logs -- and things may start to become awkward. (I'm not asking for these as part of this project, but they will be asked for and you need to design an interface that can accommodate them.) Please also take into account content that's already on the form: MediaWiki:Blockiptext. Both the text and the form will get longer with all these extra options. Scrolling is already necessary on 1080p monitors for en.wp.

If you shove everything on the same form then something like this may work better ("[ ]" is a checkbox).

Block user from:

The entire site
 * [ ] Prevent account creation
 * [ ] Prevent the user from editing their talk page
 * [ ] Autoblock
 * [ ] Prevent logged in users from editing from this IP address
 * [ ] Sending emails

Editing restrictions
 * Pages [________]
 * [ ] Include subpages (useful for userspace and AFD bans)
 * [ ] This is a regular expression
 * Namespaces [_______]
 * Categories [_______]
 * [ ] Include subcategories to depth [__] (max depth decided by technical feasibility)
 * [ ] Uploading files
 * [ ] Sending emails

Reason: [__________]


 * [ ] Watch this user's user/talk pages

--end mockup--

Other points:
 * Email needs to be both a full block option and an editing restriction.
 * I would also consider the ability to set different expiries for at least a full block and a bunch of editing restrictions (again, this suggests two forms).
 * File:Granular blocks, one giant input field.png is a confusing dog's breakfast. If I saw that, I would not know instantly what editing restrictions I can impose. It's also heavily reliant on JavaScript. MER-C 13:39, 23 March 2018 (UTC)


 * Thank you, MER-C, for the input and ideas! Making this first draft of wireframes has opened my eyes to the magnitude of decisions we'll need to make on this project. I definitely agree that we'll want to follow the Unix philosophy and should build for this concept to grow. Making this it's own tools has its' own benefits — we won't interrupt existing workflows of those who regularly set or modify blocks. But otherwise I'm of two minds if it should be part of Special:Block or a new tool.
 * Also, thank you for bringing up the part about calling these 'blocks' and the stigma involved. We definitely need to take this into account.
 * We're finishing up a few other projects now but should get back to this in mid/late April. We'll be posting more updates on the Meta wiki page and will be creating an ENWP version of this page soon. We'll see you on the talk page, then! — Trevor Bolliger, WMF Product Manager (t)  00:07, 27 March 2018 (UTC)

I'd like to invite you to participate in a discussion on meta:Talk:Community health initiative/Per user page, namespace, category, and upload blocking. After further discussion our team still thinks this should be built on top of Special:Block, both for technical and usability reasons. But we do not want to design in a vacuum so we've posed it as a discussion question. We're open to designing whatever the feedback directs us to. See you there! — Trevor Bolliger, WMF Product Manager (t)  18:58, 3 May 2018 (UTC)

January 2019

 * I'm not experimenting, I'm a product manager at the Wikimedia Foundation updating a project page for our partial blocks feature. — Trevor Bolliger, WMF Product Manager (t)  00:14, 31 January 2019 (UTC)
 * I'm really sorry for my mistake. Mosrod Talk  01:39, 31 January 2019 (UTC)
 * No worries! Project pages are a niche type of page here, much different than typical encyclopedia articles. Keep up your hard work. :) — Trevor Bolliger, WMF Product Manager (t)  01:07, 31 January 2019 (UTC)