Community Wishlist Survey 2023/Multiblocks/pl

Blokady niezależne
Blokady niezależne
	Złożenia/Czasy blokad
Grupa:	Community Tech
Członkowie drużyny:	Joydeep Sengupta, Dayllan Maza, Harumi Monroy, MusikAnimal, Sam Wilson, Karolin Siebert, Sandister Tei, Sammy Tarling
Lider:	Dayllan Maza i Karolin Siebert (Product Owners)
Aktualizacje:	Aktualizacje

This page is a translated version of the page Community Wishlist Survey 2023/Multiblocks and the translation is 21% complete.

Blokady niezależne (ang. multiblocks) to życzenie nr 14 w badaniu życzeń społeczności 2023. Celem tego życzenia jest możliwość nakładania różnych współistniejących blokad. Ta strona przedstawia podejście Community Tech do zaspokojenia tej potrzeby.

Obecnie administratorzy mogą nałożyć albo pełną blokadę na użytkownika, albo blokadę częściową, uniemożliwiającą użytkownikowi edytować pojedynczych stron lub przestrzeni nazw. Jednak administratorzy nie mogą nałożyć obu tych blokad. Na przykład nie mogą całkowicie zablokować użytkownika na jeden dzień, a dodatkowo zabrać mu możliwość edytowania określonej strony na czas nieokreślony. W związku z tym trudno im nałożyć blokadę proporcjonalną do sytuacji i trzeba albo nałożyć zbyt szeroką blokadę, powodując szkody uboczne (jak w przypadku blokad zakresów IP) albo zdjąć obowiązującą częściową blokadę i nałożyć nową, pełną blokadę.

Więcej szczegółów na Phabricatorze. Jeśli masz jakieś komentarze lub pytania, zostaw je na stronie dyskusji.

Zobacz pierwotne życzenie

Kontekst

Życzeniem numer 14 na tegorocznym (2023) badaniu życzeń społeczności były blokady niezależne. Życzenia związane z funkcją blokowania pojawiają się regularnie i często na różnych listach życzeń.

Stan obecny:

Kiedy ktoś próbuje nakładać blokadę na już zablokowanego użytkownika, poprzednia blokada musi zostać usunięta.
Wydaje się, że dawny zespół ds. narzędzi do przeciwdziałania nękaniu rozważył wiele nakładających się blokad.

Where do blocks exist in our Projects?: There are existing designs and exploration by the former Anti-Harassment Tools team.

Existing Documentation

Current Shortcomings of the Blocks

Unable to have both sitewide and partial block at the same time.
Can’t block different namespaces for different time periods.
Only one reason, shown to both the blocked user and to other admins.

Słowniczek

Blokada: See Manual:Glossary on mediawiki.org
Zmiana blokady: Akcja administratora edytującego nałożoną już blokadę. Administrator, który jako ostatni zmieni blokadę, figuruje jako ten, który ją nałożył.
Cel: Użytkownik albo IP, na które nałożono blokadę.
Edit block: When an Admin edits a block, in the back-end we remove the old format of block and add a new one. See Reblock.
Change block: See Reblock.
Unblock: Removing a block on a target.
Remove block: See Unblock.

Zakres prac i sytuacje użytkowników

Ogólne wymagania

Jako admin, kiedy nakładam blokady, chcę założyć blokadę na określony czas, żeby zapobiec kolejnym złym edycjom.
Jako admin, kiedy nakładam pełną blokadę obowiązującą przez określony czas, chcę ją połączyć z blokadą częściową, żeby ta druga została, kiedy pierwsza wygaśnie.

Scope and Constraints

Not in scope:

Interaction with autoblocks/cookie blocks
GlobalBlocking
- nb. GlobalBlocking does not have partial blocks, so this probably shouldn’t be in scope
Only minimal UI changes (i.e. no dialog like in the old designs)

Technical Investigation

In the user interface, Special:Block will require major updates. Currently, when a user tries to block a target which is already blocked, they may elect to "reblock", which means to delete the old block and insert a new block. Simply inserting an additional block is not permitted. Similarly there is a reblocking concept in the action API's block action. These user-visible concepts of conflicting blocks and reblocking will need to be updated. API clients which perform block actions may need to be updated.

MediaWiki already has the CompositeBlock class, which represents multiple blocks on a given user. There is some technical debt in this area which we will try to rectify, but broadly, permissions checks and the Block hierarchy will continue to work as before.

The current schema has an ipblocks table with a unique index on the target fields. We plan to split this table, with a new block_target table for the target fields. Almost all queries on this table will have to be updated. In WMF production, there are approximately 6 affected write query callers and 18 affected read query callers. The Cloud Services replicas are also affected, although it would be feasible to provide a view for backwards compatibility.

Why and how did we accept this wish

This wish scored high in our prioritization process for 2023. It had rank 14 and we believe the impact of this work would be great for admins and the quality of our content as we would work against vandalism.

Updates

December 2024 - Design and product updates

As we are putting the final touches on Multiblocks, we wanted to share a few design updates and product notes so that Admins on local wikis can prepare for a world in which a target may have 2+ blocks.

In the current Special:Block page, Admins are able to search for a target (Username or IP Address) and then start applying blocking logic. But since Admins will soon be able to issue a sitewide block and a partial page block with varying expiration dates, they need a new interface. Example:

BadActor1 has made 1,000 edits to their local wiki, but recently made nefarious edits on the "John Lennon" article page, and was posting abusive messages on the "John Lennon" talk page. An Admin wants to send a warning message, and also block BadActor1 from editing "John Lennon" indefinitely.
The Admin can first block BadActor1 from editing "John Lennon" article indefinitely. Then, on the Special:Block page, they can block BadActor1 from editing the Talk Page namespace for 24 hours. Lastly, as a slap on the wrist, they issue a 2-hour sitewide block, also on the Special:Block page.
The Admin can issue these blocks in any order. When one block expires, the wiki will still respect the rules of other blocks.
Admins may also edit a block. To edit a block, Admins will search for a target; all active blocks will appear in the Active Block Log. Clicking "Edit" will populate the block's current logic. To update the block, admins click save.
Admins may also remove a block on the Special:Block page. To remove a block, Admins will search for a target; all active blocks will appear in the Active Block Log. Clicking "Remove" will populate a dialog that allows the Admin to provide a reason and watch the target. Removing one block will not interfere with any other existing blocks.
The Special:Block page is built using the Codex design system. Admins who disable javascript will have all the functionality of this page, with a slightly different layout.

To build multiblocks, we have rebuilt the entire Special:Block page to help admins issue, edit, and remove blocks from one place. Over time, we will direct Admins towards Special:Block instead of Special:Unblock.

We anticipate rolling these changes out in two subsequent phases. First, since there are some major UX changes to Special:Block, we anticipate rolling out updates to Special:Block in mid-late January. We plan to follow up with the rollout of Multiblocks in late Jan - February, unless there are unforeseen technical delays.

Empty state of Special:Block page
Search results of Special:Block
Editing state for add/edit Special:Block
Success message for Special:Block changes
Remove dialog on Special:Block

February 2024 – Design Updates

Over the last few weeks we’ve been designing the user experience and user interface while talking to some admins. Here are some design decisions we want to implement:

Landing page We’ve enhanced the Special: Block user page for Admins, making it a cleaner and more intuitive experience so that users can issue, modify, or remove blocks with ease. Changes include improving the page’s order of operations, adding descriptions, a condensed layout for easier block management, and UI components from Codex (Wikimedia’s design system).
Account filled in
- Now that an “account” can have multiple blocks, it’s important that an Admin can see an account’s active blocks at the top of the page.
- We moved the “block log” to the top of the page as well, so that an Admin won’t have to scroll.
Active blocks table displayed Admins can now remove or edit blocks from the Special: Block page. We hope this allows volunteers to make quick changes to the blocks on an account, should they need to.
Partial ban interaction The partial ban form is hidden behind one click, which allows us to condense information on the page. If an Admin wants to issue a partial ban, once they click “Partial” they will see the remainder of the content they need to fill out.
Edit/remove block menu Admins can now remove or edit blocks from the Special: Block page. We hope this allows volunteers to make quick changes to the blocks on an account, should they need to.
Editing an active block Admins can now remove or edit blocks from the Special: Block page. We hope this allows volunteers to make quick changes to the blocks on an account, should they need to.
Remove block When an Admin wants to remove an active block, they will remove the block using this dialog.
Block log The block log for the account will be displayed in the table, with the current design.
Setting expiration time We’ve removed the calendar date picker for now, so the expiration time will be set just with the dropdown menu. We haven’t changed any of the options in the menu.

<span lang=
Landing page
Account filled in
Active blocks display
Partial ban
Change block
Editing an active block
Remove block
Editing an active block
Block log
Setting expiration time

December 2023 – Design Updates

User job story: Adding multiple blocks (T350485)

When ... a target is disruptive in multiple locations
... I want to create more than one block for the target,
... so that I can dissuade them from disruptive behavior while not completely driving them away from the wiki.

User job story: View blocks (T348682)

When I need to create/remove/re-block a target ...
... I want to see the list of active and past blocks on a target,
... so that I can make better decisions

User job story: Unblocking workflow (T350486)

When I want to unblock a target ...
... I want to have a simple and consistent workflow that is easy to find with predictable results,
... so that I can easily manage this important task on top of my other volunteer work.

How do we know we’ve been successful?

Possibly survey a section of admins who use and/or voted on the feature and they report being satisfied
We see multiple blocks being used and possibly standardized through community-created policies