ข้อจำกัดในการเปลี่ยนแปลงค่ากำหนดของวิกิ
 | หน้านี้ไม่ใช่หน้านโยบายแต่อย่างใด แต่มีไว้เพื่อขยายความวิธีการและแนวทางที่ผู้ดูแลระบบโครงข่ายใช้จัดการคำขอแก้ไขค่ากำหนดของวิกิ |
บางครั้งเมื่อชุมชนส่งคำขอให้แก้ไขค่ากำหนดของวิกินั้นเป็นไปได้อย่างแน่นอนในทางเทคนิค แต่บาวครั้งจะถูกปฏิเสธโดยผู้ควบคุมระบบที่เป็นผู้มีอำนาจทางเทคนิคสูงสุดในการกำหนดค่าของมีเดียวิกิ
หน้านี้จะอธิบายว่าผู้ควบคุมระบบจะจัดการกับคำขอชนิดต่าง ๆ อย่างไร และชุมชนท้องถิ่นจะสามารถคาดหวังสิ่งใดได้บ้าง รายการนี้จะไม่ได้รวมรายการคำขอที่ถูกปฏิเสธทั้งหมด เพียงแต่มีรายการที่คาดว่าจะถูกขอซ้ำอีก หากคุณเห็นว่ามีคำขออื่นที่ควรเพิ่ม หรือมีในรายการที่ควรนำออก สามารถปรับปรุงตารางนี้ได้เท่าที่จำเป็น แม้ว่าคุณจะไม่ใช่ผู้ควบคุมระบบโครงข่ายก็ตาม หากคุณไม่แน่ใจ กรุณาเพิ่มคำถามใหม่ที่หน้าพูดคุย
สิ่งที่จะถูกระงับ
ส่วนนี้คือรายการของคำขอที่จะถูกปฏิเสธในทันที ผู้ควบคุมระบบจะปฏิเสธคำขอเหล่านี้เพื่อเป็นการปกป้องหลักสำคัญของวิกิมีเดียและคุณค่าหลัก ตลอดจนปกป้องความสมบูรณ์ของโครงการโดยทั่วไป ฝ่ายกฎหมายของมูลนิธิวิกิมีเดียจะระงับการเปลี่ยนแปลงเหล่านี้เนื่องด้วยเหตุผลทางกฎหมาย
| ประเภทของคำขอ | ตัวอย่างคำขอ | เหตุผล | หมายเหตุ |
|---|---|---|---|
| การเปลี่ยนแปลงที่ทำให้มีการเข้าถึงวิกิลดลง | ลบปูมอออกจากรายการปูม | ความโปร่งใสเป็นสิ่งสำคัญในหลักสำคัญของมีเดียวิกิ แนะนำให้ขอฟีเจอร์ใหม่หากปูมมีการรบกวนชุมชน และฟีเจอร์ที่จะกรองออกยังไม่มีมาก่อน | แต่ไม่รวมไปถึงการซ่อนปูมโดยปริยายจากพิเศษ:ปูม แต่เฉพาะกรณีที่ปูมไม่มีอยู่เลยโดยสิ้นเชิง |
| แสดง CAPTCHA สำหรับทุกการแก้ไขของผู้ใช้ที่ไม่ได้ยืนยันอย่างถาวร | การปรับตั้งค่านี้จะเพิ่มข้อจำกัดกับผู้มีส่วนร่วมใหม่ ๆ การมี CAPTCHAs มีไว้เพื่อป้องกันการก่อกวนและแสปม ไม่ได้มีเหตุผลอื่น ผู้ควบคุมระบบโครงข่ายพิจารณาแล้วว่าไม่สอดคล้องกับแก่นคุณค่าของวิกิมีเดีย และไม่อนุญาตให้มีการเปลี่ยแปลงนี้ | หมายเหตุว่าการปรับตั้งค่านี้รวมแค่การเปิดใช้งาน CAPTCHA สำหรับทุกการแก้ไขเป็นการถาวรเท่านั้น หากวิกิของคุณเกิดการก่อกวนที่ฉับพลันและไม่สามารถควบคุมจัดการได้โดยสิ้นเชิง กรุณาแจ้งให้ผู้ควบคุมระบบทราบโดยเร็ว ซึ่งสามารถพิจารณาได้ว่าเป็นการรายงานเหตุการฉุกเฉินด้านความปลอดภัย ในกรณีนี้ กรุณาใช้ฟอร์มรายงานเหตุการณ์ด้านความปลอดภัย ซึ่งจะสร้าง Task ใหม่ที่สามารถเห็นได้ทั้งฝ่ายความปลอดภัยของมูลนิธิวิกิมีเดียและผู้ควบคุมระบบที่เกี่ยวข้อง พวกเขาจะเข้ามาจัดการปัญหาของคุณ และเลือกใช้วิธีการที่เหมาะสมเพื่อจำกัดและเปิดใช้งานต่อไป คุณไม่จำเป็นต้องแนะนำวิธีแก้ใด ๆ ทั้งสิ้น | |
| ลบสิทธิ์ในการแก้ไขออกจากลุ่มผู้ใช้ | "ที่ทุกคนสามารถแก้ไขได้" เป็นเป้าประสงค์หลักของโครงการวิกิมีเดีย การเพิกถอนสิทธิ์การแก้ไขโดยสมบูรณ์จากกลุ่มผู้ใช้ใด ๆ จะไม่ถูกเปิดใช้งาน | การลบหรือระงับสิทธิ์์ในการแก้ไข เช่น ACTRIAL บนวิกิพีเดียภาษาอังกฤษ สามารถเกิดขึ้นได้ แต่ยากและไม่บ่อยนัก และจำเป็นต้องมีการพิจารณาอย่างถี่ถ้วน ดูเพิ่มที่ "ปิดการอนุญาตให้ผู้ใช้ที่ไม่ใช่ยืนยันแล้วทำการสร้างหน้า" เพิ่มเติมด้านล่าง | |
| การเปลี่ยนแปลงที่เป็นไปไม่ได้ในทางเทคนิค | เปลี่ยนชื่อของตัวเลือกเขตเวลา | มีเดียวิกิใช้ฐานข้อมูลเขตเวลาของ PHP ซึ่งถูกกำหนดไว้แล้วโดยฐานข้อมูลของ IANA ดังนั้น จึงเป็นไปไม่ได้เลยในทางเทคนิคและทางปฏิบัติที่จะเปลี่ยนชื่อของเขตเวลาใด ๆ แต่ยังสามารถเปลี่ยนแปลงเขตเวลาโดยปริยายในวิกิของคุณได้โดยการแก้ไขตัวแปร $wgLocaltimezone | |
| การเปลี่ยนแปลงข้อเสนอที่ขัดต่อความปลอดภัยและ/หรือความรับผิดตามกฎหมาย | อนุญาตให้ผู้ที่ไม่ใช่ผู้ดูแลระบบดูสิ่งที่ถูกลบ | ฝ่ายกฎหมายแบนผู้ใช้ที่ไม่ใช่ผู้ดูแลระบบที่ไม่ผ่านกระบวนการ RFA ในการเข้าถึงเนื้อหาที่ถูกลบ ดูเพิ่มที่ Wikipedia:Viewing deleted content | การสร้างกลุ่มผู้ใช้ใหม่จำเป็นต้องได้รับการตรวจทานจากฝ่ายกฎหมายมูลนิธิฯก่อน วิกิขนาดเล็กมักจะถูกปฏิเสธการสร้างกลุ่มผู้ใช้ใหม่ |
| อนุญาตให้ผู้ที่ไม่ใช่ผู้จัดการโครงการทำการจัดการสิทธิของผู้ตรวจสอบผู้ใช้หรือผู้ควบคุมประวัติ | เฉพาะผู้จัดการโครงการเท่านั้นที่สามารถจัดการกลุ่มผู้ใช้ที่ถูกจำกัดสูงนี้ได้ วิกิท้องถิ่นไม่ได้รับอนุญาตให้ปรับแต่งตัวเลือกนี้ | ผู้ตรวจสอบผู้ใช้และผู้ควบคุมประวัติถูกควบคุมโดยนโยบายข้ามโครงการ ผู้จัดการโครงการจะเป็นผู้ตรวจสอบว่านโยบายถูกนำไปบังคับใช้อย่างถูกต้องแล้ว | |
| เพิ่มสิทธิการซ่อนผู้ใช้ให้กับผู้ที่ไม่ใช่ผู้ควบคุมประวัติ | By policy, it is the task of oversighters to hide things from the public. Oversighters sign confidentiality agreements and are legally required to keep the information private, while this is not true of administrators and others. | ||
| Grant Interface admins other permissions | The purpose of interface admins is to make fewer users able to edit CSS and JS pages. Granting other rights to this group may encourage wikis to grant this right when their intention is different. | Per discussion in T320752, this does not apply to editcontentmodel.
| |
| อนุญาตให้ผู้ดูแลระบบให้สิทธิบอต ผู้ดูแลระบบหรือผู้ดูแลระบบอินเตอร์เฟซ | Rejected because granting and removing those flags is a task for bureaucrats where present, or stewards. Interface administrators also have highly sensitive permissions (to edit CSS and JS pages) and requests for granting must be carefully considered. As such, it is necessary that only bureaucrats or stewards handle this task. | Wikis that currently don't have any bureaucrats and feel they are big enough to handle this themselves are recommended to elect bureaucrats instead. | |
| อนุญาตให้ผู้ดูแลระบบสิทธิแต่งตั้งลบสิทธิผู้ดูแลระบบสิทธิแต่งตั้ง | This is to protect the safety of the projects. Since bureaucrat permissions are higher than those of administrators, only stewards are allowed to do this. | Bureaucrats on all private wikis can remove bureaucrat status, but that's because private wikis are managed by dedicated groups and serve special support purposes rather than host content. | |
| Changes to use unsupported technologies, or abuse them in unsupported ways | Installation of extensions/skins that are not well maintained | Some extensions are currently installed in some Wikimedia wikis, but have significant unresolved problems or bugs. So it is decided not to install these extensions to further wikis, though existing installations will be preserved. | Currently includes: |
| Enable VisualEditor on talk pages | The visual editor is not built to support editing talk pages. As such, enabling the visual editor in a talk page namespace is likely to not always work as expected by the community. To save developers from bug reports about something that's not supposed to work in the first place, enabling VisualEditor on talk pages has been prohibited. | StructuredDiscussions implemented some VisualEditor features; another alternative is the New Discussion Tool. | |
| Changing the default skin on any individual wiki | Wikimedia should have a standardized look globally across all our projects. It has been decided that Vector will remain the default skin on all Wikimedia Wikis. | Changing the default skin on all Wikimedia wikis is certainly not prohibited, but would be extremely difficult to accomplish, and would be centrally led. Not only would this require consultation with all affected communities before such a decision could be made, but a massive effort would also be required to make all the necessary changes "behind the scenes". |
Changes that need to meet specific criteria
| ประเภทของคำขอ | เหตุผล |
|---|---|
| Local file uploads | According to Wikimedia's licensing policy, all projects are expected to host only content under a Free Content License. In limited circumstances, a project may adopt an Exemption Doctrine Policy (EDP), which defines (in accordance with both United States law as well as the law of countries where the project content is predominantly accessed) when copyrighted materials can be uploaded.
If your project may not accept non-free media (under an EDP), it is highly unlikely local file uploads will be enabled. Free media should go to Wikimedia Commons instead. See also: Non-free content. |
| Installing extensions/skins that aren't already installed on at least one Wikimedia project | To protect the security of the Wikimedia infrastructure, all extensions, skins and other components running in it must pass security, performance and other reviews. Extensions that are not already installed on at least one Wikimedia project won't be considered for installation until they pass such reviews. See Writing an extension for deployment on MediaWiki.org for required steps. |
Changes that are likely to be declined
This section lists changes that are not strictly prohibited, but are likely to be declined unless special evidence can be presented to convince system administrators that the changes are necessary.
| ประเภทของคำขอ | เหตุผล |
|---|---|
| ปิดการสร้างหน้าจากผู้ใช้ที่ไม่ได้ยืนยันอัตโนมัติ | This configuration places an undue restriction on new contributors. Sysadmins will resist such a request unless the wiki in question (1) is prepared to handle drafts in a timely manner, (2) has a well developed editing and administrative community, and (3) has established an unusually broad consensus for the change. The first two points can be addressed by appealing to the wiki's size: the number of active editors, sysops, bureaucrats, and other functionaries should be similar to "big wikis", otherwise a very good explanation will need to be given as to why the request should be accepted. The third point can be satisfied by a carefully discussed on-wiki RFC, with the closing administrator explaining the consensus in the relevant Phabricator task; if the consensus does not look particularly strong on its face (note that there may not be any sysadmins who are able to read the local language of the wiki), the admin will have to explain why it nonetheless should be considered sufficiently broad. |
| อนุญาตให้ผู้ดูแลระบบสิทธิแต่งตั้งลบสิทธิผู้ดูแลระบบ | While bureaucrats on some wikis can revoke the administrator flag, at most wikis this is the responsibility of stewards. In order for this kind of request to be accepted, the wiki should be large—with multiple active bureaucrats—and be able to demonstrate a real need for the change. In smaller wikis this ability is prone to abuse by bureaucrats wishing to usurp the power of the community to decide on issues of adminship. |
| กลุ่มพิเศษในวิกิขนาดเล็ก | System administrators may consider wiki size before adding a special user group. Such requests sometimes seem to be motivated by the mere desire to have something that bigger wikis have rather than an actual need. For example, members of the rollbacker group are given a tool that allows them to do with one click the same thing ordinary users can do in a series of steps (revert multiple edits by the same user); in small, low-traffic wikis this speed increase may not be necessary and must be weighed against the potential for abuse. Also, sometimes requests to create a custom group can instead be implemented with an existing user group (such as autopatrolled). In the interest of manageability, sysadmins will not create a new group if an alternative approach can be found. |
Changes that are likely to be stalled, though not declined
This section lists changes that are of course not be declined per consensus, but due to very high technical matters, they won't be handled shortly.
| ประเภทของคำขอ | เหตุผล |
|---|---|
| Change the canonical URL of a wiki | See also: Special language codes, Wiki-setup (rename) and phab:T172035 For several decades, some Wikimedia projects have been using canonical URLs which have problems like using the wrong language code or being otherwise confusing. As of January 2022, the process of renaming wikis and changing their URLs remains a severe technical challenge. So far, only the following wikis have ever been successfully renamed:
Currently the known challenges are related to Wikidata, Special:SiteMatrix, ContentTranslation functions, and interwiki logs. |
Changes made by the system administrators at their own discretion
As noted at Requesting wiki configuration changes, the ultimate authority on Wikimedia configuration lies with the system administrators, as only system administrators can edit it, and as such, are fully responsible for configuration.
As such, system administrators can not only reject requests, but also change configuration on their own. This section aims to explain and document why this might happen, but given the world can be hard to predict, it isn't (and can't be) complete by any means.
In this section, "changes made by the system administrators" are called "measures" for the purpose of simplicity.
Measures are mostly taken to protect the security of the Wikimedia infrastructure, but infrequently, can happen for other reasons as well.
The other reasons aren't mentioned here, because it is hard to predict them.
Examples include (but are not limited to) exceptionally high levels of vandalism, other attempts to disrupt the Wikimedia movement and the like.
Measures can be both permanent and temporary, but temporary measures tend to be more frequent.
System administrators do their best to limit temporary changes as much as possible (in both scope and duration), while still keeping the measures effective.
Any measures may or may not be communicated to the community, as warranted by security implications.
Temporary measures can include (but are not limited to) decreasing the limit of accounts created from one IP address, requiring CAPTCHAs for all edits and the like.
Permanent measures can include (but are not limited to) taking away certain abilities from administrators in favour of dedicated groups or deciding that two-factor authentication is mandated for a user group.