ابتکار عمل برای حفظ سلامت اجتماع/بستن کاربر بر اساس صفحه، فضای نام و بارگذاری
This page documents a feature the Wikimedia Foundation's Anti-Harassment Tools team may build. Development of this feature is complete.
🗣 We invite you to join the discussion!
🛠 Track in Phabricator at T2674.
گروه توسعه ابزارهای ضد آزار و اذیت بنیاد ویکی‌مدیا هم‌اکنون در حال توسعه قطع دسترسی موردی هستند. بندایش کامل همواره واکنش مناسبی برای بعضی موقعیت‌ها نیست. بستن‌های کوچک‌تر و تاکتیکی‌تر می‌توانند در عین حفظ مشارکت‌کنندگان سازنده، مشکل را برطرف کنند. هدف این پروژه اینست که مدیران ویکی به مجموعه ابزارهایی قدرتمندتری برای واکنش بهتر به موقعیت‌های متفاوت اختلاف بین کاربران دسترسی داشته باشند.
لطفاً در صفحه بحث درباره این موضوع گفتگو کنید.
درباره
انواع قطع دسترسی
در کاربرد قطع دسترسی کامل خللی ایجاد نخواهد شد. تمام قطع دسترسی‌های قبلی باقی خواهند ماند و قابلیت بستن کاربران مشکل‌ساز از تمام ویکی همانند اکنون سر جایش خواهد بود. علاوه بر قطع دسترسی‌های کامل، ما علاقه داریم تا قابلیت جدیدی برای بستن کاربران ارائه کنیم. این قطع دسترسی شامل موارد زیر می‌شود:
- ویرایش یک یا چند صفحه خاص
- ویرایش تمام صفحات در یک یا چند فضای نام
- بارگذاری پرونده
- ارسال رایانامه به دیگر کاربران
موارد استفاده
انواع قطع دسترسی موردی می‌تواند در موقعیت‌های زیر مورد استفاده قرار گیرد:
- کاربری مفید در حوزه‌ای خاص (مثل سیاست، دین و غیره) بی‌طرف نیست.
- خرابکاری مداوم در یک صفحه از طرف دامنه آی‌پی‌های قابل‌شناسایی (مثلاً خرابکاری دانش‌آموزان یک تیم ورزشی در صفحه تیم ورزشی رقیب)
- دو یا چند کاربر که با یک بستن واکنشی، تحریم شده‌اند.
- کاربری از ویژگی نامه به دیگر کاربران سوءاستفاده کرده اما برای ویکی مفید است.
- ویرایش‌های غیرمفید یک کاربر در الگوها
کاربرد
قطع دسترسی‌های موردی در موارد زیر همانند قطع دسترسی‌های کامل عمل می‌کنند:
- می‌توانند توسط مدیران انجام شوند.
- می‌توانند روی حساب‌ها، آی‌پی‌ها و دامنه آی‌پی اعمال شوند.
- شامل مؤلفه‌های دلیل، زمان انقضا، بستن صفحات بحث و زیرصفحه‌ها و قابلیت بستن خودکار آی‌پی‌ها می‌شوند.
- در سیاهه بستن و هرجای دیگری که بستن‌های کامل به نمایش در می‌آید، نمایش داده می‌شوند.
- پیام بسته شدن که شامل دلیل قطع دسترسی و دیگر اطلاعات بسته‌شدن (مدیری که عمل را انجام داده، تاریخ انقضای بندایش، دلیل بندایش و نحوه درخواست برای باز شدن حساب) است، در هنگام بسته شدن برای کاربر به نمایش در می‌آید.
به‌روزرسانی‌ها
May 7, 2020
The AHT team is going to dedicate some time towards adding feature to partial blocks. There is an open question about this on the talk page. Your thoughts would be much appreciated.
February 20, 2020
Partial blocks have been enabled on all Wikimedia wikis. Thank you to everyone who has helped this project along.
December 17
Partial blocks have been asked for more and more wikis recently. In light of that, we are ready to enable partial blocks across all wikis. This deploy will happen in the week of January 6th for most projects (unless your project has already requested more time for discussion). If your project wishes to opt-out of this deployment, please reach out to us – User:NKohli (WMF) or User:SPoore (WMF) on the talk page. We strongly encourage you to try the feature out before deciding whether it serves the needs of your project or not.
September 11
Partial blocks has been enabled on all wikivoyage, wikisource and wiktionary wikis. We think the partial blocks feature is at a good, stable stage now as we have seen fewer and fewer bugs come up in the last few months of the feature being deployed on various projects. The team has spent a lot of time in improving the backend infrastructure of block code and made sure that the code is reliable, in anticipation of any future features that may need to be added.
There continues to be requests from more wikis for partial blocks. We also presented about partial blocks at Wikimania and it was very well-received, with several attendees asking for partial blocks to be enabled on their home wikis. In light of the general positive reception to partial blocks on wikis where it is deployed, we are planning to do a wider deployment to more Wikimedia projects in the next few weeks.
We will continue to collect feedback about partial blocks as we launch the feature on more wikis, alongside data collection on usage of the feature. We are also around to do maintenance work on the features, as and when needed.
March 13
Partial Blocks are now live on Arabic Wikipedia, which means they fully support non-Latin languages and RTL languages. Partial blocks is ready to enable on any language Wikimedia wiki (except Wikidata.) 🎇
We're looking for users who want to represent their wiki to enable this feature. Please leave a message on the talk page if you would like to help. Thank you!
February 13
Namespace blocks are live! 🚀
There are some minor fixes and changes we'll be working on over the next few weeks, but the next major stage for this project is to release to more wikis so we can observe how effective they are at mitigating user misconduct, and to get feedback about any changes we should make. Specifically, we are seeking to understand:
- What is an appropriate limit of the number of pages a user should be blocked from? In the first version limit is 10, but it can any number.
- How should partial blocks be logged to allow for accurate and specific logging while keeping the logs easy to read? Currently they are being logged comprehensively in the block log.
- Should a notice appear when someone edits the user or user talk page of a partially blocked user? Currently, a notice only appears if the user cannot edit that page (e.g. a user is blocked from their own user page)
- What features are missing that need to be built?
If you would like to have this functionality on your wiki to combat harassment, vandalism, or other forms of user misconduct, please let us know on the talk page.
January 30
As upload blocks will require additional database changes (which requires months of advance notice and planning) we will first complete page and namespace blocks before deciding to pursue upload blocks.
January 16, 2019
Today we reached another significant milestone! Partial Blocks have been enabled on Italian Wikipedia and the local wiki administrators are setting partial blocks to combat vandals! A big congratulation to my team for working through the inner guts of MediaWiki and all its processes to make sure we have a safe and reliable blocking tool. 🎉
If you would like to test the functionality, it will forever be available on http://test.wikipedia.org/wiki/Special:Block (write us if you need admin privileges.) We're already talking to two other languages of Wikipedias about being testers — if your wiki would like to test please write on our talk page!
December 20
As 2018 draws to a close, our team is putting the final touches on Namespace blocks. This functionality should be ready in January on Test Wikipedia and on the non-English Wikipedias that are eager to adopt this new functionality. Our plan for early 2019 is to release to several wikis and make changes based on what problems and opportunities arise. We'll also build the ability to block a user from uploading files, creating new pages, and renaming pages.
Meanwhile, our team's analyst is analyzing data on the effectiveness of blocks. These measurements should help us better understand how many blocks are effective at stopping continued abuse to the wiki or its community members. We expect this data to show us if partial blocks are as effective as sitewide blocks and hope this data can inform the governance policies for when to levy blocks and block lengths.
December 5
Our team is still working on addressing the final defects before we enable Partial Blocks on Italian Wikipedia. We're optimistic that we can hit this milestone next week! In the meantime testing is still available on Test Wikipedia and Test Wikidata for users interested in taking a look at what's ready so far.
We're also confident that we can get Namespace blocks to a near-ready state by the end of December, before we break for the winter holidays. That functionality should be ready on Test Wiki in January.
November 26
We have a handful of bugfixes and feature enhancements to release this week! This list explains everything that's changed. In short, these changes will make Partial Blocks only affect exactly what is listed in the block set by the admin, as we originally intended. All changes will be available on http://test.wikipedia.org by Wednesday of this week.
With this set of changed we feel confident in the stability and functionality of the feature. We are working with Italian Wikipedia to look-over the functionality on Test Wiki before they adopt the feature and integrate it into their user mediation workflows. If any other wikis are excited to use this functionality, please let us know and we'll begin working with you!
Meanwhile, our devs are also working on implementing Namespace blocks. We hope to have them completed in the coming weeks.
November 8
Partial blocks are live on Test Wikipedia and Test Wikidata! If you're an admin on another wiki and would like to test the functionality please write a message on our talk page.
This first feature set is limited: admins can block an user or IP from editing up to 10 specified pages. There are some known defects that we're currently working on (for example, if an admin is partially blocked from a page they can't delete any page.) and we'll get back to building namespace and upload blocks in later November.
If you're testing partial blocks we'd love to hear from you! Drop us a note about your experience with the tool. We're looking specifically for feedback about:
- What is an appropriate limit of the number of pages a user should be blocked from? In the first version limit is 10, but it can any number.
- Are you satisfied with how partial blocks are logged?
- Do we need to change anything that has already been built?
- Is the warning message in the VisualEditor too gentle?
Thank you!
October 19
We're making significant progress on Partial Blocks and are nearly live on production wikis. We hope to have a functional version on test.wikipedia.org and test.wikidata.org in the coming weeks. We're very excited to share it with you!
While the devs put the final touches on the first version, others on our team are currently thinking about how we want to measure the effectiveness of blocks. We're asking ourselves (and anyone who will listen) questions like "Are blocks effective at stopping harm? Do users who are blocked return to make constructive edits? How do we measure this?" — if you are interested in discussing this topic, we have a 7 proposed measurements and commentary on why we selected them at the other project page.
As part of this, we've generated some data on how frequently blocks are set (did you know there are currently 3.4 million active blocks?) and pages are protected (~20,000 pages are currently protected) to better understand the scale of administrative actions.
September 24
We have a fourth round of designs, based on feedback from our second round in June. Here are the two new designs, detailed UI element views can be seen in the gallery below.
-
What Special:Block will look like after this change.
-
A partial block configured.
September 21
Our team is nearly ready to release the first feature set of partial blocks — the ability to block a user from ≤10 pages — on the beta environment then test.wikipedia by mid-October. We are talking with some early opt-in wikis to test the functionality, please let us know if your wiki would be interested in utilizing this functionality, which also gives you a great opportunity to dictate the future of this project!
In other news, due to technical complexity, we have decided to de-prioritize multiple blocks and remove it from this project. I've moved the documentation here. This small amount of functionality would take a very large amount of time to build and we first want to make sure page, namespace, and upload blocking work as expected and actually produce meaningful impact. We'll have another round of designs soon and we look forward to delivering a great partial blocks feature in the coming months!
September 4
We have our third round of designs almost ready and we want to share them now before we go too far without validating our direction. These designs include functionality to view details about multi-blocks. Because of this change we need to introduce a new piece of information during the blocking process. This led us to the idea of a block modal window, which can theoretically appear on any page — a diff page, recent changes, a profile, etc. This would allow an admin to block a user without having to navigate to another page. Here is how it would work:
// designs redacted, moved on Multi-blocks subpage. //
August 22
Based on conversations on the talk page, in person at Wikimania last month, and on the TechComm RFC for this project our team has decided to merge the project of multi-blocks into Partial Blocks. The goal of multi-blocks is to allow admins to set multiple concurrent blocks against an account with independent expiration dates, decreasing the manual workload on administrators. Example use cases for multi-blocks include:
- User:Apples has been indefinitely blocked from editing
Neptune. They then receive a 24 hour full-site block. When the full site block expires, they should continue to be blocked fromNeptune. - User:Bananas is indefinitely blocked from editing
Marsand from editingVenusuntil 2025. An admin wants to block them fromSaturnfor one month. - After User:Carrots has violated a wiki policy, an admin wants to set both an indefinite block against
Plutoand a 24-hour sitewide block at the same time, without having to write a self-reminder to update the block.
This will require changes to Special:Block, Special:Unblock, Special:BlockList, and Special:Contributions. We are working on another round of designs (with minimal changes from the last round) which we will post on this page next week. Work for multi-blocks will be tracked in Phabricator at phab:T194697. Our TechComm RFC can be found at phab:T199917 which includes all our proposed database changes and other technical implementation details.
August 8
Most feedback we’re receiving at this stage in the project is about one hypothetical — yet entirely likely — workaround a malicious user could exploit to their advantage: a user using a temporary sitewide block to erase (and therefore evade) an indefinite partial block. This could be resolved with manual solutions (e.g. calendars and reminders to reinstate the partial block) but this is inconvenient and interruptive to your workflows and prone to human error. It’s clear that we need to determine a solution to prevent this abuse before Partial Blocks releases to most wikis. There are a few ways to do this and this can get pretty complicated, please help me determine which system we should build:
- Option 1 – Re-blocks
Description: If an admin escalates a partial block to a sitewide block and the expiration date for the sitewide block is shorter than the previous partial block, the admin should have an option for the block to revert to the previous partial block parameters when the sitewide block expires.
Example: An admin blocks User:Apples from editing the page Argentina for 9 months. The same day, an admin modifies the block to Argentina and Bahamas for 8 months. The same day an admin blocks the user from the entire site for 7 months. After 7 months, User:Apples would be blocked from Argentina and Bahamas for 1 more month, after which the partial block would be entirely expired.
This change would only require adding one additional option into the Special:Block UI when a block is being modified.
- Option 2 – Multi-blocks
Description: Admins should be able to set different expirations for different elements of a block.
Example: An admin could block User:Bananas from editing Argon for 9 months, Boron for 8 months, and sitewide for 7 months. After 7 months, the user would be blocked from Argon and Boron and after 1 more month the user would be blocked only from Argon. After 1 more month the partial block would be entirely expired.
This change would require a more significant change to how blocks are currently logged and managed on Special:Block, Special:BlockList, Special:Contributions, and Special:Unblock. Users can be partially blocked from an unlimited number of pages, meaning every page could hypothetically have a different expiration, which could lead to some complicated situations.
- Option 3 – Something else!
We’d love to hear more alternate proposals. Please discuss on the talk page.
For all options it should be possible for an admin to clear all blocks from an account, leaving it entirely unblocked. This will most likely be a change to Special:Unblock.
Join us on the talk page to let us know what you think!
۲۰ ژوئیه
بنر اعلام این ویژگی با توجه به تأخیر در عرضه کد به ویکی‌پدیاهای اصلی غیرفعال شد. ما قصد داریم تا از ۳۰ ژوئیه تا ۳ اوت، آن را روی تمام ویکی‌ها فعال کنیم.
۱۹ ژوئیه
از امروز تا دوشنبه ۲۳ ژوئیه، ما بنری در فضای ویژه:بستن گذاشته‌ایم تا از مدیران برای مشاهده این صفحه و خواندن درباره پروژه و ارسال بازخورد دعوت کنیم. اگر آن بنر شما را به اینجا کشانده، خوش آمدید!
۱۳ ژوئیه
این پروژه به دلیل امور دیگر کمی تأخیر دارد و متأسفانه قابل نمایش در ویکی‌مانیا نیست. تمام گروه ضد آزار و اذیت در ویکی‌مانیا که هفته بعد در کیپ تاون برگزار می‌شود، حضور خواهند داشت. اگر شرکت می‌کنید، لطفاً ما را پیدا کرده و در مورد این پروژه با ما صحبت کنید!
ما فکر می‌کنیم که در اوایل اوت نسخه‌ای کاربردی از این ویژگی را داشته باشیم. ما همچنان در تلاشیم تا آن را با توجه به طرح به‌روزرسانی ۲۸ ژوئن بسازیم.
در آخرین هفته ژوئیه، ما بنری در ویژه:بستن قرار می‌دهیم تا از مردم برای مشاهده این صفحه و مطلع شدن از تغییرات دعوت کنیم. پیش‌بینی می‌کنیم افراد زیادی به بحث بپیوندند، خوش آمدید!
همچنین، در هفته‌های بعد ما یک درخواست نظر فنی را برای اطمینان از صحت تصمیماتمان راه می‌اندازیم.
۲۸ ژوئن ۲۰۱۸
این پروژه هم‌اکنون در دست توسعه است و ما امیدواریم که نسخه‌ای کاربردی در نیمه ژوئیه آماده شود تا بتوانیم نحوه کارش را برای بازخوردهای بعدی نشان دهیم. پیش‌بینی می‌کنیم که نسخه‌ای در نیمه اوت در ویکی‌های آزمایشی اجرا شود و پس از آن، دنبال یک ویکی برای آزمایش کردن این ویژگی خواهیم گشت.
ما مجموعه طرح‌های جدیدی برای به اشتراک‌گذاری داریم. تصور می‌کنیم که این طرح‌ها باید بیشتر بازخوردهای دریافت شده در یک ماه قبل را پوشش دهند.
-
جدیدترین طرح ما تا ۲۸ ژوئن، نحوه بازطراحی ویژه:بستن به صورتی بوده که مدیران توانایی بستن یک کاربر از بخش‌هایی از وبگاه را داشته باشند. این، نمای پیش‌فرض ماست.
-
نحوه تعیین جزئیات قطع دسترسی موردی توسط مدیران در ویژه:بستن. در نمایشگرهای عریض، سیاهه بستن در کنار این گزینه‌ها نمایش داده خواهد شد.
-
یک قطع دسترسی موردی از چندین صفحه تعیین‌شده.
-
محل نوشتن فضاهای نام
-
محل نوشتن صفحه‌ها
-
نحوه به نمایش در آمدن قطع دسترسی موردی و کاربرد آن در ویژه:فهرست بسته‌شده‌ها
نکاتی درباره این طرح‌ها:
- در نخستین تصویر، چک‌باکس‌های «بارگذاری پرونده‌ها» و «انتقال صفحات» انتخاب نشده. این، خطایی است که ما در دور بعدی طراحی برطرفش خواهیم کرد.
- عرض قسمت کشویی مؤلفه «دلیل» با توجه به طول گزینه‌ها که در هر ویکی متفاوت است نمایش داده می‌شود. کاربرد آن، همچون کاربرد امروزی‌اش خواهد بود.
- ما قصد داریم تا بارگذاری اجاکس را به جدول تاریخچه بسته‌شدن بیفزاییم. این ویژگی در نمایشگرهای کوچک، در زیر ابزار و در نمایشگرهای عریض و در ویکی‌های چپ به راست، در سمت راست ابزار قرار داده می‌شود.
نسخه‌های پیشین
به‌روزرسانی‌های پیشین در صفحه بحث نوشته شده بود که با پیشرفت پروژه به اینجا منتقل شد. خلاصه‌ای از پروژه تا امروز به شرح زیر است:
- ما تصور می‌کنیم که کاربردی‌ترین و منطقی‌ترین حالت اینست که این امکان را در بالای ویژه:بستن قرار دهیم، چرا که تجربه کاربری و نحوه کار آن تقریباً کاملاً مشابه قطع‌دسترسی‌های سابق است. ما متوجهیم که بیشتر قطع‌دسترسی‌ها کامل خواهد بود، برای همین نحوه کار به طوری بهینه‌سازی شده تا با کاربرد فعلی تداخل نداشته باشد. تمام تغییراتی که انجام دهیم، به کاربرد قبلی اضافه خواهند شد.
- تصمیم گرفتیم تا قطع‌دسترسی از رده‌ها را به بعد موکول کنیم، چون این قابلیت با چالش‌های پیچیده‌ای همراه است. ما قصد داریم تا از رضایت‌بخش‌بودن قابلیت قطع‌دسترسی از صفحه‌ها، فضاهای نام و بارگذاری اطمینان حاصل کنیم و مطمئن شویم که این امکانات باعث رسیدن اجتماع به هدف تحریم کاربر از فضایی که برای آن مخرب است بشود.
- پیشنهاد شده‌است که کاملاً این پروژه را ببندیم. گروه ما، گروه ابزارهای ضد آزار و اذیت، قویاً باور دارد که این امکان، ابزاری کاربردی برای حل مشکلات در موقعیت‌های مختلف خواهد بود و اعلام می‌کنیم که این ابزار باید به آرامی و با ظرافت روی تمام ویکی‌ها عرضه شود، چرا که باعث تغییر نحوه قطع‌دسترسی‌ها خواهد شد. ما به کاربردی بودن قطع‌دسترسی‌های موردی در تمام موقعیت‌ها باور نداریم، چون در بعضی موارد قطع‌دسترسی کامل همچنان مورد نیاز خواهد بود.
Proposed implementation
- On Special:Block, add a radio button to select setting the block as sitewide vs. partial.
- When a block is saved with the
sitewideradio button selected, the block should behave exactly as it does today. - If the
partialradio button is selected, the admin should be able to provide a list of pages and/or namespaces:- If an admin specifies page(s) to block:
- Page blocks can only be set for existing pages, with validation required in the input field.
- An autosuggest should help the admin find the correct page.
- Pages can be from any namespace
- If a page is moved or deleted, the user should still be blocked from editing that page (i.e. block by page ID, not page name)
- If an admin specifies namespace(s) to block:
- The input field should only accept valid namespaces, with validation required in the input field.
- An autosuggest should help the user find the correct namespace.
- If an admin specifies page(s) to block:
- Help tooltips should display for the new fields
- Block log entries on Special:Contributions, Special:Block, and Special:Log should be indicate if the block is partial:
- Log for sitewide blocks should not change.
- Log for page blocks should include
TIMESTAMP Admin-who-blocked (t|c|b) blocked BadApples (t|c) from editing the page(s) Foobar with an expiration time of N (reason) (unblock | change block) - Log for namespace blocks should include
TIMESTAMP Admin-who-blocked (t|c|b) blocked BadApples (t|c) from editing the namespace(s) Foobar with an expiration time of N (reason) (unblock | change block) - Log for both page and namespace blocks should include
TIMESTAMP Admin-who-blocked (t|c|b) blocked BadApples (t|c) from editing the page(s) Foobar and namespace(s) Foobar2 with an expiration time of N (reason) (unblock | change block)
- The block should be listed and annotated on Special:BlockList, per the designs
- When a user attempts to edit an applicable page, they should see a new type of block warning message using a new string key which include information on their block (reason, expiration, etc.)
- If a partial block is set, the checkbox for
Prevent this user from editing his own talk page while blockedshould be marked as disabled - The Block API should be updated to support all partial block functionality
- Sitewide blocking via API should not change
- API documentation should be updated
- If a partial block is set via API, invalid pages and namespaces should be ignored
Designs
-
Our most recent design, as of September 24, of how we will change Special:Block to allow for administrators to block a user from parts of the site instead of a sitewide block. This is the default view.
-
Special:Block, showing how an admin could set the details of a partial block.
-
A partial block with several pages set. (Some details are slightly outdated in this design.)
-
Type-ahead suggestions for namespaces. (Some details are slightly outdated in this design.)
-
Type-ahead suggestions for pages. (Some details are slightly outdated in this design.)
-
How a partial block will look and function on Special:BlockList
Notes
Category blocks
Previously, this project aimed to build the ability for admins to block a user from editing all pages inside a category. This has been put on hold until we build page, namespace, and upload blocking. Category blocks pose unique challenges that need to be addressed before we proceed with development:
- How do we handle categories that may be on the Talk Pages of applicable article pages?
- How many sub-categories deep should the category blocks apply?
- How to address situations where a user may use a sock to remove a category from a page and therefore change their own block?
- Will this introduce a speed performance drag on the user experience?
User requests
Functionality for setting more tactical types of blocks has been requested in:
- The 2015 Community Wishlist Survey/Moderation and admin tools#Enhanced per-user / per-article protection / blocking
- The 2017 Community Wishlist Survey/Anti-harassment/Per-page user blocking
- Phabricator ticket T2674 since 2005.
- This was also discussed in our wider Community health initiative/Blocking tools and improvements on-wiki consultation in late 2017 to early 2018.
Editing restrictions
In addition to simple per user blocking, the Foundation's Anti-Harassment Tools team would like to support the work done by volunteers who set, monitor, and enforce editing restrictions on Wikimedia wikis, as well as building systems that make it easier for users under a restriction to avoid the temptation of violating a sanction and remain constructive contributors.
The Editing restriction page will be used to collate and share ideas about implementing tools to make this work more accurate and more efficient. Join us on Talk:/Editing restrictions to discuss the problems encountered today that could be addressed with tech solutions.