ویکی‌پدیا:سیاست بستن

Shortcut: COM:BP

|مدیران از قابلیت بستن کاربران در زمان مقتضی برخوردارند. کاربر بسته‌شده از ویرایش صفحات، بارگذاری پرونده، و پاره‌ای امور دیگر ناتوان است. در حالت کلی، بستن آخرین چاره برای مقابله با رفتارهایی است که امکان آسیب رساندن به پروژه یا ایجاد اخلال در فضای تعاملی آن را دارند. از این رو، بستن اقدامی پیشگیرانه در نظر گرفته می‌شود، نه تنبیهی؛ بستن کاربران برای «آرام کردن» آنان پذیرفته نیست.

کاربرد

بستن به دلایل مختلفی صورت می‌گیرد. چند مورد از رایج‌ترین آن‌ها در زیر ذکر شده است:

• خرابکاری. ویرایش یا بارگذاری اخلالگرانه موجب بستن کاربر خواهد شد. مثلاً:
  • بی‌ادبی و وقاحت بیخود
  • ارائهٔ اطلاعات نادرست به صورت عامدانه (مثلاً ذکر منبع جعلی برای تصاویر)
• جنگ ویرایشی.
• نقض حق نشر. بارگذاری مکرر پرونده‌هایی که درست پروانه‌دهی نشده‌اند زمینهٔ بستن کاربر را فراهم می‌آورد. توضیحات و هشدارهای روشن دربارهٔ مشکلات پروانهٔ پرونده‌ها و ناسازگاری‌شان با سیاست‌های ویکی‌انبار باید پیش و پس از بستن کاربر به او داده شود.
• آزار. حساب‌های کاربری و نشانی‌های آی‌پی‌ای که فضایی خصمانه برای دیگر کاربران به وجود آورند بسته خواهند شد. اما آن دسته از اختلاف‌های بین کاربران که با حسن نیت همراه باشند برای رفع شدن و درخواست نظر از دیگران در ویکی‌انبار:قهوه‌خانه مطرح خواهند شد. دنبال کردن مشارکت‌های یک کاربر برای پی بردن به تخطی‌های احتمالی‌اش از سیاست‌ها مصداق آزار نیست.
• حساب‌های ربات ناپاسخگو یا بی‌جواز. حساب‌های رباتی که از اجتماع ویکی‌انبار جواز نگرفته‌اند اجازهٔ فعالیت در ویکی‌انبار را ندارند. کاربری که به صورت ربات‌وار ویرایش بحث‌برانگیز کند و نتواند دربارهٔ عملکردش توضیح دهد تا زمان انجام بحث مسدود می‌شود. پیشنهادهای ربات‌رانی را می‌توان در ویکی‌انبار:ربات‌ها یا ویکی‌انبار:قهوه‌خانه به بحث گذاشت. نمی‌توان بدون کسب مجوز پیشین در ویکی‌انبار ربات‌رانی کرد (برای گرفتن مجوز به Commons:Bots/Requests مراجعه کنید).
• حساب‌های رباتی که جواز گرفته‌اند ولی ویرایش‌هایشان در حال حاضر ایراد دارد، جهت جلوگیری از رسیدن آسیب‌های بیشتر تا زمانی که صاحب ربات ایراد را رفع کند.
• نام کاربری نامناسب.
• دور زدن انسداد. مدت زمان بسته بودن کاربری که آگاهانه انسداد را دور می‌زند، از نو تجدید می‌شود، اما اگر در این هنگام رفتارهای خطای دیگری از او سر بزند، مدت زمان بستنش افزایش می‌یابد. حساب‌های کاربری یا نشانی‌های آی‌پی‌ای که برای دور زدن انسداد به کار گرفته شده‌اند باید بسته شوند.
• سوءاستفاده از چند حساب برای گمراه کردن، فریفتن، مختل کردن، یا تحریف اجماع یا دور زدن انسداد یا دیگر محرومیت‌ها. حساب‌های ثانویه معمولاً نامعین بسته می‌شوند. ممکن است حساب اصلی، بسته به شرایط، مسدود شود یا مدت انسدادش افزایش یابد یا مورد اغماض قرار گیرد.
• پراکسی‌های باز یا ناشناس‌کننده مطابق سیاست سراسری ویکی‌مدیا معمولاً به محض کشف بسته می‌شوند. مدت زمان معمول بسته شدن یک سال است.

دستورالعمل برای مدیران

قبل از بستن

• For blocks based on disruptive behaviour, such as vandalism, repeated copyright violations and manual promotional activities, ensure that the user has been appropriately warned, preferably using a block warning template. No warning is necessary when blocking open proxies and users with inappropriate usernames. Accounts and IP addresses used solely for severely disruptive purposes such as automated spamming, serious vandalism or harassment may also be blocked without prior warning.

• Controversial blocks may be discussed at the blocks and protections noticeboard, preferably before they are applied if at all possible. As a rule of thumb, when in doubt, do not block.

• Range blocks are especially powerful tools, and discussion of these is particularly encouraged. Range blocks with a duration longer than 24 hours should be discussed with a checkuser to assess the likely impact.

موقع بستن

• Blocks can be applied to registered users, IP addresses or address ranges.

• As blocks are preventative rather than punitive, use a block duration that is proportional to the time likely needed for the user to familiarize themselves with relevant policies and adjust their behaviour. Also consider the user's past behaviour and the severity of the disruption. When blocking IP addresses, keep in mind that innocent third parties sharing the same addresses may be affected.

• Provide a reason for the block. The rationale should preferably use links to relevant policies to help the blocked user understand why they have been blocked. Where appropriate, diffs or permanent links documenting the reason for the block are also helpful.

• Account creation should be prevented in most cases, but may be allowed when blocking an inappropriate user name to allow creation of a different name.
• Autoblocking of IP addresses used by the blocked user should typically be enabled for users who were blocked for disruptive behavior. It should be disabled in most other cases, like blocking malfunctioning bots and usernames that don't follow the username policy.
• Only prevent the blocked user from using their talk page or sending e-mail if they are likely to abuse these privileges.

بعد از بستن

• Notify the blocked user, preferably using a user block template.
• Watch the blocked user's user talk page and ensure that requests for unblock are attended to.
• Blocks based on disruptive behaviour should be lifted if there is reason to believe that the disruptive behaviour will not resume.

• Controversial blocks may also be discussed at the blocks and protections noticeboard after they have been applied. To avoid wheel warring, another administrator should lift a block only if there is consensus to do so, even if there is no clear consensus in favor of the original block.

Checkuser blocks

Checkusers may need to block an editor on the basis of technical checkuser evidence, due to disruption caused by abuse of multiple accounts or IP addresses. These blocks are marked as a {{Checkuserblock}} in the block summary and must not be reversed by non-checkusers without consulting a checkuser.

As checkuser data cannot be shared publicly and a checkuser block may involve other pertinent non-public information, an unblock appeal for a {{Checkuserblock}} must only be reviewed by a checkuser. A reversal of a check user block by an administrator without consulting a checkuser may result in the removal of permissions.

Oversight blocks

In exceptional cases, there may be a need to block an editor on the basis of oversighted information that cannot be shared publicly. In such a case, the available oversighters may jointly act on the basis of group consensus. If there are insufficient oversighters available or if additional input is required they may consult the Wikimedia stewards.

Except in an emergency, non-oversight administrators should not block on the basis of information known to them that has since been oversighted. An administrator believing that such a block is required should contact one of the oversighters privately or email oversight-commonslists.wikimedia.org.

Any block made under this section should be reported by the oversighters to the community at the earliest opportunity, with as much background material as can reasonably be provided.

An editor who is blocked under this section may not be unblocked without the approval of the oversighters. An editor who wishes to have their oversight block reviewed should approach the oversighters privately, who will consider the request as a group. Public ‘appeals’ on the talk page of the blocked editor should not be used, and any that are posted may be removed.

Appealing a block

Blocked users are informed that they may request unblocking. They may do this by adding {{unblock|reason for the request}} to their own user talk page. Alternatively, they may request unblocking with an appropriate reason via e-mail to the blocking administrator or another administrator.

An appropriate reason will almost always include one of the following:

• An acknowledgement that the block was appropriate and a credible promise that the behaviour that led to the block will not be repeated
• An explanation of why the block is not appropriate based on this and other relevant policies and guidelines or is likely to be a mistake or an unintended side effect

An unblock request may be granted or declined. Before granting a request to lift a block placed by another administrator, the reviewing administrator should consult with the blocking administrator, except in obvious, uncontroversial cases. Requests made on user talk pages may only be declined by an uninvolved administrator. Unblock requests for blocks marked with {{checkuserblock}} will be reviewed by a checkuser.

Making repeated unblocking requests without appropriate reasons may be considered abusive. As noted above, users who have abused or are likely to abuse the ability to edit their own user talk page and/or send e-mail in this or any other way may have either or both of these privileges revoked, which also prevents these privileges from being used for unblocking requests.

See also

• Category:Block warning templates
• Category:User block templates
• User:Blocking subject, a test account for blocking practice
• m:Global locks, m:Global blocks, and m:Global bans: similar concepts spanning all Wikimedia projects