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.|
|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||CU can be granted only by stewards. OS was 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||ויקיפדיה:מזנון/ארכיון 302||8 out of 8 editors. Rejected for performance reasons.|
|Swahili Wikipedia||Disable anonymous page creation at sw.wikipedia||Pendekezo: Utaratibu wa kuanzisha makala||4/5 users in favour, 1 recusing.|
|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.|
|Site||Request||Community discussion and notes||Estimated consensus|
|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 (unreverted) anonymous edits were about 58 % more.|
- 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 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.
- Implementing LiquidThreads
- The extension was written thoughtfully, even though it was not perfect, and is in use on a few wikis including MediaWiki.org. As of 2013 it is 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. However, Flow is not designated to be complete for another 2 years, and even then it may decline to handle user talk pages.
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.