This is the Village pump (all) page which lists all topics for easy viewing. Go to the village pump to view a list of the Village Pump divisions, or click the edit link above the section you'd like to comment in. To view a list of all recent revisions to this page, click the history link above and follow the on-screen directions.
Discussions older than 7 days (date of last made comment) are moved to a sub page of each section (called (section name)/Archive).
Policy
Looking for guideline, forgot where it is
I recall a while ago, I found and/or was pointed to a guideline that basically stated cosmetic changes to links or templates should not be done if there is no change in functionality or where the page links (such as replacing a link to an redirect with the link to the target page). Can anyone point me into the direction of that guideline? Steel1943 (talk) 19:26, 25 October 2024 (UTC)[reply]
COSMETICBOT is a policy for bots, which includes tools that assist manual editing, and it identifies itself as a general guideline for other "bot-like" purely manual editing. So it might apply with different strength depending on how many such edits someone is doing, how they are doing them, and if/how-much disruption it's creating for other editors working on certain pages. DMacks (talk) 13:30, 27 October 2024 (UTC)[reply]
Date redirects to portals?
16 August 2006 points to the current events portal as a result of this discussion. However, date redirects will continue to come up at RfD, some some wider community discussion and input is helpful on whether or not the current events portal is an appropriate target for mainspace redirects. See also: this ongoing discussion for some context.
The second question is easy: Yes, portals are part of the encyclopaedia. As to the first question, portals are reader-facing content and so I see no reason why they wouldn't be appropriate targets for mainspace redirects, given that uncontroversially target mainspace redirects to reader-facing templates and categories when they are the best target. Whether the port is the best target for a given date will depend on the specific date but in general the portal should always be an option to consider. Thryduulf (talk) 01:32, 30 October 2024 (UTC)[reply]
I agree with this. The portal is definitely not always the best option and it has its limitations, but, as I wrote at WP:RDATE it should be considered and assessed along with mainspace articles. Cremastra (u — c) 01:44, 30 October 2024 (UTC)[reply]
If a namespace doesn't have the same standards as mainspace, then the reader shouldn't be redirected there while possibly not realizing they are now outside of mainspace. Yes, there is more content at Portal:Current events/August 2006 than at 2006#August, but the reader is now facing a decades-old page with no quality control, where links to Breitbart are misleadingly labeled as (AP). Chaotic Enby (talk · contribs) 00:50, 6 November 2024 (UTC)[reply]
Portal does have the same standards as mainspace. That a portal is not up to those standards is no different to an article being in bad shape - fix it. Thryduulf (talk) 00:54, 6 November 2024 (UTC)[reply]
No, because they are not articles. Two things can be held to the same standard without being the same thing. Criterion P1 previously allowed that (indirectly) but it was repealed in 2023 due to lack of use. Thryduulf (talk) 19:42, 7 November 2024 (UTC)[reply]
Then they aren't held to the same standards... More in general, no, they obviously aren't held to the same standards, e.g. a portal page doesn't have to be a notable topic but may be purely decorative or (as is the case with the date pages) be a list of mainly non-notable things, failing WP:NOTNEWS and WP:LISTN. That some standards are the same (BLP, copyvio, ...) can also be said for e.g. user talk pages, and we don't redirect to these pages either. Fram (talk) 20:24, 7 November 2024 (UTC)[reply]
We don't redirect to user talk pages because they aren't reader-facing, so that's irrelevant. We don't hold reader-facing templates and categories to article content policies (because they aren't articles) but we do redirect to them. Don't conflate quality standards with inclusion policies, they are not the same thing. Thryduulf (talk) 21:15, 7 November 2024 (UTC)[reply]
I wasn´t aware that the standards we were talking about were solely quality standards, whatever these may be, and not content standards, sourcing standards, ... I´m sadly not amazed that you consider these irrelevant when deciding what to present to our readers. Fram (talk) 21:37, 7 November 2024 (UTC)[reply]
In theory, I think portals should be held to the same CSD criteria as articles. But of course the A criteria actually only apply to articles. Cremastra (u — c) 22:08, 7 November 2024 (UTC)[reply]
There's a lot of random junk in portalspace, but yes, it is part of the encyclopedia. Just like categories and templates, portals are reader-facing content. CFA💬
I didn't really have super strong opinions on portals until seeing this one link to Breitbart, twice, in a misleading way. This is not okay. I agree with Fram that clearly Portals are not being held up to the same standards as regular articles and it might be a bad idea to redirect readers to them. Toadspike[Talk]23:00, 7 November 2024 (UTC)[reply]
I saw this on CENT, and I am confused by the question. Portal:Current events/2006 August 16 is very different from something like Portal:Belgium, and it doesn't make sense to pretend they are the same to establish policy. And what does "part of the encyclopedia" even mean? "Interpreting a confusing phrase" is a terrible way to decide redirect targets. For the specific question of "Should dates redirect to the Current Events portal rather than to a page like August 2006 ... I don't know. I don't see a compelling reason why they can't, nor a compelling reason why they should. Walsh90210 (talk) 15:45, 8 November 2024 (UTC)[reply]
Hey, that's a nice Portal! Thank you for restoring my faith in portals. Clicking on "Random Portal" took me to Portal:Trees, which is also pretty nice. My opinion is now that yes, portals can be good, but it seems to me that we currently have no Ps and Gs to apply to their content or measure their quality, no consensus about how to direct readers to them, and a very checkered and controversial history of deletion. I really dunno what to do about them. Toadspike[Talk]16:49, 8 November 2024 (UTC)[reply]
No, we should not redirect dates to the current events portal subpages. It's a cross-namespace redirect that takes readers from somewhere they expect to be (an encyclopedia article on the topic "16 August 2006") to somewhere they don't expect to be (a navigational aid(?) that highlights some things that happened that day). I'm not 100% sure what the current events portal subpages are for, but they're not meant to stand in as pseudo-articles in places we lack real articles. Ajpolino (talk) 22:04, 8 November 2024 (UTC)[reply]
Cross-namespace redirects in and of themselves are not a problem. They only cause issues when they take someone expecting reader-facing content to "backroom" content (e.g. project space). Both article and portals are reader-facing content, so this is not an issue. Thryduulf (talk) 22:17, 8 November 2024 (UTC)[reply]
Is there another case where we link a reader from an article to a non-article without clearly denoting it? E.g. I have no problem with the {{Portal}} template folks often use in the See also section. Ajpolino (talk) 01:12, 9 November 2024 (UTC)[reply]
Thanks. Okay, Citeweb is a bad example, not something readers look for but something editors look for. The other 2 are among the 6 existing reader facing redirects to templates (from Category:Redirects to template namespace, the only ones which are from mainspace and not editor-related like the cite templates). Not quite the "lots" you seemed to be suggesting throughout this discussion, but extremely rare outliers which should probably all be RfD'ed. Fram (talk) 11:42, 10 November 2024 (UTC)[reply]
Yes, the current events portals are valid redirect targets for dates and preferred in this case of the best article redirect for a specific date being the month section of an article on an entire year. I agree with Fram that portals are not held to the same standards as articles, but I disagree with Ajpolino's stance that a cross-namespace redirect is so disruptive that they are prohibited in all cases, given that WP:Portal says "portals are meant primarily for readers." ViridianPenguin 🐧 ( 💬 ) 23:46, 8 November 2024 (UTC)[reply]
Commenting strictly on the "are portals part of the encyclopedia" question, yes it is. Unfortunately there was one extremely loud, disruptive voice who kept making portals less useful and suffocating any discussions that would make it more beneficial to readers. Plenty of willing portal contributors, including myself, left this space and readers are still reaping the seeds of what that disruptive user planted even after they have been ArbCom banned over a year ago. So it may given some people an illusion that portals aren't doing much towards the encyclopedic goal, because the current status is handicapped by its history. I'm reserving my views on the redirect part of the discussion. OhanaUnitedTalk page07:29, 9 November 2024 (UTC)[reply]
Not, portals are not held to the standards of articles, and if something for whatever reason shouldn't be or can't be an enwiki article, this shouldn't be circumvented by having it in portalspace. Either these date pages are acceptable, and then they should be in mainspace. Or they are not what we want as articles, and then we shouldn't present them to our readers anyway. Fram (talk) 11:42, 10 November 2024 (UTC)[reply]
These current events pages differ from articles in many respects, but the referencing standards are similar. Whether they happen to be prefixed by "Portal:" or not is not reflective of their quality. J947 ‡ edits23:18, 11 November 2024 (UTC)[reply]
The current events portal example listed seems encyclopedic enough, in that apart from some formatting differences it might as well be a list article, but I've seen other portals that have editor-facing content that is more dubiously appropriate for mainspace. Consider, for example, Portal:Schools § Wikiprojects (capitalization [sic]) and Portal:Schools § Things you can do, and the similar modules at many other portals. Sdkbtalk18:27, 13 November 2024 (UTC)[reply]
Issues with antiquated guideline for WP:NBAND that essentially cause run of the mill non-notable items to be kept
5.) Has released two or more albums on a major record label or on one of the more important indie labels (i.e., an independent label with a history of more than a few years, and with a roster of performers, many of whom are independently notable).
6.) Is an ensemble that contains two or more independently notable musicians, or is a musician who has been a reasonably prominent member of two or more independently notable ensembles. This should be adapted appropriately for musical genre; for example, having performed two lead roles at major opera houses. Note that this criterion needs to be interpreted with caution, as there have been instances where this criterion was cited in a circular manner to create a self-fulfilling notability loop (e.g., musicians who were "notable" only for having been in two bands, of which one or both were "notable" only because those musicians had been in them.)
These appear to have been put together by a very small number of editors over a decade ago and hasn't seen much change since then and I feel it's much more lenient than just about anything else. This SNG defines a "label" that has been around for over "a few years" that has a roster of performers as "important". So, any group of people who have released two albums through ANY verifiable label that has exited for more than a few year can end up being kept and this isn't exactly in line with GNG. I believe a discussion needs to be held in order to bring it to GNG expectations of now.
Especially given how broadly the various criteria have been "interpreted" in deletion discussions, the best way to go about it is just to deprecate the whole thing. Rely on the GNG for band notability, and if that results in a heap of articles on ephemeral outfits, garage bands and local acts vanishing, huzzah. Ravenswing 09:07, 30 October 2024 (UTC)[reply]
The SNG isn't workable in the age of digital distribution. It's very easy to create "an independent label with a history of more than a few years". If someone wants to suggest a way to reform the SNG, I am open to solutions. But deprecation is a simple alternative if we can't. The GNG is always a good standard because it guarantees we have quality sources to write an article. Shooterwalker (talk) 14:22, 30 October 2024 (UTC)[reply]
I was active in AfD discussions when NBAND was pretty new, and it was useful for dealing with a flood of articles about garage bands and such, but I think our standards in general have tightened up since then, and I agree it is time to review it. There is the possibility, however, that revising NBAND may require as much discussion as revising NSPORT did. Donald Albury17:49, 30 October 2024 (UTC)[reply]
I guess the underlying question is: Is there actual harm in having a permastub about a band that proves to be borderline in GNG terms? Consider this:
"Alice and Bob are a musical duo in the science fiction genre.[1] They released their first album, Foo, in 2019 and their second, Bar, in 2020. Both albums were released by Record Label.[2] They are primarily known for singing during a minor event.[3]"
I'm asking this because I think that the nature of sources has changed, particularly for pop culture, since NBAND and the GNG were written. We now have subjects that get "attention from the world at large", but which aren't the Right™ kind of sources and, while these Wrong™ sources definitely provide "attention", some of that attention might not provide biographical information (which means we're looking at a short article).
For example, instead of getting attention in the arts section of a daily newspaper, they're getting attention from Anthony Fantano on YouTube. He's an important music critic,[1] but I suspect that our knee-jerk reaction is "Pffft, just some YouTuber, totally unreliable". Consequently, we might rate a band that we theoretically intend to include ("attention from the world at large") as not meeting the GNG (because the whole field relies on the Wrong™ style of sources). WhatamIdoing (talk) 19:02, 30 October 2024 (UTC)[reply]
Keep in mind that like most other notability guidelines, it is a presumed assumption that a topic is notable if it meets these criteria. If you do an exhaustive Before and demonstrate there is no significant coverage beyond the sourcing to satisfy there criteria, the article should still be deleted. None of the SNGs are geared towards preventing this type of challenge. — Masem (t) 19:30, 30 October 2024 (UTC)[reply]
If we had to yield to presumptive notability about some random band because it released two albums with Backyard Trampoline Recordings established few years ago and had to do exhaustive search to disprove notability, we're getting setup for a situation where removal is 10x more challenging than article creation. So.. I see a great value in scrapping NBAND 5, and 6. Graywalls (talk) 00:47, 31 October 2024 (UTC)[reply]
Welcome to WP:SNGs. As Masem said, they're supposed to be a rough idea of gauging notability before exhaustively searching for sources. But pretty much all of them have ended up being used as means to keep articles about trivial or run-of-the-mill subjects. Thebiguglyalien (talk) 19:37, 30 October 2024 (UTC)[reply]
Graywalls listed two criteria but the main discussion seems to be about the 1st (#5). I agree with Graywalls on that. With the evolution of the industry, the label criteria is no longer a useful indicator as it once was and IMO #5 should be removed or modified. Sincerely, North8000 (talk) 19:13, 30 October 2024 (UTC)[reply]
I've noticed that as well. I think #6 has some value still, while #5 is like saying an author who has published two or more books by a major publishing house is presumed notable. Way too low a bar without requiring some level of reception of those albums/books. (WP:NAUTHOR doesn't have that 2-book criteria, of course, just seems like parallel benchmarks.) Schazjmd(talk)13:25, 31 October 2024 (UTC)[reply]
On the other hand, in this case, I suspect that an artist that "has released two or more albums on a major record label or on one of the more important indie labels" will in 99% of cases have enough coverage to clear the GNG bar. I'd like to see an example of one that doesn't. Black Kite (talk)13:29, 31 October 2024 (UTC)[reply]
The definition of important as said in #5 is "history of more than a few years, and with a roster of performers, many of whom are independently notable". This would mean that a garage band is notable, because they've released two CD-R albums on Rotten Peach Recordings which has been around for 3 1/2 years, has a roster of performers and some of whom have a Wikipedia page on them. Often time "notable" is determined by the presence of a stand alone Wikipedia page. When you look at the page, many band member pages are hopelessly non-notable, but removal takes an AfD. So a simple deletion can become a time consuming multi-step AfD. Graywalls (talk) 19:18, 31 October 2024 (UTC)[reply]
Not opining on that band's notability, but Metal Blade is a famous independent label that has existed for 42 years, has released material by very high-profile bands, and is distributed by Sony - it's not some one-person imprint operating out of their garage. Black Kite (talk)11:28, 1 November 2024 (UTC)[reply]
One suggestion I would add is to make these two criteria apply only to bands before a specific year, that year being where physical releases still dominated over digital sales. I don't know the exact year but I am thinking it's like around 2000 to 2010. There may still be older groups during the time of physical releases that don't yet have articles that would fall into one of these criteria. Masem (t) 20:02, 31 October 2024 (UTC)[reply]
As someone who's had WP:DSMUSIC watchlisted for most of their editing history, and who tends towards deletion at that, I actually don't see much of a problem with these criterions. It certainly seems true that the majority of musicians who are signed to a label or a member of multiple bands with two other musicians who meet WP:GNG themselves meet GNG. I do think it is sometimes justified to accept less-than-GNG sourcing in articles where a SNG is met (see Wikipedia:Articles for deletion/John LeCompt for this as it applies to c6 specifically) and more importantly, NMUSIC contains language that allows deleting articles even where it is technically met (see Wikipedia:Articles for deletion/Rouzbeh Rafie for an extended argument about that. Mach6123:29, 31 October 2024 (UTC)[reply]
I've understood these criterion to be supplementing GNG, that is, that if a band or individual artist meets one or more of these criterion, they *likely* are notable. However, in the past when I was a younger and less experienced editor, I think I did understand these as being additions or alternatives to GNG. So I think that should be clarified. This has come up on the deletion discussion for Jayson Sherlock. He is a member or former member of several very notable bands, and for that reason I presumed that he would easily have independent coverage about him specifically. However, to my surprise, there's only one interview of him in a reliable source that would provide notability (there's some interviews on personal blogs or minor sites that wouldn't be RS except for him making statements about himself). But at least one editor has used the above criterion to argue that the article should be kept.--3family6 (Talk to me | See what I have done) 12:20, 1 November 2024 (UTC)[reply]
Just as an aside, interviews do not contribute to GNG unless they include secondary independent SIGCOV (such as a substantial background introduction by the interviewer). JoelleJay (talk) 15:39, 1 November 2024 (UTC)[reply]
That's how I see most SNGs (and the outliers ought to follow their lead). At the very least, we can clarify that NBAND is meant as an indicator for the GNG, and not a substitute. Shooterwalker (talk) 02:04, 2 November 2024 (UTC)[reply]
As someone who thought the old NSPORTS was wildly overinclusive and needed cleanup... these NBAND guidelines don't seem that bad? If two plainly notable musicians were discovered to have done some obscure team-up in the 1970s, that does indeed seem to be a notable topic and useful to have linked somewhere, even if there isn't tons of info on this collaboration. It's worth mentioning because minor subtopics are often merged to the overarching topic (e.g. songs to the album), but there may not be a clear merge location for this if both parties were equal contributors, and a short separate article is an acceptable compromise. Similarly, the complaint about #5 seems to be about just how "indie" the hypothetical label is, but this seems like a solvable problem. If a band fails GNG, that implies that either their two albums really were from a very obscure indie outfit and thus also fail NBAND, or else that we have some sort of non-English sources issue where we may consider keeping on WP:CSB grounds (i.e. that sources probably do exist to pass GNG, but they're difficult to find, and we can trust they exist because this was a major and notable label releasing the band's work). About the only suggestion I can offer is that the comment in 6 about avoiding circular notability could probably be phrased in the sense of GNG, i.e. that the two notable musicians need to both meet GNG and then this will create a new, safe NBAND notability for their collaboration. SnowFire (talk) 17:36, 4 November 2024 (UTC)[reply]
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.
To anyone unfamiliar with this, admin recall is a new process that is exactly what it sounds like. Currently, there is a 30 day petition period: if 25 people sign it, the admin then needs to pass a new RfA within 30 days to keep the tools. Should we change the petition period?
Option A: Keep the petition period the same (30 days)
Option B: Change the petition period to 7 days
Option C: Some other time period (like 14 or 15 days?) that's longer than a week but shorter than a month.
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.
Drm310 and I have a polite disagreement on the interpretation of WP:PAID, and I may very well be mistaken. What is very clear is if an editor is an employee of a company, they are a paid editor. What's not clear is what happens if the editor is the owner of a company. Sure, there's a conflict of interest, but are they a paid editor? I'll quote Drm310, as he says it better than me. "They said that they were a company owner and not an employee. You said that makes them a paid editor. I always interpreted the policy as: if a person is receiving (or expecting) compensation as part of their job, then they're a paid editor. But if they have an ownership stake in the company/organization, then they fall outside the definition of employee. Are we now interpreting it so that owners are paid editors too, because they are drawing an income from their business?" My position is that an owner of a company counts as a paid editor by virtue of the ownership (they don't even need to be drawing an income). Is that position correct, or is it a step too far wrt WP:PAID? --Yamla (talk) 15:25, 4 November 2024 (UTC)[reply]
I would read it as you do, @Yamla:; they have a vested interest in the company being successful, which, in my book, ultimately means getting "something" out of it (which in most cases will mean an income of sorts). Reading it differently smacks slightly of (wiki-)lawyering. Lectonar (talk) 15:35, 4 November 2024 (UTC)[reply]
Hmm. Well, Lectonar, it has always seemed to me that the line "you stand to gain from your editing, so it's effectively paid, even if you aren't actually paid for the editing" is wikilawyering, so evidently that's a matter of point of view.
I have always taken it that paid editing does not include editing about one's own business, in line with what Drm310 says, but my experience is that many, perhaps most, administrators take it the way that Yamla and Lectonar do. In a way it doesn't make much difference, as in either case the conflict of interest issue applies, but there are ways in which it may make a difference. In my opinion the most important way it may make a difference is the purely practical consideration that most owners of businesses writing about their own businesses don't recognise "paid editing" as a description of what they are doing, so it is, in my opinion, more helpful to use other wording which they will be more likely to understand than insisting "yes it is paid editing". (There's already enough of a problem with: "No, I'm not paid to edit Wikipedia, it's just part of my job" ... "Yes, but if it's part of a job that you are paid for then it's paid work" ... "Yes, but..." without adding another layer of room for misunderstanding.) I therefore think it's more helpful to treat the expression "paid editing" as not applying to editing about one's own business.
Theoretically it isn't up to us to decide what the expression means, because it's part of the Wikimedia Foundation's terms of use, over which we have no jurisdiction. However, those terms of use refer to "each and any employer, client, intended beneficiary and affiliation" and as far as I can see there is no definition or clarification of the word "affiliation", so that doesn't really help. JBW (talk) 16:10, 4 November 2024 (UTC)[reply]
I'm of the opinion that PAID applies to owners, but the wording of WP:PAID is ambiguous enough that a reasonable person might very well disagree with that opinion, and I think that should be clarified on that page. An owner of a company can still be an employee of that company (e.g. if the company is set up as a C corporation they can be considered an employee for tax and insurance purposes). I don't think the applicability of the paid-contribution disclosure should change depending on how you structure your company if the role in the company is similarly situated. If you are compensated by working at a company as an owner or otherwise, that needs to be disclosed. Even situations where an owner does not receive direct financial payments or dividends from their ownership of the company (like with a smaller startup company) they would still need to disclose that under WP:PAID, as money is not the only form of compensation. Even in a sole proprietorship they are directly paid for their work at the company, the same as if they were an employee. Owning the company should not be a loophole precluding the need for disclosure. - Aoidh (talk) 16:48, 4 November 2024 (UTC)[reply]
@Aoidh: Has anyone suggested that it should preclude the need for disclosure? If they have, I haven't seen where tgey have done so. I assumed it was obvious that there is a need for disclosure of one's position because it is a conflict of interest. JBW (talk) 22:30, 4 November 2024 (UTC)[reply]
@JBW: I'm sure I've seen it come up but I can't recall where. Someone with a COI reading Wikipedia:Conflict of interest might reasonably assume that if they are not considered a paid editor, then they are not required to disclose anything. The difference between the PAID verbiage (required...requirement..you must disclose...you must not use administrative tools for any paid-editing activity) contrasts with the less strict wording of non-PAID COI (expected to disclose...should disclose...COI editing is strongly discouraged). The section Wikipedia:Plain and simple conflict of interest guide#Disclosure also makes this distinction. I'm not saying I don't think COIs should be disclosed, but someone with a COI who is going to split hairs about whether an owner of a company make one a paid editor would be likely to split hairs there as well. - Aoidh (talk) 23:51, 4 November 2024 (UTC)[reply]
Jessintime I do not intend to tell you that your opinion on this as "absurd"; I prefer to just say that I respectfully disagree. You may like to consider which of those two approaches is more constructive. JBW (talk) 16:28, 4 November 2024 (UTC)[reply]
Jessintime OK, thanks for clarifying that. However, having looked at the article that you have linked, I am wondering what the absurd result you think would ensue. What is it that an owner of a company would be allowed to do which an employee wouldn't? Certainly not editing without disclosure of conflict of interest. JBW (talk) 22:36, 4 November 2024 (UTC)[reply]
From the policy page: Interns are considered employees for this purpose. So unpaid interns count as paid editors when editing the Starlink Wikipedia article for their employer. But edits by Elon Musk would not count as paid editing. That sounds like an absurd result to me. Do I misunderstand the policy? BusterD (talk) 19:42, 4 November 2024 (UTC)[reply]
Someone who has a few shares in a large company is one of its "owners" in law, but likely doesn't have a big enough financial stake in it to amount to a COI in Wikipedia terms. Someone who has most of the shares in a small company, on the other hand, has a COI.—S MarshallT/C22:10, 4 November 2024 (UTC)[reply]
If I may extend your example, if I were in the business of stocks or futures, I might actually have a stake (direct or otherwise) sufficient to put me in direct conflict, no matter which company is the subject. BusterD (talk) 23:00, 4 November 2024 (UTC)[reply]
I have just seen a message on Yamla's talk page, where I think he makes a point that I have tried to make, but he has expressed it perhaps more clearly than I have. He said: "In the end, whichever way the consensus goes, I think the combination of WP:PAID and WP:COI means the end result (though not the communication) ends up the same." Many of the comments above appear to be based on the assumption that not interpreting "paid editing" as including owner-editing would mean letting owners edit without disclosure, but it wouldn't. JBW (talk) 22:50, 4 November 2024 (UTC)[reply]
Thanks for copying my comment here, JBW. In my initial post, I meant "Sure, there's a conflict of interest" to cover this point, but failed to be clear. I do think the communication around paid editing is important, even if the end result (user has to declare a conflict) is the same. This is frequently a challenging concept to communicate to new editors. --Yamla (talk) 22:56, 4 November 2024 (UTC)[reply]
I think there may be a more fundamental misunderstanding of WP:PAID here than you think. Paid editing is about people being paid to edit. Let's take What is very clear is if an editor is an employee of a company, they are a paid editor to the point of absurdity: a burger flipper at a 40,000-location chain fast-food restaurant who edits the article about the chain is in no way being paid to make that edit. Their job is to flip burgers, not to do corporate PR. They do have a COI (positive or negative) due to the employment relationship, but unless the CEO or PR department or whoever is telling employees that editing Wikipedia is now part of their job it's not WP:PAID.But like many other things around here, since WP:PAID has stricter requirements and penalties than WP:COI, people tend to try to stretch the definitions as far as they possibly can to use the stricter requirements and penalties to combat editing they don't like. I won't be surprised if people in that space take objection to my paragraph above on the basis that restricting WP:PAID to the clear definitions would hamper their efforts to combat the spammer scourge.As for the business owner, if the business is making paid edits on behalf of clients then the company as a whole, including the owner, is being WP:PAID to edit on behalf of the company's clients. And the required disclosure includes those clients, not just their general ownership of the paid-editing company. On the other hand, if the business is making widgets then I'd say the owner's editing is a very major COI but it's not specifically WP:PAID. Anomie⚔00:21, 5 November 2024 (UTC)[reply]
I disagree with that interpretation of WP:PAID. The policy says: "Users who are compensated for any publicity efforts related to the subject of their Wikipedia contributions are deemed to be paid editors, regardless of whether they were compensated specifically to edit Wikipedia." I think it's completely reasonable to hold the belief that "publicity" is almost always part of the job of a company owner and other senior officers e.g., C-suite occupants, governing board members. ElKevbo (talk) 02:43, 5 November 2024 (UTC)[reply]
Yes, and even more than that, the owner, officers and board members are fiduciaries of the company, and "compensated" and "incentivized" by ownership and/or other compensation (money, goods or services -- possession of the company is a good) to work in the company's best interest, whether in editing Wikipedia, or elsewhere. -- Alanscottwalker (talk) 12:52, 5 November 2024 (UTC)[reply]
Certainly the sole or majority owner of the company has an actual or risk of COI (depending on which definition of COI you use), But "Paid" implies more that that.....that somebody is paying them and telling them what to do. North8000 (talk) 02:53, 5 November 2024 (UTC)[reply]
IMO WP:PAID should be split into its main two interpretations: "instructed (even if implicit, e.g. hired for publicity in general) to edit Wikipedia for compensation" and "direct financial interest in a subject". JoelleJay (talk) 17:39, 5 November 2024 (UTC)[reply]
The issue here is WP:COI, not WP:PAID. When you're PAID to edit, the owner (or someone acting on behalf on the owner) tells you 'your job is to do this for me'. If you don't, you lose your job/don't get paid, so that's where your incentive comes from. WP:PAID exists, among other reasons, because there are firms trying to sell these services to companies/owners, and companies/owners paying people to edit on their behalf so they can go 'we hired professionals, if they're an issue blame them!'. It's a special type of COI-editting that's common enough to have a special policy for that special type of COI editing.
When the owner themselves are doing the editing, all the special concerns of PAID disappears, save for the remaining one: COI-editting. But that's covered by WP:COI. There is nothing special about the owner of Mary Sue, owner of Certified Reiki Thetan-Level 3 Shop editing an article on her business, than Rocker Boy Joe writing about his band Rocket Bobs, or Jensen Huang vandalizing AMD articles through an account named User:AMDTROLL4V3R. They don't lose their jobs, they still have their income, and they don't get in trouble if they fail to deliver.
Headbomb {t · c · p · b}17:50, 5 November 2024 (UTC)[reply]
If your job includes promoting a business and you come to Wikipedia to promote that business, that is PAID editing, owner or otherwise. That someone would be fired for refusing is not the criteria, an owner is highly incentivized to promote their business and can expect to be compensated for that effort through business growth and profit, and it is the compensation element that makes an editor a paid editor. - Aoidh (talk) 17:58, 5 November 2024 (UTC)[reply]
There is no part of WP:PAID that suggests that a power dynamic or consequence for a failure to deliver is a determining factor, and owners are indeed compensated for their work. This is especially true when taking into account that compensation is not limited to remuneration. - Aoidh (talk) 19:27, 5 November 2024 (UTC)[reply]
Blind enforcement of 1RR/3RR does not serve the project. The question should not be whether one violated the rule, but whether they violated the rule in a way that does not benefit the article. If there is no objection to the violation, we can reasonably assume that they are benefiting the article, or at least causing no harm. The decision should be left in the hands of other editors. Could this be used as a weapon? Would there be editors who claim harm where none exists? Certainly, but that's preferable to what we have now.
The problem, no doubt familiar to editors reading this, is that there are often not enough "good" editors around to protect an article from "bad" editors (malicious or merely inexperienced) while staying within 1RR/3RR. There is no restriction on the number of BOLD edits by a given editor, or on the number of editors performing BOLD edits. ―Mandruss☎00:09, 10 November 2024 (UTC)[reply]
If someone is repeatedly reverting reverts, then there is objection to the violation by definition. That's what edit warring is. If someone is making the same BOLD edit that needs to be reverted multiple times, then they are also edit warring. There are already exceptions with these rules for patent nonsense or obvious vandalism. If there's routine disruption, then it only makes the problem worse to revert over and over instead of taking it to WP:RFPP. If you feel the need to make more than one or two reverts in a content dispute, then it's time to either consider other options or step away from the article. Thebiguglyalien (talk) 01:31, 10 November 2024 (UTC)[reply]
It's not about edit warring or re-reverts; the problem exists without a single re-revert. Editor A does ten BOLD edits, five of which are detrimental to the article because they are too inexperienced (this stuff takes years to master, so that's far from uncommon). Editors B, C, D, and E contribute an additional twenty detrimental edits (along with any number of good ones, that number being irrelevant for our purposes here). Meanwhile, competent editors F, G, and H are limited to a total of nine reverts, leaving 21 detrimental edits in the article. I say F, G, and H should be allowed to revert until someone claims they are doing harm. ―Mandruss☎02:04, 10 November 2024 (UTC)[reply]
Where are you seeing thirty detrimental edits to an article in every day? Why isn't this article protected? Why aren't editors F, G, and H starting a discussion? Why are they reverting Editor A's edits individually instead of rolling them back? Why is it so urgent that these edits need to be reverted right this moment? Even on the off chance that they encounter such an article that exists, F, G, and H would not need to engage in tag-team reverting (which is still edit warring) if they knew what they were doing. Thebiguglyalien (talk) 02:07, 10 November 2024 (UTC)[reply]
You are welcome to reduce the numbers as you please; the problem exists regardless. The article is protected, even with ECP, and there is no shortage of registered editors who have 30 days and 500 edits and still have years to go before they are editing with any reasonable level of competence. Some never reach that point. Why aren't editors F, G, and H starting a discussion? Seriously? Why are they reverting Editor A's edits individually instead of rolling them back? Because (1) they may not have the rollback right, and the rollback right should not be required to function as an editor, (2) they would be rolling back five good edits, and (3) it's impossible if Editor A's edits are interleaved with those of any other editor(s). Why is it so urgent that these edits need to be reverted right this moment? Because (particularly in large and very active articles) the bad edits can easily be missed if not caught immediately. Then they stay in the article for some unknown amount of time until noticed by a competent editor and corrected with a BOLD edit. Could be months or even years. Is that good for the article? ―Mandruss☎02:27, 10 November 2024 (UTC)[reply]
Could you give an example or two where this has caused a problem? And I note that you have answered the two most important questions inadequately: if an article is subject to edit-warring it should be fully protected, and you dismissed "Why aren't editors F, G, and H starting a discussion?" with "Seriously?". Yes, of course it's a serious question. Starting a discussion is the best way of defusing an edit war. Phil Bridger (talk) 09:20, 10 November 2024 (UTC)[reply]
"Seriously?", while counter to the WP:DR policy, might be an honest response. I often get page protection or block requests, where my first response is often "where's the discussion?" —Bagumba (talk) 10:02, 10 November 2024 (UTC)[reply]
Unless Mandruss is extremely lazy, for which I have no evidence, I don't see how that response can be honest. It only takes a few seconds to start a discussion, no longer than it took to start this one, and the person who starts it wins some extra points. Phil Bridger (talk) 17:08, 10 November 2024 (UTC)[reply]
extremely lazy, for which I have no evidence Thank you! I have my share of faults and shortcomings, but I don't think extreme laziness is one of them. So there should be new discussions for each of the bad edits (separately for the sake of efficiency and organization), and the bad edits should remain in the article until enough editors have the time, interest, and attention span to form consensuses against them while attending to other important matters. This, at an ATP where we're struggling to keep the ToC at a manageable size even without such discussions. I don't know what articles you're editing, but I want to work there. ―Mandruss☎03:51, 11 November 2024 (UTC)[reply]
I gather the Donald Trump article is a rare anomaly where bad content is something we have to live with because the current rules are incapable of preventing it. After all, it's just one article. I would oppose that reasoning. I'd say article quality is at least as important there as anywhere else. ―Mandruss☎04:33, 11 November 2024 (UTC)[reply]
So there should be new discussions for each of the bad edits ...: Yes, or what is an alternative? Your suggestion to favor "good" edits over "bad" is problematic when everyone says their's are the "good" ones. Polarizing topics can be difficult for patrolling admins to WP:AGF determine "good" v. "bad" edits if they are not subject matter experts.—Bagumba (talk) 05:43, 11 November 2024 (UTC)[reply]
What do you mean, who said? I said something about repeated edits :-) If the rule were "do not repeat edits without consensus" 1x or 3x in 24 hours, instead of "do not revert" 1x or 3x in 24 hours (which leads to the whole "what exactly counts as a revert?" issue), the problem you are describing would not happen. The 'bad' editor can make 10 bad edits, and the 'good' editor can revert all 10 edits without violating do-not-repeat-3RR, and the 'bad' editor would be able to repeat 3 of those 10 edits without crossing do-not-repeat-3RR, and the 'good' editor can revert all 3 of those without crossing do-not-repeat-3RR, et voila: equilibrium. The problem is we focus on "revert" instead of "repeat." To tamp down on edit warring, we should prohibit people from repeating their edits, not from "reverting" (whatever that means, exactly) edits. Levivich (talk) 04:50, 10 November 2024 (UTC)[reply]
Blind enforcement of 1RR/3RR does not serve the project: Are you referring to page protection or blocks? On contentious topics or any subject? —Bagumba (talk) 05:11, 10 November 2024 (UTC)[reply]
This appears to be a Verifiability policy issue, not an evaluation of specific sources. Why are we holding the discussion on a noticeboard? Why not here or at WT:V? BusterD (talk) 16:11, 10 November 2024 (UTC)[reply]
Wiki-policy about Bibliography List in an article about a famous person.
User: Walter Tau and user: Yngvadottir can not agree whether a list of publications about a singer is appropriate in the article about this singer Orville Peck. I placed this list “Bibliography: publications about Orville Peck” after section “Filmography”. She keeps deleting it without citing a specific wiki-policy. Thriley explained the deletion with “This is excessive” again without citing a specific wiki-policy. Can someone explain to us what wiki-policy regulates Bibliographic Lists in an article?— Preceding unsigned comment added by Walter Tau (talk • contribs) 16:06, 11 November 2024 (UTC)[reply]
@Walter Tau: Policies and guidelines define what is allowed in articles, They do not mandate the addition of anything. Whether or not content is due in an article is an editorial decision reflecting the consensus of the interested community. FWIW, I agree that a Bibliography section that large is excessive. Take it to the talk page and gain consensus there for how large a bibliography, if any, to include in the article. (I am ignoring the edit warring that has been going on, but be aware that any future edit warring can lead to sanctions on your editing.) - Donald Albury16:28, 11 November 2024 (UTC)[reply]
Is there a way to create a graph that shows how many pages are in a category (y-axis) over time (x-axis)? It would be particularly useful for error tracking categories. Failing that, a text-based way to monitor category population changes. -- GreenC02:40, 4 November 2024 (UTC)[reply]
There's also User:SDZeroBot/Category counter which I just finished setting up. Raw counts only, no graphs for now. (I noticed that the MusikBot task, apart from being disabled, stores the counts on-wiki which seems like an unsuitable place for large-scale storage, and it also requires an admin to enable new categories for counting.) – SD0001 (talk) 18:10, 4 November 2024 (UTC)[reply]
User:SD0001 this works for my purposes. Thank you! You could also store the data on Commons, in JSON, and it would be available to Lua templates on all 300+ wikis, which might make graphic presentation possible. The only limit is JSON file size so it probably would require a new file every year, with monthly and yearly totals included in the JSON for scaled views. Example JSON. Example module that reads it (here). -- GreenC06:45, 9 November 2024 (UTC)[reply]
Duplicate, identical, and inconsistent system messages
I am trying to figure out if these messages are actually used for some reason or if they are no longer and can safely be deleted. I recently withdrew my own MFD of all three of these pages because I need to get more help on this. And I also withdrew a speedy criteria idea discussion also. Doing some digging in the archives I found Wikipedia:Village pump (technical)/Archive 195#Inconsistent tab names in monobook for the latter two. However, looking at the default, that appears to have been fixed.
As for MediaWiki:Edit there is phab:T310529. This behavior is getting quite confusing and I need to figure out what is going on.
I wonder if we can fish out more of these messages and maybe, on a rainy day, we can figure out what to do with them; send them to MFD, or what.
Pinging the users that previously were involved in this (at least in the past couple of days or whenever). @Pppery @Xaosflux @Thryduulf @Robert McClenon
I do have other questions about MediaWiki:Rollbacklinkcount(edit | talk | history | links | watch | logs) and MediaWiki:Rollbacklinkcount-morethan(edit | talk | history | links | watch | logs), and I remember dropping the discussion because it is a stylistic thing, but I do have concerns about if any of these overrides (especially the minor ones, minor in teh sense that they just add a comma or change the case or whatever) are being made with consensus or not, and if they are to solve a temporary problem, why they aren't being undone once that temporary problem is fixed.
To be clear, I have no trouble whatsoever with the overrides made for Wikipedia's sake, like those that link to Wikipedia policies or Wikipedia help pages or adding appropriate styling. This is primarily about "minor edits" where different punctuation, capitalization, or phrasing is used as opposed to the original message. If there indeed is a problem with a system message for all wikis (not just Wikipedia), then the wording should be fixed in the software.
There are somewhere around less than 1000 overrides going from the data on AllMessages. Reviewing them all is probably going to be a pain, especially because most of these messages don't have adequate documentation on MediaWiki. AwesomeAasim02:19, 9 November 2024 (UTC)[reply]
Thank you for withdrawing the MFD nominations pending further research. I don't understand the details of how those files are used, and I would prefer. before voting on whether to delete something, to know what it is and what it is used for:
These three are very old messages, and I don't have time to code search anywhere they could be in play. As phab:T310529 noted, at least one of them is still being imported in the current skins. Most of the use of these has been migrated to newer messages, but something could still be using them. Unless there is an actual problem, I'd leave them along. Code problems certainly should be raised on phab. — xaosfluxTalk10:48, 9 November 2024 (UTC)[reply]
And even with codesearch, some messages are used in pretty unconventional ways and can be difficult to locate (Dynamic definitions and compound definitions exist). —TheDJ (talk • contribs) 22:31, 9 November 2024 (UTC)[reply]
In any case, changing MediaWiki:Edit to say "Edit" does have advantages, namely that it permits editors to use the system message in templates. Same with MediaWiki:Protect and MediaWiki:Delete.
Any administrators: Is "delete" and "protect" appearing in lowercase when you are using a skin that is not MonoBook? By default it should be capitalized. AwesomeAasim19:18, 11 November 2024 (UTC)[reply]
I hope I am at the right place with this issue - if not, I would very much appreciate redirection!
I have been trying to fix the appearance of template:Chloroplast DNA, which is supposed to provide a clickable version of File:Nicotiana tabacum Choroplast genome.svg, but I am failing to make it display properly on both desktop and mobile (see template talk:Chloroplast DNA). It is used on Chloroplast and Chloroplast DNA, two fairly important articles, the former of which is currently being tidied up. I have a nagging feeling that there should be a completely different way of doing this than how [[[:template:Chloroplast DNA]] goes about it.
A template using a mass of display absolutes overtop an image is going to have a hard time on mobile, yes. Mobile has different assumptions about how wide an image is, even if you would prefer it to have a certain size. Izno (talk) 16:56, 9 November 2024 (UTC)[reply]
Having thought about it a bit more, I am not sure how ImageMap would work with an svg image that doesn't necessarily have an "original size". Is the "nominal size" of 1,125 × 960 pixels reported on Commons an "original size" in this sense? Felix QW (talk) 11:40, 10 November 2024 (UTC)[reply]
Ah right. Thanks. BTW, aren't there admins in existence who have admin right all over every wikipedia project?who might be able to do this types of edits on cross wiki projects if asked for help. Just curious VihirLak007hmu!/duh.20:12, 9 November 2024 (UTC)[reply]
How to create a "sanitized css" page from scratch? Everytime i try, the page creating window is for a article type new page(don't know the technical term) and not a css content model page. VihirLak007hmu!/duh.22:28, 9 November 2024 (UTC)[reply]
I then decided to search Fultondale High School on Google. I saw that the Wikipedia result had remained at the 1965-2021 article. However, upon clicking on this, the page redirects to the 2023-present article, as a redirect from the Fultondale High School article (now a redirect, but formerly a reviewed article).
This is most likely unintended. I clicked on the search result for the 1965-2021 school but was redirected to the 2023-present article. I was using Google, and I haven't received the notification that the 2023-present article has been reviewed yet. Departure– (talk) 02:58, 10 November 2024 (UTC)[reply]
I wasn't aware of WP:MISPLACED in this context, cheers! But the search engines still did what they probably shouldn't. Not much of an issue for a local high school in Alabama, but this could happen to rogue autoconfirmed users on pages where the Wikipedia result is the first on searches of major topics in potentially less-than-ideal circumstances. Departure– (talk) 03:15, 10 November 2024 (UTC)[reply]
Google cached https://en.wikipedia.org/wiki/Fultondale_High_School when it was a redirect to Fultondale High School (1965–2021), so the title and excerpt on the Google search results page is from that article until they revisit the page and update their cache at an unknown time. I guess Google wouldn't have linked https://en.wikipedia.org/wiki/Fultondale_High_School on the result if MediaWiki made real HTTP redirects. It makes a "fake" redirect where it gives a HTTP 200 OK status code (redirects are 3xx) and stays on the page but displays the same content as the redirect target with "(Redirected from ...)" added at the top. If a browser has JavaScript enabled then MediaWiki rewrites the url in the address bar to the redirect target but that url is never actually loaded by the browser or Googlebot. I don't see an issue we should try to fix. The content of the unreviewed article is not indexed by Google. Somebody may merely click a link which leads to the article. Wikipedia itself has such links including in our own search results which do index unreviewed articles. PrimeHunter (talk) 04:17, 10 November 2024 (UTC)[reply]
There's a discussion at ANI right now that is heading in the direction of banning a user from creating new articles, a sub-proposal has emerged to allow them to use WP:AFC instead. My question would be this: if you check the "Creating new pages and uploading new files" is that sitewide or will it only apply to the namespace selected for the partial block? Or would we have to just consider it an traditional topic ban with no technical implementation? Just Step Sidewaysfrom this world ..... today22:22, 10 November 2024 (UTC)[reply]
@Novem Linguae will trout me for suggesting this: Edit Filter to stop that editor from creating new articles in the mainspace. (But no, don't please. If the editor has no self-control after the consensus to topic ban them, they might just earn a ticket to being blocked.) – robertsky (talk) 14:11, 13 November 2024 (UTC)[reply]
Edit filters are expensive in terms of performance when submitting an edit, and of maintaining them, so should not typically be written to stop a single user from doing something. So yes, probably better to have the user just exercise some self-control :) –Novem Linguae (talk) 14:15, 13 November 2024 (UTC)[reply]
Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.
Updates for editors
On wikis with the Translate extension enabled, users will notice that the FuzzyBot will now automatically create translated versions of categories used on translated pages. [3]
In 1.44.0-wmf-2, the logic of Wikibase function getAllStatements changed to behave like getBestStatements. Invoking the function now returns a copy of values which are immutable. [5]
Wikimedia REST API users, such as bot operators and tool maintainers, may be affected by ongoing upgrades. The API will be rerouting some page content endpoints from RESTbase to the newer MediaWiki REST API endpoints. The impacted endpoints include getting page/revision metadata and rendered HTML content. These changes will be available on testwiki later this week, with other projects to follow. This change should not affect existing functionality, but active users of the impacted endpoints should verify behavior on testwiki, and raise any concerns on the related Phabricator ticket.
In depth
Admins and users of the Wikimedia projects where Automoderator is enabled can now monitor and evaluate important metrics related to Automoderator's actions. This Superset dashboard calculates and aggregates metrics about Automoderator's behaviour on the projects in which it is deployed. Thanks to the Moderator Tools team for this Dashboard; you can visit the documentation page for more information about this work. [6]
Meetings and events
21 November 2024 (8:00 UTC & 16:00 UTC) - Community call with Wikimedia Commons volunteers and stakeholders to help prioritize support efforts for 2025-2026 Fiscal Year. The theme of this call is how content should be organised on Wikimedia Commons.
What kind of person? Are you talking about biographical articles about well-known people, or other users of the site? Do you have a link to a page where you have this problem? Nardog (talk) 07:24, 12 November 2024 (UTC)[reply]
All people I look up, there picture does not come up, but a little box is in place of the picture where the picture of the person usually is. Topjimz (talk) 08:34, 12 November 2024 (UTC)[reply]
is there a way to import all the taxonomy templates to a different wikipedia project (eg: Sinhala wikipedia) in one go? I've been manually making one by one when someone make a new article for an animal or plant and the infobox error popup saying missing template. There's no translation of names going on since they're are scientific names and in rare cases they get directed to the same name written in local letters. it there a way to import all these way easier so later ppl can make the relevant missing article pages of clades, genus, families etc and not have to copy paste each template one by one. Hope i was clear VihirLak007hmu!/duh.09:35, 12 November 2024 (UTC)[reply]
The ability of other Wikipedias to use the taxonomy templates comes up quite often. There are currently 119k taxonomy templates. I assume one could get a list using the API, but don't know if that can be used get a bulk download and then import them elsewhere. There is a category: Category:Taxonomy_templates. — Jts1882 | talk13:22, 12 November 2024 (UTC)[reply]
I've done a little research and think it can be done in two steps.
First, export the taxonomy templates from English Wikipedia to an XML file. Use Special:Export and export file from Category:Taxonomy_templates. I tested this and downloaded a 4Mb file.
Second, import into target wikipedia. This needs special permissions so only can be done by an administrator. I can't even access the page to see the options, but I assume there is an option to import the downloaded XML file.
Hope this helps. I would be interested in knowing if it works as we often get asked about interwike use on the automated taxobox talk pages. — Jts1882 | talk16:38, 12 November 2024 (UTC)[reply]
Do keep in mind that English Wikipedia doesn't have taxonomy templates for all taxa with articles (let alone the taxa that don't have articles). There are around 20,000 taxa with articles that don't have a taxonomy template yet. Plantdrew (talk) 20:49, 12 November 2024 (UTC)[reply]
So i asked for importer/inter wiki importer rights from an admin there, they said they don't have power to give me that right but a steward can. where can i find stewards VihirLak007hmu!/duh.05:23, 13 November 2024 (UTC)[reply]
To receive importer rights yourself, you would first need to make a request on your wiki to demonstrate there is consensus for you to be given this permission. This request must meet the requirements laid out in meta:Steward requests/Permissions/Minimum voting requirements § Temporary Importer (per meta:Importer, permanent importer access will not be granted unless the local community has a policy specifically allowing it). As an example, the most recent request for importer access on enwiki is here, though that was a request for permanent access. Then, you would file a request to the stewards at meta:SRP. Note that this is a very sensitive permission—it essentially gives the ability to add fake edits to a page's history—so standards for granting it are (or at least should be) high.If you don't anticipate using this permission frequently, I believe you could instead start a discussion on your wiki seeking approval for these specific imports. If that discussion were successful, you would then file a request at meta:SRM for a steward to handle the imports. The other alternative, which avoids the issue of import permissions entirely, would be to have a bot copy the templates to your wiki (subject to your local bot policy, of course). 50.223.140.130 (talk) 07:55, 13 November 2024 (UTC)[reply]
That should work, but note that importing from an XML file can only be done by importers (or more specifically, users with the importupload right); other admins can only import via an interwiki, which can only do one page at a time. 50.223.140.130 (talk) 07:15, 13 November 2024 (UTC)[reply]
Syncing across different wikis
Is there a way to sync template/list contents across wikis?
Eg: Template:Totd, Imagine another wikiproject has this template too, is there a code we can enter so whatever that is updated/added/changed/showed in the Template on the english wiki also updates/adds/changes/shows on the other wiki through their template. Gonna be useful for things like technical news, Totd etc VihirLak007hmu!/duh.11:41, 12 November 2024 (UTC)[reply]
@VihirLak007 There was a bot providing this functionality, but I think it broke. I think now this functionality only syncs Modules (which makes sense, cause these are easier to make language and wiki independent than templates). —TheDJ (talk • contribs) 12:47, 13 November 2024 (UTC)[reply]
There are two aspects of this, one is the global template wiki/synchronization, the other is multilingual support. Usually modules with '/config' or '/configuration' sub pages are easier to sync, as the multilingual settings and translations are on those config pages. Then on top of that you have modules changing the arguments, prompting a change in the transclusions on all of the wikis. So, not a copy/paste job. Snævar (talk) 14:03, 13 November 2024 (UTC)[reply]
The page looks great to me in dark mode (Brave browser on Mac OS). Can you give a specific example of one part of the article that does not display as expected? What part of the article, what is it doing, and what were you hoping it would do? – Jonesey95 (talk) 20:29, 12 November 2024 (UTC)[reply]
Script error on mobile causing headings to stop rendering
Font color not changing in infoboxes when darkmode is turned on
On sinhala wiki few infoboxes doesn't change font color to white in darkmode, so they aren't readable. How to fix this and where to exacly find the code which determine the font color according to the mode a user is using? If its possible can someone fix?
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]
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]
Background
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.
Survey (PCECP)
Support (PCECP)
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]
This is not somehow less or more restrictive as ECR. It's exactly the same level of protection, just implemented in a different way. I do not get the !votes from either side who either claim that this will be more restriction or more bureaucracy. I understand neither, and urge them to explain their rationales. Aaron Liu (talk) 12:32, 12 November 2024 (UTC)[reply]
By creating a difference between what non logged-in readers (that is, the vast majority of them) see versus logged-in users, there is an extra layer of difficulty for non-confirmed and non-autoconfirmed editors, who won't see the actual page they're editing until they start the editing process. Confirmed and autoconfirmed editors may also be confused that their edits are not being seen by non-logged in readers. Because pending changes are already submitted into the linear history of the article, unwinding a rejected edit is potentially more complicated than applying successive edit requests made on the talk page. (This isn't a significant issue when there aren't many pending changes queued, which is part of the reason why one of the recommended criteria for applying pending changes protection is that the page be infrequently edited.) For better or worse, there is no deadline to process edit requests, which helps mitigate issues with merging multiple requests, but there is pressure to deal with all pending changes expediently, to reduce complications in editing. isaacl (talk) 19:54, 12 November 2024 (UTC)[reply]
Do you think this would be fixed with "branching" (similar to GitHub branches)? In other words, instead of PC giving the latest edit, PC just gives the edit of the stable revision and when "Publish changes" is clicked it does something like put the revision in a separate namespace (something like Review:PAGENAME/#######) where ####### is the revision ID. If the edit is accepted, then that page is merged and the review deleted. If the edit is rejected the review is deleted, but can always be restored by a Pending Changes Reviewer or administrator. AwesomeAasim21:01, 12 November 2024 (UTC)[reply]
There are a lot of programmers who struggle with branching; I'm not certain it's a great idea to make it an integral part of Wikipedia editing, at least not in a hidden, implicit manner. If an edit to an article always proceeded from the last reviewed version, editors wouldn't be able to build changes on top of their previous edits. I think at a minimum, an editor would have to be able to do the equivalent of creating a personal working branch. For example, this could be done by working on the change as a subpage of the user's page (or possibly somewhere else (perhaps in the Draft namespace?), using some standard naming hierarchy), and then submitting an edit request. That would be more like how git was designed to enable de-centralized collaboration: everyone works in their own repository, rebasing from a central repository (*), and asks an integrator to pull changes that they publish in their public repository.
(*) Anyone's public repository can act as a central repository. It just has to be one that all the collaborators agree upon using, and thus agree with the decisions made by the integrator(s) merging changes into that repository. isaacl (talk) 23:22, 12 November 2024 (UTC)[reply]
That makes sense. This has influenced me to amend my Q2 answer slightly, but I still support the existence of this protection and the preemptive PC protecting of low-traffic pages. (Plus, it's still not more restriction.) Aaron Liu (talk) 23:20, 12 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]
Support Idk what it's like in other areas but in mine, of edit requests that I see, a lot, maybe even most of them are POV/not actionable/nonsense/insults so if it is already ECR only, then yea, more filtering is a good thing.Selfstudier (talk) 18:17, 11 November 2024 (UTC)[reply]
Support assuming this is technically possible (which I'm not entirely sure it is), it seems like a good idea, and would definitely make pending changes more useful from my eyes. Zippybonzo | talk | contribs (they/them) 20:00, 12 November 2024 (UTC)[reply]
Strong support per @JPxG:'s reasoning—I think it's wild that we're willing to close off so many articles to so many potential editors, and even incremental liberalization of editing restrictions on these articles should be welcomed. This change would substantially expand the number of potential editors by letting non-EC contributors easily suggest edits to controversial topic areas. It would be a huge win for contributions if we managed to replace most ECP locks with this new PCECP.– Closed Limelike Curves (talk) 02:07, 14 November 2024 (UTC)[reply]
Oppose (PCECP)
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]
Except that is how pull requests work on GitHub. You make the edit, and someone with reviewer permissions approves it to complete the merge. Here, the "commit" happens, but the revision is not visible until reviewed and approved. Edit requests are not pull requests, they are the equivalent of "issues" on GitHub. AwesomeAasim19:03, 11 November 2024 (UTC)[reply]
It may come as a surprise, but Wikipedia is not GitHub. While they are both collaborative projects, they are very different in most other respects. Thryduulf (talk) 19:20, 11 November 2024 (UTC)[reply]
With Git, submitters make a change in their own branch (which can even be in their own repository), and then request that an integrator pull that change into the main branch. So the main branch history remains clean: it only has changes that were merged in. (It's one of the guiding principles of Git: allow the history tree of any branch to be simplified to improve clarity and performance.) isaacl (talk) 22:18, 11 November 2024 (UTC)[reply]
Edit requests are supposed to be pull requests.
Clearly indicate which sections or phrases should be replaced or added to, and what they should be replaced with or have added. — WP:ChangeXY
Yeah that is what they are supposed to be but in practice they are not. As anyone who has answered edit requests before, there are often messages that look like this:
This template must be followed by a complete and specific description of the request, that is, specify what text should be removed and a verbatim copy of the text that should replace it. "Please change X" is not acceptable and will be rejected; the request must be of the form "please change X to Y".
The edit may be made by any extended confirmed user. Remember to change the |answered=no parameter to "yes" when the request has been accepted, rejected or on hold awaiting user input. This is so that inactive or completed requests don't needlessly fill up the edit requests category. You may also wish to use the {{EEp}} template in the response. To request that a page be protected or unprotected, make a protection request.
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]
Weak Oppose I do understand where this protection would be helpful. But I just think something is EC-protectable or not. Don't necessarily think adding another level of bureaucracy is particularly helpful. --Takipoint123 (talk) 05:14, 11 November 2024 (UTC)[reply]
Oppose. I'm inclined to agree that the scenarios where this tool would work a benefit as technical solution would be exceedingly niche, and that such slim benefit would probably be outweighed by the impact of having yet one more tool to further nibble away at the edges of the open spaces of the project which are available to new editors. Frankly, in the last few years we have already had an absurdly aggressive trend towards community (and ArbCom fiat) decisions which have increasingly insulated anything remotely in the vain of controversy from new editors--with predictable consequences for editor recruitment and retention past the period of early involvement, further exacerbating our workloads and other systemic issues. We honestly need to be rolling back some of these changes, not adding yet one more layer (however thin and contextual) to the bureaucratic fabric/new user obstacle course. SnowRise let's rap11:23, 12 November 2024 (UTC)[reply]
Oppose. The more I read this discussion, the more it seems like this wouldn't solve the majority of what it sets out to solve but would create more problems while doing so, making it on balance a net negative to the project. Thryduulf (talk) 21:43, 12 November 2024 (UTC)[reply]
Oppose and Point of Order Oppose because pending changes is already too complicated and not very useful. I'm a pending changes reviewer and I've never rejected one on PC grounds (basically vandalism). But I often revert on normal editor grounds after accepting on PC grounds. (I suspect that many PC rejections are done for non-PC reasons instead of doing this) "Point of Order" is because the RFC is unclear on what exactly is being opposed. Sincerely, North8000 (talk) 22:15, 12 November 2024 (UTC)[reply]
Pretty sure that what happens is that when vandals realize they will have to submit their edit for review before it goes live, that takes all the fun out of it for them because it will obviously be rejected, and they don't bother. That's pretty much how it was supposed to work. Just Step Sidewaysfrom this world ..... today22:22, 12 November 2024 (UTC)[reply]
This is a very good point, and I ask for @Awesome Aasim's clarification on whether reviewers will be able to reject edits on grounds for normal reverts combined with the EC restriction. I think there's enough rationale to apply this here beyond the initial rationale for PC as explained by JSS above. Aaron Liu (talk) 23:24, 12 November 2024 (UTC)[reply]
Reviewers are given specific reasons for accepting edits (see Wikipedia:Pending changes § Reviewing pending edits) to avoid overloading them with work while processing pending changes expeditiously. If the reasons are opened up to greater evaluation of the quality of edits, then expectations may shift towards this being a norm. Thus some users are concerned this will create a hierarchy of editors, where edits by non-reviewers are gated by reviewers. isaacl (talk) 23:44, 12 November 2024 (UTC)[reply]
I understand that and wonder how the reviewer proposes to address this. I would still support this proposal if having reviewers reject according to whether they'd revert and "ostensibly" to enforce EC is to be the norm, albeit to a lesser extent for the reasons you mentioned (though I'd replaced "non-reviewers" with "all non–auto-accepted"). Aaron Liu (talk) 00:13, 13 November 2024 (UTC)[reply]
I'm not sure to whom you are referring when you say "the reviewer" – you're the one suggesting there's a rationale to support more reasons for rejecting a pending change beyond the current set. Since any pending change in the queue will prevent subsequent changes by non-reviewers from being visible to most readers, their edits too will get evaluated by a single reviewer before being generally visible. isaacl (talk) 00:59, 13 November 2024 (UTC)[reply]
Sorry, I meant Aasim, the nominator. I made a thinko. Currently, reviewers can undo just the edits that aren't good and then approve the revision of their own revert. I thought that was what we were supposed to do. Aaron Liu (talk) 02:13, 13 November 2024 (UTC)[reply]
Yes. Anything that is obvious vandalism or a violation of existing Wikipedia's policies can still be rejected. However, for edits where there is no other problem, the edit can still be accepted. In other words, a user not being extended confirmed shall not be sufficient grounds for rejecting an edit under PCECP, since the extended confirmed user takes responsibility for the edit. If the extended confirmed user accepts a bad edit, it is on them, not whoever made it. That is the whole idea.
Of course obviously helpful changes such as fixing typos and adding up-to-date information should be accepted sooner, while more controversial changes should be discussed first. AwesomeAasim17:37, 13 November 2024 (UTC)[reply]
Yeah, but also edits made in violation of an already well-established consensus. Edits that enforce a clearly-established consensus (proven by previous talk page discussion), are, from my understanding, exempt from all WP:EW restrictions. AwesomeAasim18:38, 13 November 2024 (UTC)[reply]
Oppose per Thryduulf and SnowRose. Also regardless of whether this is a good idea as a policy, FlaggedRevs has a large amount of technical debt, to the extent that deployment to any additional WMF wikis is prohibited, so it seems unwise to expand its usage. novovtalkedits19:05, 13 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?
Also to add on there needs to be some enforcement measure for WP:ARBECR. No technical enforcement measures on WP:ARBECR is akin to site-banning an editor and then refusing to block them because "blocks should be preventative". AwesomeAasim19:42, 13 November 2024 (UTC)[reply]
Blocking a site-banned user is preventative, because if we didn't need to prevent them from editing they wouldn't have been site banned. Thryduulf (talk) 21:16, 13 November 2024 (UTC)[reply]
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]
Oppose (Preemptive PCECP)
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]
No need for protection if there is no disruption. Trouble is, the ECR restriction is enacted in response to widespread disruption, this time to the entire topic area as a whole. Disregard for POV, blatant inclusion of unverifiable or false (unreliable) information, and more all pose serious threats of disruption to the project. If WP:ARBECR was applied broadly without any protection I would agree, but WP:ARBECR is applied in response to disruption (or a serious threat of), not preemptively. Take this one for example, which is a long winded ANI discussion that ended in the WP:GS for the Russo-Ukranian War (and the ECR restrictions). And as for Arbitration Committee, ArbCom is a last resort when all other attempts to resolve disruption fail. See WP:ARBPIAWP:ARBPIA2WP:ARBPIA3WP:ARBPIA4. The earliest reference to the precursor to ARBECR in this case is on the third ArbCom case. Not protecting within a topic area that has a high risk of disruption is akin to having a high-risk template unprotected. The only difference is that carelessly editing a high-risk template creates technical problems, while carelessly editing a high-risk topic area creates content problems.
Either the page is protected technically (which enforces a community or ArbCom decision that only specific editors are allowed in topic areas) or the page is not protected technically but protected socially (which then gives a chance of evasion). I see this situation no different from banning an editor sitewide and then refusing to block them on the grounds that "blocks should only be used to prevent disruption" while ignoring the circumstances leading up to the site ban.
What PCECP would do is allow for better enforcement of the community aspect. New editors won't be bitten, if they find something that needs fixing like a typo, they can make an edit and it can get approved. More controversial edits will get relegated to the talk page where editors not banned from that topic area can discuss that topic. And blatant POV pushing and whatnot would get reverted and would never even be seen by readers.
The workflow would look like this: new/anon user make an edit → edit gets held for review → extended confirmed user approves the edit. Rather than the current workflow (and the reason why preemptive ECP is unpopular): new/anon user makes an edit → user is greeted with a "this page is protected" message → user describes what they would like to be changed but in a badly formulated way → edit request gets closed as "unclear" or something similar. AwesomeAasim14:21, 11 November 2024 (UTC)[reply]
No. We should be quicker to apply protection in these topics than we would elsewhere, but not preemptively except on highly visible pages (which, in these topics, are probably ECP-protected anyway). Animal lover|666|17:18, 11 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 (preemptive ECP)
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 (preemptive ECP)
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]
WP:RUNAWAY sums up some of the tactics used by disruptive editors: namely Their edits are limited to a small number of pages that very few people watch and Conversely, their edits may be distributed over a wide range of articles to make it less likely that any given user watches a sufficient number of affected articles to notice the disruptions. If a user is really insistent on pushing their agenda, they might not be able to push it on the big pages, they may push it on some of the smaller pages where their edits may get unwatched for months if not years. Then, researchers digging up information will come across the POV article and blindly cite it. Although Wikipedia should never be cited as a source, it still happens. AwesomeAasim14:35, 11 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]
I am actually starting to wonder if "protection" is a bit of a misnomer, because technically pages under pending changes are not really "protected". Yeah the edits are subject to review, but there are no technical measures to prevent a user from editing. It is just like recent changes on many wikis; those hold edits for review until they are approved, but they do not "protect" the entire wiki. AwesomeAasim23:40, 11 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]
Good Idea! That’s actually what I was going to propose but you took it. To add to your amazing proposal, I suggest that every wiki translation must be approved by a speaker. Like If someone translated an article from English to Arabic, the translated article goes to an Arab speaker, by algorithm when the person would press a button that says “send for approval” or something like that, and the Arab person who gets the translated article will read the Wikipedia page and look for any errors, then the Arab corrects it and it gets published to the world. And why can’t the opposite happen, when an article gets translated to say french To English the same thing happens the French person machine translates the article, it gets sent to approval, a fluent English speaker goes and corrects it, then it gets published. If it is an extinct language, a person who is a professional in the language will correct it, and as for rates, I mean Wikipedia has at least 1 person who knows the language. Anyway have a good day! Cheers! Datawikiperson (talk) 10:10, 10 November 2024 (UTC)[reply]
I'm not sure of the technical backend for that tool, but I do see at English Wikipedia a constant inflow of articles translated from sister projects, usually without proper attribution, sometimes with broken templates.Some of these translations are pretty good, up to idiomatic phrasing; others have the appearance of raw machine translation, with errors no one fluent in the target language would leave in.As to the original proposal / idea, a flow of machine translations from this project to sister Wikipediae, that is indeed out of scope here, and would have to be brought up individually at each language project. Except maybe Cebuano Wikipedia. Folly Mox (talk) 14:49, 10 November 2024 (UTC)[reply]
I occasionally translate from English to Chinese and vice versa, and take on some bits from Japanese and Korea projects to be translated on to here if the information and sources can be used on here. And I strongly discourage automated AI translations from English to other languages, which you are proposing, without further inputs from the targeted language projects. AI translations to other languages from English are not perfect and can have the same devastating impact you don't want to see on English Wikipedia. – robertsky (talk) 14:30, 11 November 2024 (UTC)[reply]
"Wikipedia:Redirect sandbox"
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]
Firstly, excuse my ignorance, but what is TPOD? Secondly, I don't see any clear proposal here. Yes, size is often important, but what do you think we should do about it? We can cajole editors into providing size, but we shouldn't reject images without it. Phil Bridger (talk) 13:48, 9 November 2024 (UTC)[reply]
Sorry I got the abbreviation wrong — POTD. Today’s (11/10/2024) POTD is an example of what I’m talking about. The reader knows a bark beetle is tiny, but why not give the actual size? It’s not that the information isn’t available. I clicked on the photo, then on "details." The description of the photo says the adult male is 4.0 mm to 5.5 mm long. I came back to the post and clicked on the name. The linked article includes the same information. The information is there this time. I agree, it’s not always either place. But when it is, it should be provided to be complete. Wis2fan (talk) 04:54, 10 November 2024 (UTC)[reply]
A picture caption is finite, it does not need to (and indeed in most cases cannot) include every detail about an image and its subject. Therefore it should only include information that is most relevant, and that will not always include the size. For example the POTD for 8 November was an 1860 photograph of John Tarleton (Royal Navy officer), is the size of the print really the most relevant information or is it the size of the subject what you want to know? It's fine to encourage people to put the size of the image and/or subject in the caption where that is relevant, but it is not always going to be, so a one-size-fits all rule is not going to be appropriate. If you want to know, just look at the extra details. Thryduulf (talk) 14:37, 10 November 2024 (UTC)[reply]
Thryduulf is absolutely correct, the size of the object in a photo is unimportant when it is a human. The size isn’t necessary for today’s POTD (11/11/2024). But I still think it is important when it is a bark beatle. And many other things. I also think that a writer should anticipate a reader’s questions and provide the answers. Suggesting that if a reader wants the size of an object they should look at the extra details is not helpful. I’d bet most readers don’t know how to find them. Wis2fan (talk) 04:29, 11 November 2024 (UTC)[reply]
I vaguely remember I suggested something similar at commons once, requesting that more people who post photos consider including a scale-bar if it's the sort of subject that would benefit from one (biological specimens, museum artefacts whose size is likely to be unclear to a general reader). I think I got shot down in flames for general naivete. My opinion is: In any situation where a reference book would use a scale bar, or indicate prominently by caption or other means, the size of an illustrated object, we should do the same, so far as we can. This would probably include articles about most species (birds, insects etc.) and articles about things where the size is central to the article (an article on miniaturisation of transistors, for example, should show the size of the transistors in its photos). Elemimele (talk) 13:52, 12 November 2024 (UTC)[reply]
Artist collective infobox
Hello! I have made an infobox for artist collectives (inspired by my own frustration trying to use the regular artist one for graffiti crews) and would like feedback from the community before publishing it. The old infobox proposal page is now defunct and suggests posting here instead.
Personally, I'd much rather not see this, or anything like it, used. Almost everything in it will be disputable or disputed, or is really vague. It seems a classic example of where an infobox is just unhelpful clutter, and will displace or make too small an image that would be more helpful. Are you asking at the VA project, & if not, why not? It's not really for here. Johnbod (talk) 05:03, 12 November 2024 (UTC)[reply]
Require 2FA for bureaucrats
Heya, I noticed a couple of weeks ago that while interface administrators and central notice administrators need 2FA, bureaucrats, who can grant interface admin don't need 2FA. To me this seems a bit weird, because if you wanted to compromise an account with access to interface admin tools, bureaucrats may not all have 2FA. Hence, I'm proposing requiring all enwiki bureaucrats to enable 2FA as a precaution. Zippybonzo | talk | contribs (they/them) 09:24, 12 November 2024 (UTC)[reply]
I see non-restricted adjacent bugs T242553 and T242556 were both created on 12 Jan 2020. Would it be accurate to describe this as an evaluation which has been unresolved for about 5 years? -- zzuuzz(talk)13:58, 12 November 2024 (UTC)[reply]
Support per pppery and zippybonzo - should be a requirement locally. Waiting for phab tickets could take years while I imagine a RFC would pass pretty quickly. BugGhost🦗👻19:44, 12 November 2024 (UTC)[reply]
Idea lab
Can we consider EC level pending changes?
This is just an idea, and I want to workshop this a bit more, but I think it would be helpful to have pending changes at the extended confirmed level. This could be called "PC2" again (not to be confused with the original PC2) or "PCECP". The idea would be to help enforce WP:ARBECR and similar restrictions where non-extended confirmed users are prohibited from certain topic areas. Under this level, edits by non-extended-confirmed editors would be held for review, while extended confirmed users can approve these edits and thus take responsibility under WP:PROXYING.
I think it would be helpful for pages where (1) parts of the article intersect with a contentious topic, or (2) the article in its entirety intersects with a contentious topic, but not edited frequently. AwesomeAasim16:54, 27 September 2024 (UTC)[reply]
This seems like it could be useful. It would have to be restricted to infrequently edited pages (likely excluding all current events articles) so as not to overwhelm Pending Changes every time Reuters publishes a new story or an edit war erupts. The big question is: what problem are you trying to solve? Toadspike[Talk]20:39, 27 September 2024 (UTC)[reply]
There are some contentious topics designated either by ArbCom or the community where only extended confirmed users are allowed to participate. However, admins refuse to protect pages where there isn't enough disruption to justify protection. Although, it should be considered that the XCON restriction applies regardless of whether a page is protected or not.
What PCECP would do is essentially remove fears that there "isn't enough disruption to justify protection" while buffering all non-extended-confirmed contributions so they have to be approved, in line with "non-extended-confirmed can only make edit requests". Templates that are specifically for this case like {{edit protected}} break when the page is not protected. AwesomeAasim22:00, 27 September 2024 (UTC)[reply]
The problem with that is that the 500/30 rule is specifically designed to keep newer editors out due to extreme amounts of disruption as a rule. There's a good reason why both of the world's main hot wars (the Arab-Israeli conflict and the Russo-Ukrainian war) are under 500/30. And, as has been brought up repeatedly and bears repeating again, high volumes of edits on a given article contraindicate CRASHlock.
But the biggest stumbling block here is that no consensus exists yet for an extended-confirmed CRASHlock. The last discussion about expanding CRASHlock to higher protection levels predates XCP entirely. There would need to be a formal RfC for this, not VP spitballing. —Jéské Courianov^_^vthreadscritiques15:37, 28 September 2024 (UTC)[reply]
XCON protection makes sense for high traffic articles, but low traffic articles? If the edit is minor such as fixing spelling mistakes or grammatical errors, there should be no problem. Fixing spelling and grammar is generally outside of contentious topic areas anyway. From WP:ARBECR: On any page where the restriction is not enforced through extended confirmed protection, this restriction may be enforced by other methods, including ... the use of pending changes.
I probably would set up abuse filters as well to see if a page is in a category that primarily deals with a contentious topic, and then warn and tag the edit in question. AwesomeAasim16:22, 28 September 2024 (UTC)[reply]
Most low-traffic CT articles don't have any protection since they never saw amounts of vandalism necessitating protection. Protection requests that solely rely on arb enforcement and little to no evidence of vandalism get declined. Aaron Liu (talk) 23:26, 28 September 2024 (UTC)[reply]
Yeah I see that, but the problem is that a non-XCON edit will get approved on pages that not many people are watching. Pending changes still allows non-XCON users to make these edits, but their edits will need to be approved and they can be reverted if in violation of WP:ARBECR. This is also in line with how pending changes is used on low-traffic articles to monitor (not prevent) disruption. AwesomeAasim18:26, 29 September 2024 (UTC)[reply]
@Aaron LiuMost low-traffic CT articles don't have any protection since they never saw amounts of vandalism necessitating protection. Protection requests that solely rely on arb enforcement and little to no evidence of vandalism get declined. Untrue, articles in ECR topics can and are pre-emptively locked. What actually happens is that articles with minimal disruption are usually not brought to WP:RFPP or noticed by a wayward admin. Mach6119:53, 29 September 2024 (UTC)[reply]
Untrue, articles in ECR topics can and are pre-emptively locked.
Seems reasonable. I've always wondered why pending changes isn't deployed more often. It seems a useful tool, and there are lots of pending changes reviewers so very little backlog Cremastra (talk) 14:18, 28 September 2024 (UTC)[reply]
Still not seeing it. People supposedly mistrust it because there was a trial 14 years ago and enwiki admins didn't immediately stop using it after the trial period pending a consensus on the future of the feature? Anomie⚔18:43, 9 October 2024 (UTC)[reply]
The TL;DR I'm taking away from this discussion is that you're still butthurt over consensus not going your way 12 or 13 years ago, and assuming that anyone opposed to PC shares that reason and no other. I think it's unlikely continuing this conversation is going to go anywhere useful. Anomie⚔18:59, 9 October 2024 (UTC)[reply]
That isn't how consensus works, either. Consensus can be determined by an RfC, yes. But it can also develop just by the way that things are done already, regardless of whether it has formally discussed.
I think about the example given by Technology Connections about "the danger of but sometimes". The LED traffic light is superior in energy savings and much more, but sometimes snow and ice builds up on them, so they are bad. Likewise, XCON pending changes will help with enforcement of WP:ARBECR but sometimes admins might apply this to pages out of policy, so it shouldn't be used again. The correct response would be to place in policy guardrails so that admins don't do that. AwesomeAasim19:00, 9 October 2024 (UTC)[reply]
How is an RfC from over 13 years ago still reflective of consensus today? I am pretty certain that while some opinions might not have changed, others definitely will have. No one is saying there should be full pending changes. AwesomeAasim18:16, 9 October 2024 (UTC)[reply]
I guess you might be the only one using this terminology; as it is not in WP:GLOSSARY or anywhere else.
Nonetheless, this is the Idea Lab; it is the place to develop ideas, not to show stark opposition to ideas. That is what the other discussion boards are for; consensus polling. It should be noted that WP:ECP was created originally for the purpose of enforcing arbitration decisions and community sanctions. It was never intended for anything else; it just got used for other stuff de facto. AwesomeAasim18:40, 9 October 2024 (UTC)[reply]
(edit conflict) All these things you think are obvious really are not. You should try explaining yourself better instead of emphatically waving your hands at something random. Anomie⚔18:43, 9 October 2024 (UTC)[reply]
Obvious perhaps, but it still doesn't make much sense. I'm not sure how using your own special terms of unclear implications to disparage things you dislike is helping communication or community understanding here. Cremastra (talk) 19:37, 9 October 2024 (UTC)[reply]
I don't understand. People mistrust PC because of a bureaucratic misimplementation of an experiment over 10 years ago? (In a noncentralized bureaucracy where dumb shit happens all the time?) The RfC is explicit that it makes no normative judgement on PC, and it seems the !voters are not doing so either. SamuelRiv (talk) 18:37, 9 October 2024 (UTC)[reply]
It's worth noting that the 2017 RfC is the last one about any aspect of CRASHlock, to my knowledge. As I said above, there would need to be a new RfC in order to get consensus for extended-confirmed CRASHlock, as PC2 was originally full-protection level and no ECP!CRASHlock question was asked in the2016RfCs, none of which were particularly comprehensive. (The last comprehensive RfC was the 2014 clusterfuck.) —Jéské Courianov^_^vthreadscritiques06:47, 10 October 2024 (UTC)[reply]
I think the main reasons editors don't want to expand the use of pending changes are practical: no technical support for fixes (or additional feature development) is on the horizon, in spite of documented bugs; and uncertainty in the community's ability to manage expanded use. There are certainly vocal editors who are wary due to past history, but this has already been a factor in other decisions, and they have accordingly been influenced to be more definitive about how any trials will proceed. isaacl (talk) 18:55, 9 October 2024 (UTC)[reply]
Ok so there's a lot of history here as you are already seeing above, and no one's even gotten to discussing Phillipe's little misadventure yet. Despite all that I actually think the general idea here is sound. And since we are discussing history its worth pointing out that as a practical matter this is actually closer to what the EC restriction was intended to do in its earliest incarnation where it functioned as a softer version of 1RR originally enforced as a bespoke AE remedy on one specific article reverts of non-qualifying accounts did not count towards 1RR.
Times have changed, ECR now tends to be enforced in mainspace with ECP and is applied far more broadly than anyone from then would have envisioned, for better and for worse.
The best use case here is for quiet pages where the history of non-EC editing is largely one of minor non-contentious fixes and improvements, but have caught attention due to sporadic contentious edits, where it can offer a middle way between leaving enforcement to post-edit reverts and preventing all non-EC editing.
As a practical matter the limitations of the extension mean that it really only works-well on low-traffic pages and realistically improvements to the extension aren't coming anytime soon. So use case (2) makes sense, but (1) is a harder sell. Might not be enough of a use case to justify the hassle. Personally I'd have to do some research and think about this a little but the basic idea is sound.
A multi-part RfC asking how ECR should be enforced for existing pages, including based on activity. High traffic pages will need extended protection retroactively as those tend to get the most disruption from ECR violations. Low-traffic pages, not so much, but we can use abuse filters and workshop ECP pending changes for this. Spelling and grammar fixes as far as I am aware are excluded from WP:ARBECR. AwesomeAasim19:52, 1 October 2024 (UTC)[reply]
Sounds good - but bear in mind we are discussing CRASHlock (which would require developer buy-in to make XC happen) and an Arbitration policy (which ArbCom may short-circuit). Also note that there would likely need to be a separate RfC consensus to allow XC CRASHlock in the first place; like I said above we haven't had a comprehensive discussion about it since 2014. —Jéské Courianov^_^vthreadscritiques16:26, 26 October 2024 (UTC)[reply]
@Jéské Couriano, I do wish you would quit using that made-up word. WP:PC is shorter to type, and when editors use the same words for the same thing, then we're less likely to end up with avoidable confusion ("CRASHlock sounds really bad, but I'm just asking for WP:PC"). WhatamIdoing (talk) 00:26, 27 October 2024 (UTC)[reply]
WP:ARBECR can first just be XCON PC. After extensive edits by non-EC, piling on to PC backlog, then it can just be upgraded to normal XCON. If the disruption is already severe before being brought to RFPP or other venue, then XCON protection can just be the first action. ~/Bunnypranav:<ping>13:05, 28 October 2024 (UTC)[reply]
@Jéské Couriano the discussions that you linked are from 2016, so we cannot assume the consensus has not changed. Also, I believe that this is a platform for building ideas and new proposals, hoping to bring them to reality while abiding by consensus. ~/Bunnypranav:<ping>15:28, 30 October 2024 (UTC)[reply]
On another thought I am actually wondering if we can just have a two-part RfC as to whether to turn on this feature I discuss. Part 1 would just be about PCECP and part 2 would be just about replacing ECP with PCECP on low-traffic WP:ARBECR and related articles. AwesomeAasim16:41, 30 October 2024 (UTC)[reply]
That makes sense, but the second RfC might fail, as it one would have to discuss page wise about the change in protection. Also proving that PCECP is enough for said pages will be complicated, and also have to think about the storming of backlog in PC if it is not enough. ~/Bunnypranav:<ping>16:45, 30 October 2024 (UTC)[reply]
The name we use for Wikipedia:Notability has long been a source of confusion. People can guess the basic concept of many policies and guidelines from the plain-English meaning of the title (e.g., Wikipedia:Reliable sources are sources you rely on; Wikipedia:Copyright violations is about violations of copyright etc.), but this one has quite a different meaning. You can have several sources that directly say ____ is a notable musician, and we'll reply that he's not WP:Notable.
I'd like to brainstorm some alternative phrases that could be used instead of "notability", or as a supplement to it, that would be less confusing to people unfamiliar with our internal jargon.
Abbreviation found in comments at Wikipedia:Articles for deletion and in edit summaries, indicating that the article's subject is not notable enough for a Wikipedia entry. A subject is non-notable if editors agree not to have an article about this subject. Their decision is usually based on things like not finding enough reliable sources to write a decent encyclopedia article, but it can also be based on things like a desire to present a small subject as part of a larger one.
A characteristic held by article subjects that qualify for separate, stand-alone articles. A notable topic is one that "is suitable for a stand-alone article or list when it has received significant coverage in reliable sources that are independent of the subject." Note that "notability" is a property of a topic, and has nothing to do with the quality of an article, or whether an article exists for the topic.
Words for the concept: criteria, concept, test, quality, qualities, requirements, notedness, guideline, threshold, when to create an article
Words for the result: separate article, stand-alone article, separate page, stand-alone topic, new topic, own page, article creation, article suitability, inclusion
Some specific ideas:
Collapsed list of prior ideas
The following discussion has been closed. Please do not modify it.
Article concept guideline
Article creation criteria
Article creation guideline
Article sourcing test
Article suitability criteria
Article test guideline
Article threshold
Criteria for article creation
Guide to which topics should be included as articles on Wikipedia
Guideline for when a topic should have its own article
Inclusion criteria
Is the subject written about in reliable sources?
New topic test
Notedness
Own page threshold test
Page sourcing guide
Primary notability criterion
Qualifying for a separate article
Separate article criteria
Source availability
Source depth
Stand-alone concept
Stand-alone article criteria
Stand-alone topic criteria
Stand-alone topic criterion #1 (#2, #3, etc.)
When to create an article
Feel free to expand the box if you want to see some of the prior ideas. It's collapsed because some research on brainstorming ideas suggests that looking at other people's ideas can reduce the total number of ideas shared. Duplicates are fine!
I had also been thinking about this. The core issue, in my opinion, is that we're trying to describe as "notability" something that is closer to "for someone/something to have an article, they should be well-documented in reliable sources". At its core, the term "notability" carries more of a connotation of relative importance, leading to a lot of newcomers, and sometimes even other users, being misled as to what makes a topic notable. On the other hand, the actual guidelines describing it focus on the existence of reliable sources about the topic, with importance only being used by some guidelines as a proxy for these sources being likely to exist.A word like well-sourced or well-documented would carry this idea better, without the a priori of "importance/fame is what matters" that "notability" carries. Chaotic Enby (talk · contribs) 21:13, 22 October 2024 (UTC)[reply]
Lots of topics are documented by primarily primary sources (eg like many news event), but we require coverage by secondary sources, so those would worsen the situation. — Masem (t) 21:20, 22 October 2024 (UTC)[reply]
Good point, although it could still be a first start, and no word can fully convey our notability guidelines either. Maybe encyclopedically sourced could help convey the fact that not any source works? Or, as you employ the term "coverage", we could make the difference between (primary) documentation and (secondary) coverage and call it well-covered? Chaotic Enby (talk · contribs) 21:27, 22 October 2024 (UTC)[reply]
Chaotic Enby: I am still chewing over all this. I fear that encyclopedically sourced could be easily misunderstood and potentially lead to more newbies trying to cite Wikipedia itself. I really don't have a sense of how well people outside Wikipedia and academia understand the distinctions between primary, secondary, and tertiary sources. I think well-covered does capture the essence of what we're trying to convey without causing more confusion. — ClaudineChionh (she/her · talk · contribs · email) 23:42, 22 October 2024 (UTC)[reply]
I'd say that people outside the wiki-verse and academia understand primary/secondary/tertiary "not at all", and I'd say that people in the wiki-verse understand the distinction "poorly". Editors struggle with WP:PRIMARYNEWS, especially when it comes to the question of notability ("But event is obviously important, so obviously this breaking news article is secondary"), and most of them could not explain why Wikipedia:Secondary does not mean independent. WhatamIdoing (talk) 00:17, 23 October 2024 (UTC)[reply]
Masem, the GNG requires secondary sources, but NPROF does not. Both are still wiki-notable. We therefore need a handle for this concept that does not assume the GNG approach. WhatamIdoing (talk) 00:13, 23 October 2024 (UTC)[reply]
I caution against this because as it is used now, notability is not used as a check at new page review, and primarily is a method used for evaluating whether to delete an article at AFD. We should have an advice page with that title about how to make sure you have a good topic and reviewing the notability of the topic is a good starting point as part of it. — Masem (t) 21:35, 22 October 2024 (UTC)[reply]
A nod to WP:Structurism as an existing concept. Also a hint that newcomers should add content to existing article, and no be trying to add a new orphan topic as their first contribution.
I'm inclined to something like "stand-alone topic criteria" (to clarify that the point is determining whether a topic warrants a stand-alone article) or, in a similar vein, "when to create an article" (or possibly "when it can be appropriate to create an article", since in occasional cases it can be appropriate to cover a small number of closely related topics that could be notable in the same article rather than separately). I do agree with the notion that notability isn't the best name for this guideline and that having a term that's more like plain English. Hydrangeans (she/her | talk | edits) 21:26, 22 October 2024 (UTC)[reply]
Maybe something like suitable topics or suitable article topics would work. That implies the existence of editorial judgement and that some topics simply aren't suitable. User:Chaotic Enby, this was inspired by your idea of "well-sourced", which has the potential to be confused with well-cited (i.e., the number of refs in the article right now, rather than the number of sources in the real world). WhatamIdoing (talk) 00:21, 23 October 2024 (UTC)[reply]
From all the suggestions so far, this seems the most understandable so far. It's short, it communicates that some things are excluded and that there is 'judgement' involved. —TheDJ (talk • contribs) 09:46, 23 October 2024 (UTC)[reply]
I really like this, because (1) it removes the emotional pain of being deemed "not notable", and (2) it avoids the confusion we currently have of subjects that are notable but about which we cannot have a meaningful article. To clarify: (1) AfD and Teahouse waste a lot of time trying to explain to upset people that Wikipedian notability has nothing to do with importance, creativity, or future value to humanity. We could save a lot of trouble by focusing on the objective need for sources rather than the subjective view of importance. (2) Notability is currently only half of the two tests we need to pass: We can't have an article unless the subject is notable and someone's written something about it for us to summarise. We have a lot of guidelines that say "XXX is generally considered notable", which result in unexpandable stubs because although it can be demonstrated from primary sources that two old ladies and a chicken once lived near a railway siding in Ohio (making it a genuine inhabited settlement), there is now nothing there, and no one has ever written anything about it, or ever will. Focusing on what is necessary to create an article would cut to what actually matters, practically, rather than getting tied up in legalistic debates about what constitutes a notable thing. Elemimele (talk) 16:14, 23 October 2024 (UTC)[reply]
But all too often, we get the argument that we should have an article on XXX because sources exist, even though no one has demonstrated the existence of such sources. Attempts to add the requirement that reliable sources must be cited to create or keep an article have been repeatedly rejected. I would support replacing "notability" with something like "specific topics are suitable for articles if they are well-sourced, NPOV, and meet certain broad topic requirements (i.e., replacements for SNGs)". Donald Albury17:32, 23 October 2024 (UTC)[reply]
@Donald Albury, do you mean that topics are suitable/notable if they're neutral, or do you mean that articles are suitable/notable if they're neutral? I'm not sure if you mean that you want to repeal WP:NRVE and expand the deletion policy to say that a (deserved) {{POV}} tag is grounds for deletion, or if you mean that citing sources in a neutrally written article must be possible, even if it hasn't happened yet (including for many years). WhatamIdoing (talk) 17:44, 23 October 2024 (UTC)[reply]
I was just trying to express that availability of reliable sources is required, but not sufficient, and that other policies and guidelines also must be met for an article to be suitable for inclusion in WP. Donald Albury18:30, 23 October 2024 (UTC)[reply]
I do like suitable much better than notable (and came here to suggest it). It's more accurate, but still gives some flexibility in definition, where something like well documented might be open to misinterpretation / lawyering. Folly Mox (talk) 17:50, 23 October 2024 (UTC)[reply]
@Seraphimblade also deserves credit for this idea, since a comment from him is the source of "article suitability" in the list above.
I'm leaning a bit towards "topics" (or "subjects"?), because "articles" could be argued to exclude lists, and because of the endless problem of "it's not notable because the article's quality is currently too low". WhatamIdoing (talk) 02:13, 24 October 2024 (UTC)[reply]
I like that a lot. On Wikipedia, a suitable topic for an article is one where either sufficient reliable, independent sources can be found or which meets the criteria outlined in a subject-specific suitability guideline (SSG)... – sounds both more understandable and closer to how we actually decide whether or not to keep articles, in practice. – Joe (talk) 08:02, 25 October 2024 (UTC)[reply]
Just to throw out an idea that I think can minimize disruption, is to consider a comparable situation to the relatively recent rename of of the old Naming Convention page to WP:Article Titles while specific advice of naming for various fields are still at "Naming Convention". In that same vein, if the GNG was moved to its own page (thus sitting alongside the sepearate SNG pages) and what's left at WP:N left there, then renaming that leftover to some of the suggestions above would still allow us to keep the principle of notability via the GNG and SNG while having a better landing page at a more familiar term and to explain the GNG and SNG functions within that. It would minimize a mass edit on p&g pages. The GNG and SNGs can be described as tests used on Wikipedia to measure how notable (real world definition) a topic is within the suitability on an encyclopedia. Masem (t) 18:11, 23 October 2024 (UTC)[reply]
Well, in terms of providing g a word that is closer to the real definition for our practice related to when a topic is suitable for it's own article, treating the existing idea of notability through the GNG and SNGs as is and focusing on a clear word for the broad concept is a clean solution. Masem (t) 19:39, 23 October 2024 (UTC)[reply]
The issue is that GNG is about how well-documented the topic is in independent secondary sources, which doesn't necessarily map to real-world notability, and using the latter word for it has been just as much source of confusion. Chaotic Enby (talk · contribs) 19:45, 23 October 2024 (UTC)[reply]
We can frame the GNG and SNGs as semi objective, source based tests to evaluate real-world notability, and establih in the top level guideline that one reason to allow a topic to have an article is via demonstrating real world notability using the GNG and SNGs tests. That moves us away from having notability take the wiki definition. We still need a clear understandable title for the top level guideline, and that would also discuss more that the GNG and SNGs, such as the current NLIST advice. — Masem (t) 16:55, 24 October 2024 (UTC)[reply]
The issue is, basing article suitability on real-world notability is a very iffy definition. GNG (and to a lesser extent the SNGs) provide us with a better foundation for defining what is suitable for our encyclopedia, which is quality of independent secondary sourcing. "This person is important" is ultimately a less relevant criterion than "this person has enough secondary sources to write an article about them", if our goal is to write an encyclopedia (tertiary source, i.e. relying on secondary sourcing). Chaotic Enby (talk · contribs) 17:02, 24 October 2024 (UTC)[reply]
Consider that several of the SNG do give measure of real world notability based on claims of importance which can be given by a single reliable primary source, the expectation they can be expanded. The key is that with a tiny bit of rewording of the GNG and SNGs are set as the evaluation of real world notability with the expectation of sourcing and coverage required for an encyclopedia, either which establishes one way a topic is suitable for a stand alone article. Masem (t) 17:35, 24 October 2024 (UTC)[reply]
The reality is that wp:notability is the operative word for "allowed to have a separate article" and the talisman for the fuzzy ecosystem/process which decides that. It incorporates with wp:notability guidelines, degree of compliance with WP:not (a measure of the degree of enclyclopedicness of the article) and a bit of influences from real world notability/importance. Any term needs to acknowledge this. If one tries to base it on summarizing just what the wp:notability guidelines say, IMO it won't work. Sincerely, North8000 (talk) 02:00, 24 October 2024 (UTC)[reply]
Yes. And the strongest consideration in it would be wp:notability per the notability guidelines, but the above other factors described above are also a part of that consideration. North8000 (talk) 15:31, 24 October 2024 (UTC)[reply]
I prefer to see a more obvious name for the guideline for article creation. Something such as like "Guideline for article creation" would be more obvious. TFD (talk) 16:21, 24 October 2024 (UTC)[reply]
Agree. My point was agreeing with the structure/content. If we want this to have legs, we'll need something with an even shorter with a good acronym for it. North8000 (talk) 17:08, 24 October 2024 (UTC)[reply]
Procedural request I don't mean to gum up the process. But there's a risk of having 100 different ideas from 99 different editors, which can make it difficult to reach a consensus. Whenever this brainstorming step is over, I want to recommend compiling them into a list, sorted by some type of subcategory. That way we can slowly funnel our way towards something that can earn a consensus. I believe you'd probably find (at least) three or four types of names:
Non-descriptive (compare WP:NOT or WP:SIZE): inclusion criteria, inclusion test, article creation threshold, etc.
Type of outcome (compare WP:DISAMBIG or WP:STANDALONELIST): separate article, stand-alone article, separate page
Standard of sources (compare WP:RELIABLE or WP:VERIFIABLE): independent sources, third party sources
Standard of coverage (compare WP:OR or WP:COPYRIGHT): significant coverage, minimum coverage, coverage threshold
I lean towards something more descriptive, because "inclusion criteria" just shifts the complaints from "Wikipedia has an arbitrary definition of notability!" to "Wikipedia has an arbitrary list of inclusion criteria!" Newcomers and outsiders notoriously don't read passed the headline, or even twist ambiguity in bad faith to attack Wikipedia with misinformation campaigns. It would help the project much more if the guideline title summarized an uncontroversial standard for our encyclopedia. (Currently: if no reliable, independent sources can be found on a topic, then it should not have a separate article. or A topic is presumed to be suitable for a stand-alone article or list when it has received significant coverage in reliable sources that are independent of the subject.) Shooterwalker (talk) 17:24, 24 October 2024 (UTC)[reply]
I agree that "inclusion criteria" could shift the complaints from "Wikipedia has an arbitrary definition of notability!" to "Wikipedia has an arbitrary list of inclusion criteria!" However, the current name has an additional problem, namely "I have three Wikipedia:Reliable sources that WP:Directly support a claim that this subject is 'notable', so why are you claiming that it's non-notable?" That problem would go away with a name like "inclusion criteria". WhatamIdoing (talk) 19:57, 24 October 2024 (UTC)[reply]
We do have arbitrary criteria, though. All the WP:SNGs are arbitrary. The WP:GNG is arbitrary in what it considers "significant", "reliable", and "independent". Individual decisions on articles are arbitrary in how these guidelines are interpreted and how strictly they are applied. It's better to be open about that than pretend, like too many 'notability theorists' do, that we've come up with a 350 word rubric that objectively divides all of human knowledge into worthy and unworthy. I think most people can understand that to make a large project like this manageable, you have to agree on some boundaries – and respect them, even if they don't agree with them. – Joe (talk) 08:18, 25 October 2024 (UTC)[reply]
Except we do also have rubrics, and we also have to work together, so we have found it necessary to define together. There's boundaries, you say? What are they? We have to go about answering that question together. -- Alanscottwalker (talk) 11:20, 25 October 2024 (UTC)[reply]
Yes, that's what I'm saying. WP:GNG and the WP:SNGs are the boundaries we've arrived upon. They aren't objective, they're arbitrary and subjective, but that's okay. – Joe (talk) 11:31, 25 October 2024 (UTC)[reply]
Perhaps it would be more precise to say that there is an element of arbitrariness and subjectivity to decisions, especially for borderline subjects. WhatamIdoing (talk) 16:35, 25 October 2024 (UTC)[reply]
But, they are not just arbitrary. They describe real world things (sources) and using them for coming to decision (measure), and even more importantly, the rationale for doing so (writing based on what reliable others do). Arbitrary would be no definition, no rubric at all among us. We may suck, but we don't usually just rely on throwing darts or dice to delete articles. Alanscottwalker (talk) 18:39, 25 October 2024 (UTC)[reply]
Do they really describe real-world sources? Consider "The person has had a substantial impact outside academia in their academic capacity." The basis for deciding this is: Wikipedia editors say so.
Yes, they do, those impacts are sourced, somehow -- you actually do have to prove it to each other. (Besides, you already know, this "independence" is a both matter of degree, and not strictly necessary to be in the definition for all real world sources -- and as a matter of various qualities a real world source might have, we are generally more concerned with trustworthy). Alanscottwalker (talk) 20:56, 25 October 2024 (UTC)[reply]
I've been told that the usual way of qualifying under the second one ("significant impact") is to write a book that is used in (undergraduate?) classes at multiple universities. But some classes, and some universities, appear to be more equal than others for this determination, which is arbitrary, using the definition as a decision made according to individual personal preference rather than by its intrinsic qualities.
I agree with you that supporters of these two criteria use sources whose independence can often be most politely described as a "matter of degree", and they appear to agree with you that independent sources are "not strictly necessary". (For example, I have seen sources accepted by other editors that were just a few links to class syllabi, saying that the text for the class would be Big Textbook by Alice Expert. In GNG terms, these are mere passing mentions in self-published sources, and would not be accepted for any other subject at all.) WhatamIdoing (talk) 21:36, 25 October 2024 (UTC)[reply]
I strongly disagree with the statement that the WP:GNG is arbitrary. (Or even the additional requirements of the WP:SNGs.) At worst, the application of WP:N requires some level of judgment, based on a consensus of editors applying the principle. But the evidentiary standard for writing an article is based on real, practical, and empirical experience. And it helps our project when the world understands that we write articles based on evidence. Shooterwalker (talk) 01:41, 29 October 2024 (UTC)[reply]
It's not completely random, but it is arbitrary, in the sense that nobody on the face of the earth except for English Wikipedia editors uses this definition of "notable". For example, I think virtually all people would agree that a YouTube celebrity with twenty million fans was "a famous or important person" -- it is only Wikipedians who have a secret alternate definition where it means "has had three newspaper articles written about them". jp×g🗯️12:11, 29 October 2024 (UTC)[reply]
That's a different point, and the real point of this brainstorm. Asking for sources isn't an arbitrary standard, but in hindsight, the word "notability" is an odd choice of words to describe it. Shooterwalker (talk) 22:04, 29 October 2024 (UTC)[reply]
Frankly, I think that it is an obvious error that we incorrectly refer to our guideline as "notability", and that we call things that meet this guideline "notable". It is not arbitrary -- there are rules -- but they aren't about notability. No normal speaker of the English language, when they say "notability", means what that guideline says.
If I'm going to be totally honest, it feels like -- whether designed intentionally or not -- the guideline's name is designed to make sure that newbies give invalid arguments during deletion debates, thus ensuring that their autobiographies/advertisements/etc are deleted and they are dismissed, because they stupidly assume that the word means the thing it means in 99.999% of its usage in the English language. For example, the obvious direct interpretation of "Smith is not notable" is:
The speaker's subjective opinion, which you can argue against by saying "Yes he is".
A claim that he is not very famous, which you can argue against by saying X million people listen to his podcast
A claim that he is not very successful, which you can argue against by saying he made X million dollars or has Y thousand clients or employs Z hundred people.
A claim that he is not very unique, which you can argue against by saying that he's the first X to ever Y, or the only Z who's ever Qd while Zing.
We do not accept any of these arguments. If you make any of these arguments, we sneer and ridicule you for being an idiot.
I would propose that the "notability" guideline be called something that does not, in any way, create "two-tier" sentences (e.g. ones where there's an obvious plain English interpretation, and then a second Wikipedian English interpretation where it means something else). For this reason I think stuff like "impactfulness topic criteria" might be helpful, but would not fully solve the issue, as people still know what the word "impactful" means, and would argue that things were impactful, when what we actually meant was impactful, and only a moron would think that meant impactful. It should be something that nobody would ever think to define in terms other than looking up the Wikipedia policy for it. For example: "includability" or "florfbap". jp×g🗯️12:07, 29 October 2024 (UTC)[reply]
Maybe "sourceability"? It brings the idea of having quality sources, while not being an already existing word, to make it clear that it's a unique Wikipedia concept. Chaotic Enby (talk · contribs) 16:01, 29 October 2024 (UTC)[reply]
Honest answer, you deprecate NPROF. I don't know why this one guideline has been repeatedly giving exemptions to sourcing requirements in an encyclopedia that should rely on secondary sources. Chaotic Enby (talk · contribs) 15:53, 1 November 2024 (UTC)[reply]
"Sourcability" is far too close in meaning to WP:Verifiability and implies a weaker aspect when in fact what notability currently is is more complex than just WP:V itself. (that's one reason why notability remains a guideline rather than a policy, because of how complex it is) Masem (t) 17:08, 1 November 2024 (UTC)[reply]
Binominal expression or complete sentence This is a great discussion and thank you to OP for starting it. I think all the suggestions presented so far are great, though, they each introduce some of the ambiguity that already exists with Notability. I guess my comment is that we seem to be caught up on coining an all-encapsulating single word that could replace Notability. Maybe this is a case where a binominal expression ("Nice and Plenty") or even a complete sentence would be more appropriate to communicate the complexity that WP:NOTABILITY houses? Chetsford (talk) 18:10, 1 November 2024 (UTC)[reply]
Timeline of significant figures
While many people have made contributions to history (many more than could fit in one timeline), it's undoubtable that some people's influence far exceeds that of others. 
Therefore, I think we should have a timeline of the significant figures in history. 
I completely understand that determining how significant some people are is a difficult task. It's expected to take struggle and effort to make this work. However, people deserve to know who made the greatest contributions to the advancement of humanity.
Also, many scholars themselves have written about who they believe are to be the most significant people.
I have created a sketch of this idea at User:Wikieditor662/sandbox. It's far from perfect, but you get the main idea. The people are colored based on the era they were in. The most significant people make it to the overview and those who are not as important but still nonetheless significant (as well as people born earlier so the overview doesn't get clumped) go to the individual timelines (below the overview) along with those in the overview.
I would again like to reiterate that this is something that is going to take effort, dedication, and much debate, but if we do this, then I think it could be worth it. What do you all think?
Kindly, I'm experiencing philosophical opposition to this project. History has been a team effort, and further elevation of the already elevated is not likely to improve genuine understanding of historical processes. The Great man theory correctly fell out of fashion early last century.Having said that, I don't mean to dissuade you from undertaking a project you're clearly interested in, and this seems like it could serve as some kind of subpage of WikiProject Vital Articles. Using the inclusion criterion "listed at WP:VA" is probably the only way you'd ever develop any kind of agreement as to which historical figures to include. That WikiProject has already done a lot of debating over which topics are more important than others.The periodisation scheme is pretty parochial and Eurocentric, and would have to be converted to numeric year spans or whatever schema WP:VA uses (and the section headings would have to be delinked per MOS:NOSECTIONLINKS). You'll also want to consider how to handle cases where vital dates are approximate, unknown, disputed, etc. Folly Mox (talk) 00:12, 24 October 2024 (UTC)[reply]
I would tend to agree with Folly Mox on this. I'll add that it might be pretty much impossible to find an actual inclusion criteria, that is, any kind of consensus in reliable sources as to who is a significant enough figure – or even if we can compare the significance of historical figures across times, cultures, and domains. If anything, that page will inform more about our own selection than about any historical truth behind it.However, having it as part of WP:VA, rather than as an encyclopedic article, could make it a pretty useful reference for articles about famous figures needing improvement, without claiming that these are necessarily the most significant ever. Chaotic Enby (talk · contribs) 01:07, 24 October 2024 (UTC)[reply]
@Wikieditor662: you may have set yourself up for a poor reception with the questionshould people be included based off on how significant, famous, or both they are/were?. Both of these attributes are not quantifiable: the only inclusion criteria VA would recognise as feasible would probably be "limit to Level 3" (112 figures), or "include Level 3 and Level 4" (1995 additional figures; 2107 total). (Delta qualifiers like "vital dates securely known".)When a discussion is opened on a page and nobody responds for almost two weeks – as is the case here – this can often be understood as signalling lack of interest.If you really are interested in this data visualisation existing somewhere outside your userspace – which has seen no buy-in by participants at this thread nor any of the 93 watchlisters of the WikiProject talkpage – a next step might be to make a new timeline including precisely the figures listed at Wikipedia:Vital articles/Level/3 § People, and pitch the idea again, specifically as a WikiProject subpage, perhaps at WT:VA instead of WT:PVITAL.I'm afraid I feel compelled to reiterate that this idea does not feel pedagogically sound, and is likely to tell us more about the people who select the figures to include than it teaches about history. Folly Mox (talk) 01:06, 7 November 2024 (UTC)[reply]
I would lean towards option 1, with option 2a as a second choice. The less bureaucracy the better, and CUs are trusted enough to use the permission responsibly. They have also already signed the NDA. If we are going to create a separate right, ArbCom is the body which is best equipped to assign (and importantly, monitor the use of) tools which give access to non-public information. Are there other options I am not thinking of? Reasons to pick a particular option? Other comments? HouseBlaster (talk • he/they) 02:47, 28 October 2024 (UTC)[reply]
Option 2a with the right being given initially to any current CU or former CU in good standing who asks for it. That way it can be added/removed independently of the CU rights if there is any reason to do so, and allows for any changes in the future. Thryduulf (talk) 03:34, 28 October 2024 (UTC)[reply]
Given that ACE scrutineers are routinely granted local CU for the purpose of properly scrutinizing the election, I do not think an electionadmin without CU makes any sense. (I can see the argument for having CUs without electionadmin, however.) In other words, I do not think it should be added independently of the CU right, but removing it would be acceptable. HouseBlaster (talk • he/they) 03:40, 28 October 2024 (UTC)[reply]
I think the ability to assign/remove it independently of CU is more important than whether it ever is given to a non-CU or removed from someone without removing CU. Thryduulf (talk) 03:45, 28 October 2024 (UTC)[reply]
Option 2a and personally, I don't think it necessarily needs to be restricted to CheckUsers. As long as the appointment comes with a vote of ArbCom and has community consultation, it satisfies the WMF's criteria for access, assuming the recipient is identified as well. I see no reason to lock it behind the CheckUser right, though I do think ArbCom is the right choice for who should be assigning it. EggRoll97(talk) 04:38, 28 October 2024 (UTC)[reply]
We should postpone considering this until phab:T377531 is resolved. Communication from WMF regarding SecurePoll related groups/rights has not been technically accurate. In particular I want to note the following points:
electionadmin group gives access to sensitive data as of today, but this is actually because of a bug. If/when the bug fix is merged (gerrit:1083337), no PII would be leaked – and the ability to setup and configure polls becomes quite low-risk and can be bundled into the sysop toolkit.
The user right which actually does expose PII, securepoll-view-voter-pii, is extremely sensitive! It allows viewing the IPs and UAs of all the voters in a single page. This is a much higher level of access than CheckUser which only allows viewing the data for a user individually, and the use of such access along with the given reason go into logs which are audited by ArbCom/Ombuds for compliance with local and global CheckUser policy. Compare that with securepoll-view-voter-pii which allows viewing PII en masse without any audit trail (phab:T356442).
This idea starts with the presupposition that PII must be collected on these. That is something that can be discussed. Perhaps it doesn't need to be, especially if we are going to keep using manual whitelists for the electoral rolls. — xaosfluxTalk09:48, 28 October 2024 (UTC)[reply]
Per SD, I think that all admins should have electionadmin right, since scheduling elections seems like great mop work. However, I disagree that the right to view voter private information shouldn’t be given to all CheckUsers. I think that it should, since the users that have accessed the information are already logged (T271276), so there is an audit trail. CheckUsers are also the ones who know about socks, so they seem like a great fit.
Unless we start doing an election a week we'll ever need more than a handful of election admins, so I'm not sure giving it to every admin is necessary. It sounds more like interfaceadmin (of which we have 10) or bureaucrat in that regard (15, and they aren't busy). – Joe (talk) 11:32, 28 October 2024 (UTC)[reply]
What benefits would there be in having way (as in perhaps 100x) more people than needed? The drawbacks I can see immediately are: increased risk/attack surface (we generally follow the principle of least privilege for even the most minor rights); increased chance of misunderstandings arising from the lack of clarity over who's responsible for elections (look at what's happened already); increased chance of conflicts when too many people are trying to coordinate one election; increased expectations for new admins from adding yet another bundled responsibility. – Joe (talk) 18:01, 28 October 2024 (UTC)[reply]
The arbitration committee election is run by volunteers who co-ordinate to avoid overlapping work. I'm confident that Wikipedia's collaborative community will continue in this tradition with administrator elections.
Bundling privileges together is a tradeoff: sure, election admins could be a separate user group, with the overhead cost of the processes to add or remove members. That has to be weighed against the risk of someone setting up votes without community approval. I think I agree with SD0001 that it's not a high-risk scenario. There are much better ways for someone who obtained access to an admin's account to disrupt Wikipedia than trying to setup clandestine polls. isaacl (talk) 18:34, 28 October 2024 (UTC)[reply]
That's what I'm basing my numbers off. The ArbCom election is run by three coordinators, three scrutineers, and a couple of people setting up the pre-RfC. So eight people, and none of them seem particularly run off their feet. We have over eight hundred admins.
I imagine the potential for abuse would not be in setting up bogus elections but in manipulating or sabotaging real ones or (if CU ends up being included in this) doxxing voters en masse. Admin accounts are scarce and valuable enough commodity for it to be worth the effort for some people. But again, we apply the principle of least privilege to rollback and page mover. Why wouldn't we do it here? – Joe (talk) 19:54, 28 October 2024 (UTC)[reply]
Regarding the arbitration committee election: anyone is eligible to co-ordinate the election RfC and the non-votewiki portion of the election itself. They don't all rush in and try to perform tasks without co-ordinating with each other.
SD0001 suggested that the electionadmin right be bundled with the admin toolset since, after the bug is fixed, it does not require CheckUser privileges. I appreciate that, in your view, the risk is sufficiently high to warrant the overhead of managing the electionadmin right with a separate process.
Regarding the page mover and rollback rights, they remain bundled with the sysop group, though. Since those rights are granted separately, if the principle of least privilege were followed, admins should have to apply for them separately rather than getting them bundled. I've previously stated my support for tailoring permissions with matching roles (see this comment thread on protection for Did You Know queues for example). But I recognize that there is an overhead cost, and there have to be willing volunteers to pay it. isaacl (talk) 22:09, 28 October 2024 (UTC)[reply]
Who will have access to the vote details? Unrelated to the other private details who voted, and how they voted should be encrypted and access extremely limited. If that's not the case these won't be 'secure' elections, and voters need to be very visibly warned that their votes aren't private -- LCU ActivelyDisinterested«@» °∆t°12:51, 28 October 2024 (UTC)[reply]
The creation and setup can be done by 'crats as Joe mentioned. For the PII exposing rights, I do agree with SD's views, I also have another option, this right can be asked only by existing Check Users, and the ArbCom can grant it to the ones who have a respectable experience using CU tools. ~/Bunnypranav:<ping>12:55, 28 October 2024 (UTC)[reply]
One thing to keep in mind, to see SP PII you have to be listed on the specific poll (and you have to be in the electionadmin group to be eligible to be listed on the specific poll). So if we decide to collect the enhanced PII in SP, then it is still limited to only the users registered to the specific poll. — xaosfluxTalk13:21, 28 October 2024 (UTC)[reply]
Regarding the attack vector for users with the electionadmin, a compromised account could add more scrutineers to the poll. Thus the risk would be that everyone in the group with the securepoll-view-voter-pii right could gain access. So for simplicity, I think we should be prepared to accept that everyone with the securepoll-view-voter-pii right might have access. If want to be able to move users in and out of this group on a per-poll basis, then there should be a separate user group for it. isaacl (talk) 18:45, 28 October 2024 (UTC)[reply]
Note: It is certainly possible we could have multiple, overlapping secure polls at the same time on different topics with different admins, etc. — xaosfluxTalk18:52, 28 October 2024 (UTC)[reply]
So one thing that needs to be considered is, first assuming we collect the PII in SP, is that if a scrutineer wants to be able to further investigate a voter using other on-wiki data, they will also need to be a local checkuser to be able to check those logs. So it needs to be established that those checks are appropriate, and additionally we currently give arbcom exclusive decision making authority on who may be a local checkuser. — xaosfluxTalk18:50, 28 October 2024 (UTC)[reply]
Echoing Xaosflux above, I believe electionadmin / securepoll-view-voter-pii does not grant every electionadmin the ability to see every voter's data ever. I think it just grants the ability to be added to a poll during setup. There is compartmentalization. So how this would work in practice if we gave the right to all the checkusers is that when we have an election, we'd probably want to pre-pick 3 checkusers to scrutineer the election, add them to the poll, then only those 3 would have access to the data. Right now the way I am asking WMF to set up SecurePoll for us is to let any admin create a poll, and then only that poll's designated electionadmins can edit a poll or scrutineer. phab:T378287. There's 3 pending patches related to phab:T377531 that may change some details of how SecurePoll permissions work. We may have some additional clarity after those patches are merged and have been in production for a few weeks. –Novem Linguae (talk) 19:08, 28 October 2024 (UTC)[reply]
I think we need a discussion of who should have it. The RfC linked above gave this meta page as an explanation of what an 'electionadmin' is, and it says (perhaps contrary to the default in the documentation) that it's a right that allows users to set up elections with SecurePoll. – Joe (talk) 07:38, 29 October 2024 (UTC)[reply]
I'm opposed to local CUs doing scrutineering. For electionadmin (excl PII), I don't see why we don't give it to the Electoral Commission only? They're elected to manage the ACE process. This is distinct to option 2 in my eyes; it would be assumed consensus upon election of an Electoral Commission (perhaps the crats could action the userrights changes). For AELECT, it's trickier but could be discussed in post-trial discussions. For PII scrutineering, I think we should continue using stewards for ACE; for AELECT it's up in the air (and subject to them willing to do it, and the frequency of admin elections being reasonable for them, I'd prefer stewards handling it). ProcrastinatingReader (talk) 22:11, 29 October 2024 (UTC)[reply]
But is it really good to require relying on Stewards for local stuff? It just seems more logical to me that we make it all an on-wiki process. I just don't see why not local CU. Aaron Liu (talk) 22:22, 29 October 2024 (UTC)[reply]
I think so, at least for scrutineering. Stewards are happy to deal with it AFAICT and it's been the way it's done historically. Aside from independence reasons, I'd be concerned with local CUs doing election scrutineering with PII because that would give local CUs a dual-purpose. Their purpose atm is tackling abuse, and they're restricted by the Wikipedia:CheckUser policy. In particular, they need cause, and their checks are logged. But scrutineers see all voters', which is a large portion of the active editor userbase, and their checks aren't logged. I find it hard to reconcile this in my head with the restrictions placed upon CUs in our local policy, which become meaningless to my mind if CUs can see most active editors' IPs come ACE/AELECT anyway. ProcrastinatingReader (talk) 22:29, 29 October 2024 (UTC)[reply]
Not exactly sure what @Xaosflux meant above, but the task he mentioned only said that it was a bit too easy (as in friction, not permission) to access the PII, not that it's not logged; in fact, the task links to phab:T271276, which made access logged. Correct me if I'm wrong, but don't the list of users who can access PII have to be whitelisted by the electionadmin for every election? Aaron Liu (talk) 23:42, 29 October 2024 (UTC)[reply]
Yes, to see securepoll data you have to be an explicitly listed admin for the specific poll you want to view; to be eligible to be listed you have to currently be in the electionadmin group. Viewing the securepoll data is logged in securepoll. It is also possible to configure a poll to not collect personal data at all, so just the public list of usernames would be available. — xaosfluxTalk23:53, 29 October 2024 (UTC)[reply]
I didn't know about the feature mentioned in phab:T271276 and didn't see it in localhost, probably because of some missing setup. It does seem to be logged after all. Nevertheless, it just records that someone saw the full list – there's obviously no way of logging whose PII they happened to look at or take note of. That's more of what I meant. – SD0001 (talk) 22:19, 30 October 2024 (UTC)[reply]
A possible solution CUs having a lot of instant access, if a CU wants to become a PII scurtineer, they would have to apply to it, and a group of trusted users (crats/ArbCom/anyone else that the community deems trusted) can approve it. This perm can be granted/requested per election, and they would be added into the securepoll view PII whitelist. ~/Bunnypranav:<ping>10:35, 30 October 2024 (UTC)[reply]
In summary, you're proposing we ask bureaucrats to give people the electadmin right. Honestly, since we (probs. justifiably) don't appear to want SecurePoll to be frictionless, I think that's a good-enough idea. Aaron Liu (talk) 22:21, 29 October 2024 (UTC)[reply]
The original purpose of the arbitration committee election commission was to be able to decide on questions that needed to be settled quickly to be effective, and thus a community RfC discussion wouldn't be feasible. Community expectations has shifted the role to include more management of community comments. Most of the election management continues to be done by other volunteers. Personally, I don't like continuing the trend of making the commission more central to the arbitration committee election process as I'd prefer that it remain a largely hands-off role. I like how the arbitration committee elections are run through a grassroots effort. isaacl (talk) 22:38, 29 October 2024 (UTC)[reply]
How are election admins on votewiki currently decided? It looks like Cyberpower and Xaosflux have had electionadmin for various periods.[9][10] Is consensus needed, or do WMF just appoint people who express interest in helping manage the process? ProcrastinatingReader (talk) 22:46, 29 October 2024 (UTC)[reply]
When an election is being configured on votewiki the coordinators have accounts made and are added to the group, then are added to the election, as are the scrutineers. In elections such as ACE, the coordinators are removed when voting begins so they can't access the PII that gets collected. — xaosfluxTalk23:55, 29 October 2024 (UTC)[reply]
When there are non-technical coordinators, they may not get added as they wouldn't have anything to do - in which case the WMF resource generally does all the work. — xaosfluxTalk23:56, 29 October 2024 (UTC)[reply]
I'm going to split a couple of ideas out in to subsections below. There are a few complicated things that need to be considered. Let's assume this isn't for ACE right now, but for any other use case we decide to use securepoll for. — Preceding unsigned comment added by Xaosflux (talk • contribs)
create new separate userright Setting up elections is a specialized, new, sensitive, very social process. Although elections require checkuser services and support, there is little overlap in the roles. I presume how this is going to work is that we have a noticeboard for requesting elections, a form to complete in that noticeboard, and then the electionadmin will use the tool which generates the election instance. When the election is complete, then I think the electionadmin should turn the results over to a checkuser for scrutiny. The major English Wikipedia election is Wikipedia:Arbitration Committee Elections December 2023/Coordination, but I think that whomever is in this role for English Wikipedia should be open and eager to collaborate across wikis with elections including Picture of the Year, WMF board elections, special elections like the Movement Charter, and Community Wishlist. All of these elections have had very serious social challenges which are beyond the role of technical functionary. It may not fall to the role of electionadmin to resolve all social issues, but the electionadmin certainly should not create election instances carelessly or without confirming that community support for an election is in place. The results of Wikimedia elections direct investments at least in the tens of millions of dollars. This election committee should consider the possibility of requesting a budget from the Wikimedia Foundation to communicate the elections, train election coordinators, discuss election policy and best practices across languages and wikiprojects, and try to establish some social and ethical norms that apply through Wikimedia projects. I would like for people to trust our elections and believe that Wikipedia is democratic. Activities like "promoting democracy" are not in the scope of checkuser duties. If we assign this userright to checkusers, then I think that will restrict elections to what checkusers currently do, rather than allow us to design elections to meet community needs. And yes of course - people with electionadmin rights should not get checkuser access to personal data. Bluerasberry (talk)21:11, 1 November 2024 (UTC)[reply]
While I have many words to say against your argument on electionadmins, this is a workshop, so at this point I think we should accept "create new electionadmin user group" and "add electionadmin to all admins" as separate options.
If we assign this userright to checkusers, then I think that will restrict elections to what checkusers currently do, rather than allow us to design elections to meet community needs.
@Aaron Liu: Scrutineering and election administration are non-overlapping workflows. Part of scrutineering is checkusering. Another part of scrutineering could include confirming that someone is eligible to vote by non-standard, non-machine readable criteria, which Wikimedia elections often include. For example, elections over off-wiki processes often give voting rights to people who contribute to Wikipedia outside the Wikimedia platform, such as by processing Wikimedia Commons content for upload or similar. Bluerasberry (talk)00:31, 2 November 2024 (UTC)[reply]
I'm fairly sure election administrators configure the list of eligible voters, not scrutineers. I have trust in administrators to conduct diplomacy and even more trust in a potential group of "specialized, sensitive, and very social" users. Aaron Liu (talk) 00:39, 2 November 2024 (UTC)[reply]
Scrutineering and election administration are non-overlapping workflows. I agee. I envision splitting electionadmin into a user right that adds and edits polls, and a user right that scrutineers polls. They are currently kind of combined. phab:T377531. –Novem Linguae (talk) 05:55, 2 November 2024 (UTC)[reply]
You lost me a bit in the second half of your post, because you switched to talking about global elections and WMF budgets. I think that would be unrelated to what we're talking about here, which is developing the ability for enwiki to host its own non-global elections, with the goal of 1) not depending on and using the resources of global partners such as stewards and WMF Trust & Safety, 2) developing the technical and social ability to hold many more elections than we do currently, and 3) increasing autonomy. Our use cases are things like WP:ACE and WP:AELECT. By the way, global elections are their own special beast, and are much more technically challenging than local elections (phab:T355594, wikitech:SecurePoll#How to run a board election), and basically require WMF Trust & Safety and WMF software engineer support no matter what, unlike local elections which will run completely self-sufficiently once we have a system in place. –Novem Linguae (talk) 05:53, 2 November 2024 (UTC)[reply]
Do we need PII in SP for local elections?
So this is something that is going to be important as to who is going to be allowed to do what, and how they will be allowed to do that. Polls don't have to collect PII. If they don't, they will still collect usernames. PRO's are that if we don't collect PII in the vote action, then the bar of who can administer elections is much lower. The con is that checkuser data of the vote-action isn't collected. Keep in mind the username is still collected - and checkuser investigations of everything that person has done on-wiki can continue as per normal. This is very close to how it is in RFA now, if the only edit/action that wasn't checkuser recorded for someone was their "vote". — xaosfluxTalk14:26, 30 October 2024 (UTC)[reply]
I like the idea of collecting the PII from the voting data, as it's a good way of excluding some socks and catching others. However that's not the really the purpose of having a poll, so I don't see why its collected. Maybe I'm missing something, is there some other reason to collect the data? -- LCU ActivelyDisinterested«@» °∆t°15:33, 30 October 2024 (UTC)[reply]
The purpose of collecting the PII is to detect attempts to circumvent the one person, one vote requirement by one person voting from multiple accounts. This is done by analysing the public and non-public information in the same way that checkusers at SPI do. At arbcom elections struck votes fall into five categories:
Editors in good standing voting twice from the same account. This is permitted and should just automatically invalidate the older vote but occasionally it doesn't happen. Scrutineers strike the earlier vote.
Editors in good standing voting twice with different accounts in good faith. e.g. someone with a valid alt account wanting to change their vote but forgetting which account they used first time, or forgetting that they'd already voted. Scrutineers strike the earlier vote.
Editors discovered to be sockpuppetteers by normal means after they have cast votes. If only one account has been used to vote the most recent vote by that account is allowed to stand, if multiple accounts have been used to cast votes then all the votes are struck.
Known sockpuppetteers voting with one or more accounts discovered to be sockpuppets by the scrutineers. Scrutineers strike all votes.
Editors, not previously known to be sockpuppetteers, discovered by scrutineers to be voting with multiple accounts in bad faith. Scrutineers strike all votes.
Without PII being collected I believe that the first three types of multiple voting would still be detectable, the rest would not. Sockpuppetteers who vote using only one account will not be detected by scrutineers regardless of whether PII is collected or not. Thryduulf (talk) 16:43, 30 October 2024 (UTC)[reply]
The last two fall into the using the poll to catch editors who are socking that I mentioned, but should this be something that's part of the poll? I guess the main issues would be a sockpuppetiers setting up accounts that allow for voting, and then never using them again. That would be near impossible to catch unless they slipped up before hand.
Say the was a EC requirement to vote, a malicious actor could setup multiple accounts, use them to make good edits in completely separate areas to avoid scrutiny, and only bring them together within a vote in an attempt to sway the outcome. The normal methods for catching sockpuppets would be ineffectual in stopping that.
CUs who aren't election admins can't see anything more about the vote/voter that a normal admin can, even if they have a reason to look. Thryduulf (talk) 20:20, 30 October 2024 (UTC)[reply]
Sorry, I meant the scrutineers, not either of the above. I know that this is somewhat CU procedure and typed my thoughts out wrong :) thanks for the correction Aaron Liu (talk) 20:32, 30 October 2024 (UTC)[reply]
only if the poll is set to collect PII. I don't see any option to turn off PII collection on the page Special:SecurePoll/create. One way to turn that off would be to not grant the user right securepoll-view-voter-pii to anyone. Unless I am missing an option somewhere. –Novem Linguae (talk) 21:13, 30 October 2024 (UTC)[reply]
Hmmm, seems like this feature didn't get off the ground (only hide the voter list from other voters did). Sort of why we are in idea lab though -- if this is useful we could put in a feature request do "disable PII collection". — xaosfluxTalk22:02, 30 October 2024 (UTC)[reply]
Electionadmins do not need access to personally identifying information Someone should be able to scrutineer election data. Right now checkusers do that. I do not think electionadmins should have access to personally identifying information, but they should be able to consult with checkusers or have some way to confirm election validity. Bluerasberry (talk)21:15, 1 November 2024 (UTC)[reply]
This is about whether scrutineers should have access to PII, not about electionadmins. Scrutineers are the people whitelisted for each election to view a list of the browser-used and IP-used for every vote. Aaron Liu (talk) 22:21, 1 November 2024 (UTC)[reply]
?? I must be misunderstanding. Who gets whitelisted to scrutineer, and on what basis? As I understood, checkusers can already do this, and the discussion is about whether users with the electionadmin right could additionally scrutineer. Is "whitelist to scrutineer" an additional class of users? Bluerasberry (talk)00:36, 2 November 2024 (UTC)[reply]
No, this subheading is about whether scrutineers should be able to access PII, not electamins. For each election, highly trusted users (so far, with the votewiki elections, those users have been stewards) are asked if any of them would like to volunteer to scrutinize the election (and just that election, though they can also volunteer to scrutinize futre elections separately). After that, when setting up the election, two lists have to be added by an electamin: 1. a list of all users who may vote; and 2. a list of users who may view the PII-containing logs of voting.A list from which a software may "bouncer" to deny everybody not on the list is called a whitelist. Aaron Liu (talk) 00:49, 2 November 2024 (UTC)[reply]
Who gets whitelisted to scrutineer, and on what basis? Depends on the election. One common format is to pick 3 stewards to scrutineer an election. Then WMF T&S gives them electionadmin permissions on votewiki, and they are added to just the election they'll be scrutineering. As I understood, checkusers can already [scrutineer]. I don't think this is correct. The checkuser group does not have any SecurePoll related permissions by default. We would have to change the #Wikimedia-site-config via a Phabricator ticket. However giving checkusers these permissions is a logical idea since checkusers have already signed the NDA and are already trusted to handle the kind of voter data that SecurePoll collects. –Novem Linguae (talk) 06:03, 2 November 2024 (UTC)[reply]
Checkusers do not currently scrutineer our elections and never have. Stewards, those who are not from enwiki, do it. Nobody aside from the three designated stewards who are scrutineering (which are any three stewards who volunteer) are the only ones who see the PII of voters in elections. ProcrastinatingReader (talk) 09:55, 3 November 2024 (UTC)[reply]
No PII means no scrutineering. Are we comfortable with having 600 vote WP:AELECTs or 1,600 vote WP:ACEs without anyone double checking IPs and user agents for obvious socks? I'm leaning towards yes collect PII. Also SecurePoll does not currently appear to have an option to turn off PII collection. –Novem Linguae (talk) 06:22, 2 November 2024 (UTC)[reply]
No PII means no scrutineering. I wouldn't say so. It would mean elections have the same level of (sockpuppetry) scrutineering as RfAs, where only usernames are visible. I don't really think a sock is going to change the outcome of an ACE election. At the same time, it may well help ensure the integrity of elections, if even through deterrence, thus I'm ambivalent on whether to collect PII.
I think either stewards scrutineering with PII or no PII scrutineering are OK with me. I'd prefer either of those options to local CUs scrutineering though, which I find a bit discomforting. ProcrastinatingReader (talk) 09:54, 3 November 2024 (UTC)[reply]
It would mean elections have the same level of (sockpuppetry) scrutineering as RfAs At the moment, not exactly – an RfA vote is an edit, so its PII is available to CUs, whereas a SecurePoll vote is not logged to Special:Log, so the CU tool has no access to its PII. I've filed phab:T378892 regarding this. I concur that local CUs should not get access to the wholesale PII of all voters. Scrutineering should be either done by local CUs using the CU tool only (assuming the ticket is resolved), or by external stewards like currently. – SD0001 (talk) 10:48, 3 November 2024 (UTC)[reply]
Do we need to encrypt the backend poll data?
How people voted isn't available through the securepoll system, but when setting up a poll you can optionally choose the configure encryption. This will prevent vote data from being able to be accessed by system administrators who read the datastores. This provides quite strong voter secrecy. The downside is that cryptography is hard, and will require election administrators to understand these aspects, develop and strictly adhere to secure processes for key management. As this larger idea is about who can be an election admin, if we need this component we will need a way to ensure that such admins are not only trustworthy, but that they are also technically competent. — xaosfluxTalk14:26, 30 October 2024 (UTC)[reply]
I'm confused, you say How people voted isn't available through the securepoll system and encryption will prevent vote data from being able to be accessed by system administrators. So to clarify without encryption can system admins see how people voted, or is that information store elsewhere? -- LCU ActivelyDisinterested«@» °∆t°14:35, 30 October 2024 (UTC)[reply]
When you create a poll, you can choose to optionally encrypt the poll data. This can be done with SSL or GPG keys. If you encrypt the poll, the stored data can't be read by system admins (note, this is not a wikipedia admin, or 'election admin', but the back-end server administrators). Finalizing the poll requires loading the decryption key in to the tallying mechanism. If the poll isn't encrypted it is possible the vote data could be accessed by system admins accessing the raw stored data. In either case, the software doesn't ever produce a voter:choice output. — xaosfluxTalk15:01, 30 October 2024 (UTC)[reply]
Ok so the choice that voters make isn't accessible even without encryption, which would suggest encryption isn't needed. What general type of information about the vote data is accessible without encryption? -- LCU ActivelyDisinterested«@» °∆t°15:05, 30 October 2024 (UTC)[reply]
It's not available through the poll system (the confidentially risk is only of stored raw data for server admins). The public data is what you can already see on all elections: date of vote, name of voter, and if the vote has been replaced or stuck. — xaosfluxTalk15:19, 30 October 2024 (UTC)[reply]
Note that the current poll encryption feature still doesn't entirely prevent an actively malicious sysadmin from, say, modifying the software to do something with the unencrypted data either before it's encrypted or after it's been decrypted to be counted. Of course that's much harder to pull off than just reading the unencrypted database (especially if you don't want to leave any traces) and requires a bit more server-side access, but not impossible. Taavi (talk!) 15:14, 30 October 2024 (UTC)[reply]
(no opinion in whether it should be encrypted, just stating some facts) Not all sysadmins are WMF staff. And there are a total of 192 sysadmins, which is much more than you might expect. * Pppery *it has begun...17:34, 30 October 2024 (UTC)[reply]
Out of curiosity, where's the 192 number coming from? Folks in the ops LDAP group would definitely have enough database access to modify votes in the SQL database, but that's only 65 people I think. Who'm I missing? –Novem Linguae (talk) 21:26, 30 October 2024 (UTC)[reply]
Yes. The first two can modify the running code, and analytics-privatedata-users can also read things from the database (in addition to the restricted group). Taavi (talk!) 04:20, 31 October 2024 (UTC)[reply]
analytics-privatedata-users contains 270 people, 128 of whom are already in one of the other groups, making 334 people total. No, I don't expect any of them to go snooping, but it is what it is ... * Pppery *it has begun...21:53, 31 October 2024 (UTC)[reply]
Given that voting choices could be accessed I would say it needs to be encrypted. Obviously this only makes it harder to access the information not impossible, but that is true of all such measures. Account passwords are required even though as a security measure they can be overcome.
This should be decided on a case-by-case basis. If a WikiProject is using SecurePoll to elect its coordinators, using encryption seems like overkill. For ArbCom elections, on the other hand, I see no reason not to encrypt. For such significant elections, there would be no shortage of volunteers who can handle OpenSSL keys. – SD0001 (talk) 17:59, 30 October 2024 (UTC)[reply]
Leaning no to encryption. Seems like overkill. "Make the workflow more complicated for every electionadmin in every election" vs "make it harder for a rogue sysadmin to tamper with an election one time or a couple times until they get caught/fired/access removed" seems to be the tradeoff to weigh here. –Novem Linguae (talk) 21:28, 30 October 2024 (UTC)[reply]
It's not tampering with the result that is the problem, and reading the vote choices is unlikely to get caught. I wouldn't vote if I knew my vote was so easily accessible. -- LCU ActivelyDisinterested«@» °∆t°22:01, 30 October 2024 (UTC)[reply]
I'll have to try out encryption in a SecurePoll test wiki sometime. I should probably also take a peek at the database and see exactly what it encrypts. But my impression is it increases complexity for the electionadmin, who has to do stuff like generate encryption keys, then make sure the encryption key doesn't get lost else the entire election's results are lost. This will reduce the pool of folks that can easily administrate an election, limiting it to a small pool of technical users who are familiar with this encryption workflow. –Novem Linguae (talk) 06:08, 2 November 2024 (UTC)[reply]
Avoiding a long month of drama
Well. WP:RECALL is upon us now, and, while clearly an improvement for community accountability, the first petition is already showing that the system has its limits. To be fair, that is to be expected – we can't really brainstorm a perfect system without any real-life testing, and such a new system should be open to community inputs for tweaking it into a more functional state.
Namely, the issue is with recall proposals that are, from the start, overwhelmingly likely not to succeed. In a case such like this one, where the number of (informal) opposes far outweighs the number of signatories, prolonging the long drawn-out process (the petition being open for a month, and then potentially seven days of RRfA) isn't desirable if the outcome is already pretty much known. I figure there should be a way to cut short petitions where it is clear that most editors are not behind it, a sort of WP:SNOW close, to avoid dragging the admin and the community through a month-long slog.
Of course, the petition itself shouldn't be the final !vote on admin accountability, but only a means to bring up the issue. So, if we go through an opposes/signatories ratio to close it early, for instance, it should be pretty high (maybe 3 to 1?), but still allow a way to cut short petitions with no chances of succeeding. Chaotic Enby (talk · contribs) 13:55, 28 October 2024 (UTC)[reply]
Discussion ongoing: limiting petition participation to signatures Discussion ongoing: shortening the recall period Links added 12:24, 7 November 2024 (UTC) —Folly Mox (talk)
Agreed. If each person were allowed to write a single short statement (absolute maximum 2 sentences) about why they support/oppose and no discussion or replies were allowed then a month would be reasonable. A month of what's currently happening at the first petition is completely unreasonable - a week of that plus a week of RFA hell is not reasonable even for someone whose conduct is beyond the pale (and they should be at Arbcom anyway) let alone a month for someone who has just made a few minor mistakes or pissed off a few people.
The Crats should be empowered to close petitions early if the result is clear (either way). Arbcom still exists as a venue should people think that a petition that was going to succeed was closed too early. Thryduulf (talk) 14:15, 28 October 2024 (UTC)[reply]
Isn't the primary point of the petition process to ensure that we don't have frivolous RRFAs? It seems that most of the participants are already trying to skip to a future RRFA discussion that may not even materialize. — xaosfluxTalk14:23, 28 October 2024 (UTC)[reply]
That is indeed an issue, the petition is itself getting a RfA-like amount of discussion before the RRfA even started. Thryduulf's proposal of limiting the conversation to a single short statement per person could make it much more manageable, and cut short the problem by making 30 days long petitions less awful. Chaotic Enby (talk · contribs) 14:59, 28 October 2024 (UTC)[reply]
Opposes don't formally affect the outcome of the petition, that's what the RRfA is for. From my own thought process (and from what I read from that discussion), opposes can only dissuade potential petition signers to NOT sign the petition. fanfanboy(block)14:39, 28 October 2024 (UTC)[reply]
I know, that's why I was referring to them as informal opposes above. But there should still be a way for the community to formally state that the vast majority is not in support of a petition. At least to shut down frivolous petitions in advance. Chaotic Enby (talk · contribs) 14:57, 28 October 2024 (UTC)[reply]
The Lizardman's Constant means that pretty much all views will be supported by some people, so no, I don't think we can rely on that. It's a complete waste of everyone's time if we only pay attention to the support votes and force a WP:SNOWBALL petition to go to RRfA. Theknightwho (talk) 18:34, 30 October 2024 (UTC)[reply]
There is no drama except what some editors are creating. I don't think an admin is going to quit because they discover that five people think they shouldn't be an admin. Those that oppose the petition can just... not sign it. It'll be over in 30 days. I'm not opposed to shortening the 30 days but I'd rather wait at least one full cycle before deciding. Preferably more than one full cycle. Levivich (talk) 14:47, 28 October 2024 (UTC)[reply]
As I have said elsewhere, we need to reduce the drama surrounding these. I agree that people opposing the petition should just leave it alone. There should be no discussion section and no threaded responses to endorsement; a week of discussion (which is plenty) happens once the petition is successful. Additional discussion only makes the signal to noise level worse and cranks up the heat. —Kusma (talk) 22:54, 29 October 2024 (UTC)[reply]
Agree with some of the others that shortening the time makes sense, though I don't think we should be cutting it to shorter than 2 weeks if we started at 30 days. 25 signatures in 30 days does seem really out of wack - less than one signature a day, in a community this large, where RFAs have some 200 votes in a week and we've already got more than 400 votes in the admin elections? Seems very off. -- asilvering (talk) 16:12, 28 October 2024 (UTC)[reply]
Thing is that many editors (including myself) voted for the 30 days. Now seeing what has happened, I agree it should be shortened. 2 weeks seems like a good number. fanfanboy(block)16:21, 28 October 2024 (UTC)[reply]
I suppose, we'll have to be mindful of the potential for editors to seek an administrator's recall, who blocked/banned them, in the past. Grudges are always possible as being a core of recall attempts. GoodDay (talk) 14:46, 28 October 2024 (UTC)[reply]
I think shortening the time period for the petition to 10 or 14 days makes sense. I would oppose allowing snow closes regardless of how unlikely it appears that a petition will pass. ~~ Jessintime (talk) 15:18, 28 October 2024 (UTC)[reply]
I'm inclined to believe that, instead of tinkering with this on an ad hoc basis with every new petition, we modify the terms of the recall process to be a six-months trial and then -- at the end of that -- evaluate everything that worked and didn't and make whatever modifications are needed in one fell and final swoop. Chetsford (talk) 16:25, 28 October 2024 (UTC)[reply]
@Chetsford The close of the final RfC establishing recall instructed that any outstanding issues may be resolved through normal editing. (emphasis mine), and personally, I am very burnt out by all the multi-step trials and ratification RfCs that sprung out of RFA2024. Mach6116:47, 28 October 2024 (UTC)[reply]
To be fair, this is a discussion on the idea lab, so the goal is first to figure out what to change before figuring out how to change it. And also because, even if a user could technically make a WP:BOLD edit, having a consensus behind it is always good. Chaotic Enby (talk · contribs) 17:00, 28 October 2024 (UTC)[reply]
I looked at the petition before it closed, and realised multiple editors opposing it despite it not having any effect. I think it should be possible to run a petition in a closer timeframe to an RfA or AfD. To summarise, petitions could be changed as follows :
Each petition runs for exactly a week.
Any extended confirmed editor can support or oppose the petition
If consensus is reached to desysop after a week (ie: support / support + oppose = 70% per current RfA thresholds) then the admin is desysopped
I think holding an admin to the threat of being desysopped for over a month is worse than what happens at Arbcom. Conversely, if the community is in obvious agreement than an admin has outstayed their welcome and must go, it gets the job done far more quickly without people getting frustrated about when it's going to happen. And furthermore, if somebody starts a petition in retaliation ("Desysop this admin, he blocked me for no reason!") it'll get short shrift and SNOW opposed by the community.
The only issue I have with that is theoretical. Ostensibly, the petition is supposed to create a turnstile sparing an Admin from having to go through the back-and-forth of an entire RfA unless there's some minimum support for that. In other words, ideally, the Admin simply ignores the petition until or if the threshold is met. Only then do they need to ramp up to start compiling, potentially, years of diffs, etc. to defend themselves at RfA. Going straight to RfA means any single, aggrieved editor can encumber an Admin with the significant angst of a full RfA. Of course, that's all theoretical. As we've seen from the current example, the mere act of petitioning creates the angst it was designed to mitigate. So, if we're going to introduce a Reign of Terror anyway, we may as well make it the most efficient Reign of Terror we can come up with, on which basis I'd support this suggestion. Chetsford (talk) 17:01, 28 October 2024 (UTC)[reply]
The other option would be to make it so that the petition doesn't turn into a Reign of Terror to begin with. Which is easier said than done, but a good first step would be to limit back-and-forth conversation and just have it be, well, a petition. Chaotic Enby (talk · contribs) 17:05, 28 October 2024 (UTC)[reply]
I do have a few concerns on that. In this situation the Admin is being recalled for reasons no one is allowed to articulate to them, but maybe they'll learn them during sentencing (RfA)? I liked The Trial as much as anyone, but I'm not sure how I feel about recreating it IRL. But I'm open to whatever. Chetsford (talk) 17:13, 28 October 2024 (UTC)[reply]
No it wouldn't prevent reasons being given, it would just restrict discussion of those reasons. So everybody supporting or opposing the petition would be able to (arguably should be required to) give a single short statement (50 words or 2 sentences have been suggested) about why they are supporting/opposing. However there would be no discussion unless and until an RRFA was opened. There would be no restriction on clarification being sought on user talk pages, e.g. if user:Example wrote "Support because of their actions at the recent AfD" anyone would be allowed to go to user talk:Example and ask which AfD(s) they were referring to if it wasn't clear. Thryduulf (talk) 17:20, 28 October 2024 (UTC)[reply]
I would say no. If the petition can get 25 people to agree (despite all the issues of the discussion section), then the RFA should run. Y'all are Streisanding the current petition and bringing people in. If it was as sterile and clinical as the process laid out was supposed to be, it would more than likely died in a month. spryde | talk20:52, 28 October 2024 (UTC)[reply]
I think any petition is going to get significant amounts of attention, maybe not quite this much if they become routine, but certainly enough that it's never going to be "sterile and clinical" under the current setup. Thryduulf (talk) 21:14, 28 October 2024 (UTC)[reply]
If the time is reduced to a week, then the number of signatures needed should be reduced. I also don't understand the point of opposition statements. If it is a petition, then there should just be people signing it, maybe proposing changes to the petition statement. It seemed like a lot of the opposition was based on people not likely the process. There is already a problem with accountability for admins in Wikipedia, because admins are not only well known, but have power to block people, and probably have more knowledge of how Wikipedia works than the poor editors who try to recall them. Admins are pretty safe. Term limits would have been a better solution, as well as temporary blocks for admins. Tinynanorobots (talk) 11:35, 29 October 2024 (UTC)[reply]
For now, we have a sample set of one incomplete case. Ten editors have signed the petition in the first 40 hours. A linear projection would predict that 25 signatures would be reached in less than five days. Some commenters have assumed that the level of opposition expressed to this petition indicates that Graham87 would retain the admin bit in an RRFA. If a case that appears this weak does reach 25 signatures in less than a week, why should we have to wait a month for cases where there is less enthusiasm for signing a petition. I will note that the rate of new signatures likely will decline, prolonging the end, and that some commenters are claiming that many potential signers will wait to the last minute to sign to avoid social pressure, but that is not an argument for waiting a month, as they can sign the petition at the last minute whether the duration is for a week, two weeks, or a month. But, as I said, this is the first case, and my crystal ball is very murky. Donald Albury13:39, 29 October 2024 (UTC)[reply]
I think that that first recall petition showed some of the warts of the process in a really stark way. Floating 4 significant changes for the community to think about here, either separately or in combination:
1) - The petition process is too long. If these are going to turn into mini-RfAs, then the petition needs to be significantly shorter than a RFA. 24-72 hours is plenty of time to see whether the petition has legs, anything more is cruel.
2) - The petition is too easy to initiate. I know that people will complain about cabals, but I really think it should take an admin to initiate one of these. Alternatively a small group (3 ish) of extended confirmed users works.
3) - We should move from number of supports to number of net supports. If a petition has 1 net support at closing time, it can go through as prima facie evidence that the petition has legs. If the ratio of opposes to supports gets over 2-3 to 1, we can close early without losing many petitions that would wind up successful.
4) - The commentary is too much. Restrict people, both support and oppose, to something very short, like 10 words and 1 link.
Obviously this is idea lab, so please discuss which of these have merit fluidly either alone or in any combination. tweak numbers, break things. Tazerdadog (talk) 17:07, 28 October 2024 (UTC)[reply]
I'd agree with shortening the petition process (although 72 hours might be too drastic), but I think turning them into mini-RfAs is not the goal. The point of the petition is to see if there is a substantial number of editors wanting a recall election to begin with, not to replace the recall election entirely. And, if you need to get 3 people on board to start the petition, you're functionally making a petition for the petition.For the same reason, net supports shouldn't really be what is measured (as it isn't about whether the admin has majority support, but only about whether some people are questioning it). A large oppose ratio, however, would indicate the petition will likely not be successful, so the early close you suggest could work. Also agree with your idea of restricting commentary, as said above. Chaotic Enby (talk · contribs) 17:11, 28 October 2024 (UTC)[reply]
The old RFC/U process required two editors to sign within 48 hours, or the page would get deleted. These two editors had to show evidence(!) of having attempted to resolve the same(!) dispute with the targeted editor. This was fairly effective at preventing RFC/Us over disputes that just needed a Wikipedia:Third opinion. WhatamIdoing (talk) 18:43, 29 October 2024 (UTC)[reply]
It's impossible to constrain the discussion when the petition has started and for the petition page not to turn into a quasi-RfA. That's why the petition signatures and comments should be understood as RRfA !votes. The signatures would begin counting as !votes when 25 of them are collected, and prior to that, the signatures would be null !votes, and only valid as fulfilling a precondition to their collective validity as !votes. A signature is actually a latent 'oppose adminship' RRfA !vote. An "oppose petition" comment is actually a 'support adminship' RRfA !vote. At any point, if the admin does not like the protraction and feels secure about passing, the admin can cut the petition stage short and start the RRfA with their statement, answers and all, without a need to wait for signatories to reach 25. That imbues all signatures with the power of a !vote immediately, regardless of how many there are, whereas the "oppose petition" comments have had the power of a 'support adminship' !vote all along. If the admin doesn't feel secure, they can wait it out, and are protected by the fact that the opposition to their adminship is ineffective until it reaches the critical mass of 25 signatories. It isn't reasonable to think that the admin is unfairly treated by the fact that opposition to their adminship is rendered ineffective until a difficult procedural barrier is overcome; that's obviously a mechanism that protects their status. If they don't feel like they need that protection, if the climate seems friendly to their adminship, they can relinquish it and start the RRfA.—Alalch E.17:32, 28 October 2024 (UTC)[reply]
I'm not sure we should understand them as quasi-votes, since it would be perfectly reasonable for someone to sign the petition because they think a re-RFA ought to be initiated, not because they think the admin should step down. That is, I can easily see someone putting their name on the petition because they believe a re-RFA is the right thing to do, not because they desire for the admin in question to be de-sysopped. But it's true that nothing is stopping an admin from "calling the bluff" and standing for re-RFA before the petition reaches 25 signatories. At this point, frankly, that doesn't look like it would be a bad move for our unfortunate first candidate. -- asilvering (talk) 19:27, 28 October 2024 (UTC)[reply]
The way the process is currently set up, you're right. But I would argue that it should be different (that's the idea I'm presenting): If you do not think that the admin should cease being admin, you should not sign the petition. On the material side, the petition should be presented as: "By signing you are stating that the administrator has lost your confidence"; and on the procedural side: "By signing you are stating that (because the administrator has lost your confidence and provided that he has also lost the confidence of many other editors) the administrator should undergo a RRfA". —Alalch E.11:09, 29 October 2024 (UTC)[reply]
It isn't impossible to constrain discussion. We are capable of setting and enforcing a rule that says "Signatures only. No diffs, no explanations, no discussion, no opposes". This might be fairer, since even a few words or a single diff could prompt "me too" votes from people who had no concerns of their own, and a diff or a brief comment could be taken unfair or out of context. It would probably be stressful for the admin, as people would be publicly expressing dislike without any reason.
Editors generally oppose efforts to prevent them from talking about other editors, though, so I doubt we'll end up there. More realistically, we could insist that any discussion happen on the talk page. WhatamIdoing (talk) 20:00, 29 October 2024 (UTC)[reply]
ArbCom manages to have strict rules about constraining discussion, and it does lead to more productive cases (read: not a shiftest). I would support a "Signatures only" rule, especially considering the opening comment should already be expected to have the needed context.A talk page discussion would be already lower profile and likely more calm, and ultimately look less like a !vote or like its own mini-RfA. Chaotic Enby (talk · contribs) 20:21, 29 October 2024 (UTC)[reply]
Any rule restricting what can and can't be said on the page needs to come with explicit instructions to this on the page and a clear statement of who is allowed to remove things that objectively break the rules (I'd favour "anybody"). Perhaps accompanied with a "you will be partially blocked from this page if you reinsert, without explicit advanced consensus, something removed." Thryduulf (talk) 20:46, 29 October 2024 (UTC)[reply]
That could definitely work. WP:RECALL doesn't need a set of clerks like the (much more complex) ArbCom cases do, if the only rule is "just leave a signature" or close to that. Also agree with the disclaimer, and good of you to be thinking of the implementation details already!I'm thinking of having a formal proposal with both the restriction on discussion and the shortened timeframe as independent options. Given how the WP:RECALL RfCs have been criticized for not being well-advertised, it might be good to bring this one up on WP:CENT. Chaotic Enby (talk · contribs) 21:55, 29 October 2024 (UTC)[reply]
Discussion will migrate elsewhere. ArbCom is mentioned as a counterexample, but discussion there is quite free-flowing, only formatted differently to avoid long non-constructive threads... but the stated problem here is not non-constructive threads, the stated problem is comments. That is completely different. "Discuss calmly and with measure" and "don't talk" is different. It will be possible to have an adjacent discussion on some other page or pages. And if you are blocked from the page, so what, what you added to the page, diffs and all, stays in history and can be viewed by anyone. —Alalch E.23:36, 29 October 2024 (UTC)[reply]
And if you are blocked from the page, so what, what you added to the page, diffs and all, stays in history and can be viewed by anyone.
I agree that a complete ban on discussion will result in the discussion happening elsewhere, but that's not necessarily a bad thing. Wherever there are humans, there will be gossip mongers, but gossip whispered between a few people (e.g., via Special:EmailUser) for a few days, or even for 30 days, is not as widely and as permanently destructive as accusations posted on the internet forever. WhatamIdoing (talk) 18:04, 30 October 2024 (UTC)[reply]
That elsewhere could just be the talk page, and it appears that it might just be that. Edit: All in all, "discussion elsewhere" + word limits + RfA monitor function preserved + "five uninvolved signatories first" latch mechanism could all add up to something good. I'm for trying. —Alalch E.22:32, 30 October 2024 (UTC)[reply]
It all depends on who you want to sign up to a petition. If it is only "editors who have independently decided that an admin's conduct should be examined", the only way is to disallow comments from both signatories and opponents. Otherwise many signatories will sign because they are convinced by the arguments, even if they never heard of the admin before. In that case, allowing only signatories to comment will dramatically skew the results and be quite unfair. In summary, allow everyone to comment or allow nobody to comment. Zerotalk02:10, 30 October 2024 (UTC)[reply]
I'd also like to raise another issue. We have created a risk-free way for editors to get back at an admin who has sanctioned them. I think that editors who have received a recent (definition?) personal sanction from an the admin should not be a signatory. Zerotalk02:10, 30 October 2024 (UTC)[reply]
I can see both sides of this. Perhaps a reasonable way forwards is to disallow someone from initiating a petition if they have received a recent (within the last 3 months?) personal sanction from the admin. They can still support a petition initiated by someone else, but perhaps only if 5 uninvolved editors have already supported. If there is a genuine issue this should be an easy bar to clear but it would make retaliatory petitions much harder to initiate and harder for them to succeed. Thryduulf (talk) 02:35, 30 October 2024 (UTC)[reply]
Maybe we could make it so that the first five signatures (other than the initiator) must not have been involved with any dispute in which the admin concerned acted in their capacity as an administrator within the last (1? 2? 3?) months. If five uninvolved editors are prepared to sign a petition that suggests it's more likely to have some merit than if no such group of five are? Thryduulf (talk) 02:39, 30 October 2024 (UTC)[reply]
Let's say it's day three and there are fifteen signatures. The first five signatories have not been involved in the discussed sense, followed by ten signatures from people who have been involved (they were the greater cohort that was waiting for the special signatures to add up so that they can add theirs; imagine ANI participants). One among the first five withdraws their signature ("I changed my mind after reading the talk page"). There are no longer five signatures from uninvolved signatories. What then? All's good? (Probably not.) Petition has failed? (Probably not.) Monitor halts signature collection only allowing signatures from uninvolved signatories, until one such additional signature is collected? (Probably not.) Monitor notes that the petition will be invalid unless at least one more special signature is supplied during the entire remaining period? (Maybe.) Monitor notes that the petition will be invalid unless at least one more special signature is supplied during a set period, for example three days? (Maybe.) —Alalch E.17:00, 30 October 2024 (UTC)[reply]
I hadn't thought of that scenario. The simplest option would just be a latch - once five uninvolved people have signed the petition is unlocked and remains that way for the duration. Thryduulf (talk) 19:03, 30 October 2024 (UTC)[reply]
As the two main proposals that editors seem to converge on (limiting discussion and shortening the petition timeframe) are essentially independent, I'm thinking it can be best to go for a two-part RfC, with the following questions:
Should input to WP:RECALL petitions be limited to signatures only?
Should the petition duration be limited to X amount of days?
There is also the possibility of having multiple options for each question. For the first one, an alternate proposal of limiting input to to a short statement per person was also suggested, while multiple timeframes for the petition could also be proposed. Chaotic Enby (talk · contribs) 22:59, 29 October 2024 (UTC)[reply]
I think a RFC like this needs to happen. I think the second bullet point is fairly self-explanatory, but the first needs more thought. On a recall petition, is there value in having a statement from the initiator? A statement from the admin being recalled? Statements from people bringing up new evidence? Statements/signatures from supporters? Which belong on the main page, and which belong on the talk page? If we impose a length limit, can anyone truncate statements to fit in it? Do we need clerks, arb style?
For example, I favor the initiator getting a short statement, the admin having unlimited length to respond optionally (hidden comment in the template that makes a section if they choose to respond), all recallers signature only on the main page, with limited commentary on the talk page, and any list of supporters with limited commentary on the talk page, no threaded discussion anywhere. Any editor except the initiator and the admin being recalled can move comments to enforce length/threading/talk page. This is not about my preference, but more saying that this bullet point can get really complex really fast, and we should think about that now in workshopping. Tazerdadog (talk) 02:04, 30 October 2024 (UTC)[reply]
Thanks a lot for the feedback! You're right that the first bullet point should definitely be clarified before the actual RfC.In my mind, the initiator would be able to make a short statement, with the rest being only signatures (as the point of the petition isn't to be its own RRfA, but only to gauge whether it has enough support). Regarding the admin responding, I think it (and other replies) should be reserved to the talk page, to avoid it becoming a RfA-lite where the admin has to respond to the claims to not be seen as suspicious. Chaotic Enby (talk · contribs) 02:20, 30 October 2024 (UTC)[reply]
If the admin is allowed a right of reply, but only on the talk page, it should be possible to see from just the main page whether they have chosen to respond or not. Regardless of where, everybody who has the right to comment (including the responding admin) should be subject to a word limit, although not necessarily the same limit. Thryduulf (talk) 02:30, 30 October 2024 (UTC)[reply]
In my mind, the initiator is no more or less important than anyone else who prefers to recall that admin, I prefer not creating a "first mover" advantage. So I'd rather just be strictly signatures only, or strictly "Short statement on main page without replies" for everyone.
I can get behind a word limit for the responding admin. I do think it's important that the admin have the ability to present their case in the same location that the initiator does. Tazerdadog (talk) 06:55, 30 October 2024 (UTC)[reply]
I agree with that as well, I just end up at "Initiator and all future signatures should be given same weightage" and "Maybe both should be on talk" as my preferences. Soni (talk) 05:20, 30 October 2024 (UTC)[reply]
I start with "someone should say why we're all here" and "I don't want everyone piling on with extensive commentary. I will concede that I create a first mover advantage as a consequence of those, but I think that's the best we can do. Either way, I think we can craft a RFC that presents all this fairly without too much difficulty. Tazerdadog (talk) 06:52, 30 October 2024 (UTC)[reply]
Ultimately, a "first mover" advantage makes sense in that, since they're starting the petition, they are responsible for explaining it. We don't need 25 redundant explanations, but we don't need an unexplained petition either, so it is logical that the creator of the petition be the one to state the case for it. Chaotic Enby (talk · contribs) 08:10, 30 October 2024 (UTC)[reply]
"The talk page will be open anyway", will that result in all the "pre-RRFA RRFA" stuff just happening there instead of on the petition itself? Anomie⚔07:49, 30 October 2024 (UTC)[reply]
Moving the discussion to a less prominent place behind the petition, plus a word limit as Thryduulf suggested, would definitely limit the "pre-RRFA RFA" stuff. Not everyone will go through long talk pages, making it less critical to respond than with the "in-your-face" discussion that currently runs in the middle of the signatures. Chaotic Enby (talk · contribs) 08:07, 30 October 2024 (UTC)[reply]
If it's mandated that no discussion happen on the petition page, I'm not so sure the petition's talk page would remain very much "less prominent". Sure, not everyone will bother to check the talk page, but knowing that's where discussion is I suspect anyone who would have pre-RRFA RFFA-ed as things are now would. Anomie⚔07:51, 31 October 2024 (UTC)[reply]
I don't think it's a good idea to start a two-part RFC so soon after we just ended a three-part RFC. Take note of the backlash to the third RFC; a fourth RFC will get even more backlash; a fifth even more. Levivich (talk) 16:45, 30 October 2024 (UTC)[reply]
But you really think, three days into the first petition, you've learned enough about this process to know how to change it for the better? There's no part of you that's thinking "it's too soon to draw any conclusions"? Levivich (talk) 17:33, 30 October 2024 (UTC)[reply]
I share Levivich's concerns here. Now's a fine time to take some notes, but we're 10% of the way through the first use of a process. We might learn something in the coming days, or in a second petition. We might also discover that the RFC question needs to be "Well, that was a disaster. All in favor of canning the idea completely?" WhatamIdoing (talk) 18:12, 30 October 2024 (UTC)[reply]
And this is why I said, above, We can start workshopping the RfC right now, but it's probably best to hold off opening the RfC itself for the moment given how heated emotions are. I do not claim to personally know exactly how to change the process, but we can already start discussing the shortcomings we can see, even if we are not going to open the RfC right now. Chaotic Enby (talk · contribs) 18:21, 30 October 2024 (UTC)[reply]
People have been proposing changes all over the place. Why not have a discussion that will hopefully bring up possible problems with proposed changes, even if it will be a while before any RfC should start? Donald Albury19:42, 30 October 2024 (UTC)[reply]
@Chaotic Enby: I've been thinking about how to format this RfC for a fair while. If someone has a better idea than yet another dedicated subpage, I'm all ears, because I'm not sure how else to deal with the number of proposals and changes people are asking for. theleekycauldron (talk • she/her) 18:44, 31 October 2024 (UTC)[reply]
I think subpages is fine, but we probably should try to limit the number of options to be voted on, in some way. Either by number or some other ways.
Say if a proposal is something like "For 2 future RECALL petition, the petition will not have any discussion. After this trial, you need consensus to make it permanent" - that's self contained and gives place to start off from. Much better than just trying to push through every change at once. Soni (talk) 20:56, 31 October 2024 (UTC)[reply]
That's the point of starting this discussion now. We're at the ideas stage, at some point after the first petition ends (and, if one happens, after the subsequent RRFA ends) this will move into the stage of collating those ideas that both could work and got some indication they might be supported and refining them into draft proposals. Once we have a rough idea of what and how many proposals there are is the time to work out the best structure for an RFC, as until we know those things we can't know what will and won't work. Thryduulf (talk) 00:39, 1 November 2024 (UTC)[reply]
IP editors now have the ability to turn on dark mode, which previously was limited to logged in users setting a preference. We should extend this concept to allow IP editors to set other prefernces such as disabling fundraising banners or whatever other preference they prefer. RudolfRed (talk) 23:33, 1 November 2024 (UTC)[reply]
Supporting preferences in general would mean the caching infrastructure could no longer be used for non-logged in users, which would have a big impact on the amount of computing resources required to handle Wikipedia's traffic. So I don't believe that general support is in the works. isaacl (talk) 05:40, 2 November 2024 (UTC)[reply]
They could 1. restrict preferences to a subset that won't interfere with caching; or 2. figure out a way to serve cache to everyone who didn't touch certain preferences. Aaron Liu (talk) 18:28, 2 November 2024 (UTC)[reply]
I've discussed this before so don't really want to get into the details again, beyond saying that making the servers do anything is more expensive than reading ready-to-go HTML content and sending it back. Please feel free to discuss your ideas with the WMF engineering team. isaacl (talk) 21:33, 2 November 2024 (UTC)[reply]
There was some talk in 2023 about a limited set of prefs. mw:Temporary accounts are only created upon editing, not ordinary readers. I can't remember whether they settled on creating the account at the time you open the page to edit, or if it's created only when you click the big blue Publish button, but we should expect only a few logged-out users to gain access that way. However, that requires getting temp accounts fully deployed everywhere, which will happen eventually rather than soon. (Fundraising banners can already be suppressed [for a week at a time?] via cookie; just click the button to make it go away.)
As for the desirability: You should believe Isaacl when he says that this is a lot more expensive and difficult than people think it 'should' be. WhatamIdoing (talk) 01:14, 6 November 2024 (UTC)[reply]
I don't see the slightest problem in restricting privileges like preferences to logged-in editors. If the default editing experience for IPs can be improved, that's fine, but if someone wants an experience different from the default, they already have a very simple way to get it. Zerotalk02:40, 6 November 2024 (UTC)[reply]
Comparison shopping with data from factboxes
As more information is put in Wikidata and is presented in Wikipedia's fact boxes, I think this opens a possible new feature or gadget similar to the comparison shopping offered by many e-commerce websites. As I visit the article Thailand, the factbox should have a little tick box to add this article to my personal comparison basket, and when I tick that box on another comparable object (using the same factbox template), say Chile, I should be able to view my current comparson set, presenting a table with two columns for Thailand and Chile, and rows for their attributes: capital city, main language, population, area, GDP, etc. LA2 (talk) 11:45, 2 November 2024 (UTC)[reply]
Idea to reduce issue with user pages being used for hosting a vanity page or advertisement
Some of the recent discussion on AN/I regarding Fastily and U5 closures centered on the challenges of properly addressing misuse of user pages. I believe the high volume of apparent misuse is causing difficulty in balancing protecting Wikipedia and taking due care in deletions. Anything that would reduce misuse (or reduce the consequences of misuse) should help relieve some of the pressure.
Thus my half-baked proposal below. The goal of this proposal is to reduce the attractiveness of putting up fake Wikipedia pages and holding yourself out to the world as having a page about you.
Proposal
The primary user page will automatically have the output of {{User page}} displayed at the top. Once a user becomes extended confirmed, they will have the ability to suppress display of the template. Extended confirmed users who abuse this by making an inappropriate user page can have the right to suppress display taken away by an admin. When first enacting this change, all current extended confirmed users will have the display suppressed, though they can enable the display if desired.
This is a Wikipediauser page. This is not an encyclopedia article or the talk page for an encyclopedia article. If you find this page on any site other than Wikipedia, you are viewing a mirror site. Be aware that the page may be outdated and that the user whom this page is about may have no personal affiliation with any site other than Wikipedia. The original page is located at https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(all).
Above is the output of the template, for those unfamiliar with it.
That could be a good idea. For new users who might not know it, a message could also be added to inform them that drafts should ideally not be written on their main userpage, with a link to automatically move it to their user sandbox. Chaotic Enby (talk · contribs) 20:16, 5 November 2024 (UTC)[reply]
I don't have any objection to this in principle. I think the application of this is likely to get pretty hairy, though. And I think most people write promo drafts on their userpage because they don't know they're promo and don't know that's not the place for drafts - so I don't think this would really help. But if I woke up tomorrow and this was the status quo, I wouldn't be mad about it or anything. -- asilvering (talk) 20:35, 5 November 2024 (UTC)[reply]
After giving it more thought, one objection I can see is that enforcing a banner on people's userpages might not be well-received, especially since the target demographic (non-ECP editors) likely won't overlap much with the people who will take the decision. I agree with your explanation for why people write promo drafts on their userpage, and a way to gently inform them that that isn't the place might be better.Now that I think about it, we need an equivalent of U5 that isn't "speedy deletion" but "speedy move to sandbox" (with a message informing the user of what happened, of course). Now that would be helpful. Chaotic Enby (talk · contribs) 20:40, 5 November 2024 (UTC)[reply]
The main issues with user pages seem to be promotional drafts and non-Wikipedia uses (like fake election articles for alternate history forums). It's non merely an enwiki issue - while userspace pages aren't prominently visible, images uploaded for them are. It's a big problem for Commons to have spam and hoaxes mixed in with other images. I'm not sure there's actually a common problem with userspace pages being passed off as real articles; I don't object to this proposal, but I think other changes might be more effective. In particular, I would propose stricter rules and other changes for userspace, with the primary aim of reducing incorrect userspace usage to reduce admin work:
Edit filters disallowing commonly misused elements like external links, images, and infoboxes for new users in userspace. This would essentially kill userspace for fake articles and make promotional userpages less attractive. Maybe even have a fairly strict character limit for new users - that would allow them to have a bluelinked user page introducing themselves, but not enough space for their CV or fake article.
Prominent edit notices for userspace explaining restrictions and directing users to draftspace
Disable the "upload file" link in userspace. The vast, vast majority of crosswiki uploads from userspace are junk.
Better bot patrolling of userspace. This could include creating lists of new userspace pages for easier patrolling, or even automatic moves of likely drafts to draftspace.
Partial blocks from userspace for those who misuse it. This should be more akin in seriousness to an edit filter than a mainspace block.
Formally expand U5 to include any clearly non-Wikipedia usage, regardless of whether the user has mainspace edits, after other interventions reduce userspace usage overall. Obvious junk shouldn't have to go to MfD just because the creator has mainspace edits.
As to passing off user pages as Wikipedia articles, I have encountered it once in real life, and everyone in that conversation was convinced it was real until I started reading the URL more carefully. Admittedly, this was a while ago, and perhaps people are more sophisticated now, but I suspect it is still a bit of an issue, and one that would be easily stomped out with this change. — rsjaffe🗣️22:21, 5 November 2024 (UTC)[reply]
I do agree that there's lots more things that should/could be done and appreciate your list. Perhaps the discussants here could put together a package of changes to improve the situation, though approval of each one would be independent, as some items in the package may be more of an issue than others. — rsjaffe🗣️22:23, 5 November 2024 (UTC)[reply]
I particularly like the edit filter preventing links idea. A plaintext page without through links is (generally) essentially harmless. I don't like the idea of a character limit unless it could be just applied to the top-level user page, rather than subpages which can legitimately be used for draft development. Espresso Addict (talk) 06:35, 6 November 2024 (UTC)[reply]
This is mostly in response to the first point. When creating a new article in mainspace, the little popup on the side always invites me to create the article in my userspace instead. Help:Your first article#Where to start writing also recommends placing drafts in a user subpage. I could very easily see a new editor not understanding the difference between their main userpage and a user subpage. If we block things such as infoboxes, external links, or set word limits, we will be sending a very mixed message to new users. Maybe an edit filter to block new editors from adding external links to commercial/social media sites? (LinkedIn, YouTube, blogspot, what have you). There's very valid reasons why we don't block these types of links in general, but if we're thinking about userspace spam from non-contributors, then maybe? Lots of good faith users do end up adding links to these sorts of websites, but I also think discouraging them from doing that until they've been around long enough to learn the intricacies of WP:SPS isn't a bad idea. I don't really know edit filters, however, so I have no idea how practical this would be. I also don't have enough data to throw myself behind this suggestion just yet.
Not a fan of expanding u5. But maybe, for abandoned SPAs with a spammy vibe, a process similar to PROD? A user tags something as obviously unencyclopedic, and the creator has a month or so to return to their account and contest it, or else an admin reads the userpage, confirms it's never likely to be useful, and either a)declines the tag (so it can never be tagged again) or b) bins it on the understanding that should the creator return, they can request undeletion. MfD doesn't get clogged up with long-abandoned quasi-spam, and it limits the risk of biting newer contributors since it wouldn't work on them. This won't do anything for active spam-like users, but neither does U5, seeing as they can just re-create the page as many times as they'd like before getting inevitably blocked. (And then we go back to userspace prod). There's probably flaws with this idea. I could absolutely see somebody trying to abuse it in the way U5 is abused. The most obvious way is if two editors get into a dispute, one of them is blocked, and the other tries to delete their userspace now that their "enemy" is gone. I like to think that would be noticeable, however. Also, admins would still be required, and thus required to read the pages before deleting them. If the admin fails to do so, that would be very bad.
I like the idea of removing the "upload file" link in userspace. I also think we should remove it in draftspace. I also think we should make the "upload to commons!" link less prominent. A few gours ago, I nearly accidentally uploaded a non-free book file to commons; it was only once I got to the second page when I realised I'd mistakenly clicked the giant blue box as opposed to the tiny grey one. If I'm doing that, then goodness knows what a new user who doesn't understand the difference between their own work and a screenshot is thinking. (And that's just talking about good-faith newbies who are still hunting for clues. Commons does not need anymore copyvio spam than it already puts up with.) This also would not stop users from adding images to their userspace. They would still have other ways. It would merely slow them down, force them to ask questions, and hopefully learn about copyright. GreenLipstickLesbian (talk) 09:46, 7 November 2024 (UTC)[reply]
This isn't a good template for this use. The header is harmless, but of the main text only the first sentence (to the effect of "this is not an encyclopedia article") is relevant. That sentence is needed, though, as well as a statement that this page hasn't been reviewed or quality-checked (even to the extent that normal Wikipedia articles are).Also, we don't need the option to let the page owner turn it off for everybody else, just a handy gadget to hide it for logged-in users who don't know to edit their own css. Without that, we could do this right now without the proposed software changes, which probably would never happen anyway. —Cryptic22:29, 5 November 2024 (UTC)[reply]
Oh, and I see no reason at all to limit it to the primary user page. I don't think I've seen anybody passing off a main user page in their "now read our article on Wikipedia!" link, but have to sandboxes and other subpages a couple times. —Cryptic22:34, 5 November 2024 (UTC)[reply]
Is there any way to get the software to display the namespace in User: and User talk: the way it shows up for every other namespace? Seems like that would be a step towards the goal here. Folly Mox (talk) 00:49, 6 November 2024 (UTC)[reply]
What is the onboarding (or whatever it's called) doing in the way of suggesting very new editors start user pages by the way? I did wonder if we were inadvertently inviting users to make a profile in their first or second edit, and then immediately deleting it U5 with unfriendly messages. Espresso Addict (talk) 06:59, 6 November 2024 (UTC)[reply]
Unless things have changed in the twelve months since I tested the new user signup flow, accounts are presented with a couple messages about Suggested Edits, then land at Special:Homepage. I don't remember there being (and definitely didn't screencap) anything related to creating a userpage. Folly Mox (talk) 11:19, 7 November 2024 (UTC)[reply]
It is, however, a pretty normal impulse to have, creating a userpage. Social media and various apps outright make you do it before being able to do anything else, and many newcomers will have been trained on that kind of behaviour. Also, if you're nervous, userspace edits feel safe, like you're not disturbing anybody while you're mucking around. -- asilvering (talk) 14:18, 7 November 2024 (UTC)[reply]
It's something that is encouraged in in-person training for new editors. A new editor with a userpage tends to be treated less harshly by some new page patrollers than one whose name is a redlink. Thryduulf (talk) 19:00, 7 November 2024 (UTC)[reply]
@Folly Mox, Asilvering, and Thryduulf: Thanks, Folly Mox. I think we need more advice on what the top-level user page may be used for, aimed both at new editors trying to create a profile and, perhaps more importantly, at patrollers. I've seen user pages that were entirely appropriate even for an editor with no other edits ("Hello world, my name is EA, I'm excited to edit Wikipedia!" sort of thing) being tagged G11/U5 by patrollers. (As far as I can tell, some patrollers think U5 is for anything created by a user with few non-userspace edits.) Asilvering writes, "if you're nervous, userspace edits feel safe", and I've found new patrollers think the same, it's a safe space to patrol without offending anyone who knows how to complain. And the flipside to Thrydulf's "A new editor with a userpage tends to be treated less harshly by some new page patrollers than one whose name is a redlink" is that patrollers are suspicious that a blue-linked user page is just the first step in a campaign of terror spam. Espresso Addict (talk) 23:09, 7 November 2024 (UTC)[reply]
Is there an editnotice for new users when they go to edit their userpage? I don't think there is. I don't see one when I try to edit mine, at any rate. -- asilvering (talk) 23:27, 7 November 2024 (UTC)[reply]
I'm getting the impression that some don't speak English at all and have used AI to draft something. Certainly that's true of promotional autobios submitted to draftspace in perfect American Marketing Speak, where I sometimes find it is impossible to communicate with the creator because they don't speak plain-old (British) English (and I don't speak their language). Espresso Addict (talk) 02:14, 8 November 2024 (UTC)[reply]
Okay, so this is a very barebones proposal at the moment, and I'm looking for thoughts into it, especially about viability and how likely this would be to gather consensus. This seems like the right place. Essentially, the idea I'd like to develop is allowing requests for the researcher group. At Special:ListGroupRights, it has the three rights commonly referred to as viewdeleted, as well as apihighlimits. This was discussed a bit at Wikipedia_talk:Requests_for_adminship/Archive_269#Temperature_check:_Applying_for_the_Researcher_right. Essentially, this would add a third section to WP:RFA, perhaps called Requests for Researcher, and would follow the same general process as an RFA, compliant with the WMF's requirements for viewdeleted access. Unlike other unbundling proposals, this includes only viewing rights, and while it would probably be a fairly rare ask, it would avoid many of the issues that plague other unbundling proposals, since it does not necessary unbundle actions, just viewing permissions, meaning it doesn't touch the block/delete/protect triad of rights that will likely never be unbundled. EggRoll97(talk) 00:09, 6 November 2024 (UTC)[reply]
The WP:RESEARCHER right, since its inception, has required approval from the WMF (specifically from the Legal department, if memory serves). I suspect, but don't know for sure, that this approval requires signing contracts about protecting privacy, etc. It sounds like your plan is to make this userright available to more people, with fewer controls. Is that your goal? WhatamIdoing (talk) 03:36, 6 November 2024 (UTC)[reply]
@WhatamIdoing: Based on the general response from the WMF, we (the community) are allowed to use it as a normal usergroup, if we wish, based on Joe Sutherland's response of Generally you all can do as you want with the Researcher right, though of course Legal will require that anyone who receives it still pass some form of RfA-like process. It historically was only given to those who signed NDAs with the WMF, but as of now is unused and the WMF has indicated they are fine with us using it. I would say the controls would actually be greater, since it would require anyone seeking it request community approval. EggRoll97(talk) 06:05, 6 November 2024 (UTC)[reply]
I imagine the usecase would probably depend, and might need to be somewhat flexible (similar to how those who make a request for adminship generally have areas they're requesting the tools for), though it should serve to provide some benefit to others. I imagine good use cases might include those who work with LTAs, SPI, edit filters, or other areas where the ability to view deleted contributions would enable them to make a better contribution to the project and where a good case can be made that they are handicapped by its absence, using the wording that ArbCom in 2008 used about viewdeleted. Overall though, I'd think it would be very much still up to the community at large to determine "is this a good use-case, or is there no reason to actually grant this?". EggRoll97(talk) 06:56, 6 November 2024 (UTC)[reply]
Right now, the process is closer to provide your real name, sign a legally binding contract, and have a good reason, probably involving paperwork showing approval from your Institutional review board.
I'm not sure your use cases are realistic. People working with LTAs need a block button. SPI needs more CheckUsers. The edit filter managers have to be admins. WhatamIdoing (talk) 07:18, 6 November 2024 (UTC)[reply]
I agree with WhatamIdoing that those people with a genuine need to view deleted material are usually admin or admin+ already. There's some scope for research on what WP deletes, which I suppose is why it has been referred to as "researcher", but that's not really benefiting the community directly. Espresso Addict (talk) 07:59, 6 November 2024 (UTC)[reply]
I agree this would be very useful for non-admin EFMs. I asked xaosflux about this once upon a time - he raised some pitfalls at the time. My feeling is that the use case is too niche for most to feel it's worth the community time needed to develop a process around this, when probably less than 10 people will ever hold this right. ProcrastinatingReader (talk) 18:43, 6 November 2024 (UTC)[reply]
I wonder if, similar to how the import right was assigned without necessarily having a dedicated process behind it, it might be easier and less of a burden on community time to simply have individual requests at WP:VPP for the researcher right if it's that niche of a usecase. The usecase you describe was actually part of my motivation for making this. EggRoll97(talk) 21:42, 6 November 2024 (UTC)[reply]
As just a bit of an addendum to the previous comment, I checked the listing of all EFMs and checked through which ones are non-admins. We have a total of 15 non-admin accounts that have EFM. Of those, 8 were granted the right by a consensus discussion, 5 were self-granted as the user was formerly an administrator, 1 is a bot (so technically 14 human EFMs), and 1 was granted the right for bug checking(?) with a user talk page discussion. I imagine your estimate is quite right, in that case, since the 5 who self-granted as admins I believe can simply ask for their admin rights back at WP:BN if they need viewdeleted. The bot obviously doesn't need it, so that leaves 9, at least for that particular usecase. EggRoll97(talk) 21:55, 6 November 2024 (UTC)[reply]
Short note on this: I don't think we should not use that group for anything from the community and once no longer required it should be removed. We could make a process for a community-managed group that allows viewing non-suppressed deleted content, however the approval process will need to be "rfa like" to meet foundation requirements. It would need not be strenuous and should be able to get by so long as it: accepts both support and opposition feedback from the community, be able to measure that appropriate support exists, be well-advertised, and be well-attended. — xaosfluxTalk18:59, 6 November 2024 (UTC)[reply]
Example is our RFA system, which we could even use the existing system with an option that someone is only running for "view deleted admin". If it ran for at least a week, had at least 25 attendees, and had good consensus (i.e. ~2/3 support) think that would more than suffice. Could be assignable by 'crats. — xaosfluxTalk18:59, 6 November 2024 (UTC)[reply]
So if I follow you correctly, the ideal path would probably involve creating a separate group with the permissions duplicated, and some form of "request for view deleted" being added to WP:RFA? EggRoll97(talk) 21:42, 6 November 2024 (UTC)[reply]
Creating "Machine Wikipedia" as an edition of Wikipedia
Hi, according to Tim Berners Lee's proposal, that is "Web 3.0" or semantic web, we should make our existing web machine-readable. But current editions of Wikipedia (English, French, etc.) are not machine-readable. Even though "Wikidata" provides some "structured machine-readable data", it does not implement Web 3.0, because Wikidata only provides structured data for one concept and the article may contain many concepts that are not included in its Wikidata item.
So I propose to create "Machine Wikipedia" like other editions of Wikipedia (such as English) which is written in the "machine language", e.g. triples of RDF (Resource Description Framework). This way, Chat-bots and other machines can access required information more accurately and more conveniently. This new edition of Wikipedia (Machine Wikipedia) can be filled with RDFs, both by humans and by artificial intelligence using natural language processing (NLP). Thanks. Hooman Mallahzadeh (talk) 10:08, 7 November 2024 (UTC)[reply]
Sigh. Since I'm genuinely not sure whether you're aware, I'm going to head off with the obligatory remark that a sizable plurality of editors are either highly skeptical of or firmly oppose operation of the Chat-bots and artificial intelligence using natural language processing (NLP) you see as the primary benefactors of this proposal—either as they presently exist, or in principle. That is to say, I would not get invested in this proposal, as the benefits you envision are already seen instead as clearly negative outcomes by much of the community.
I'll give fair warning that I am not really volunteering to have you pitch me on why these things are actually good, but I just don't want you to get your hopes up. Remsense ‥ 论11:00, 7 November 2024 (UTC)[reply]
@Folly Mox I propose to change the project name from "Abstract Wikipedia" to "Machine Wikipedia" to match Tim Berners-Lee's vocabulary, and finally add it an interWiki like other editions of Wikipedia. We can call the goal article "Machine article".
I should note that extraction RDFs from an article by humans needs some expertise, i.e. this is an encoding process, but the product of this extraction process is very simple, it contains many lines of RDF triples, and we call that "Machine article".
@Gråbergs Gråa Sång, Convenient Discussions does that (after). Beneath each comment on a talk page are the options Reply Edit Thank. If you highlight some text in the comment, Reply changes to Quote, and it automatically includes the text in your reply formatted with Template:TQ. I like CD because it shows signatures before the comment, which has made it a lot easier for me to follow threads. Schazjmd(talk)14:52, 7 November 2024 (UTC)[reply]
For a by default feature that would benefit to all users, the Editing team has a thank button on the works. This deployment is currently blocked as this "Thank" button is dependent of other design changes. These changes have been deployed to 50% of users at English Wikipedia; we have to make it a default component. I'm a bit behind schedule regarding this deployment (listed as T379264) as other priorities came up. If you think these design changes and the thank button would be welcomed, I more than welcome support to prioritize this! Trizek_(WMF) (talk) 14:57, 7 November 2024 (UTC)[reply]
Having started some Wikipedia articles and added to others, I have the following questions and suggestions:
Why are there four different reference templates, when they all have roughly the same content?
Why does one template call it “Journal”, and another call it “Work”?
Why does there need to be a Page slot and a Pages slot? (printer drivers handle both together)
Should there not be one uniform format for all references when published? (see "Notes", David Graham Phillips: six different references, six different formats)
I suggest there be one reference template that has places for all necessary content, and that all references follow the same format when published:
Template
Title of source _________________ URL ___________________
Last name of source creator _________________ First name ________________________
News agency _____________________ Website name ___________________________
Name of journal, magazine, newspaper, etc. ___________________________ Volume _____ Issue _________ Page(s) ________
Name of publisher ________________________________ Location of publisher _________________________
Date source published __________________ Date source accessed____________________
Ref name ________________ Ref group __________________ Ref ID for anchor ___________________
There are quite a few more citation templates, it is just the four most commonly used that are available in the tool bar. All of the citation templates use the same set of fields, and you can build a citation from scratch using Template:Citation. The four citation formats available in the tool bar just start you with the fields most commonly used for each type of citation. You can leave fields empty, and you can add other fields as needed, as is needed when citing a chapter in a book, for instance. Donald Albury18:53, 7 November 2024 (UTC)[reply]
As a minor correction, not all of the CS1|2 templates support the same parameter set. For example, as of 2023, calling {{Cite book}} with the parameter |website= (or any of its aliases, like |work=, |journal=, |periodical=, |magazine=) will cause a template error, and add the article to Category:CS1 errors: periodical ignored (23,226).To address the substance of the OP, that there is any consistency among the most commonly used citation templates is the result of years of effort and discussion. The multiplicity of display formattings is a feature, not a drawback. There will never be just one single citation template, uniform in formatting across all sources and transclusions.Pbergerd, if you want the input fields in whatever editor you're using (not clear from tags in your contribs) to match the displayed format of those templates, that would best be addressed to whomever maintains your editing interface of choice (if anyone). The formatting will not be changed in the other direction (i.e. display matches input field ordering). Additionally, to my knowledge no citation template display leads with the title when the author is known, so I doubt you'll find consensus for your specific implementation proposal anywhere. All the best, Folly Mox (talk) 18:39, 9 November 2024 (UTC)[reply]
As a less gloomy follow up, our editing guideline WP:CITEVAR allows for articles to maintain the style used by the first major contributor or adopted by the consensus of editors already working on the page. So if you feel strongly about title-headed citations, you can implement your preferred formatting on articles you create, or unreferenced articles you provide the first citations for. But don't be surprised if bots come along and change it.With respect to your specific example David Graham Phillips § Notes: three two of the six citations – Fellow, Mencken, and Ravitz – are manually formatted (not the result of any citation template) and shouldn't be used as examples of a surfeit of citation formats. Two of the three four sources used in citation templates do not provide any authorial or editorial attribution (verified in sources), so naturally the format will differ from that of sources where the author is known.Tangentially, it is somewhat common for articles to use a mixture of Shortened footnotes and regular "defined in place" citations. Usually this is unintentional, as editors new to an article will almost never add citations in shortened format, except improperly, adding to Category:Harv and Sfn no-target errors (4,782). Converting all the new sources to shortened footnote form happens very irregularly. Sometimes articles will intentionally adopt a mixed style, where "main sources", multiply cited sources, or sources cited at more than one in-source location (a subset of the previous criterion) will be formatted in shortened form, and the remainder in the standard fashion. Folly Mox (talk) 19:22, 9 November 2024 (UTC)corrected per below 20:38, 10 November 2024 (UTC)[reply]
There are plenty of reasons not to use shortened footnote templates, and the lack of support for extra parameters is a feature (the footnotes, after all, are supposed to be short).I'm wondering why |access-date= in particular would ever be helpful to support: it's one of the cruftiest parameters, displaying rather a lot of text for information only really needed during archive snapshot hunting; it's not useful for print sources, which have a stable form per publication date, and are the most common types of sources where shortened footnotes are used; and why would you have different access dates for different sections of the source? Can't it just be added to the full citation template the shortened footnote links to?Quotes are another matter, but are easily included within the <ref>...</ref> tags following a harv family template like {{harvp}} or {{harvnb}}, which can be embedded within ref tags. Folly Mox (talk) 15:51, 10 November 2024 (UTC)[reply]
The attributes I mentioned were just random examples, but, e.g., |sectionlink= certainly seems important, and lots of printed sources are also available as PDF. Placing detail as free text in <ref>{{harvnb}}...</ref> does not create the proper metadata, so while it might work for |quote= it does not for other attributes. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 11:40, 11 November 2024 (UTC)[reply]
"The article cites more than one reliable source and is better developed in style, structure, and quality than Start-Class, but it fails one or more of the criteria for B-Class. It may have some gaps or missing elements, or need editing for clarity, balance, or flow."
The heuristic for C-class is "substantial but is still missing important content". The heuristic for Start-class is, similarly "developing but still quite incomplete": not very different. As an alternative, you can try to determine whether the article is "Useful to a casual reader, but would not provide a complete picture for even a moderately detailed study" or "Provides some meaningful content, but most readers will need more."
And here's the military history version of C-class:
"The article meets B1 or B2 as well as B3 and B4 and B5 of the B-Class criteria.
Here, rather than having to make a difficult heuristic judgement between C-class and start-class, clear criteria determine whether an article is start-class and other clear criteria determine whether it is C-class. It seems to me to be a reasonable formalization of the two heuristics (referencing and completeness) used to determine C versus Start class anyways. I think if Wikipedia adopted this generally, it would make rating articles much faster and simpler and less confusing given that the criteria for distinguishing C-class articles are formalized rather than subject to essentially how complete the article feels. When I rate articles, I usually spend a good bit of time worrying about whether it is C-class or Start-class -- a major part of the decision making currently is informed by observing other people's decisions. WP:MILHIST has basically solved that and added a FAQ.
Has anybody ever proposed using the MILHIST criteria before? I do remember seeing proposals (not successful) to merge C and Start class, but not this specifically. Mrfoogles (talk) 08:55, 11 November 2024 (UTC)[reply]
Making the assessment process any more formalized than it is is a non-starter when we have hundreds of thousands of articles that aren't assessed at all. PARAKANYAA (talk) 15:32, 12 November 2024 (UTC)[reply]
My experience is that any article ratings other than those which are part of a formal process (i.e. all those except GA, A, and FA) tend to be assigned based on vibes rather than any strict concern with the criteria, and mostly are not updated when the article changes. If assessments are largely made without reference to the criteria, I'm not sure that changing the criteria will have much effect. Even assuming for the sake of argument that people are carefully rating articles based on the assessment criteria, ratings are updated so infrequently that there's no guarantee that they are still appropriate at any given time. I don't object to clearer criteria for what is a start/C/B class article, but I also don't know that I really see the point: at this point in Wikipedia's development, what if anything do people actually use these ratings for? Generally I agree with the view which has been expressed by various people in the past (I know Iridescent used to make this point, as in this thread) that the distinctions between start/C/B class are pretty pointless and we'd be just as well off scrapping them entirely and ending up with a scale which goes stub/standard/good/featured or even unassessed/good/featured. (You mention proposals to merge start- and C-class, but I cannot find them in the archives of Wikipedia talk:Content assessment or WP:VP) Caeciliusinhorto-public (talk) 12:58, 13 November 2024 (UTC)[reply]
I'd pretty much agree with this, adding that in my experience most ratings are assigned almost entirely on article length, and also that nearly all our readers and most of our editors never look at them. Johnbod (talk) 13:37, 13 November 2024 (UTC)[reply]
They are pointless, generally speaking, other than that it's nice to say you've improved the quality of X article to Y, which can be a nice achievement. You might be right than eliminating the distinctions might be a good idea -- stub/start/C are very difficult to distinguish meaningfully, and checking that everything is cited correctly in B requires a mini-GA review level of work for long articles. Mrfoogles (talk) 02:58, 14 November 2024 (UTC)[reply]
Given the reception, probably not going to propose this. What the system really needs is a reform based on determining what purposes it actually serves. Mrfoogles (talk) 02:59, 14 November 2024 (UTC)[reply]
Enable interlanguage links to author links in cite templates
One of the edits I most often do is to use author link to wiklink names in citations, including in citations that use templates like Template:Cite book. This works great if the author already has an article in English Wikipedia.
Unfortunately, when the author only has an article about him in some other language, this cannot be taken advantage of. Interlanguage links do not work in cite templates. I think Wikipedia does not allow one set of braces or curly brackets {{}} to be inside another set {{}}; in other words does not permit nested layers of templates.
Proposal
I propose that Wikipedia, via some way (whether or not that means allowing nested layers of curly-bracketed templates), enable interlanguage links in citations that use cite templates.
Eberhard Straub (2011). Eine kleine Geschichte Preußens. Klett-Cotta. p. 17.
The wiki markup for the citation reads:
{{cite book|title=Eine kleine Geschichte Preußens|author=Eberhard Straub|year= 2011|pages=17|publisher=Klett-Cotta}}
To make the author's name in the citation be a wikilink to his article, one would insert a new field in the citation like this:
|author-link=Eberhard Straub
but that would create a red link in English Wikipedia, because Eberhard Straub does not currently have an article in English Wikipedia.
However, he does in German Wikipedia, making it preferable for such a link to be an interlanguage link, thus empowering readers who want to know more about the cited author to at least be able to look at the article about him in German, and also inviting readers to be editors and create a new English-language article about him. If and when that English-language article is posted, then the red link to his name and the smaller bracketed blue link to the German article disappear from view and the link appears to readers to be an ordinary blue link to the new English language article.
How?
I don't know how to accomplish this.
I don't know if it's technically feasible to change the Wiki software to allow for a nested layer of curly-bracketed template to be used within another curly-bracketed template, using the already-existing author-link field, like this:
{{cite book|title=Eine kleine Geschichte Preußens|author=Eberhard Straub|author-link={{interlanguage link|Eberhard Straub|de}}|year= 2011|pages=17|publisher=Klett-Cotta}}
Or if a new interlanguage author-link field in the citation template needs to be created instead, like
{{cite book|title=Eine kleine Geschichte Preußens|author=Eberhard Straub|ill-author-link-de=Eberhard Straub|year= 2011|pages=17|publisher=Klett-Cotta}}
just put :de:Eberhard StraubEberhard Straub[in German] (2011). Eine kleine Geschichte Preußens. Klett-Cotta. p. 17.The real reason it didn't work is because the template already generated a [[]], so the parameter tries to linkify a link and render "[[[[:de:Eberhard Straub]]]]], causing it to fail. You can nest templates easily.
Doe, John (1 April 2020). [I witnessed Tom Hanks admitting to actually being born one year earlier, faking his age to enlist in the scouts] (Dream). Lucid. Recurring Tom Hanks scouts dream number 8. Doe's bedroom, 412 Example Street, Suburbiaville, London: REM stage R.
Thanks for your feedback, but the main problem with your suggestion is that it doesn't work with author links, which can draw from separately provided surnames and given names, and then display the results as surname first, then comma, then given name, hyperlinking to the article about the author. I didn't mention this in my original comment for reasons of space and focus.
In other words, what I really want to be able to do is to do something like
{{cite book|title=Eine kleine Geschichte Preußens|author-first=Eberhard author-last=Straub |ill-author-link-de=Eberhard Straub|year= 2011|pages=17|ill-publisher-de=Klett-Cotta}}
Given that it's recent (May 2024) and it has suggestions directed at Wikimedia Foundation, I was just wondering if Wikimedia Foundation is aware of this article. And I am not asking with respect to editor conduct, but with respect to any potential initiatives (such as partnerships with potential volunteer experts to audit few articles). Bogazicili (talk) 19:12, 4 November 2024 (UTC)[reply]
Here is a quick overview of highlights from the Wikimedia Foundation over the first half of November 2024. Please help translate.
WikiCelebrate Mārtiņš Bruņenieks
Upcoming and current events and conversations Talking: 2024 continues
Commons Community Call: The first community call with Wikimedia Commons volunteers and stakeholders to help prioritize support efforts for 2025-2026 Fiscal Year will take place on November 21. The theme of this call will be about how content should be organised on Wikimedia Commons. The call will be hosted by Chief Product and Technology Officer Selena Deckelmann.
Wikifunctions: The Abstract Wikipedia team is working toward a rewrite of our backend services in a different programming language, likely Rust. More status updates.
Temporary accounts: Logged-out editors on 12 wikis, including Norwegian, Romanian, Serbian, Danish, and Cantonese Wikipedia, receive temporary accounts now. This new account type enhances the privacy of logged-out editors and makes it easier for community members to communicate with them. Read the new Diff post to learn more about temporary accounts.
Mobile apps: The Mobile Apps team has released an update to the iOS app’s navigation, now available in the latest App store version.
Admin Retention: A survey on Wikipedia Administrator Recruitment, Retention, and Attrition is open until November 11. As part of the Foundation's 2024-2025 Annual Plan, the research team and collaborators are studying recruitment, retention, and attrition patterns among long-tenured community members in official moderation and administration roles.
Knowledge is Human: The campaign web page, which educates visitors on Wikipedia’s model and why it’s trustworthy, has earned over 140,000 clicks. The campaign has increased pageviews on WikimediaFoundation.org by more than 50%.
Annual Goals Progress on Equity See also a list of all movement events: on Meta-Wiki
WikiCelebrate: From making a minor maintenance edit in 2005 to being one of the most appreciated Wikimedians in the Central Eastern European (CEE) region: this month we celebrate Mārtiņš Bruņenieks.
Future of Language Incubation: As part of a new Future of Language Incubation initiative to support language onboarding, Wikipedia is now live for five languages: Pannonian Rusyn, Tai Nüa, Iban, Obolo, and Southern Ndebele.
Global Advocacy: Reflecting on the anniversary of the EU’s Digital Service Act (DSA), Wikimedians share successes and public policy priorities at digital rights Global Gathering event, and more global advocacy updates.
Fundraising Report: Our annual fundraising report for the 2023-2024 fiscal year is published. Last year, we had over 8 million donors giving an average donation of m:Fundraising/2023-24 Report0.58. We ran campaigns in 33 countries, 18 languages, and received donations from over 200 countries.
We would prefer not to deploy on English Wikipedia at that time, though. A knee jerk reaction would be requesting otherwise and have enwiki be onboard as early as possible. – robertsky (talk) 08:48, 9 November 2024 (UTC)[reply]
It makes sense to fine-tune implementation on smaller wikis before rolling out to larger ones, but I am a lot more comfortable about this implementation than I was with earlier reports, which merely talked of hiding IP addresses, with all the worries over how we then handle IP vandalism, and did not provide any benefits to the (logged-in) community of editors. Espresso Addict (talk) 08:57, 9 November 2024 (UTC)[reply]
Indeed, I was very pleased that the ability to look at IPs had been extended to patrollers. Is there somewhere better that we can highlight this useful update, which allayed many of my concerns as an administrator about the upcoming change, as I fear the WMF page is not much read? Espresso Addict (talk) 09:33, 9 November 2024 (UTC)[reply]
How will this change the WP:OUTING policy? For example can I include the IP address or cidr range of a temporary account in the suspected sock list? Would that be considered outing? Because anyone(logged out editors too) can see a SPI report.Ratnahastin (talk) 09:38, 9 November 2024 (UTC)[reply]
Most likely not, as you're required to agree to certain terms when opting in to view IPs (as you already are on this wiki when enabling IP info). It would be a violation of not only local policy but ToS. Nardog (talk) 11:51, 9 November 2024 (UTC)[reply]
I think there should not be a need to include the IP address or the CIDR range in SPI report. Just the list of temporary accounts will do. Any CU, clerks, or patrolling admins will to have updated their checking processes to account for temporary accounts. – robertsky (talk) 12:02, 9 November 2024 (UTC)[reply]
Has anyone seen an indication of how many buttons you have to click to see IP info? In the past, people might post half-a dozen IPs at ANI and someone else would point out that that was a /64 that should be blocked with no collateral damage. At least one template ({{blockcalc}}) can extract IPs from wikitext and show the ranges involved. We will have to see how much hassle will be involved with the new system. Johnuniq (talk) 02:02, 10 November 2024 (UTC)[reply]
@Johnuniq: I have the global version of edit filter helper, so I have access on the wikis where it's just been rolled out (plus testwiki). If I recall correctly, it's just one button agreeing to the IP information policy to reveal IPs, but there are more boxes in Special:Preferences that allow for things like revealing IPs in the edit filter and using IP information on contribution pages. There's also a global preference available to CU/OS and certain global groups (global rollback/sysop, and global abuse filter helper/maintainer) to enable IP information cross-wiki. EggRoll97(talk) 23:32, 10 November 2024 (UTC)[reply]
Temporary accounts can be changed if one clears cookies or uses a different browser, not the same case with a cidr IP range. This will certainly make it a bit of a hassle to list out every temporary account associated with the IP range, anyway let's see how this feature is implemented first. Ratnahastin (talk) 02:06, 10 November 2024 (UTC)[reply]
Open letter about Asian News International vs. Wikimedia Foundation
Do you mean the users or a part of the body of wikipedia itself? As in, could Trump take over the website or otherwise exert significant pressure that would otherwise be alleviated by relocation? If not, then I guess no action necessary.
Are the servers located in the United States? It's looking like the answer is no, and I'm sorry for being paranoid, it's just that he has done things in this country that we didn't anticipate because we didn't expect anyone to have the sort of character that it would be a problem in that position. 75.142.254.3 (talk) 20:01, 10 November 2024 (UTC)[reply]
The primary Wikimedia data centers are located in the U.S., with caching centers distributed around the globe. I think you'd be hard pressed to find a country with better legal protections for online free speech, but as you note, it shouldn't be taken for granted. Legoktm (talk) 20:13, 10 November 2024 (UTC)[reply]
Yeah, the 1st amendment provides stronger protections than almost all countries have; even if Trump tried he'd be hard pressed to find a court that would agree with Wikipedia censorship (unlike in India...). Galobtter (talk) 04:34, 11 November 2024 (UTC)[reply]
The Wikimedia Foundation, which hosts Wikipedia, is based in the United States, and has to comply with US laws. Unless a relevant law is passed or legal action is taken, there isn't much Trump can do. ARandomName123 (talk)Ping me!20:17, 10 November 2024 (UTC)[reply]
If Trump goes authoritarian, which at this point I'm not going to rule out, US Law could be changed on a whim. But, I'm going to try to not be paranoid as much on this and WMF may already have evaluated appropriate courses of action given how they've managed to handle a wide variety of different kinds of disruption already. 75.142.254.3 (talk) 20:20, 10 November 2024 (UTC)[reply]
The bottom line is, we just don't know. I'm sure the WMF has contingencies in place for if US law ever becomes prejudicial to the project. Until he actually becomes president, we don't know what will happen. We just have to wait and see. TheLegendofGanon (talk) 20:22, 10 November 2024 (UTC)[reply]
As a basic precaution there should be a Wikipedia mirror with daily backups hosted on a server geolocated in a country with a higher democracy index and a higher internet freedom index than the US. I'd suggest Iceland, personally.—S MarshallT/C04:23, 13 November 2024 (UTC)[reply]
Honestly, it's unneeded. Look, I get worrying about this situation but I doubt the situation will get so bad where wikipedia needs to move overseas. As stsated above, wikimedia also likely already has a plan for if this happens. Gaismagorm(talk)11:40, 13 November 2024 (UTC)[reply]
Just a thought, but if the WMF does have or in the future creates contingency plans for moving operations in response to political developments, publicly revealing such plans in advance might make it harder to carry them out. It would be like a business announcing that they will build a factory in a given location without having at least an option to buy the land they will build on. Donald Albury16:11, 13 November 2024 (UTC)[reply]
Stop worrying to much, I doubt Trump is going to do anything against Wikipedia. Attacking and threatening to block Wikipedia will only infuriate the centrist voters, which I didn't think anyone would want to do. Some of the editors here are Trump supporters as well! What is concerning for Wikipedia today is the above case in India, where WMF HAD agreed to disclose the editor's information because of a defamation suit. ✠ SunDawn ✠(contact)06:01, 14 November 2024 (UTC)[reply]
Realistically, I doubt anything in particular will happen to Wikipedia. But if you want to prepare for the worst, as it were, and you have a machine with some extra disk space, consider periodically keeping an updated copy of the Wikipedia database dump. I get one periodically, just in case, since I've got plenty of spare space on this machine anyway. If worst ever came to worst, plenty of volunteers have the technical skill to get a DB dump up and working on a MediaWiki instance elsewhere, and run it at least while things are sorted out. I doubt it'll ever come to that, but if you want to be prepared just in case, well, the more widely copies of those are available, the better. Just remember that Wikipedia was completely run by volunteers once, from software development to sysadmins, and we could do it again if we had to. SeraphimbladeTalk to me06:12, 14 November 2024 (UTC)[reply]
((uh-oh ... IF the above "attempted" wikilink does not work, then ... maybe try thisinstead.))
By the way, perhaps that above-mentioned "Talk:" page section -- which is brand new, right now -- might be difficult to find, in the future ... if/when it has been archived.
(Perhaps even when using the link displayed as "this", where, besides those [ill-advised?] square brackets in the section name, having been "escaped" [in some way] by using "percent-5B" and "percent-5D", it also uses a full URL starting with "https" instead of a syntax involving "double"square brackets.)
@Schazjmd: It's not always that simple. "Just fixing the target" can be a real problem if someone reorganizes the target article and changes sections' titles. Been there, experienced that. CiaPan (talk) 18:37, 6 November 2024 (UTC)[reply]
Let me clarify what I meant: fix the target on the redirect page. If the redirect page is pointing to a section that has been renamed, change the wikilink on the redirect page to the new section name. Schazjmd(talk)18:44, 6 November 2024 (UTC)[reply]
Fictional flag used in multiple places
This problem is not unique to the English-language Wikipedia, but I'm starting here because this is my native language. I'm bringing this to an explicit discussion here rather than just editing so that we can build an explicit consensus that I can then show the other Wikipedias.
I think this is a more general case of Commons is not a reliable source. I often see people take images in commons completely at face value, including them in articles without any real source. Commons has very different rules than enwiki. They are mostly concerned with copyright and licensing, and (intentionally) make no attempt to verify that images are "real" or that the descriptions are factually correct. That's just not their job. But it is our job when we use one of their images in an enwiki article. RoySmith(talk)16:21, 7 November 2024 (UTC)[reply]
I belong to an organization which has a flag. The design is described in exquisite detail in our charter ("white stripe, whose width is one-sixth of the hoist", that kind of thing). I sat down one day and carefully drew an example in a drawing app, taking pains to get the geometry exactly as described. The charter (long) predates things like Pantone, but I did consult with a commercial artist to get their input on the correct RGB values to use for the colors and attempted to get all the people who produce material for us to use these "official" versions. Eventually I gave up and accepted that people will just copy-paste from whatever is handy. Now I just amuse myself by tracing the lineage of various bits of marketing material by which version of the flag they've got. But, yeah, we should do better than that. RoySmith(talk)17:25, 7 November 2024 (UTC)[reply]
@WhatamIdoing: please feel more than free to pursue that.
I am glad to see there appears to be consensus to remove this from all articles. I will do so, or at least attempt to (some may be tricky because of templates). - Jmabel | Talk17:03, 10 November 2024 (UTC)[reply]
I suspect there will be few objections to bold removal of any fictional flags. Commons has a real issue with their flag galleries, unfortunately. CMD (talk) 11:06, 11 November 2024 (UTC)[reply]
What does the arbitration committee in Wikipedia do
1) Deals with user behavior problems that our normal consensus process at WP:ANI can't handle. 2) Deals with administrator behavior problems. 3) Deals with anything related to private, off-wiki information. 4) Deals with certain unblock requests. –Novem Linguae (talk) 02:56, 10 November 2024 (UTC)[reply]
I have trawled through some dark places on Wikipedia and collated Wikipedia:Open letters, I have added summaries and outcomes to the older open letters, do correct me directly there if the summaries aren't right. if there's any other open letters from the community or the enwiki community had participated to be added, go ahead (except for the burger king related ones as those explicitly said they were not from the community). – robertsky (talk) 04:08, 10 November 2024 (UTC)[reply]
Redirects are cheap, but how many is too many?
I'm just wondering how others feel about this, without immediately starting an RfC or deletion discussion. @Hughbe98: as the one who created this example (but discussion is not about editor, but about edits).
Is this excessive, and if so how to reduce this? Removing the uppercase / lowercase variations would halve this already... Do we have guidance on a best approach for redirect creators? In total we now have already 448 redirects to this one article[11]. Fram (talk) 17:48, 12 November 2024 (UTC)[reply]
Ugh. This is what search engines are for. In the deep dark old days, we used to create these kinds of redirects because search wasn't very good. It's much better now (where "now" means the better part of 20 years) so we should just let it do its job. RoySmith(talk)17:59, 12 November 2024 (UTC)[reply]
I see no problem here to be addressed. None of these individual redirects is so wrong as to merit deletion, so I don't see how the quantity much matters. BD2412T19:07, 12 November 2024 (UTC)[reply]
Oh, storage space wasn't my concern. More things like issues with "what links here" being harder to navigate, more redirects to watchlist for vandalism, more work when the target gets changed (e.g. in the list above, the target is a potential article apparently, so when it gets created all the redirects need updating), more potential "wrong" results in searches (to take the most recent creation, is 13 W. 3 significantly different from 13W3, which has a different target), ...? But if people see no issue, then my question is answered and no action is needed. Fram (talk) 20:00, 12 November 2024 (UTC)[reply]
Redirects are cheap and usually uncontentious. Just occasionally an unambiguous redirect can become ambiguous as a new meaning arises for it. I suspect that only fixing redirects when they have become ambiguous would save a lot of unnecessary distraction and pointless make work. I used to spend quite a lot of time resolving multiple redlinks, and yes some of the redirects set up to do this would now be resolved by search. But improved search doesn't on its own resolve redlinks. ϢereSpielChequers09:04, 13 November 2024 (UTC)[reply]
In 
White
Silver
Blue
Pink
Gold
Red
Green
Skyblue
Purple
Turquoise
Black
Agree, but only slightly. If you added the letters, it would be better. Also, a solution to your region-basing could be to do a Language-based (like "O" for "Office" would become "S" for "Schoolhouse" in a theoretical "Reversed English") The Master of Hedgehogs (converse) (hedgehogs) 14:33, 17 October 2024 (UTC)
.jpg)
.jpg)
Discussion ongoing: limiting petition participation to signatures
wikimedia.org know if you have any feedback or suggestions for improvement!
CiaPan (talk) 18:37, 6 November 2024 (UTC)
