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.
When discussion has ended, remove this tag and it will be removed from the list. If this page is on additional lists, they will be noted below.
Should a new pending changes protection level - extended confirmed pending changes (hereby abbreviated as PCECP) - be added to Wikipedia? AwesomeAasim19:58, 5 November 2024 (UTC)[reply]
WP:ARBECR (from my understanding) encourages liberal use of EC protection in topic areas authorized by the community or the arbitration committee. However, some administrators refuse to protect pages unless if there is recent disruption. Extended confirmed pending changes would allow non-XCON users to propose changes for them to be approved by someone extended confirmed, and can be applied preemptively to these topic areas.
It is assumed that it is technically possible to have PCECP. That is, we can have PCECP as "[auto-accept=extended confirmed users] [review=extended confirmed users]" Right now it might not be possible to have extended confirmed users review pending changes with this protection with the current iteration of FlaggedRevs, but maybe in the future.
Support for multiple reasons: WP:ARBECR only applies to contentious topics. Correcting typos is not a contentious topic. Second, WP:ARBECR encourages the use of pending changes when protection is not used. Third, pending changes effectively serves to allow uncontroversial edit requests without needing to create a new talk page discussion. And lastly, this is within line of our protection policy, which states that protection should not be applied preemptively in most cases. AwesomeAasim19:58, 5 November 2024 (UTC)[reply]
It's better than EC, which already restricts being the free encyclopedia more. As I've said below, the VisualEditor allows much more editing from new people than edit requesting, which forces people to use the source editor. Aaron Liu (talk) 03:52, 6 November 2024 (UTC)[reply]
Support, functionally a more efficient form of edit requests. The volume of pending changes is still low enough for this to be dealt with, and it could encourage the pending changes reviewer right to be given to more people currently reviewing edit requests, especially in contentious topics. Chaotic Enby (talk · contribs) 20:25, 5 November 2024 (UTC)[reply]
Support having this as an option. I particularly value the effect it has on attribution (because the change gets directly attributed to the individual who wanted it, not to the editor who processed the edit request). WhatamIdoing (talk) 20:36, 5 November 2024 (UTC)[reply]
Support: better and more direct system than preemptive extended-confirmed protection followed by edit requests on the talk page. Cremastra (u — c) 20:42, 5 November 2024 (UTC)[reply]
Support, Pending Changes has the capacity to take on this new task. PC is much better than the edit request system for both new editors and reviewers. It also removes the downsides of slapping ECP on everything within contentious topic areas. Toadspike[Talk]20:53, 5 November 2024 (UTC)[reply]
Support Agree with JPxG's principle that it is better to "have drama on a living project than peace on a dead one," but this is far less restrictive than preemptively setting EC protection for all WP:ARBECR pages. From a new editor's perspective, they experience a delay in the positive experience of seeing their edit implemented, but as long as pending changes reviewers are equipped to minimize this delay, then this oversight seems like a net benefit. New users will get feedback from experienced editors on how to operate in Wikipedia's toughest content areas, rather than stumbling through. ViridianPenguin 🐧 ( 💬 ) 08:57, 8 November 2024 (UTC)[reply]
Oppose There's a lot of history here, and I've opposed WP:FPPR/FlaggedRevs consistently since ~2011. Without reopening the old wounds over how the initial trial was implemented/ended, nothing that's happened since has changed my position. I believe that proceeding with an expansion of FlaggedRevs would be a further step away from our commitment to being the free encyclopedia that anyone can edit without actually solving any critical problems that our existing tools aren't already handling. While the proposal includes However, some administrators refuse to protect pages unless if there is recent disruption as a problem, I see that as a positive. In fact that's the entire point; protection should be preventative and there should be evidence of recent disruption. If a page is experiencing disruption, protection can handle it. If not, there's no need to limit anyone's ability to edit. The WordsmithTalk to me03:45, 6 November 2024 (UTC)[reply]
The Wordsmith, regarding "However, some administrators refuse to protect pages unless if there is recent disruption as a problem, I see that as a positive.", for interest, I see it as a negative for a number of reasons, at least in the WP:PIA topic area, mostly because it is subjective/non-deterministic.
The WP:ARBECR rules have no dependency on subjective assessments of the quality of edits. Non-EC editors are only allowed to make edit requests. That is what we tell them.
If it is the case that non-EC editors are only allowed to make edit requests, there is no reason to leave pages unprotected.
If it is not the case that non-EC editors can only allowed to make edit requests, then we should not be telling them that via talk page headers and standard notification messages.
There appears to be culture based on an optimistic faith-based belief that the community can see ARBECR violations, make reliable subjective judgements based on some value system and deal with them appropriately through action or inaction. This is inconsistent with my observations.
Many disruptive violations are missed when there are hundreds of thousands of revisions by tens of thousands of actors.
The population size of editors/admins who try to address ARBECR violations is very small, and their sampling of the space is inevitably an example of the streetlight effect.
The PIA topic area is largely unprotected and there are thousands of articles, templates, categories, talk pages etc. Randomness plays a large part in ARBECR enforcement for all sorts of reasons (and maybe that is good to some extent, hard to tell).
Wikipedia's lack of tools to effectively address ban evasion in contentious topic areas means that it is not currently possible to tell whether a revision by a non-EC registered account or IP violating WP:ARBECR that resembles an okay edit (to me personally with all of my biases and unreliable subjectivity) is the product of a helpful person or a ban evading recidivist/member of an off-site activist group exploiting a backdoor.
Oppose, I hate pending changes. Using them widely will break the wiki. We need to be as welcoming as possible to new editors, and the instant gratification of wiki editing should be there on as many pages as possible. —Kusma (talk) 21:47, 6 November 2024 (UTC)[reply]
We already have a similar and larger backlog at CAT:EEP. All this does is move the backlog into an interface handled by server software that allows newcomers to use VE for their "edit requests", where currently they must use the source editor due to being confined to talk pages. Aaron Liu (talk) 23:06, 6 November 2024 (UTC)[reply]
... if the number of protected pages does not increase. I expect an increase in protected pages from the proposal, even if the terrifying proposal to protect large classes of articles preemptively does not pass. —Kusma (talk) 13:08, 7 November 2024 (UTC)[reply]
Most PCECP pages should be ECP pages (downgraded?) as they have lesser traffic/disruption. So, the number of pages that will be increase should not be that much. ~/Bunnypranav:<ping>13:35, 7 November 2024 (UTC)[reply]
@Kusma Isn't the loss of instant gratification of editing better than creating a request on the talk page of an ECP page, and having no idea by when will it be reviewed and implemented. ~/Bunnypranav:<ping>11:25, 7 November 2024 (UTC)[reply]
Oppose — Feels unnecessary and will only prevent other good faith editors from editing, not to mention the community effort required to monitor and review pending changes requests given that some areas like ARBIPA apply to hundreds of thousands of pages. Ratnahastin(talk)01:42, 7 November 2024 (UTC)[reply]
There is a very good reason I reference Community Resources Against Street Hoodlums in my preferred name for the protection scheme, and the answer is generally no since the topic area we are primarily talking about is an ethno-political contentious topic, which tend to draw partisans interested only in "winning the war" on Wikipedia. This is not limited to just new users coming in, but also established editors who have strong opinions on the topic and who may be put into the position of reviewing these edits, as a read of any random Eastern Europe- or Palestine-Israel-focused Arbitration case would make clear just from a quick skim. —Jéské Courianov^_^vthreadscritiques18:21, 7 November 2024 (UTC)[reply]
Oppose, per what JSS has said. I am a little uncomfortable at the extent to which we've seemingly accepted preemptive protection of articles in contentious areas. It may be a convenient way of reducing the drama us admins and power users have to deal with... but only at the cost of giving up on the core principle that anybody can edit. I would rather have drama on a living project than peace on a dead one. jp×g🗯️18:16, 7 November 2024 (UTC)[reply]
Oppose as unnecessary, seems like a solution in search of a problem. Furthermore, this *is* Wikipedia, the encyclopedia anyone can edit; preemptively protecting pages discourages contributions from new editors. -Fastily22:36, 8 November 2024 (UTC)[reply]
Someone who is an expert at configuring mw:Extension:FlaggedRevs will need to confirm that it is possible to simultaneously have our current type of pending changes protection plus this new type of pending changes protection. The current enwiki FlaggedRevs config looks something like the below and may not be easy to configure. You may want to ping Ladsgroup or post at WP:VPT for assistance.
Extended content
// enwiki// InitializeSettings.php$wgFlaggedRevsOverride=false;$wgFlaggedRevsProtection=true;$wgSimpleFlaggedRevsUI=true;$wgFlaggedRevsHandleIncludes=0;$wgFlaggedRevsAutoReview=3;$wgFlaggedRevsLowProfile=true;// CommonSettings.php$wgAvailableRights[]='autoreview';$wgAvailableRights[]='autoreviewrestore';$wgAvailableRights[]='movestable';$wgAvailableRights[]='review';$wgAvailableRights[]='stablesettings';$wgAvailableRights[]='unreviewedpages';$wgAvailableRights[]='validate';$wgGrantPermissions['editprotected']['movestable']=true;// flaggedrevs.phpwfLoadExtension('FlaggedRevs');$wgFlaggedRevsAutopromote=false;$wgHooks['MediaWikiServices'][]=staticfunction(){global$wgAddGroups,$wgDBname,$wgDefaultUserOptions,$wgFlaggedRevsNamespaces,$wgFlaggedRevsRestrictionLevels,$wgFlaggedRevsTags,$wgFlaggedRevsTagsRestrictions,$wgGroupPermissions,$wgRemoveGroups;$wgFlaggedRevsNamespaces[]=828;// NS_MODULE$wgFlaggedRevsTags=['accuracy'=>['levels'=>2]];$wgFlaggedRevsTagsRestrictions=['accuracy'=>['review'=>1,'autoreview'=>1],];$wgGroupPermissions['autoconfirmed']['movestable']=true;// T16166$wgGroupPermissions['sysop']['stablesettings']=false;// -aaron 3/20/10$allowSysopsAssignEditor=true;$wgFlaggedRevsNamespaces=[NS_MAIN,NS_PROJECT];# We have only one tag with one level$wgFlaggedRevsTags=['status'=>['levels'=>1]];# Restrict autoconfirmed to flagging semi-protected$wgFlaggedRevsTagsRestrictions=['status'=>['review'=>1,'autoreview'=>1],];# Restriction levels for auto-review/review rights$wgFlaggedRevsRestrictionLevels=['autoconfirmed'];# Group permissions for autoconfirmed$wgGroupPermissions['autoconfirmed']['autoreview']=true;# Group permissions for sysops$wgGroupPermissions['sysop']['review']=true;$wgGroupPermissions['sysop']['stablesettings']=true;# Use 'reviewer' group$wgAddGroups['sysop'][]='reviewer';$wgRemoveGroups['sysop'][]='reviewer';# Remove 'editor' and 'autoreview' (T91934) user groupsunset($wgGroupPermissions['editor'],$wgGroupPermissions['autoreview']);# Rights for Bureaucrats (b/c)if(isset($wgGroupPermissions['reviewer'])){if(!in_array('reviewer',$wgAddGroups['bureaucrat']??[])){// promote to full reviewers$wgAddGroups['bureaucrat'][]='reviewer';}if(!in_array('reviewer',$wgRemoveGroups['bureaucrat']??[])){// demote from full reviewers$wgRemoveGroups['bureaucrat'][]='reviewer';}}# Rights for Sysopsif(isset($wgGroupPermissions['editor'])&&$allowSysopsAssignEditor){if(!in_array('editor',$wgAddGroups['sysop'])){// promote to basic reviewer (established editors)$wgAddGroups['sysop'][]='editor';}if(!in_array('editor',$wgRemoveGroups['sysop'])){// demote from basic reviewer (established editors)$wgRemoveGroups['sysop'][]='editor';}}if(isset($wgGroupPermissions['autoreview'])){if(!in_array('autoreview',$wgAddGroups['sysop'])){// promote to basic auto-reviewer (semi-trusted users)$wgAddGroups['sysop'][]='autoreview';}if(!in_array('autoreview',$wgRemoveGroups['sysop'])){// demote from basic auto-reviewer (semi-trusted users)$wgRemoveGroups['sysop'][]='autoreview';}}};
I basically came here to ask if this is even possible or if it would need WMMF devs involvement or whatever.
For those unfamiliar, pending changes is not the same thing as the flagged revisions used on de.wp. PC was developed by the foundation specifically for this project after we asked for it. We also used to have WP:PC2 but nobody really knew what that was supposed to be and how to use it and it was discontinued. Just Step Sidewaysfrom this world ..... today21:21, 6 November 2024 (UTC)[reply]
Depends on what exactly is meant by "implementation". A configuration where edits by non-extendedconfirmed users need review by reviewers would probably be similar to what was removed in gerrit:/r/334511 to implement T156448 (removal of PC2). I don't know whether a configuration where edits by non-extendedconfirmed users can be reviewed by any extendedconfirmed user while normal PC still can only be reviewed by reviewers is possible or not. Anomie⚔13:32, 7 November 2024 (UTC)[reply]
Looking at the MediaWiki documentation, it is not possible atm. That said, currently the proposal assumes that it is possible and we should work with that (though I would also support allowing all extended-confirmed to review all pending changes). Aaron Liu (talk) 13:56, 7 November 2024 (UTC)[reply]
I think the RfC summary statement is a bit incomplete. My understanding is that the pending changes feature introduces a set of rights which can be assigned to corresponding user groups. I believe all the logic is based on the user rights, so there's no way to designate that one article can be autoreviewed by one user group while another article can be autoreviewed by a different user group. Thus unless the proposal is to replace autoconfirmed pending changes with extended confirmed pending changes, I don't think saying "enabled" in the summary is an adequate description. And if the proposal is to replace autoconfirmed pending changes, I think that should be explicitly stated. isaacl (talk) 22:06, 6 November 2024 (UTC)[reply]
The proposal did not specify if it assumed co-existence is possible, or enabling it is possible, which could mean replacement. Thus I feel the summary statement (before the timestamp, which is what shows up in the central RfC list) is incomplete. isaacl (talk) 22:31, 6 November 2024 (UTC)[reply]
While on a re-read, It is assumed that it is technically possible to have PCECP does not explicitly imply co-existence, that is how I interpreted it. Anyways, it would be wonderful to hear from @Awesome Aasim about this. Aaron Liu (talk) 22:42, 6 November 2024 (UTC)[reply]
The key question that ought to be clarified is if the proposal is to have both, or to replace the current one with a new version. (That ties back to the question of whether or not the arbitration committee's involvement is required.) Additionally, it would be more accurate not to use a word in the summary that implies the only cost is turning on a switch. isaacl (talk) 22:49, 6 November 2024 (UTC)[reply]
It is assuming that we can have PC1 where only reviewers can approve edits and PCECP where only extended confirmed users can approve edits AND make edits without requiring approval. With the current iteration I don't know if it is technically possible. If it requires an extension rewrite or replacement, that is fine. If something is still unclear, please let me know. AwesomeAasim23:06, 6 November 2024 (UTC)[reply]
I suggest changing the summary statement to something like, "Should a new pending changes protection level be added to Wikipedia – extended confirmed pending changes (hereby abbreviated as PCECP)?". The subsequent paragraph can provide the further explanation on who would be autoreviewed and who would serve as reviewers with the new proposed level. isaacl (talk) 23:19, 6 November 2024 (UTC)[reply]
I think inclusion of the preemptive-protection part in the background statement is causing confusion. AFAIK preemptive protection and whether we should use PCECP over ECP are separate questions. Aaron Liu (talk) 19:11, 7 November 2024 (UTC)[reply]
Q2: If this proposal passes, should PCECP be applied preemptively to WP:ARBECR topics?
Support, including on talk pages. With edit requests mostly dealt with through pending changes, protecting the talk pages too should limit the disruption and unconstructive comments that are often commonplace there. (Changing my mind, I don't think applying PCECP on all pages would be a constructive solution. The rules of ARBECR limit participation to extended-confirmed editors, but the spirit of the rules has been to only enforce that on pages with actual disruption, not preemptively. 20:49, 7 November 2024 (UTC)) Chaotic Enby (talk · contribs) 20:21, 5 November 2024 (UTC)[reply]
Support I'm going to disagree with the "no" argument entirely - we should be preemptively ECPing (even without pending changes). It's a perversion of logic to say "you can't (per policy) do push this button", and then refuse to actually technically stop you from pushing the button even though we know you could. * Pppery *it has begun...20:52, 5 November 2024 (UTC)[reply]
Support (Summoned by bot): While I disagree with ECR in general, this is a better way of enforcing it as long as it exists. Constructive "edit requests" can be accepted, and edits that people disagree with can be easily reverted. I'm slightly concerned with how this could affect the pending changes backlog (which has a fairly small number of active reviewers at the moment), but I'm sure that can be figured out. CFA💬23:41, 5 November 2024 (UTC)[reply]
No, I don't think this is necessary at this time. I think it should be usable there, but I don't feel like this is a necessary step at this time. We could revisit it later. WhatamIdoing (talk) 20:37, 5 November 2024 (UTC)[reply]
No, we still shouldn't be protecting preemptively. Wait until there's disruption, and then choose between PCXC or regular XC protection (I would strongly favour the former for the reasons I gave above). Cremastra (u — c) 20:43, 5 November 2024 (UTC)[reply]
No, I feel this would be a bad idea. Critics of Wikipedia already use the idea that it's controlled by a select group, this would only make that misconception more common. -- LCU ActivelyDisinterested«@» °∆t°14:36, 6 November 2024 (UTC)[reply]
Absolutely not. No need for protection if there is no disruption. The number of protected pages should be kept low, and the number of pages that cry out "look at me!" on your watchlist (anything under pending changes) should be as close to zero as possible. —Kusma (talk) 21:44, 6 November 2024 (UTC)[reply]
I'm not saying such a discussion exists, but changes to Arbitration remedies/discretionary sanctions are something they would want to weigh in on. Arbitration policy (which includes WP:Contentious topics) is in their wheelhouse and this would have serious implications for WP:CT/A-I and any further instances where ArbCom (rather than individual editors, as a discretionary sanction) would need to resort to a 500/30 rule as an explicit remedy. —Jéské Courianov^_^vthreadscritiques04:58, 6 November 2024 (UTC)[reply]
That is not my reading of WP:ARBECR. Specifically, On any page where the restriction is not enforced through extended confirmed protection, this restriction may be enforced by...the use of pending changes... (bold added by me for emphasis). But if there is consensus not to use this preemptively so be it. AwesomeAasim05:13, 6 November 2024 (UTC)[reply]
While I appreciate the forward thinking that PCECP may want to be used in Arb areas, this feels like a considerable muddying of the delineation between the Committee's role and the community's role. Traditionally, Contentious Topics have been the realm of ArbCom, and General Sanctions have been the realm of the Community. Part of the logic comes down to who takes the blame when things go wrong. The Community shouldn't take the blame when ArbCom makes a decision, and vice versa. Part of the logic is separation of powers. If the community wants to say "ArbCom, you will enforce this so help you God," then that should be done by amending ArbPol. Part of the logic is practical. If the community creates a process that adds to an existing Arb process, what happens when the Arbs want to change that process? Or even end it altogether? Bottomline: Adopting PCECP for ARBECR is certainly something ArbCom could do. But I'd ask the community to consider the broader structural problems that would arise if the community adopted it on behalf of ArbCom. CaptainEekEdits Ho Cap'n!⚓05:18, 7 November 2024 (UTC)[reply]
Interesting. I'd say ArbCom should be able to override the community if they truly see such action fit and worthy of potential backlash. Aaron Liu (talk) 12:30, 7 November 2024 (UTC)[reply]
Just a terminology note, although I appreciate many think of general sanctions in that way, it's defined on the Wikipedia:General sanctions page as ... a type of Wikipedia sanctions that apply to all editors working in a particular topic area. ... General sanctions are measures used by the community or the Arbitration Committee ("ArbCom") to improve the editing atmosphere of an article or topic area.. Thus the contentious topics framework is a form of general sanctions. isaacl (talk) 15:22, 7 November 2024 (UTC)[reply]
Regarding the general point: I agree that it is cumbersome for the community to impose a general sanction that is added on top of a specific arbitration remedy. I would prefer that the community work with the arbitration committee to amend its remedy, which would facilitate keeping the description of the sanction and logging of its enforcement together, instead of split. (I appreciate that for this specific proposal, logging of enforcement is not an issue.) isaacl (talk) 15:30, 7 November 2024 (UTC)[reply]
Extended confirmed started off as an arbcom concept - 500 edits/30 days - which the community then choose to adopt. ArbCom then decided to make its remedy match the community's version - such that if the community were to decide extended confirmed were 1000 edits/90 days all ArbCom restrictions would update. I find this a healthy feedback loop between ArbCom and the community. The community could clearly choose (at least on a policy level, given some technical concerns) to enact PCECP. It could choose to apply this to some/all pages. If it is comfortable saying that it wants to delegate some of which pages this applies to the Arbitration Committee I think it can do so without amending ArbPol. However, I think ArbCom could could decide that PCECP would not apply in some/all CTOP areas given that the Committee is exempt from consensus for areas with-in its scope. And so it might ultimately make more sense to do what isaacl suggests. Best, Barkeep49 (talk) 16:02, 7 November 2024 (UTC)[reply]
The "contentious topics" procedure does seem like something that the community should absolutely mirror and that ultimately both the community and ArbCom should work out of. If one diverges, there is probably a good reason why it diverged.
As for the broader structural problems that would arise if the community adopted it on behalf of ArbCom, there are already structural problems with general sanctions because of the community's failure to adopt the new CTOP procedure for new contentious topics. Although the community has adopted the contents of WP:ARBECR for other topic areas like WP:RUSUKR, they don't adopt it by reference but by copying the whole text verbatim. AwesomeAasim17:13, 7 November 2024 (UTC)[reply]
That's not the same structural problem. The community hasn't had a lot of discussion about adopting the contentious topic framework for its own use (in my opinion, because it's a very process-wonky discussion that doesn't interest enough editors to generate a consensus), but that doesn't interfere with how the arbitration committee uses the contentious topic framework. This proposal is suggesting that the community automatically layer on its own general sanction on top of any time the arbitration committee decides to enact a specific sanction. Thus the committee would have to consider each time whether or not to override the community add-on, and amendment requests might have to be made both to the committee and the community. isaacl (talk) 17:33, 7 November 2024 (UTC)[reply]
Prior to contentious topics there were discretionary sanctions. Those became very muddled and so the committee created Contentious topics to help clarify the line between community and committee (disclosure: I help draft much of that work). As part of that the committee also established ways for the community to tie-in to contentious topics if it wanted. So for the community hasn't made that choice which is fine. But I do this is an area that, in general, ArbCom does better than the community because there is more attention paid to having consistency across areas and when a problem arises I have found (in basically this one area only) ArbCom to be more agile at addressing it. But the community is also more willing to pass a GS than ArbCom is to designate something a CT (which I think is a good hting all around) and so having the community come to consensus about how, if at all, it wants to tie in to CT (and its evolutions) or if it would prefer to do its own thing (including just mirroring whatever happens to be in CT at the time but not subsequent changes) would probably be a good meta discussion to have. But it also doesn't seem necessary for this particular proposal. Best, Barkeep49 (talk) 17:41, 7 November 2024 (UTC)[reply]
Q3: If this proposal does not pass, should ECP be applied preemptively to articles under WP:ARBECR topics?
Support as a second option, but only to articles. Talk pages can be enforced solely through reverts and short protections so I see little reason why those should be protected. AwesomeAasim19:58, 5 November 2024 (UTC)[reply]
Support for articles per Aasim. Talk pages still need to be open for edit requests. (Also changing my mind, per above. If anything, we should clarify ARBECR so that the 500-30 limit is only applied in cases where it is needed, not automatically, to resolve the ambiguity. 20:52, 7 November 2024 (UTC)) Chaotic Enby (talk · contribs) 20:20, 5 November 2024 (UTC)[reply]
I agree with Chaotic Enby and Pppery above and think all CT articles should be protected. I am generally not a fan of protecting Talk pages, but it's true that many CT Talk pages are cesspools of hate, so I am not sure where I sit on protecting Talk pages. Toadspike[Talk]20:57, 5 November 2024 (UTC)[reply]
Oppose because I think this is a bad idea. For one thing, just making a list of all the covered articles could produce disputes that we don't need. (This article might be covered, but is it truly covered? Reasonable people could easily disagree about whether some articles are "mostly" about the restricted area vs "partly", and therefore about whether the rule applies.) Second, where a serious and obvious problem, such as blatant vandalism, is concerned, it would be better to have an IP revert it than to mindlessly follow the rules. It is important to remember that our rules exist as a means to an end. We follow them because, and to the extent that, they help overall. We expect admins and other editors to exercise discretion. It is our policy that Wikipedia:If a rule prevents you from improving or maintaining Wikipedia, ignore it. This is a proposal to declare that the IAR policy never applies to the rule about who should normally be editing these articles, and that exercising discretion is not allowed. WhatamIdoing (talk) 20:42, 5 November 2024 (UTC)[reply]
While there's already precedent for preemptive protection at e.g. RFPP, I do not like this. For one, as talk pages (and, by extension, edit requests) cannot use the visual editor, this makes it much harder for newcomers to contribute edits, often unnecessarily on articles where there are no disruption. Aaron Liu (talk) 23:47, 5 November 2024 (UTC)[reply]
Mu - This is basically my reading of the 500/30 rule as writ. Anything that would fall into the 500/30'd topic should be XCP'd on discovery. It's worth noting I don't view this as anywhere close to ideal but then neither did ArbCom, and given the circumstances of the real-world ethnopolitical conflict only escalating as of late (which in turn feeds the disruption) the only other - even worse - option would be full-protection across the board everywhere in the area. So why am I not arguing Support? Because just like the question above, this is putting the cart before the horse and this is better off being discussed after this RfC ends, not same time as. —Jéské Courianov^_^vthreadscritiques02:47, 6 November 2024 (UTC)[reply]
Absolutely not, pages that do not experience disruption should be open to edit. Pending changes should never become widely used to avoid situations like dewiki's utterly absurd 53-day backlog. —Kusma (talk) 21:53, 6 November 2024 (UTC)[reply]
Very strong oppose, again Kusma puts it excellently. Protection should always be the exception, not the norm. Even in the Israel-Palestine topic area most articles do not experience disruption. Thryduulf (talk) 13:50, 7 November 2024 (UTC)[reply]
Since we're assuming that PCECP is possible and the last two questions definitely deal with policy, I feel like maybe this should go to VPP instead, with the header edited to something like "Extended-confirmed pending changes and preemptive protection in contentious topics" to reflect the slightly−larger-than-advertised scope? Aaron Liu (talk) 23:53, 5 November 2024 (UTC)[reply]
I think policy proposals are also okay here, though I see your point. There is definitely overlap, though. This is both a request for a technical change as well as establishing policy/guidelines around that technical change (or lack thereof). AwesomeAasim00:26, 6 November 2024 (UTC)[reply]
If this proposal is accepted, my assumption is that we'd bring back the ORANGELOCK which was used for the original incarnation of Pending Changes Level 2. There's a proposed lock already at File:Pending_Changes_Protected_Level_2.svg, though it needs fixes in terms of name (should probably be something like Pending-level-2-protection-shackle.png or Extended-pending-protection-shackle.png), SVG code (the top curve is a bit cut off), and color (should probably be darker but still clearly distinguishable from REDLOCK). —pythoncoder (talk | contribs)21:43, 8 November 2024 (UTC)[reply]
I think light blue is a better color for this. But in any case we will probably need a lock with a checkmark and the letter "E" for extended confirmed. AwesomeAasim22:22, 8 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.
Okay, to make this clear, The content should NOT be taken down. NSFW and NSFl content needs to be shown because Wikipedia is a censor free website. No content should be treated over the other and NSFW and NSFL content needs to be treated the same as all the others. Now the proposal I will make is that since a lot of kids use Wikipedia to learn stuff and they may come across these things. For the sake of safety, gory, offensive and sexual content should have a blur or a black screen, and in order to view the image, they have to click the image and click I am over 18 or something like for example, they come across the Russo-Ukrainian war. In this article there is a gory picture. What there should be instead is a blur or a black box, the description of the picture still stays, and in order to view the content they have to press the picture, and it will ask for verification, like when you press the picture it says, this picture has gore in it or something like that, then it says you have to be 18 to view the image or something like that, then there is a button saying I am over 18 or something like that, then to view the content just press the button. If this somehow doesn’t work at least have a disclaimer at the top saying there is bad stuff in it. So yeah, here is my suggestion. Datawikiperson (talk) 11:11, 6 November 2024 (UTC)[reply]
This has been proposed many times previously. It has failed for multiple reasons, including what should be censored being highly context and culturally (and even subculturally) dependent - for example person A might wish to blur a photograph of a woman breastfeeding but not a photograph of a gunshot wound, while person B might wish the exact opposite. If you take the view that anything anybody wants to be blurred should be blurred, even if others do not, but that would lead to extremes like all images of people being blurred.
A second reason is that there is no practical reason to apply the setting en-masse. At first glance, images in Commons:Category:Sex and subcategories would seem to be fairly uncontroversial, but that falls apart very quickly when you see what sort of images that would catch, for example:
So it would have be to set for at least each category, without subcategories, and there are at least thousands of them on Commons. At the individual image level you are looking at over 110 million. And that's assuming you can get agreement (per above). Thryduulf (talk) 11:57, 6 November 2024 (UTC)[reply]
I agree with what Lectonar and Thryduulf have said above. If this was implemented it would (since most of our editors are American) be as a very Americo-centric view of what is not safe - it would be Thryduulf's person A's view, not mine. The only way to guarantee safety is to block all images using one of the approaches on the page mentioned by Lectonar, Phil Bridger (talk) 13:17, 6 November 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.
Add AI translation option for translating from English to non-English article.
AI certainly improved a lot by now. It can translate to many non-english language better than traditional translators . My suggestion is to add AI translation option for translating from English to non-English article. User will review the AI translation to see if its correct. It will increase the translation quality. I dont suggest using AI for English article, that could have a devastating impact. Dark1618 (talk) 18:50, 7 November 2024 (UTC)[reply]
That's out of scope here, and would need to be asked on each and every individual language-edition of Wikipedia, as those would be the ones dictating policy for translations into their respective languages. —Jéské Courianov^_^vthreadscritiques19:10, 7 November 2024 (UTC)[reply]
Why would a translation into English be devastating, but a translation from English into any other language be acceptable? English just happens to be that most used language in the world by some measures: beyond that it has no special status. Anyway, we can not decide here what is appropriate for other language Wikipedias. Phil Bridger (talk) 19:33, 7 November 2024 (UTC)[reply]
A sandbox for testing redirects, which redirects to Wikipedia:Sandbox and has a sandbox notice when you click for more information about that sandbox. It can be redirected anywhere and is automatically reverted like all other sandboxes.
What is there to test that this would be good for? If you make a mistake while creating a redirect, you can just fix it. Remsense ‥ 论08:42, 8 November 2024 (UTC)[reply]
The cliche is “Size doesn’t matter," but it does in many things — paintings, sculptures, jewelry, crystals, anything larger or small than usual and even if it’s the usual size if readers don’t know what that it. It makes a difference if a painting is 2” by 3” or 2’ by 3’. Especially in TPOD, because more people will see it, but really everywhere. I suggest that writers be encouraged to provide the relevant size in the text or caption of every photo where it’s necessary and that the editors working on TPOD be strongly encouraged to give the size whenever possible. If the size is not given in the text being referenced, that information is often in the photo's "details," in addition to the editing history. Wis2fan (talk) 04:51, 9 November 2024 (UTC)[reply]
White
Silver
Blue
Pink
Gold
Red
Green
Skyblue
Purple
Turquoise
BlackAgree, 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)
