Wikipedia:Village pump (idea lab)

 Policy Technical Proposals Idea lab WMF Miscellaneous 

• Table of contents
• First discussion
• End of page
• New post

The idea lab section of the village pump is a place where new ideas or suggestions on general Wikipedia issues can be incubated, for later submission for consensus discussion at Village pump (proposals). Try to be creative and positive when commenting on ideas.
Before creating a new section, note:

• Discussions of technical issues belong at Village pump (technical).
• Discussions of policy belong at Village pump (policy).
• If you're ready to make a concrete proposal and determine whether it has consensus, go to the Village pump (proposals). Proposals worked out here can be brought there.

Before commenting, note:

• This page is not for consensus polling. Stalwart "Oppose" and "Support" comments generally have no place here. Instead, discuss ideas and suggest variations on them.
• Wondering whether someone already had this idea? Search the archives below, and look through Wikipedia:Perennial proposals.

Discussions are automatically archived after remaining inactive for two weeks.

« Archives, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61

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. Awesome Aasim 16:54, 27 September 2024 (UTC)

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)

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. Awesome Aasim 22:00, 27 September 2024 (UTC)

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é Couriano v^_^v ^{threads critiques} 15:37, 28 September 2024 (UTC)

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. Awesome Aasim 16:22, 28 September 2024 (UTC)

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)

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. Awesome Aasim 18:26, 29 September 2024 (UTC)

@Aaron Liu 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. 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. Mach61 19:53, 29 September 2024 (UTC)

Untrue, articles in ECR topics can and are pre-emptively locked.

Could you add an example? There is a long list of declined RFPP requests for arbitration enforcement. Aaron Liu (talk) 20:42, 29 September 2024 (UTC)

See this exchange between an admin who refused to protect based on ECR due to a lack of disruption and a (former) admin who explained to them otherwise. Mach61 19:46, 1 October 2024 (UTC)

Thanks, I get the "can" now. Aaron Liu (talk) 20:59, 1 October 2024 (UTC)

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)

Because there are enough people who dislike or distrust pending changes that it's hard to get a consensus to use it. See, for example, Wikipedia:Village pump (proposals)/Archive 183#RFC: Pending-changes protection of Today's featured article. Anomie⚔ 14:41, 28 September 2024 (UTC)

Well, gee, I fucking wonder why? —Jéské Couriano v^_^v ^{threads critiques} 15:39, 28 September 2024 (UTC)

Would you care to elaborate on your point? I'm not seeing it. Anomie⚔ 17:04, 28 September 2024 (UTC)

@Anomie: Read the "Proposal" section on the linked page. The fact that RfC even exists should give you a clue as to why CRASHlock is so mistrusted by a significant minority of editors. —Jéské Couriano v^_^v ^{threads critiques} 18:01, 9 October 2024 (UTC)

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)

You familiar with the idiom of the Camel's nose? —Jéské Couriano v^_^v ^{threads critiques} 18:47, 9 October 2024 (UTC)

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)

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. Awesome Aasim 19:00, 9 October 2024 (UTC)

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. Awesome Aasim 18:16, 9 October 2024 (UTC)

@Awesome Aasim: The RfC was linked specifically to point out one of the reasons for the mistrust in the PC system. The most recent RfC on CRASHlock, as I said, predates XCP as a concept. —Jéské Couriano v^_^v ^{threads critiques} 18:20, 9 October 2024 (UTC)

Also, please explain what you mean by "crashlock". I cannot find any discussion or glossary entry on "crashlock". Awesome Aasim 18:21, 9 October 2024 (UTC)

@Awesome Aasim: It should be VERY obvious from context. —Jéské Couriano v^_^v ^{threads critiques} 18:26, 9 October 2024 (UTC)

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. Awesome Aasim 18:40, 9 October 2024 (UTC)

(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)

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)

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)

It's one reason, and probably the biggest for some (who viewed the trial's mishandling as trying to force CRASHlock/FlaggedRevisions down our throats). Another reason is that, from 2010 to 2014, CRASHlock RfCs were called at least once a year, with most of them being written by pro-CRASHlock editors. —Jéské Couriano v^_^v ^{threads critiques} 18:42, 9 October 2024 (UTC)

Ok for those not into WP politics, there's an overview opinion piece from the August 2011 WSP that seems to capture the attitude and aftermath. It appears the closure results of the RfCs left admins in an indeterminate state as to whether PC can ever be applied or removed. SamuelRiv (talk) 18:47, 9 October 2024 (UTC)

as to whether PC can ever be applied or removed True in 2011 when that was written, but later RFCs resolved that. Anomie⚔ 19:02, 9 October 2024 (UTC)

Could you link to said RfCs? All else that's linked previously regards the main page. SamuelRiv (talk) 19:56, 9 October 2024 (UTC)

Wikipedia:Pending changes/Request for Comment 2012 established basic consensus to use PC, with Wikipedia:PC2012/RfC 2 and Wikipedia:PC2012/RfC 3 clearing up some details. PC level 2, on the other hand, never got consensus for use and eventually in 2017 there was consensus to remove it from the configuration. Template:Pending changes discussions has a lot of links. Anomie⚔ 22:14, 9 October 2024 (UTC)

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 the 2016 RfCs, none of which were particularly comprehensive. (The last comprehensive RfC was the 2014 clusterfuck.) —Jéské Couriano v^_^v ^{threads critiques} 06:47, 10 October 2024 (UTC)

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)

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.

Apologies for the hastily typed response, I'm a little pressed for time; hopefully there was something useful in there. 184.152.68.190 (talk) 16:06, 22 October 2024 (UTC)

Maybe what is needed is this...

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. Awesome Aasim 19:52, 1 October 2024 (UTC)

I view the ECR in the PIA area to be absolute (no editing full stop by those who do not meet 500/30), so CRASHlock would be off the table there in any event. I'm not sure if this also applies to WP:GS/RUSUKR (which falls into the EE area). —Jéské Couriano v^_^v ^{threads critiques} 18:57, 9 October 2024 (UTC)

Can we build the proposal here?

Here is some starter text maybe to get the ball rolling:

• What is the best way to enforce WP:ARBECR on articles?
  • Option 1: Preemptive XCON protection
  • Option 2: Preemptive XCON pending changes
  • Option 3: Edit filters
  • anything else?

This probably is incomplete, anyone else have ideas for this proposal? Awesome Aasim 19:41, 16 October 2024 (UTC)

I'd say remove "preemptive", as it is sometimes placed only in response to disruptive activity from non-ECs. Aaron Liu (talk) 11:31, 17 October 2024 (UTC)

So should reactive also be an option? Awesome Aasim 17:32, 17 October 2024 (UTC)

I think so. That's what I support. Cremastra — talk — c 19:29, 17 October 2024 (UTC)

So we should have it like this?:

• What is the best way to enforce WP:ARBECR on articles? Please rate whether these options should be preemptive, reactive, or not used.
  • Option 1: XCON protection
  • Option 2: XCON pending changes
  • Option 3: Edit filters/Revert filters
  • anything else?

Awesome Aasim 19:39, 17 October 2024 (UTC)

sure. Cremastra — talk — c 19:42, 17 October 2024 (UTC)

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é Couriano v^_^v ^{threads critiques} 16:26, 26 October 2024 (UTC)

@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)

My point still stands - a new RfC, developer buy-in, and ArbCom not interdicting the RfC would be required for this to become a reality. —Jéské Couriano v^_^v ^{threads critiques} 17:34, 27 October 2024 (UTC)

No, we're discussing "pending changes protection". Crashlock is a type of cardboard box. --Ahecht (TALK
PAGE) 21:18, 28 October 2024 (UTC)

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)

Read what I wrote above in re an RfC. EC!CRASHlock does not exist, and would need a consensus to use it and the devs being willing to work on it for it to be a thing. Spitballing anything about this is a waste of time until that happens, especially as the current consensus is that (1) anything beyond standard CRASHlock is deprecated and (2) ECP renders EC!CRASHlock pointless. —Jéské Couriano v^_^v ^{threads critiques} 17:17, 28 October 2024 (UTC)

Please, stop calling it "CRASHLOCK" it's confusing and pointless. At least explain why pending changes = crashing. Cremastra (u — c) 19:59, 28 October 2024 (UTC)

@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)

@Bunnypranav: Which is why I'm saying "start a new RfC." Something everyone seems to be glossing over despite me saying something to this effect four separate times in this thread. —Jéské Couriano v^_^v ^{threads critiques} 06:44, 3 November 2024 (UTC)

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. Awesome Aasim 16:41, 30 October 2024 (UTC)

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)

That would be hard-required, as I've repeatedly been saying. Without an existing consensus for the former, any discussion on using it for 500/30 rule areas is academic. —Jéské Couriano v^_^v ^{threads critiques} 06:51, 3 November 2024 (UTC)

RFC started

See WP:VPPR#RfC: Extended confirmed pending changes (PCECP). Awesome Aasim 19:58, 5 November 2024 (UTC)

Describing Notability in plain English

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.

Background

From Wikipedia:Glossary:

NN, non-notable

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.

Notability, Notable

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.

From a recent discussion:

• 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!

Your ideas (“notability”)

Please share your ideas here. Even a 'bad' idea might inspire the next person to think of another option. WhatamIdoing (talk) 21:04, 22 October 2024 (UTC)

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)

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)

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)

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)

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)

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)

I like “When to create an article”. SmokeyJoe (talk) 21:22, 22 October 2024 (UTC)

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)

So "When to have an article"? WhatamIdoing (talk) 00:18, 23 October 2024 (UTC)

“When to have a separate article”?

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.

- SmokeyJoe (talk) 02:12, 23 October 2024 (UTC)

• 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)
• I like "stand-alone article criteria" as it is focused on when to create an article. --Enos733 (talk) 21:28, 22 October 2024 (UTC)
• 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)

  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)

  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)

  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 Albury 17:32, 23 October 2024 (UTC)

  @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)

  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 Albury 18:30, 23 October 2024 (UTC)

  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)

  Suitable / Suitability is the first suggest I like, it helps show that this is a Wikipedia stand not a general idea. -- LCU ActivelyDisinterested «@» °∆t° 20:23, 23 October 2024 (UTC)

  Thanks a lot! I do very much like suitable topics (suitability?) too, as it is broad and flexible enough to cover our various policies on the topic. Chaotic Enby (talk · contribs) 19:26, 23 October 2024 (UTC)

  @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)

  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)

• 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)

  There might be some advantages to splitting the GNG out onto its own page, but I think that might need to be a separate discussion. WhatamIdoing (talk) 18:36, 23 October 2024 (UTC)

  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)

  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)

  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)

  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)

  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)

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)

So WP:What topics are allowed to have a separate article? WhatamIdoing (talk) 02:10, 24 October 2024 (UTC)

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)

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)

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)

My concern about WP:Guideline for article creation is that I would expect the advice on a page with that name to overlap considerably with Help:Your first article. There's more to article creation than identifying whether this is a suitable/acceptable/appropriate/notable topic for an article. WhatamIdoing (talk) 17:17, 24 October 2024 (UTC)

• 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)

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)

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)

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)

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)

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)

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)

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.

Or "The person's academic work has made a significant impact in the area of higher education, affecting a substantial number of academic institutions." I tried adding a requirement for Wikipedia:Independent sources to that, and it got reverted 75 minutes later. WhatamIdoing (talk) 19:21, 25 October 2024 (UTC)

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)

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)

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)

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)

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)

• 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)

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)

I was about to suggest this, one advantage is "sourcable" and "sourcability" having the same grammatical categories as "notable" and "notability", easing rewrites.--LaukkuTheGreit (Talk•Contribs) 10:39, 1 November 2024 (UTC)

How do you apply that to WP:NPROF, which doesn't really care about sources? WhatamIdoing (talk) 15:42, 1 November 2024 (UTC)

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)

Until that magical future appears, I think we need a name that encompasses SNG criteria that are not directly dependent on sourcing. WhatamIdoing (talk) 16:57, 1 November 2024 (UTC)

"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)

• 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)

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?

Wikieditor662 (talk) 20:34, 23 October 2024 (UTC)

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)

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)

Hey @Folly Mox@Chaotic Enby I posted to Wikipedia talk:WikiProject Vital Articles and a week later there's still no response... Is there anything else I could do?

Thanks,

Wikieditor662 (talk) 20:25, 1 November 2024 (UTC)

@Wikieditor662: you may have set yourself up for a poor reception with the question should people be inclu­ded based off on how significant, famous, or both they are/were?. Both of these attributes are not quantifiable: the only inclusion criteria VA would recog­nise as feasible would probably be "limit to Level 3" (112 figures), or "include Level 3 and Level 4" (1995 addi­tional 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)

That sounds like a giant pile of WP:OR – Joe (talk) 12:26, 24 October 2024 (UTC)

Determining who should be an electionadmin

Following Wikipedia:Village pump (proposals) § Enabling SecurePoll elections with the electionadmin right (permalink), I am starting a discussion on who should actually get the electionadmin permission. (The permission is necessary for scrutineering the results.) I see a couple of potential options:

1. Bundling the permission with CheckUser
2. Creating a separate user group which simply contains the electionadmin permission, which is assignable...
   1. ...by the Arbitration Committee, or
   2. ...by community consensus at (either a new WP:Requests for election administrator or some existing page, such as WP:AN)

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)

Pinging participants at the VPR discussion: @ActivelyDisinterested, Bluerasberry, Bunnypranav, Chaotic Enby, EggRoll97, Isaacl, JSutherland (WMF), Just Step Sideways, Levivich, Novem Linguae, Pinguinn, Pppery, SD0001, Sdkb, Sohom Datta, Thryduulf, and Xaosflux. Thanks, HouseBlaster (talk • he/they) 02:47, 28 October 2024 (UTC)

Option 1. At least until T377531 is done, in which case I would give securepoll-edit-poll to admin (or maybe crat) while leaving securepoll-view-voter-pii only for checkusers. * Pppery * _{it has begun...} 02:51, 28 October 2024 (UTC)

Option 1. If scruntinising for socks, then going with CUs group – robertsky (talk) 02:55, 28 October 2024 (UTC)

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)

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)

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)

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)

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).

– SD0001 (talk) 07:25, 28 October 2024 (UTC)

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. — xaosflux ^Talk 09:48, 28 October 2024 (UTC)

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.

Also, guys, this is the idea lab, not VPR. Don’t pile on! Aaron Liu (talk) 11:28, 28 October 2024 (UTC)

• 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)

  We don't "need" it, but I see only benefits in having all admins able to do it. Aaron Liu (talk) 12:55, 28 October 2024 (UTC)

  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)

  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)

  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)

  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)

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)

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)

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. — xaosflux ^Talk 13:21, 28 October 2024 (UTC)

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)

Note: It is certainly possible we could have multiple, overlapping secure polls at the same time on different topics with different admins, etc. — xaosflux ^Talk 18:52, 28 October 2024 (UTC)

Sure. Everyone who has the securepoll-view-voter-pii right should be trusted for all polls currently in progress. isaacl (talk) 18:59, 28 October 2024 (UTC)

• Community consensus, as we do for scrutineers. I really don't like the idea that arbcom would be involved in any way in the admin election process, and they don't need more workload anyway. Just Step Sideways ^{from this world ..... today} 17:24, 28 October 2024 (UTC)

  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. — xaosflux ^Talk 18:50, 28 October 2024 (UTC)

• 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)

  @Novem Linguae: Where is the consensus for giving all admins the ability to create a poll? It seems contrary to Levivich's close of Wikipedia:Village_pump_(proposals)#Enabling_SecurePoll_elections_with_the_electionadmin_right: An RFC to determine how the new right should be distributed can be launched at any time; it may be advisable to advertise that RFC on WP:CENT. – Joe (talk) 22:05, 28 October 2024 (UTC)

  It's the suggested setting in the extension documentation at mw:Extension:SecurePoll, and exposes no PII. However if folks object we can change the ticket. –Novem Linguae (talk) 22:29, 28 October 2024 (UTC)

  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)

  Roger. Will move it to electionadmin for now. –Novem Linguae (talk) 08:45, 29 October 2024 (UTC)

• 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)

  The stewards have already indicated that they are not willing to continue handling enwiki admin elections. Thryduulf (talk) 22:20, 29 October 2024 (UTC)

  Looks opposite to me? See: [1] and [2] - seems like their initial comment was misinterpreted? ProcrastinatingReader (talk) 22:21, 29 October 2024 (UTC)

  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)

  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)

  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)

  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. — xaosflux ^Talk 23:53, 29 October 2024 (UTC)

  Oops, I pinged the wrong person, sorry. I meant @SD0001 lol Aaron Liu (talk) 01:30, 30 October 2024 (UTC)

  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)

  Since scrutinners need to be whitelisted, I don't really see a problem. Aaron Liu (talk) 23:23, 30 October 2024 (UTC)

  Maybe $wgSecurePollUseLogging = true; and then visiting Special:SecurePollLog will turn it on. –Novem Linguae (talk) 23:35, 30 October 2024 (UTC)

  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)

  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)

  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)

  How are election admins on votewiki currently decided? It looks like Cyberpower and Xaosflux have had electionadmin for various periods.[3][4] 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)

  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. — xaosflux ^Talk 23:55, 29 October 2024 (UTC)

  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. — xaosflux ^Talk 23:56, 29 October 2024 (UTC)

  Can something similar to this be continued, then? Coordinators are added to electionadmin, and either local crats or admins flip the bits each ACE? ProcrastinatingReader (talk) 07:10, 30 October 2024 (UTC)

• 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)

  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.

  What else would scrutineers need to do besides inspecting election PII and checkusering to ensure democracy? Aaron Liu (talk) 22:20, 1 November 2024 (UTC)

@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)

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)

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)

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)

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". — xaosflux ^Talk 14:26, 30 October 2024 (UTC)

That is actually is pretty good option. As there is a suffrage requirement, the chances of abuse are a lot lower. ~/Bunnypranav:<ping> 15:25, 30 October 2024 (UTC)

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)

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)

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.

I was thinking this might be overkill, but now I'm starting to think I was wrong. -- LCU ActivelyDisinterested «@» °∆t° 17:14, 30 October 2024 (UTC)

At least the CUs can detect same IPs/same ballot + proxy. Aaron Liu (talk) 20:13, 30 October 2024 (UTC)

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)

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)

I think scrutineers can see the IP address associated with a ballot only if the poll is set to collect PII? Thryduulf (talk) 20:39, 30 October 2024 (UTC)

Looking back on the discussion, I read Disint's comment wrong. Aaron Liu (talk) 21:01, 30 October 2024 (UTC)

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)

I'm not sure if creating a poll works on enwiki yet. Aaron Liu (talk) 23:24, 30 October 2024 (UTC)

This was in my localhost testing environment. –Novem Linguae (talk) 23:36, 30 October 2024 (UTC)

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". — xaosflux ^Talk 22:02, 30 October 2024 (UTC)

• 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)

  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)

  ?? 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)

  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)

  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)

  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)

• 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)

  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)

  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)

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. — xaosflux ^Talk 14:26, 30 October 2024 (UTC)

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)

My understanding is they can't unless election admins give them the key (basically a very strong password) Aaron Liu (talk) 14:48, 30 October 2024 (UTC)

If encryption prevents them from accessing the datastore, can they access the unencrypted datastore without need of a key? -- LCU ActivelyDisinterested «@» °∆t° 14:55, 30 October 2024 (UTC)

No, that's the core concept of encryption. Aaron Liu (talk) 14:58, 30 October 2024 (UTC)

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. — xaosflux ^Talk 15:01, 30 October 2024 (UTC)

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)

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. — xaosflux ^Talk 15:19, 30 October 2024 (UTC)

Sorry this doesn't make it clearer. Yes or no, can a sysadmin see how people have voted by accessing the database if it's not encrypted? -- LCU ActivelyDisinterested «@» °∆t° 15:27, 30 October 2024 (UTC)

Yes. Aaron Liu (talk) 15:30, 30 October 2024 (UTC)

Thanks, and sorry for being slow. -- LCU ActivelyDisinterested «@» °∆t° 15:34, 30 October 2024 (UTC)

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)

Yes this is true of all safety measures, but not an argument against them. -- LCU ActivelyDisinterested «@» °∆t° 15:27, 30 October 2024 (UTC)

I don't think we need to safeguard anything from the WMF. Aaron Liu (talk) 14:58, 30 October 2024 (UTC)

(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)

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)

deployment and restricted also have those permissions as I understand it. * Pppery * _{it has begun...} 22:52, 30 October 2024 (UTC)

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)

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)

Hmm, do they know they're operating WMF services? Aaron Liu (talk) 23:25, 30 October 2024 (UTC)

Obviously I can't read the minds of all of them, but probably, given that one of the requirements is signing L3. * Pppery * _{it has begun...} 01:09, 31 October 2024 (UTC)

Yes. Taavi (talk!) 04:34, 31 October 2024 (UTC)

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.

Voters would expect that their votes are secure, or if not they need to be well informed that their votes are not. -- LCU ActivelyDisinterested «@» °∆t° 15:41, 30 October 2024 (UTC)

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)

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)

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)

"... in every election" Encryption can be configured differently for each election. – SD0001 (talk) 22:02, 30 October 2024 (UTC)

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)

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)

 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)

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. — xaosflux ^Talk 14:23, 28 October 2024 (UTC)

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)

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)

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)

I feel like if a petition is unnecessary, then no one would sign it. fanfanboy (block) 15:02, 28 October 2024 (UTC)

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)

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)

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)

Noting I've withdrawn the petition. Sincerely, Dilettante 15:41, 28 October 2024 (UTC)

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)

Two weeks as a baseline sounds like a more reasonable time, that could very much work. Chaotic Enby (talk · contribs) 16:15, 28 October 2024 (UTC)

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)

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)

• 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)

  That's exactly what I suggested a few months back Mach61 16:44, 28 October 2024 (UTC)

• 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)

  @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. Mach61 16:47, 28 October 2024 (UTC)

  I have no idea what that means. Any single editor can just change the process by WP:BOLD editing it? If that's the case, why are we having this discussion? Chetsford (talk) 16:52, 28 October 2024 (UTC)

  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)

• 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.

Any views on that? Ritchie333 ^{(talk) (cont)} 16:51, 28 October 2024 (UTC)

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)

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)

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)

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)

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 | talk 20:52, 28 October 2024 (UTC)

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)

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)

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 Albury 13:39, 29 October 2024 (UTC)

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)

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)

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)

That could work, in a way. Every editor can start a petition, but two editors have to sign within 48 hours or it gets closed without further ado. Chaotic Enby (talk · contribs) 18:50, 29 October 2024 (UTC)

• 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)

  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)

  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)

  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)

  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)

  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)

  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)

  I think that's a good course of action. Aaron Liu (talk) 22:25, 29 October 2024 (UTC)

  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. Chaotic Enby (talk · contribs) 22:48, 29 October 2024 (UTC)

  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)

  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.

  Nobody inspects every nook and cranny in history for bad things people have said to agree with it. Aaron Liu (talk) 01:29, 30 October 2024 (UTC)

  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)

  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)

• 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. Zero^talk 02:10, 30 October 2024 (UTC)

  Very good point, and why I would favor "allow nobody to comment" as a general rule. Chaotic Enby (talk · contribs) 02:22, 30 October 2024 (UTC)

• 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. Zero^talk 02:10, 30 October 2024 (UTC)

  On the other hand, editors victims of administrator misconduct should definitely be able to support the administrator being brought to recall. Chaotic Enby (talk · contribs) 02:26, 30 October 2024 (UTC)

  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)

  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)

  That makes sense. Zero^talk 02:42, 30 October 2024 (UTC)

  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)

  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)

  I agree. Anything more complicated would be too complicated. —Alalch E. 22:30, 30 October 2024 (UTC)

Workshopping the RfC

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)

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)

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)

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)

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.

The talk page will be open anyway, so people who want to elaborate on why can do it as they prefer Soni (talk) 05:14, 30 October 2024 (UTC)

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)

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)

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)

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)

"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)

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)

Will this: Any ... comment may be struck based on the same criteria used during requests for adminship (from WP:RECALL) hold true on the talk page? —Alalch E. 16:33, 30 October 2024 (UTC)

I think that is something that will need to actively decided. Thryduulf (talk) 16:45, 30 October 2024 (UTC)

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)

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)

By two-part, I mean asking two questions simultaneously, not running one RfC and then another. The second RfC had more then ten simultaneous questions, so two should be manageable. Chaotic Enby (talk · contribs) 17:28, 30 October 2024 (UTC)

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)

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)

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)

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 Albury 19:42, 30 October 2024 (UTC)

@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)

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)

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)

Notification: RfC: Shorten the recall petition period

Wikipedia:Administrator recall has an RfC for possible consensus. A discussion is taking place. If you would like to participate in the discussion, you are invited to add your comments on the discussion page. Thank you. CNC (talk) 21:59, 1 November 2024 (UTC)

Notification: RfC: Should we add text prescribing just signatures, no discussion?

Wikipedia:Administrator recall has an RfC for possible consensus. A discussion is taking place. If you would like to participate in the discussion, you are invited to add your comments on the discussion page. Thank you. Chaotic Enby (talk · contribs) 15:58, 3 November 2024 (UTC)

The first notification is for shortening the period and the second one is for limiting comments to just signatures. Aaron Liu (talk) 16:03, 3 November 2024 (UTC)

Have modified title of first notification to make more sense. CNC (talk) 16:38, 3 November 2024 (UTC)

Allow IP editors to set preferences

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)

I believe that would require changes to the software. Thryduulf (talk) 00:46, 2 November 2024 (UTC)

I mean, temporary accounts are already on. I doubt that the WMF isn't already planning this. Aaron Liu (talk) 00:49, 2 November 2024 (UTC)

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)

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)

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)

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)

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. Zero^talk 02:40, 6 November 2024 (UTC)

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)

LA2, this doesn't sound like it would be possible to implement entirely in client-side scripting, and would require dev involvement. Software changes like this can be suggested at the global Community Wishlist. Folly Mox (talk) 12:06, 7 November 2024 (UTC)

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.

Above is the output of the template, for those unfamiliar with it.

Thoughts? — rsjaffe 🗣️ 19:59, 5 November 2024 (UTC)

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)

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)

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)

It's just "move to draft". I have no idea why more CSD taggers don't use it. -- asilvering (talk) 20:41, 5 November 2024 (UTC)

I don't think we give clear enough guidance on what the taggers can/can't do. — rsjaffe 🗣️ 22:24, 5 November 2024 (UTC)

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.

Pi.1415926535 (talk) 22:11, 5 November 2024 (UTC)

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)

@Rsjaffe if anything, people are less sophisticated about this now, since many mobile browsers try very hard to obscure URLs. -- asilvering (talk) 22:37, 5 November 2024 (UTC)

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)

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)

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)

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. —Cryptic 22:29, 5 November 2024 (UTC)

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. —Cryptic 22:34, 5 November 2024 (UTC)

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)

It already does that? WhatamIdoing (talk) 01:17, 6 November 2024 (UTC)

Thanks, @WhatamIdoing, I thought I was the crazy one. -- asilvering (talk) 01:18, 6 November 2024 (UTC)

The theme Minerva does not appear to me to show the User: prefix, but does seem to for most namespaces <https://en.wikipedia.org/wiki/User:Example?useskin=minerva>. Skynxnex (talk) 02:23, 6 November 2024 (UTC)

And Folly Mox is on the mobile site. @SGrabarczuk (WMF), could you please talk to the Web team about this? User pages ought to say that they're User: pages, even if someone would like to hide that fact. WhatamIdoing (talk) 03:33, 6 November 2024 (UTC)

Whoops I didn't think to check in other skins. Apologies for the confusion. Folly Mox (talk) 14:05, 6 November 2024 (UTC)

This problem is especially bad on mobile since, as asilvering points out, mobile browsers hide URLs. McYeee (talk) 07:06, 7 November 2024 (UTC)

• 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)

  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)

  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)

  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)

  @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)

  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)

  asilvering, according to Wikipedia:Editnotice § User and user talk (confirmed at Template:Editnotices/Namespace/User), When editing a new user page, {{base userpage editnotice}} will show. The editnotice is already pretty clear. Folly Mox (talk) 00:42, 8 November 2024 (UTC)

  Welp. You can't fix that level of banner-blindness with anything. -- asilvering (talk) 00:46, 8 November 2024 (UTC)

  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)

• Wouldn't adding {{Userspace draft}} to the userpage fix the issue? Nobody (talk) 10:44, 6 November 2024 (UTC)

Researcher group

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)

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)

@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)

What sort of editors are you thinking might wish to get this right, EggRoll97? Espresso Addict (talk) 06:38, 6 November 2024 (UTC)

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)

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.

You would replace this with convincing RFA voters that you should have this but not have admin rights. Have you read Wikipedia:Perennial proposals#Hierarchical structures on partial adminship?

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)

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)

@WhatamIdoing Edit filter managers don't need to be administrators, see WP:EFM. Thryduulf (talk) 08:33, 6 November 2024 (UTC)

You're right. I should have looked it up instead of relying on memory. Thank you. WhatamIdoing (talk) 16:26, 6 November 2024 (UTC)

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)

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)

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)

• 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. — xaosflux ^Talk 18:59, 6 November 2024 (UTC)

  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. — xaosflux ^Talk 18:59, 6 November 2024 (UTC)

  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)

  Duplicated? No, for example apihighlimits isn't likely required at all here. — xaosflux ^Talk 10:17, 7 November 2024 (UTC)

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)

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)

Hooman Mallahzadeh, this project is already underway. See m:Abstract Wikipedia. Folly Mox (talk) 11:08, 7 November 2024 (UTC)

@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".

I really think that "Machine Wikipedia" project can be made very fast, and the delay that "Abstract Wikipedia" project had made is unreasonable. Hooman Mallahzadeh (talk) 11:35, 7 November 2024 (UTC)

Ok, it sounds like you know quite a bit about machine learning. But, kindly, this has no relation to English Wikipedia. m:Talk:Abstract Wikipedia has 236 watchlisters, and the project has a public mailing list, if you want to get in touch about your ideas with the team involved. Folly Mox (talk) 12:01, 7 November 2024 (UTC)

@Folly Mox I added a comment there. Thanks for your response. Hooman Mallahzadeh (talk) 12:35, 7 November 2024 (UTC)

"Thank" as a button in threaded discussions

Is there a script or gadget that adds "[Thank]" before "[Reply]"? After is fine too, but I think before might be better.

If not, is someone willing/able to make one? It would make thanking easier, I think. Gråbergs Gråa Sång (talk) 14:12, 7 November 2024 (UTC)

@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)

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)

You can also turn off the feature to change signature positions. Aaron Liu (talk) 15:17, 7 November 2024 (UTC)

Thanks for the replies! Gråbergs Gråa Sång (talk) 15:37, 7 November 2024 (UTC)

Reference templates

Wikipedia reference templates

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 ___________________

(put DOI and PMID in “extra fields”)

Print references in same order of information as in the template above. Pbergerd (talk) 14:19, 7 November 2024 (UTC)

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 Albury 18:53, 7 November 2024 (UTC)

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)

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)

One reason for using <ref>CS1 or CS2 template</ref> instead {{sfn}} is the cs1|2 fields that sfn does not have, e.g., |quote=, |access-date=, |section-link=. This will be even more true if and when <ref extends=base>...</ref>, Wikipedia:Village pump (technical)#Coming soon: A new sub-referencing feature – try it! permalink/1241515798, becomes available. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 15:23, 10 November 2024 (UTC)

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)

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)

Thanks for all of your information. (I actually did use the book template for the Ravitz citation.) Pbergerd (talk) 15:58, 10 November 2024 (UTC)

Whoops, sorry; not sure how I misread / misre­membered that. Corrected my earlier reply. Folly Mox (talk) 20:38, 10 November 2024 (UTC)

Has anyone proposed using the military history's criteria for C-class universally before?

The Wikipedia:WikiProject Military history/Assessment has much clearer criteria for C-class than what we currently have. Here's Wikipedia:Content assessment:

"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.

Detailed criteria

• B1. It is suitably referenced, and all major points have appropriate inline citations.
• B2. It reasonably covers the topic, and does not contain obvious omissions or inaccuracies.
• B3. It has a defined structure, including a lead section and one or more sections of content.
• B4. It is free from major grammatical errors.
• B5. It contains appropriate supporting materials, such as an infobox, images, or diagrams.

See also the B-Class assessment & criteria FAQ."

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)

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)

Well, the idea of this would be to make it easier to assess them. Mrfoogles (talk) 23:09, 12 November 2024 (UTC)

C-class came from Wikipedia:Content assessment, not MILHIST. (See Wikipedia talk:Content assessment/Archive 4#Proposal - adding C-class between GA-Class and Start-Class, Wikipedia talk:Content assessment/Archive 4#Results of the poll and Wikipedia talk:Content assessment/Archive 4#New C class live.) It was subsequently adopted by the Military History Project in 2009 in the manner described in order to minimise the amount of work required. (A single change to our project template.) (See Wikipedia talk:WikiProject Military history/Coordinators/March 2009). Hawkeye7 (discuss) 23:58, 12 November 2024 (UTC)

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)

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)

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)

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)

Enable interlanguage links to author links in cite templates

Apologies if this should be go to Village_pump_(proposals) or Village pump (technical). Please let me know if I should make this proposal there instead, or to some other place.

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.

Example

To make this concrete rather than abstract, look at Basic Law for the Federal Republic of Germany. Currently the second citation is:

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}}

What do you think?

Carney333 (talk) 17:12, 12 November 2024 (UTC)

just put :de:Eberhard Straub

Eberhard 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.

Aaron Liu (talk) 17:30, 12 November 2024 (UTC)

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}}

to produce something like:

Straub, Eberhard. (2011). Eine kleine Geschichte Preußens (in German), Klett-Cotta. p. 17.

Carney333 (talk) 01:25, 14 November 2024 (UTC)