THERMODYNAMICS

Wikipedia:Village pump (proposals): Difference between revisions

17 October 2024

Line 213: Line 213:

P.S., this might be better suited for the technical village pump, so feel free to move it there if you like. [[User:JSutherland (WMF)|Joe Sutherland (WMF)]] ([[User talk:JSutherland (WMF)|talk]]) 20:07, 17 October 2024 (UTC)

*”’Support”’ enabling. This seems like a perfunctory step needed to facilitate the [[WP:administrator elections|administrator elections]] that we have [[Wikipedia:Requests_for_adminship/2024_review/Phase_I#Proposal_13:_Admin_elections|found consensus to conduct]]. Whether this separate RfC is even needed is debatable, but I think it’ll be easier to just get consensus than to debate whether it’s necessary. [[User:Sdkb|Sdkb]] [[User talk:Sdkb|”’talk”’]] 20:17, 17 October 2024 (UTC)

*”’Support”’. This isn’t a requirement holding for admin elections, arbcom elections (or any other type of elections) but (if I’ve understood correctly) it will reduce the amount of support we need from the WMF when we do hold them. I agree completely with Sdkb’s last sentence. [[User:Thryduulf|Thryduulf]] ([[User talk:Thryduulf|talk]]) 20:35, 17 October 2024 (UTC)

Discussion page for new proposals

The proposals section of the village pump is used to offer specific changes for discussion. Before submitting:

Discussions are automatically archived after remaining inactive for nine days.

« Archives, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212, 213, 214

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)[reply]

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)[reply]
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)[reply]

^ 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)[reply]

@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)[reply]

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)[reply]
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)[reply]

@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)[reply]

I was responding to the suggestion that the Mediawiki wiki page be archived. isaacl (talk) 02:44, 6 October 2024 (UTC)[reply]

Ah OK, well that’s certainly not a decision to be made here. — xaosflux ^Talk 11:36, 6 October 2024 (UTC)[reply]

@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)[reply]

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)[reply]

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)[reply]
cc @Jon (WMF) and SGrabarczuk (WMF): who are the members of the WMF Web team. SCP-2000 10:38, 6 October 2024 (UTC)[reply]
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)[reply]
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)[reply]

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)[reply]
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)[reply]

Thank you for clarifying this is OK with the development team, I’ll start a survey section now to check community consensus. —Matrix(!) _{ping one}^{when replying} {user – talk? – _uselesscontributions} 16:19, 9 October 2024 (UTC)[reply]

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 one}^{when replying} {user – talk? – _uselesscontributions} 16:28, 9 October 2024 (UTC)[reply]
I’m completely neutral on this, commenting here only because I was pinged. Thryduulf (talk) 17:04, 9 October 2024 (UTC)[reply]
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)[reply]

@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 one}^{when replying} {user – talk? – _uselesscontributions} 11:35, 13 October 2024 (UTC)[reply]

I’m just not convinced any of those are worth inventing a new wheel over – the system is not broken in the sense that issues are being reported and fixed. * Pppery * _{it has begun…} 16:19, 17 October 2024 (UTC)[reply]

Just because issues are getting fixed, doesn’t mean it’s happening efficiently. The current system is very inefficient, even if issues are getting fixed. It is still creating lots of friction preventing new users from fixing issues. —Matrix(!) _{ping one}^{when replying} {user – talk? – _uselesscontributions} 18:19, 17 October 2024 (UTC)[reply]

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 one}^{when replying} {user – talk? – _uselesscontributions} 08:57, 12 October 2024 (UTC)[reply]

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)[reply]

Fair enough. I’ll wait for consensus to develop (I just got impatient since no once was participating). —Matrix(!) _{ping one}^{when replying} {user – talk? – _uselesscontributions} 11:49, 13 October 2024 (UTC)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)Not necessarily. If they promote articles with a chance to survive AfD above 50%, and we assume they are uniformly distributed in probability, the average promoted article would have 75% of chance to survive AfD, or in other words get deleted 25% of the time. If they get deleted 40% of the time, there might be a level of overpromotion going on. Chaotic Enby (talk · contribs) 16:38, 16 October 2024 (UTC)[reply]

(I love people who can math.)

I think it depends on your underlying assumptions about the distribution. If you have 10 articles, each with a 51% chance of surviving AFD, and you promote them all, and all 10 get sent to AFD, then you’d expect five to get deleted – and they were all still correct promotions. WhatamIdoing (talk) 16:55, 16 October 2024 (UTC)[reply]

That definitely depends on our hypotheses about the distribution, indeed. If the 10 articles range from 51%, 56%, … up to 96%, then you’d have a lower expectation of deleted articles (2.65 if I mathed correctly). But there’s also a hidden assumption in here, in that an article with 96% chances of surviving an AfD will probably not be sent there to begin with, meaning the deletion rate of articles being sent at AfD will naturally be higher than the total deletion rate.All in all, it would be interesting to have more statistics about both the deletion chance of AfC articles at AfD, and how much AfC articles are underrepresented at AfD to begin with. Chaotic Enby (talk · contribs) 18:18, 16 October 2024 (UTC)[reply]

Deletion stats are difficult to measure retrospectively. It might be something that we need to study prospectively. There’s also the complication of experience: people submitting articles through AFC are not going to have the same deletion rate as people like you and me. WhatamIdoing (talk) 18:51, 16 October 2024 (UTC)[reply]

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. That doesn’t necessarily have to prevent it; the WMF doesn’t set an actual bar for the community review. Therefore, we could have a much lower-pressure, lower-stakes community review of every editor who meets a certain threshold of edits and age to determine eligibility for one day obtaining those rights via sortation, with the sole focus being “is this person likely to abuse rollback or access to deleted material?” (which would almost always lean towards acceptance, since it is automatic, done for everyone, and doesn’t directly grant adminship.) Only arguments and rationales specifically related to that question would be allowed and considered by closers when closing such discussions, not general discussions of whether they’d make a good admin in other ways; and they wouldn’t require bcrat closures or anything. This would then allow admin status to be granted to those editors via sortition because they’d previously passed a community review on the aspects the WMF cares about. –Aquillion (talk) 19:12, 16 October 2024 (UTC)[reply]

the prohibitive priveliges being rollback and. Rollback doesn’t seem very dangerous. I doubt wmf would put their foot down about handing out that one too easily. Agree that wmf would object to handing out view deleted though for legal reasons. This has been well discussed before. –Novem Linguae (talk) 19:19, 16 October 2024 (UTC)[reply]

I don’t think that the WMF cares about Wikipedia:Rollback (which doesn’t even get used much, because Twinkle and other scripts can mimic the same effect). The legal problem is viewdeleted. They have consistently said that they want proof that the community trusts the people who have that particular right (e.g., we trust them not to restore copyvios or re-post uploaded revenge porn to another site). The process of community vetting can change, but there must be a community vetting process. WhatamIdoing (talk) 19:43, 16 October 2024 (UTC)[reply]

(e.g., we trust them not to restore copyvios or re-post uploaded revenge porn to another site). I’ve never heard that. WMF’s stated reason for viewdeleted being sensitive is that they want to be able to say in court that when something is deleted, it is well and truly deleted, and that only vetted individuals will have access to it, rather than it being easily accessible. The vibe I’m getting is to make sure BLP, libel and defamation, etc. stays deleted and that they can argue it is truly deleted in court. –Novem Linguae (talk) 20:40, 16 October 2024 (UTC)[reply]

If someone is restoring the inappropriate here or posting it on other websites, then that’s not “staying deleted”, and nobody could argue that it is, even around the dinner table. We need to be able to trust that admins won’t do that. WhatamIdoing (talk) 21:59, 16 October 2024 (UTC)[reply]

Either way, though, my point is that we can have a more lightweight vetting process focused specifically and exclusively on whether someone is likely to abuse the specific tools the WMF is worried about. Whenever alternative approaches to adminship come up, people bring up that WMF concern, and it’s easily addressed. The WMF isn’t worried about people abusing blocks, or unblocks, or weighing in at WP:AE, or AE enforcement actions; and the (perceived, at least) high risk associated with those things under the current system is what actually makes people reluctant to promote admins and which therefore makes RFAs hard. This is also self-perpetuating in that the fewer admins there are the more impact each one has, raising the stakes of RFA in a way that risks breaking it. The community and the WMF are worried about different things. –Aquillion (talk) 22:34, 16 October 2024 (UTC)[reply]

I agree. This is a solvable problem. Also, it doesn’t have to be solved in the first iteration. We could test the system on a couple of other userrights, and circle back to test some others later. WhatamIdoing (talk) 23:09, 16 October 2024 (UTC)[reply]

Wouldn’t revenge porn etc. be oversighted, not just deleted? jlwoodwa (talk) 04:57, 17 October 2024 (UTC)[reply]

Yes, but admins often revdel serious problems first, before reporting to the oversighters. (Also, that’s not usually uploaded locally.) WhatamIdoing (talk) 05:02, 17 October 2024 (UTC)[reply]

WMF doesn’t care about rollback. We could even auto-promote users to some “been around a while” group that includes all of Autopatrolled, New page reviewer, Page mover, Pending changes reviewer, Rollback and they wouldn’t care. — xaosflux ^Talk 13:53, 17 October 2024 (UTC)[reply]

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)[reply]

Re-instating this proposal, I want to make the icons look more clear and sleek; I will eventually add on more to the icons (such as good articles, audio articles, etc.) I also want to add region-based letter shackles, so for example 拡 (拡張, Kakuchō) would be the Japanese extended-protection icon, same with 満 (満杯, Manpai) for full-protection.

by 2I3I3 (talk) 16:25, 16 October 2024 (UTC)[reply]

Agree with others that these new icons look dated. However, if we are discussing changes to lock icons, then I must say the the purple for upload protected is incongruously gaudy. Cremastra — talk — c 20:23, 17 October 2024 (UTC)[reply]

Pretty strong oppose trying to run a geolocation script on every load to try to make dynamic labels here. If anything (which I also don’t like) labels should follow user interface language. — xaosflux ^Talk 17:39, 16 October 2024 (UTC)[reply]

I understand the differences, I was just suggesting (because I don’t really speak any other language you could propose a specific version) Also, I will later add the letters on the shackles.

by 2I3I3 (talk) 19:16, 16 October 2024 (UTC)[reply]

and icons* 2I3I3 (talk) 19:16, 16 October 2024 (UTC)[reply]

SVG file formats can be translated. See c:Commons:Translation possible/Learn more. WhatamIdoing (talk) 23:33, 16 October 2024 (UTC)[reply]

Oppose making the primary (only) differentiation be color, as that gives out less information then the current scheme and is useless for those without color viewing abilities. — xaosflux ^Talk 17:41, 16 October 2024 (UTC)[reply]

Agree with Xaosflux on this one. Furthermore, the two issues of the old icon scheme (color and “realistic” shading that doesn’t look great on small icons), which were the reasons for the change to begin with, are present on this one too.Regarding the region-based symbols, it would make more sense to display them based on the language edition, and, since each language edition already sets its own standards for this stuff, there isn’t much more we can do. Chaotic Enby (talk · contribs) 18:13, 16 October 2024 (UTC)[reply]

Agree, but only slightly. If you added the letters, it would be better. Also, a solution to your region-basing could be to do a Language-based (like “O” for “Office” would become “S” for “Schoolhouse” in a theoretical “Reversed English”) The Master of Hedgehogs ^(converse) ^(hedgehogs) 14:33, 17 October 2024 (UTC)[reply]

File:New Wikipedia Icons.png Well, here you go! (I made these, CC0 license) 2I3I3 (talk) 17:45, 17 October 2024 (UTC)[reply]

Will those icons/colours work with dark mode? I also agree that letters are essential. Thryduulf (talk) 14:44, 17 October 2024 (UTC)[reply]

Shackles? You mean locks? And they look more like handbags to me. –User:Khajidha (talk) (contributions) 15:47, 17 October 2024 (UTC)[reply]

They’re called shackles File:Pending-protection-shackle.svg 2I3I3 (talk) 17:47, 17 October 2024 (UTC)[reply]

See also Shackle. These are padlocks, and the upper U-shaped bit is the shackle. WhatamIdoing (talk) 20:22, 17 October 2024 (UTC)[reply]

Yet another solution in search of a problem. * Pppery * _{it has begun…} 16:18, 17 October 2024 (UTC)[reply]

Per WP:WIKICLICHE we’ve been asked to not say this quite as much, due to supply chain issues – if we use them too much we could see a huge shortage down the road. But I hope I’m generating more heat than light with this comment, or throwing the baby out with the bathwater. Cremastra — talk — c 20:22, 17 October 2024 (UTC)[reply]

The pseudo-3D shading looks dated compared to the current flat icons. Most modern design systems (including codex, which is the new design system for Wikimedia wikis) are built around flat icons. –Ahecht (TALK
PAGE) 18:36, 17 October 2024 (UTC)[reply]

What about icons such as featured, good, and audio? 2I3I3 (talk) 18:55, 17 October 2024 (UTC)[reply]

These are not visual improvements whatsoever, unfortunately. They are clear regressions in design, and the current icons are fine. Our system is particular to the English Wikipedia, so it’s perfectly appropriate for their design to be relative to the English language.Remsense ‥ 论 19:29, 17 October 2024 (UTC)[reply]

Hello! My name is Joe Sutherland and I’m on the Trust and Safety team at the Wikimedia Foundation. In the past, your community has shown interest in holding elections with SecurePoll — perhaps you already have through votewiki. We are now looking into making this available to local communities to run elections themselves. This will require the “electionadmin” right to be enabled on your project, which is a right that allows access to sensitive information.

As such, it is likely that you will need to run a Request for Comment (or similar process) to ascertain consensus for the implementation of this feature. To help guide such a discussion, we’ve put together a Meta-Wiki page with more information about what enabling the right will mean for your community.

If your community does discuss and decides to move forward with this, T&S would like to support you — please let us know via email ( ca@wikimedia.org ) if and when consensus is reached. Thank you!

P.S., this might be better suited for the technical village pump, so feel free to move it there if you like. Joe Sutherland (WMF) (talk) 20:07, 17 October 2024 (UTC)[reply]

Wikipedia:Village pump (proposals): Difference between revisions

Survey (dark mode reporting)

LEAVE A REPLY Cancel reply

EDITOR PICKS

Superconductivity appears in nickelate crystals under pressure – Physics World

electrostatics – Can external charges affect charges within a cacity inside...

Talk:Tuner (radio)/Gallery RFC: Difference between revisions

POPULAR POSTS

Band 8 Writing Answer for Chart

How much does it cost to fix Axle Seal Leak?

3 Kinds of Toggle Latches and their Different Uses

POPULAR CATEGORY