Limits to configuration changes
Rarely, a local community consensus will emerge for a particular wiki configuration change that is technically feasible to implement, but is rejected by the system administrators. Arguably this is a demonstration of a technocracy, or a necessity to preserve the founding principles and our mission. This page serves to document and discuss cases that might be interpreted as instances of this kind, and to address the underlying issues.
|Site||Request||Community discussion and notes||Estimated consensus|
|Several wikis||Installation of LiquidThreads||hiwiki, ptwiki, zhwiki, svwiki, ...||There was consensus in several wikis. Although the extension is installed on some WMF wikis, it was considered unmaintained and incomplete - and future switching back from LiquidThreads to normal talk pages seemed difficult - so no further installations were allowed.|
|All wikis (not only WMF wikis)||Changes that about timezone options||N/A||As in MediaWiki software, we use PHP timezone database, where it uses IANA Time Zone Database, it's technically and physically impossible to change any names of timezone options. It's only possible to change the default value of timezone in your wiki via changing the $wgLocaltimezone. (See this request that about Ukrainian cities for example.)|
|Some wikis||Allowing non-admins to view deleted content||TBA||Blocked by WMF Legal, see Wikipedia:Viewing deleted content.|
|English Wikipedia||Remove unused accounts after 90 days||en:Wikipedia talk:Delete unused username after 90 days#Straw poll||255 editors fully supported the change; 18 editors opposed it. Rejected for inclusivity reasons.|
|Hindi Wikipedia||Allow bureaucrats to add users into the CheckUser user group||hi:विकिपीडिया:चौपाल/पुरालेख_20#Enable Some User Groups||CheckUser and Oversight permissions can be granted only by stewards (OS was mistakenly allowed for a period, then disabled).|
|Hindi Wikipedia||Enable log of Autocreated accounts in Hindi Wikipedia||hi:विकिपीडिया:नयी सुविधाएँ||Rejected for privacy reasons. The consensus was given to a bunch of requests at the same time.|
|English Wikipedia||Trial for disabling non-autoconfirmed page creation||en:Wikipedia:Village pump (proposals)/Proposal to require autoconfirmed status in order to create articles||2/3 of 500 users according to closer. Rejected for inclusivity reasons.
|Hebrew Wikipedia||Change default image sizes for thumb and gallery to 250px and 200x200px respectively||he:ויקיפדיה:מזנון/ארכיון 302||8 out of 8 editors. Rejected for performance reasons.|
|Swahili Wikipedia||Disable anonymous page creation at sw.wikipedia||About 5 users in favour out of about 15 active. Test allowed for 6 months (until 2015-09-15) while alternatives are being tested locally.|
|Turkish Wikipedia||Disable anonymous page creation at tr.wikipedia||Madde oluşturabilme hakkı||14 users in favour, 2 recusing (out of ~64 very active users).|
|English Wikivoyage||en.Wikivoyage: increase default image thumb size to 270 and change user prefs thumb size choices||Proposal to change default thumbnail size||At least 5 users (no opposes). Rejected for performance reasons.|
|German Wikipedia||Hide the "thanks" log on the German Wikipedia||Kurzmeinungsbild: Dankeschön-Logbuch||«32 people voted for hiding the log, 10 against, 5 have expressed their opinion without voting.» Rejected as «Transparency is a non-negotiable principle of MediaWiki». The users are recommended to seek removal of the log instead if considered useless (T57428).|
|Maithili Wikipedia||Enable Grant Bot Rights Permission for Sysop in Maithili Wikipedia||Enable Grant Bot Rights Permission for Sysop in Maithili Wikipedia||Task sought to allow administrators to add and remove bot flags. While it was allowed for some time in pt.wikivoyage (gerrit change #50181), it was later reverted (gerrit change #276917). Rejected because bot flag granting and removal is a task for bureaucrats where present, or stewards.|
|Wikimedia Commons||Uninstall Flow from Commons||Proposal to uninstall Flow||19 users support, 10 oppose and one abstention. Although this was done on English Wikipedia and Meta, this request has also been rejected due to potential security risks concerns. The Flow topics are handled as implementing $wgFlowReadOnly instead (see phab:T188577). To avoid problems on other wikis, Flow has been uninstalled from all wikis where it has zero topics (see phab:T188812).|
|Site||Request||Community discussion and notes||Estimated consensus|
|Several wikis||Editinterface granting and removing by sysops||—||Permissions to edit the site interface ('editinterface') or other users personal .js or .css files are very sensitive ones. Requests for creating this group locally are likely to be rejected unless there's a well established and large community able to review the activities of the potential future users. If created, this right can only be granted by bureaucrats where present, or stewards.|
|English Wikipedia||Increase autoconfirmed threshold||en:Wikipedia:Autoconfirmed Proposal/Poll: consensus emerged for 7 days/20 edits; only 4 days/10 edits was implemented. The old threshold was 4 days/0 edits. The issue was complicated by the fact that the bug to implement this change specifically requested 4/10 due to conflicting interpretations of the poll.||50 editors supported 4/10 (or less) as the new threshold; 100 editors supported 7/20 (or higher).|
|Indonesian Wikipedia||Disable anonymous page creation and editing on id.wikipedia||id:Wikipedia:Pembatasan hak membuat artikel baru untuk pengguna anonim/Pemungutan suara: consensus emerged supporting disabling both page creation and editing for anons. Only page creation was disabled. Disabling anonymous editing was seen to violate the inclusivity of the Founding principles.||23 editors supported NOANON; 5 editors rejected 1 abstain.|
|Portuguese Wikipedia||Enable CAPTCHA for all edits of non-confirmed users on pt.wikipedia in order to reduce editing activity||pt:Wikipédia:Votações/Voltar a usar o CAPTCHA para todas edições de usuários não-confirmados: the request was partially rejected as "not compatible with the Wikimedia movement's core values"; CAPTCHAs have been instated on 2013-07-30 to be disabled on 2013-12-31 or earlier.||A majority of about 54/63 users voted for the configuration (with 45 asking it to be permanent) before statistics were produced showing e.g. that, without the unconditional CAPTCHA, productive (un-reverted) anonymous edits were about 58% more.|
|Wuu Wikipedia||Some user group change on wuu.wikipedia||wuu:Wikipedia:红茶坊#Usergroup: consensus to add Rollbacker permissions. The original proposal drafted by User:Cosine02 was having requests to add "editinterface" and "abusefilter-log-private" rights. However, with dissuasions by Nbfreeh and Krenair the requests have been dropped.||3 editors supported, only one opposed|
|Estonian Wikipedia||New user right and user group for et.wikipedia.org||w:et:Vikipeedia:Üldine arutelu#Autopatrullija kasutajagrupp: new user right and user group for sole purpose of hiding gadgets from inexperienced users. Declined for scalable manageability reasons.||Adding an already existing group: autopatrolled instead|
- Please add to this discussion.
Some changes are applied inconsistently to a few wikis, and not allowed on others.This should require a more detailed discussion and explanation; including a separate page devoted to that feature or concept, where it is implemented, and what is preventing it being implemented elsewhere. In the long term, any feature should either be available to all wikis or not available according to an explicit calculation (e.g:for performance, some features might become unavailable once a wiki reaches a certain size). The most controversial feature requests:
- Restricting anon and newbie contributions
- Some wikis disallow anon page creation (en:wp). Others have been denied this configuration (tr:wp, sw:wp) with no clear explanation. To be consistent, either those with such a configuration should be testing out removing it for a subset of edits, to smooth the way towards turning it off, or those without it should be able to test out adding it, to smooth the way towards turning it on
- The en:wp request to disallow non-autoconfirmed page creation was phrased as a temporary trial. It was still denied, due to fears of the "long-lasting social ramifications" of such an impacting change; it took a comparable amount of time for any alternative feature to be turned on. The trial was later approved, and implemented in September 2017. The English Wikipedia has a long history of "trials" (started with or without consensus) which became permanent due to the sclerotization of the consensus-gaining process, the most prominent example being the "experiment" of restricting article creation to confirmed users.
- lmplementing LiquidThreads
- The extension was written thoughtfully, even though it was not perfect, and was in use on a few wikis including MediaWiki.org. As of 2013 it was arguably capable of serving some of the smaller wikis (not sv.source, which stopped using it after experiencing too many critical bugs).Yet sv:wp, pt:wp, and zh:wp had their requests to use it rejected, partly out of a fear that it would be hard to switch over and harder still to switch back if it did not become a long-term solution. There has also been a back-burner project for years to implement a better talk-page solution; the idea that one might be forthcoming helped push back on these community requests. Flow is now available instead on most wikis.
Ideas for improving this process:
- Allow individual wikis to try things out for a few months, even when they may be mistakes, unless such things may have an irreversible effect. Perhaps having a standard 3-month trial, with automatic expiry of the change, requiring a thoughtful data analysis before requesting turning it on again. Testing new configurations should be no big deal; getting a large community to vote for a change would be the threshold to justify the sysadmin time needed to make a test possible.
- Features like LiquidThreads that appear to be 'semi-permanent' would benefit from conversion scripts that help migrate a wiki to/from use of that feature. Development of these import/export tools should be considered part of implementing a complete extension; as they have a major impact on how easy it is to turn them on.