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.
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.
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.
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).
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 think "checking up on whether people did the thing correctly" and "doing the thing" are really different actions. So while I think it's obvious that this would increase the amount of "checking up on each other" work, I'm not sure it's the admins at AfC and NPP that will be shouldering that work, though I'm sure we probably would do so somewhat disproportionately. -- asilvering (talk) 21:44, 25 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).
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 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]
Complicating this, I don't think most AfC reviewers go for "50% likelihood of AfD survival" so much as "I'm more than 50% sure this would survive AfD" - not quite the same thing. I think I'm one of the more lenient AfC reviewers (well, of those among us who aren't socks), and if 25% of my accepts went to AfD I'd be shocked. Also I think people would be telling me to resign. -- asilvering (talk) 21:42, 25 October 2024 (UTC)[reply]
I suspect that you're correct. Just having more than a small number of articles sent to AFD, even if they were all kept in the end, would raise some eyebrows. WhatamIdoing (talk) 22:26, 25 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]
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. — xaosfluxTalk13:53, 17 October 2024 (UTC)[reply]
I'd be tempted to do it slightly the other way around - go ask the editors whose sortition perms are about to expire if they want it taken away, and leave it otherwise, so long as they used it non-disruptively. -- asilvering (talk) 22:32, 25 October 2024 (UTC)[reply]
I think the idea about temporary permissions is that you can't build a fiefdom. Do the work for a designated period of time, and then your turn's up, and someone else takes over to do their best. WhatamIdoing (talk) 02:13, 26 October 2024 (UTC)[reply]
I wonder if we could do this in reverse. Specifically, I worry that the regulars at ANI and COIN (in particular) see so much bad behavior that they develop a distorted view of the community and its goals. For example, if you see an endless parade of accusations about undeclared paid editing because the complainant believes the content to be 'promotional', then you'll start seeing UPE scammers behind everything, even when it's just an ordinary person, not fully aware of our house style[*], trying to write about a subject that interests them. Could we pick a random set of 'regulars' and invite them to take a break for three months? And invite, say, 10x as many uninvolved folks to step up to take their places?
[*] For example, our house style declares that "offices in 26 countries and as of October 2024 in the process of opening offices in two more countries" is okay, but "offices in more than 25 countries" is culpable promotionalism, and the maintenance cost of the first style is unimportant.
I don't like proposal 1. NPP and AfC are the most important roles to encourage new editor–retention. Overzealous deletion/declines can drive new editors, content, and ideas out. (Speaking personally, it also doesn't seem very nice to have your fun revoked after making just 1 goof. The strike thing would be agonizing to enforce. Admins may get angried against for "why did you strike this patroller just because they were too officious, jargony, and laconic and scared a newbie away?". Meanwhile, I see no better alternative to the 1-strike system, therefore I do not like proposal 1.) I don't really see the purpose of proposal 2 as pretty much only editing contentious topics directly without edit request relies on this (who would be autoconfirmed and run for administrator?), and such experience is quite essential towards editing such flamewar-inducing pages directly, but I could be fine with it, I suppose. Aaron Liu (talk) 22:34, 1 November 2024 (UTC)[reply]
Are you assuming that someone new to NPP and AFC would be more likely to delete/decline new articles than the existing folks? I'm not sure that would be true, honestly. WhatamIdoing (talk) 00:38, 2 November 2024 (UTC)[reply]
I don't think this will work. Firstly, we need to at least attempt to establish that someone understands the rules and instructions before we give them these rights. Secondly we don't expect perfection from admins, so one strike and you're out is excessively harsh - particularly as that strike will count against them if they ever want to apply for advanced permissions in the future (whether it should nor it, it will). It will be a big disincentive to actually use the tools, particularly if they have shown no interest in the job (and not using the tools when they had them will be something they have to defend at RFA if they stand). Thryduulf (talk) 03:07, 2 November 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.
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 — c20:23, 17 October 2024 (UTC)[reply]
Oppose. I think the gradients or bevels make these icons less clear and sleek, at least in their current iteration. The icons also become less readable at smaller resolutions since the shackle part of the padlocks takes up more space, making the actual symbol inside smaller.
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. — xaosfluxTalk17: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.
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. — xaosfluxTalk17: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]
I thought we were using "shackle" as the word to describe a thing by a single aspect for the purposes of avoiding conflation with protecting/locking editing. Aaron Liu (talk) 18:13, 2 November 2024 (UTC)[reply]
Well, we shouldn't, because as @WhatamIdoing noted, the shackle is one part of a padlock. And simply using the word "padlock" avoids conflation, without calling things the wrong thing. (It's even the exact same number of letters.) FeRDNYC (talk) 03:55, 3 November 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 not generating more heat than light with this comment, or throwing the baby out with the bathwater. Cremastra — talk — c20:22, 17 October 2024 (UTC)[reply]
Never throw the baby out with the bathwater. This will contaminate your greywater collection system. Like other meats, babies are not compostable, so they should be sorted into the landfill waste stream unless otherwise advised by your municipal waste management authority. Folly Mox (talk) Folly Mox (talk) 20:46, 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]
Just for funStill feel like a step backwards. The current "Good article" icon, on top of having less of a distracting shading and being more readable, is in a consistent style with a lot of our other icons. The current "Featured article" icon, although not consistent with the others, is pretty unique and recognizable in design, while this one looks like a generic star.Just for fun, I did once make a "Good article" star in the style of the FA one – not meant for any official implementation beyond my personal script of course, but it's neat to see how it would look like. Chaotic Enby (talk · contribs) 22:14, 17 October 2024 (UTC)[reply]
Have you ever looked at the Featured Article icon, full-size? (If not, check it out at File:Cscr-featured.png. I'll wait.) ...Like or lump @Chaotic Enby's GA star, it's actually of a fairly harmonious style with the current FA star, which is (as noted) currently not consistent with anything else anywhere. Arguably it's well-known/recognizable — Chaotic makes that argument, anyway — but TBH I have a feeling the great majority of readers never see it larger than head-of-a-pin-scaled, and wouldn't even recognize the actual, full-sized image AS our FA icon. FeRDNYC (talk) 04:10, 3 November 2024 (UTC)[reply]
I have seen the full FA icon; the GA star is just straight out of Cthulhu (...positively). It is fun, but I think GA should be more inline with the rest of the article-rating icons because of the kinda lesser rigor. Aaron Liu (talk) 13:26, 3 November 2024 (UTC)[reply]
To be fair, it's definitely a concept design rather than an actual proposal. If anything, I far prefer having the current GA icon as our official one, as it is more harmonious with basically anything that isn't the FA star. Chaotic Enby (talk · contribs) 22:18, 4 November 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]
Color me baffled. By starting with Re-instating this proposal, you make me think you want to reinvigorate some failed proposal. But then I follow your link and see that the proposal led to the implementation of new padlock icons, which; I guess, you mean to reverse. I also fail to understand what you mean by region-based letter shackles; do you mean for articles about, e.g., Japan? Or articles viewed by somebody we're supposed to have guessed might be in Japan? Or somebody with the Japanese language listed in a userbox on their User page? It's English Wikipedia, so I can't see the last two being useful options, and the first one will only lead to arguments and confusion and we've got that already. The current icons seem clear enough to me, although I don't know how to measure "sleek", I guess. In summary: baffled. — JohnFromPinckney (talk / edits)12:15, 18 October 2024 (UTC)[reply]
I mean region-based letter shackles basically like the letters on shackles but different regional translations. (This'll probably not work because of @Chaotic Enby's post.)
So (just to see if I understand it finally), you're proposing on English Wikipedia that Japanese Wikipedia use icons with Japanese symbology, and Spanish Wikipedia use some Spanish-language indicator on the padlock, etc. Yes? — JohnFromPinckney (talk / edits)22:30, 18 October 2024 (UTC)[reply]
Oppose for now. Status quo is fine. It's really cool that you're contributing your graphics skills to the movement though. I'm sure there's some less high profile areas that could really benefit from your skills. –Novem Linguae (talk) 03:55, 23 October 2024 (UTC)[reply]
Oppose: New proposals are nice but I personally like the style of the old ones better, and flat icons also seem more up-to-date to me. Regional shackles sound like a good idea, but don't appear to be in this proposal, so I'll just say I support those (maybe in the old design-style in my preference). Mrfoogles (talk) 20:22, 23 October 2024 (UTC)[reply]
Oppose per Remsense. The new 3D icons look like something from the early days of the internet. Plus the shadowing makes the icons appear unnecessarily "bulky" (not sure how to say this). Nythar (💬-🍀) 22:33, 25 October 2024 (UTC)[reply]
Oppose here as well. It's not about status quo or resistance to change, I vastly prefer the current icons to the proposed replacements. (Admittedly subjective) points in favor of the current icons over the new ones:
The flatter look will render better at small sizes (since these icons are actually shown at a fraction of the size they're displayed in this thread)
Ditto the blockier font
Ditto the thicker shackle arcs
The skinny shackles and rectangular body give the proposed replacements the appearance of handbags, not padlocks
The letter placement is more uniform and precise in the current icons; the proposed replacements appear to have been "eyeballed". IMHO SVG art of this sort is best hand-coded (if not from scratch, then at least as a finalization pass to clean up the code), with all of the dimensions precise and uniform.
I appreciate the effort, and I'm sorry to be critical, but I'm just not into them at all. The current set, OTOH, are actually fairly well-designed and optimized for their purpose, which is an important consideration in designing functional artwork of this sort. It's puzzling to me that anyone would be looking to replace them, as there's surprisingly little room for improvement IMHO. FeRDNYC (talk) 13:19, 26 October 2024 (UTC)[reply]
I think the proposed sets may been cool at the time of the previous proposal. Those locks would be more appropriate for something like in 2008. It's for the same reason why traffic lights are always (from top to bottom) red yellow green. And why train doors on British trains need doors to have sufficient contrast to the rest (see PRM TSI). In other words, using colour alone for distinguishing isn't enough.
Oppose - not a fan of the proposed icons (see also Nythar's comment), and the current locks work quite well. however, I would be supportive of a redesign of the GA/FA icons (/the various icons of the same style) in a style similar to the current locks. Rexo (talk | contributions) 20:30, 29 October 2024 (UTC)[reply]
What if we kept the shackles and good icon, get a new featured icon, and make a built-in feature that allows shackles to be compatible with dark mode? 2I3I3 (talk) 03:07, 2 November 2024 (UTC)[reply]
(to clarify: the style used by a lot of icons across the wiki (including FA/GA) feels dated, and the locks have a cleaner look that I think could be used as a basis for further redesigns. I don't think that would inherently lead to the quality symbols implying protection.) Rexo (talk | contributions) 13:54, 4 November 2024 (UTC)[reply]
I don't think the Norro or FA icons are dated, and using padlocks to indicate quality just makes no semantic sense. We adopted padlocks because it showed that the article was locked from editing. Aaron Liu (talk) 14:07, 4 November 2024 (UTC)[reply]
Our article Shackle says "A shackle is also the similarly shaped piece of metal used with a locking mechanism in padlocks.[1]". Some here seem confused, but anyone using "shackle" to refer to the handle part of the handbag-looking icon is correct. Anomie⚔21:18, 2 November 2024 (UTC)[reply]
The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion.A summary of the conclusions reached follows.
WP:SNOW: unanimous support to have the ability to hold local SecurePoll elections, including enabling the electionadmin right on enwiki. An RFC to determine how the new right should be distributed can be launched at any time; it may be advisable to advertise that RFC on WP:CENT. Levivich (talk) 14:48, 27 October 2024 (UTC) Levivich (talk) 14:48, 27 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!
Sorry, I wasn't totally clear - this would be for future (admin/ArbCom) elections that the community would like to run. The elections scheduled to start soon will use the existing votewiki system. Joe Sutherland (WMF) (talk) 19:43, 18 October 2024 (UTC)[reply]
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. Thryduulf (talk) 20:35, 17 October 2024 (UTC)[reply]
Support. This would help us host local administrator elections and arbitration committee elecitons that aren't so dependent on the limited bandwidth of the stewards (scrutineers) and WMF T&S (for vote.wikimedia.org setup). By the way, are electionadmins basically checkusers within the SecurePoll tool (being able to see IP information for voters)? So we'd need to make sure that folks that receive that permission are a functionary and/or sign an NDA? –Novem Linguae (talk) 20:35, 17 October 2024 (UTC)[reply]
P.S. Is there a ticket on Phab to separate election checkuser capabilities from election creation/editing capabilities? This might be worth looking into. The person that sets up polls doesn't necessarily need to be the same person that checks all the voters. And it may make sense to have a division here. For example, someone technical can set up SecurePoll, and existing checkusers could do the scrutineering. –Novem Linguae (talk) 20:39, 17 October 2024 (UTC)[reply]
I did some research and it looks like any admin can create a poll, but only electionadmins (scrutineers) can edit a poll or view checkuser-like data on voters. This split is a bit odd, as I think it'd be better if admins could also edit polls that they were added to when the polls were created, so I've filed phab:T377531 to explore that idea a bit further. –Novem Linguae (talk) 23:56, 17 October 2024 (UTC)[reply]
Support to help us implement administrator elections in a more practical way for both us and the WMF. However, will electionadmins be a new user group? They seem to combine characteristics of checkusers and bureaucrats, and I'm not sure whether it would work to bundle the right into either by default. On the other hand, Novem Linguae's proposal of splitting the user right could work better, with a technical-minded crat setting up the poll, while checkusers get the scrutineering right. Chaotic Enby (talk · contribs) 22:20, 17 October 2024 (UTC)[reply]
If I'm reading the code right... yes, electionadmin would either need to be a new user group, or the permissions for it (securepoll-create-poll, securepoll-view-voter-pii) added to an existing user group such as the checkusers. The latter might be simpler than creating a whole new appointment process for electionadmins.
At first glance, I don't see a relationship between bureaucrats and electionadmins. Electionadmins can't grant any user groups, unlike bureaucrats. Again, if I'm reading the code right, any admin can create a poll. –Novem Linguae (talk) 00:01, 18 October 2024 (UTC)[reply]
For the relationship between bureaucrats and electionadmins, it's more to have the same group in charge of regular RfAs and admin elections, and to decouple checkusers from this additional responsibility. But that might be too redundant, and having any technical-minded admin able to do it could be enough, although it would be a major responsibility to give to any admin and might make it more difficult for potential candidates to gain the voters' trust. Chaotic Enby (talk · contribs) 13:14, 18 October 2024 (UTC)[reply]
The technical village pump is for questions about how to do X, whereas how to grant the electionadmin right requires a proposal for a policy, so this page is the appropriate place. Since the right provides access to voter information (as per meta:SecurePoll/Local elections § What does the electionadmin right do?), a process is needed to establish who is trusted with this access. The options I can think of are by consensus discussion, by election, or by appointment (which would push the question up one level on how to decide what group does the appointing). Being part of an existing trusted group, such as those with the oversight right or the checkuser right, could be a requirement to become an election admin. isaacl (talk) 23:35, 17 October 2024 (UTC)[reply]
It might be simplest to grant the permissions securepoll-create-poll and securepoll-view-voter-pii to the checkusers. That way we don't need the overhead of a separate user group or separate appointment process. I think you have to specifically be added to a poll by the poll creator to see its PII, so there shouldn't be any security risk from giving all the checkusers the ability to be added to polls by the poll creator. –Novem Linguae (talk) 00:03, 18 October 2024 (UTC)[reply]
This feels like a major oversight. The admin elections are modeled after WP:ACE but apparently nobody thought about the scrutineers that need to be approved and tooled up each year for ACE. I'm presuming this means the elections are on hold until we clear this up? Just Step Sidewaysfrom this world ..... today00:15, 18 October 2024 (UTC)[reply]
Locally, we have a few options that we could consider if we decide to do polls. First, we don't HAVE to encrypt the database, it doesn't make the votes readily available - but a developer could access them, so that is something to consider (also means not having to deal with key escrow to finalize the election). Additionaly, we don't have to let SP collect private info. We would still have the usernames - it would just prevent using the checkuser info on the securepoll votes. These are all just things to consider if we set up polls - point is that there are options. — xaosfluxTalk13:41, 18 October 2024 (UTC)[reply]
Support Local communities should have the autonomy to conduct elections when they see fit, and not be so dependent on a certain WMF team that has a tight calendar. Also, the inability to conduct separate elections on multiple sites at the same time is a big limitation of the current system that would be addressed by this. – SD0001 (talk) 08:55, 19 October 2024 (UTC)[reply]
Support -- Per SD and Xaos above, I think deploying SecurePoll locally so that individual communities can conduct elections in a autonomous and decentralized manner at the tradeoff of some confidentiality is a good idea in general. Sohom (talk) 14:26, 19 October 2024 (UTC)[reply]
Support An RFC will definitely be necessary to determine who can scrutineer. I imagine we have a few options, the first two I can think of being either assigning the CheckUser group (or perhaps a different set of users?) the electionadmin right, or just creating a new usergroup and having Stewards go ahead and assign it to the relevant scrutineers a week or so before an SP is scheduled to occur, then remove it afterwards. EggRoll97(talk) 03:33, 23 October 2024 (UTC)[reply]
Support I have organized Wikimedia elections for affiliate organizations and after trying open processes, have found that commercial software is the only practical option. The Wikimedia community loves democratic process and elections, but has never had tools to support that. Making an option for SecurePoll has been a longstanding community request since at least 2016 when meta:SecurePoll was set up. Bluerasberry (talk)15:05, 26 October 2024 (UTC)[reply]
The discussion above 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.
Task: When an edit adds an file link without "|(\s*)?frameless" or "|(\s*)?thumb" within it, warn the user and tell them they probably wanted to put a |thumb in. Still allow them to save the edit. Can also scan for every format supported if wanted.
Needs wider discussion but until then, {{EFR}}. The basis for this request is on one accidential removal of a colon. This seems more like something that might be raised at Phab if nothing else, but I don't think we need a filter to warn people to use thumb. EggRoll97(talk) 23:52, 23 October 2024 (UTC)[reply]
Coming from VPR. I'm not sure what our standards are for edit filters enough to be able to comment on the appropriateness of one for this. But I can say that I've certainly been guilty of forgetting to add thumb and not previewing, resulting in situations exactly like the linked diff.
Actually, no, I'm not sure if edit check applies. Its project page defines it as a set of improvements for the visual editor, where I highly doubt editors make this mistake. Aaron Liu (talk) 02:19, 24 October 2024 (UTC)[reply]
Ah, true, I forgot that. In that case, we might want a different sort of warning, perhaps akin to the disambiguation link added one. Sdkbtalk02:24, 24 October 2024 (UTC)[reply]
Might be a good idea for community wishlist more than anything else. I don't think an edit filter is really the best way to go here. Even on a warn-only, it will be catching good-faith edits, and (temporarily) slowing down these contributions. This isn't to say this isn't a problem, just that edit filters may not be the best way to solve it. EggRoll97(talk) 04:39, 25 October 2024 (UTC)[reply]
Technically a lot of the formulas in maths articles are inline images (see e.g. series (mathematics)). These are generated rather than transcluded, but it wouldn't surprise me if there is some edge case where an image is transcluded inline for a similar purpose. Thryduulf (talk) 11:39, 25 October 2024 (UTC)[reply]
There are certainly articles containing inline images for discussing symbols (which may not have straightforward Unicode character representations), e.g. rare historical letter glyphs or musical notation elements (see Archaic Greek alphabets or Mensural notation, to name just two that I happen to have worked on). Yes, I guess articles like these are few, but if an article requires them, it will require them numerous times. Fut.Perf.☼11:59, 25 October 2024 (UTC)[reply]
I don't think that will be scalable, given the number of potential articles and the number of potential images. What might work would be something in the syntax to say "I am intentionally using this image inline" Thryduulf (talk) 12:05, 25 October 2024 (UTC)[reply]
From testing in my sandbox it seems to me that this would work in all cases where there isn't a caption being used as alt text (#10) as that removes the alt text. Glagolitic script#Characteristic uses captions in this manner.
However, when I tabulated the results (Special:Permalink/1253409176) any double pipes were interpreted as table syntax, even inside the file link, so broke things. Which makes things complicated. I'd also like to know if this breaks anything for users of screen readers.
We could also do [[File:Slinky shrewsbury.jpg|inline|]][[File:Slinky shrewsbury.jpg|inline|caption]] for case 1 (no caption) and case 2 (w/ caption). Regex would scan for |inline|. Aaron Liu (talk) 21:04, 25 October 2024 (UTC)[reply]
Another thought is that we'd need to get VE to insert this parameter too, otherwise it would trigger the warning for the next person to edit the source, with the potential for confusion and lost edits. Thryduulf (talk) 01:19, 26 October 2024 (UTC)[reply]
(edit conflict) I agree with both those suppositions, but I don't know if there are other uses than maths articles. However my main point was that good faith reasons for using an inline image, however rare, almost certainly do exist and so there needs to be some provision for allowing them. Thryduulf (talk) 12:00, 25 October 2024 (UTC)[reply]
There are lots of templates that use inline images, so be careful. I general I would say, please don't make too many assumptions about how people should NOT use wikicode. People are for more inventive with the syntax than you expect :) —TheDJ (talk • contribs) 12:05, 25 October 2024 (UTC)[reply]
Thanks for the examples. However, I think we all should refocus the conversation onto the |inline| override idea proposed above. With the override idea, editors adding new inline images can see how to stop the message from popping up again and go on on their merry way. Aaron Liu (talk) 00:52, 26 October 2024 (UTC)[reply]
What you're modeling here – thinking about how a policy/convention could be programmed into editing experiences – is precisely the kind of practice we're intending Edit Check to inspire.
I like and support this idea for that very example you state (geez that was a big image). My one concern related to the warning message encouraging the usage of these parameters, however, is that it needs to be very clear upfront that |frame, |frameless, and |thumb may NOT be used in any combination together since these three are contradictory parameters. When these conflicting parameters do appear together on a single image, it triggers a Bogus/Invalid Image Option syntax error, a Wikipedia tracked error that sprouts a dozen or so new cases daily. I and another editor teamed up this summer and finally eliminated the existing backlog of the 7000+ cases of active Invalid Image Options, and is one of a few error types our little community has caught up with and are keeping mowed down so that it doesn't resprout and grow wild again. My main concern is that if Wikipedia is not clear up front that these cannot be used together, people might think to there is no issue in just adding all the options and being done with it, (a "Heck with it all" reaction) leading to a higher rate of repopulation of this error type. Would stating use only one (to discourage combinations) be effective, or might a second/subcheck message be reasonable on (re)submission in these cases? Zinnober9 (talk) 05:53, 28 October 2024 (UTC)[reply]
A proposed override for the edit filter above is introducing multiple captions, which is also a linter error. Do you know if there's a way to configure the linter extension so that the override is an exception? Aaron Liu (talk) 12:52, 28 October 2024 (UTC)[reply]
That is well beyond my knowledge. Jonesey95 knows more than I do, they might know, but I'd suspect that's more of a question for WMF. If multiple captions were introduced, I'm concerned with how that would work and how are the controls for determining which caption displays. I think the current WP:EIS syntax is fairly straight forward, and people make all sorts of unintended messes with it now. Zinnober9 (talk) 15:50, 28 October 2024 (UTC)[reply]
If multiple captions were introduced, I'm concerned with how that would work and how are the controls for determining which caption displays.
The software currently handles this well: by always only displaying the last caption, as you've probably seen at Thryduulf's sandbox. Aaron Liu (talk) 16:58, 28 October 2024 (UTC)[reply]
I have, as that's how I learned about this discussion. (see discussion User talk:Thryduulf#Image syntax). Multiple captions, while "handled" in the way you expect, are not error-free syntax in current WP:EIS code, and Thryduulf's current sandbox example has four cases demonstrating multiple captions, which are each causing invalid image errors (Lint report page) (cases 10 and 16, 11 and 17). These reported errors from the EIS syntax usage are the objection I have have in regards to this proposal. 22:11, 1 November 2024 (UTC) Zinnober9 (talk) 22:11, 1 November 2024 (UTC)[reply]
Yeah, I understand. Would you have any objections if only adding "|inline|" before another caption would not trigger a linter error? Aaron Liu (talk) 22:23, 1 November 2024 (UTC)[reply]
I'm coming to this discussion late, so forgive me if I misunderstand. I read through it twice, and I don't get it. The proposal is to stop people from inserting File:/Image: calls unless they have thumb or frameless? If that is the proposal, I don't see how it is reasonable. People insert such images all the time and have done so for decades, and things are generally fine. I did a semi-random search for insource:/\[\[File:/ -insource:/thumb/, and I got List of world sports championships, Nephrozoa, Filozoa, Countries of the United Kingdom, Papua New Guinea at the 2015 Pacific Games, PubChem, and more than 100,000 other pages that do not appear to be causing any trouble. I think there may be an XY problem here. – Jonesey95 (talk) 15:31, 28 October 2024 (UTC)[reply]
Not stop completely, give a warning for new additions through an edit filter that won't stop them if they save a second time or include some kind of override. Aaron Liu (talk) 16:54, 28 October 2024 (UTC)[reply]
But why stop or warn at all for a completely valid usage that appears in more than 100,000 pages without a problem? What is wrong, for example, with the image used in the infobox at PubChem, which is not an inline image and does not use thumb or frameless? What is wrong with the image used at Short story, which uses neither thumb nor frameless and is not inline? What is wrong with the map images at Political divisions of Bosnia and Herzegovina, which use neither thumb nor frameless and are not inline? These are just three easily accessible examples from well over 100,000 pages. – Jonesey95 (talk) 03:45, 2 November 2024 (UTC)[reply]
In the PubChem case, I'm not sure if the image was correctly added, as from what I recall the file name should be given directly as a parameter in infoboxes. However, basically every article with a phylogenetic tree, a series template, or a list of countries with flagicons would be affected, which isn't great. Chaotic Enby (talk · contribs) 04:22, 2 November 2024 (UTC)[reply]
Would this stop occur when someone adds a template using {{ambox}} or a similar message box to a page? Those templates use images that are not inline, frameless, or thumbnails. I think this idea may need a significant re-think. – Jonesey95 (talk) 04:39, 2 November 2024 (UTC)[reply]
Looking back the original issue was accidentally transcluding very large (in terms of dimensions) images at full size, which is an issue, but one that is very significantly narrower in scope than the proposed solution would address (and I agree that is not practical). Adding a warning only when the image exceeds say 2000px wide or 1200px high (larger than standard 1080p resolution) is unlikely to inconvenience many pages. My gut feeling though is that this would need to be done in software as whatever generates the warning would to get image dimensions from Commons as part of the parsing of the wikitext. Thryduulf (talk) 04:49, 2 November 2024 (UTC)[reply]
On second thoughts maybe only the width criterion is needed, as something long and thin will just vertically scroll without too much disruption? Most very wide images should probably be using {{wide image}} or thumb. Thryduulf (talk) 04:52, 2 November 2024 (UTC)[reply]
That could work, but, if we wish to tackle the narrow issue of wide images, I am not sure whether an edit filter alone would work. As far as I know, regex can't go in the file page and check its metadata? (Or maybe the edit filters have more capabilities I don't know about) Chaotic Enby (talk · contribs) 15:24, 2 November 2024 (UTC)[reply]
As you've said, that would require quite a bit more work than an edit filter. The issue is also that valid new usages of inline images without a template are quite little. Aaron Liu (talk) 17:05, 2 November 2024 (UTC)[reply]
The issue is also that valid new usages of inline images without a template are quite little. Are you sure about that? There are lots of examples noted in just this thread? How often are problematic (i.e. extremely large) images added inline accidentally? Unless it is significantly more than valid uses of inline images then it's not going to be worth it. Thryduulf (talk) 17:11, 2 November 2024 (UTC)[reply]
How often are valid images added inline? Anecdotally, it happens quite occasionally enough. In fact, its usage at NCAA Division III—one of the results on the first page of search—was a mistake that had been there for 4 years before I fixed it today. I was preparing a paragraph that evaluated the first page of the search results when I realized that I can't find any guidelines on using non-small inline images instead of frameless images within infoboxes and tables, therefore, half of my basis for this proposal may be incorrect. Aaron Liu (talk) 18:09, 2 November 2024 (UTC)[reply]
For the short story case, could you explain which image? If your concern is the sidebar, I'm pretty sure we can exclude the template namespace, which also tends to have arcane wizardry. (Also, the edit filter would not warn just for existing usages. It would only warn on additions and new usages that don't use some e.g. Liechtenstein flag template (it only detects the relevant wikitext)) Aaron Liu (talk) 17:02, 2 November 2024 (UTC)[reply]
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.
I frequently edit articles about small towns in Iowa. When the 2020 US Census results were released, the vast majority of these articles had multi-paragraph summaries of the 2000 and 2010 Census results, usually under the heading "Demographics". The 2010 summaries appear to have been made by a bot, which is no longer active. The 2020 Census results have been available for several years now, and no bot has run through these articles and inserted 2020 Census summaries. For a few of the larger cities in Iowa, editors had added 2020 summaries, but for the vast majority of cities, towns and CDPs, the articles only had 2000 and 2010 summaries. So I updated the 974 articles for the Iowa towns with no 2020 summary, manually (I didn't clobber any exisiting 2020 summaries, unless they had fewer than 3 sentences). I spot checked the situation for other states, and found a similar situation. There may be as many as 40,000 articles that have this issue (for example: Northfield, Minnesota).
I think a case could be made that these articles really don't need extensive summaries of the census results. But I don't think many people would think that these articles should have extensive summaries of past censuses, but not the most recent one. Surely the most recent census is the most relevant. Having the summaries end at 2010 makes the article look abandoned.
Before I edited all those Iowa city articles, I made a Python script that called the US Census Department servers' API, to fetch the data, and the script produced a text block formatted properly for Wikipedia. I think it would be useful to to make a bot to update the articles for other states, but there are tricky issues, and I have never made a Wikipedia bot. Is there anyone who would be willing to work with me to make a bot to do these updates? If this is the wrong place to be asking that, can someone direct me to the correct place? Thanks for any info! PopePompus (talk) 01:51, 27 October 2024 (UTC)[reply]
@PopePompus, you're definitely correct that census data for U.S. cities is a very lacking area.
I'd start by reviewing the discussion here from 2020 — as you'll see toward the end, my view is that we very badly need to be converting this information into template form, rather than copying and pasting it (which is a large part of what has created the mess). I'd then open new discussion at WT:CITIES to get a sense of where current consensus is at. You may also want to look at what information Wikidata has and whether that can be of use. Once you've established consensus there to make changes, bot approvals go at WP:BOTREQ.
Overall, this will certainly be a major project, given the complexity of the information involved and the wide scale at which changes are needed. Good luck! Sdkbtalk04:12, 27 October 2024 (UTC)[reply]
I will just add that a bot created almost all of the articles about places in the US that were enumerated by the US Census in 2000. Many of those articles for years consisted of very little more than the demographic section. I believe that most of the 2010 census data was added manually, generally attempting to follow the 2000 bot-created format. Adding the 2020 census data has been piecemeal, at best. A bot to handle this sounds good, but getting agreement on the format for the data in articles may require some discussion. Donald Albury13:26, 27 October 2024 (UTC)[reply]
I think the mass creation of the articles by a bot was a very good thing. At least in the case of Iowa, most of the articles have accumulated non-bot content. Since the barrier to entry for editing an existing article is far lower than creating a new one, it's safe to say that most of the post-bot content would not ever have appeared absent the bot. I agree with Sdkb that a template is the way to go. I had not seen the 2020 discussion he pointed to, and I found that discussion somewhat disappointing, because a lot of the discussion was about details, rather than focusing on what I think are the major issues: Template or not, should old results be retained in the main body of the text, and perhaps most importantly who's gonna do it. PopePompus (talk) 13:53, 27 October 2024 (UTC)[reply]
Consistency of the Demographics sections across articles about (Census enumerated) populated places in the US is desirable. Unfortunately, I have no experience with bots, and have fallen into the hole of trying to expand articles about almost 80 species in a genus. Donald Albury14:32, 27 October 2024 (UTC)[reply]
I would like to see a bot add this information. Adding the same thing as last time is okay with me, though a complete re-write might eventually be desirable. It looks like Yellowcard has done some work at getting the US census numbers into Wikidata. Perhaps he has the needed skills, or at least is familiar with the format of the database?
(In terms of a complete re-write, imagine that an exact replica would result in these three sentences in the article (in separate sub-sections):
[From 2000] The racial makeup of the city was 95.67% White, 3.29% Native American, 0.17% from other races, and 0.87% from two or more races.
Would it be possible to combine this into a single statement like:
The racial makeup of the city was 88.5% White, 0.5% African American, 1.5% Native American, 1.5% from other races, and 8% from two or more races, representing a decline in <name listed groups with significant change> and an increase in <name other groups> since the 2000 census.
Thanks @WhatamIdoing for the ping. We (a interested user group in the German Wikipedia) have invested a lot of time and effort by extracting the data from the US Census Bureau website/database and uploading it to Wikidata. This is done for data like population, number of households, area, water area, per capita income (which comes from the ACS) etc. The population data is available for the 2010 and 2020 census.
Creating a bot that fetches the information from the Census Bureau's website and creates plain text (!) is a horrible idea to me. The data is available on Wikidata and usable for Wikipedia already (and has been since 2021). The project on German Wikipedia has a bit stopped due to real-life timing issues, but could be restarted. For the German Wikipedia (where article creation by a bot is rejected, for whatever reasons), we use the data in the infoboxes for all US cities that have an article. The data is so reliable that we even have removed the parameters for population and household counts in the infobox - they are fetched from Wikidata no matter what. No manual updating of Census information in the article necessary nor possible any more.
Articles in German face the same issue as in the English Wikipedia - totally outdated, bot-generated and therefore boring Demographics paragraphs. There is a clear consensus that we will not make this mistake again. Data like this should go into the article via templates, not via plaintext. Yellowcard (talk) 16:06, 28 October 2024 (UTC)[reply]
Some editors at the English Wikipedia distrust Wikidata, so relying entirely on Wikidata isn't accepted. They worry that vandalism (or innocent mistakes) will go unnoticed and uncorrected. We also have a substantial group of editors who believe that paragraphs are preferable to infoboxes, or necessary in addition to infoboxes. Between them, I think the most likely outcome is plain old paragraphs. WhatamIdoing (talk) 17:43, 28 October 2024 (UTC)[reply]
The discussion above 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.
White
Silver
Blue
Pink
Gold
Red
Green
Skyblue
Purple
Turquoise
Black
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)
Needs wider discussion but until then, {{EFR}}. The basis for this request is on one accidential removal of a colon. This seems more like something that might be raised at Phab if nothing else, but I don't think we need a filter to warn people to use 
Liechtenstein flag template (it only detects the relevant wikitext)) Aaron Liu (talk) 17:02, 2 November 2024 (UTC)