Wikipedia:Village pump (proposals)
Policy | Technical | Proposals | Idea lab | WMF | Miscellaneous |
The proposals section of the village pump is used to offer specific changes for discussion. Before submitting:
- Check to see whether your proposal is already described at Perennial proposals. You may also wish to search the FAQ.
- This page is for concrete, actionable proposals. Consider developing earlier-stage proposals at Village pump (idea lab).
- Proposed policy changes belong at Village pump (policy).
- Proposed speedy deletion criteria belong at Wikipedia talk:Criteria for speedy deletion.
- Proposed WikiProjects or task forces may be submitted at Wikipedia:WikiProject Council/Proposals.
- Proposed new wikis belong at meta:Proposals for new projects.
- Proposed new articles belong at Wikipedia:Requested articles.
- Discussions or proposals which warrant the attention or involvement of the Wikimedia Foundation belong at Wikipedia:Village pump (WMF).
- Software changes which have consensus should be filed at Phabricator.
Discussions are automatically archived after remaining inactive for nine days.
Editing Sri Lankan Election 2024 page
[edit]The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Could someone edit this page to show that AKD won. Idk how to edit elections Irindu10 (talk) 15:22, 22 September 2024 (UTC)
- Looks like it has already been done. In the future, it is better to ask this on the article's talk page (here, Talk:2024 Sri Lankan presidential election), as it is more likely to be seen by editors more knowledgeable on this specific topic. This page here is for more wide-ranging proposals, rather than to request specific edits. Chaotic Enby (talk · contribs) 02:30, 28 September 2024 (UTC)
Request for check user is meant to be for request for permission
[edit]The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
OK 132.147.192.240 (talk) 02:21, 28 September 2024 (UTC)
- Hi! Wikipedia:Requests for checkuser is inactive, and has been replaced by Wikipedia:Sockpuppet investigations. Also, while the names might be confusing, it isn't a request for permission, as it wasn't to request to become CheckUser, but rather to request assistance from a CheckUser in a specific situation. Chaotic Enby (talk · contribs) 02:25, 28 September 2024 (UTC)
- Requests for checkuser access are handled by the Arbitration Committee, see Wikipedia:Arbitration Committee/CheckUser and Oversight for details. It's worth noting here though that it is one of the most restricted rights on the project (for good reason) and cannot (by both policy and technical restriction) be granted to IP editors. Thryduulf (talk) 02:34, 28 September 2024 (UTC)
Bring dark mode reporting on-wiki.
[edit]The current system is very convoluted. Being on a fourth level subpage on a different wiki with 90% of the comments not being signed, and using an emoji system for distinguishing resolved/unresolved issues makes it a nightmare for a) finding issues, b) responding, and c) asking for more details. It would be easier to have a page like Wikipedia:Dark mode reports so more editors could help fix issues. We should import the page here and archive the MediaWiki wiki page. Thoughts? @SCP-2000, FeRDNYC, and I Am Andumé: as editors involved there on fixing issues (if I've missed someone feel free to ping them). —Matrix(!) {user - talk? - uselesscontributions} 14:42, 5 October 2024 (UTC)
- Note: When you go to "Report a problem with dark mode" it should land you here: https://www.mediawiki.org/wiki/Reading/Web/Accessibility_for_reading/Reporting/en.wikipedia.org?section=new&action=submit&preloadtitle=PAGEYOUAREON%20dark%20mode%20error&preload=MediaWiki:vector-night-mode-issue-reporting-preload-content . The logged out user/mobile workflow may be different. — xaosflux Talk 20:30, 5 October 2024 (UTC)
- These may be localized by changing these interface messages. However, if we don't have it reported to the page it is being reported to on mediawikiwiki, we should not expect that the software developers and project team will monitor the reports. — xaosflux Talk 23:28, 5 October 2024 (UTC)
- ^ This. Think about whether it's more important to you to have the page structured your way, or more important to have the dev team look at the feedback. Tradeoffs are a fact of life. It's IMO likely that they'd appreciate some improvements to the format, but it's also possible that this is what works best for them (e.g., perhaps omitting sigs solves them a privacy hassle if they import the feedback to a different system? I doubt it, but Chesterton's fence suggests that we shouldn't assume that there is no reason for the unusual format). WhatamIdoing (talk) 00:48, 6 October 2024 (UTC)
- @Xaosflux: I don't think the software team has looked at any of the reports in a while anyway. It looks to be mostly left up to the community. They did some at the start of the dark mode beta, but as the most important features were taken care of, the more minor templates and pages were left to the community. —Matrix(!) {user - talk? -
uselesscontributions} 09:35, 6 October 2024 (UTC) - I agree that the reports from all the wikis should end up in one centralised place so the developers only have to look at one wiki, but I'm not so sure about the status icons. Developers have to be able to read English to make sense of the reports, so can't their status be in English too? Phil Bridger (talk) 11:07, 6 October 2024 (UTC)
- Dark mode isn't just for English Wikipedia, so archiving the page on the Mediawiki wiki and making the communities of all other wikis come to English Wikipedia to make reports isn't ideal. isaacl (talk) 01:37, 6 October 2024 (UTC)
- @Isaacl if we changed the report link here, it would only be for users of enwiki - anyone on the hundreds of other projects would still go to mediawikiwiki unless their project also overrode the default. — xaosflux Talk 02:33, 6 October 2024 (UTC)
- I was responding to the suggestion that the Mediawiki wiki page be archived. isaacl (talk) 02:44, 6 October 2024 (UTC)
- Ah OK, well that's certainly not a decision to be made here. — xaosflux Talk 11:36, 6 October 2024 (UTC)
- I was responding to the suggestion that the Mediawiki wiki page be archived. isaacl (talk) 02:44, 6 October 2024 (UTC)
- @Isaacl: You seem to have misunderstood the proposal. We can archive this page only, we don't need to archive everything for every site. —Matrix(!) {user - talk? -
uselesscontributions} 09:37, 6 October 2024 (UTC)- That's really secondary, but sure if these go somewhere else those could be copied over and a note could just be left there. — xaosflux Talk 11:44, 6 October 2024 (UTC)
- Thanks for the clarification. I do agree with the others who have expressed a preference for a centralized location for error reporting. isaacl (talk) 16:33, 6 October 2024 (UTC)
- @Isaacl if we changed the report link here, it would only be for users of enwiki - anyone on the hundreds of other projects would still go to mediawikiwiki unless their project also overrode the default. — xaosflux Talk 02:33, 6 October 2024 (UTC)
- cc @Jon (WMF) and SGrabarczuk (WMF): who are the members of the WMF Web team. SCP-2000 10:38, 6 October 2024 (UTC)
- An example of a project doing something like this is dewiki, see w:de:Wikipedia:Dark Mode/Probleme for their page. — xaosflux Talk 11:44, 6 October 2024 (UTC)
- I'm reminded of the early visual editor rollout where there were some editors (including at least one WMF employee) spent some considerable time and effort translating user reports left on a page on en.wp into phabricator tickets, often after more testing to verify reports and give details more useful to developers. I'm not involved in the dark mode at all (and I don't personally use it) but if there are volunteers to do something similar then giving people the option of reporting locally with those reports being copied over might work. Thryduulf (talk) 17:12, 6 October 2024 (UTC)
- This is a fundamentally different situation in that, while any Visual Editor issues would generally manifest everywhere, no matter which installation reported the problem, with dark-mode issues the overwhelming majority of cases are addressed by making local content changes (to a specific article or template). A vanishingly small percentage of the reported problems are in any way generalizable beyond the immediate context of the initial report. (So, I agree, it's a bit odd to exfiltrate the reports to a different wiki in the first place; issues with local content — which these are — need to be, and ultimately will end up being, handled locally.) FeRDNYC (talk) 20:38, 6 October 2024 (UTC)
- Hey everyone - wanted to a give a quick reply from the team's perspective. In short - this is totally up to whatever the community finds easier/more comfortable. We had initially set up the system to be more centralized as we did not want to presume which local page each wiki would find more comfortable. That said, we have no concerns with wikis making the change to a local page if preferred, and a few wikis have so far chosen to do this with good results. Some more information on how to do this is available at the top of our general reporting page. Hope this is helpful! OVasileva (WMF) (talk) 19:47, 8 October 2024 (UTC)
- Thank you for clarifying this is OK with the development team, I'll start a survey section now to check community consensus. —Matrix(!) ping onewhen replying {user - talk? -
uselesscontributions} 16:19, 9 October 2024 (UTC)
- Thank you for clarifying this is OK with the development team, I'll start a survey section now to check community consensus. —Matrix(!) ping onewhen replying {user - talk? -
Survey (dark mode reporting)
[edit]Following the response from WMF, I think it's a good idea for a survey to check if we want to proceed further. @Xaosflux, FeRDNYC, SCP-2000, Isaacl, Phil Bridger, WhatamIdoing, and Thryduulf: and any other people, please state your position briefly:
- Support as proposer: Most of the people actually tackling dark mode issues aren't WMF developers now, but volunteers. Dark mode issues are a local issue per FeRDNYC and therefore should be handled locally on this wiki for best results. We can also change the system to something better in the process (including signatures, using archive templates instead of emojis, etc.). —Matrix(!) ping onewhen replying {user - talk? -
uselesscontributions} 16:28, 9 October 2024 (UTC)- @Matrix, are you planning to watch the page and solve the problems? I'm not. WhatamIdoing (talk) 17:02, 9 October 2024 (UTC)
- @WhatamIdoing: yeah I already do so on the MediaWiki page —Matrix(!) ping onewhen replying {user - talk? -
uselesscontributions} 17:16, 9 October 2024 (UTC)- In that case, I defer to whatever you believe will be functional for yourself/anyone else doing the work. If the volume is low enough (one note a week?), then repointing the link to Wikipedia:Village pump (technical) might be better than creating a new page. WhatamIdoing (talk) 17:24, 9 October 2024 (UTC)
- It's more like 3-4 per day. Deferring to VPT sounds like it would cause problems. —Matrix(!) ping onewhen replying {user - talk? -
uselesscontributions} 20:38, 9 October 2024 (UTC)
- It's more like 3-4 per day. Deferring to VPT sounds like it would cause problems. —Matrix(!) ping onewhen replying {user - talk? -
- In that case, I defer to whatever you believe will be functional for yourself/anyone else doing the work. If the volume is low enough (one note a week?), then repointing the link to Wikipedia:Village pump (technical) might be better than creating a new page. WhatamIdoing (talk) 17:24, 9 October 2024 (UTC)
- @WhatamIdoing: yeah I already do so on the MediaWiki page —Matrix(!) ping onewhen replying {user - talk? -
- @Matrix, are you planning to watch the page and solve the problems? I'm not. WhatamIdoing (talk) 17:02, 9 October 2024 (UTC)
- I'm completely neutral on this, commenting here only because I was pinged. Thryduulf (talk) 17:04, 9 October 2024 (UTC)
- Oppose I don't see the point - this involves spending a lot of effort fixing something that isn't really broken. * Pppery * it has begun... 15:11, 12 October 2024 (UTC)
- @Pppery: It is broken though - the page has no archiving, there are no signatures so replying is slow, the current emoji system for responding to issues is substandard, and it's hidden in an obscure location so no one can find it to help fix issues. Also, since there are no signatures, it's a nightmare chasing people to get further details of issues. What part of that isn't broken? —Matrix(!) ping onewhen replying {user - talk? -
uselesscontributions} 11:35, 13 October 2024 (UTC)
- @Pppery: It is broken though - the page has no archiving, there are no signatures so replying is slow, the current emoji system for responding to issues is substandard, and it's hidden in an obscure location so no one can find it to help fix issues. Also, since there are no signatures, it's a nightmare chasing people to get further details of issues. What part of that isn't broken? —Matrix(!) ping onewhen replying {user - talk? -
Implementation
[edit]Okay, the consensus is the people fixing dark mode issues can decide the location, and FeRDNYC has also expressed the current issues with the current system. Dark mode issues are ultimately usually a local problem, and WMF has also said this is technically possible. We would need to do a few things:
- Import the MediaWiki page to enwiki with the options "Copy all the revisions for this page" and "Assign edits to local users where the named user exists locally" (this is important for archiving later).
- Use User:ClueBot III archiving (User:lowercase sigmabot III relies on signatures which won't work out)
- Repoint MediaWiki:Vector-night-mode-issue-reporting-notice-url and make MediaWiki:Vector-night-mode-issue-reporting-preload-content include signatures
- Archive the MediaWiki enwiki page.
I think we can start working on this.
—Matrix(!) ping onewhen replying {user - talk? - uselesscontributions} 08:57, 12 October 2024 (UTC)
- I'm fine doing the transwiki import for this when ready, but I'm not seeing a consensus in the discussion above yet. The "assign local" part is not needed; I doubt anyone at mwwiki will care about that page, we're not going to delete anything there but can just slap a cross-wiki redirect on it. So what next? Someone that hasn't !voted on this above should eventually close this discussion with a result. For the xmlimport part, feel free to ping me at that time. — xaosflux Talk 11:43, 13 October 2024 (UTC)
- Fair enough. I'll wait for consensus to develop (I just got impatient since no once was participating). —Matrix(!) ping onewhen replying {user - talk? -
uselesscontributions} 11:49, 13 October 2024 (UTC)
- Fair enough. I'll wait for consensus to develop (I just got impatient since no once was participating). —Matrix(!) ping onewhen replying {user - talk? -
Sortition for elevated permissions
[edit]Proposal for trial: assignment to a small random group of editors to elevated permissions for a fixed short term by sortition.
- Test 1: Selected extended-confirmed editors, who have edited in the past 100 days, get AfC and/or new page reviewer, which have backlogs. They still have to read the instructions. (PCR is too weak for a practical experiment imo.)
- Test 2: Selected auto/confirmed editors, who edited recently, get bumped into extended-confirmed.
- Rules: Any admin can strike for any behavior at any time; one strike and you're out; no extension of term; no exceptions. Also: you cannot refuse permissions, and your editing or sanction history (but not block history) has no bearing on whether you get or don't get permissions. Every admin and editor with equal permissions capable of oversight will have a readily-accessible list of test editors. (It's not difficult to deduce otherwise.)
- Numbers: As a conservative estimate for a first experiment, maybe 200 editors on both tests simultaneously for 6 months, depending on the activity level of those in the sample -- if 20 editors substantially increase their activity in response, that's measurable and manageable.
The purpose is to increase engagement by somewhat active editors across the spectrum, and perhaps even motivate requests for permanent permissions and adminship down the line. In that spirit, if a test editor loses permissions in the one-strike rule, it should have minimal or zero bearing on requesting permissions in future. This is a learning and motivational experience. That permissions here are ultimately reversible and have oversight means that, on balance, if an ill-behaved editor now ends up being able to credibly seek permissions in future, this model, should it be causative, was indeed a success.
- Research and benefits and cautions
Sortition literature addresses both issues that have zero bearing on WP governance, and issues that are quite important. Additionally, I believe there are issues unique to WP that sortition may address that the literature has not yet done. Review: (TG Bouricius 2013 "Democracy Through Multi-Body Sortition: Athenian Lessons for the Modern Day").
What is proposed is called partial governance by sortition with rotation and mandate (Owen and Smith 2018 "Sortition, rotation, and mandate"). Known and possible benefits and cautions:
- Random selection is more likely to give demographic and ideological representation (Ebadian et al 2022 "Is Sortition Both Representative and Fair?"). While WP editors are not representative of general populations, our adminship is even less representative (in Corple 2016 "Beyond the Gender Gap" p.25: 6% vs 15%+).
- A high barrier to entry of WP adminship and some permissions, combined with thanklessness of tasks and relatively low social prestige, means that we are probably below rate-of-replacement on adminship, and there are backlogs for areas needing permissions. Sortition, if it results in participation, relieves this burden. It also increases representative fairness and ideological diversity to those who would handle the content and administrative backlogs. (Afaik this is a WP-unique issue.) In Polish Wikipedia the exclusionary effect on new candidates of acquaintancy among admins was studied (Spychała et al 2014 "Does the Administrator Community ... Acquaintance Relation?"); so if a similar phenomenon exists in all permissions then sortition would help disrupt it.
- If there is admin corruption (and some editors have claimed as such), sortition is suggested to reduce it (Bagg 2024 "Sortition as Anti-Corruption"). It also potentially is a check against administrative subversion (Sutherland 2011 "What sortition can and cannot do") by cabals of editors, as exposed recently in Croatian Wikipedia.
- On the effects of granting priveliges/power: In (Sassenberg et al 2014 "Power corrupts: revisited"), the relationship of elevated power and a sense of communal responsibility vs individual corruption (whether one is elevated as opposed to the other) is complex with contradictory results in the literature. In general, if people are in a socially-oriented environment and goals, which I'd suggest epitomizes WP editing, then power would orient them toward the former. However, the review also suggests that the perception of power as an increase opportunity or promtion, rather than just increased responsibility, is a big part of the increased motivational effects, which would suggest that since sortition may lower the prestige of elevated priveliges, it would have a negative effect on motivation; but this seems again highly social-context- and goal-dependent in the literature.
My brief literature stroll suggested possible routes for future investigation on WP; for further on power and motivation is Pappas APA 2021; and in particular we might push hard to raise the social prestige of elevated priveliges on WP, as well as their associated social responsibilities, per management papers like (Friedrichs 2023 "The benefits of prosocial power motivation in leadership"). Also while it's tempting to consider, if this experiment is successful, a radical future proposed sortition of admins, akin to the admin-for-a-day proposed in 2012, but per WMF this is not legally doable, the prohibitive priveliges being rollback and deleted material. SamuelRiv (talk) 22:39, 7 October 2024 (UTC)
- I have trouble imagining us (i.e., those of us who have achieved a measure of power and control in the current system) being willing to give up control over permissions, no matter how slight this might be.
- That said, I think that both Test 1 and Test 2 would be worthwhile experiments, and I specifically suggest considering selecting candidates for Test 2 from among those who are nearly EXTCONF anyway (e.g., they have the time but they're short 100–200 edits, or they have the edits, but they're short 1–2 months).
- In terms of the size of the experiment, that really ought to be determined by a Power (statistics) analysis. WhatamIdoing (talk) 17:22, 9 October 2024 (UTC)
- Even if there's an element of power and status to them, the vast majority of what people with advanced permissions do is just drudgery. It seems really unlikely to me that somebody randomly assigned NPP or even admin is actually going to want to use them. And one of the main functions of the perm system is to reduce the attack surface these rights offer by only giving them to people motivated enough to ask for it.
- Also, yes AfC and NPP are backlogged, but 'reviewing the reviewers' is also work and there are very few admins doing it. This would massively increase that workload - who's going to pick up the slack? – Joe (talk) 17:58, 9 October 2024 (UTC)
- I imagine that an editor who receives a note saying something like "You've been given this permission temporarily. Please read up and use it if you want" might use it a few times, at least to try it out. If they have a positive experience, they might request to the perm later through the usual channels.
- Giving a perm only to those motivated enough to ask means that a higher percentage of the requesters is improperly motivated. Undeclared paid editors will be more motivated to ask for the permission than an ordinary volunteer. WhatamIdoing (talk) 18:20, 9 October 2024 (UTC)
- I am quite a fan of sortition for filling real-world positions, both where it is used in many countries (mainly for selecting juries) and for some other positions. A few thoughts on its applicability to Wikipedia:
- I doubt that many people would devote much time to the task, because they have to earn a living, and paying the people selected would cause many other issues.
- Many people would try out their new permissions, but most would drop out.
- There need to be clear success/failure criteria. Too many things are tried here, then clearly fail, but continue to be used because of the sunken cost fallacy (I know this is controversial, but I would class draft space as being one of these).
- I'm sure I could come up with loads more points, both for and against, but I have to go now. Phil Bridger (talk) 19:49, 9 October 2024 (UTC)
- Clear criteria are highly desirable. Unfortunately, I'm not sure that a single metric works (e.g., we don't want to lose these randomly selected editors and we don't want WP:UGLY articles in the mainspace), and it's entirely possible that doing the jobs correctly would result in the selected editors quitting. For example:
- Existing AFC promotions have a very low rate of deletion at AFD. (I believe that the normal rate is about 75%.) Given that they're supposed to promote articles that are likely (i.e., 51%, not 90%) to survive AFD, this means that they are underpromoting and overrestricting.
- If the new AFC people collectively promote articles that get deleted only 40% of the time, that's a sign that they're doing it correctly (still underpromoting, actually), even though theirs are getting deleted more often than older AFC folks. Thie AFD metric would show success.
- But: if each AFD, or the run up to those AFDs, comes with recriminations and complaints about how they're being too "lenient", then the yelled-at editors might quit. The editor-retention metric would show failure.
- If we get mixed results, what should we do? WhatamIdoing (talk) 21:50, 9 October 2024 (UTC)
- Clear criteria are highly desirable. Unfortunately, I'm not sure that a single metric works (e.g., we don't want to lose these randomly selected editors and we don't want WP:UGLY articles in the mainspace), and it's entirely possible that doing the jobs correctly would result in the selected editors quitting. For example:
RfC on In the news criteria
[edit]There is a request for comment on the In the news criteria at Wikipedia:Village pump (policy) § RfC: In the news criteria amendments. voorts (talk/contributions) 23:01, 7 October 2024 (UTC)