Wikipedia:Village pump (all)

This is the Village pump (all) page which lists all topics for easy viewing. Go to the village pump to view a list of the Village Pump divisions, or click the edit link above the section you'd like to comment in. To view a list of all recent revisions to this page, click the history link above and follow the on-screen directions.

Click here to purge the server cache of this page (to see recent changes on Village pump subpages)


Village pump sections

Edit-find-replace.svg
Policy
post, watch, search
Discuss existing and proposed policies

Preferences-system.svg
Technical
post, watch, search
Discuss technical issues about Wikipedia

Dialog-information on.svg
Proposals
post, watch, search
Discuss new proposals that are not policy-related

Tools-hammer.svg
Idea lab
post, watch, search
Incubate new ideas before formally proposing them

Wikimedia-logo black.svg
WMF
post, watch, search
Discuss issues involving the Wikimedia Foundation

Help-browser.svg
Miscellaneous
post, watch, search
Post messages that do not fit into any other category

View all village pump sections at once

Hyperlink-internet-search.svg
Other help and discussion locations
I want... Where to go
...help using or editing Wikipedia Teahouse (for newer users) or Help desk (for experienced users)
...to find my way around Wikipedia Department directory
...specific facts (e.g. Who was the first pope?) Reference desk
...constructive criticism from others for a specific article Peer review
...help resolving a specific article edit dispute Requests for comment
...to comment on a specific article Article's talk page
...to view other Wikimedia projects Wikimedia Meta-Wiki
...to learn about citing Wikipedia in a bibliography Citing Wikipedia
...to report sites that copy Wikipedia content Mirrors and forks
...to ask questions or make comments Questions


Discussions older than 7 days (date of last made comment) are moved to a sub page of each section (called (section name)/Archive).

Policy

Undisclosed alternate accounts

Background

Since the early days of the English Wikipedia, there has been a tradition or custom of some users having either known or undisclosed alternate accounts. This has held over to some extent into the modern era of the project and is enshrined in policy at WP:VALIDALT. Publicly disclosed alternate accounts are fully free to edit in any way with few restrictions; however, WP:PROJSOCK states that undisclosed accounts may not edit the Wikipedia namespace. English Wikipedia is something of an outlier in this regard: many other WMF projects regard undisclosed alternate accounts as illegitimate sock puppets. Therefore, behavior that is technically acceptable at EN.WP can have serious consequences if practiced on many other WMF wikis. Existing policy makes it clear that private disclosure to ArbCom or individual functionaries does not allow for policy violations, but this is often misunderstood by users and can lead to frustration both on the side of users and of CheckUsers.

Issues

  • A blanket ban on undisclosed alternative accounts editing project space results in a situation where content created by an alt could be under discussion, for example via WP:AFD, or the user's behavior may be under discussion at forums such as WP:ANI and by the letter of current policy, the user cannot participate in those discussions at all.
  • Only the Arbitration Committee has access to the list of known undisclosed alternative accounts. This information is considered private and generally cannot be shared, even with checkusers. This means a user could have disclosed their alt account to the committee, only to be blocked for socking, and the connection between the accounts publicly revealed, in the course of a legitimate sockpuppet investigation.
  • There is not actually a hard obligation to disclose alternative accounts at all, to anyone. It is therefore likely that the accounts known to the arbitration committee or individual checkusers are mostly those who would not abuse them anyway, and represent only a small portion of the total number of such accounts.
  • There is no reasonable way to police all the edits of all known alternative accounts to ensure they are within policy.

Proposed remedies

  • Not anyone else's problem Change language of policy to actively discourage using privacy alts and to make it clear that if the connection is discovered it is not the responsibility of the community, the functionaries or the Arbitration Committee to conceal it. If the connection is made clear by the privacy alt's behavior, that is the fault of the account operator.
  • Clarify WP:PROJSOCK: Carve out narrow exemptions to the project space ban for deletion discussions related to content created or edited by the alt account, or discussions of the alt accounts' own behavior. Broader discussions on site policy, other users behavior, etc, are still strictly off limits.
  • No longer allowed at all: The use of privacy alts is to be considered deprecated and removed from policy. Any user operating more than one account without publicly linking them for any reason will be subject to the sockpuppetry policy. This would not apply to legitimate clean start accounts where one account was abandoned before the new account began editing. (this option is mutually exclusive with the other proposed options)

Discussion of proposed remedies

  • I've opened this discussion because some recent events have revealed a number of issues, identified above, with the policy on private alternative accounts. The first remedy in particular I feel pretty strongly about. Privacy alts are at-your-own-risk. If you screw it up and are detected, whoever you disclosed to can verify that you disclosed an alt to them, but that doesn't obligate that user to then cover up the entire affair. Generally, private alt accounts are just a bad idea, and we should probably be more stringent in discouraging them, and also making it clear that disclosing is not a free pass to otherwise violate the socking policy. On the second remedy, it's just not fair that we allow these accounts for privacy reasons, but by the letter of policy they cannot contribute to any project-space discussion, even if it is about their own behavior or content they created. The third remedy, I threw in there in case it happens that the community just wants to end this practice altogether, as many other projects have. I've not proposed specific wording, this is more about looking for consensus on the ideas, the wordsmiths can get in there and create the appropriate wording if such a consensus is reached. Beeblebrox (talk) 22:15, 15 April 2021 (UTC)
    Beeblebrox, Thanks for starting this discussion. I suspect it will attract enough attention that maybe you want to break it out into its own subpage? -- RoySmith (talk) 22:23, 15 April 2021 (UTC)
  • One thing I'd like to see added to option 2 is permitting undisclosed alts to ask questions at appropriate venues (Teahouse, Help Desk, that sort of thing), since the letter of the law says those are projectspace but those aren't exactly policymaking venues. People also ask legitimate questions at the village pumps, but I'm not sure whether to include those in this exception since those are more "internal project policy discussion" venues. GeneralNotability (talk) 22:17, 15 April 2021 (UTC)
  • Question: I understand the reasons for public alt accounts (such as having an alt for public computers or at work), but what are the reasons (in the past, at least) for allowing undisclosed/private alt accounts? Schazjmd (talk) 22:21, 15 April 2021 (UTC)
I would like to know this too. I don't have an issue with undisclosed alt accounts that would out someone who isn't paid but if you don't want to potentially connect yourself to your employer, a simple solution is to not edit about them. No one is forcing you to and conversely, no one is forcing you to edit Wikipedia at all. TAXIDICAE💰 22:27, 15 April 2021 (UTC)
See the comment directly below for one example. Often it's a matter of not wishing to "out"some specfic aspect of their life, either something mundane as mentioned below, or perhaps editing controversial topics on religion or sexual practices. Beeblebrox (talk) 22:32, 15 April 2021 (UTC)
@Schazjmd: that's a good question. The common old-school example for why someone would have a "secret" alt is to edit embarrassing subjects, e.g. certain sexuality topics. Another possibility is to edit a topic, which editing with the main account may compromise the user's privacy. Another possibility could be an existing Wikipedia editor having assigned coursework that involves editing Wikipedia, and would not want that associated with the main account, either from either side so to say (on-wiki in terms of an association with a given university, or having university colleagues know the existence of the main account). In some cases there are real-world implications in that Wikipedia editors may experience trouble with local authorities as a result of certain edits.
At the end of the day we are a project that permits pseudonymous editors. Short of running certain mass checkusers—something that is a non-starter as far as the privacy policy goes—we ought to accept that there is not much one can do about someone using two accounts to edit separate topics. Of course, there are obvious deceptive uses of multiple accounts; think of vote-stacking an AfD or cases where a banned user uses multiple accounts to evade the ban to continue the same disruption that led to the ban. That said, it ought to be considered whether the simple fact of using an alternate account is somehow a problem. Maxim(talk) 23:34, 15 April 2021 (UTC)
Praxidicae, I've edited with an undisclosed alt in the past. Not everyone is okay with being connected to articles about illness, politics, religion and sexuality. There's also a photo around here somewhere of the pierced penis of a Wikipedian which I helped anonymize. They made a request to vanish when they found potential clients who googled their name found a pierced penis as the top result. It actually took years, but I just checked it again and it seems Google has *finally* forgotten about it. — Alexis Jazz (talk or ping me) 15:04, 30 April 2021 (UTC)
Yes, I do recall you using an undisclosed alt in the past. AntiCompositeNumber (talk) 23:48, 30 April 2021 (UTC)
  • I hope the third suggestion isn't going to be taken seriously. I have a some photos I've been meaning to add to a few articles when I get around to it. These photos could be traced back to my real-world identity. Should I really have to choose between adding the photos, and outing myself? Because I see no other way to add the photos than create a "privacy alt". Suffusion of Yellow (talk) 22:24, 15 April 2021 (UTC)
    • I assumed someone would propose it during the course of the conversation, so I just put it out there. Beeblebrox (talk) 22:32, 15 April 2021 (UTC)
    Suffusion of Yellow, regardless of the above changes, using a separate account only to upload pictures shouldn't put you at any risk. Blocking someone for using multiple accounts requires behavioural evidence (with or without technical evidence), so the chance of someone connecting those two accounts is practically zero. (Yes, mistakes happen, and checkusers occasionally run checks they shouldn't, but that's also why oversight exists.) – bradv🍁 23:27, 15 April 2021 (UTC)
    It doesn't matter whether you would be caught for uploading the images. It matters that it's against the rules. I've been in similar cases to Suffusion of Yellow and agree that the third suggestion is ludicrous. If there is a common use case of people evading a rule with no harm done, no way of detection and in a way that nobody could possibly object to then it is a bad rule. Though in my case it would actually stop me uploading pictures altogether, because I would follow the rule even if it's pointless and unenforceable (too high consequences for too low a reward). (And though Commons isn't under our scope, this soft redirect and the fact I have used or would use an en.wiki account to add the uploaded images to articles means that this is our jurisdiction.) — Bilorv (talk) 12:17, 16 April 2021 (UTC)
  • I would really only support 2 as worded, and could support 1 if language about "actively discouraging" is removed. I've never used an alternate account, but I respect that others may find it necessary. I agree that no one is ever under any obligation to keep knowledge of someone else's secondary account secret, HOWEVER, I also can understand legitimate reasons to use a secondary account. We should still discourage good hand/bad hand accounts, or similar purposes, such as participating in policy discussions while concealing prior activity on Wikipedia, but I do agree that exceptions need to be allowed for when the alternate account has itself an interest in the discussion, such as AFDs for articles where the account is a contributor. However, Wikipedia should neither encourage nor discourage the use of private alts with the only caveat that actual violations of community trust are likely to have consequences. --Jayron32 22:35, 15 April 2021 (UTC)
  • (This thread moved from its own section originally entitled A difficult example): Let's assume I'm a member of International Flat Earth Research Society, and I've made many posts edits from my personal account (with a non-PII account name) espousing this viewpoint, including vigorous participation in AfDs and other WP-namespace pages. In my day job, I'm employed by NASA where my job responsibilities include computing trajectories for space missions. I haven't told my employer of my flat earth beliefs because that knowledge would impact my career advancement. Assume for the moment that despite my private views, I'm good at my job. One day, my boss comes to me and says, "We need a WP:Wikipedian in Residence to curate articles about NASA, and you're it. Your job responsibilities will include being active in discussions about what articles to keep or delete". The "No longer allowed at all" option would put me in a bind. There's no way I can perform my job without either breaking our socking policy or outing myself to my employer. If you don't like my NASA example, I'm sure you can think of similar situations. — Preceding unsigned comment added by RoySmith (talkcontribs) 22:41, 15 April 2021 (UTC)
    Aside from the absolute absurdity of this example, your career advancement isn't Wikipedia's problem, nor should it ever be. You can turn down a WIR or come clean - transparency is key here. You don't have to dox yourself by adding your full name or even first name. Disclosure doesn't require identifying yourself. WIR is another matter and not really relevant to this discussion. TAXIDICAE💰 22:47, 15 April 2021 (UTC)
    Praxidicae, Why is the example absurd? We have many examples of people who edit as a requirement of their employment. A department in a University wanting every faculty member to have a wikipedia page and assigning that job to some low-level person in the department office. We've seen that scenario multiple times. -- RoySmith (talk) 22:56, 15 April 2021 (UTC)
    And that person is welcome to decline that request from their employer if it would violate the sites terms of use for the same reason an employer demanding an employee break a law or policy should be declined. No one forces you to edit as a volunteer or a paid editor and our policy is already clear enough on that. TAXIDICAE💰 23:25, 15 April 2021 (UTC)
    RoySmith, in this case you could just stop editing from your previous account. Using serial accounts does not constitute sockpuppetry, unless you are subject to a block or ban. – bradv🍁 23:15, 15 April 2021 (UTC)
    But what if they are subject to block or other restriction. Continuing the NASA example, our theoretical editor (let's called them Tarquin) is presumably a generally good contributor and net positive to the encyclopaedia but perhaps they are topic banned from editing articles about the phantom time hypothesis or they have a mutual interaction ban with another user? If Tarquin just stayed away from those topics/editors we probably wouldn't be any the wiser, but it would be a breach of policy and obviously the other party to the interaction ban would not know to stay away from the new account. Thryduulf (talk) 01:28, 16 April 2021 (UTC)
    If someone is subject to a ban they shouldn't be creating a new account or accepting a paid editing position – especially not without being fully transparent with both their employer and the editing community. That's currently prohibited by both our sockpuppetry policy and our paid editing policy, and none of the proposed changes above would alter that. – bradv🍁 02:07, 16 April 2021 (UTC)
    @Thryduulf: I think you could have picked a better example for a username. :-) That user's very familiar to me for his early work in mathematics and classical music articles. I don't think I ever spoke to Tarquin personally but his name is very familiar to me in page histories and on old talk pages. I hope he'd be as amused by this as I am; I've mentioned it on his talk page. Graham87 08:46, 16 April 2021 (UTC)
    In a paid WiR role, you are already mandated to disclose your alternative accounts under current policy Wikipedia:Paid-contribution disclosure#How to disclose: "paid editors must provide links to the user page(s) of their Wikipedia account(s) on each website on which they advertise, solicit or obtain paid editing services, as well as in direct communications with each client and potential client (such as through email). If the paid editor has used or controlled more than one Wikipedia account, each account must be disclosed." This was added in a recent RfC. – Finnusertop (talkcontribs) 23:17, 15 April 2021 (UTC)
    Whether and to what extent that applies to Wikipedians in residence is not at all clear. It is also completely and utterly unenforceable because we can (and should) never know the contents of all private communication, as was pointed out repeatedly when it was proposed. I'm also dubious that stipulating the content of communication between employer and (potential) client is something that it is even legal for a third party to place restrictions on. Thryduulf (talk) 01:01, 16 April 2021 (UTC)
  • I explained my concerns with WP:PROJSOCK elsewhere. I can only see what I can read from the history, so perhaps someone who was actually there knows the context better and can point out any errors, but its current enforcement doesn't make sense to me. Most illegitimate uses are obvious why they're disallowed; you can't use multiple accounts to pretend to be multiple people in a way that bolsters your position, avoids scrutiny, or deceives editors. But PROJSOCK isn't intuitive in the same way. It's cited to an ArbCom case from 2007 where the evidence was an editor abusing multiple accounts to participate in policy discussions whilst avoiding scrutiny. The community appears to have narrowly worded it to this (and similar variants) for years after the case, clarifying that Alternate accounts should not edit policies, guidelines, or their talk pages; comment in Arbitration proceedings; or vote in requests for adminship, deletion debates, or elections. That all makes sense, and directly follows from the case evidence too. Then in 2014 someone boldly edited the page to the vaguer "quote[] from the underlying Arbcom decision" which says Undisclosed alternative accounts are not to be used in discussions internal to the project. As a reader, discussions internal to the project is ambiguous whether it means a namespace ban or (indeed, as the original interpretation appears to have been) just consensus discussions, and a Wikipedia namespace ban doesn't logically follow from the evidence in that case. Asking questions in venues (including WP:VPT, which whilst is a "village pump", it's used for asking questions not consensus discussions on making policy) is totally fine, for example. That 2014 edit, at least as interpreted now, appears to have been a material change. Was there a discussion leading up to that? Why is the WP namespace more of a problem than any other NS? ProcrastinatingReader (talk) 22:44, 15 April 2021 (UTC)
    • To be explicit, I’d vote to begin by scrapping PROJSOCK, as it’s clearly been misinterpreted from the original reason it was written, as is redundant to existing examples. But I see this not mutually exclusive with some other remedies, which extend beyond just project space. ProcSock (talk) 12:49, 27 May 2021 (UTC)
  • (based on your old sandbox I've presumed option 1 includes CUs disclosing connections) Presumably users can be subject to discretionary checks for various reasons, and the CU policy is rather vague on what is grounds for a check. So, reading that option now, a discretionary check could result in a privacy account popping out (possibly already disclosed to ArbCom which the CU wasn't aware about, but even if not we don't treat ignorance of policy as deliberate attempts to violate policy), so the CU goes ahead and links the two accounts publicly. So basically you'd have CUs outing editors, with solid technical evidence to dispel any doubt too. Which just isn't fair on its face. ProcrastinatingReader (talk) 22:57, 15 April 2021 (UTC)
  • My tenure on the Arbitration Committee, and as a checkuser, made me aware of plenty of situations where the use of an alternative account was the only legitimate way to continue participating on the project. I also saw any number of situations where legitimate use strayed into illegitimate. This was often by accident, but if someone sees that slip, the cat is not getting back in the bag. The conflict between alternative accounts and Wikipedia's commitment to transparency is unresolvable. I'll defer to the current committee on whether they think the present system is sustainable. Personally, I wouldn't want to be entrusted with that information, and if I were seeking to avoid scrutiny and still edit Wikipedia (a difficult task), I would be loath to disclose that information to anyone. Mackensen (talk) 23:01, 15 April 2021 (UTC)
    Mackensen, I've just noticed that you were part of the Committee that passed the principle that led to PROJSOCK (Wikipedia:Requests for arbitration/Privatemusings § Sockpuppetry). What was the reasoning behind it? The first two sentences are intuitive, but I don't understand that final restriction. Pinging those members of the Committee. Sdrqaz (talk) 21:57, 16 April 2021 (UTC)
    Sdrqaz wow, what a fucked up thing {{bcc}} is. How in the living hell is a recipient supposed to know where on the page they've been bcc'd? Otherwise, my opinion about sockpuppetry (I hate that term) is the same it was back then: "Should be generally forbidden. Wikipedia is not a role-playing game." But I wasn't going to win that argument, which is why I've divorced myself from all involvement in Wikipedia policy; I'm a sore loser.--jpgordon𝄢𝄆 𝄐𝄇 00:56, 17 April 2021 (UTC)
    Sorry about that, jpgordon. I only use it when I feel there are too many people being pinged. Thanks for sharing your opinion on sockpuppetry. Sdrqaz (talk) 17:12, 17 April 2021 (UTC)
    Sdrqaz, I don't think we thought we were saying anything new. See for example my comments at Wikipedia:Requests for arbitration/Privatemusings/Workshop#Alternate accounts: The use of an alternate account to stir up policy debates while the main account does something different has never been acceptable on Wikipedia. Sockpuppetry was understood to mean the abuse of multiple accounts; using multiple accounts non-abusively was frowned on but not banned. Maintaining a burner to stir things up on policy pages evaded accountability. Mackensen (talk) 23:22, 16 April 2021 (UTC)
    Sdrqaz, that said, this was apparently a controversial assertion at the time (I'm sure I knew that once, but I'd forgotten). See Wikipedia talk:Requests for arbitration/Privatemusings/Proposed decision#Principle 3 concerning sockpuppet policy. Mackensen (talk) 23:27, 16 April 2021 (UTC)
    I was pinged into this discussion. The contentious issue seems to be the natural justice of excluding undisclosed private accounts from the Wikipedia: namespace. My reaction here is "too bad". I would keep the principle, and just note that there may be mitigating circumstances for such editing. On the whole we want to know that users edit in good faith from single accounts in internal discussions, and I find said "restriction" natural at the level of ArbCom principles. Charles Matthews (talk) 07:12, 17 April 2021 (UTC)
    Thanks, Mackensen and Charles. Mackensen, wouldn't such abuse fall under the "avoiding scrutiny" part of policy? I don't think PROJSOCKing should be encouraged (and the maintenance of accounts in the Privatemusings case arguably falls under that avoidance), but a blanket ban doesn't sit well with me. Sdrqaz (talk) 17:12, 17 April 2021 (UTC)
  • I would prefer that PROJSOCK be modified. There are cases where a privacy alt is useful. Just because we are not censored, does not mean the world is the same. They can be particularly useful in maintaining sexual health articles. A recent example is the RfD's for Tiny penis. It's reasonable to not want that at the top of your contribution history, and as long as the editor is not being deceptive or behaving in a way that will get them sus'd out, we should allow privacy alts in discussions of that nature and not actively discourage their use. Wug·a·po·des 23:24, 15 April 2021 (UTC)
  • I generally back proposal 2. There are reasons for private accounts. While editors obviously can't be obliged to "cover it up", that does not mean that we have to pick an all or nothing approach. For example, a sockpuppet investigation could have the details revdelled if it was agreed no breach had occurred, but required major disclosure to demonstrate it. We wouldn't be any worse off, other than a few minutes of admin clerk time. Some minor amendments to the nature of proposal 2 to include helpdesks and so on in the exemption also seems reasonable. I had originally wondered "why not just switch back to the main account to ask", but realised that certain questions would require enough specificity to accidentally twin the accounts. One additional change I'd propose would be formally authorise ARBCOM to share details on private alts with CUs Nosebagbear (talk) 23:52, 15 April 2021 (UTC)
  • If never the two accounts shall meet, why should we care? Absent seeking significant bits, is it really an issue if an editor manages to successfully maintain two alternate wiki personalities for years on end? The risks should be disclosed up front (option 1) and from there on, it should be on the editor to ensure the two personalities are never in the same venue. Once they catch the eye of a CU AND violate policy, then public revelation may be a consequence (though pointing to things like WP:BLP, we have expressed an aversion to exposure that could lead to real-world harm of subjects, though guess editors do not get the same courtesy). In short, it seems like we shouldn't be playing a game of gotcha until/unless pseudo-anonymity is not a core policy of en-wiki. Slywriter (talk) 00:07, 16 April 2021 (UTC)
  • A modified option 2 (with the warnings from option 1) is really the only practical option here, but instead of minor amendments it should be rewritten wholesale to focus exclusively on detailing what activities and behaviours are prohibited. For example we want editors to be able to highlight problems and potential problems with articles/project pages/technical issues, we want them to be able to respond to queries about their editing, we want them to be able to ask questions aimed at improving their editing, etc. We don't want them to misrepresent themselves as more than one person, we don't want them to !vote multiple times in a discussion, we don't want them evading sanctions, etc. All of these things are equally desirable or not desirable regardless of what namespace they happen to occur in. Asking for help on an article talk page is no different to asking for help at a Wikiproject page or the teahouse, discussing the reliability of a source on an article talk page is no different to discussing the reliability of a source at WP:RSN. Discussing changes to a template used on user pages is unquestionably a "discussion internal to the project" but I see no possible justification for excluding privacy alts from such a discussion, doubly so if they are excluded if the discussion happens in the Wikipedia namespace but not if it happens in the template talk namespace. If there are certain discussions such users need to be excluded from (and I'm having difficulty thinking of any) then we need to detail what those discussions are and importantly why they excluded (people are more likely to abide by rules they understand the purpose of that rules they don't). Thryduulf (talk) 01:17, 16 April 2021 (UTC)
  • I was writing something up, then Thryduulf put it in a far more elegant manner. I have no objection to private secondary accounts editing project space and would scrap PROJSOCK entirely. The standard provisions under WP:BADSOCK would apply, such as voting twice in the same AfD (though that would defeat the point of a "private" secondary account), voting twice in the same discussion, editing the same articles etc. Sdrqaz (talk) 01:24, 16 April 2021 (UTC)
    Sdrqaz, I'm trying to think of any truly problematic behaviour that is prohibited under PROJSOCK but isn't covered by one of the other provisions, and I can't think of any. Scrapping that line entirely may, in fact, be the most straightforward solution. – bradv🍁 02:09, 16 April 2021 (UTC)
    Thanks, Bradv. I'm open to changing my mind if someone puts forth a good argument, but I'm pleasantly surprised by how commenters so far are viewing it – I had thought mine would be a minority opinion due to a desire for transparency. Sdrqaz (talk) 17:56, 16 April 2021 (UTC)
  • Scrapping WP:PROJSOCK sounds good, given that all of the areas where editing project space creates problems appear to be dealt with by other restrictions. Tamwin (talk) 07:02, 16 April 2021 (UTC)
  • I agree that WP:PROJSOCK should be scrapped. As written, it doesn't make much sense because it may not be clear which account is the alternate and which is the primary. And it's not clear what "discussions internal to the project" means or why this matters. Andrew🐉(talk) 08:56, 16 April 2021 (UTC)
  • Scrap WP:PROJSOCK. The whole thing has contradicted Wikipedia:Clean start outright for years, even though the latter is policy (rather than essay). The only things we need to stop alternate accounts doing is evading scrutiny, bypassing editing restrictions and creating a false illusion of support for an action (and anything else uncontroversial I'm forgetting off the top of my head). Our rules here are ludicrous. Let's say someone edits as a child and gives away a bit too much personal information (not enough to dox, just enough for them to be concerned that combined with the topic of their edits or time zone or something else, it's enough to not wish to be public). Let's say that someone copies and pastes the wrong text without noticing, it's personal information and by the time it can be oversighted they're scared someone has seen and saved it. Or someone drunkenly writes something with stupidly much information. All three of these people have the choice between losing all right to privacy or never editing Wikipedia properly again (just mainspace edits is not "properly"). People here are underestimating how much information editors can unintentionally give away in behavioural evidence such as subject knowledge contributions, timestamps of edits, edits about localised topics etc., and how much some people value privacy. If an experienced editor wanted a new account just to stop the behavioural evidence piling high enough that they could be targeted then that's a plenty good enough reason.
    If someone starts an SPI based on a valid alt then you need to contact them by email or contact a CU/SPI clerk by email and explain the situation. The SPI should then be dropped, with the closure written to create as little suspicion as possible. Tough situation with no ideal solution but it's better than nothing. If you think your alt is now unusable because of the connection drawn, even though the SPI was thrown out, then start a new valid alt. — Bilorv (talk) 12:17, 16 April 2021 (UTC)
    Bilorv, creating a new account, as long as the old one was not under some sort of sanction or block, is not and has never been sockpuppetry and does not violate PROJSOCK. It's only sockpuppetry (and that includes PROJSOCK) if you operate multiple accounts simultaneously. GeneralNotability (talk) 19:46, 16 April 2021 (UTC)
    @GeneralNotability: says who? WP:SOCK says "The general rule is one editor, one account", "sockpuppetry, or socking, refers to the misuse of multiple Wikipedia accounts", "Editors must not use alternative accounts to mislead, deceive, disrupt, or undermine consensus" etc. No mention of whether you're operating them simultaneously. PROJSOCK says, in full, "Undisclosed alternative accounts are not to be used in discussions internal to the project", correct? The page doesn't define "alternative" but I've always taken it to mean "second or subsequent account created" (with complications in the case of IP editing). If that's not the case and I've not overlooked a definition, then it needs properly defining. It also seems to me that a counterexample to your comment is that WP:BADSOCK explicitly lists "Misusing a clean start", a term specifically referring to a new account operating never in conjunction with an old account, as an instance of sanctionable sockpuppetry. (Though this bullet point is almost the exact opposite of CLEANSTART, as the main use of a clean start is when you think you've been messing up and you want a chance to leave that baggage behind i.e. avoid some types of scrutiny. Another one to remove entirely.) I think we need a lot of discussions about how to rectify the many contradictions within SOCK and itself, and SOCK and CLEANSTART, and removing PROJSOCK is one of the things I would like to happen. — Bilorv (talk) 20:42, 16 April 2021 (UTC)
    Bilorv, further down the page, under WP:SOCKLEGIT: Clean start under a new name: A clean start is when a user stops using an old account in order to start afresh with a new account, usually due to past mistakes or to avoid harassment. A clean start is permitted only if there are no active bans, blocks, or sanctions in place against the old account. (some further details follow that quote, but that's the gist). Also, If you are unable to access your account because you have lost the password or because someone has obtained or guessed your password, you may create a new account with a clean password. SPIs are routinely declined because the reported accounts operated sequentially. I concede that both of those say you're supposed to mark the old account as retired or (for lost-password cases) publicly declare the connection between accounts. With lost-password scenarios, however, odds are that the editor in question didn't actually read the sockpuppetry rules when they got locked out and created a new account, so that is fairly loosely enforced. GeneralNotability (talk) 21:11, 16 April 2021 (UTC)
    @GeneralNotability: I'm struggling to see which of this text supports the claim creating a new account, as long as the old one was not under some sort of sanction or block, is not and has never been sockpuppetry, or which of it refutes any of the statements I made. — Bilorv (talk) 21:23, 16 April 2021 (UTC)
    Bilorv, apologies, it's actually the context of those sentences (the fact that they're under WP:SOCKLEGIT, which is the section "Legitimate uses") which supports the claim. The heading of that section, in part, says Alternative accounts have legitimate uses. For example, editors who contribute using their real name may wish to use a pseudonym for contributions with which they do not want their real name to be associated (...) These accounts are not considered sockpuppets. and then goes on to list examples of legitimate alternative accounts, two of which I quoted in my previous post. I do, however, quibble with the terminology of "alternative accounts" since that (to me) implies the use of more than one account at the same time. GeneralNotability (talk) 21:35, 16 April 2021 (UTC)
    @GeneralNotability: thanks, I think I understand better where you're coming from now, though I can't agree that the policy as written supports your claim. On the other hand, I think I agree that it should be written in a way that makes the claim unambiguously true. There are lots of problems here—"Inappropriate uses of alternative accounts" is including things which maybe don't fit the letter of this definition of "sockpuppet", but it's labelled WP:BADSOCK and everyone uses this as a list of sockpuppet behaviour. This definition of "These accounts are not consider sockpuppets" follows the section, rather than preceding it, and still leaves a lot of terminology specification to be desired. This is the sort of thing I'm referring to about SOCK contradicting itself—I suppose the base issue here is that I've been here 7 years and read the page dozens of times and I don't feel I understand clearly where the boundaries are. In general I don't like legalese and bureaucracy, but I do think we're doing a huge disservice to anyone navigating alternate accounts (or IP and logged-in editing) in good faith because they need to be able to say: here is an ironclad justification for my actions and if I ever have to defend them, here is unambiguous policy as written at the time I made these decisions. Or they need to know: actually, I can't do this, and here's the unambiguous reason why. — Bilorv (talk) 21:56, 16 April 2021 (UTC)
    The more this discussion goes on and the closer I look at all the policies the more I see what a complete mess they are. Wikipedia:Sockpuppetry could do with a complete top-to-bottom rewrite to increase clarity, remove contradictions, and present everything in a logical order. For example several of the bullets under inappropriate uses are different examples of appearing as multiple people, there should just be a single prohibition on doing that with an non-exhaustive list of examples. Thryduulf (talk) 21:44, 16 April 2021 (UTC)
    Absolutely, this is part of the point I'm trying to make (though I think I'm muddling it partly because I don't even understand what the rules are and aren't, so I struggle to suggest concretely what new version to change to). — Bilorv (talk) 21:56, 16 April 2021 (UTC)
    @GeneralNotability: Question: Say you got a 14 year old doing some silly stuff and gets themselves indeffed. 4 years later they decide to give Wikipedia another try. Obviously it's not ideal to be continuing an account where one was adding obscenities to articles or something. So... they're expected to get an unblock on their main account, and then mark it as retired and then create a new one? If they've lost the password to the original, they're expected to reset it. If they've lost the email, then...? ProcrastinatingReader (talk) 09:24, 17 April 2021 (UTC)
    Just to clarify the point a bit: I strongly oppose all three of the proposed remedies and feel they are a step backwards from the already inadequate status quo, though (1) is the least objectionable. — Bilorv (talk) 20:42, 16 April 2021 (UTC)
  • 1 or 3 are my preferred solutions. --In actu (Guerillero) Parlez Moi 13:47, 16 April 2021 (UTC)
  • Scrap WP:PROJSOCK. I can't think of any behavior we want to disallow which isn't already covered by one of the other bullet points in WP:ILLEGIT. -- RoySmith (talk) 14:39, 16 April 2021 (UTC)
  • Scrap PROJSOCK per the others. Otherwise oppose all three options. Levivich harass/hound 15:44, 16 April 2021 (UTC)
  • Keep PROJSOCK, but can clarify; 1 and 3 are preferred I largely agree with Guerillero on this (also courtesy ping to Risker for some history on the topic.) I am fine with clarification on PROJSOCK that people can validly use it to comment on discussions directly relevant to them, but that isn't a reason to throw our the baby with the bathwater.
    There are several reasons behind PROJSOCK, but one of the main ones is that it provides a clear line for individuals rather than the rather ambiguous avoidance of scrutiny line, which is open to interpretation. As an example of where these would be issues:
  1. People commenting on AE or ANI cases related to individuals they have a known negative relationship with. This prevents the closer from weighting arguments (grudges are fair to consider), and has the effect of potentially preventing sanctions on a main account (i.e. IBAN.) Even if only one account comments, this is an issue.
  2. Potential harassment concerns following users around in project space that they don't like from disputes elsewhere. Even if there is not any double voting, this is still an illegitimate use of multiple accounts. It is significantly harder to deal with, however, if there is not a clear prohibition.
  3. Concealing behaviour on internal discussions that might not be sanctionable but would have a negative impact on someone's position within the community -- if you're an archinclusionist or archdeletionist with positions way outside of the community norm and use a "privacy alt" to comment on AfDs this is an abuse of multiple accounts. If you request permissions at NPR and it is clear that you do not have an understanding of the notability policy that is in line with the community's it will be denied. If you run for RfA and you have positions on any number of topics that show a clear disconnect with community consensus, you will not pass RfA. All of these are forms of evasion of scrutiny that erode community trust, and are abuses of multiple accounts, but without PROJSOCK would be much more difficult to deal with.
We are an online community and part of that is about trust. If you don't know that the person who you are talking to is not commenting in a completely absurd and abusive manner 10 minutes later, or at least have reasonable assurances that they aren't, trust will go down hill. Many other Wikimedia projects do not allow secondary accounts at all. Updating our policy to allow people to essentially have as many personalities as they want in project space, and have ways to Wikilawyer out of it as the policy would be unclear is a clear negative, and would set us up with Commons to be one of the projects most open to abuse. TonyBallioni (talk) 01:32, 17 April 2021 (UTC)
Hmm... On #2, surely hounding is hounding anywhere (why is it any better to be following an editor around on article talk or template talk pages?). On #3, surely we shouldn't make policy that affects many editors for the sake of the dozen per year that want to run RfA (who can be asked to disclose individually?). Also, general note, aren't 1/3 not mutually exclusive with 2? Seems like Beeble has pointed out multiple issues, and even if PROJSOCK is adjusted (in whatever direction) the 'issues' about CUs not knowing declared alt accounts, or the infeasibility of policing edits (whether in WP: or any other namespace) remains. ProcrastinatingReader (talk) 10:15, 17 April 2021 (UTC)
TonyBallioni, The problem is, this is conflating "internal discussions that affect project policy" with "Wikipedia namespace". Given that we do allow privacy socks, surely you're not arguing that WP:Teahouse should be off-limits? Is asking for help on Help talk:Footnotes OK, but not on Wikipedia talk:Citing sources?
If a privacy sock is dragged to WP:AN, can they defend themselves there? Or if one of their articles is nominated at WP:AfD, can they participate in that discussion? Would it be OK to protest a WP:PROD, because that happens in article Talk space, but once you've done that and somebody takes the next step and brings it to AfD, you're stuck?
And what about WP:DYK, WP:GA, WP:FA? Are those fair game for privacy socks? DYK reviews take place mostly in Template space, GA in article Talk space, and FA in Wikipedia space. Does that mean that DYK and GA are OK, but FA is not?
What about participating in wikiprojects? They're in Wikipedia space. Would our hapless NASA employee from my earlier example be barred from participating in WP:Wikiproject Flat Earth? Maybe that's off-limits but Portal:Flat Earth is fine?
What about drafts? Can they review submissions in Draft space, but not add their name to Wikipedia:WikiProject Articles for creation/Participants?
Your goal is to ensure that privacy socks don't get to speak with multiple voices at discussions that drive project policy. That's a laudable goal, but outlawing the subset of pages that happen to fall into the Wikipedia namespace does not advance that goal. By the time you're done carving out all these exemptions, the bright line you seek will have gotten rather blurry. -- RoySmith (talk) 12:47, 17 April 2021 (UTC)
Your goal is to ensure that privacy socks don't get to speak with multiple voices at discussions that drive project policy. No. That is not my goal, and my entire response above was saying it doesn't matter if people only contribute once to each discussion if they are doing so in a way that is designed to avoid scrutiny and deceive the community. My goal is to prevent evasion of scrutiny by people using multiple accounts, because evasion of scrutiny destroys trust on a collaborative project, which is one of the driving principles of our policy on the abuse of multiple accounts.
The reason why Wikipedia space in particular matters is because the only reason to use a second account in the Wikipedia namespace outside of limited discussions about content (RSN, AfD, and FA mainly) is to avoid scrutiny. It's to separate personalities, and not cause you to associate actions from one with the other. Unless your dealing with sexually deviant materials or other similar controversial topics, there really isn't a valid reason to want to have privacy on your project space discussions other than evasion of scrutiny
Which leads us to the final point: clear lines addressed with common sense are easier to enforce than ambiguous policy. No one is currently being blocked for commenting on the Tea House or in DYK or the like with a second account. CUs and SPI clerks have brains and are able to determine intent. If you remove a clear prohibition, that becomes much harder to figure out, and appeals become more difficult. Ambiguity on what constitutes "Avoidance of scrutiny" isn't helpful, and by keeping one line that clearly defines it for everyone, you help people know what is and isn't allowed and you help with enforcement. We're dealing with hypotheticals about the negatives, there are some heavy handed blocks, but they're pretty rare for this violation. The positives of this line when it comes to enforcement, however, are pretty huge. TonyBallioni (talk) 17:18, 17 April 2021 (UTC)
"by keeping one line that clearly defines it for everyone" Except the current single line doesn't clearly define it for everyone (otherwise we wouldn't be having this discussion). In addition to RSN, FA, AfD there are the village pumps (this one arguably excluded), the help desk, WikiProject pages, XfDs (especially related to pages they've contributed to with the alt account), RFU, RFHM, ITNC, TALKPP and similar projects, AN(I) when their behaviour is being discussed or they are the victim of others' bad behaviour, CCI, EFR, EFFP, EAR, Arbitration space for cases relevant to the pages they edit with the alt, RFA/RFB for someone they've interacted with in topics they edit using their alt, and likely many more I've not heard of. Yet the current wording does not do anything to stop someone developing multiple account personalities in discussions that happen to occur in places other than the Wikipedia and Wikipedia talk namespaces. By saying "CUs and SPI clerks have brains and are able to determine intent." you seem to be agreeing with me that what matters is the intent of the person, so surely the rules should be written to state that what matters is the intent not the venue? "The positives of this line when it comes to enforcement, however, are pretty huge." I've not seen a single good enforcement of this rule that was not also covered by other existing provisions so I completely disagree with you that "The positives of this line when it comes to enforcement, however, are pretty huge."Thryduulf (talk) 18:19, 17 April 2021 (UTC)
clear lines addressed with common sense are easier to enforce than ambiguous policy — Easier for CUs. But for the people actually using these accounts, it's much harder. Whether you will be blocked and outed is based on the goodwill of a CU or their whim on whether to go by "common sense" or the rule. We should not be setting a rule stricter than how we want to apply it—rather, the opposite, because "disruptive editing" does not have and does not need a rigorous definition, as the community can always decide to rule something as disruptive on a case-by-case basis. — Bilorv (talk) 18:01, 27 April 2021 (UTC)
  • Keep PROJSOCK, leaning option 1 – essentially per Tony. Abolishing PROJSOCK would require us to replace it with a huge wall of text explaining what exactly constitutes evasion of scrutiny in projectspace. Yes, there's a reasonable argument to be made for split contribution histories in articlespace in some cases. But independently using two accounts to participate in behind-the-scenes community processes inherently makes it impossible for me to evaluate someone's conduct as an editor in context, and that is poison for community discourse. If carveouts and clarifications are needed, that's fine and we can discuss those, but deprecation of PROJSOCK would either lead to ballooning policy or socking galore. As for my take on option 1: The current system of is suboptimal because it presents us with complicated OUTING considerations – I'm not opposed to people using alts to edit controversial topics (in articlespace) per se, but using them in a way that's policy-compliant and disconnected from their main account should be the responsibility of the operator. --Blablubbs|talk 09:39, 17 April 2021 (UTC)
    @Blablubbs and TonyBallioni: Why is projectspace special? Why is evading scrutiny on a page in the Wikipedia namespace different to evading scrutiny anywhere else? Why is, e.g. Wikipedia:Help desk a "behind-the-scenes community process" but e.g. Help talk:Citation Style 1 not? Why would we need a "huge wall of text explaining what exactly constitutes evasion of scrutiny"? Surely it is better to just prohibit "evading scrutiny" and list some examples so that we don't have to deal with wikilawyering? Thryduulf (talk) 11:08, 17 April 2021 (UTC)
    Thryduulf, the Help Desk is one of the places I would consider carveout-worthy. What is special are places like AfD, AN(/I), AE or RFAR. The issue with relying only on the evasion of scrutiny clause is that it will lead to Wikilawyering either way. It inevitably provokes situations where people say "but it wasn't one of the listed examples" and we have to have drawn-out unblock discussions and AN threads about what is and isn't evasion of scrutiny. I'd argue that most scenarios where someone uses a privacy alt in community discussions are inherently scrutiny evasion; a blanket ban on PROJsocking with specific, narrow exceptions is more feasible. Blablubbs|talk 11:18, 17 April 2021 (UTC)
    Even if we say something like PROJSOCK is required, "consensus discussions and conduct dispute resolution" seems to encompass all of those examples, and others. The average projectspace page is just not problematic, from WikiProject talk pages to bot/editfilter requests. Even the text I cite is questionable, as asking whether a source is reliable at RSN could be seen as a "consensus discussion" but is just not problematic. ProcrastinatingReader (talk) 11:25, 17 April 2021 (UTC)
    Also, what if a privacy alt is being harassed? They can't post to ANI, so what's their recourse? Should they contact an admin privately? (if so, how do you communicate this to them? using the ANI banner that evidence shows few actually read?) ProcrastinatingReader (talk) 11:34, 17 April 2021 (UTC)
    @Blablubbs: So a privacy alt is not allowed to contribute to a discussion at XfD about a page they are a significant contributor to? What benefit to the project does that bring? As long as they only contribute using one of their accounts and don't otherwise give the impression of being multiple people, I just cannot see how their actions are harmful? As for "but it wasn't one of the listed examples" it's much much harder to wikilawyer around a list of examples that is explicitly not a complete list than it is a list that purports to be complete. Thryduulf (talk) 11:54, 17 April 2021 (UTC)
    I'll reply with two quotes from Tony's comment that I'm in full agreement with. As for noticeboards and AfD discussions:
    • I am fine with clarification on PROJSOCK that people can validly use it to comment on discussions directly relevant to them, but that isn't a reason to throw our the baby with the bathwater. Whether we want to keep the wording as "projectspace", or tweak it to "consensus discussions and conduct dispute resolution" is another matter.
    As for what harm it brings to just blanket-allow participation in such discussions:
    • ...if you're an archinclusionist or archdeletionist with positions way outside of the community norm and use a "privacy alt" to comment on AfDs this is an abuse of multiple accounts.
    If we see such an obvious alternative account used to vote in AfDs now, current policy gives us grounds for an investigation; a deprecation of PROJSOCK would severely complicate that, but such behaviour is highly problematic and a serious breach of community trust. Blablubbs|talk 12:11, 17 April 2021 (UTC)
    Firstly, why is using multiple accounts to express extreme views more problematic than using a single account to do so if there is no attempt to manipulate the discussion or appear as multiple people? Secondly, why is using multiple accounts to communicate such positions problematic in the Wikipedia namespace but not in any other namespace? Thirdly, If we agree that using an alternative account in a given manner is problematic then surely policy should explicitly prohibit using multiple accounts in that manner rather than as part of a very broad and very vague prohibition that requires numerous carveouts and exceptions to avoid catching things we don't want to prohibit and requires people to guess what behaviour we don't want them to engage in? Thryduulf (talk) 12:43, 17 April 2021 (UTC)
    Anyway, even if we do nothing but remove "Undisclosed alternative accounts are not to be used in discussions internal to the project." the behaviour you are talking about would still be covered by "it is a violation of this policy to create alternative accounts to confuse or deceive editors who may have a legitimate interest in reviewing your contributions." Thryduulf (talk) 12:47, 17 April 2021 (UTC)
    To answer your question as to why it's problematic for someone to use different accounts to segregate views on internal matters: our system is built on trusting other contributors, and part of that trust is built on knowing their past history of views. As an example, I know you and I agree significantly on most things related to the harassment policy and outing, but have very different views on speedy deletion. While I'll engage with you on the latter topic, I'm also not going to spend a significant amount of my time trying to persuade you around to my point of view because at some point based on past discussions, I know we're just going to have to agree to disagree. On the flip side, in discussions around harassment and privacy, I'm much more likely to rethink my position and see if I considered everything if I see you or someone else who I know I share similar thoughts to arguing one way.
    This is what comes with being a community: you take all of the actions and positions of people, and they do impact how you read what they're saying and influence your thoughts. That's not a bad thing, that's human nature and it is a natural and important part of communities, both online and otherwise. The concern isn't an account that exists solely to segregate views on policy discussions, it's two accounts that never overlap and are fully developed accounts with their own personalities contributing to community discussions in a way that if uncovered would cause a loss of trust in the community. Having some policy around that clearly prohibiting it is a good thing, as in my experience it's easier to deal with clear lines with common sense than it is to deal with ambiguous lines in a similar manner. TonyBallioni (talk) 17:18, 17 April 2021 (UTC)
  • All three original options seem reasonable to me, per the proposal. Removing WP:PROJSOCK from the sockpuppetry policy entirely, however, is an idea that came up during the discussion and that isn't agreeable to me. Imagine someone who operates two accounts, one for mainspace and one for projectspace. Both are strictly separated: The mainspace account never edits the Wikipedia namespace, the projectspace account never edits articles. The result is an account that does not violate any policies while undermining our trust in community discussions. One of the main aspects of internal Wikipedia discussions is that they're held by users who also contribute to the encyclopedia in ways that can be easily looked up. Allowing project-only sockpuppets to loudly participate in internal discussions without ever having made any visible contributions to the encyclopedia would be a mistake: Policies affecting all articles are created in internal discussions, so we'd suddenly be open to policy changes by people who have no idea what their proposed changes mean to editors. Policy must be written, and consensus must be found, by people who verifiably contribute to the encyclopedia. Project socks prevent this verification. ~ ToBeFree (talk) 10:59, 17 April 2021 (UTC)
    An account that edits only in projectspace is a very, very uncommon situation and PROJOCK both prohibits far, far more than that and doesn't actually prevent an account that doesn't contribute to the encyclopaedia from contributing (loudly or otherwise) in internal discussions held on e.g. template (talk) pages, help (talk) pages, article talk pages, category (talk) pages, etc. I'd also argue that an account that has contributes to the development of back-end tools and similar has verifiably contributed to the encyclopaedia. Thryduulf (talk) 11:14, 17 April 2021 (UTC)
  • "The reason why Wikipedia space in particular matters is because the only reason to use a second account in the Wikipedia namespace outside of limited discussions about content (RSN, AfD, and FA mainly) is to avoid scrutiny." I disagree with this. I would create a second account under my real identity if I could, and use my real-name account for noncontroversial editing and all noncontroversial project space discussions, while using my anonymous Levivich account to edit controversial topics (like war, politics and religion) and related project space discussions. If I did, it wouldn't evade scrutiny, it would increase it. Right now I could have a privacy alt that edits, say, sex topics (User:Sexivich?), and I can use this Levivich account to edit project space RFCs about sex issues and no one would know Sexivich's edits in those areas were mine. That avoids scrutiny. If instead I could use the Sexivich account for sex-related project space discussions, that would be more transparent, not less. If we're going to allow privacy alts (and we do, as we should), we should allow those alts to edit all namespaces. Levivich harass/hound 18:45, 17 April 2021 (UTC)
  • Strongly agreed on the first remedy. We should discourage privacy alts not because they're illegitimate, but because they don't work very well. Like Beeblebrox, my experience with this on ArbCom was a bunch of cases of people setting up a privacy alt for good reasons, accidentally outing themselves and/or getting themselves CU-blocked because they misunderstood our byzantine sock policy, then asking us to unring the bell. Probably there's a bias there in that we only heard about the cases that went wrong but, with this and other policies (oversight, vanishing, clean starts), we need to be more up front with the fact that the only reliable way to maintain your privacy on Wikipedia is to never reveal private information in the first place.
I always thought PROJSOCK was an arbitrary rule, but I don't know the history behind it, so I'm on the fence about that. – Joe (talk) 19:05, 17 April 2021 (UTC)
  • Scrap PROJSOCK, remedy #2 second choice Projectsock is really an outdated and overly broad guideline that should be eliminated, but if that doesn't have consensus I would support clarifying it to make its reach more narrow.Jackattack1597 (talk) 00:59, 18 April 2021 (UTC)
  • Strongly Discourage non-publicly-declared parallel-editing accounts,
    and simplify the rules for simple cases before getting bogged down in the complicated LEGITSOCK rules.
WP:SOCK is confusing for a simple newish Wikipedian to get simple answers. There is some very complicated stuff in it that is interspersed with simple stuff, and I think the simple stuff should be stated clearly and upfront, and with the complicated stuff below, under warnings.
The simple stuff is:
WP:SOCKING is NOT:
  • The use of multiple accounts that are publicly declared (declared on the main userpage, and all such accounts connected). Examples for this include secure and non secure computers. Segregation of edits of different types. Maintenance of multiple watchlists. Templates for this include {{User alternative account name}}, and I think they belong at the top of the main userpage.
  • Non-editing accounts. eg. Reader accounts; long-abandoned accounts; doppelganger-prevention accounts.
  • Editing logged out to fix errors in mainspace.
Stuff gets complicated when talking about multiple editing accounts that are not publicly declared. Mainly, the reason for these seems to be "privacy". There are good reasons to not publicly disclose two editing accounts. You may have a good reason to edit publicly, in front of family, work, or for educational course purposes, and not want to reveal your main anonymous account. However, the section allowing for this should clearly and strongly state that doing this is NOT RECOMMENDED, and if done, done only briefly and for very narrowly defined purposes. One little mistake, and the connection may be spotted, and may then be forever public. Relative newcomers to Wikipedia should be actively discouraged from running undeclared editing accounts in parallel. This complicated stuff needs to be written, and is written, but it should be separated from the simple for the sake of simple comprehension of a simple reading of policy for simple questions.
The rules for non-publicly-declared parallel-editing accounts need to be clear and hard. There is currently a rule that you have these, only the main account may edit project space. This is very important for accountability. I think some words are needed to clarify what is a "main account".
Should an undeclared account every be allowed to participate in AfD discussions on their own content? We had discussions on this at WT:SOCK in March 2010, and in the end I found User:SlimVirgin, 10:03, 19 March 2010 specifically, convincing that legitsocks should not be allowed at AfD or dispute resolution. I also think that it is a simple and necessary extension to this that IPs must not be allowed to contribute to AfD, or to project space discussions in general.
--SmokeyJoe (talk) 08:36, 18 April 2021 (UTC)
Answering User:RoySmith's questions of 12:47, 17 April 2021 (UTC). For LEGITSOCKS, that are the not the main account, These should be specific-purpose, preferably short-term accounts. WP:Teahouse should be off-limits. Asking for help on Help talk:Footnotes maybe, but not on Wikipedia talk:Citing sources? No, simple hard rules are needed for this dangerous practice. The main account can ask questions about citing sources. I don't see why the non-main LEGITSOCK should be asking at Help talk:Footnotes.
If a privacy sock is dragged to WP:AN, they cannot defend themselves. If a privacy sock is dragged to WP:AN, and the thread is entertained, something is wrong, and the person is not qualified to run a privacy sock. An account trying to be quiet and do a specific thing should be quiet and well mannered.
If one of their articles is nominated at WP:AfD, can they participate in that discussion? No. The community has to be trusted to be running a fair AfD.
Would it be OK to protest a WP:PROD, because that happens in article Talk space, OK. But once you've done that and somebody takes the next step and brings it to AfD, you're stuck? That's right. Trust the community at AfD.
And what about WP:DYK, WP:GA, WP:FA? These are high end editing, competitive and somewhat drama associated. Reputation and accountability are important here. It is no place for a sockpuppet.
No to WikiProjects. No to AfC reviewing. No to Portals.
Pretty much, LEGITSOCKS should stick to mainspace, and to answer questions directed to them in talk space and user_talk. --SmokeyJoe (talk) 11:21, 18 April 2021 (UTC)
  • I strongly support the right to have privacy alts. Accordingly, they should be allowed to contribute in the project namespace, insofar as it's practical to write policy allowing this, subject to concerns such as the ones raised by TonyBallioni. They should certainly be allowed to defend their articles from deletion, and other such directly relevant activities. Benjamin (talk) 08:45, 18 April 2021 (UTC)
  • Scrap PROJSOCK and scrap disclosures - PROJSOCK misinterprets the Arbcom case that led to its addition to the policy. The issue there was not that the user was using undisclosed alternate accounts in project space (in and of itself) but that they were using them in ways that were already forbidden by WP:SOCK (apparently WP:GHBH and WP:STRAWSOCK). It's not Arbcom's place to invent policy and they should not have done so here. If someone uses different accounts to contribute to different discussions (not the same discussions) in otherwise legitimate ways, what does it matter? PROJSOCK is a "gotcha" policy that punishes users for no benefit to the project; we should just remove the bullet. As for disclosures, we should probably stop: it's irresponsible and probably unethical to suggest that disclosing a private alt to Arbcom somehow imparts a guarantee of privacy, which is absolutely not the case. It's also clear that everyday editors don't understand that each WMF site is a separate project with separate governance, that our coordination between projects is deliberately very limited, and that what might be allowed here might not be allowed on other WMF projects. What we should do is more strongly advise editors considering a privacy alt of the dangers: if they do use their alt in forbidden ways then we will publicly connect their main just as we do for all sockpuppet accounts, and although we discourage outing, Wikipedia is in the real world and we really have no control over other editors trying to "unmask" a privacy account, though I say we should do more to discourage editors who make a habit of malicious witchhunts. If a user is going to try to use a privacy alt, they need to understand the risks, and that they are responsible for maintaining their privacy, not Wikipedia. I am, however, very strongly against creating a policy that private alts are forbidden. Ivanvector (Talk/Edits) 13:30, 18 April 2021 (UTC)
  • Question: I've been editing since 2006, but usually I create a new account every few months because I don't think scrutiny is fair. That is, if someone doesn't like what I write about sexuality topics, I don't want them going through my environmental topic editing to dig dirt on me. Is my behavior outside established norms? If I give myself a WP:CLEANSTART every three months, and abandon all my earlier accounts, is that bad? 50.242.124.27 (talk) 16:04, 18 April 2021 (UTC)
    • I think it's fine. I'm sort of the opposite of you: I've only ever edited under one account. But I've given serious consideration to doing it your way (repeated clean starting), or just saying the heck with having a registered account and editing only under a dynamic IP. The irony of IP editing, especially from a large dynamic range like a mobile provider, is that it entirely avoids all the "scrutiny" that others talk about. Dynamic IPs can edit (almost) everything and there is zero way to even see their contribs history (since the ranges are shared). And like 90%+ of the encyclopedia is written by IPs this way... no scrutiny for most editors and yet the website doesn't fall apart. That's why I think talk of scrutiny and community is misplaced: really the transparency and control we think we have over registered accounts is a joke: we only have that for those who bother to register an account and use it, and use it within policy, which is a tiny minority of all editors. Transparency and scrutiny of this type are an illusion. Levivich harass/hound 17:44, 18 April 2021 (UTC)
      • None of this is aimed at clean start accounts. Having two accounts at once is different than abandoning an account and starting a new one. If the IP has really been doing that for as long as they say, they are doing it exceptionally well and I for one have no problem with that. Beeblebrox (talk) 21:20, 18 April 2021 (UTC)
        @Beeblebrox: Doesn't it (strictly speaking) violate the letter of Wikipedia:Clean_start#Contentious_and_scrutinized_topics? (if so, perhaps that letter needs rewording) ProcrastinatingReader (talk) 21:48, 19 April 2021 (UTC)
    • This is exactly the sort of case that SOCK/CLEANSTART needs to allow. Privacy is serious business. We can't just have our rules say that it's not an option. Thank you for your contributions and I would hate to see you forced to change your editing pattern. — Bilorv (talk) 18:01, 27 April 2021 (UTC)
  • There's an interesting point above. Posit this situation:

    RoySmith decided to do it the other way around: Edit as real-world identity User:RoySmith, easily identified with boating being a well-known name in the boating world, on boating subjects; and in order to hide the shame from xyr boating colleagues of also knowing about K-Pop and species of beetle, editing everything else except for boating as User:BigBubblyBoatingBob.

    Currently this is both a Project:Sockpuppetry#Legitimate uses and illegitimate under the above proposals.

    Is this even the problem to be addressed? People mention AFD, but the sorts of sockpuppetry that we largely get at AFD are pretty much always of the kind that are illegitimate anyway. It certainly does not seem to be anything like what the Privatemusings case was, either.

    Uncle G (talk) 22:48, 18 April 2021 (UTC)

  • I think the solution is to encourage sockpuppetry. There are a few common uses of sockpuppetry that are so heinous that the entire concept is banned: socking to evade a ban/block/sanction (block evasion), socking to create the illusion of consensus (vote-stacking), and socking to evade scrutiny (WP:GHBH). There's also the well-established norm that no person can have more than one account with admin permissions. Beyond that, I think we need to re-consider why socking is a problem. User:力 (power~enwiki, π, ν) 00:16, 20 April 2021 (UTC)
  • I don't support any option as I feel that some editors may be embarrassed for users to know that they edit in a specific category and if they declared that they used an alt in those categories it might further increase the embarassment. I feel like instead there should be a template that says "This is a privacy alt of a user who would wish to remain anonymous, who uses this alt to edit in these categories:", that way the alt would still technically be declared but it saves the editor the embarrassment of having to specifically declare that they own the alt who edits in categories they would wish to not be known as an active editor in. Blaze The Wolf | Proud Furry and Wikipedia Editor (talk) 19:59, 20 April 2021 (UTC)
  • Just to clarify for myself: I do not support getting rid of PROJSOCK entirely. I think it needs to be changed, but I do think it serves a purpose. Privacy alt sre intended to be used for editing content, if you want to talk about policy, you should use your main account. Beeblebrox (talk) 20:04, 21 April 2021 (UTC)
  • To borrow Benjamin's phrase, I strongly support the right to have privacy alts. To those people saying they need to judge a person's history and character to have a working community: a privacy alt is effectively a separate person (or persona). Their contributions, discussions, and interpersonal relationships can stand on their own. I understand there's a fear that you might hold Dr Jekyll in high esteem whilst there’s a Mr Hyde stalking around. Wouldn't that be a rare occurrence? Much more common would be the case of Rob the boating expert and Bob who edits in other areas. If both accounts behave in a respectful and constructive manner, and they're not teaming up to mislead, then they should both have a voice in all parts of the project that relate to their respective topic interests. Pelagicmessages ) – (11:14 Sun 25, AEDT) 00:14, 25 April 2021 (UTC)
  • Beeblebrox, it's a bit of bullshit that there is no option to "leave things as they are". We aren't under any obligation to parrot other wikis, after all. I haven't read all the discussion (and shouldn't need to in order to opine here), but a discussion for change that doesn't allow the option to leave the status quo is null and void, imho, as you can't gauge the most basic question "is there an appetite for ANY change?". It's not like you to make such a glaring omission like that. Dennis Brown - 18:03, 25 April 2021 (UTC)
    I don't quite see it that way. I'm proposing remedies to perceived problems. If the community feels that either there is no problem or these aren't the remedies that will solve them, they will be rejected and the status quo retained. Happens all the time. Beeblebrox (talk) 18:54, 25 April 2021 (UTC)
  • I support retiring WP:PROJSOCK, which I have always regarded as a truly asinine policy. I shouldn't have to log in every time I want to contribute to a "discussion internal to the project," which, by the way, could be understood to mean "any discussion anywhere, not just in the project space, that doesn't deal exclusively with article content," and my failing to do so shouldn't be a valid excuse for some priggish admin to block me. Also, I strongly oppose the idea of effectively restricting everyone to one account—I see it as nothing short of an attempt to sneak in a (near-)prohibition on IP editing. Iaritmioawp (talk) 14:52, 29 April 2021 (UTC)
  • This site is discussing an issue prevalent on Reddit; should burner accounts be allowed? Over there, people can get away with that with (near)-impunity; but, for what it's worth, this is a new account as my old account never had email when I created it in the late 2000s on here (around 2004-2005, IIRC). I would argue people do need privacy-related sockpuppets, but there's also the people who come simply to claim usernames. As it is, there was even a suggestion on here, way back in 2007, that a now long-gone vandal (notorious for moving pages, IIRC) who wanted to reform should restart under a new account and never disclose the old one! This is a difficult topic area. But allowing multiple accounts on platforms has always been a touchy issue. I can see both sides of the argument though. Chelston-temp-1 (talk) 13:20, 30 April 2021 (UTC)
  • Scrap WP:PROJSOCK. There are plenty of reasons why an editor might want to edit under their real name for their main edits, and an alt account for topics they don't want to be associated with their real name. Say they support an unpopular political candidate. But then that alt account can't participate in wikiprojects on that topic, or discuss policy issues that affect that topic. That's silly. --GRuban (talk) 17:51, 6 May 2021 (UTC)
I believe the policy clause being questioned here is a misinterpretation of ArbCom. The statement is sourced to Wikipedia:Requests for arbitration/Privatemusings#Sockpuppetry, which says: Sockpuppet accounts are not to be used in discussions internal to the project, such as policy debates. Firstly, this quote doesn't refer to discussions about behavior or to deletion discussions. Secondly, and more importantly, the question is if "sockpuppetry" means using multiple accounts in a single discussion, or using a non-main account in any of the discussions this statement refers to. I believe we should take the first meaning here, while the policy statement takes the second; if you take the second, it should apply only to the discussions refered to by the first issue here. 147.161.8.37 (talk) 12:57, 19 May 2021 (UTC)
The best way to know is to ask the arbs who handled this case, hope some of them are still around and remember this case 14 years later. The arbs are: User:Kirill Lokshin, User:UninvitedCompany, User:FloNight, User:Jpgordon, User:Jdforrester, User:Mackensen, User:Morven, and User:Charles Matthews. 147.161.8.37 (talk) 13:19, 19 May 2021 (UTC)
Anonymous editing, and efforts to maintain anonymity, were more widely thought to be good things in the early days of the project than today. Specific scenarios that I recall being discussed during that era (possibly but not necessarily as part of the Privatemusings decision) were individuals who were risking governmental or institutional reprisal for their edits, most notably editors from China. Another example would be editors disclosing details of cryptographic or DRM systems, which posed real risks of prosecution in some jurisdictions back in the day. Yet another would be contributions to topic areas that would reveal lifestyle choices (sexual orientation, recreational drug use) that could result in real-world discrimination. These concerns remain valid today for editors contributing from particularly conservative jurisdictions.
As Wikipedia has evolved, the very onerous restrictions on anonymous editing (especially in difficult topic areas) make it necessary to have a named account to make meaningful contributions. It is my view that requiring users to link all their contributions by using the same account at all times will silence important voices that have a genuine interest and ability to contribute. I also believe that the present approach to dealing with socking is heavyhanded and unsustainable, and that we are better off evaluating edits based on their merit rather than their source. UninvitedCompany 20:27, 21 May 2021 (UTC)
My mood at the time was pretty specific -- I was really pissed off at Privatemusing's socking to "carry on and exacerbate drama", as I said in refusing an unblock request from him, and I was likely only considering it through my really intense hatred of socking in general. I think now I'd recommend deleting it; we don't need this blanket policy to deal with disruptive and/or dishonest socking when it's disruptive and/or dishonest. --jpgordon𝄢𝄆 𝄐𝄇 23:29, 4 June 2021 (UTC)
  • Delete WP:PROJSOCK. Since this discussion has not yet closed, I'll add my voice to those who think the simplest solution is to get rid of PROJSOCK entirely. I asked earlier in this conversation if there was any disruption being caused by alternate accounts editing in project space that was not also covered by one of the other rules, and to my knowledge, no one has come up with one. But what's more concerning to me, as a checkuser and a member of the arbitration committee, is the number of times that obvious alternate accounts get checked solely because they edited project space, despite there not being any disruption or evidence of abuse. I don't believe such checks fall within the spirit of the CU policy, but they are justified simply because of this wording in the sockpuppetry policy. This is circular logic at best, and it's high time we fix it. – bradv🍁 21:53, 27 May 2021 (UTC)
    • User:Bradv, and many others, what do you mean by “Delete WP:PROJSOCK”? It looks like you haven’t read the text that you link. PROJSOCK says that you mustn’t use alternative accounts to circumvent policy. I think you might mean WP:SOCK#Legitimiate uses#Privacy??? I note that WP:SOCK is a mess in terms of structural logic of presentation of information, and debating by reference to SHOUTYONEWORDSHORTCUTS is not helpful. —SmokeyJoe (talk) 04:11, 30 May 2021 (UTC)
      SmokeyJoe, you're right, I should clarify. I mean that this line should be removed: Internal discussions: Undisclosed alternative accounts are not to be used in discussions internal to the project. It's redundant to the actual problematic behaviour described in the subsequent lines. – bradv🍁 04:29, 30 May 2021 (UTC)
      @SmokeyJoe: I've tried to solve the problem by creating an anchor for that shortcut; WP:PROJSOCK should redirect to that sentence specifically. Sdrqaz (talk) 11:57, 31 May 2021 (UTC)
      User:Sdrqaz, I think that is counter productive. Too many non-intuitive shortcuts do not help understanding of the policy, and the6 make it harder to improve the structure and presentation. It would be better to quote text explicitly, and to not write in slogans. —SmokeyJoe (talk) 12:14, 31 May 2021 (UTC)
      SmokeyJoe, I agree that we shouldn't overuse these shortcuts (especially without linking to them when first mentioned) because it creates barriers of entry to newer users, but the immediate problem at that point was that it wasn't clear to where WP:PROJSOCK referring. That was the (admittedly superficial, in light of other concerns you've raised) problem I was trying to resolve. Sdrqaz (talk) 12:25, 31 May 2021 (UTC)
  • I think the current policy is good enough. No significant changes. That's OK to have a different policy in English WP. Also, no scrapping WP:PROJSOCK as a whole. I think Undisclosed alternative accounts are not to be used in discussions internal to the project just needs to be clarified. I guess it means editing in the project space, like the noticeboards and AfD? This needs to be more explicitly stated. My very best wishes (talk) 18:02, 8 June 2021 (UTC)

Consolidating help venues

Impartial Expert Editor

Maybe this is the wrong place in which to be asking this question. However, at the Dispute Resolution Noticeboard, there is a dispute where one of the editors says that they need an impartial expert editor to supervise the rewriting of a group of articles. Wikipedia does not have any designations of expert editors or master editors. (Some new editors may think that the various service ribbons on user pages have more meaning than they do. The editors who display the service ribbons know that the awards are either humorous or humourous, depending on continent.) There isn't a pool of impartial expert editors who can be called on when requested. My thinking is that improving any group of articles is sort of what WikiProjects are for. Is there any additional advice that I should give to an editor who says that a whole group of articles need to be substantially rewritten? Robert McClenon (talk) 04:23, 18 May 2021 (UTC)

  • Isn't this where setting out the issues on the article talk page and then requesting comments using the feedback request service can provide the benefit of impartial input from experienced editors who have signed up to that service? They may not bring topic expertise as such but can advise on whether there is indeed a problem and what might be next steps. AllyD (talk) 06:26, 18 May 2021 (UTC)
    • User:AllyD - Yes, but.... I don't think that is exactly what the editor in question wants. The editor in question wants to recruit an impartial expert editor to oversee a long project of rewriting a group of articles. As I understand the Feedback Request Service, it is invoked via the Request for Comments mechanism, and so can be used in either of two ways. The first is to ask a specific question and obtain a binding consensus, for which other editors will have been invited via FRS. The second is to ask an open-ended question, which will obtain comments (just as RFC stands for). I think that what is being asked for is something more. Thank you for your comments. Robert McClenon (talk) 17:01, 18 May 2021 (UTC)
      • @Robert McClenon: I'd go with your initial hunch: WikiProjects. If the most relevant WikiProject is dormant, try its parent project or something closely related. WikiProjects get a lot of criticism but this sounds like a perfect task for them. – Finnusertop (talkcontribs) 00:33, 19 May 2021 (UTC)
        • Thank you. I think that the editor who requested an impartial expert editor has the idea that there are ranks or grades of expertise among Wikipedia editors which may be indicated by their service ribbons on their user pages. We know that some editors display various sorts of service ribbons on their user pages. It has always been my understanding that those service ribbons are humorous and should not be taken seriously. I think that I have seen at least one case of an editor who thinks that there is a semi-official pool of such editors to be called on. Robert McClenon (talk) 23:03, 30 May 2021 (UTC)

Need clarity around the role of AfD closers

It's not uncommon for admins closing discussions at WP:AfD to offer their own opinion on the notability of a subject, i.e. whether WP:GNG and/or some WP:SNG is met. These will often get brought to WP:DRV for review. There's one such case at DRV now, and while that case was indeed what led me to start this thread, I want to focus on the more general issue, not just that one case or that one admin.

For as long as I've been involved in AfD (which is a long time), the rule has been that closers are supposed to distill the discussion, not inject their own opinions about notability. Unfortunately, I can't find any policy statement which comes right out and says that. WP:CLOSE#Policy comes close, calling out specific exceptions for WP:V, WP:OR, WP:CP, and WP:NPOV, but doesn't explicitly say those are the only exceptions. In any case, it's a WP:INFOPAGE, so doesn't rank as policy. Likewise, WP:Supervote, while widely cited in DRV discussions, is just an essay.

So, what I'm looking for is a more official statement that AfD closers must rely on the input of the discussants regarding notability. If there's not an actual policy page where it makes sense to add that, then at least a consensus close to this thread and updating WP:CLOSE#Policy to explicitly disallow closers to apply their own notability judgements would be good enough. -- RoySmith (talk) 16:04, 24 May 2021 (UTC)

Thanks for raising this issue. WP:DGFA might be a place to put it also. But I think the issue you're raising is broader than deletion discussions. We have almost no policies or guidelines about closing statements, and what is and is not appropriate to include in them. It's not really spelled out in WP:CONSENSUS, WP:CLOSE, WP:RFCEND, DGFA, WP:XFD, WP:DELPOL... how to write a closing statement doesn't appear to be anywhere in our alphabet soup. I would imagine the rules or at least principles for closing statements should be the same for XfDs as for RFCs and other discussions. We should write something, as it will help all sorts of closure reviews. Levivich harass/hound 16:22, 24 May 2021 (UTC)
  • Thanks RoySmith for raising this; I agree that the principle of not supervoting definitely enjoys community support and ought to be codified somewhere, along with other information about closes per Levivich. Info about non-admin closes could be moved there, too. {{u|Sdkb}}talk 16:52, 24 May 2021 (UTC)
  • I think most practices around closes are informal, split over various individual consensus', and some good advice in Wikipedia:Advice on closing discussions. It's generally recognised that it's not the job of closers to supervote; very few closes are, and I don't think anyone has ever made the WP:JUSTANESSAY argument when their supervote is challenged, so I don't see why a policy is necessary (and don't think it's a good idea). Decisions are made by WP:CONSENSUS and I suppose the role of closers is just someone uninvolved who summarises what the consensus in a discussion was. I guess a note in Wikipedia:Consensus could be added to this effect? ProcrastinatingReader (talk) 17:34, 24 May 2021 (UTC)
  • I would support this. SportingFlyer T·C 17:52, 24 May 2021 (UTC)
  • My sense has always been that arguments presented in a closing statements should never include (other than perhaps as background information and only if they don't affect the close) any argument that was not presented by participants/!voters. Unless they are overriding policy, such as when folks want to keep a clear copyvio. Jo-Jo Eumerus (talk) 18:45, 24 May 2021 (UTC)
  • Wikipedia:Deletion guidelines for administrators § Rough consensus, which is linked to from Wikipedia:Closing discussions § Consensus, discusses examining strength of argument and any relevant policies. Arguments that are made in bad faith, contradict policy, are based on unsubstantiated personal opinion, or are illogical are given as examples of arguments that may be discounted. I'm not sure any new official guidance on determining consensus is required on this aspect, but perhaps Wikipedia:Advice on closing discussions should be more broadly advertised to prospective closers. The "Additional considerations" section covers not discussing arguments that weren't raised in discussion, and not reaching an outcome that no one discussed, for example. isaacl (talk) 19:57, 24 May 2021 (UTC)
  • I'm not sure the responses have adequately discussed exactly what RoySmith proposes - there have been a couple DRVs of late where the closer has appeared to agree with the side that "wins" the discussion, especially where the closer looks at the sources and makes their own determination of whether something is notable. This isn't about raising arguments that weren't raised in discussions, it's about whether closers should be looking at sources to assess the notability of the article they're closing. SportingFlyer T·C 10:40, 25 May 2021 (UTC)
  • Perhaps better direction is in order about what the closer should look for, but it seems almost impossible for a closer to close a dispute about claims based on the sources presented and whether they reasonably support one side or the other, or both sides to some extent, without looking at the sources. (eg.: 'Primary source!' 'No, it's not!' Look at source, who makes the cogent claim, or is there a reasonable disagreement?). Alanscottwalker (talk) 11:29, 25 May 2021 (UTC)
    Yeah, in such cases one would often end up with a "Both sides are advancing legitimate arguments about whether the sources satisfy WP:SIGCOV and none of them is clearly more compelling than the other, so no consensus it is". Jo-Jo Eumerus (talk) 13:40, 25 May 2021 (UTC)
  • The closing statement in a deletion discussion is very much a performative utterance and there are expectations that we don't pollute the performance of closing (which enacts consensus in addition to, hopefully, summarizing the strength of arguments) with the arguments it's supposed to be considering. In most of the cases I've seen where people take issue with a closer expressing an opinion, it was a matter of framing rather than an actual supervote. If someone changes "it doesn't meet GNG" to "consensus it that it doesn't meet GNG" or "arguments that it doesn't meet GNG were strongest" that changes it back from a supervote to a summary. My concern about adding more exact and/or prescriptive language into instructions for closers is that it's already hard enough to close discussions based on strength of argument vs. numbers. People already get accused of supervoting just for closing against the numbers all the time. — Rhododendrites talk \\ 14:16, 25 May 2021 (UTC)
    That's a good point about not wanting to make it harder to close against the numbers. {{u|Sdkb}}talk 10:42, 29 May 2021 (UTC)
  • I largely agree with what Jo-Jo, Alan, and Rhododendrites said. Closers should read the sources to make sure the claims are accurate but shouldn't stray beyond what participants said about the sources (unless some major policy like WP:BLP is being ignored). AfDs are unusual in that they are often a binary outcome---delete or !delete---while other discussions are far more open ended. Because of this, summarizing the debate and major view points can look like a supervote, but if the close focuses on how participants applied the policies under discussion (numbers can sometimes be helpful here) I think most misunderstandings can be avoided. I don't close many AfDs, but this is how I approach requested moves which have a similar binary outcome. Wug·a·po·des 23:51, 29 May 2021 (UTC)
    I have to disagree on reading the sources, that's really the participants' task, not the closer's. Also, the lines would get blurred between what's the closer's own preference and what the consensus is if closers went this far. Jo-Jo Eumerus (talk) 14:47, 30 May 2021 (UTC)
  • As noted, there's certainly lots of cases where it's more the closer has just failed to add "consensus of discussions states that" before "GNG is not met" (etc). Sure, if they raise an argument (other than copyvio etc) that isn't mentioned at all then that's a bit problematic, but again I've not seen issues at DRV on those cases - usually its fairly obvious if its a superclose. In terms of "should they be checking sources to see if reasoning on those grounds is justified" I have to answer no - that would just be a different form of a supervote. If !voters think other !voters' arguments that sigcov et al are/are not met are invalid, they are responsible for disputing that and making that determination, not the closers. Nosebagbear (talk) 13:10, 30 May 2021 (UTC)
    So if an AFD gets flooded with socks saying that source A says XYZ, and it in fact says no such thing, a closer should close in favor of the provably false assertion to avoid supervoting? That's an absurd conclusion that I strongly disagree with recommending. Just to put some meat to this hypothetical, say 7 editors claim that The Example Daily article covers subject Anex Ample and is written by an independent journalist. One lone editor says "actually, the author bio at the bottom says the author is an employee of Anex Ample and was paid by them to write this article", and one of the original seven comes back to say "no it doesn't". Under the "don't look at the sources" theory, I should close with the 7 editors even if the source does say it was paid for by Anex Ample.
    This cannot possibly be the correct outcome, partly because it incentivizes lying. No consensus is usually a default keep, so if you want an article kept, just lie about the sources and fillibuster the discussion---the closer can't check and the participants won't have enough time to refute them all (see Gish gallop). Making sure that participants are engaging in good faith dispute and accurately characterizing external material is basic due diligence; not doing so makes it impossible to comply with Wikipedia:Closing discussions#not counting heads as a closer would not be able to figure out which claims are false let alone discount them. Imagine if judges in a court room could only hear testimony but never see the evidentiary documents discussed in that testimony because it might compromise their objectivity. If that's the fear then the solution is not enforced ignorance but to forbid that person from being a judge (the whole point of recusals). Verifying assertions and drawing your own conclusions from a source are two very different things, and if a closer cannot distinguish between the two, they should not be closing discussions. If I cannot trust a closer to objectively verify the assertions made about external material, why I should I trust them to objectively evaluate the discussion at all? We should not confuse ignorance with objectivity, let alone recommend it. Wug·a·po·des 03:54, 31 May 2021 (UTC)
    Agree with this, generally. I don't think reading the sources is always necessary, but where the question of which argument is indeed stronger comes down to what the sources actually say, the closer shouldn't refrain from looking at the sources for fear of being labeled a supervoter. — Rhododendrites talk \\ 05:17, 31 May 2021 (UTC)

There is too much supervoting on RfCs and with WP:NACs too, but maybe for another time. Xxanthippe (talk) 04:05, 31 May 2021 (UTC).

Original research heraldry for fictional universes

Is there some more specific policy for this? I removed some: Special:Diff/1026260344 and Special:Diff/1026072768. These images are artist impressions based on text descriptions. I'm afraid there may be a lot more out there. According to OTRS the image on the right is a creation of User:TTThom. It's used on Heraldry of Middle-earth, I'd remove it but removing all the OR will leave the article gutted and I'm not in the mood for an edit war. Is there some misunderstanding about WP:OR that causes these to be added without getting reverted in a decade? — Alexis Jazz (talk or ping me) 12:02, 1 June 2021 (UTC)

It's one thing to make up heraldry for real-world royalty/houses based on language but I would tend to agree that doing this for the same for fictional ones are far less appropriate. Unlike real heraldry which follows a specific language format that allows for license-less recreations without engaging in OR, fictional ones rarely are given in the same verbiage and thus fan-made art, while maybe not being strictly a copyright violation or failing fair use, is likely original research. --Masem (t) 13:25, 1 June 2021 (UTC)
  • If the depiction actually matches the description in the primary sources (which should always be the author themself or someone explicitly authorized by the author), and the depiction is both sourced to said description and presented as an artistic depiction with clear labelling of such (not just in the caption, but with, for example, a section hat), and is not used in the primary infobox of a page, then I would find such images appropriate and useful. Anything short of that warrants either removal, or improvement to the standards I described.
Note that I would not apply this standard to images on commons, where I think that the only standards which needs be met is a clear description of what it is and a clear statement that it's an artistic depiction. ᛗᛁᛟᛚᚾᛁᚱPants Tell me all about it. 13:32, 1 June 2021 (UTC)
  • Well, even with a limited knowledge of heraldry, there are in fact very few heraldic colours - only one kind of yellow (gules), only one kind of green (vert), and so on, so there is little to get wrong if, as the editor above has rightly stated, the original description is clear and unambiguous. I'm sure any specialist in heraldry will be able to confirm that they can readily reconstruct any badge or flag or coat of arms from its description, so if there's a lion rampant on a vert field or whatever they can draw it exactly to the satisfaction of other heraldry specialists. As long as it's made clear that this is an artist's impression or a heraldic reconstruction or some such phrase, there is no problem here. I don't agree with Masem, therefore, that there's any particular issue about heraldry in fiction; if a book's author has given a heraldic description, then that account can be taken as a specification of a heraldic badge without any suggestion of editorial invention. All the best, Chiswick Chap (talk) 14:03, 1 June 2021 (UTC)
    Chiswick Chap, there are in fact very few heraldic colours - only one kind of yellow (gules), only one kind of green (vert), and so on, so there is little to get wrong if, as the editor above has rightly stated, the original description is clear and unambiguous. Not that it's an important point, but I'd like to note that just because we have a limited palette of colors in real life heradly, that does not suggest that fictional heradly would use the same palette, or even have limits at all.
    But, you should not read that as disagreement with your overall point that heraldry is constrained to certain norms, and depictions that fit within those norms are very likely to be nearly identical to each other. Furthermore, I do, actually, think it quite likely that Tolkien, at least, would have limited himself to real-world heraldric standards, due to the depiction of Middle-earth as pre-paleolithic Europe. ᛗᛁᛟᛚᚾᛁᚱPants Tell me all about it. 14:16, 1 June 2021 (UTC)
    If these are all coming from language that is based on real world heraldry (and we're talking what appears to be mostly ME and Wheel of Time, which I would think are works that would follow that) then I can see the argument there's no issue with these. What we want to avoid is crossing a line to full fledged fan art on WP for fictional universes (eg a fan's interpretation of Battle of Helm's Deep would be inappropriate despite how descriptive the book + associated works give it). --Masem (t) 15:57, 1 June 2021 (UTC)
    Masem, This tracks exactly with my view. I outlined what my standards would be for making it explicitly clear, above. I'm a little waffley on the issue of fantasy worlds like Westeros, which is less historically tied-in to the real world, but generally speaking, I'd say a firm "no" to depicting anything that there's already an official or semi-official depiction of, like the battle you mentioned. ᛗᛁᛟᛚᚾᛁᚱPants Tell me all about it. 17:24, 2 June 2021 (UTC)
    I'm also thinking cases where, for example, the original cover art is a clear influence on the work that fan art may become derivative of that creates a question. This example gets away from the heraldy aspect but like a fan's version of Harry Potter (short of cosplay) would likely be problematic given the "official" presentation on the original cover as well as the US printing as well in the films. Heraldry, as established for even real world cases, is different and why we can use user-created COArms and flags even though there may be existing preferred versions out there, but anything short of this is going to fall more into derivative works that can be at issue. --Masem (t) 19:06, 2 June 2021 (UTC)
    Masem, Exactly.
    Now, if there's a good reason why we would want to show fan art, then it's up for discussion. As a hypothetical, I imagine a work of fiction which became known primarily for the fan-art it inspired. In that case, a couple examples might be okay. And cosplay might be useful to help demonstrate the prominence of a work in pop culture.
    But there's no way, to steal your example, that we'd use one of my childhood paintings as the top image at Battle of Helm's Deep, or one of my depictions of Stryker no matter how fond or proud of it I was, no matter what kind of "artistic depiction" templates we slap on it, because if we need an example, we can grab a still from the film under fair use.
    On a side note, the use of images in that article is spot on. ᛗᛁᛟᛚᚾᛁᚱPants Tell me all about it. 22:30, 2 June 2021 (UTC)
    Nitpick: gules = red, or = yellow. Dhtwiki (talk) 05:20, 2 June 2021 (UTC)
  • I don't really have a problem with illustrating the statement "the flag of the fictional domain of Kusmaland is a red pterodactylus on a green background" with a user-created image of a red pterodactylus on a green background. Actually, I think this should be encouraged. It just needs to be made absolutely clear what is being shown, and no claim of "official" status of this artist's impression should be made without it appearing in other sources. Something like the flag gallery in The World of the Wheel is not appropriate without explicit sourcing. —Kusma (talk) 15:54, 1 June 2021 (UTC)

BLPPROD and Authority Control

Hello!

I ran into a couple unsourced BLP articles (i.e. Kev Hopper) and proposed them for deletion via Wikipedia:Proposed deletion of biographies of living people. I noticed that they had authority control templates, but that was it. The BLPPROD templates were later removed on the grounds that authority control counts as sources in the same way that external links would. While this reasoning makes sense, authority control is pulling links from Wikidata. The Wikipedia page source code only shows {authority control} and nothing else, so in my mind, the Wikipedia page itself contains no sources in any form. That's the disconnect for me.

Whether authority control makes BLPPROD ineligible or not, I think it should be explicitly specified in the policy to avoid this confusion again, such as "adding article contains no sources in any form (as references, external links, authority control identifiers, etc.)". Mbdfar (talk) 19:02, 2 June 2021 (UTC)

  • This is ridiculous, authority control is not a substitute for sources. In the case of the particular article you mentioned the "source" in the authority control is unreliable anyway (see WP:UGC). The BLPPROD template clearly states Once the article has at least one reliable source, you may remove this tag., yet it was removed even though there are no reliable sources anywhere in the article including the authority control template.--Rusf10 (talk) 19:07, 2 June 2021 (UTC)
To be fair, GB fan would have been in his right to remove the tag if authority control does count for sourcing. Per the policy, "to place a BLPPROD tag, the process requires that the article contains no sources in any form (as references, external links, etc.) which support any statements made about the person in the biography. Please note that this is a different criterion than the one used for sources added after the correct placement of the tag." So if the authority control does count for sourcing (no matter the reliability), I would have placed BLPPROD incorrectly as the page would have been ineligible. Mbdfar (talk) 19:14, 2 June 2021 (UTC)
  • 100% agreement with Rusf10 here. The authority control listed at Kev Hopper links back to a database of user generated content, and even if the content were editorially controlled, that would not in any way establish notability, as there's no bar for inclusion that roughly translates to GNG. ᛗᛁᛟᛚᚾᛁᚱPants Tell me all about it. 22:22, 2 June 2021 (UTC)
MPants at work, Rusf10; Right, but you guys are missing the point of this discussion. My apologies for being unclear. This is not an argument about subject notability, nor about the reliability of sources. This is about WP:BLPPROD. BLPPROD states that "to place a BLPPROD tag, the process requires that the article contains no sources in any form (as references, external links, etc., reliable or otherwise) " For example, BLPPROD is invalid on an article that has so much as a link to a tweet. My question is whether pre-existing authority control identifiers qualify as a source contained in the article. In other words, is an article BLPPROD eligible if it has a valid authority control identifier? The policy should be made clear. Mbdfar (talk) 22:32, 2 June 2021 (UTC)
No it isn't, because "To be eligible for a BLPPROD tag, the entry must be a biography of a living person and contain no sources in any form (as references, external links, etc., reliable or otherwise) supporting any statements made about the person in the biography". In the case of Kev Hopper, the AC link (which is to MusicBrainz) does not support any statement mde in the prose of the article. And even if it did, it's not a reliable source, which makes me wonder why we bother with it. Black Kite (talk) 22:38, 2 June 2021 (UTC)
Black Kite, if I may ask a follow-up question; If an AC link DOES support a statement made in the prose of the article, would you consider it a valid "source" (thus rendering the article BLPPROD ineligible)? Take the page Jorge Niosi for example. He has many identifiers that support his birthdate, nationality, and publications. Would you consider this page BLPPROD immune? Mbdfar (talk) 22:52, 2 June 2021 (UTC)
The AC link definitely does support material in the biography -- it verifies an item on his discography, and by having a discography, it verifies that he's a musician. Is it a reliable source? Probably not, but that is not (and should not be) a requirement for preventing BLPROD, which is meant to wipe the most blatant cases. If this concern about AC and BLPROD is something that arises frequently, then yes, it should be added explicitly to the BLPROD descriptor. If this is a rare case, then probably not worth the hassle. --Nat Gertler (talk) 23:03, 2 June 2021 (UTC)
The AC link verifies nothing because its NOT reliable. (WP:V is about using reliable sources) A source that is not reliable does not count. Otherwise, someone could just create an article and link to their own blog to circumvent BLPPROD.--Rusf10 (talk) 01:08, 3 June 2021 (UTC)
But BLPPROD does say reliable or otherwise, so someone could circumvent it that way. JoelleJay (talk) 02:39, 3 June 2021 (UTC)
A source that is not reliably absolutely counts for making the BLPROD illegitimate. Per WP:BLPROD, "The requirements can be summed up as: only add a BLPPROD if there are no sources in any form that support any statement made about the person in the article, but once (properly) placed, it can only be removed if a reliable source is added." If you want to change the core of BLPROD, that's a much larger discussion to have. --Nat Gertler (talk) 03:08, 3 June 2021 (UTC)
There are alternatives to get rid of pages with only unreliable sources such as speedy delete, prod, or AFD, so no need to be concerned about gaming the system. Unreliable sources need more examination to see if they are, so not great for fast deletion of articles based on that. Graeme Bartlett (talk) 03:56, 3 June 2021 (UTC)
Authority Control should be considered valid for external links, provided that (as far as we can tell, after the fact) the link in question was actually there when the tag was added. 147.161.12.57 (talk) 06:21, 3 June 2021 (UTC)
Mbdfar, I wholeheartedly concur with Black Kite's response to this comment. The AC template is not, and should not be considered a source. It is an index which allows one to find data on the subject, but it doesn't guarantee the existence or relevance of said data. ᛗᛁᛟᛚᚾᛁᚱPants Tell me all about it. 12:23, 3 June 2021 (UTC)
  • I would agree that the AC template, on its own, is not enough to prevent a PROD... however... it does link us to an index of potential sources that should be reviewed prior to a PROD (per WP:BEFORE). If it is likely that one of those potential sources could support information in the article, then don’t prod... go directly to AFD if you wish to question/challenge notability. Blueboar (talk) 12:41, 3 June 2021 (UTC)
The question is not is the AC template enough to prevent a PROD. The question concerns WP:BLPPROD. The BLPPROD policy says that any source, reliable or not, on the article that supports any information in the article makes it ineligible for BLPROD. If we have this scenario:
  1. We have a BLP.
  2. The BLP has {{authority control}} in its source code.
  3. In the authority control template that renders on the article there are link(s).
  4. In at least one of the links there is some piece of information that is also in the article.
Is this enough to make this BLP ineligible for BLPPROD? ~ GB fan 13:56, 3 June 2021 (UTC)
GB fan, I would say that depends entirely on whether or not the information in that link exists and meets our standards for reliability. In the example listed above, it clearly does not do the latter. If there's a case where it does... Well, I think that such cases should be discussed, which probably puts me on your side of things for those cases. In general though, the presence or absence of an authority control template on a page should not be a factor in dealing with BLPROD. ᛗᛁᛟᛚᚾᛁᚱPants Tell me all about it. 15:37, 3 June 2021 (UTC)
Exactly... Do due diligence BEFORE prodding. First check the potential sources linked through the AC template. If any of them could be cited in the article, then PROD is probably not appropriate. But if none are usable, then go ahead and prod (and mention that you checked AC and found no viable sources). Remember that PROD is for clear cut cases. If there is any doubt, don’t PROD. Blueboar (talk) 15:35, 3 June 2021 (UTC)
MPants at work: Why should an AC link be treated any differently than any other external link when it comes to BLPROD -- i.e., if it contains any of the information in the article, even if it's not reliable, then BLPROD is not allowed? If there's some reason, that would seem an exception that would have to be built into BLPROD, which it currently is not. --Nat Gertler (talk) 15:43, 3 June 2021 (UTC)
NatGertler, because there's no guarantee that it will contain any information at all, let alone any information that's in the article.Just because something's indexed in a database doesn't mean there's any data attached to that index. ᛗᛁᛟᛚᚾᛁᚱPants Tell me all about it. 15:49, 3 June 2021 (UTC)
MPants at work, so it sounds like we should treat it like any other external link. Merely having an external link doesn't void a BLPROD. "To be eligible for a BLPPROD tag, the entry must be a biography of a living person and contain no sources in any form (as references, external links, etc., reliable or otherwise) supporting any statements made about the person in the biography." An AC link that supports statements in the bio would seem to fit quite nicely into the "etc." in that, if not simply as an "external link". I'm still not seeing the "but not Authority Control" exception in this. --Nat Gertler (talk) 16:09, 3 June 2021 (UTC)
  • snicker* good luck with that. The wikidata crowd dont want it treated as an external link because then it would be subject to WP:EL and its content being removed in many cases. The solution to this is to alter BLPPROD to allow BLPRODing of articles that do not contain references/sources. External links or templates are not a consideration if something can be prodded based on the sourcing, because they are not sources or references. Just remove the wording that is causing this. Only in death does duty end (talk) 16:17, 3 June 2021 (UTC)
the "but not Authority Control" exception for me (which lead me to starting this discussion) is that the AC links are hosted on Wikidata, not Wikipedia. The links on Wikidata can be changed or removed without leaving a changelog on Wikipedia. I think this is important in a BLP context. The Wikipedia page itself hosts no external links or sources, which lead me to interpreting BLPPROD this way. Mbdfar (talk) 16:24, 3 June 2021 (UTC)
I don't think the distinction of whether data/link content is stored on Wikidata or on Wikipedia is particularly useful to make. We use images from Commons in our articles all the time although that means we don't have local control over changes. In the case at hand, had someone turned the AC template into a MusicBrainz link would not have made the situation any better, or any worse. —Kusma (talk) 18:52, 3 June 2021 (UTC)
  • NatGertler, Merely having an external link doesn't void a BLPROD. I agree, and believe that merely having an AC template should not void a BLPROD.

An AC link that supports statements in the bio would seem to fit quite nicely into the "etc." in that, if not simply as an "external link". Yes, hence why I said above that it's worth discussing in those cases. I agree with Blueboar that checking the AC links should be normal due diligence for BLPRODing an article. I also assert that double-checking the AC links should be part of the normal due diligence for removing a BLPROD. Finally, I also agree with Only in death below that external links should not be included in the criteria at WP:BLPROD. There should be actual sources to void it, not simply external links. ᛗᛁᛟᛚᚾᛁᚱPants Tell me all about it. 16:26, 3 June 2021 (UTC)

  • As I understand it, BLPPROD uses bright line rules. The Musicbrainz link was present in the article (doesn't matter whether through AC or directly), so the article wasn't a BLPPROD candidate. However, the link doesn't verify anything useful, and I can't find sources that support much other than #REDIRECT [[Stump (band)]]. I would support strengthening BLPPROD to require presence of a reliable source/a reliable xlink before use, that would make adding and removing the BLPPROD follow the same rules. —Kusma (talk) 15:53, 3 June 2021 (UTC)
    Are there any serious objections to redirecting? We still have this unsourced BLP to take care of... —Kusma (talk) 18:54, 3 June 2021 (UTC)
If only we had a clear cut policy to take care of unsourced BLPs ;)
Jk, I think a redirect is rational. Mbdfar (talk) 04:06, 4 June 2021 (UTC)

The current version of WP:BLPPROD is, if there is any source in the article, whether it is reliable or not, and that source supports any statement in the article, the article can not be BLPPROD'd. So an external link to the BLP's personal self published website that supports some statement in the article makes the article ineligible for BLPPROD. Going back to the article that was mentioned in the first post in this section, Kev Hopper. It has an authority control template with one link. That link goes to musicbrainz.org. The musicbrainz page says that Kev Hopper released an album called Stolen Jewels in 1990. The first entry in the list of Solo albums in the Kev Hopper article says that he released Stolen Jewels in 1990. So we have an external link that supports information in the article. Under the current version of BLPPROD, is this eligible for a BLPPROD? ~ GB fan 17:51, 3 June 2021 (UTC)

  • Not eligible. —Kusma (talk) 18:04, 3 June 2021 (UTC)
Ignoring for the moment, the unreliability of that database, I don't think the name & release year of an album really rises to the level of being considered a source here, else one could just as validly point to the article's name as being sourced to the AC link. I'd want to see some substantial facts in the AC link, not just a single datum that does nothing to really tell us anything about the subject. ᛗᛁᛟᛚᚾᛁᚱPants Tell me all about it. 18:22, 3 June 2021 (UTC)
  • If you determine that a subject is not notable then just use a different procedure to propose/nominate it for deletion. The BLPPROD procedure is simply something that was introduced in the midst of a moral panic when some disruptive editors, egged on by Jimmy Wales, thought that it was more urgent to delete unsourced articles that said "Joe Bloggs is a footballer who plays for Anytown United" than to delete genuine BLP violations, which often cite loads of sources. Please let's think about things, rather than blindly follow procedures. I'm still convinced that the difference between what is valid for placing a BLPPROD tag and what is valid for removing it was a simple accident of wording caused by the rush to put something in place, rather than the philosphical talking point beloved of Wikilawyers that it seems to have become. Phil Bridger (talk) 18:56, 3 June 2021 (UTC)

Proposal to adjust the policy wording to include "authority control"

I propose that we update the policy to read To be eligible for a BLPPROD tag, the entry must be a biography of a living person and contain no sources in any form (as references, external links, authority control links, etc., reliable or otherwise)Novem Linguae (talk) 03:45, 4 June 2021 (UTC)

  • Support as proposer. I've had one of my BLP prods declined for this before, and it was not intuitive to me. I think it needs to be explicitly stated. I don't have an opinion on whether authority control should count or not, I just want to make sure that if this is the de facto standard, that it is stated clearly in the policy. –Novem Linguae (talk) 03:45, 4 June 2021 (UTC)
  • Support, seems I've made a mountain out of a molehill, huh? I echo everything stated above. Mbdfar (talk) 03:51, 4 June 2021 (UTC)
  • There are good arguments above for this. Namely that BLPPROD is a special circumstance, PROD is still available, and authority control does imply potential. That said, what about just a link to a google search for the subject's name? The idea of a "source" implies to me that it could in some way have been intended as a source for the text of the article. That is, it was added to support material in the article, even if it happened to be added as an external link, etc. That seems unlikely for authority control... — Rhododendrites talk \\ 04:49, 4 June 2021 (UTC)
    Thanks for your comment. The policy currently states "sources in any form, reliable or otherwise". Seems to me like any source or link invalidates the use of BLPPROD. If we wanted to discuss making the application of BLPPROD broader (having some links be "so bad" that they don't count as links, essentially), maybe we could start a second proposal. I have some opinions on this, but I'd prefer to discuss them in a different section, since at its heart it is a different proposal. –Novem Linguae (talk) 05:09, 4 June 2021 (UTC)
    I'm not so sure "sources" applies to absolutely any link on the page. Again, what about just a link to a google search? It makes more sense to interpret this as "if someone used a source but only included it as an external link rather than a citation, that's still a source" rather than "any link=source". — Rhododendrites talk \\ 15:07, 4 June 2021 (UTC)
  • Support only if a strengthening of BLPPROD does not pass. This proposal is a useful clarification that may save us pointless discussion in the future, but "BLPs must have a reliable source or be eligible for BLPPROD" might be a better approach overall. —Kusma (talk) 10:03, 4 June 2021 (UTC)
  • Support Makes sense. Perhaps have authority control in between 'references' and 'external links'? Thanks. Mike Peel (talk) 10:12, 4 June 2021 (UTC)
    People !voting below seem to ignore the fact that AC provides a demonstration of notability (the example given isn't a good one, since MusicBrainz often isn't seen as a reliable source - but, say, the British Library?), and that the policy already includes 'external links' not only references/citations. Mike Peel (talk) 16:34, 12 June 2021 (UTC)
    The problem is exactly that, that authority control links include random databases like MusicBrainz (quite why anyone would want to link to a database written by people who are doubly illiterate, in that they both don't know how to separate words and can't spell, is beyond me) as well as very reliable links like the British Library. I had always thought that authority control was about verifying that sources were about the same subject, but that goal seems to have been subverted on Wikipedia into being about any database that refers to a particular name, whether that is the same subject or not, and whether the database is in any way reliable or not. Phil Bridger (talk) 19:50, 12 June 2021 (UTC)
  • Oppose - A database of potential sources is not itself a viable source. The sources linked through AC may or may not invalidate a BLPPROD... but we don’t know without checking them before Prodding. I would also remove the “or otherwise” in the parenthetical - but that may require a second RFC. Blueboar (talk) 11:42, 4 June 2021 (UTC)
  • Oppose An authority control link is not a source. The language regarding external links is quite clearly to permit sourcing that's not properly cited, a common mistake by new editors. But any editor capableof implementing an AC template with the link, is capable of making proper cites. Given that an AC link doesn't guarantee to contain any info beyond the name of a subject... There's no reason to treat it like a source. ᛗᛁᛟᛚᚾᛁᚱPants Tell me all about it. 15:45, 4 June 2021 (UTC)
We can not even assume that the AC template was added by a human editor. It might have been added by bot, with no one checking to see if any of the potential sources are actually viable. Blueboar (talk) 10:28, 5 June 2021 (UTC)
Damn good point, this. ᛗᛁᛟᛚᚾᛁᚱPants Tell me all about it. 19:03, 9 June 2021 (UTC)
  • Oppose Authority Control in some cases (including the one above) does not even use reliable sources. If anything we need to improve the quality of sources being used for BLPs.--Rusf10 (talk) 01:25, 5 June 2021 (UTC)
  • Oppose - authority control is not a reliable source. Levivich 15:04, 5 June 2021 (UTC)
    NOTE that BLPPROD does not (currently) require sources to be reliable to negate the PROD. Even the presence of unreliable sources can do so. (We can change that requirement if we want to, but that is a different question from what is being asked).
    The more fundamental problem is that Authority Control isn’t a source, but merely a generated list of databases in which potential sources might (or might not) be found. Blueboar (talk) 15:20, 5 June 2021 (UTC)
    Good point, thanks. I updated my !vote. Levivich 21:11, 5 June 2021 (UTC)
  • Oppose I think the wording's confusing about what constitutes a "source." An authority control is not a source. It could be a source, but it would need to support content in the article. We include "external link" because we have several different ways of referencing which new editors may be unfamiliar with, and may use direct links as a source - those words exist to not punish those users. SportingFlyer T·C 21:26, 5 June 2021 (UTC)
  • Oppose – a source, by definition, is something that the author relied upon in writing the article. Authority control, by definition, is a navigation tool. That's really all there is to it. Authority control templates are means by which someone could hypothetically find reliable sources in the future. They are not sources in and of themselves, any more than {{BLP unsourced}} is a source because it contains links to search engines that might hypothetically find reliable sources. Extraordinary Writ (talk) 22:01, 5 June 2021 (UTC)
  • Oppose AC is a link to potential sources, it is not a source itself and does not satisfy sourcing requirements for articles. — xaosflux Talk 18:51, 9 June 2021 (UTC)
  • Oppose AC is basically WP:ITEXISTS. It's not a source and cannot be used to support any form of content in an article, thus if a BLP article only has an AC template somewhere then it still is unsourced since the provided "source" is not actually supporting any of the material in the article. RandomCanadian (talk / contribs) 16:04, 12 June 2021 (UTC)
  • Oppose changing the wording because sometimes AC links verify information in the entry and other times they don’t, as discussed at length above. And for what it’s worth, if they do verify info (even unreliably), to me that’s a source that renders the entry ineligible for BLPPROD. But this morass is a great example of why I would support WP:TNT for the whole process. Innisfree987 (talk) 02:13, 13 June 2021 (UTC)

POV with admitted lack of knowledge on the matter ?

Hello, I witnessed a WP:TAGTEAMed administrator both warning an user of possible block and acknowledging he/she did not reviewed the relevant conflict/edits/discussion. Is there a WP:RULES that administrator or user cannot take consequential actions if they have no knowledge of the said matter ? I would like to know such rule to cite it. Yug (talk) 11:24, 3 June 2021 (UTC)

Better to ask this at WP:AN, but you should maybe link the relevant discussion so people can understand the context and advise accordingly, and also judge whether your summary is a fair representation of the events. ProcrastinatingReader (talk) 11:28, 3 June 2021 (UTC)
My idea was to cite that WP:Rule if it exist when I will message WP:AN. I already bumped into the concept of "flyover" editors/administrators for users who jump in, drop an opinion without understanding of the situation, then leave, but I can't find the page if any. Yug (talk) 12:24, 3 June 2021 (UTC)
I don’t think there is any “rule” (for or against). A lot depends on WHY the admins in question “jumped in”. Blueboar (talk) 12:50, 3 June 2021 (UTC)
The closest that I can think of is WP: ADMINACCT, where admins are supposed to be able to explain and justify their actions as admins. --Kyohyi (talk) 13:07, 3 June 2021 (UTC)

Notice of RfC on how usernames should be displayed in custom signatures

See Wikipedia talk:Signatures#RfC: usernames in signaturesRhododendrites talk \\ 01:11, 4 June 2021 (UTC)

Welcome over warning

Hello, How about having a new policy for experienced Wikipedians in relation to WP:Don't Bite Newcomers that promotes sending "Welcome" over "warning"? A number of unconstructive edits by anonymous users don't happen to be pure Vandalism. They are either mistakes or test edits. Sometimes due to the lack of the knowledge of Wikipedia, they err the formatting. We have rollbacking tools like Redwarn that just warn those users. Whereas, the Welcome template has more helpful links for them to better understand Wikipedia and make constructive edits to Wikipedia. This way, we can retain more happy newcomers. P.S.- This need not be exercised for those who truly vandalize Wikipedia. They better be warned than getting a Welcome. Lightbluerain (Talk | contribs) 02:56, 5 June 2021 (UTC)

That is a good idea. I always use {{Subst:Welcome to Wikipedia}} due to its pleasant and yet comprehensive content. VV 06:21, 5 June 2021 (UTC)
  • It depends on WHY you are warning the new user. Some behaviors are so unacceptable and egregious that they should be slapped down (hard)… no matter who the editor is. Blueboar (talk) 15:30, 5 June 2021 (UTC)
    Certainly that is the case in some situations. But lets not have that get in the way of the broader discussion on being more welcoming to new editors in general. I agree that a little too often we are more likely to slap on a warning template rather than something a little more helpful and welcoming. PackMecEng (talk) 15:37, 5 June 2021 (UTC)
I agree we have such users but not all are as I wrote in my post as well. Lightbluerain (Talk | contribs) 06:00, 6 June 2021 (UTC)
Although I am sure that mistakes happen and I know from experience that some new editors are too quick to issue a vandalism warnings, and that tools like Redwarn perhaps make it too easy to issue such warnings, I would want to see data about how frequent such errors are overall. In my experience, it is pretty easy in most cases to distinguish between good faith newbie bungling and malicious intent. I strongly favor welcoming and assisting the honest newbies, and I also favor ousting malicious people promptly. Convincing evidence of a widespread problem that cannot be controlled by existing mechanisms should be required to implement a policy change. Cullen328 Let's discuss it 05:10, 8 June 2021 (UTC)
Cullen328, How to collect the data? I have no idea for this. Lightbluerain (Talk | contribs) 03:34, 9 June 2021 (UTC)
Lightbluerain, my personal skills are not in data collection on Wikipedia, but I will evaluate the data that editors with such skills collect. Cullen328 Let's discuss it 05:07, 9 June 2021 (UTC)
Alright. Lightbluerain (Talk | contribs) 10:06, 9 June 2021 (UTC)
Oppose. The level one warnings have a pretty nice and welcoming tone if you read their texts from the perspective of a newcomer, and that is intentional. They also have the advantage of being brief and readable, with concise and specific instructions that newcomers can immediately implement. In my view, this is actually more helpful to newcomers than a generic welcome message which doesn't address the problem with their contributions. JBchrch talk 11:16, 11 June 2021 (UTC)
JBchrch, we have welcome templates on twinkle that addresses some of the problematic edits. I agree the level one warning templates have welcoming tones. The welcome templates addressing problematic edits have more helpful links than the warning one along with an encouraging edit summary. I use both of them considering the conditions I specified in my post. Lightbluerain (Talk | contribs) 06:25, 12 June 2021 (UTC)

Wikiquote

Hello, my question is about the link to Wikiquote found at the bottom of some WP articles. In my opinion, the quotations inserted in WQ are often an important complement to the WP page, for example when WP talks about the thought of an author and WQ illustrates it with the author's own words. However, the link to WQ is located at the bottom of the WP page with other external links and I am sure that it goes unnoticed by the vast majority of readers who might be interested in such quotes. To remedy this lack of visibility, is one allowed to insert the link to WQ in one of the sections dealing with the author's thoughts? In the French WP it is tolerated. Regards,--Hamza Alaoui (talk) 14:53, 5 June 2021 (UTC)

In general, I think bottom of article is reasonable, since WQ is WP:USERG and shouldn't be given more "attention" than external links. I may be pessimistic, but I find it probable that a WQ entry could have serious cherry-picking problems from some sort of POV. I've never edited WQ, so I don't know how "good" it is. Gråbergs Gråa Sång (talk) 08:13, 6 June 2021 (UTC)
I agree with Hamza Alaoui, it is almost impossible to find the link to Wikiquote in the articles. Can't something be done to improve this? --Mhorg (talk) 11:29, 11 June 2021 (UTC)

Reverting a revert

The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion. A summary of the conclusions reached follows.
Rejected per snowball clause  . The proposal has been withdrawn by HAL333. (non-admin closure) Sdrqaz (talk) 10:26, 8 June 2021 (UTC)

The following scenario is frustratingly common: An editor changes the longstanding status quo with an edit. You revert the edit and encourage them to discuss on the talk page. They then revert that revert. There should be repercussions for this disregard of civil discussion through the BOLD, revert, discuss cycle. I propose that the following becomes policy:

If a user's edit that changes the status quo is reverted, a revert of that revert will result in a talk page warning. A second revert of such a revert begets a 24 hour block.

This would not apply to an edit originally removing some gross violation of Wikipedia policy, such as a BLP vio. And, 3RR would still stand, as the 3 reverts do not necessarily have to be over the exact same issue. ~ HAL333 18:36, 6 June 2021 (UTC)

  • Support as nom It would encourage discussion and help stifle edit warring before it heats up. ~ HAL333 18:46, 6 June 2021 (UTC)
  • Comment – let's clarify this because the wording is a bit confusing. User1 makes a WP:BOLD edit, User2 reverts to WP:STATUSQUO and encourages talk page discussion. User1 reinstates the edit, gets a talk page warning. User2 reverts it again to the STATUSQUO. User1 again reinstates the edit, gets blocked. Is that what you're proposing, HAL333? —El Millo (talk) 18:50, 6 June 2021 (UTC)
    Facu-el Millo, Yes. Sorry for any confusion. ~ HAL333 19:04, 6 June 2021 (UTC)
  • Support, no contested edit should be allowed to remain before the issue is settled just because of the editor's persistence. —El Millo (talk) 23:50, 6 June 2021 (UTC)
    • Strike my support based on other comments below. I second Number57's opinion: The issue for me is more with 3RR giving an advantage to the editor going against the status quo. IMO this should be amended to allow an editor one free revert to restore the status quo. —El Millo (talk) 17:22, 7 June 2021 (UTC)
  • Oppose. People aren't born with knowledge of how Wikipedia works. A warning for making the same edit twice? And a block on the second offense. Maybe they thought their edit didn't save. Or maybe they're really right and the "status quo" is wrong, but they don't yet know about WP:CITE, WP:V, WP:BRD, WP:OMGWTFBBQ, etc. Or they didn't see the warning. Or the first person to revert them was carelessly pushing buttons. Or they're an busy or elderly expert in their field, and just don't have the time or patience to learn our petty little rules. Or they're a kid, trying their best. A block on the second offense would be spectacularly heavy-handed. Give people time to learn how this place works.
    And, I'd like to see "status quo" defined in a way where all the tricky edge cases don't just work out to "version preferred by the editor with the higher edit count" in practice. Suffusion of Yellow (talk) 00:53, 7 June 2021 (UTC)
    Suffusion of Yellow Valid point - we shouldn't bite the newcomers. How about three such warning templates for IP, new, and autoconfirmed editors and only one for those who are extended confirmed? ~ HAL333 04:10, 7 June 2021 (UTC)
    I really don't think it's possible to write a message that is both non-bitey and makes it clear the editor will be blocked on the very next edit. Suffusion of Yellow (talk) 20:21, 7 June 2021 (UTC)
  • Comment I think we would have to clearly define at what point something becomes WP:STATUSQUO. Is it WP:STATUSQUO after being in the article a day, a week, a month, a year, etc? Regards  Spy-cicle💥  Talk? 01:02, 7 June 2021 (UTC)
How about 15 days or anything present in an article after going through a GAN or FAC? It wouldn't be fair to give February and July equal treatment. ~ HAL333 04:13, 7 June 2021 (UTC)
15 days seems okay though I feel we may have to adjust on context (i.e. low traffic article has a higher wait time for status quo). Probably on FAC maybe on GAN, but I suppose we would also have to adjust WP:ONUS. It can be tricky to formulate the best way to propose it but I do certainly understand the frustration. I remember rewriting an article, I submitted to GAN, it got completely rewritten by another editor, I reverted it back to the status quo, back and forth and then another editor reverted it back to the new version forcing it off the status quo, then a different editor failed my GAN due to edit warring. Easier just to work on lower traffic articles...  Spy-cicle💥  Talk? 07:02, 8 June 2021 (UTC)
  • [ec] Comment, There is nothing special about status quo per se. Do not mistake it for consensus as a result of reasoned discussion and evidence. A lot of status quo is the consequence of no-one getting round to making an improvement yet. · · · Peter Southwood (talk): 04:16, 7 June 2021 (UTC)
  • Oppose as currently expressed. Too vague, with loopholes for misuse. · · · Peter Southwood (talk): 04:25, 7 June 2021 (UTC)
  • Oppose. This needs to be added to WP:PERENNIAL. Making WP:BRD a guideline or policy instead of an essay has been proposed many times, and failed every time. If someone insists on engaging in editwarring, use WP:ANEW if it breaches WP:3RR. If it's more a long-term pattern of evading 3RR but editwarring a lot anyway, try WP:ANI as more likely to produce a restraint.  — SMcCandlish ¢ 😼  10:14, 7 June 2021 (UTC)
  • Oppose BRD is worth trying to follow but it isn't always possible or even desirable. There are enough ways to deal with this situation already.Selfstudier (talk) 10:29, 7 June 2021 (UTC)
  • Oppose. There are many situations where such a bright-line rule would lead to perverse outcomes, such as when a spelling mistake is corrected that nobody has noticed for years. Are we really saying that someone who reinstates a reverted correction should be warned and then blocked, even if the correction is obviously correct? As so often, this is an area where human judgement is needed rather than adherence to strict rules. Phil Bridger (talk) 10:33, 7 June 2021 (UTC)
  • I completely agree with the issue presented, but I can't agree with this implementation given concerns raised by Phil Bridger, among others. I agree we should use common sense more when it comes to edit warring. Elli (talk | contribs) 14:42, 7 June 2021 (UTC)
  • Support in principle but oppose as currently written. "Do not repeat an edit without consensus" is what our rule should be (it would be an effective sitewide 1RR, which I would support, and is basically what is being proposed, but I quibble on the propose wording). Levivich 14:48, 7 June 2021 (UTC)
    As I understand it, WP:1RR allows the original editor to make one revert, whereas this proposal is explicitly prohibiting this. It's really making the bold, revert, discuss cycle mandatory. isaacl (talk) 20:13, 7 June 2021 (UTC)
  • Oppose There are several situations where a revert of a revert is perfectly acceptable – for instance, the outcome of a discussion being implemented and the original reverter being unaware of this outcome, or reverting a knee-jerk blind revert that was not done in good faith. The issue for me is more with 3RR giving an advantage to the editor going against the status quo. IMO this should be amended to allow an editor one free revert to restore the status quo. Number 57 15:10, 7 June 2021 (UTC)
    I totally agree with you on 3RR. ~ HAL333 16:33, 7 June 2021 (UTC)
  • Oppose and personally I like how 3RR advantages an editor going against the status quo. It forces people making a revert to find at least once other person to agree with them which proves consensus. Chess (talk) (please use {{reply to|Chess}} on reply) 19:47, 7 June 2021 (UTC)
    The problem is that conflicts with WP:CONSENSUS. Per NOCON (part of consensus) the change shouldn't be made unless there is a consensus to change it. Often edit wars occur because editors trying to make a change haven't shown consensus but they have enough reverts on their side to be the last revert standing. So long as CONSENSUS is policy our behavioral rules should push in that direction. Springee (talk) 21:28, 7 June 2021 (UTC)
  • As much as I think the bold, revert, discuss cycle is a good approach whose level of community support makes it close to a policy, I feel making it mandatory might be too inflexible for all situations. I think it could also exacerbate article ownership issues, by making it easy to turn every update into a protracted discussion. isaacl (talk) 20:24, 7 June 2021 (UTC)
  • Oppose as stated but... I strongly support the concern here. Far to often I've see a poor quality edit added to a page, it gets reverted (back to status quo) then the person who added it or even another editor restores the disputed content. A flaw of 1RR or 3RR is any time both editors use up their "edit limit" the result is the change stays vs is reverted. I would rather see something included in the 1RR rules that say, 1RR, mandatory BRD if a new edit is challenged. This would allow an editor to make several new edits to a page, even if one of those edits is reverted, without hitting the 1RR limit. However, if any edit is challenged they cannot restore it without talk page consensus first. Number 57's "one free revert" might work as well but reducing the number of reverts is probably better than increasing the number. Either way, it is a problem that the current system inadvertently favors a change vs status quo. Springee (talk) 21:24, 7 June 2021 (UTC)
    • An alternative might be to turn 3RR into a three edit rule – i.e. an editor cannot make the same edit more than three times within a 24 hour period. This would take away the advantage the editor going against the status quo has. Number 57
  • Comment from nominator Well this looks like a WP:SNOWCLOSE. But as suggested by multiple editors above, I'll propose a (more thought-out) change to 3RR in a few days. Cheers. ~ HAL333 21:29, 7 June 2021 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Am I canvassing?

Hi, a user just made this comment.[1] Am I doing something wrong? I don't think I'm canvassing... I am exposing in this discussion[2] with a user encountered in an AE request, all the events that I consider unfair about another user. If so, I'll stop now. Thank you.--Mhorg (talk) 18:57, 6 June 2021 (UTC)

  Comment: This seems like it should be brought up at WP:ANI, instead of here. 2601:1C0:4401:24A0:6463:127E:E490:C360 (talk) 16:30, 11 June 2021 (UTC)

Airport destination lists

I don't need to cite specific examples, just look up any article about a reasonably sized airport and you'll find an #Airlines_and_destinations section. I don't know if there's an explicit consensus for this (or, if there is, if it's a WP:LOCALCONSENSUS), but they seem to be blatant and obvious examples of WP:NOT (both because we're not a travel guide and because we're not an indiscriminate collection of information), in addition to being high-maintenance stuff. Would there be any objection to me starting an RfC (here) to get explicit consensus for their removal? RandomCanadian (talk / contribs) 01:52, 11 June 2021 (UTC)

It appears to be part of the standard Wikipedia:WikiProject Airports/page content layout. Make sure you are clear in your RfC whether you are only talking about the destinations vs the whole airlines list also. DMacks (talk) 02:01, 11 June 2021 (UTC)
So LOCALCONSENSUS, as I was saying? RandomCanadian (talk / contribs) 02:24, 11 June 2021 (UTC)
Not everything you didn't get a chance to vote on is a violation of "local consensus" and not every bit of text that appears at Wikipedia requires pre-approval by the entire community. Where the community has decided some principle, local consensus should not override it, but the community has not decided this issue in any meaningful way, and no one is doing anything wrong here. --Jayron32 14:40, 11 June 2021 (UTC)
It definitely feels like something to see if the project's standards are inconsistent with the overall en.wiki expectations. An RFC would be appropriate but you definitely need to make sure the Airports wikiproject is informed about it. --Masem (t) 02:31, 11 June 2021 (UTC)
On the other hand, we list all the stations train stations directly service, why not airports? --Golbez (talk) 04:01, 11 June 2021 (UTC)
Trains really cannot reroute as freely as airplanes, in which there that's all up to what airlines decide to do for the most part. There are reasons to consider, particularly for smaller regional/municipal airports, to say that they generally serve to provide connecting flights to a major airport hub, but this reasoning doesn't make sense for the large scale airports. --Masem (t) 04:14, 11 June 2021 (UTC)
New routes opening and closing does get mentioned in the media. People seem to maintain them. Kind of the only reason I can see to remove them is that Wikipedia is the best place on the internet for this information. Which isn't such a great reason to destroy this useful resource. —Kusma (talk) 05:51, 11 June 2021 (UTC)
For a slightly more encyclopaedic reasoning, something like the destination list is necessary to understand what kind of airport a given airport is. From a European perspective, for example it is a characterising feature whether an airport has domestic flights or not. Nuremberg Airport is reasonably usefully connected to hubs and business destinations (plus holidays), while Dortmund Airport serves holidays and flights home for Eastern Europeans working in Germany. You can read this off from the destination list without having to make a judgement in the article whether you consider flights to Barcelona and Paris to be business or leisure flights. If you explain the character of the destination list in prose, you still have to give some examples, and then going for the full list isn't very far away. —Kusma (talk) 06:34, 11 June 2021 (UTC)
There's no reason what type of airport cannot be described in text using terms-of-art words for describing the airports. Eg: as I mentioned, a small regional airport likely only has flights to two or three major hubs so that can be briefly mentioned. But I would not list all the possible destinations for a major hub like JFK or LAX. Instead, something like "Atlanta International Airport is one of Delta's main hubs in the United States, serving its domestic routes and international travel to Europe, Central and South America." That future proofs the article from any changes that may happen to Delta's flightplans. --Masem (t) 15:02, 11 June 2021 (UTC)
That would be an issue if the destination tables weren't regularly updated. Look at any airport, I just spot-checked Heathrow: we have lots of airport editors who gnome specifically to keep the information up-to-date. Some don't make any other edits. SportingFlyer T·C 22:45, 11 June 2021 (UTC)
A typical small regional airport in Germany, on the other hand, has zero connections to major national hubs. From Erfurt–Weimar Airport, you can't fly to Frankfurt or Munich. Airports are very different in countries with functioning rail networks and countries without. Future-proofing could work well using "as of" and by hiding the lists should they become out of date. In practice, airport destination lists have been well maintained, unlike, say, electoral constituencies, which are commonly ten years old and outdated by two elections. —Kusma (talk) 16:10, 12 June 2021 (UTC)
  • This comes up every so often, and is in my mind quite misguided. The tables have been kept up to date, and the destinations an airport serves receive quite a bit of media coverage. Furthermore, WP:NOTTRAVEL doesn't really apply here - as with train stations, a list of destinations gives an idea of the connectivity of a certain airport. I've often used Wikipedia as a reliable source to look at how places connect to other places. The airliner world often has to deal with poor WP:NOTTRAVEL arguments since it's transportation related - this may be a bit antiquated of an analogy now, but it's clear a table of airlines operating from the airport with the airline's phone number or web site without any destinations would be a NOTTRAVEL violation. A list of destinations has encyclopaedic value, and I'd be a strong oppose at any RfC. SportingFlyer T·C 09:50, 11 June 2021 (UTC)
    • This appears to be the most recent RfC on the matter. SportingFlyer T·C 09:54, 11 June 2021 (UTC)
    • Here is another RfC in a central location that clarified that transportation lists are fine. —Kusma (talk) 10:16, 11 June 2021 (UTC)
      • The first RfC was held at the page of the relevant wikiproject, likely attracted relatively low participation from outside editors, and was 5 years ago. The second RfC is about list articles, not about this specific example, so I'm not sure its particularly relevant. The only reason to keep them is because they're already there (AFAICS) - i.e., an appeal to tradition and a sunk cost fallacy. This comment also seems to highlight issues of BIAS which I hadn't thought of so far. A prose description of the main destinations served by airlines operating from an airport would have much more encyclopedic value than a WP:NOTDIR listing of all of them with barely any annotations, and most often only based on routine coverage/primary sources if at all significant. The tables can go at Wikitravel, it you want, really, but it is rather clear that they're not encyclopedic here as they stand. As has been said, I think by Drmies (IIRC) or someone else, lists (as opposed to actual prose) are often excuses for crap articles, or in this case I'd say for a not particularly helpful part of an article. Option 1 of the relevant RfC seems to really be the only policy-justifiable one: Wikipedia articles should be a "summary of knowledge" (as fit for an encyclopedia), not a listing of all of it. WP:NOTNEWS would also apply, since the route changes only get routine, non-significant coverage. RandomCanadian (talk / contribs) 14:03, 11 June 2021 (UTC)
        • In the specific example of Dortmund Airport, the destinations sections adds detail to what is written in the History section. It illustrates the article, just like the images do. An "as of" is missing, just like the images should clarify whether they are historic images or current images. I'd like to see the lists more in a historical context than always up-to-date (1940s and 1950s Shannon Airport destinations are probably more exciting than the current list) but I really don't get how Wikipedia gets better if the level of detail provided in these lists is explicitly outlawed. Would you also like to remove the current route from London Buses route 406 or is that ok because it doesn't list all of the stops, but makes a selection with unknown criteria and possibly bias? —Kusma (talk) 14:37, 11 June 2021 (UTC)
          • What does the destination section add that is not already in the history section (ignoring that the history section itself looks like OR, since no sources are cited)? It just gives an unannotated listing of every destination served. Doesn't highlight the fact the airport is mostly served by low-cost airlines, nor does it tell anything about overall flight frequency or which airports are most frequently served... I don't see why you're deflecting to bus routes: these, like trains, aren't quite as prone to frequent changes as airports, and as we can see the route and its destinations/trajectory and proposed changes thereto gets enough coverage that some encyclopedic prose can be written about it. And yes, partial lists which only highlight the overall route (the links are to London neighbourhoods which the route passes through, not to particular stops) and interchange points with other transit (an objective criteria, easy to assess) are much less problematic then ones which would give every single stop (compare what's in the article with https://tfl.gov.uk/bus/route/406/ ) - that's what the equivalent of listing every airport served is for a bus route. "1940s and 1950s Shannon Airport destinations are probably more exciting than the current list": probably, but that would likely be WP:OR if you can't find secondary sources which report on the significance of these routes (for ex. "Shannon Airport was an important stop-over point for transatlantic flights, bla bla so on so forth...[sources]"). If the only sources are WP:PRIMARY (a directory-like listing of routes), then it likely isn't encyclopedic information. RandomCanadian (talk / contribs) 15:10, 11 June 2021 (UTC)
            • I like the analogy to images illustrating the text - listing the destinations rather than calling something a "small, regional airport" is a way of showing rather than telling. Perhaps adding clickable maps to the articles would perhaps be even better, but that is likely a bigger maintenance burden. CapitalSasha ~ talk 16:05, 11 June 2021 (UTC)
              • Illustratively, at least for smaller airports (not major hubs) which have only a handful of inbound/outbound routes, you could easily make a map to show these as means of illustration without the need for a table. I would not also be suprirsed that for the major world hubs, LAX, JFX, SFO, etc. that you can find RSes that document the principle routes in and out of these cities and use that illustratively (eg showing like LAX connects to several main western Asian airports as well as Hawaii, in addition to its cross-US flights). I fully appreciate the need to point out, relatively, where these airports sit in a larger scheme of airport networks, that to me is encyclopedic and something if could be visually illustrated, would be good, but full route info (subject to short-term changes) is beyond WP scope. --Masem (t) 20:58, 11 June 2021 (UTC)
            Oh, I'm sure there are secondary sources for that. Most transport geek stuff is well documented. My personal transport geek phase was more than 30 years ago, so I won't go and fix any of these articles. I'd suggest you go to WT:AIRPORTS to discuss how airport articles can be improved by adding context to these lists, and by concentrating perhaps more on the text than the data. —Kusma (talk) 17:03, 11 June 2021 (UTC)
              • I'm relying on memory for this, but Wikitravel doesn't want the tables, since they're not really useful for a travel guide. (To be fair, I also don't understand the bus route argument.) I also don't think it's obvious at all they're not encyclopaedic, and that's ultimately what an RfC will be decided on, since there's not a clear policy answer here. We're probably also coming at this from completely different perspectives - I have a bunch of old books from the pre-internet days on airlines, aircraft, and airports, et cetera. Destinations and routes come up prominently, and I would expect a list of airlines operating to the airport at a bare minimum. SportingFlyer T·C 20:28, 11 June 2021 (UTC)
  • Based on the above, and the sentiment I expressed, there seems to be some potential improvement, and at least a plausible chance of agreement, that replacing this with prose descriptions would be an improvement while still keeping the most important information about the airport's status and destinations in it. RandomCanadian (talk / contribs) 02:30, 12 June 2021 (UTC)
  • Feel free to come up with a better question if you can. I didn't expect the reaction to the below. @Kusma: re. 1911 Britannica: example, please? Link to the Wikisource entry for convenience. RandomCanadian (talk / contribs) 16:10, 12 June 2021 (UTC)
    @RandomCanadian, s:1911 Encyclopædia Britannica/Liverpool tells us the American ports the city is connected to by steamer. They consider this information worth including although it could change before their next edition. —Kusma (talk) 16:22, 12 June 2021 (UTC)
    @Kusma: The commerce of Liverpool extends to every part of the world, but probably the intercourse with North America stands pre-eminent, there being lines of steamers to New York, Philadelphia, Boston, Baltimore, Galveston, New Orleans and the Canadian ports. That's a one sentence mention, and it clearly isn't exhaustive, unlike the tables we have here. This would be equivalent of taking the example that was given earlier (Dortmund Airport) and saying stuff like "Dortmund is connected to most major European cities, such as Athens, London, Vienna, Prague, as well as to other low cost airports, ..." Your comparison is wrong. RandomCanadian (talk / contribs) 16:32, 12 June 2021 (UTC)
    @RandomCanadian: Heh, "encyclopedic"/"unencyclopedic" stopped being a good word to use while talking about what should be in Wikipedia more than 10 years ago because there is no longer anything that can be usefully compared to Wikipedia, which is rather sui generis. Anyway, back to Britannica: This is a one sentence mention in the main article about Liverpool, not in some specialised page elsewhere, so they seem to attach some importance to it. They are also paper, and we are not. Apparently you do agree now that destination lists are encyclopedic (whatever that means), you just object to airport articles containing, in addition to a prose description, a complete and up to date list? Don't you think the Britannica article would be better if it told us what "the Canadian ports" are or if it did not have this bias of listing all American ports but no others? Being exhaustive helps avoiding bias. —Kusma (talk) 16:47, 12 June 2021 (UTC)
    @Kusma: "you do agree now that destination lists are encyclopedic" - nope, what I agree is that a summary listing, ideally in prose format, of the most important information about destinations from a given travel point, is a valid "summary of knowledge" as befitting an encyclopedia. The 1911 example you give uses this to succinctly make the point that "Most of Liverpool's trade is [was, circa 1911] with North American ports." Which ports exactly doesn't matter, though I assume that the ones listed are the most prominent and most frequently served. This is useful information, and in doesn't get stuck up in the minutiae of which destinations exactly, since that's not really an important detail unless you actually wish to go somewhere, in which case you're not going to be taking your information from an encyclopedia anyway, are you? RandomCanadian (talk / contribs) 17:08, 12 June 2021 (UTC)
    @RandomCanadian: Thank you for withdrawing the RfC. FWIW, I would support a suggestion to have some prose that augments and contextualises the tables in, say, Wikipedia:WikiProject Airports/page content, but I don't wish impose this on the people doing the actual work, at least not without their involvement. For your last question, believe it or not, I have actually used these lists in my travel planning. Least annoying way to answer the question which of the 9 airports that I can reach with reasonable effort have direct flights to a given place. Saves me the trouble of finding the airport's official pages, clicking through ads and cookie banners, finding the content in a language I can read, find where they have their actual destinations instead of the page where they try to sell me some other flights... Thanks to an army of aviation nerds, I can just use Wikipedia instead, where it is in a standardised format that is the same for every airport. While WP:USEFUL isn't an accepted argument to keep this content, it isn't a good argument to get rid of it either. —Kusma (talk) 18:57, 12 June 2021 (UTC)

RfC: Ariport destination tables

WITHDRAWN
A shame, but clearly no enthusiasm for this particular proposal. RandomCanadian (talk / contribs) 16:05, 12 June 2021 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Should tabular listings of destinations in airport articles be removed and replaced with prose descriptions? 02:23, 12 June 2021 (UTC)

Survey

  • Yes per comments in above discussion about NOTDIR and the high maintenance burden of this non-encyclopedic information. RandomCanadian (talk / contribs) 02:23, 12 June 2021 (UTC)
  • Strong oppose this type of instruction creep. Destination lists are encyclopedic information (just look into the 1911 Britannica), you just want them in prose instead of lists? The proposal basically says "we should avoid having complete and up to date information about these things". These lists change about as often as sports team squads do, and are being well maintained by dedicated people. The problem you wish to solve does not exist. —Kusma (talk) 06:18, 12 June 2021 (UTC)
  • Oppose They are useful information to have in articles, and having them as lists/tables makes it easier to quickly parse compared to prose. Thanks. Mike Peel (talk) 07:56, 12 June 2021 (UTC)
  • Strong oppose Just because we include information in a tabular format does not mean WP:NOTDIR applies. WP:NOTTRAVEL, mentioned above, also doesn't apply, since no travel guide would want this information - just because the information bases itself in travel does not mean that it's written like a travel guide. The "high maintenance" is wrong and completely ignores the fact we have many wiki-gnomes who update this on a frequent basis. "Non-encyclopaedic" is an opinion, and one I strongly disagree with. As someone with lots of aviation related books, destination information was one of my primary uses of the site before I started contributing on a regular basis. Finally, no example of what this would look like in prose has been contributed. This is a half-baked proposal that doesn't fix any problem. SportingFlyer T·C 08:01, 12 June 2021 (UTC)
  • Oppose Prose for this sort of information would be difficult to compile in an accessible manner. Tables are suitable and well established. NOTDIR does not apply, surely, as an airport article would be expected to contain an easy to read summary of destinations available from that airport. doktorb wordsdeeds 08:40, 12 June 2021 (UTC)
  • No. WP:NOTDIR doesn't apply here, as this is not a list of loosely associated topics, a directory for conducting business, nor a simple listing without context. The proposal to change it with prose description is merely table-phobia - if the content violated NOTDIR or NOTTRAVEL, it would do it in prose form as well. We are discussing merely about presentation format, and I'm not aware of no policy saying that tables are a format to avoid when showing a list of items. Also, the problem of having to maintain the content would also exist if this was changed to prose, so how does it solve the problem as stated? Diego (talk) 09:07, 12 June 2021 (UTC)
  • Oppose. The proposal is to reformat the content, with no comment about changing the scope or level of detail of the content (that is, it does not address the original goal of the preceding discussion). Therefore it it just a Wikipedia:Manual of Style/Lists question. Table seems the best way to organize this info, though no prejudice from also including other prose highlighting general themes or historical aspects. DMacks (talk) 15:21, 12 June 2021 (UTC)
    If you read the clarification comment below, you'll see the proposal is to trim the info by putting it into prose and sticking to what can be found in reliable secondary sources and not simply to be a listing of destinations based on WP:PRIMARY sources. RandomCanadian (talk / contribs) 15:30, 12 June 2021 (UTC)
    My position stands. No evidence that this can't be found in secondary (User:Kusma suggests above that it can). And no evidence that only using secondary for bare facts, which might lead to omissions, is better than a factually complete statement (the idea being the specific details, not the general patterns). And finally, WP:PRIMARY explicitly condones this sort of bare-facts use. DMacks (talk) 15:36, 12 June 2021 (UTC)

Discussion

Question clarification "prose descriptions" might be a bit vague, but this is intentional so as not to explicitly exclude specific but not thought of forms of reliably sourced information and also not to get people hung up on wording. It ideally includes any significant information which can be reliably sourced, such as main airlines serving the airport, most important destinations, so on so forth. RandomCanadian (talk / contribs) 02:30, 12 June 2021 (UTC)

  • @Diego: "it would also violate NOTDIR in prose format" - wrong. Prose format would make it far more inconvenient to give a full, excessive listing of all of them. We're an encyclopedia, not an airport departures board. Readers who absolutely need the information should not be using Wikipedia for this - they should instead go directly to the airport's website. To those who don't, the only relevant and encyclopedic information is providing a summary (Encyclopedia: "reference work or compendium providing summaries of knowledge") of it, for example in the case of the previously linked Dortmund Airport: "As of 2021, Dortmund is a hub for Wizz Air, and is also used by other low-cost carriers such as Ryanair ... Destinations served including most major European cities, and..." In the current form, the tables are a clear, context-less indiscriminate collection, without providing any useful information. We don't list every single stop of a bus route ('cause we're not a bus schedule website). Likewise, on the exact same grounds, we shouldn't list every single airport served from another one. RandomCanadian (talk / contribs) 12:42, 12 June 2021 (UTC)
    It's not an indiscriminate list per WP:DISCRIMINATE, though - it's a very clearly defined list of airlines which serve the airport, and the places they fly to from that airport. They're also not schedules as you seem to imply, that would clearly violate WP:NOT. As someone who looks at this sort of information, I really don't understand why you think readers "shouldn't be using wikipedia for this." SportingFlyer T·C 12:47, 12 June 2021 (UTC)
    Listing every element of a set, even if the set is clearly defined, can still be indiscriminate if it serves no useful encyclopedic purpose. Prose is preferred, especially if it can be used to give more context. Describing which type of airlines serve an airport, what the main focus of destinations is, ... is far more relevant context information than leaving an unannotated list which is subject to frequent and non-encyclopedic short-term changes. As I said, it's a WP:BADIDEA. RandomCanadian (talk / contribs) 13:30, 12 June 2021 (UTC)
    Again, "no useful encyclopaedic purpose" is your own opinion. We'll see how the discussion plays out. SportingFlyer T·C 13:35, 12 June 2021 (UTC)
    The tables provide additional information with clearly given context that you mainly seem to object to because they are complete and up-to-date. WP:NOTPAPER tells us that we are not bound by the limitations of paper-based encyclopaedias, but can "include more information, provide more external links, and update more quickly." Your opinion "without providing any useful information" has already been disproved by other people telling you that they do regard this as useful information. —Kusma (talk) 14:13, 12 June 2021 (UTC)
    Thank you. Put exactly what I wanted to say, above. "NOTDIR" can be thrown about with enthusiasm but NOTPAPER should be our guiding principle here. doktorb wordsdeeds 15:04, 12 June 2021 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Technical

Freenode IRC servers 'takeover'

Background

Traditionally, WMF projects and volunteers coordinated on Freenode IRC servers. Should we migrate (or aim to migrate) these projects to Libera Chat instead? Headbomb {t · c · p · b} 20:13, 20 May 2021 (UTC)

Discussion

The question here is to address what we should general aim to try to do. I'm well aware each project is independent and can setup IRC channels wherever they want. However, we could decide that we encourage specific servers and discourage others, and try to migrate the 'official' Wikipedia/Wikimedia IRC channels to Libera instead of Freenode. Headbomb {t · c · p · b} 20:17, 20 May 2021 (UTC)

I don't see that this needs an RFC? Wikimedia group contacts have already announced they will migrate to Libera on meta. Izno (talk) 20:22, 20 May 2021 (UTC)
This affects a lot more than what the WMF does. For example, there's #wikipedia-bag, #wikipedia-en-afc in templates like {{AfC welcome}} (including substed version of it), etc. etc. etc. Headbomb {t · c · p · b} 20:41, 20 May 2021 (UTC)
So, why would we go somewhere else? Who has the knowledge in the community for that? Who wants to volunteer for that? Izno (talk) 20:46, 20 May 2021 (UTC)
See the above articles. As for who has the knowledge, there's busloads of technical users here that can help with this. Headbomb {t · c · p · b} 20:48, 20 May 2021 (UTC)
Ok, let me spell it out then: A) We don't need an RFC. An RFC is a waste of the community's time on the point. B) Plain common sense is "go where WMF says they're taking the main channels". Izno (talk) 20:53, 20 May 2021 (UTC)
Also see here. -- RoySmith (talk) 21:04, 20 May 2021 (UTC)
If I understand correctly, the channels were set up by the individual channel operators? So I suggest they can come up with a proposed plan and publicize it. I imagine most people will be fine with that, but in the event anyone objects, it can be discussed further. (Just as at meta, there may be interest in other chat tools, but that shouldn't stop any transition plan under these specific circumstances.) isaacl (talk) 21:06, 20 May 2021 (UTC)
Wikimedia is migrating to Libera Chat, that was announced by the IRC Group Contacts already. See IRC/Migrating to Libera Chat for some of the technical details, it'll of course take time to update documentation, links etc. Legoktm (talk) 21:43, 20 May 2021 (UTC)
RfC tag removed per discussion above; if this is about notifying as many users as possible rather than inviting feedback, the Signpost and WP:AN are probably better places for a notification. There is one at Wikipedia:Administrators'_noticeboard#IRC_security,_Oversight_notice. ~ ToBeFree (talk) 22:49, 20 May 2021 (UTC)
@ToBeFree: You didn't remove it, you commented it out. There is a difference. --Redrose64 🌹 (talk) 19:25, 21 May 2021 (UTC)
...and I had even looked at that section.   Thanks for removing it. ~ ToBeFree (talk) 19:27, 21 May 2021 (UTC)

Conflict between User:Awesome Aasim/addmylinks and User:BrandonXLF/QuickEdit

  Resolved

@Awesome Aasim and BrandonXLF: The editing window for QuickEdit appears in the text editor for addmylinks. ― Qwerfjkl | 𝕋𝔸𝕃𝕂  (please use {{reply to|Qwerfjkl}} on reply) 18:50, 3 June 2021 (UTC)

@Qwerfjkl: What do you mean the editing window is appearing in the text editor, what steps do you perform for this to happen? addmylinks has some buttons that look the same as the ones in QuickEdit, but that's the addmylinks text editor and not QuickEdit.
Do you mean when you save a page using QuickEdit, the page appears in the "My Links" section on the sidebar? BrandonXLF (talk) 19:15, 3 June 2021 (UTC)
@Qwerfjkl Looks all normal to me. Can you give browser information as well as skin information? Aasim (talk) 05:11, 4 June 2021 (UTC)
At first, pages appear normally, but when I click the 'quick edit' button, the 'My links' section is replaced with the normal 'QuickEdit' editor. (I'm using the Vector skin, but it might be affected by User:TheDJ/mobileVector.css.) ― Qwerfjkl | 𝕋𝔸𝕃𝕂  (please use {{reply to|Qwerfjkl}} on reply) 06:59, 4 June 2021 (UTC)
@Awesome Aasim @BrandonXLF This seems to only happen on mobile. ― Qwerfjkl | 𝕋𝔸𝕃𝕂  (please use {{reply to|Qwerfjkl}} on reply) 15:53, 6 June 2021 (UTC)
@Aasim @BrandonXLF I've used User:BrandonXLF/PortletLinks to replace Aasim's script. ― Qwerfjkl | 𝕋𝔸𝕃𝕂  (please use {{reply to|Qwerfjkl}} on reply) 19:52, 8 June 2021 (UTC)
@Qwerfjkl: I was able to reproduce the issue on the new Vector skin, I'll see what I can do to fix it. BrandonXLF (talk) 20:49, 8 June 2021 (UTC)
@Qwerfjkl: The issue should be fixed now. BrandonXLF (talk) 16:40, 9 June 2021 (UTC)
Thanks! ― Qwerfjkl | 𝕋𝔸𝕃𝕂  (please use {{reply to|Qwerfjkl}} on reply) 17:11, 9 June 2021 (UTC)
@BrandonXLF By "new Vector skin", are you referring to User:TheDJ's mobileVector? ― Qwerfjkl | 𝕋𝔸𝕃𝕂  (please use {{reply to|Qwerfjkl}} on reply) 17:17, 9 June 2021 (UTC)
@Qwerfjkl: I'm referring to mw:Reading/Web/Desktop Improvements. If you go to appearance settings with Vector skin selected and uncheck "Use Legacy Vector" you see the new version of the skin. BrandonXLF (talk) 18:33, 9 June 2021 (UTC)
Thanks! ― Qwerfjkl | 𝕋𝔸𝕃𝕂  (please use {{reply to|Qwerfjkl}} on reply) 14:55, 11 June 2021 (UTC)

Mobile/desktop .js pages

  Resolved

When I load any .js page on the desktop version of Wikipedia, I cannot paste or copy text, so I have to switch to the mobile version. Is there a way to get a round this? (I think WikEd allowed me to view text normally.) ― Qwerfjkl | 𝕋𝔸𝕃𝕂  (please use {{reply to|Qwerfjkl}} on reply) 16:52, 6 June 2021 (UTC)

There's certainly something odd about the edit box in some circumstances. If you don't get an edit cursor when you click in the edit box, click in the edit summary box instead, then use ⇧ Shift+Tab ↹ to get to the main edit box. You should then be able to click with the mouse on the desired editing point. --Redrose64 🌹 (talk) 18:22, 6 June 2021 (UTC)
It works for me. Does it work if you log out? Does safemode work? What is your browser? What is your skin at Special:Preferences#mw-prefsection-rendering? PrimeHunter (talk) 18:28, 6 June 2021 (UTC)
@PrimeHunter @Redrose64 I'm using a mobile device, which is why I have to switch to the mobile version to paste anything. ― Qwerfjkl | 𝕋𝔸𝕃𝕂  (please use {{reply to|Qwerfjkl}} on reply) 19:55, 8 June 2021 (UTC)
@PrimeHunter It does not work in safemode, and I'm using the vector skin. I cannot test wether it works when logged out, as User:Qwerfjkl/common.js isn't editable by a non-interface administrator. ― Qwerfjkl | 𝕋𝔸𝕃𝕂  (please use {{reply to|Qwerfjkl}} on reply) 06:25, 10 June 2021 (UTC)
Can you copy and paste when you log out? Safemode does not load any user js page. What do you mean by "load any .js page" in "When I load any .js page on the desktop version of Wikipedia, I cannot paste or copy text"? Are there circumstances where you can copy and paste in desktop? PrimeHunter (talk) 09:17, 10 June 2021 (UTC)
@PrimeHunter Normally, when editing on a mobile device in desktop mode (or mobile mode), I can double- or triple-tap on a word to highlight, and an option to copy or paste appears above the selected text. However, in .js pages, this doesn't happen; the text selection behaves wierdly, and instead of options appearing above the selected text, a '...' Box appears, with multiple options that don't work. ― Qwerfjkl | 𝕋𝔸𝕃𝕂  (please use {{reply to|Qwerfjkl}} on reply) 21:28, 10 June 2021 (UTC)
Oh, you are talking about editing js pages. Loading a js page usualy means a load command to run the script in the page. Try clicking the <> icon at the left of the toolbar to switch between the normal editor and the code editor. PrimeHunter (talk) 21:37, 10 June 2021 (UTC)
Thanks! ― Qwerfjkl | 𝕋𝔸𝕃𝕂  (please use {{reply to|Qwerfjkl}} on reply) 14:57, 11 June 2021 (UTC)

Problem with major intersection in an article about a road

Take a look at Dillon County under "Major intersections" in South Carolina Highway 38. There are two places called Oak Grove, South Carolina. The one that had an article before I added the one in Dillon County has more people and is obviously more notable.— Vchimpanzee • talk • contributions • 17:43, 6 June 2021 (UTC)

Template:Jctint#Parameters, location_special. MarMi wiki (talk) 02:10, 7 June 2021 (UTC)
That works. Thanks.— Vchimpanzee • talk • contributions • 20:11, 7 June 2021 (UTC)
Fredddie did this.— Vchimpanzee • talk • contributions • 15:52, 8 June 2021 (UTC)

Weird redirect

Does anyone know what's happening here? It seems like an attempt to create a redirect to a centralized talk page, but the "../" isn't something I've seen before and it's not currently working. {{u|Sdkb}}talk 17:58, 7 June 2021 (UTC)

Hmmm. It is working for me. I haven't seen this shortcut before either, though. --Florian Blaschke (talk) 18:24, 7 June 2021 (UTC)
It's a subpage link (or rather a parent page link in this case). It should work, but it appears due to a bug, redirects like it haven't worked from at least 2006, see phab:T8151. BrandonXLF (talk) 18:30, 7 June 2021 (UTC)
I really wonder why it works for me then, both on Firefox and Opera. --Florian Blaschke (talk) 01:38, 9 June 2021 (UTC)
  Fixed by just explicitly declaring the target. — xaosflux Talk 10:46, 8 June 2021 (UTC)
@Sdkb: This has always worked fine for me, and I use it sometimes. Here's a demo, just follow the breadcrumbs. Do any of these not work for you? I'm on Win 10/Vivaldi, but I checked it on iOS 14.2 mobile as well. Haven't incorporated it into a redirect, though, so maybe there's something squirrely there. Mathglot (talk) 01:56, 12 June 2021 (UTC)
That works for me! {{u|Sdkb}}talk 02:10, 12 June 2021 (UTC)

Best way for tool to monitor Category:Requests for unblock?

I am making a tool for monitoring Category:Requests for unblock. I looked at the IRC feed but it does not seem to monitor additions and removals from categories.

Right now I am using the API to ask for its members every few minutes, but it would be nicer if I could get a feed as I prefer not to bother the API too much. Does anyone know a better way to monitor for additions and removals from a category? HighInBC Need help? Just ask. 02:44, 8 June 2021 (UTC)

Anomie probably does similar things for the protected edit requests queues. Izno (talk) 04:20, 8 June 2021 (UTC)
AnomieBOT just queries all pages in the categories periodically. Anomie 11:35, 8 June 2021 (UTC)
Might my CatChangesViewer help you? Also obviously you can watch the category to monitor additions/removals, though imperfect (for which I wrote another script). Nardog (talk) 04:30, 8 June 2021 (UTC)
MediaWiki itself can show you category additions, see mw:Manual:CategoryMembershipChanges. It is turned on on every WMF site.--Snævar (talk) 09:18, 8 June 2021 (UTC)
@HighInBC: so if you are "making a tool", can't your tool just query the category? The other option mentioned above involves the watchlist. One thing you could try would be to make another account, add those categories to that account's watchlist - then use the watchlist RSS feed for that account to see the changes. — xaosflux Talk 10:38, 8 June 2021 (UTC)
I am querying the category right now. Interesting idea about the watchlist. Right now it is not using and account as it is read only. But that is a good idea. Thank you. HighInBC Need help? Just ask. 10:48, 8 June 2021 (UTC)
@HighInBC: see Wikipedia:Syndication#Watchlist_feed_with_token for more on that, as it will let you not have to worry with the normal "authentication" stuff needed for logging in with an account programmatically for this case. — xaosflux Talk 11:02, 8 June 2021 (UTC)
Oh that is neat. Thank you for that info. HighInBC Need help? Just ask. 11:05, 8 June 2021 (UTC)
Yes that is perfect. I can supply the API that token, and the timestamp of my last check and get a full update in just one call. I no longer have to store the previous state to compare against to find out what has changed. Thank you, and thanks to everyone else who gave advice. HighInBC Need help? Just ask. 11:15, 8 June 2021 (UTC)
@Xaosflux: But as you can see in the URL, isn't a feed essentially just an API call returned in Atom XML rather than JSON? I can't imagine it's less server-expensive than simpler API calls that don't require tokens. Nardog (talk) 13:43, 8 June 2021 (UTC)
@HighInBC: Oh, you're making a tool! Sorry I was off. I may be still preaching to the choir, but: AFAIK there are two basic ways: list=recentchanges can give you the specific edits that caused additions/removals, but it's limited to last 30 days and doesn't detect changes by way of transclusions; list=categorymembers doesn't have those limitations but only gives you additions, not removals, and only timestamps, not revisions. Nardog (talk) 12:08, 8 June 2021 (UTC)
@HighInBC: The Wikimedia EventStream API shows both category additions and removals. It's a stream (hence makes your tool actually work in real-time, rather than every 10 minutes or so), and doesn't require any authentication or atom XML parsing. – SD0001 (talk) 03:32, 9 June 2021 (UTC)
Thank you, I was looking for a real-time solution instead of polling. This is very useful. I have learned a lot from this thread. HighInBC Need help? Just ask. 04:04, 9 June 2021 (UTC)
@SD0001: Perfect, and only 27 lines of code: User:HighInBC/Category unblock watcher.pl. HighInBC Need help? Just ask. 05:30, 9 June 2021 (UTC)

Keeping track of new pictures in a wide category tree

Hello,

I'm a marine biologist specialized in Echinodermata. I would like to be informed of any new picture of these animals so I can review the identification and, when useful, add them to the relevant Wikipedia articles. But as there are over 7000 species of the, of course I can't check all the categories every day. I used to benefit from Ogrebot's newsfeed for a long and useful time but it is no longer working. Do you guys know any other way I could get such uploading newsfeed ? (knowing that I'm not a hacker).

Thanks and best regards,

FredD (talk) 07:22, 8 June 2021 (UTC)

This is basically the same question as the "Best way to monitor Category:Requests for unblock", so the same answers apply.--Snævar (talk) 09:20, 8 June 2021 (UTC)
Outdenting as this wants an entire recursive category tree. — xaosflux Talk 10:35, 8 June 2021 (UTC)
@FredD: are most of these new files not actually here, but on commons? — xaosflux Talk 10:42, 8 June 2021 (UTC)
I'm not sure I understand what you mean, Snævar. Xaosflux, it's for pictures that are not yet on commons but will be added in the future. I want to know when people add them, so I can review and use them. Thanks ! FredD (talk) 11:38, 8 June 2021 (UTC)
@FredD: if you would like someone else to make a bot to make such a report for you, you can ask over at WP:BOTREQ. Best regards, — xaosflux Talk 13:33, 8 June 2021 (UTC)
Ok, I'll try this. Thanks ! FredD (talk) 14:01, 8 June 2021 (UTC)

action=protect with pre-filled fields?

  Resolved – Information provided. — xaosflux Talk 14:29, 9 June 2021 (UTC)

Is there a way to build a URL which gets you to the "Change protection" screen, but with fields pre-filled? You can do that with block user, via Special:Block, i.e. this, but as far as I can tell from the wikimedia manual, there's no version of that for page protection. What I'm hoping to do is be able to have a script which creates a link you can click on to take you to a pre-filled out form, which you just have to review and click the "Confirm" button. I know I can do it directly through the API, but if I can do it with a clickable link, that would be preferable. -- RoySmith (talk) 14:00, 8 June 2021 (UTC)

@RoySmith The URL params should match the name attribute of the input fields. You can inspect the DOM to see what they are. This technique should work on most all forms in MediaWiki. Here's an example that touches almost every field: [3]. MusikAnimal talk 16:24, 8 June 2021 (UTC)
MusikAnimal, Ah, cool. Thanks. I guess that's what the docs mean by "This page is a partial list of the parameters" :-) -- RoySmith (talk) 16:41, 8 June 2021 (UTC)

Bug in "Find edits by user"?

Bug? The "Next 500 results →" link at https://sigma.toolforge.org/usersearch.py?name=50.201.195.170+&page=Talk%3AWuhan_Institute_of_Virology&server=enwiki&max= doesn't work. Σ runs it? (Leads to https://sigma.toolforge.org/usersearch.py?startdate=None&name=50.201.195.170+&page=Talk%3AWuhan_Institute_of_Virology&server=enwiki&max=500 which leads to itself. Started here.) --50.201.195.170 (talk) 23:50, 8 June 2021 (UTC)

As you noted, this is not part of the English Wikipedia, and you can follow up at User talk:Σ. — xaosflux Talk 00:08, 9 June 2021 (UTC)
Anyone know why this isn't part of the standard UI? It's part of the API, see https://en.wikipedia.org/w/api.php?action=query&titles=Talk%3AWuhan_Institute_of_Virology&prop=revisions&rvuser=50.201.195.170&rvlimit=500. So why do we need an external tool to produce human-readable output? Suffusion of Yellow (talk) 00:33, 9 June 2021 (UTC)
Interesting question. The native API result suggests usersearch.py is more severely broken; it finds 0 edits, instead of the many the API finds in the last 500 revisions. Also a bug? (It is "part of the English Wikipedia", xaosflux, in the sense that the tool is linked to from every page like that where I said I started, though at toolforge.org. So? I can follow up on their talk if @Σ: doesn't respond to the ping and/or others may help. E.g. if I'm confused and these aren't bugs.) --50.201.195.170 (talk) 02:12, 9 June 2021 (UTC)
50, we link to many external tools - but we (the editors and admins of wikipedia) don't maintain them. If it is broken to the point being useless, we can remove the external link from the interface or change it to something else - but we can't actually do anything about it being broken any more then if the RIR links on the bottom of your talk page had an error - we have no access to the codebase for that tool, only its maintainer does. Removal or replacement can be discussed at the associated message here: MediaWiki talk:Histlegend. — xaosflux Talk 10:26, 9 June 2021 (UTC)
The people that maintain them often watch this page, or know what the issue is, how to fix it, or provide alternatives. I think this is a perfectly acceptable venue. Because I saw this discussion, I've changed MediaWiki:Histlegend to point to what should be a fully working tool (disclosure, authored by yours truly). MusikAnimal talk 22:57, 10 June 2021 (UTC)
Yup. I just didn't bother arguing/FTT. --50.201.195.170 (talk) 00:05, 13 June 2021 (UTC)
User:Ale jrb/Scripts/userhist.js also provides this function as a userscript integrated into special:contribs, though the UI is bit outdated. – SD0001 (talk) 03:33, 9 June 2021 (UTC)
Did anyone find the 2 bugs reproducible (or not reproducible)? I guess so, but I don't see anyone mentioning one way or the other. --50.201.195.170 (talk) 23:14, 9 June 2021 (UTC)
This feature works fine in XTools: https://xtools.wmflabs.org/topedits/en.wikipedia.org/50.201.195.170/1/Wuhan_Institute_of_Virology. I've changed MediaWiki:Histlegend to point to it for the time being. MusikAnimal talk 22:54, 10 June 2021 (UTC)

Up until recently there was not a way to search for edits by IP addresses. At some point this became possible, but I have simply never gotten around to implementing this. Σσς(Sigma) 10:00, 11 June 2021 (UTC)

IP addresses have actor IDs just like accounts, so if you go by that it should be the same query for both IPs and accounts. If you want to query for IP ranges (which XTools only very recently added support for, but it's been technically possible since late 2017), then that does require a different query. Is the source code published anywhere? I'm happy to help. MusikAnimal talk 17:21, 11 June 2021 (UTC)
You're right. It's actually already supported, but the link above doesn't work because there's a space at the end. https://sigma.toolforge.org/usersearch.py?name=50.201.195.170&page=Talk%3AWuhan_Institute_of_Virology&max=500&server=enwiki works fine. OopsΣσς(Sigma) 02:26, 12 June 2021 (UTC)
Ha! So not broken, after all. Though you could strip out the blank spaces server-side, I suppose. Edge case, for sure! Anyway in light of this I've changed MediaWiki:Histlegend to point back to Sigma's. MusikAnimal talk 05:22, 12 June 2021 (UTC)
Thank you for helping, MusikAnimal! Wrong?: Σ: the link above doesn't work because there's a space at the end Umm...gaslighting? The links in my OP above obviously don't have spaces in 'em. They can't; they're bare URLs. (And no %20's either.) No, they were certainly not working and work now. --50.201.195.170 (talk) 00:05, 13 June 2021 (UTC)

Change in "Find edits by user"?

Clicking on "Find edits by user" today is taking me to a new user interface at xtools.wmflabs.org. It was a different one until yesterday. Is there any notice or discussion around this? How can I remove the pie charts that show up in that page? I could not find a way to see a customized result, even after logging in to that site. Or, how can I go back to the older interface? - Jay Talk 13:02, 11 June 2021 (UTC)

See above. --Izno (talk) 13:51, 11 June 2021 (UTC)
I had seen it earlier, and did not know it is related to my query. How is it related to my query? What has happened? - Jay Talk 14:13, 11 June 2021 (UTC)
Ok, so the earlier tool was called WikiBlame and it is broken, and xtools is a temporary replacement? And this discussion is the place where we can get updates on this? - Jay Talk 14:30, 11 June 2021 (UTC)
WikiBlame is a completely different tool and is still accessible via "Find addition/removal". Nardog (talk) 14:42, 11 June 2021 (UTC)
On second thoughts, can we retain XTools permanently? It is superfast as compared to the earlier tool, and I can live with the pie charts if not customizable. Or is there a way a user can customize the tool to be used for "Find edits by user" via Preferences? - Jay (Talk) 05:31, 12 June 2021 (UTC)
These external tools are linked from MediaWiki:Histlegend - if there are additions/removals or just label changes needed, feel free to suggest an edit at MediaWiki talk:Histlegend. — xaosflux Talk 09:57, 12 June 2021 (UTC)
Seconded: retain XTools permanently. --50.201.195.170 (talk) 00:05, 13 June 2021 (UTC)

What just happened to Watchlist?

Five minutes ago, my Watch list looked like it always did. Is it my imagination, or are the square green boxes on the left new (as of the last 5 minutes, it seems). Some are green. Some are the same old blue color they always were. I went over and looked at my Commons watchlist, and the little boxes to the left are all the same blue color. I'm not sure what the green color is supposed to signify. Clicking on any color of them, does not change the color. So, what is the purpose? — Maile (talk) 23:08, 9 June 2021 (UTC)

Green are unread, blue are those you've looked at. — JohnFromPinckney (talk / edits) 23:11, 9 June 2021 (UTC)
You may have accidentally enabled "Display green collapsible arrows and green bullets for changed pages in your watchlist, page history and recent changes (unavailable with the improved Watchlist user interface)" in the Preferences. Nardog (talk) 23:15, 9 June 2021 (UTC)
Yes, that was it - checked in Preferences. Thanks. — Maile (talk) 23:24, 9 June 2021 (UTC)
@Maile66: It's not new, see for example Wikipedia:Village pump (proposals)/Archive 103#"Updated since last visit" markers from eight years ago. --Redrose64 🌹 (talk) 23:28, 9 June 2021 (UTC)
Yeah, I saw on Preferences that it wasn't new. But something on mine made it suddenliy really stand out, to the point of being annoying. Perhaps a font or some other something updated on my system to cause it. My browsers - Firefox and Chrome - both showed it the same way. — Maile (talk) 23:35, 9 June 2021 (UTC)
@Redrose64 and Nardog: I think - perhaps - why this suddenly stood out at me. And maybe this changed. I've been looking at my watch list on Commons and Wikisource. They both have the green and blue square boxes, but look normal to me. The difference - both of them display the time of edit to the right of the edited page name. The one here on Wikipedia displays it to the left of the page name, between the boxes and the article name, creating what seems like a wider gap between the boxes and the rest of it. Or maybe it's my imagination, but that seems to be the difference to me. — Maile (talk) 00:52, 10 June 2021 (UTC)

Cats visible in mobile view for mobile users

Hello, probably just my device, or, are there any other mobile users experiencing categories being visible(in a block like manner) whilst in mobile view? is there a d.i.y manner for me to remedy this? Celestina007 (talk) 20:34, 10 June 2021 (UTC)

WP:ITSTHURSDAY, I think. This appears to be intentional and working as designed, as step one of a change in mobile category display. See T246049, which appears to have changed the mobile view to display categories. It may be followed by T152199, which intends to make them collapsible.
This change appears to have been announced as part of the often inscrutable list of updates linked from the above Tech News (and always posted well after the Tech News, so you have to remember to check the link sometime after the Tech News posting). See mw:MediaWiki 1.37/wmf.9#MinervaNeue for the description of this change.
I am not always great at following the phab/gerrit/WMF bread crumbs, and never great at understanding why they work on this fiddly stuff instead of fixing real bugs, so I could have any of this wrong. – Jonesey95 (talk) 20:54, 10 June 2021 (UTC)
This change removes the old component that used to do categories on mobile, which had a half dozen open bugs associated with it. So... yes, it fixed real bugs. Izno (talk) 21:09, 10 June 2021 (UTC)
And may even enable category gadgets. Izno (talk) 21:09, 10 June 2021 (UTC)
You can completely hide it by adding #catlinks {display: none;} to your minerva.css. – Rummskartoffel (talk • contribs) 21:02, 10 June 2021 (UTC)
Jonesey95, Rummskartoffel, Izno thanks, I think I’d probably just opt to hide it (if it doesn’t translate to it being invisible in desktop view also) You coders/script creators and all template editors in general are gifted. This aspect of editing just overwhelms me. Celestina007 (talk) 21:19, 10 June 2021 (UTC)
minerva.css only affects the mobile skin, so you'd still see categories while on the desktop version. – Rummskartoffel (talk • contribs) 21:26, 10 June 2021 (UTC)
@Rummskartoffel, thanks-a-billion mate. Celestina007 (talk) 22:26, 10 June 2021 (UTC)

Is the global Lua function type effectively overrideable?

So I made a function in Module:Lua class (last function) that tries to override/build upon the default type to support new "types". I was testing it in User:Alexiscoutinho/sandbox 1 and noticed that it behaves differently if you are previewing. When you view the sandbox normally, it should contain "table table table". However, if you preview the page (without edits of course) it would now contain "class Base instance" (which is desired). What is going on? Why is the type function behaving differently? Alexiscoutinho (talk) 21:33, 10 June 2021 (UTC)

While OOP is great, I'm not sure that the confusion of another layer would be worthwhile. However, I purged User:Alexiscoutinho/sandbox 1 and it is now showing "class Base instance", the same as in preview. Johnuniq (talk) 00:21, 11 June 2021 (UTC)
Thank you very much! I completely forgot how to fully purge a page. Furthermore, I thought purging was only client side, thus I got quite surprised when the issue persisted in an anonymous tab. Alexiscoutinho (talk) 01:13, 11 June 2021 (UTC)

Make cross-project links open in a new tab

Is there any way to make links to other language wikipedias, commons, Wiktionary, etc, open in a new tab? I sometimes forget that they don't behave like normal external links and it's annoying. DuncanHill (talk) 00:59, 11 June 2021 (UTC)

You must have enabled "Open external links in a new tab or window" at Special:Preferences#mw-prefsection-gadgets. It's not default. I don't know how to extend it to interwiki links. PrimeHunter (talk) 01:19, 11 June 2021 (UTC)
It'll require a bit of javascript. @DuncanHill You can do it by adding $(function() { $('.extiw').attr('target', '_blank'); }); to special:mypage/common.js. – SD0001 (talk) 04:20, 11 June 2021 (UTC)
Hold down the Command (Mac) or Ctrl (Windows/Linux) key while you click the link. – Jonesey95 (talk) 06:21, 11 June 2021 (UTC)
exactly, by far the easiest way to do it and works on any website. —TheDJ (talkcontribs) 07:39, 11 June 2021 (UTC)
indeed, but I thought that was obvious and DuncanHill was looking for an automated solution. – SD0001 (talk) 10:39, 11 June 2021 (UTC)
They aren't external links, they're internal within Wikimedia. Mike Peel (talk) 10:57, 11 June 2021 (UTC)
google: doesn't look like an external link, but is. A lot of the m:Interwiki map is truly external. —Kusma (talk) 12:07, 11 June 2021 (UTC)
Weird, I didn't know that was possible (nor do I understand *why* that is possible) but none of the examples before that were external. Mike Peel (talk) 12:47, 11 June 2021 (UTC)
Traditionally most of the other websites that had special interwiki prefixes were other wikis or other free content sites, with some other sites like Google thrown in for convenience. The main difference between the interwiki map links and normal external links (other than the styling) is that interwiki map links do not have the "nofollow" attribute. (I once got so annoyed at Wikia/Fandom's advertising that I worked a bit to turn "nofollow" on for links that go there). —Kusma (talk) 13:04, 11 June 2021 (UTC)
@SD0001: Thanks, that certainly works for commons, wikiquote, etc, doesn't work for the interlanguage links down the left-hand side. @Jonesey95: and @TheDJ: actually right-click and open in new tab is what I use, but as I mentioned I sometimes forget, and @Mike Peel: they may or may not be external but they behave like external links in that the preferences I set here do not apply there, and things like templates that work here do not work there. Anyway, thanks all. DuncanHill (talk) 16:30, 11 June 2021 (UTC)
@DuncanHill Change '.extiw' to '.extiw .interlanguage-link-target' to cover them as well. – SD0001 (talk) 16:37, 11 June 2021 (UTC)
@SD0001: That doesn't seem to do anything - and stops it working for commons etc too. DuncanHill (talk) 16:45, 11 June 2021 (UTC)
@DuncanHill oops, needed a comma there in between: '.extiw, .interlanguage-link-target'SD0001 (talk) 16:52, 11 June 2021 (UTC)
Bingo! @SD0001:, this will be a great help to me, many thanks. DuncanHill (talk) 16:55, 11 June 2021 (UTC)

NASA 2gb PNG image too large for Commons?

QUESTIONS: Tried uploading a recent NASA 2gb PNG image ( at "https://photojournal.jpl.nasa.gov/archive/PIA24663_fullres.png" on NASA-page => "https://photojournal.jpl.nasa.gov/catalog/PIA24663" ) (takes awhile - ~1hr/?) - but Commons didn't seem to accept it for some reason - is the image file-size too large for Wikipedia? - Is there some workaround? - image seems relevant to several NASA articles (ie, "Perseverance (rover)", "Timeline of Mars 2020" and possibly more) - downloaded image file opens OK in my Firefox browser (Wintel10/Firefox/DellXPS8900) - iac - Thanks in advance for a reply - Stay Safe and Healthy !! - Drbogdan (talk) 11:41, 11 June 2021 (UTC)

@Drbogdan: c:Commons:Maximum file size might be helpful. Elli (talk | contribs) 11:43, 11 June 2021 (UTC)
"takes awhile" lol.. you don't say.. 2 GB... —TheDJ (talkcontribs) 12:58, 11 June 2021 (UTC)
@Drbogdan, unless someone wants to count the number of grains of sand on Mars, I don't see why the image dimensions wouldn't be downscaled by 4, and the image saved as jpg, like they did here https://photojournal.jpl.nasa.gov/jpeg/PIA24663.jpg, file size 15 MB (link found here). Those who really need the 2.4 billion pixel image can always go back to NASA. Ponor (talk) 14:19, 11 June 2021 (UTC)

FWIW - seems — * Perserverance at Van Zyl (AVideo360; 1:40; Spring 2021) on YouTube (related site; 2GB PNG-image) — added to "Timeline of Mars 2020#External links" may be sufficient for now - Thanks for all the comments above - Stay Safe and Healthy !! - Drbogdan (talk) 14:58, 11 June 2021 (UTC)

Sometimes the upload gets stuck on the unstash step; if you upload a file with UploadWizard and it "fails", you might still be able to publish it from c:Special:UploadStash. I've also found c:User:Bawolff/stash.js to be immensely useful for this purpose. -FASTILY 08:25, 13 June 2021 (UTC)

Is there a module function that given a table returns a JSON-like tabulated string?

Alexiscoutinho (talk) 22:43, 11 June 2021 (UTC)

mw:Extension:Scribunto/Lua reference manual#mw.text.jsonEncode
Trappist the monk (talk) 23:03, 11 June 2021 (UTC)
Thanks! Alexiscoutinho (talk) 23:21, 11 June 2021 (UTC)

Hidden maintenance category shows up at top of main category list

Why am I seeing one hidden category showing up at the top of the main category list at the bottom of an article?

On the article Simone de Beauvoir, the first category I see is "Wikipedia articles with WORLDCATID identifiers", a maintenance category. The next two cats are Simone de Beauvoir, followed by 1908 births; these two correspond to the first two categories explicitly in the article wikicode. The first category is not in the wikicode anywhere, which is not surprising, as it is a maintenance category that is probably dragged in by a citation with an |oclc= param.

I have my preferences set so that I see hidden maintenance categories, and after the main category list which is displayed to everybody, the hidden cat list starts off with: CS1 maint: numeric names: authors list; CS1 maint: archived copy as title; Articles with short description, and so on. Why doesn't the WORLDCATID maintenance category appear somewhere with these hidden categories, instead of the top of the main category list? Thanks, Mathglot (talk) 01:32, 12 June 2021 (UTC)

Because a since-fixed bug in a series of edits I made to Module:Pages with authority control identifiers caused the category to no longer register as hidden. I've applied some null edits, and now the category is back to its proper spot. * Pppery * it has begun... 01:44, 12 June 2021 (UTC)
@Pppery:, thanks! Mathglot (talk) 02:37, 12 June 2021 (UTC)

Embedding infoboxes

At Miawpukek First Nation, I tried to embed an infobox in order to remove duplication and shorten the infobox. It didn't work too well. If an editor could look at User:Magnolia677/sandbox I would appreciate the input. Thank you! Magnolia677 (talk) 10:49, 12 June 2021 (UTC)

  Fixed in your sandbox (top half). – Jonesey95 (talk) 13:26, 12 June 2021 (UTC)

No info for special pages, a few others as well?

googling Special:CreateAccount for example, or googling Special:UserLogin or any other special page to my knowledge, I've seen it always says "No information is available for this page. Learn why." Why is that? Also some others like googling Wikipedia:Sockpuppet investigations also don't seem to work either, but it never seems to work for special pages. Why does it not work specifically for special pages, or for any other specific page? It doesn't appear to be the same as noindexing, as you can search for the page, it just doesn't give you info. 54nd60x (talk) 13:44, 12 June 2021 (UTC)

The page at one time was robots.txt blocked to avoid it being indexed. Then google started indexing pages even if they showed up in robots.txt and said we should be using noindex. But noindex cannot easily be detected if the page is also in robots.txt (unless the google bot finds some per chance traversal path that has the pages linked from elsewhere)... and those Special pages were never removed from the robots.txt. Similar for SPI. —TheDJ (talkcontribs) 14:42, 12 June 2021 (UTC)
@TheDJ: Why were special pages avoided being indexed? And does it mean that the magic word __NOINDEX__ would have no use as it can't be added to a special page. If the pages are not noindexed in robots.txt, why doesn't it give you info for special pages? And in what circumstances would it be best to avoid searching for special pages? 54nd60x (talk) 01:24, 13 June 2021 (UTC)
@54nd60x: Special pages can't be indexed because there is nothing to index: a special page doesn't actually exist until you visit it. When you follow a link to a page like Special:Preferences the page is generated specifically for you; once served to you it's deleted again; and what you receive is different from what other people receive when they follow exactly the same link. --Redrose64 🌹 (talk) 07:39, 13 June 2021 (UTC)
@Redrose64: Special pages can't be indexed because there is nothing to index: a special page doesn't actually exist until you visit it. Could you please explain that? Does it mean that special pages have visible content but they aren't actually editable as it's just transclusion of MediaWiki pages? Also, why is Wikipedia:Sockpuppet investigations and perhaps some other non-special pages noindexed? Does it have to do with privacy? 54nd60x (talk) 10:41, 13 June 2021 (UTC)

Some user scripts are not working

I already addressed this concern at Wikipedia talk:User scripts#Not working but no one is responding. Help me, please. —hueman1 (talk contributions) 14:08, 12 June 2021 (UTC)

See WP:JSERROR on how to report script errors. For starters, you can tell which one isn't working. – SD0001 (talk) 14:22, 12 June 2021 (UTC)

Quarry namespace mapping

Have you ever been frustrated because there's no way to map namespace numbers to namespace names in a database query? I hereby present Quarry 55924 for your amusement. There's hacks, there's ugly hacks, and then there's hacks that are so ugly you're proud of them. -- RoySmith (talk) 16:40, 12 June 2021 (UTC)

You don't even need to join pagelinks for that: quarry:query/55928.
I had a somewhat similar idea a while ago, but using a sandbox with links to Talk:Talk, User:User, User talk:User talk, and so on, so I could just use pl_namespace and pl_title out of pagelinks, and not have to worry about some joker breaking the query by creating extra subpages or inbound links or whatever. I couldn't figure out how to get it working with the main namespace, though.
quarry:query/55930/User:Cryptic/ns, to make it concrete. Munging the titles with MID() etc. like you did could do it, but it stops being brief enough that I'd feel ok pasting it into the middle of real queries. Still better than what I usually resort to like in e.g. quarry:query/50255. —Cryptic 20:04, 12 June 2021 (UTC)
My go to is including the namespace number and then using regex change it to {{subst:ns:N}} and then putting it in a sandbox and then it works. A better system would certainly be nice though. --Trialpears (talk) 20:22, 12 June 2021 (UTC)
Cryptic, You win. -- RoySmith (talk) 21:11, 12 June 2021 (UTC)
This was one of the reasons I created User:SDZeroBot/Database report. It supports wikilinking titles from the query output, using a namespace number from another column. – SD0001 (talk) 05:56, 13 June 2021 (UTC)
Namespaces aren't consistent across wikis - see the identical list rendered on 5 wikis - English, Commons, WikiData, Meta, and German.
Since Quarry allows querying different wikis just by changing the specified database from enwiki_p, the SQL should also (preferably) be wiki-neutral to maximise reusability. The method in Quarry 55915
SELECT CONCAT('[[', IF (pt.pt_namespace=14,':',''), '{{ns:', CAST(pt.pt_namespace AS CHAR), '}}:', pt.pt_title, ']]')
dresses the namespace/page-title as a wikilink in a wiki-neutral way (skipping the use of regex Trialpears mentioned). Thankfully namespace 14 is consistently Category (or equivalent) in needing the colon prefix for all wikis AFAIK. The resultset can be taken as a wikitable & sandboxed on the corresponding wiki.
User DerHexer is a useful test subject for this query since he's an admin for dewiki_p, enwiki_p, commonswiki_p, & metawiki_p. - Cabayi (talk) 07:29, 13 June 2021 (UTC)
I've learned from experience that the file namespace (consistently 6) also should have a leading colon, otherwise that looks great and I will use it next time. --Trialpears (talk) 08:15, 13 June 2021 (UTC)
@Cabayi: Namespaces -2, -1, and 0 through 15 inclusive are consistent in their purposes across all WMF wikis, and I think across all MediaWiki wikis also. The non-negative numbers also always occur in pairs: all subject namespaces have an even number, and its corresponding talk namespace is always one greater. Whilst the local names do vary (e.g. User: might be Utilisateur: (French) Benutzer: (German), etc.), the name used on English Wikipedia may be used for all of them (e.g. try following fr:User:Redrose64), with one pair of exceptions. These exceptions are namespaces 4/5, which have been localised here to Wikipedia:/Wikipedia talk:, and as you noticed at Commons, Meta etc. the local names are Commons:/Commons talk:, Meta:/Meta talk:, etc. The default non-localised name for these two namespaces is Project:/Project talk:, and they work everywhere - try following Project:Namespace, meta:Project:Namespaces or indeed ru:Project:Пространства имён.
For namespaces numbered 16 or above, not all of them exist on all wikis, but for those that use a given number, its purpose is the same for all wikis that use the same number - for instance, Module:/Module talk:, where they exist, are always 828/829 although as with namespaces 15 and below, the local names may vary.
@Trialpears: The File: namespace is like the Category: namespace in that an initial colon is necessary to make a link instead of to activate a feature. --Redrose64 🌹 (talk) 08:31, 13 June 2021 (UTC)
Thanks, Redrose64. I've adjusted Quarry 55915 to handle files as well:
SELECT CONCAT('[[', IF (pt.pt_namespace=6,':',IF (pt.pt_namespace=14,':','')), '{{ns:', CAST(pt.pt_namespace AS CHAR), '}}:', pt.pt_title, ']]') page,
and salted File:SaltedFile for a test example...
amended to handle files as well
page protection level
Direct_Deal extendedconfirmed
Fuego_bxndz extendedconfirmed
Janix_Marie_Mendez extendedconfirmed
Janix_Mendez extendedconfirmed
Jim_Gomez extendedconfirmed
Manoj_Verma extendedconfirmed
Naveed_Qazi extendedconfirmed
Naver_Matome_(Service) extendedconfirmed
Naver_matome extendedconfirmed
Sarju_Prasad_Dubey extendedconfirmed
Syed_Mansoor_Ali_Naqvi extendedconfirmed
TourHQ extendedconfirmed
Udit_Bhanu extendedconfirmed
YDNW_Dive extendedconfirmed
Draft:Ameel_Shamsi extendedconfirmed
Draft:Amit_Bhadana_(youtuber) extendedconfirmed
Draft:Fm_Kid extendedconfirmed
Draft:Harshil_Anuwadia extendedconfirmed
Draft:Juned_Patel extendedconfirmed
Draft:P&M_Movies extendedconfirmed
Draft:Pawan_Chawla extendedconfirmed
Category:Railroad_museums_in_Hawaii sysop
Ashraf_Palarakunnummal_(Ashraf_Thamarassery) sysop
COVIDemic sysop
Fox_Sports_Japan_(company) sysop
Juned_Patel sysop
Vivek_Bindra sysop
Y._R._Dudhani sysop
YASH_DUDHANI sysop
Yash_Rajendra_Dudhani sysop
Draft:Yash_Dudhani_2 sysop
File:SaltedFile templateeditor
Since this method doesn't touch on the actual namespace names (localised or global) no adjustment is needed on that front. The SQL is still wiki-agnostic.
Cheers, Cabayi (talk) 08:54, 13 June 2021 (UTC)

Silly Question

Silly Question: is it possible change to User:Talk:Talk from User:0mtwb9gd5wx ? .... 0mtwb9gd5wx (talk) 08:47, 13 June 2021 (UTC)

0mtwb9gd5wx, I think WP:UNCONF applies and I'd decline it. Other renamers may view it differently and perform the rename. Once done, other users may also see it as WP:UNCONF and report you to WP:UAA.
It also has the potential to break stuff. Many templates handle usernames and strip leading namespaces. I doubt any of them have been tested for this level of misdirection.
It's a balancing act, how badly do you want it and how much grief can you tolerate? Cabayi (talk) 09:04, 13 June 2021 (UTC)
Also, m:GRP#Policy re frivolous & repeated requests. Cabayi (talk) 09:07, 13 June 2021 (UTC)
I glanced at the previous post after writing the subsequent one, it was just an amusing idea. .... 0mtwb9gd5wx (talk) 09:16, 13 June 2021 (UTC)
0mtwb9gd5wx, once upon a time I thought for (;;) would be cool/amusing as my "forever" username. Boy, was I ever wrong. Cabayi (talk) 09:25, 13 June 2021 (UTC)

Template:DistroWatch

No documentation, so I hacked one example, so it needs to be pretty. .... 0mtwb9gd5wx (talk) 08:37, 13 June 2021 (UTC)

@0mtwb9gd5wx: Where a template has no documentation, you may use the {{Bad documentation}} template, you don't need to post here. --Redrose64 🌹 (talk) 08:49, 13 June 2021 (UTC)
0mtwb9gd5wx, thanks for improving the documentation! Usually we keep documentation on a separate documentation page such as Template:DistroWatch/doc if it is longer than a line or two which, I have now done. You also accidentally added it in a way that the documentation was included when the template was used on pages which is another reason it's much simpler to have a dedicated documentation page. --Trialpears (talk) 08:54, 13 June 2021 (UTC)
@Trialpears:, I am not very familiar the technical infrastructure, so I posted here. Lots of mistakes... .... 0mtwb9gd5wx (talk) 09:08, 13 June 2021 (UTC)
0mtwb9gd5wx No worries =). We all were new once. If you want to make more modifications to the documentation you should do that at Template:DistroWatch/doc and not Template:DistroWatch. I think it looks acceptable now. --Trialpears (talk) 09:11, 13 June 2021 (UTC)

Education program (again)

About a month ago I brought up the possibility of removing the education program talk namespace at Wikipedia:Village pump (technical)/Archive 189#Education program namespace removal. This was prompted by T217137 and similar tasks which resulted in removal from other Wikis following that the namespace was emptied either through deletion or moves. Currently there are 0 pages in the Education program namespace and 1,427 pages in the Education program talk namespace. My plan is to move most pages from their current location of Education program talk:FOO to Wikipedia talk:Education program archive/FOO. Some pages that have no significant content (such as the supported by wikied messages) will/have been deleted outright without archiving. Assuming there are no objections in the next few days I will proceed with this plan. --Trialpears (talk) 08:38, 13 June 2021 (UTC)

Vega

A how-to guide asserts that Vega Code can be copied to wiki and be used to generate charts/graphs. Then, why does this code not work? TrangaBellam (talk) 10:20, 13 June 2021 (UTC)

@Yurik: Are we not supporting 3.0, yet? TrangaBellam (talk) 10:47, 13 June 2021 (UTC)
@TrangaBellam: the only notes I see say we only support v2; this is part of the graph extension though - so you may get some better responses here: mw:Extension talk:Graph. — xaosflux Talk 11:53, 13 June 2021 (UTC)

Proposals

Consolidating help venues

AFAICS, we have a few primary help venues for questions of a general nature:

I don't know exactly what the difference between Teahouse and Help desk is (in this MP discussion other editors raised this point), possibly the former is considered useful for newbies and the latter for experienced editors? Though skimming the Teahouse and HD I don't really get the impression that these are really distinct in terms of questions asked. More importantly, my feeling is that Wikipedia:Editor assistance should probably be redirected somewhere, as that venue is completely inactive and mostly goes back to pre-2011, and WP:EAR should probably be redirected to either Teahouse or the help desk as it doesn't seem to have any distinguishing features from either. ProcrastinatingReader (talk) 16:10, 20 April 2021 (UTC)

  • The latter two are mostly or entirely historical AFAIK. The Teahouse is for the newest of the new. The help desk is generally for more complicated questions, but not unwelcoming for people who end up there as opposed to THQ. GMGtalk 16:13, 20 April 2021 (UTC)
  • Broadly speaking, the Teahouse is designed for new users, unfamiliar with Wikipedia, its culture, and its jargon, while the Help Desk is designed for people who are more familiar with Wikipedia in general. Which is not to say that it works out so 100% of the time, but in general that is how it is supposed to work. As a result, a person answering a question at the help desk would feel free using shortcuts, referring people to technical documents, and using wikijargon to answer questions there; however the Teahouse is supposed to presume that the OP would know none of that, and strives to treat users as though they need to have their hands held through the process, and responders should adopt a tone in their response that they are dealing with Wikipedia newbies who wouldn't know how to read a Wikipedia namespace document, what a diff is, or what any of the terms d'art that we use in daily conversation at Wikipedia mean at all. We need both of those two help desks to keep that distinction available. EAR has long been moribund, and I'm actually shocked to see it hasn't since been marked historical. --Jayron32 16:16, 20 April 2021 (UTC)
  • The editor assistance page isn't a venue in itself but a place to find a specific willing helper. I agree though that the help desks are as good a place to find a helpful editor and make a personal connection. isaacl (talk) 16:54, 20 April 2021 (UTC)
  • I agree the last two seem historical. As to the difference between the first two, it's something I also wondered when working on user:Levivich/Help, which is my prototype attempt at consolidating new user help pages. Levivich harass/hound 17:25, 20 April 2021 (UTC)
resolved venue discussion
  • @ProcrastinatingReader: I'm missing which policy or guideline this is seeking to create or amend - perhaps a different venue would be more appropriate for this. — xaosflux Talk 17:34, 20 April 2021 (UTC)
    I think I'd meant to post this at VPR (only just realised it's at the policy pump). I'll move. ProcrastinatingReader (talk) 17:37, 20 April 2021 (UTC)
  • Do we have a good mapping of the ingresses to each of these processes that may need adjusting? — xaosflux Talk 19:08, 20 April 2021 (UTC)
  • I think our helpers are more than capable of determining what level of help to provide to users. I think combining the help desk and the Teahouse could be a useful turn of events. Experienced users shouldn't mind, and new users will be less confused. We have so many possible pages for new users, consolidation is key to accessibility. We really need to be thinking hard on how to make it easier to onboard new users. On a side note, calling it the Teahouse feels confusing to me. I wish it was just called the "help desk", which is self explanatory, but it should retain the cultural norms of the Teahouse. AdmiralEek (talk) 23:29, 20 April 2021 (UTC)
    Also, advertised this at the TH and HD talk pages. AdmiralEek (talk) 23:33, 20 April 2021 (UTC)
  • Planning to add some more substantive comments later, but people might want to take a look at Morgan, Jonathan T.; Halfaker, Aaron (22 August 2018). "Evaluating the impact of the Wikipedia Teahouse on newcomer socialization and retention". Proceedings of the 14th International Symposium on Open Collaboration: 1–7. doi:10.1145/3233391.3233544.. It has some useful empirical evidence about what the Teahouse does, as well as an explanation of its goals as opposed to the Teahouse. Vahurzpu (talk) 05:54, 21 April 2021 (UTC)
  • I support keeping the Teahouse and the Help desk separate as I have the Help desk watchlisted and occasionally contribute, but I would find it onerous to follow Teahouse guidance and explain every Wikipedia process in my own words rather than linking to the process and answering any follow up questions. The Help desk has a prominent link to the Teahouse and the Teahouse page should probably have a similar link the Help desk. Both links should probably be followed by a request to post queries in one venue rather than both. TSventon (talk) 12:19, 21 April 2021 (UTC)
  • Per TSventon, the Teahouse and Help desk should definitely be kept separate, and are intended to meet the needs of different types of editors, even if there is often some overlap. At WP:TH we strive to communicate in plain English, and in a friendly tone, assuming little or no prior knowledge by the questioner. As has already been said, WP:HD is shorter, more succinct, and often more technical in the tone, both in terms of questions asked, but especially in the answers given. Welcoming new editors and answering their questions in a simple, friendly manner at the Teahouse does make engagement with newcomers much lengthier, but, as has been pointed out by Vahurzpu above, research by Jmorgan (WMF) and colleague showed that the Teahouse makes a significant contribution to new editor retention - and that's what we all want, isn't it? It also continues to provide a testbed for research on editor retention (see this post by Maximilianklein at WT:TH in January 2020).
    I note that ProcrastinatingReader's question linked to a partly agreed discussion that they closed on agreement to add a link to the Teahouse on the Main Page, and it's there that the distinction on target audiences really ought to be made, though the precise wording would need further attention. I would certainly be in favour of that link being added, and the different active venues made clear. Of course, if a question at WP:TH is too technical for the poor Teahouse Hosts to respond too, we do sometimes refer people on, though that would most often be to WP:VPT - or WP:REFDESK for the off-topic ones. (I do, however, wish WP:TH had a better archive naming system, more akin to that at WP:HD as it would make it much easier for a newcomer to find their old, archived post when they're in a dated format.) With regards to any suggestion to merge WP:TH/WP:HD, this comment from Maineartists sums it up: "if it ain't broke, why fix it?". But, as for WP:Editor Assistance - yes, this probably does need marking as historical, and I note that Kudpung suggested precisely that back in 2018. But as I've never been there (who has?), I can't comment further from any personal experience on where would be the best redirect. I'm guessing WP:TH might make the most sense. Nick Moyes (talk) 22:39, 21 April 2021 (UTC)
  • I agree with Procrastinating Reader that the help venues ought to be consolidated, and I'm fine with marking the editor assistance forum as historical. One of the things that newcomers most often say about Wikipedia is that the number of back-end pages is overwhelming, so it is not good that editors are encountering potential confusion over where to ask their question in the first place.
    Regarding the point made about the intended difference between the TH and the HD, that's all fine and dandy, but the key word is intended. There are currently lots of complete newcomers ending up at the HD, and relying on them to read the hatnote and switch to the Teahouse if they want a friendly response is not working. We need to do a better job of pointing to the TH rather than the HD in all newcomer-facing areas, and making the latter a much quieter venue that gets only non-obvious questions from established editors. {{u|Sdkb}}talk 01:41, 23 April 2021 (UTC)
  • I was the main user answering at WP:EAR for a few years. It was one of the principal help venues until the The Tea House opened. My original comment about closing EAR down was in fact in 2013. I'm surprised no one has taken the initiative to deprecate it and close down all the links to it. Kudpung กุดผึ้ง (talk) 05:12, 23 April 2021 (UTC)
  • In a volunteer environment, I think groups interested in an initiative should be free to decide how to organize it, as long as it doesn't impose an undue burden on others. In this context, I think the following questions should be examined regarding any potential burden:
    1. Are questions being asked and answered effectively?
    2. Are responders able to deal with questions effectively?
  • Regarding the first question, different types of venues appeal to different editors, so it can be useful to have a metaphorical teahouse setting as well as a more terse question-and-answer format. Regarding the second question, as noted by others, different responders may be interested in answering at different levels of detail. Is having multiple venues effective at supporting this, versus the tradeoff of some responders having to monitor several places? Related to both questions, if someone asks a question in one place that, based on the level of detail needed by the questioner, is better suited for another place, is that question still handled effectively (by still answering at the desired level, by smoothly moving it to the other place, or by other means)?
  • In short, I'd like to hear from the people on the ground: does having two venues hinder your ability to get appropriate responses or to adequately respond to questions? Do we need to have a wider mix of people watching the help desk or teahouse in order to deal with different expectations on level of detail? Is eliminating one going to actually draw more watchers to the other? I'm not enthusiastic about telling volunteers to stop contributing to a productive initiative, even if I think they could equally help another productive initiative. isaacl (talk) 19:46, 24 April 2021 (UTC)
  • I occasionally stop by both the Teahouse and Help Desk, and even answer questions. I wouldn’t call myself highly experienced in either. I do see a lot of overlap (but also much difference). If someone asks a noob question at HD, it’s better to answer them in-place rather than tell them to go off and re-ask at Teahouse. Vice-versa, having some more-clueful questions at Teahouse helps break the monotony there. If we did want to maintain a strong separation, rather than an intent, then we could move discussions from one forum to another, just like this discussion has been moved from VPP to VPR. But moving threads on MediaWiki is a bit more cumbersome than on some other discussion platforms. I do think we're a bit curt with people asking a question in both places: having two fora is potentially confusing and asking for help in more than one place isn't in the same league as forum-shopping across DR–AN–ANI.
    Both HD and TH are limited by the high volume and rapid archiving, especially Teahouse. I recall one new editor who was quite miffed that the Teahouse is presented as a place to have a friendly chat, but is in practice mostly a rapid-fire Q&A feed. If we were a smaller community, we could have all chat at le Bistro or the Beerhall, rather than compartmentalising it into multiple silos (VP* is a good example). This brings us to a practical limitation. Merging the two would exacerbate the situation with high volume of questions. And there’s also the nature of the questions: the merged Help venue could be overwhelmed with so much repeated "how i make new article for non-notable thing?", "my thing's not showing up in Google", and "why AFC take so long?".
    Talking about practical as opposed to intended differences, a big difference between Teahouse and Help Desk is the entry points. New users often get a big welcome message directing them to the TH.

IIRC, even some of our level-one warning templates direct them there.
– Pelagicmessages ) – (12:45 Sun 25, AEDT) 01:45, 25 April 2021 (UTC)

  • For those wondering what the differences are between EA/EAR and Teahouse/Help Desk; If you take a close look, you will notice that many EAR requests are dispute/content related, something I think Teahouse/Help Desk either do not deal with, or do not promote being that they are mainly promoted as Q and A forums. Other things that are promoted heavily on EA/EAR, but not on Teahouse are the ability to contact a list of helpful editors directly and make edit requests. While these features might be technically possible at the Teahouse, they are not promoted in any way that makes them functionally useful such as they are at EA/EAR. Huggums537 (talk) 16:03, 1 May 2021 (UTC)
  • Comment. I've been active answering requests at WP:EAR lately. I like it because it's low traffic, but not completely inactive. I can keep it on my watchlist without it bloating to 100+ revisions a day, and I have a decent chance of being able to answer (before someone else provides a good answer, making the need for me to answer unnecessary). –Novem Linguae (talk) 23:19, 1 May 2021 (UTC)
  • Comment. Putting myself in the mindset of a noob, I know what a helpdesk is, I have no idea what the teahouse is - some fancy facility for the experts in the know to have a chat, I suppose. I know which I would turn to for help. Yet we do it backwards; we are so used to doing it backwards we don't even realise we are. I can see your replies now; "@steelpillow, the Help:Contents explains which and why" - except noobs don't read smallprint, they just go "Great, a nice blue help desk link >click<". Just a word of advice from a long-serving technical author and UI designer in the IT business; whatever you guys decide, a prominent clickable Help Desk button is what noobs want and expect. — Cheers, Steelpillow (Talk) 15:40, 23 May 2021 (UTC)

Proposal: deprecate WP:EA/WP:EAR and close down all active templates or help pages linking to it

There is consensus to enact this proposal, to consolidate help venues, hence the less active one is closed down. It has been suggested to redirect these pages, but there is no consensus as to exactly where. starship.paint (exalt) 04:01, 31 May 2021 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

  • Support No point in newcomers being directed to an inactive venue. Pages also needs marking as 'historic'. Pinging ProcrastinatingReader as OP. Nick Moyes (talk) 23:10, 23 April 2021 (UTC)
    • Nick Moyes, where are you getting the idea it's an inactive venue? The oldest request was the 16th, and the newest on the 30th. Huggums537 (talk) 14:32, 1 May 2021 (UTC)
      @Huggums537: Here are the figures:
      Hope this helps, Nick Moyes (talk) 23:39, 1 May 2021 (UTC)
      Yes, this does help because I can see the "inactive" tag was improperly attributed to a forum that is actually just "less active", a misrepresentation I wouldn't have been so miffed about if it had been properly presented as "nearly" or "almost" inactive. Huggums537 (talk) 10:57, 2 May 2021 (UTC)
      Ok Nick Moyes, I owe you an apology for harping about the "inactive" tag bit. Upon further investigation, it seems the idea originated from the original post of ProcrastinatingReader who said the venue was, "completely inactive", leading others such as GreenMeansGo, Levivich, and Sdkb to conclude the venue was of a "historical" nature. ProcrastinatingReader could you explain why you described the venue as "completely inactive"? I'm assuming good faith that you were referencing the EA signup page not the EAR project page, and had no intention to misdirect anyone. I also agree that page is not very active. However, I think it is very similar to the signup page of many other projects, and that it is not intended to be be all that active since it's only real purpose is for people to sign on to the project. Many of these project signup pages are not really that active. This is hardly grounds for putting any project into a "historical" condition, or calling it completely inactive when an editor signed up for the project just a month and a half ago. Huggums537 (talk) 12:31, 2 May 2021 (UTC)
      The statement is quite clear: More importantly, my feeling is that Wikipedia:Editor assistance should probably be redirected somewhere, as that venue is completely inactive and mostly goes back to pre-2011, and WP:EAR should probably be redirected to either Teahouse or the help desk as it doesn't seem to have any distinguishing features from either. It does not say what you seem to think it says. The last 5 registrations go back to 2018, and the last 10 go back to 2012, almost a decade ago. That's "completely inactive". ProcrastinatingReader (talk) 13:16, 2 May 2021 (UTC)
      @Huggums537: While they may not be entirely dead, there is still probably some calculation to be done there about whether we're confusing new editors by having unnecessary duplication of forums that have very little variation in scope. As already covered, there is a non-overlapping region for TH and HD. That's largely due to efforts like HostBot, that specifically target new users.
      But we're not doing ourselves any favors if we have so much redundancy that "where do I ask my question" ends up being somebody's first question. Alternatively, if you have links to helping forums far and wide, and a new user that doesn't know hot to use their contribution history, and can't find the question once they've asked it. GMGtalk 16:05, 2 May 2021 (UTC)
      I agree more calculations would need to be done because I very seriously doubt we would be facing any "where do I ask my question" issues. This is an irrational fear-based argument that has no basis in reality since the status quo has not already produced any significant amount of such issues that I'm aware of. There is no reason to expect that leaving the EA/EAR and TH/HD intact would cause things to change in that way. However, removing EAR removes options available to a user that are not available in the other help forums such as the ability to make certain dispute/content/edit requests. This is entirely useful for those who have no interest in a venue so vile as the peanut gallery. I recently discovered the joy of Wikipedia:Dispute resolution requests and found it extremely helpful to have dispute options available so that I could find a more friendly and suitable way to resolve a dispute. More options are better. See my bathroom argument below. Huggums537 (talk) 16:47, 2 May 2021 (UTC)
      We have lots of issue-specific noticeboards and general question venues. Unnecessarily splitting up conversation reduces good outcomes, both in terms of answers to question asked and in confusion to the asker. There's a legitimate argument that merging HD+TH would cause the volume to be so high that the merge is counter-productive (hence it hasn't been proposed). Same is not true of EAR. We have {{edit request}} and WP:DR venues like WP:DRN and WP:3O. If EAR is duplicating the work of 4 different systems, and doing so in an inferior manner, then that's absolutely not a productive venue. ProcrastinatingReader (talk) 17:11, 2 May 2021 (UTC)
      The key question as I mentioned previously is whether or not the requestors and responders feel the system works well for them. I don't like telling volunteers that they should stop working in a way they find productive just because I think they could be productive elsewhere. isaacl (talk) 17:20, 2 May 2021 (UTC)
      It's not just because they'll be productive elsewhere, it's because having too complex a system scares off new volunteers. There's a survivorship bias in who actually makes it to posting a question, and many editors get intimidated simply when faced with multiple places to ask a question. While we would like them to be bold and pick one, many people are afraid of choosing wrong and getting yelled at so they just don't post. Duplicating work can be harmful, and if volunteer workflows are harming efforts to bring in more volunteers then yes I think we should ask them to learn a new workflow. Wug·a·po·des 06:54, 3 May 2021 (UTC)
      Wugapodes, where is your data or any evidence to suggest that any such harms have been occurring with the current processes? I grow weary of these fear-based arguments rampant on Wikipedia without any rational evidence to back them up. This proposal is essentially asking that we go intrude upon a group happily conducting business, and force them to pack up shop to do business in places they may not want to, and in ways that are not exactly the same as they are accustomed to all because we think we know better, or don't like what they are doing, and all in the name of less activity. That makes just about as much sense as boarding up the guest room so nobody can use it at all since it doesn't get used that much anyway. Huggums537 (talk) 11:27, 3 May 2021 (UTC) Also, your argument suggests we should put a sign over the boarded guestroom door that says, "Harmful! Do not enter!" It's kind of comical actually. All this talk about "duplicating" work as if we are somehow going to be multiplying things just by leaving them as they happily have been is really absurd. The Wikipedified logical mentality mystifies me. Huggums537 (talk) 11:48, 3 May 2021 (UTC)
      If there's a problem with the productivity of one or more of the help systems from the point of view of questioners or responders, then certainly we ought to examine means to improve matters. I've only seen theoretical examples here, though, which is why I think we should talk to the participants for the different initiatives, see what they think, and give them wide latitude to decide what modes of operation work well for them. Regarding being yelled at, I think the ideal solution is not to yell at anyone, and provide reassurance upfront that no matter where someone asks for help, the request will be directed towards responders who can help. Imperfect world that this is, that might mean moving the request to a more specialized venue (such as the technical village pump for questions tied to MediaWiki's implementation, the reliable sources noticeboard for questions on appropriate sources, and so forth), which I think is manageable. isaacl (talk) 20:13, 3 May 2021 (UTC)
      I agree. Relating this to my guest room analogy above, we have to consider that in this case the guest room is actually currently occupied. I think it would be far more proper to get the opinions of the guests themselves as to how harmful they think the guest room is as opposed to suddenly tossing them all out under the pretext that we *think* it might be harmful, then trying to justify it by saying it wasn't used that much anyway so board it up and we'll slap a "Danger" sign on it to make ourselves feel better about it. Huggums537 (talk) 07:08, 4 May 2021 (UTC)
      If requests for assistance are still being answered suitably, the venue is still active. isaacl (talk) 17:18, 2 May 2021 (UTC)
      Agree with points made by Isaacl. Huggums537 (talk) 17:41, 2 May 2021 (UTC)
      It would probably be impossible to know. I guess we could look on the user talk pages of the editors listed there for any questions asked, but it'd be impossible to know WP:EA is where they came from. With ~150 pageviews per month, I'm not optimistic. In any case, the format is IMO archaic and inferior to newer systems. ProcrastinatingReader (talk) 17:43, 2 May 2021 (UTC)
      Well, there are the requests on the request page for which you can see the responses and response time. If you're thinking about direct contact with helpers, personally I wouldn't call it an inferior mechanism: one-on-one assistance can be effective. In any case, I don't think a shutdown should be imposed. Feel free to have a chat with the editors involved and reach a consensus that answering questions at the help desk would be essentially equivalent. isaacl (talk) 18:45, 2 May 2021 (UTC)
  • Support per comments in section above. {{u|Sdkb}}talk 23:29, 23 April 2021 (UTC)
  • Support - ditto Levivich harass/hound 00:46, 24 April 2021 (UTC)
  • Support – very sensible and solid proposal that hopefully begins to address our issues with help venues. Aza24 (talk) 01:37, 24 April 2021 (UTC)
  • Support per Aza24. ProcrastinatingReader (talk) 07:46, 24 April 2021 (UTC)
  • Support per Nick Moyes. EpicPupper 23:21, 24 April 2021 (UTC)
  • Support Assuming we haven't missed anything, this seems like a no-brainer. ElKevbo (talk) 02:56, 25 April 2021 (UTC)
  • Makes sense. ~ HAL333 20:36, 28 April 2021 (UTC)
  • Oppose because this seems like a useful venue to me, and I don't understand why anyone thinks the venue is inactive since there are currently 15 open requests. I also don't understand why notice was given about this discussion on the Teahouse and Help Desk talk pages, but not the other two, so I will do that now. Huggums537 (talk) 14:32, 1 May 2021 (UTC)
  • Support it may have been useful historically, but now it seems to be an unnecessary duplication of the Help Desk. – Teratix 14:38, 1 May 2021 (UTC)
    • Except the Help Desk does not offer dispute resolution or take edit requests like EAR does even though they might be able to do so if asked, but it isn't offered as a standard feature, so it's not really a duplicate. Huggums537 (talk) 10:57, 2 May 2021 (UTC)
      • There are many other forums that offer dispute resolution (both content- and conduct-related). I'm not sure what you mean by "take edit requests", since those are posted on articles' talk pages. If you're intending to convey the generic meaning of "helping implement a suggested edit" – these are already easily handled by the Help Desk (example from today). – Teratix 01:23, 4 May 2021 (UTC)
        • Teratix, that wasn't the point. You said EAR was a "duplication" of Help Desk, and it isn't because EAR does disputes and Help Desk does not. Neither does Teahouse. Therefore this idea about EAR being a "duplication" is an incorrect assessment. Huggums537 (talk) 05:58, 4 May 2021 (UTC)
          • EAR doesn't seem to "do disputes"; one of its first instructions to potential requestors is that discussions related to content disputes might better be addressed at the dispute resolution noticeboard. But even if EAR did resolve disputes, I would merely update my assessment from "EAR duplicates the functions of Help Desk" to something like "EAR duplicates the functions of the Help Desk and DRN". My core argument would be unaffected. – Teratix 09:38, 4 May 2021 (UTC)
            • Except we aren't discussing the merging of DRN, we are discussing the merging of help forums. So, I think it's an irrelevant part of your core argument. Also, just look at some of the request history and you can easily see that they DO handle disputes. Huggums537 (talk) 14:56, 4 May 2021 (UTC)
              • I don't mind having a discussion, but if you don't accurately represent my views, you won't make any progress towards changing my mind. We aren't discussing the merging of DRN. I never said DRN should be merged. You can easily see that they DO handle disputes. I've clearly explained that the question of whether EAR resolves disputes is irrelevant to my core argument – EAR duplicates the functions of other Wikipedia forums. None of your three replies have actually addressed this point. – Teratix 02:13, 5 May 2021 (UTC)
                • I've been trying to address the point, but you're not accepting it, or I'm not explaining it well enough. EAR offers services that the Teahouse and Help Desk do not, such as those also found at DRN, and other forums. Since we are comparing and discussing the merging of help forums it is an invalid, and false equivalence to compare the services of EAR to the other help forums, therefore it is also invalid saying EAR is a "duplicate" of the other help forums. It is not. It is unique. It borrows from several forums. Likewise, you would never claim EAR to be a "duplicate" of DRN since it offers other services DRN does not such as help requests. DRN is strictly dispute resolution so it would be an unfair comparison, not a "duplicate". Just because something has similar qualities does not make it "duplicate". I don't think people understand what a "duplicate" is, or they are just throwing the term around far too loosely. Either one of these things would be equally sub-optimal. In a nutshell, I think the "duplication" argument (of help or any other Wikipedia forums) about EAR is an invalid one. Huggums537 (talk) 03:46, 5 May 2021 (UTC)
                  Once again, you're not accurately representing my views. I'm not claiming EAR is an exact duplicate of a particular alternate forum, I'm claiming it duplicates the functions of other forums. It is also invalid saying EAR is a "duplicate" of the other help forums. It is not. It is unique. It borrows from several forums. Yes, that's my point; it has no functions that are not fulfilled elsewhere! At this point, you've argued your view in about 20 comments and replies to other editors, without making any headway. In my opinion that comes close to bludgeoning the process. It might be time to step back from discussion. – Teratix 09:15, 5 May 2021 (UTC)
                  I'm glad we could finally get down to the bottom of your actual point. If you had only said this at the beginning instead of claiming it was a duplicate of the Help Desk, it would have saved us a lot of discussion to get to your point. However, there is a big difference between having a long discussion to get to your point, and "bludgeoning the process". It's very poor form to accuse other editors for disruptive editing because of your own lack of being able to explain your point properly in the first place. Any other comments I've made elsewhere have only been in those specific places where I felt a response was needed to make a case for keeping EAR. At any rate, I still feel that your point is wrong anyway because [overlooking that] EAR does in fact perform a function that is not performed elsewhere by virtue of the fact that it is the only help forum that also does disputes and other requests. The very fact that it "duplicates the functions of other forums" is evidence that it is a forum that fulfills a function in a way that no other forum does. With that, I will stop commenting here before anyone else decides to make any wild bad faith accusations. Huggums537 (talk) 13:30, 5 May 2021 (UTC) In other words, EAR is the only forum I am aware of that fulfills the function of combining these other services. Huggums537 (talk) 15:41, 5 May 2021 (UTC)
                  I suggest we not get stuck on semantics and adopt a holistic view. It's not essential to label the editor assistance initiative as a help forum, nor is it necessary to only look at other venues labelled as help forums as potential replacements. (If everyone participating in the editor assistance project were happy to move activity to other areas, for instance, I don't think it matters if those other areas are all help forums.) isaacl (talk) 04:46, 5 May 2021 (UTC)
                  Isaacl, Well, yeah if they were happy to go to other forums then they would just choose to go to whatever they prefer, either DRN or Teahouse, but if they like both, then we would be splitting their interests across multiple venues and creating the very problem that IP user 192.76.8.91 said we would be solving. Huggums537 (talk) 05:22, 5 May 2021 (UTC)
                  Well, you've already argued for the benefits of having multiple venues in which editors can get assistance. Note there's no need to ping me to this discussion. isaacl (talk) 05:31, 5 May 2021 (UTC)
                  Yes, I do argue for more choices and options to be available. I think EAR offers that in a very unique way that others do not. It can do more than the help forums can, and it is not as awful as ANI. However, you seem to be implying that since I've argued for more choices, I shouldn't be making an argument about forcing contributors to go to more places. Well, they are really two different arguments, aren't they? I feel just fine making both of them. Sorry about the ping. The script puts it in, and I sometimes forget to remove it. Huggums537 (talk) 06:13, 5 May 2021 (UTC) BTW, thank you for attempting to point out the apparent paradox of my arguments, as the larger paradox of creating the very problem we are trying to solve by implementing the solution has been revealed... Huggums537 (talk) 07:58, 5 May 2021 (UTC)
                  No, I was just saying I don't need to discuss the advantages of being able to handle questions on one or more venues, as both sides see fit, since you've already done so. It's normal for processes to change over the years, which can mean creating new ones or eliminating old ones. If there is a shortage of volunteers to make one process work effectively, then we may need to consolidate efforts; as the size of the English Wikipedia community grows, it may be more effective to have more specialized initiatives. isaacl (talk) 16:02, 5 May 2021 (UTC)
  • Oppose The OP's claim is false. Page statistics indicate that activity has been quite constant and stable in recent years and is far from zero. Andrew🐉(talk) 15:00, 1 May 2021 (UTC)
    See comparison stats above. Nick Moyes (talk) 07:15, 2 May 2021 (UTC)
    That's also just half the point, the other is that it causes needless redundancy and unproductive decentralization. Aza24 (talk) 07:22, 2 May 2021 (UTC)
    The main thing I notice from the stats above is that the person who adds the most text to the Teahouse is one Nick Moyes. So, what we have here is a takeover bid in which smaller rivals are crushed and destroyed. The trouble is that you do not get economies of scale in Wikipedia. Bigger is not better because wiki pages become unusable when they get too large, becoming unreadable and having technical trouble with template overload. And, if you force people to do things in the one true way, then volunteers who don't care for this will tend to withdraw their labour. So then fewer volunteers are given a larger workload. This may work for a while but you then get burnout of a single point of failure. Notice how the Signpost is in crisis again because its centralised structure is burning out the chief editor once more. My !vote stands. Andrew🐉(talk) 08:56, 2 May 2021 (UTC)
    I kind of agree with Andrew Davidson. This logic that we already have a place being used for help so we don't need another is akin to the family who upgraded their home from a 1 bed/1 bath up to a five bedroom home and said to themselves; "we don't need another bathroom, we need a centralized place for everyone to pee to make things easier". It's completely senseless. Also, there is no redundancy in keeping EAR when you are comparing two forums that offer different kinds of services and EAR offers services the others do not. However, even if it were a "redundant" service, I think my "more bathrooms is better" argument still applies. Huggums537 (talk) 10:57, 2 May 2021 (UTC)
    This bathroom argument does not fit—I can't believe I'm saying this, but more bathrooms is of course helpful because only a single person can use it at a time, but that is not the case with these help venues. Having multiple locations for purposes with no significant difference is just not helpful, it's confusing, dividing up resources and repetitive. And why are we acting like there's some conspiracy here? " smaller rivals are crushed and destroyed" I mean what????? The page views data has shown that the activity at EAR is certainly lower, and at the rate it's descending I see no reason to believe diverted traffic could overwhelm the teahouse or help desk, both of which are extremely efficient. In fact, if anything, it will hardly have an effect at all in the average "workload" at these places. Centralization is not inherently negative, it's the a core practice of WP—the Sign Post is completely incomparable, and has a host of its own issues. Aza24 (talk) 17:05, 3 May 2021 (UTC)
    Splitting up noticeboards only works well in my experience when each of the sub-noticeboards has a specific purpose and takes a specific section of the traffic. Look at some of the successful splits, the village pump, for example, has separate sections has separate sections for policy, WMF relations, technical stuff etc. Can you imagine the mess if instead we'd split it by creating "Village pump 1", "Village pump 2", "Village pump 3" etc, and the rules were "Post on whatever board you feel like"? If we want to split the help boards into smaller sections it should be done by splitting the help desk into topics, e.g. "help with templates", "help with sourcing", "help with policy and guidelines". I don't think the bathroom analogy really fits either, I think the situation is more akin to buying a five bedroom home, then buying the identical home next door, trying to live in both at the same time and wondering why you're ending up with everyone congregating in the same house. 192.76.8.91 (talk) 17:29, 3 May 2021 (UTC)
    In my experience, I see plenty of processes on Wikipedia that work well without being centralized. One example I can think of right off the top of my head are these very help forums under discussion. What evidence has anyone offered that any of these forums have not worked well other than low traffic status? That's no indication whatsoever about whether the forums have or have not worked for the people who are using them. If anything, it's only an indication that the forums with more traffic were advertised more, and the ones with less did not get as much exposure. Huggums537 (talk) 06:19, 4 May 2021 (UTC)
    Having low traffic is inherently bad for a help board - to give people good and timely advice you need a large base of volunteer helpers with a range of experience answering questions. Yesterday someone on the board asked for help with an article dispute involving the sizing of an image in an infobox - it took 8 hours for them to get a response, which basically boiled down to "Usually we leave the image size at default". They asked a follow up question about how to prevent future edit wars, which as of writing this comment, has been unanswered for 14 hours. Looking through the talk page archives this is not an uncommon occurrence. People have laid out other issues with having multiple help boards above and below, not least of which is that it's extremely confusing for newcomers looking to ask a question to be faced with multiple pages with completely different names that do the same thing. 192.76.8.91 (talk) 09:41, 4 May 2021 (UTC)
    And so you think mass consolidating all three forums into one huge conglomerate is going to actually reduce response times as opposed to making them longer? I would seriously rethink that position if I were you. Huggums537 (talk) 14:56, 4 May 2021 (UTC) Also, your decry about response times is rather laughable. I invite you to look at some other consolidated and unified venues that are proving they don't work such as Articles for Creation where the backlog is over 5,000 and the response time is measured in months not hours or you could look at something like the unblock request system and see how you like those response times. Admins should be able to review a block just as easily as a dispute is reviewed at EAR, but they don't and that's what you get for your unified consolidation. Huggums537 (talk) 15:55, 4 May 2021 (UTC)
    The comparison with AfC seems sound. I just took a close look at the Teahouse and found that it's just an unfocussed Q&A board – there doesn't seem to be any of the gentile socialising which its name suggests. There, Nick Moyes explains that "Sadly, quite a lot of our work here is telling hopeful editors that they stand no chance of their pet article becoming a reality..." and so we see that it's mainly a hostile obstruction just like AfC. As an event coordinator who regularly deals with new editors at editathons, I make sure to steer new editors away from AfC and I will now be treating the Teahouse in the same way. And this also shows how careful you have to be with statistics. If the Teahouse is actually having an adverse effect by discouraging newcomers and driving them off rather than helping them, then making it busier may make matter worse. What we need are statistics on the effect of these various help desks. Which of them actually increase productivity and retention and which hurt it? Andrew🐉(talk) 08:38, 5 May 2021 (UTC)
  • Support Make sense to me.Afernand74 (talk) 13:59, 2 May 2021 (UTC)
  • Comment- LOL, "takeover bid". What absolute nonsense. Reyk YO! 14:10, 2 May 2021 (UTC)
  • Support Per NickMoyes's data above. We should not be dividing our efforts because having too many venues confuses newbies. It's best to steer new editors to a single place to ask questions or make requests, and the Teahouse got 30x more traffic than WP:EAR in 2020 so I think we should go with that one. Editors active at EARS can still continue to fulfill requests, just watch the Teahouse for them instead. Wug·a·po·des 06:47, 3 May 2021 (UTC)
  • Support. I don't see the value in having multiple venues with overlapping focus, and I think it creates more issues than it solves:
    • It's confusing for newcomers, who are already confronted with a huge number of noticeboards, help pages and discussion forums. As an example, if you were looking to find out if a source is usable in a draft you're writing you could be directed to WP:TEA, WP:RSN, WP:HD, WP:AFCHELP or WP:EAR, all of which could be suitable places for asking your question.
    • It splits volunteer contributors across multiple pages, which means helpers who are experts in one aspect of editing may miss questions posted on a help forum they don't check often, resulting in lower quality answers.
    • People asking for help on the lower traffic noticeboards will have an unnessasarily longer waiting times for responses. Some of the questions on WP:EAR took 3 hours or more to get a response, which isn't ideal for a newcomer in the middle of writing their first page. 192.76.8.91 (talk) 16:45, 3 May 2021 (UTC)
      Since EAR offers multiple services such as dispute resolution and help services, you are still splitting volunteer contributors across multiple forums. For example, if a volunteer at EAR likes reviewing disputes and helping new editors at one centralized location, they will now have to split their efforts across multiple venues because they will now need to go to both Teahouse and DRN. Huggums537 (talk) 05:29, 5 May 2021 (UTC)
  • Support EAR is a moribund page, and having too many options is detrimental to the efficient operation of any of them. We wouldn't have to if it were a well-used part of Wikipedia. Though it may have been in the past, it isn't now, and we're better served shutting it down. --Jayron32 16:06, 4 May 2021 (UTC)
    Nobody has provided any evidence whatsoever that this so called "moribund" page has been of any detriment to the operation of any of the others in any way at all. Huggums537 (talk) 05:00, 5 May 2021 (UTC)
  • Support The slow proliferation of Wikipedia behind-the-scenes forums is inevitable, but a well-maintained garden needs pruning from time to time. This seems sensible. Ganesha811 (talk) 01:08, 5 May 2021 (UTC)
  • Support - make the pages redirects. — Ched (talk) 03:58, 5 May 2021 (UTC)
  • Support Rather a few large venues than many small ones. CaptainEek Edits Ho Cap'n! 21:23, 8 May 2021 (UTC)
  • Support, when I founded the Editor Assistance project, it was mainly as a reaction to the closure of the old "Association of Members' Advocates", so that people would have somewhere to go and ask for advice. Any more, it does seem rather duplicative of what the Teahouse does, and it makes sense to have a single place to direct people to get help and advice on editing rather than several. Seraphimblade Talk to me 13:39, 14 May 2021 (UTC)
  • Oppose There is no harm in diversity as long as the different venues are clear about what they are for — GhostInTheMachine talk to me 15:34, 16 May 2021 (UTC)
  • Support. Sensible consolidation, as this page isn't so active and doesn't seem to have a distinct identity and purpose from the Help Desk / Teahouse / Dispute resolution. the wub "?!" 00:13, 19 May 2021 (UTC)
  • Support consolidation with the Help Desk.  – John M Wolfson (talk • contribs) 14:44, 23 May 2021 (UTC)
  • Support I think the case made for consolidation is convincing. --Trialpears (talk) 15:27, 23 May 2021 (UTC)
  • Oppose. EAR and the Help Desk have different purposes. At the Help Desk, you ask "how can I do this?" At EAR, you say "I'm not able to do this, can someone please do it for me?" Admittedly, some users ask things at EAR which should have been asked at the Help Desk or Teahouse, but that's not a reason to get rid of it. Maproom (talk) 07:45, 29 May 2021 (UTC)
    So... it duplicates edit requests? ProcrastinatingReader (talk) 09:11, 29 May 2021 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Proposal: Close down Help Desk and replace with Teahouse

I find a clear consensus against this proposal. Editors feel that the Help Desk and the Teahouse have differing purposes, cultures, and intended audiences. Extraordinary Writ (talk) 18:07, 25 May 2021 (UTC) (non-admin closure)
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Before I start, I know that this is most definitely going to be very constroversial, and I just want to put it out there to get some feedback on it. The Teahouse looks like a great replacement to the Help Desk, the hosts system works well, there is a nice onboarding process for new questions, and it looks pretty welcoming in general. I think that consolidating the Help Desk and Teahouse would also help some of the confusion for where to ask questions as well. Thoughts? EpicPupper (talk) 04:44, 9 May 2021 (UTC)

  • I strongly oppose this. I help out at both places occasionally and they are intended for different situations (new vs experienced users). There is no need to merge them and doing so would only add frustration. Elli (talk | contribs) 21:16, 12 May 2021 (UTC)
  • Oppose and no. Huggums537 (talk) 21:58, 12 May 2021 (UTC)
  • Oppose if I want help I go to a help desk. If I want tea I go to a tea house. DuncanHill (talk) 22:03, 12 May 2021 (UTC)
  • Oppose even now, if I need Help in a topic where I don't know anything about the field at all (3D images was an example) I go to the Teahouse, because helpers there know to start from first principles. But for most of my questions, I only need to know how to handle a specific edge case - running me through all of copyright as a primer would be undesired, so I ask that at the Helpdesk etc Nosebagbear (talk) 12:31, 13 May 2021 (UTC)
  • Oppose. The cultures of these two help venues are distinct. Help Desk serves experienced editors and Teahouse newbies. When answering at these venues, I don't need to check the asking editors' credentials and tailor my response accordingly because it's assumed. – Finnusertop (talkcontribs) 12:48, 13 May 2021 (UTC)
  • Oppost per Nosebagbear and Finnusertop. MB 13:24, 13 May 2021 (UTC)
  • Oppose. The Help Desk is inherently designed as and functions as a place for all editors to go, including the experienced ones. the Teahouse is specifically for new editors, needing basic help. ---Sm8900 (talk) 🌍 14:31, 13 May 2021 (UTC)
  • Oppose per above, they have clearly defined and distinct domains, and they are both very active. No need to shut down either. --Jayron32 14:32, 13 May 2021 (UTC)
  • Oppose The two venues are intended to be different in character — GhostInTheMachine talk to me 15:36, 16 May 2021 (UTC)
  • Oppose. The Teahouse has a distinct culture and identity, which research has shown to be effective in retaining new editors. Merging in the Help Desk would dilute this, and reduce its effectiveness. the wub "?!" 00:14, 19 May 2021 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Proposal: Replace Main Page Help Desk link with Teahouse link

  • Support Whilst we're here: to follow up from this discussion which closed with consensus to add a Teahouse link but wasn't sure on which form it should take. It seems like there's probably a consensus to keep TH and HD separate for now. So I think replacing the Help Desk link on the Main Page with a link to the Teahouse would be better. Editors coming from there are probably newcomers, and it's too confusing/bloaty to have them both listed trying to explain the differences IMO. ProcrastinatingReader (talk) 07:46, 24 April 2021 (UTC)
  • Commment Whilst happy to support this, I am slightly concerned about removing the Help Desk link entirely. Wouldn't the following work OK?:
    • Community portal – Bulletin board, projects, resources and activities covering a wide range of Wikipedia areas.
    • Help desk – Ask questions about using Wikipedia.
    • Teahouse - A help desk for novice editors. A friendly space to ask about editing Wikipedia.
    • Local embassy – For Wikipedia-related communication in languages other than English.
    • Reference desk – Serving as virtual librarians, Wikipedia volunteers tackle your questions on a wide range of subjects.
    • Site news – Announcements, updates, articles and press releases on Wikipedia and the Wikimedia Foundation.
    • Village pump – For discussions about Wikipedia itself, including areas for technical issues and policies.
    I wouldn't want to undermine any attempt at gaining a consensus by offering a formal counter-proposal at this early stage, but do add one if it helps. Nick Moyes (talk) 09:12, 24 April 2021 (UTC)
    This works for me, although I'd say put the Teahouse above HD in order, and replace the Help desk description with something like "For more experienced editors to ask questions about editing Wikipedia." I still think I prefer replacing the link altogether, as I think the Teahouse does a better job at helping newbies and that giving unnecessary choices is bad UX and adds a slight bit of friction. ProcrastinatingReader (talk) 09:44, 24 April 2021 (UTC)
  • Support one link. Oppose two links. We don't need and shouldn't have two forums for asking questions (so help desk and teahouse ought to be merged). If we do have two forums, TH should be linked on the main page (so support this proposal). Under no circumstances should both be linked; that will just confuse people. Levivich harass/hound 13:24, 24 April 2021 (UTC)
  • Support Teahouse link on Main Page and, if we have both links, putting it above the Help Desk. If we retain both, the Helpdesk blurb line should include something that it is for non-novice editors. I am neutral to removing the Helpdesk from main page and just having Teahouse there. Nosebagbear (talk) 14:02, 24 April 2021 (UTC)
  • I do not support this good-faith, well-intentioned suggestion. I support adding an additional link to the tea house and I have no objections whatsoever to placing that link above the help desk link. But as long as the help desk is open and we want editors to use it then we need to link to it. I strongly recommend a separate discussion focused solely on whether we can and should consolidate these two efforts; I would strongly support such a motion but it seems to be a much larger proposal than what has been put forth here that warrants a separate, dedicated discussion with a clear header so other editors can see what is being proposed. ElKevbo (talk) 02:59, 25 April 2021 (UTC)
    We do have links to the help desk, from internal pages like WP:Questions, Template:Wikipedia help pages, Template:Noticeboard links, etc. The proposal isn't to scrap all those links. It's just to replace it on the Main Page specifically, from where it's more likely we'll be getting newcomer clicks rather than anything else. ProcrastinatingReader (talk) 15:32, 25 April 2021 (UTC)
  • Link to both but put the Teahouse above the Help Desk. Adding another line won't damage the layout, but it will allow more people to get the assistance they need. —Naddruf (talk ~ contribs) 17:11, 25 April 2021 (UTC)
  • Further comment on Main page wording I'm uncertain what words are best if the Teahouse goes above the Help desk on the Main page links. I've racked my brain, and this is the best I can come up with:
    • Teahouse - A help desk for novice editors. A friendly space to ask about editing Wikipedia.
    • Help desk – Ask questions about using Wikipedia. Aimed mostly at those with some editing experience already.
    (or perhaps...*Help desk – Ask questions about using Wikipedia. Less friendly, more curt and tons of abbreviations!) Nick Moyes (talk) 00:19, 26 April 2021 (UTC)
    Can the wording for the Teahouse just be "A friendly space for new editors to ask about editing Wikipedia"? —Naddruf (talk ~ contribs) 16:21, 28 April 2021 (UTC)
  • Support removing the Help Desk link and replacing it with a link to the Teahouse. The Main Page is likely where new editors will go for information. Experienced editors can still manually go to the Help Desk.EpicPupper 20:26, 27 April 2021 (UTC)
  • Support Per Epicpupper. Two links is just confusing, and the better of the two links for the main page is the teahouse. Calliopejen1 (talk) 04:21, 30 April 2021 (UTC)
  • Support Link to both as proposed by Nick Moyes here. My logic is that we need two different places to get either advanced or novice answers. As a newer user, I'm glad to now be aware the help desk exists. I've been going to the Teahouse for answers, and while I appreciate the friendly, and helpful manner, it kinda sucks getting treated like a day one IP user getting spoon-fed answers. Now I know I have a place I can go to get answers I can handle. I think other users will like to know this too. Huggums537 (talk) 14:48, 1 May 2021 (UTC)
    • But you didn't learn this information from a link on the Main Page, and other established editors won't either. — Bilorv (talk) 23:18, 1 May 2021 (UTC)
      • But still, I learned about Teahouse from my talk page, and if there had been a descriptive Teahouse link on the main page with a contrasting descriptive Help Desk link right below, I most likely would have picked up on it much sooner. Huggums537 (talk) 12:31, 2 May 2021 (UTC)
  • Support: just a link to the Teahouse is preferable (don't make people confused before they've even clicked on a help forum, because they don't know which one is right for them) but a link to both Teahouse and Help Desk would be an improvement, as the Teahouse is friendlier. — Bilorv (talk) 23:18, 1 May 2021 (UTC)
  • I would support replacing with something like {{tq|Need help? Try our Help forum for new users or our Help forum for more experienced users. GMGtalk 22:39, 2 May 2021 (UTC)
    I think GreenMeansGo offers an interesting solution. Huggums537 (talk) 00:01, 3 May 2021 (UTC)
Support replacement of link....only need one and the teahouse is better at recruitment for new editors. This past year has seen a good increase in the amount of individual edits but a decrease in registration.....perhaps the Teahouse can help us fix this problem.Moxy-  23:08, 2 May 2021 (UTC)
  • Support. The teahouse is pretty much the clearing house now. Guy (help! - typo?) 20:18, 3 May 2021 (UTC)
  • Support, I'd be surprised if experienced editors didn't know about the help desk, and more so if they were accessing it from the front page. Accessing help venues from the front page seems like something more aimed towards newer users, hence the use of a teahouse link. Aza24 (talk) 22:21, 3 May 2021 (UTC)
  • Support two links, with the Teahouse link above, and the help desk link reading something like "for more advanced questions." Ganesha811 (talk) 01:09, 5 May 2021 (UTC)
  • Oppose The Teahouse has a misleading name as there doesn't seem be any socialising or group activity and there's certainly no tea. When I attend physical editathons, the tea/coffee breaks are the best bit as sharing refreshments is a good way to bond and engage with other editors. The Teahouse actually seems to be just an unfocussed Q&A board. We already have plenty of those with more accurate names like the Help Desk and Reference Desk. Andrew🐉(talk) 08:54, 5 May 2021 (UTC)
    The lack of tea is indeed distressing. Maybe it should be renamed to Coffeehouse so that we can instead be distressed about the lack of coffee? — GhostInTheMachine talk to me 18:01, 5 May 2021 (UTC)
  • Oppose Add a link to the Teahouse to the 6 links already in Other areas of Wikipedia section on the Main page — as proposed by Nick Moyes right at the start — GhostInTheMachine talk to me 18:07, 5 May 2021 (UTC)
  • Oppose removing the Help Desk link. Support adding an extra link to the Teahouse. --Jayron32 14:33, 13 May 2021 (UTC)
  • Strong oppose linking to both, weak support for switching to Teahouse. Folks, we've been through this before, where we can't agree on the best help link to use, so we end up including two very similar help links, and pretty soon newcomers are overwhelmed with redundant options and succumb to choice paralysis. Whatever happens here, don't let that be the outcome—a single link to either the TH or the HD is vastly superior to linking to both. As for which venue to link, I don't think we've differentiated them clearly enough to be able to say for certain which is most appropriate. De jure, it's probably the Help Desk, as theoretically anyone could be seeking help from the main page, but de facto, it's probably the Teahouse, as in reality it's basically just newcomers using that link. {{u|Sdkb}}talk 05:13, 14 May 2021 (UTC)
  • Oppose Add the Teahouse link and update the Helpdesk and Teahouse link descriptions to clarify the distinction — GhostInTheMachine talk to me 15:44, 16 May 2021 (UTC)
  • Support using Teahouse link. Users coming from the Main Page are more likely to be newbies, so it makes sense to direct them to the forum designed for them. The Help Desk isn't going away for more experienced users. the wub "?!" 00:15, 19 May 2021 (UTC)
  • Comment - There seem to be a roughly equal number of editors here second-guessing what links other people use, or are likely to use, and drawing diametrically opposite conclusions. Proof, if proof were needed, that none of us really know which idea is best. From a website design perspective, it might be a good idea to trial both links and include some kind of referer data. To borrow GreenMeansGo's suggestion, that might look something like this: Need help? Try our [[WP:THQ#RefMain|Help forum for new users]] or our [[WP:HD#RefMain|Help forum for more experienced users]] nagualdesign 19:47, 25 May 2021 (UTC)
nagualdesign The easiest way of tracking what links people actually click on would be to pipe the links through some statistical redirects, like we did when we wanted to see if anyone was using the COVID-19 banner. 192.76.8.73 (talk) 23:18, 25 May 2021 (UTC)
Great idea! nagualdesign 23:23, 25 May 2021 (UTC)
  • Support As the teahouse is more useful for newer editors it should replace the help desk link, my second choice is adding the teahouse link while keeping the help desk link. Jackattack1597 (talk) 10:58, 4 June 2021 (UTC)
  • Support Works for me. ~ HAL333 04:39, 8 June 2021 (UTC)

leave things until the Growth team featured are fully implemented

WP:Mentorship tools gives new users a much easier path to get help. Might want to let those stabilize in production before making major changes. –xenotalk 13:47, 30 May 2021 (UTC)

  Like EpicPupper (he/him | talk, FAQ, contribs) 21:35, 9 June 2021 (UTC)

Restricting GFDL-licensed uploads

 
Why GFDL is impractical for visual media

This is a proposal to make some restrictions on uploading new files licensed {{GFDL}}-only.[4]

GFDL was originally designed for software manuals and it is not good for media because it makes it difficult to re-use the material (see comic to the right). Motivated by the the wish of making it easier to re-use files in compliance with the world-wide wiki-vision the Wikimedia Foundation Board decided in 2009 to stop using GFDL as a sole license while allowing importation of text without the GFDL license. The Wikimedia Foundation Board did not forbid GFDL for media files but encourages people to use licenses other than GFDL, for example CC licenses.

The Wikimedia Foundation Board explicitly mentioned that each wiki could restrict the use of GFDL. The English Wikipedia has removed GFDL from MediaWiki:Licenses and MediaWiki:Licenses/en-ownwork but it is still possible for users to add it manually.

In September 2018 is was suggested to deprecate the GFDL license but at the time no consensus could be formed to limit GFDL on the English Wikipedia.

Some of the arguments against the restrictions were:

  1. We have a lot of non-free files so why should we not allow GFDL?
  2. If we find media that is licensed GFDL we won't be able to copy it to Wikipedia.

Re 1) The idea of a wiki is to share knowledge freely. That is the reason we have Wikipedia! Non-free content is an exception per the licensing policy. It is something a community may decide to have (not must) but the use must be minimal. So while we have non-free files that is not a reason to allow anyone to license their uploads with a license that isn't quite in the spirit of sharing free knowledge. We also don't allow CC BY-NC or CC BY-ND.

Re 2) Technically true, but the use of GFDL for media files is virtually (if not completely) nonexistent outside Wikimedia. When files are uploaded as GFDL in 2021 it is either because it is a copy or a derivative of another file from another wiki-project or because the uploader has specifically chosen to use GFDL.

Several projects already have restricted the use of GFDL, for example Japanese Wikipedia, Commons and Wikivoyage. Other projects are likely waiting to see what English Wikipedia does.

The suggestion is this:

GFDL is not permitted as the only acceptable license where all of the following are true:

  • The content was licensed on or after 1 July 2021. The licensing date is considered, not the creation or upload date.
  • The content is primarily a photograph, painting, drawing, audio or video.
  • The content is not a software logo, diagram or screenshot that is extracted from GFDL software or[5] a GFDL software manual.

The above does not restrict non-free usage of content. If a work that is not a derivative work with a GFDL license is used under a non-free rationale, it doesn't have to be scaled down but other non-free limitations will still apply.

The theoretical possibility of future GFDL-licensed content that would be eligible for non-free inclusion has been brought up as an argument in the past and this is a compromise that will hopefully mitigate that.

I'm not a native English speaker so if there are typos or bad wording you are welcome to fix. Thank you! --MGA73 (talk) 16:37, 10 May 2021 (UTC)

^ The term "GFDL software" was based on a misunderstanding. GFDL was created two decades ago to accompany free software licenses because using free software licenses for manuals was considered odd. GFDL was adopted by some software projects for their manuals, but never for the software itself. Since GFDL-licensed software doesn't exist, it is not possible to extract anything from it. Software logos, diagrams or screenshots can only be extracted from GFDL-licensed software manuals, which do exist. This note was added by Alexis Jazz, coauthor of this proposal. Apologies for any confusion that may have arisen from this error. — Alexis Jazz (talk or ping me) 15:17, 12 May 2021 (UTC)

^ Some voters expressed a desire to restrict GFDL for Wikimedians but not for external sources. Since many Wikimedians are active on other self-published sources like photo sharing sites, social media or blogs, this would be very difficult to enforce. However, we'd like you to know that if a source for fresh GFDL-content is found in the future outside Wikimedia (this is purely theoretical, we know of no such source today), it is always possible to have a new vote to create an exception for that specific source. — Alexis Jazz (talk or ping me) 16:42, 14 May 2021 (UTC)

  • Oppose. We are the free encyclopedia. That means, as far as files are concerned, that any license that is free enough will do. What constitutes a free enough license is defined by the foundation:Resolution:Licensing policy, referring to the Definition of Free Cultural Works (1.0), and GFDL fully meets these these requirements. That Commons no longer allows GFDL-only files is an excellent reason to allow them to be uploaded locally here. The "free" in the free culture movement includes the freedom to choose between equally free licenses. – Finnusertop (talkcontribs) 17:03, 10 May 2021 (UTC)
    Thank you for your comment. I would like to point out that it was the Wikimedia Foundation Board that decided in 2009, that GFDL should not be used on wiki projects. If anyone know what "we" are it must be the Wikimedia Foundation Board? Commons continued to allow GFDL for 9 years before they fully implemented the resolution. Do not blame Commons for the resolution if you disagree with it. --MGA73 (talk) 17:59, 10 May 2021 (UTC)
    It decided it would stop allowing it on uploads as the sole license. At no point did it decide that it 'should not be used on wiki projects'. You would make your point better if you did not state outright falsehoods. Only in death does duty end (talk) 18:15, 10 May 2021 (UTC)
    Sorry it is was not clear. I'm only talking about future uploads. Files allready uploaded can of course stay. Thank you for letting me know. --MGA73 (talk) 19:29, 10 May 2021 (UTC)
    @MGA73: The 2009 resolution implemented meta:Licensing update, which switched licensing of text contributions from GFDL-only to GFDL + CC BY-SA. It continued to allow files under any free license but encouraged to dual license existing GFDL-only files under CC BY-SA where possible. It neither ruled that already uploaded GFDL-only files "should not be used on wiki projects" nor that future uploads under that sole license should not be allowed. The way English Wikipedia implemented it is that "All media licenses existing before the transition remain valid and acceptable to the Foundation. However, the community may choose to modify or restrict the licenses it encourages people to use. For example, emphasizing CC licenses in the upload form and de-emphasizing GFDL licenses." I am not sure if it even allows us to completely deprecate a free license (that's more than just "de-emphasizing" one). Even if it does, I'm of the opinion that we should allow free licenses of files to the maximum extent possible. It's not about which licenses are better/more ideal, but which licenses are free, and that has already been settled since the 2007 resolution which the 2009 one in no way overruled. – Finnusertop (talkcontribs) 13:38, 14 May 2021 (UTC)
  • Support. The link Finnusertop provides links to [6] from where you end up at [7] which also notes the problem with GFDL. Finnusertop speaks of allowing "GFDL-only files" to be uploaded here so they won't be homeless. The reality is that without Wikimedia, GFDL-only licensed photos wouldn't exist to begin with. Not all free licenses are equal. One could even make up a completely ridiculous but technically free homebrew license, and I can only hope we'd reject it if that happened. GFDL is a relic of the past. It served a purpose, once. It no longer does, it has been superseded by better licenses. GFDL is not a practical license for visual media (like photos) and there is literally no reason for a photographer to license their photos as GFDL other than to pester re-users. We shouldn't allow photographers to pester re-users. — Alexis Jazz (talk or ping me) 18:01, 10 May 2021 (UTC)
  • Support. The GFDL is free, and I don't think anyone here is questioning that. The GNU FDL is perfect for free software documentation, as well as any other text where the list of contributors is not as large as Wikipedia's. But this is not the case for media (especially photographs), where it's very impractical to use. We are supposed to make knowledge easier to disseminate. The GFDL doesn't allow that for media. Even the FSF has acknowledged the impracticality of the FDL on those media, which is why they released FDL 1.3 in the first place.

    I'm okay with the compromise that has been put here. I don't see any reason to restrict the resolution of a solely GFDL-licensed medium. But we certainly should discourage solely using the GFDL for non-text, non-software media. pandakekok9 (talk) 05:24, 11 May 2021 (UTC)

  • I'm somewhat meh on this. On the one hand, we shouldn't be afraid of trying to clean up relics of the past to simplify the maintenance burden, and GFDL is clearly a relic of the past. However, because of past media uploaded with it, we'll never be able to get rid of it completely. It appears that we've already done what we can to discourage its use by making it super far from the default. Given that, the number of files being uploaded via GFDL is likely tiny. If someone really wants to use it for some reason and won't contribute their work otherwise, then sure, I hope we'll decide to take the work. But hopefully pretty much everyone will just go and put it on Commons under CC. {{u|Sdkb}}talk 05:41, 11 May 2021 (UTC)
  • Support. I see no drawbacks and even WMF itself is saying it's not ideal for image media. SpartaN (talk) 05:52, 11 May 2021 (UTC)
  • Too early to just prohibit GFDL, instead deprecated and discourage it for a year, especially with an edit filter warning. After a year we can evaluate whether it is still needed at all and prohibit if it really is useless. Graeme Bartlett (talk) 10:14, 11 May 2021 (UTC)
    @Graeme Bartlett: Thank you. The license was removed as a suggested license in 2009: Special:Diff/294994426. So it has been discouraged for almost 12 years now. --MGA73 (talk) 13:40, 11 May 2021 (UTC)
  • Support This is years overdue, how are GFDL-only licenses still allowed here? GFDL really isn't suitable for images, and GFDL-only uploads haven't been allowed on Commons since 2018! Thanks. Mike Peel (talk) 10:50, 11 May 2021 (UTC)
  • Meh leaning support, how many GFDL only uploads have we had in the past 12 years? —Kusma (t·c) 14:23, 11 May 2021 (UTC)
    @Kusma: Thank you. My guess is around 1380 files. --MGA73 (talk) 19:34, 11 May 2021 (UTC)
    MGA73, thanks. The vast majority of these seem rather old, with very few exceptions such as File:RitwikSanyal1.JPG (which is a new upload overwriting an older one GFDL licensed in 2010). Incidentally, the "Upload a new version of this file" dialog doesn't do a good job at checking that the license of the new and old files are identical. —Kusma (t·c) 20:44, 11 May 2021 (UTC)
    MGA73, actually far less. Kusma asked about the last 12 years. (so since 2009) Files older than that which weren't eligible for relicensing would also be included in your query. Who hopper.png was actually PD-self (maybe the uploader was confused?), File:Poktori-2.jpg is PD-self, File:Chuck Close 1.jpg is nonfree, File:Paullusmagnus-logo.JPG comes from m:File:Paullusmagnus-logo (small) reloaded.png and is GFDL-presumed and would be eligible for relicensing as CC BY-SA 3.0 if we accept the GFDL-presumed, this isn't own work?, File:Shared interest lending diagram.PNG was incorrectly tagged as not being eligible for relicensing, File:Tenka Qing.png is identical to w:ja:ファイル:Tenka Qing.png so also incorrectly tagged as not being eligible for relicensing, File:Pb0.9.2 (r86)Win7.PNG is GPL I guess, File:Fence Lake Monument.jpg is also PD-self. And so on. Excluding false positives, overwrites where the original upload is eligible for relicensing but the overwrite isn't and uploads from 2009 and 2010 when some uploaders just weren't aware yet of the license migration, only a small fraction would be left. — Alexis Jazz (talk or ping me) 21:54, 11 May 2021 (UTC)
    @Kusma and Alexis Jazz: I know the number can be discussed. There are also files that are moved to Commons, deleted or where the uploader have later agreed to relicense. I hope everyone will accept if GFDL is no longer accepted for new uploads and therefore use a cc-license. --MGA73 (talk) 07:30, 12 May 2021 (UTC)
  • So, I'm supportive of not allowing new original works in GFDL only; but not so supportive of relegating uploads of existing GFDL works found elsewhere to non-free/fair-use only status. — xaosflux Talk 14:41, 11 May 2021 (UTC)
    @Xaosflux: Thank you. If existing works are licensed GFDL today they can still be uploaded as GFDL. Also in 2 months or 2 years from now. --MGA73 (talk) 19:21, 11 May 2021 (UTC)
    Xaosflux, if it was licensed before 1 July 2021 you could still upload it, even after 1 July 2021. If it was licensed after 1 July 2021.. Just try to find something that was recently licensed as GFDL outside Wikimedia. I'll be surprised if you find anything. IIRC, some years ago a Wikipedian convinced an organization that didn't want to release their work with a free license to release some work under the GFDL because the terms would complicate/inhibit re-use anyway, so they wouldn't have to worry much about those pesky re-users. Errr, yeah. notafish advocated for this all the way back in 2005: Why the Wikimedia projects should not use GFDL as a stand alone license for images. — Alexis Jazz (talk or ping me) 19:40, 11 May 2021 (UTC)
    @Alexis Jazz: so if we are not going to purge the ones we have or consider them non-free, and they would be a rarity -- why would we need to prohibit them? What problem is that solving? I'm fully supportive that any editor-created images should be CCBYA (and really, they should be uploaded to commons not enwiki unless there is some esoteric non-article related reason). — xaosflux Talk 19:57, 11 May 2021 (UTC)
    Xaosflux, we don't want to name and shame, but there are photographers who either multi-license their work with GFDL+CC BY-NC knowing full well the GFDL is largely useless for commercial use of a single image in a printed publication or who will hang on to GFDL until it is no longer allowed to either make a point about GFDL being a bad license (some will know who I'm talking about) or out of some sort of misplaced nostalgia. Not being able to completely dry the room doesn't mean we shouldn't stop people from using the faucet above the broken sink. Use of GFDL-only images in articles can only decline after we've sealed the faucet. — Alexis Jazz (talk or ping me) 20:34, 11 May 2021 (UTC)
    I'm not convinced this is a problem in need of solving, if that photog is an editor - then sure, lets say they can only upload their own work under CCBYSA; If you find one of their pics and think it is useful to include then I don't think we should stop you from uploading it though. — xaosflux Talk 20:57, 11 May 2021 (UTC)
    Xaosflux, I guess I was unclear. All the photographers I'm talking about are Wikimedians. One does not find GFDL-licensed photos outside Wikimedia. — Alexis Jazz (talk or ping me) 21:59, 11 May 2021 (UTC)
    @Alexis Jazz: well - you could, but in any case I'd be fine with the next step being that we disallow anyone to upload their own work here with only a GFDL license. — xaosflux Talk 23:10, 11 May 2021 (UTC)
  • Support GFDL was always a poor fit for images. It is designed for manuals, textbooks, other reference and instructional materials, and documentation which often accompanies GNU software... it can be used for any text-based work, regardless of subject matter. (bold mine). It was used for images in Wikipedia's early days because the Creative Commons licenses didn't exist yet. Once CC became fully developed and it was clear that CC was a better license for use on images, the WMF wisely began the process of migrating image licensing policy to favor CC licensing. Basically, the GFDL was a poor tool to fit the purpose, but was all that we had in 2001 when Wikipedia was founded. When better tools came along, it was no longer needed as a tool. Other than legacy images which have been licensed with only GFDL before we change the policy, we should deprecate any future uses of the license. --Jayron32 14:47, 11 May 2021 (UTC)
  • Support. Flickr does not offer GFDL licensing on uploaded images. Google does not show GFDL licensed images in their "free images only" tools on Google Images. GFDL itself is intended for "manual, textbook or other document"s. For these reasons, we shouldn't allow images solely licensed under GFDL - because not only are they limiting the reuse on Wikipedia, it prevents other image hosting sites from reusing our images as part of their repositories. However, I do not think it should be deprecated as a whole - as long as someone chooses to license their image under another acceptable free license (or to the public domain/CC0), they should be permitted to also select GFDL and license it that way. Furthermore, images licensed only under GFDL should continue to be uploadable, and I do not believe that they should be considered fully "non-free content". If a GFDL image is the only one that is able to be found for a purpose, even if a freer image could be created, I think that the non-free content criteria should accommodate using a GFDL licensed image as opposed to relegating it to the strictness of those criteria - but not a full relaxation thereof. Part of the Wikimedia movement is to encourage free access to information - and we are not accomplishing that by considering the GFDL, with its onerous and strict terms for abiding with attribution, the same as a CC license. The GFDL is great for its purpose - especially when considering digital documentation/media that can easily contain a plethora of required attribution/copying elements without it becoming unusable - but that is not what we consider "free". -bɜ:ʳkənhɪmez (User/say hi!) 22:06, 11 May 2021 (UTC)
  • Support, mainly per Alexis Jazz. GFDL-only is a bad license for images, and it's now obsolete. No reason to continue to allow it, especially since the only people who use GFDL-only for images are Wikimedia editors. In effect we continue to perpetuate a bad copyright practice that doesn't exist anywhere else. Regarding fair use concerns, I think they are mostly theoretical, again since the only people who might ever want (and ever do) upload a GFDL-only image to Wikipedia are Wikipedia users themselves and they upload their own work. The likelihood that we are going to find an image somewhere on the web licensed as GFDL-only that we may want to upload here (as fair use or as a free image) is quite small. But for formal purposes I'd be perfectly fine explicitly specifying that if someone wants to upload a GFDL-only licensed image as a fair use image, that's allowed and that in this situation GFDL-only will be treated the same as a non-free license. Nsk92 (talk) 23:57, 11 May 2021 (UTC)
  • Oppose per Finnusertop, and concerns raised by Xaosflux even though I actually agree Creative Commons is a better license for photos, I have to stick to my beliefs in the freedom to choose. I might otherwise need that far less practical option some day, so I'm against anyone removing it. Also, the idea of adding this WP:CREEPy instruction set about if you uploaded before or after this date is just adding adding more needless confusion to the process that we say we want to remove by getting rid of "3 pages" of licensing. Except, the 3 pages have already been determined to be "free enough" so there is no confusion, but the new policy would bring plenty of confusion while people attempt to make "determinations" about already existing media. I can see all the disputes happening already... Huggums537 (talk) 01:47, 12 May 2021 (UTC)
    @Huggums537: Thank you for your comment. I agree that we should make things as simple as possible. But I think that the only way to make it more simple is to reduce it to "GFDL is not allowed!". I know you oppose but if you had to chose between those 2 alternatives which one do you think is the best (or the least crappy)? --MGA73 (talk) 07:43, 12 May 2021 (UTC)
    Forgive me, but exactly which 2 crappy alternatives are you asking me to choose from? Huggums537 (talk) 10:10, 12 May 2021 (UTC)
    @Huggums537: First alternative is my original (the one you call CREEPy) and the second alternative is "GFDL is not allowed.". --MGA73 (talk) 10:22, 12 May 2021 (UTC)
    Ok. Got it. I vote for a third alternative, just leave things as they are because you can't very easily add free software with a Creative Commons, but you can with a GFDL. This proposal overlooks that fact. Huggums537 (talk) 10:28, 12 May 2021 (UTC)
    @Huggums537: Thank you. But the proposal is that software licensed GFDL can still be uploaded to Wikipedia as GFDL. --MGA73 (talk) 12:02, 12 May 2021 (UTC)
    Yes, I understand your point, but I read your proposal differently because educational and/or instructional software as well can oftentimes also be primarily categorized as video or audio, so the proposal as it is written could cause those softwares to be excluded. These are the kinds of softwares I was thinking of that might get overlooked, but there very well may be other factors that have not been taken into consideration. Huggums537 (talk) 14:29, 12 May 2021 (UTC)
    Huggums537, I might otherwise need that far less practical option some day Actually, you won't. If somehow in the future you find a problem with Creative Commons, you might switch to the basic {{Attribution}} or {{PD-self}} templates, perhaps {{FAL}} or another free license or write a better license from scratch. But not GFDL. instruction set about if you uploaded before or after this date That's actually not in there. There is a standard grandfather clause based in the licensing date. So if you find a GFDL-only licensed file on, say, dewiki or itwiki, you may upload it here if it was tagged GFDL before 1 July 2021. make "determinations" about already existing media Already existing media is simply not affected by this proposal, so there is no need to worry about dispute over that. Except, the 3 pages have already been determined to be "free enough" The real-world example from notafish and the comic explain why GFDL just isn't a practical license for visual media. There appears to be some confusion about "GFDL software", but this appears to be an error in the proposal that I overlooked (I coauthored the proposal): GFDL was created two decades ago to accompany existing free software licenses like the GPL. Before that, the manual that came with free software was typically licensed under the free software license, which was odd because reasons. Software itself does not get licensed as GFDL. — Alexis Jazz (talk or ping me) 14:56, 12 May 2021 (UTC)
    Okay, that addresses a lot of my concerns, and I still do think the Creative Commons is a better license for photos. I'm just not convinced it's better for audio or video or even drawings since they can be comprised of illustration such as flow charts and blueprints etc. You can find a good example of the confusion I'm talking about if you do a Google search for Harry Potter wizarding world DVD game, then try to make a determination whether it should be classified as a DVD video, a software video game or perhaps either or both. Huggums537 (talk) 15:38, 12 May 2021 (UTC) An even better general example that I can think of is a document called an electrical schematic which could be interpreted as both a drawing and/or a manual. Huggums537 (talk) 16:30, 12 May 2021 (UTC)
    The distinctive aspects of the GFDL is the requirement to maintain some of the identity of the original—the specified cover text, any specified invariant sections, and the acknowledgment or dedication sections—while also requiring the modified version to distinguish itself from the original with a different title. For audio or video recordings, frankly I think it would be preferable for someone to craft a new free licence that appropriately takes into account the attributes of those media. For a schematic, sure, issue it within a document that already complies with the GFDL. isaacl (talk) 19:58, 12 May 2021 (UTC)
    I guess that makes sense. Another good example is blueprints because they are architectural drawings, but also construction manuals. Huggums537 (talk) 20:14, 12 May 2021 (UTC)
  • GFDL only makes sense for printed works that can contain within themselves the sections required to be preserved by modified versions, as the licence assumes this context. At a minimum, this means a title page, copyright and licensing page, and history section. I think it is reasonable to restrict its use to files that already contain within themselves a title page, a copyright and licensing page, and if the file is a modification of an earlier one, a history section. Thus even for an image extracted from a GFDL book, I think the uploaded work should contain within itself a title, copyright and licensing, and history pages, either within the image or with everything bundled together in a document file format. This would make it easier for re-users to comply with the licensing terms. isaacl (talk) 02:17, 12 May 2021 (UTC)
    That is a very reasonable argument. However, the argument could also be made that the title of a photo technically constitutes a "title page", and the revision history of the photo a "history page" while licensing does not need to be within the photo itself, unlike other media such as film or software. On the flip side of this argument, we could allow media such as film and free software under a GFDL license because they have titles, revision histories (maybe not so much in film), and licensing within them. Huggums537 (talk) 10:05, 12 May 2021 (UTC)
    @Huggums537: yes we could. But the question is why should we? WMF conluded in 2009 that GFDl is not good for Wikipedia so they decided not to use it as the sole license. There are better alternatives so why not use them? --MGA73 (talk) 10:32, 12 May 2021 (UTC)
    Because in the case of drawings, audio, and video this could be instructional or educational in nature such as a type of course work that is more suitable to a GFDL license than Creative Commons for the authors. While we are a "free knowledge" site even CC acknowledges authorship [through attribution]. Huggums537 (talk) 10:49, 12 May 2021 (UTC)
    If you squint just right, and turn your head just so, you can sort of invent ways for other forms of media to have equivalents to the sections described by the GFDL. (For a photo distributed as its own individual work, separate web pages is not one of them, as the license refers to sections and pages of the document itself. Also reproducing the license in full within the document is mandatory.) But the fact remains that the licence was written assuming the context of a printed work with specific sections contained within the document, and thus it makes most sense to limit the use of the license to works within this context. isaacl (talk) 14:42, 12 May 2021 (UTC)
  • Support GFDL is impractical for new content, and if people practically can't reuse our content, then it's not really free (as in freedom). It is important that we have an exception for legacy content though like Commons has, as there is a lot of legacy early 2000s content out there that was licensed as GFDL just because it was the popular license at the time (I uploaded some to Commons a few months ago). Legoktm (talk) 15:29, 12 May 2021 (UTC)
  • Support. Ruslik_Zero 20:47, 12 May 2021 (UTC)
  • Oppose. "Is it helpful? Is it necessary? Is it kind?" Does this solve an actual problem Wikipedia has? Or only an imagined one, that will make uploading (and RE-uploading) relevant media more difficult? Does this improve the encyclopedia or its usability or its RE-usability? If not, vote NO. 71.62.227.79 (talk) 02:52, 13 May 2021 (UTC)
    Does this solve an actual problem Wikipedia has? Didn't want to name and shame, but I guess there's no avoiding it eventually. Here's an example. that will make uploading (and RE-uploading) relevant media more difficult? GFDL hasn't been a default option for years. Licensing date counts, not the upload date. Is it necessary? Is it kind? If you simply don't care, why require a license at all? Even easier. Yes, it's necessary. or its RE-usability? Yes, that one. See this real-world example from notafish and the comic above. — Alexis Jazz (talk or ping me) 04:27, 13 May 2021 (UTC)
  • Strongly oppose. I use the GFDL because I have frequently seen images I uploaded under Creative Commons used outside Wikipedia without attribution because it is widely assumed to be equivalent to public domain. I no longer upload my photos to Commons because they adopted a proposal like this. Jonathunder (talk) 16:41, 13 May 2021 (UTC)
    Lots of people erroneously assume that Wikipedia's text is PD and violate the license. Doesn't mean we should go back to GFDL only for the text. —Kusma (t·c) 16:51, 13 May 2021 (UTC)
    Thank you for your comment. Sadly there are always someone that do not care about copyright. I do not think that it makes much difference to them if you add CC or GFDL. May I ask if there is always attribution for the files you have licensed GFDL? --MGA73 (talk) 17:20, 13 May 2021 (UTC)
  • Strongly oppose per Finnusertop, 71, and Jonathunder. We should not be restricting the use of free licenses because a sister project does (and quite a few people have complicated relationships with that sister project); banning GFDL uploads because Commons does makes about as much sense as switching to CC-BY because Wikinews uses it. As an active editor at Wikivoyage, that comparison is in turn totally inappropriate, because Wikivoyage has completely different goals to Wikipedia and GFDL text licensing genuinely does serve it poorly; Wikivoyage articles are intended to be used in print more often than Wikipedia ones (see our goals and non-goals and our guide for Wikipedians working cross-project), where printing out the GFDL license is a much bigger concern. However, files uploaded locally to the English Wikipedia are implicitly intended for use on the English Wikipedia, a project with very little focus on print; they may be used in many places, including as print images, as their free license encourages, but the situation depicted by that comment or described by Wikivoyage is downplayed because it simply isn't the original use case. GFDL is a free license, and while we perhaps don't encourage it as strongly as our preferred ones, we can use it just as any other. Banning GFDL uploads because they're 'outdated', as some have encouraged here, makes as much sense as banning CC-BY/CC-BY-SA 1.0 or 2.0 ones for the same reason, and I can tell you there are many useful files with those licenses. Vaticidalprophet 09:32, 14 May 2021 (UTC)
    @Vaticidalprophet: Thank you for your comment. You should not restricting GFDL because Commons did. You should restrict it because the Wikimedia Foundation Board and many other agree that GFDL is not a good license and it does not match the vision of Wiki. Also I think you are wrong about photos uploaded to English Wikipedia. They are very often copied to other projects and used there. There is no such thing as "for Wikipedia". The purpose of Wikipedia is to share with everyone!
    I think that if the only reason to keep GFDL is because "Commons is stupid" then it is not a good reason at all! --MGA73 (talk) 11:34, 14 May 2021 (UTC)
    There is no such thing as "for Wikipedia". The purpose of Wikipedia is to share with everyone! Then it's a good thing I said exactly that, then, isn't it? Wikipedia content is intended to be shared under a free license, not "a free license except this one because it might be awkward". Wikivoyage has a completely different purpose to Wikipedia as regards GFDL compliance, i.e. it's intended to be used in print form, and so "GFDL might be awkward in print" is an actual strong argument. Commons is an intended dedicated image repository, and images hosted on it are being used for that purpose, while Wikipedia is not an image host, and images hosted on it are targeted at Wikipedia articles; that's not to say they can't/shouldn't/won't be shared elsewhere, because they're free images under free licenses, but it does mean "this might be awkward to use in a certain form it's far less likely to be used in than these other random things" is a singularly unconvincing argument. Banning GFDL for new uploads can only hurt Wikipedia's free mission, it cannot help it, because it would only serve to prevent the uploads of files licensed under a free license. There is absolutely no circumstance where banning a free license for reasons of "it might be awkward to use in a specific way" is helpful towards a free mission, ever. Also, there is no need to respond to, let alone ping, every opposer. Vaticidalprophet 11:42, 14 May 2021 (UTC)
    Sorry you see it that way and noted your point. I try not to repeat myself. When I comment or ask it is because I would like to hear the arguments. I do not claim always to be right and if someone make the right arguments I might even withdraw my suggestion. As you can see it has been modified a bit because it was unclear. --MGA73 (talk) 12:27, 14 May 2021 (UTC)
    makes as much sense as banning CC-BY/CC-BY-SA 1.0 or 2.0 ones for the same reason There is a compatibility mechanism for CC 2.0 with newer versions. There is no compatibility for the 1.0 license, but: CC-BY 1.0 includes "credit reasonable to the medium", so unlike GFDL it is feasible to comply with the license terms. Also I have never seen any not-ancient content with a CC 1.0 license. (unlike 2.0 which is still commonplace because of Flickr) — Alexis Jazz (talk or ping me) 17:16, 14 May 2021 (UTC)
  • Oppose I would support a limitation on GFDL for Wikipedian-created content, but if we are reusing a third-party's work that happens to be licensed GFDL and it otherwise meets all other appropriate factors, I do not see any reason to limit that use. We should not be cutting off a potential source simply because of all the free licenses they could have used they used one that's not the best option for images, but otherwise still compat with "free license" otherwise. --Masem (t) 13:26, 14 May 2021 (UTC)
  • Weak oppose per above, modulo the fact that I believe the GFDL is not a "free" license. If someone uses GFDL-only, just ask them to dual license and give them the reasons why it is helpful; we don't need to create more convoluted rules that no one will read. If something is suitably licensed and improves the encyclopedia, we should be able to use it. Wug·a·po·des 23:42, 14 May 2021 (UTC)
  • Support, very well thought out proposal that's worth enacting. It's also better late than never to follow the WMF's guidance. Setting the restriction based on license date, not upload date, is a reasonable way to allow older material while cleaning things up for the future. I agree with Alexis Jazz that this restriction can always be revisited if a significant amount of fresh GDFL content appears in the future. -M.Nelson (talk) 14:12, 15 May 2021 (UTC)
  • Weak Oppose the GFDL is clearly suboptimal for images to put it mildly, and it's nice to be able to copy things to commons so other projects can take advantage of them. That said I don't like the idea of rule creep here; we can always request dual-licensing, and if someone really only wants to contribute images under the GFDL that's not ideal but it's still improving the encyclopedia and I see no reason to stop them. Regards, 31.41.45.190 (talk) 01:56, 16 May 2021 (UTC)
  • Note that most of the concerns raised by the opposers here have already been solved by the compromise put up here. Let me highlight that part:

    The above [proposal] does not restrict non-free usage of content. If a work that is not a derivative work with a GFDL license is used under a non-free rationale, it doesn't have to be scaled down but other non-free limitations will still apply.

    The theoretical possibility of future GFDL-licensed content that would be eligible for non-free inclusion has been brought up as an argument in the past and this is a compromise that will hopefully mitigate that.

    Material that is solely GFDL-licensed after the cut-off date of 1 July 2021 can still be used in the English Wikipedia, just under a non-free rationale. And they are exempted from the resolution limit. So before opposing this proposal, please check first if your concern has already been resolved by the said compromise. pandakekok9 (talk) 05:52, 16 May 2021 (UTC)

Your solution is to use a non-free rationale for freely licensed media. Thats ridiculous. Only in death does duty end (talk) 13:45, 16 May 2021 (UTC)
@Pandakekok9: Exactly what OID said, I saw your proposal it just didn't make any sense, sorry. Regards, 31.41.45.190 (talk) 14:21, 16 May 2021 (UTC)
It makes no sense to require a non-free rationale for content that shares the same license as our text. Beyond that, we have enough trouble getting people to properly use non-free rationales for stuff that is completely non-free so I'm suspicious expanding its use to copyleft media will do anything more than confuse people further. It's a clever idea, and I'd prefer it over forbidding them entirely, but it doesn't resolve my concerns. Wug·a·po·des 22:06, 16 May 2021 (UTC)
This is a misunderstanding of our licensing. The only contributions which are actually dual-licensed are those which came before the date we switched to CC BY SA 3.0. The contributions made after are solely CC by SA 3.0. (Generally anyway, a few people dual license CC and some others after that date.) See our reuse page. Going by the counts at Wikipedia:Size_of_Wikipedia, that means there are some 3.5 million articles which are CC BY SA 3.0 alone. Izno (talk) 00:43, 17 May 2021 (UTC)
@Izno: I was going off the text at the bottom of my editing box which says By publishing changes, you agree to the Terms of Use, and you irrevocably agree to release your contribution under the CC BY-SA 3.0 License and the GFDL (emphasis added). This text seems based on our (legally binding) terms of use, specifically foundation:Terms of Use/en#7. Licensing of Content which by my reading says that all our content is available under the GFDL and Re-users may comply with either license or both. I haven't gone through the history of our ToS, but unless that was recently changed the entire (text of the) encyclopedia is available under the GFDL. Wug·a·po·des 01:34, 17 May 2021 (UTC)
Oh gosh, the inconsistency. The Meta FAQ on the point is interesting, as is the introduction to the update itself. Maybe I'm the one reading it wrong. Izno (talk) 02:12, 17 May 2021 (UTC)
See meta:Licensing update/Questions and Answers#Replacing GFDL with CC-BY-SA?. As per GFDL, modifications of older GFDL content has to continue to be available by GFDL. For completely new content, say a new article, individual editor contributions are made on the basis of dual licensing. But with the licensing update, there is the option to import a purely CC-BY-SA-licensed work from an external source. The resulting content would only be licensed CC-BY-SA, since it would be incorporating non-GFDL content. isaacl (talk) 02:31, 17 May 2021 (UTC)
Isaacl, As per GFDL, modifications of older GFDL content has to continue to be available by GFDL. Technically what you say is correct, but it doesn't apply here. Talking about the wikitext, it has been relicensed as CC BY-SA 3.0. So modifications of that content can be published with a BY-SA and/or GFDL license. We could simply abandon GFDL for wikitext completely without repercussions. — Alexis Jazz (talk or ping me) 03:09, 19 May 2021 (UTC)
I stand corrected: it's true the Wikimedia Foundation could set a cutover date where the snapshot of Wikipedia at that time is made into a derivative work following the terms of the CC-BY-SA licence, and so going forward, all text content would be relicensed soley as CC-BY-SA. isaacl (talk) 05:11, 19 May 2021 (UTC)
  • Support The restrictions of the GFDL, when applied to most files, are sufficiently restrictive for the license to be less free than what we would otherwise expect. --AntiCompositeNumber (talk) 01:49, 18 May 2021 (UTC)
  • Strong support. Visual media that are licensed solely under the GFDL do not meet the definition of a free cultural work. In particular, the freedom to copy and redistribute the work must be "practical" and "without any risk". This change is long overdue. Kaldari (talk) 20:08, 20 May 2021 (UTC)
  • Strong support - doesn't meet free standard and can't be used on Commons and thus other wikiprojects. This decisively makes the work non-free for all intents and purposes. This shouldn't even be a tough call. Magog the Ogre (tc) 23:20, 24 May 2021 (UTC)
  • Support. GFDL is waaayyy too easy to abuse. For example, let's say I have this picture of a fetal pig I took in Forensics class one day. It's my work, and I want to use it on our article on fetal pigs except I want to punish re-users just because I can. Besides forcing people to provide a copy of the license (just for using my singular picture of a fetal pig), here's what else I can do:
    1. Use {{GFDL-self-with-disclaimers}} to require re-users provide a copy of all our disclaimers. See Wikipedia:GFDL standardization.
    2. Mark my userpage as a "Cover text" which means it is also required to be included.
    3. Add a bunch of invariant sections. These are basically appendices which have to be included in every re-use in order to remain compliant with the license. I am not aware of any restrictions regarding the use of invariant sections.
    I don't think anyone should be allowed to do this. –MJLTalk 01:16, 25 May 2021 (UTC)
    I can see the disclaimers thing, but I'm not sure whether you're allowed to use the latter two on Wikipedia. Wouldn't that already make the work undisputably nonfree? If such things are allowed on Wikipedia all this time, we are facing an even larger problem than before. pandakekok9 (talk) 10:37, 30 May 2021 (UTC)
  • There have been questions about the number of files and also some said that we should not say no to freely licensed files from external sources. So I checked a bit to find out more about the files. Sadly there is no easy way to find information about deleted files so the numbers below does not include deleted files (copyvios, orphan files no longer usable and files moved to Commons).
As of today there are 1,343 files in Category:Wikipedia license migration not eligible that have no creative commons license. It is fewer than the 1380 I mentioned earlier but some have been deleted as copyvios, some was licensed wrong and a few users relicensed.
999 files are own work (have the templates GFDL-self, GFDL-user or self) and 344 files are not marked clearly as own work.
After the change of license in 2009 there were still many uploads with GFDL by many different users. Today there are 331 files from 2010 and they are uploaded by 198 different users. The number dropped over time and there are only 11 files from 2017 uploaded by 9 different users.
When Commons restricted use of GFDL in 15 October 2018 the number increased. 394 files are uploaded after that date (some are an edited version of an older upload).
  • But of the 394 files 365 is uploaded by 1 user and all uploads in 2021 is made by that user.
  • And of the 394 files only 2 are not marked as own work. The 2 files that are derivated from files on Commons licensed both GFDL and cc-by-sa-3.0 so they should be relicensed.
So the numbers conform that it is only Wikipedians that still use GFDL (primary one user). --MGA73 (talk) 19:16, 25 May 2021 (UTC)
For all of 2020, there is only one image left (that isn't from Jona) that maybe isn't copyvio: File:MV Alta, Co. Cork, February 2020.jpg. And here is the rationale for using GFDL: "Yo, thanks for your query. Fundamentally I'm wary of relicensing this photo as CC as neither I nor the original photographer wanted it being used willynilly outside of Wikipedia, and GFDL seemed the best bet for that." That is what GFDL is used for. — Alexis Jazz (talk or ping me) 03:18, 26 May 2021 (UTC)
  • Support per User:MGA73, but the second bullet point, "* The content is primarily a photograph, painting, drawing, audio or video" is too narrow and should include all types of media and image files including both still and animated computer graphics, as well as files representing 3D objects. Better would be "* The content is a media file representing still or moving images, 3D objects, or audio". MichaelMaggs (talk) 11:43, 1 June 2021 (UTC)
  • Support per above. On a side note, I can't tell you how many times I have accidentally clicked on GDFL when trying to publish an edit. ~ HAL333 04:41, 8 June 2021 (UTC)
  • Support per nomination & others, although isn't this really an issue for Commons? Most free media will be uploaded there, not on English Wikipedia. There's essentially no good reason to use GDFL for images any more, so this will exclude the "clueless user selects a license at random" case and the mostly-hypothetical but still bad malicious "trolly GDFL" case where a user just wants to lock down their image in a non-standard way. SnowFire (talk) 17:10, 11 June 2021 (UTC)

The future of the Book namespace

Should the book namespace be deprecated and if so what should deprecation include? --Trialpears (talk) 18:27, 15 May 2021 (UTC)

This RfC will involve several different but related proposals. First of all I will give some history on the book namespace since many editors are likely to be unaware of the namespace. I will also explain the current status and link to some previous discussions (not required reading by any means). Then I will outline a few possible actions each in their own section. When the RfC is closed the consensus for each proposal will be evaluated and hopefully there will be a consensus on how to deal with this zombie namespace. --Trialpears (talk) 18:27, 15 May 2021 (UTC)

History (book namespace)

The book namespace was introduced in 2009 as a way to download or print a collection of articles. To do this you use Special:Book to select a collection of articles you want in the book. divide them into chapters and choose some rendering settings. You can also give it a cover image, change the color of the book, choose rendering settings, and divide the articles into chapters.

After this was done you could either purchase a printed copy from PediaPress or download it in a wide variety of formats including PDF using the Offline Content Generator.

Eventually the Offline Content Generator became outdated and unmaintainable. Bugs and security issues could no longer be fixed so the Wikimedia Foundation turned off the book rendering service on all Wikimedia wikis in October 2017. Since then, Wikipedia books have only been available either in physical form from PediaPress or through MediaWiki2LaTeX (de:b:Benutzer:Dirk Huenniger/wb2pdf/manual). The issue with this is that we now require readers to visit a third party site to access our content and either purchase it or wait for a significant amount of time to get access to the book to render if MediaWiki2LaTeX even works properly for you. A large proportion of our books are too long to render and a good chunk of the rest have things like navboxes breaking the renderer and even if it in theory should work I've had times were it randomly stop or I can't download the book for unexplained reasons. If you want to do it locally (which I've heard works significantly better) you will have to do it on Linux or set up a virtual machine. After investing a few hours trying to do this I gave up so I haven't tested that personally. If you want a PDF of an article I would instead suggest using the "Download as PDF" option in the side bar which can reliably give you a PDF version in seconds.

Currently the namespace has total pageviews on the order of a popular portal like Portal:South Africa. This is spread out over a bit over 6000 pages. During a normal month without significant editor activity most books don't get a single view and just 1.5% of books get a pageview a day. The most popular one Book:Fundamental Data Structures gets just 15. It's also worth noting that these figures are significantly inflated by my and others recent maintenance work which has resulted in thousands of these views.

There have been several previous initiatives to hide books from readers, the biggest three being 2019 removal of book creator from side bar and suppression of many links, 2021 removal of remaining links and 2021 deletion of some book related templates. The latter two were basically unanimous decisions.

Books are still considered a community facing namespace and are on help pages often referred to as "community books" and are supposedly being community maintained. They are indexed by search engines. You can create books in the book namespace using Special:Book, but they can also be created in userspace as Category:Wikipedia books (user books). The namespace is listed as unused at WP:Namespace.

PediaPress links to a few of our books at the Catalog, which may or may not be possible to retain if the books are deleted on Wikipedia. It would continue to be possible to use PediaPress as long as Special:Book isn't removed. Either by not saving the book on wiki and saving it at PediaPress or by saving it user space.

The question now is how should we handle books in the future. This could include alternatives from keeping the status quo since it's barely seen by anyone to complete deletion of the namespace including all books within it. --Trialpears (talk) 18:27, 15 May 2021 (UTC)

In 2019 PediaPress implemented a new PDF render, which is used for the "Download as PDF" link, but it is clear in phab:T186740 that book support will not happen.--Snævar (talk) 19:32, 15 May 2021 (UTC)

  • Comment. I'd like to add some further remarks to that. The original agreement was between the WikiMedia Foundation (WMF) and PediaPress. They wrote our original rendering engine, the Offline Content Generator (OCG). They also wrote one for themselves and at first you could download a free PDF softcopy in their format if you did not want to pay for a dead tree. They subsequently withdrew the softcopy option. Meanwhile OCG never worked right. PediaPress's attempts to fix it were constantly overtaken by changes to the templating and other games in both software and user spaces. Also, Wikibooks gained in functionality and content. So the early interest in our books faded. We have twice tried and failed to develop a replacement, MediaWiki2LaTeX is suffering from under-development and Collector, a replacement for OCG promised by PediaPress, has also gone silent since its alpha test site appeared. It has become impossible to know whether a viable in-house renderer would actually attract users; we have never had such a thing, volunteer effort is insufficient to deliver it and WMF have consistently refused to resource its development. I'd suggest that we have reached the crunch decision: is there any point in having both Wikipedia:books here and Wikibooks? Isn't one enough? Fiddling with our dying namespace is merely prolonging the agony. We need to either resurrect it or drive a stake through its heart. Although my preference lies with the former, I am under no illusions that the majority consensus would be for the latter. I used to believe that we owed PediaPress to keep it going, but on reflection they pulled the free downloads of their format from under our feet for expressly commercial reasons, and let us down again over Collector; we owe them nothing any more. I can always maintain book pages manually in my userspace and upload them to MediaWiki2LaTeX or whatever, I don't need anything else. — Cheers, Steelpillow (Talk) 14:04, 16 May 2021 (UTC)

Proposals (book namespace)

Formally deprecate the book namespace

The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion. A summary of the conclusions reached follows.
There is a consensus to formally deprecate the book namespace, describing pages within it as historical or not maintained. (non-admin closure) (t · c) buidhe 09:22, 24 May 2021 (UTC)



This would include changing the language used at pages such as Wikipedia:Books, Help:Books and {{Saved book}}. Books in the book namespace would no longer be described as community maintained. --Trialpears (talk) 18:27, 15 May 2021 (UTC)

  • Support This at a minimum should be done. The namespace does not enjoy community maintenance and we should make that clear. Calling it deprecated will make it clear for anyone that books aren't really supported. --Trialpears (talk) 18:27, 15 May 2021 (UTC)
  • Oppose Books still exist, fix the software and books will come back to life. Headbomb {t · c · p · b} 18:42, 15 May 2021 (UTC)
  • Oppose What? Per Headbomb. Throwing out the baby with the bath water. Fix the software! Littleolive oil (talk) 18:47, 15 May 2021 (UTC)
  • Comment @Headbomb and Littleolive oil: The status of fixing the software is that nothing has happend since 2017 and the extension is only bugfix maintained. I can not imagine a developer being willing to spend many weeks or months of work to get this up and going again, especially when the download as PDF feature exist. The amount of pageviews (many of which would not want to download a book) is like I said comparable to one popular portal which I can't imagine any developer justifying spending that kind of time on with 100s of more important projects. If the software is fixed usage may return to pre removal levels. December 2016 the namespace got a bit over 6000 daily pageviews on average which is comparable to a page like Dog. If you want to hold on hope that it will one day be fixed that's reasonable but I thought I should at least explain why I can't see that happening. --Trialpears (talk) 19:04, 15 May 2021 (UTC)
    Your lack of imagination is not ground for the deletion of books. If the PDF renderer works, one could make use of it to batch render collections of articles/books, and that would be a perfectly good basis for book-rendering to build upon. Headbomb {t · c · p · b} 19:12, 15 May 2021 (UTC)
    Or... one could just print multiple PDFs with what we have now? No one uses books, and it seems no really ever did. TP is hardly speculating, if it's easy as you say, why hasn't anyone done it yet? Aza24 (talk) 19:20, 15 May 2021 (UTC)
    Chicken and egg issue. No one uses books because the software is broken. Fix the software, people will use books again. They were decently popular back when the renderer worked. As for "why hasn't anyone done it yet", ask the WMF. Headbomb {t · c · p · b} 12:56, 16 May 2021 (UTC)
    Some data about usage is at User:SD0001/Books. It shows that the vast majority of this namespace has single-digit monthly page views. Most books have very few editors. Max number of distinct editors who have edited a book is 36 for Book:The Beatles. About half of all books have 2 just distinct editors (the 2nd edit mostly being AWB/HotCat). This doesn't indicate that they were decently popular ever. – SD0001 (talk) 19:46, 16 May 2021 (UTC)
    Yes, that's rather normal after all links to books were removed from the mainspace in 2020. See the clear drop in [8], and [9], [10] for examples. Headbomb {t · c · p · b} 21:33, 16 May 2021 (UTC)
  • Support—I just made a book on Gilbert Reaney with one of the external softwares and see nothing of use. In fact, the only differences I see from the PDF & Printable version downloads are a formal table of contents, title page and (for some reason) every single WP link turned into a url to that Wikipedia page in a note. I mean, what nonsense! We shouldn't support something as unhelpful as this, especially when a)there are 3rd party alternatives b)We literally have PDF and printable versions already c)it has remained unfixed for 4 years d)No one even used them when they were functioning! Aza24 (talk) 19:16, 15 May 2021 (UTC)
  • Support - books are like portals: just not in enough demand by readers to be worth spending community resources on. And there are existing services to create PDFs. WikiBooks should be it's own wiki or inter wiki tool, and it can create books from any language wiki not just enwiki; but it's a distraction as an enwiki namespace or enwiki project. Levivich harass/hound 19:21, 15 May 2021 (UTC)
  • Support per nom, Aza24, and Levivich. Books was an experiment that we tried, which is fine. It failed, which is also fine. Let's acknowledge the failure and move on, not continue to waste effort trying to maintain it. {{u|Sdkb}}talk 20:18, 15 May 2021 (UTC)
  • Support as secondary option to deletion for the reasons given in the comment below. ƒirefly ( t · c ) 20:30, 15 May 2021 (UTC)
  • Support There is a real trend hereon WP to hang on to things that don't work anymore, are inactive, etc. It's a bad trend and the book namespace is a perfect example of it. Beeblebrox (talk) 20:50, 15 May 2021 (UTC)
  • Support. As a long time reader and on-off IP editor I've had a few attempts at using the book namespace over the years, but each time it has been a universally terrible user experience. It's common to find books that have significant NPOV, weight, and design issues, and let's not kid ourselves that the book namespace is community maintained - it's not. It's a dumping ground for people's personal book projects which are occasionally fixed up by a passing wikignome. To illustrate this let's have a look at the user experience for finding a book on a random topic that any encyclopedia should be able to cover well - "European history"
Extended content
  • So, to start Book:European history doesn't exist, not as a book, nor as a redirect to something relevant. Not a good start in terms of ease of searching when the mainspace equivalent (European history) has existed since 2002 and averages over 1000 page views a month. The internal search engine turns up 3 books with overlapping focus - in a community maintained namespace surely duplicate pages should be merged?
    • The first book that turned up was Book:EuropeHistory, which illustrates all the worst problems with books. Created by a single user in 2009 - 2011, the only edits since have been the occasional bit of wikignomery. Massive due weight problems: why does the roman empire get a total of 4 articles, while the European union gets 134? Why is there no mention of world war II? What is cruft like List of tallest buildings in the European Union, Galileo (satellite navigation) and European Union acronyms, jargon and working practices doing in a history book? This is massively out of date and has been abandoned since it's user created it - despite covering the European union in an inordinate amount of detail there's no mention of Brexit?
    • The second book that turned up is Book:History of Europe. This has better focus IMO, but it consists only of a chronological list of articles with no attempt to sort the content into chapters. Created by a single user in 2010, only edits since have been wikignomery and an aborted attempted merge, so the book is missing anything that happened in the last 10 years.
    • The final book that turned up is Book:Europe1. This is the best of the bunch in my opinion - it has a well defined chapter structure, a reasonable amount of articles and is relatively up to date (though that's just because it was created more recently, again it was created by a single author in 2017 and has seen only gnoming edits since). Even as the best of them I still don't see how it offers a better user experience than History of Europe, which sorts the same articles into the same basic time periods and is much more readable, and at this title it isn't something that readers are going to be able to easily find. The last two sections of this book are duplicated (and have been since creation 4 years ago) seemingly without anyone noticing.
  • Having now found a reasonable book I have a few options to read it - I can either click through each of the articles in the list using it as a poor substitute for a summary style article or list, I can muck about setting up a Linux virtual machine to export the pages to latex then compile that to a pdf, or I can pay a third party company to print me a paper copy of an electronic encyclopaedia that will be outdated in a couple of years. Who is this aimed at? People who can't access the website reliably but can download enormous pdf files on a regular basis? People who can't afford internet access but can spend $$$ on print on demand books? People who need an easy to use book creation wizard but know how to set up Linux and use latex? I just don't see what demographic this is targeting.
  • Overall the book namespace is just not a good or useful experience for readers, and there is no sign of any community actively curating these books. I would support depreciating the community book namespace and moving all books in it to the userspace of the original creator, as in my experience in 95% of cases they will be the only person to have actually added any content to the book. 192.76.8.91 (talk) 21:05, 15 May 2021 (UTC)
  • Support and all the ones below too. I find the "just fix it" argument weak. If somethings been broken for this long and no one wants to fix it, its probably not worth fixing. I am struggling to see the value of this namespace even if it did work properly. Aircorn (talk) 21:49, 15 May 2021 (UTC)
  • Support. Please! Gog the Mild (talk) 21:59, 15 May 2021 (UTC)
  • Oppose for lack of any benefit in doing so. Nemo 22:00, 15 May 2021 (UTC)
    The benefit is that more editorial time gets spent on articles, which is what matters in the long run. – SD0001 (talk) 10:12, 16 May 2021 (UTC)
  • Support - This has been broken for years. There doesn't seem to be much of a push to fix this, and per Aircorn, this isn't really looking like a thing a whole lot of people want. If a few users desire something like this, they can do it in their userspace, but as a whole, the book namespace seems to be dead. Hog Farm Talk 23:01, 15 May 2021 (UTC)
  • Support. It's a feature that never gained much traction and is obsolete now. -- RoySmith (talk) 00:20, 16 May 2021 (UTC)
  • Support. —¿philoserf? (talk) 02:09, 16 May 2021 (UTC)
  • Support. Nobody seems interested in maintaining any of this. If volunteers apply, perhaps it could be revived one day. For now, let it continue in userspace. — Alexis Jazz (talk or ping me)
  • Support per evidence presented as well as IP192's. --Izno (talk) 03:27, 16 May 2021 (UTC)
  • No Vote on the one hand, it's been broken for years and nobody has cared to fix it. Also, this feature should really be in user-space (for individual users' books) or project space (for collaborative efforts on topics). While it should be a good idea, I'm not sure we want to encourage people to do churnalism publishing of "Wikipedia content books" on self-publishing platforms. No vote myself, but unless somebody comes up with an idea to improve the usage of the namespace this will certainly pass. User:力 (power~enwiki, π, ν) 03:31, 16 May 2021 (UTC)
  • Support deprecating the namespace. As others have said the namespace is a failed experiment, I just don't understand the utility in maintaining these as a community. Some users are still interested in creating books, sure, they can do so in userspace – there is no need for community maintenance which is a waste of resources over something which the readers don't care about. – SD0001 (talk) 07:07, 16 May 2021 (UTC)
  • Support This is a broken namespace and massive waste of time. — Preceding unsigned comment added by Jackattack1597 (talkcontribs)
  • Oppose I oppose anything that uses the word "deprecate" — GhostInTheMachine talk to me 14:07, 16 May 2021 (UTC)
  • Support, but archive the content. —Kusma (t·c) 14:13, 16 May 2021 (UTC)
  • Oppose As this seems to be a technical matter controlled by PediaPress and the WMF/MediaWiki, governed by a legal contract between them, then this is none of our business. If editors or readers do not find the facility useful then they are not required to use it. Andrew🐉(talk) 17:27, 16 May 2021 (UTC)
  • Support. (1) Books are out of scope. The feature is peripheral to our purpose and should not be maintained as critical infrastructure, either technically or editorially. (2) re: "fix it", any intrepid volunteers or businesses can do so without the book namespace. (3) Books are already deprecated, per the above history. That we update our documentation should be uncontroversial. (4) Separate from this discussion, I would be curious to learn what positive impact (readership or wider audience) has come from Books during its existence. czar 18:18, 16 May 2021 (UTC)
  • Support: I'll lay my reasoning out once and refer to it in each subsequent comment. I support all progression towards ridding ourselves of the book feature. No-one has given a convincing use-case worthy of all the volunteer time that is still going into it (which is hardly a large proportion of what is done on the site, but still a substantial number of raw hours). 192.76.8.91 lays out brilliantly some examples of how there is no convincing use-case for at least much of the content. A tiny proportion of casual readers have heard of it. It's not good for people with good internet, or with bad internet. It doesn't relate to how people actually browse and read articles. And finally, we are not preventing anyone from implementing this functionality properly, and even for profit—so long as the CC-BY-SA attribution legally required is given. — Bilorv (talk) 22:10, 16 May 2021 (UTC)
  • Support This is a new topic for me and I've read your reasoning and all the comments above carefully. I am not persuaded by "it's a bug so fix it!" near the top. Clearly the facts speak for themselves, in my view. The book format is not working, but on top of that, the book format is not popular or well used. I think it's time to draw down the curtain, empty the orchestra pit, and switch off the foyer lights, for the show is over. doktorb wordsdeeds 22:18, 16 May 2021 (UTC)
  • Support this is the minimum that should be done. I thought about this for some time, and your reasoning seems solid. Personally, PDFs seem like a much better solution than books, and the only difference I see is a Table of Contents. Through looking at pageviews, books also seem rarely used. EpicPupper (talk) 04:14, 17 May 2021 (UTC)
  • Support per 192.76.8.91. First of all, the software doesn't work. That is to say, the software is broken, and doesn't work. That is to say, working is something that the software, in this situation, does not do. We have PDF rendering, which does basically every single thing "books" were supposed to do, except it actually works. So then we are left with "the book namespace", which is... just a bunch of random very badly put together lists of articles? The fact of the matter is that, not only does the namespace receive virtually no views and no edits, the content in it is almost all far below what we'd consider to be Wikipedia quality. The question then becomes why we're formally endorsing, in the voice of the community, some random namespace where random people throw random articles together with no peer review or consensus procedure, and giving it the veneer of respectability. Sad! jp×g 04:34, 17 May 2021 (UTC)
    It is wholly wrong to suggest that "We have PDF rendering, which does basically every single thing "books" were supposed to do." It falls very short of book functionality as implemented by the old OCG. It processes only a single article (not much worse than my web browser's standard web-page-to-PDF print option handles Wikipedia articles). A book renderer also needs to pull in every article from the contents list and adjust chapter titles as per the contents list. In order to comply with the legal requirements of our licensing, it then has to collate and append the users from the entire histories of all the articles into one massive Copyrights section. Then again for the images from the Commons. Finally, it must render to PDF, paginate, and add the page numbers to the Contents list. For some reason the false meme that "PDF creator does it all" is quite widespread and many refuse to acknowledge its utter falsehood (Indeed, failure to address it was the principal reason our own developer community has consistently failed, but that is another story). — Cheers, Steelpillow (Talk) 10:31, 17 May 2021 (UTC)
  • Support per Levivich above, and per BlueRaspberry's deletion comment below. We should move to avoid wasting precious volunteer hours on projects that are not well-enough supported to survive. Ajpolino (talk) 05:53, 17 May 2021 (UTC)
  • Support - I've been here for six years and I have never edited the book namespace, even in an administrative capatcity. Anarchyte (talk) 10:45, 17 May 2021 (UTC)
  • Support an interesting experiment that didn't catch on. I don't see any point in spending any resources on it at this stage. Hut 8.5 19:50, 17 May 2021 (UTC)
  • Support This is an encyclopedia, books belong to Wikibooks. So how about moving the books to Wikibooks instead of deleting them? -Killarnee (CTU) 17:22, 18 May 2021 (UTC)
  • Support We are an encyclopedia, not a bookstore. Books are just not in high enough demand from our userbase to be worth the outsized editor time required. AdmiralEek Thar she edits! 17:53, 19 May 2021 (UTC)
    What time is required by our outsized editor? — GhostInTheMachine talk to me 18:10, 19 May 2021 (UTC)
  • Support. Unmaintained features should be removed. Sandstein 07:09, 20 May 2021 (UTC)
  • Oppose Deprecation is half-baked nonsense, it will confuse the heck out of visitors and book enthusiasts will keep right on adding books to it anyway. We really do not want a "hidden" wiki stitched into the one that anyone can read. — Cheers, Steelpillow (Talk) 08:58, 20 May 2021 (UTC)
  • Support. This is just formalising what's currently the case: these aren't maintained by the community, the software doesn't work, and barely anyone views the books. Realistically it doesn't seem that any of these things will change. the wub "?!" 13:56, 23 May 2021 (UTC)
  • Support Although it gives me no great joy to say this, we should have deprecated portals and we should deprecate books, to trim the number of namespaces.  – John M Wolfson (talk • contribs) 14:37, 23 May 2021 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Noindex the book namespace to hide it from search engines

The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion. A summary of the conclusions reached follows.
There is a clear consensus to noindex the book namespace to hide it from searches. (non-admin closure) (t · c) buidhe 09:23, 24 May 2021 (UTC)



This would occur by changing the MediaWiki configurations and prevent Wikipedia Books from showing up in search results. Books would still be reachable with Wikipedia's internal search function. --Trialpears (talk) 18:27, 15 May 2021 (UTC)

  • Support If we are to hide the links internally we should also hide them from search engines for the same reasons. This content does not benefit readers and leaves room for publishing something in an indexed namespace without supervision. This could possibly be abused by spammers or COI editors. --Trialpears (talk) 18:27, 15 May 2021 (UTC)
  • Support on a temporary basis. With the re-enabling of indexing when/if the PDF renderers are fixed. Headbomb {t · c · p · b} 18:45, 15 May 2021 (UTC)
  • Support - as a minimum, per my comments in support of deprecation. Levivich harass/hound 19:22, 15 May 2021 (UTC)
  • Support per nom; this should go along with deprecation. {{u|Sdkb}}talk 20:19, 15 May 2021 (UTC)
  • Support per all the above. Beeblebrox (talk) 20:51, 15 May 2021 (UTC)
  • Support per nom if there is no consensus to depreciate the namespace outright, as there is no point in directing readers to a namespace for a withdrawn service that isn't particularly well maintained. 192.76.8.91 (talk) 21:17, 15 May 2021 (UTC)
  • Oppose as there is no indication that people landing on such pages from search engine caused anyone harm. Nemo 22:00, 15 May 2021 (UTC)
  • Support - Frankly, I don't see anyone searching the internet really finding this useful. Doesn't seem helpful to land people searching for a topic to get sent to the book namespace. This should be largely masked from search engines. Hog Farm Talk 22:55, 15 May 2021 (UTC)
  • Support If nobody's watching this namespace and it's indexed, it's just an open invitation for spammers and other SEO-miscreants. -- RoySmith (talk) 00:22, 16 May 2021 (UTC)
  • Support. —¿philoserf? (talk) 02:10, 16 May 2021 (UTC)
  • Support, also, get rid of the book namespace. Nobody seems interested in maintaining any of this. If volunteers apply, perhaps it could be revived one day. For now, let it continue in userspace. — Alexis Jazz (talk or ping me)
  • Support per evidence presented. --Izno (talk) 03:27, 16 May 2021 (UTC)
  • Support per above - no benefit to search engine visitors to landing here while this is broken. User:力 (power~enwiki, π, ν) 03:28, 16 May 2021 (UTC)
  • Support per above. I think we should go further (see comments in the deletion section below), but this would be a start. ƒirefly ( t · c ) 06:49, 16 May 2021 (UTC)
  • Oppose As this seems to be a technical matter controlled by PediaPress and the WMF/MediaWiki, governed by a legal contract between them, then this is none of our business. If editors or readers do not find the facility useful then they are not required to use it. Andrew🐉(talk) 17:29, 16 May 2021 (UTC)
  • Support: per my reasoning above. — Bilorv (talk) 22:10, 16 May 2021 (UTC)
  • Support per above. EpicPupper (talk) 04:15, 17 May 2021 (UTC)
  • Support, per the arguments I made (and cited) in my support for the above section. Namely, for a variety of reasons, the Book namespace is filled with low-quality content (which is regrettable and could have been avoided). But, as it stands, there's no reason to think that we are benefiting from having the Book namespace open to all and sundry. jp×g 06:20, 17 May 2021 (UTC)
  • Support makes sense — GhostInTheMachine talk to me 11:54, 17 May 2021 (UTC)
  • Oppose Hiding it is half-baked nonsense, it will confuse the heck out of users looking for them and book enthusiasts will keep right on adding books to it anyway. We really do not want a "hidden" wiki stitched into the one that anyone can read. — Cheers, Steelpillow (Talk) 08:58, 20 May 2021 (UTC)
  • Support as an initial step. These pages aren't maintained, we shouldn't be presenting them to search engines with the Wikipedia name as if they are. the wub "?!" 13:56, 23 May 2021 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Remove the option to save in the book namespace from the book creator

The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion. A summary of the conclusions reached follows.
There is a consensus to remove the option to use this tool to create books in the book namespace. (non-admin closure) (t · c) buidhe 09:31, 24 May 2021 (UTC)


This would be implemented by changing a simple MediaWiki configuration setting as documented at mw:Extension:Collection#User rights for saving books. The book namespace would still be editable and it would be possible to move books from user space there or manually create a book using wiki text and then use the book creator. --Trialpears (talk) 18:27, 15 May 2021 (UTC)

  • Support This would be a great way to heavily discourage creation of new community maintained books while not impacting creation of user books or editing of existing books. --Trialpears (talk) 18:27, 15 May 2021 (UTC)
  • Support on a temporary basis. With the re-enabling when/if the PDF renderers are fixed. Headbomb {t · c · p · b} 18:44, 15 May 2021 (UTC)
  • Support - per my comments in support of deprecation. Levivich harass/hound 19:23, 15 May 2021 (UTC)
  • Support, as something that should go along with deprecation. {{u|Sdkb}}talk 20:21, 15 May 2021 (UTC)
  • Support. —¿philoserf? (talk) 02:14, 16 May 2021 (UTC)
  • Support, also, get rid of the book namespace. Nobody seems interested in maintaining any of this. If volunteers apply, perhaps it could be revived one day. For now, let it continue in userspace. — Alexis Jazz (talk or ping me)
  • Support per evidence presented. --Izno (talk) 03:26, 16 May 2021 (UTC)
  • Support per above. I think we should go further (see comments in the deletion section below), but this would be a start. ƒirefly ( t · c ) 06:50, 16 May 2021 (UTC)
  • Support to along with namespace deprecation proposal above. – SD0001 (talk) 07:11, 16 May 2021 (UTC)
  • Support Makes sense to limit the books to user space — GhostInTheMachine talk to me 14:02, 16 May 2021 (UTC)
  • Oppose As this seems to be a technical matter controlled by PediaPress and the WMF/MediaWiki, governed by a legal contract between them, then this is none of our business. If editors or readers do not find the facility useful then they are not required to use it. Andrew🐉(talk) 17:29, 16 May 2021 (UTC)
  • Support: per my reasoning above. — Bilorv (talk) 22:10, 16 May 2021 (UTC)
  • Support. Makes sense along with depreciation. EpicPupper (talk) 04:16, 17 May 2021 (UTC)
  • Support as a step towards removing the namespace entirely. Ajpolino (talk) 05:53, 17 May 2021 (UTC)
  • Oppose if still creatable, even if discouraged, removing the tool (which likely goes largely unused; if it was causing a problem, that would be one thing) that may prove useful in the rare case a book is helpful is silly. — Godsy (TALKCONT) 07:06, 17 May 2021 (UTC)
  • Oppose "Discouraging" others is disgustingly self-oriented social engineering - if a feature is undesirable, be honest enough to get rid of it. And if there is no consensus to do that, then you have absolutely no excuse for poking others in the eye. — Cheers, Steelpillow (Talk) 09:03, 20 May 2021 (UTC)
  • Support. the wub "?!" 13:56, 23 May 2021 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Drop support for book class from WikiProject assessment

This would involve emptying and deleting the categories at Category:Book-Class articles and editing the associated templates to not support the book namespace. --Trialpears (talk) 18:27, 15 May 2021 (UTC)

  • Support At this point these don't serve a purpose and has already been marked historical. --Trialpears (talk) 18:27, 15 May 2021 (UTC)
  • Oppose Books still exist, this is no different than having a category class. Headbomb {t · c · p · b} 18:42, 15 May 2021 (UTC)
  • Support - per my comments in support of deprecation. Levivich harass/hound 19:23, 15 May 2021 (UTC)
  • Support these are not, and never were, articles. Has already been marked as historical for a year. Clearly we aren't doing this already, might as well acknowledge it. Beeblebrox (talk) 20:54, 15 May 2021 (UTC)
  • Support - This no longer has a function. Hog Farm Talk 21:01, 15 May 2021 (UTC)
  • Support. —¿philoserf? (talk) 02:15, 16 May 2021 (UTC)
  • Support, also, get rid of the book namespace. Nobody seems interested in maintaining any of this. If volunteers apply, perhaps it could be revived one day. For now, let it continue in userspace. — Alexis Jazz (talk or ping me)
  • Support per evidence presented. --Izno (talk) 03:25, 16 May 2021 (UTC)
  • Support Books are just collections of existing articles. The articles are the things to assess — GhostInTheMachine talk to me 14:03, 16 May 2021 (UTC)
  • Oppose As this seems to be a technical matter controlled by PediaPress and the WMF/MediaWiki, governed by a legal contract between them, then this is none of our business. If editors or readers do not find the facility useful then they are not required to use it. Andrew🐉(talk) 17:30, 16 May 2021 (UTC)
  • Oppose, conditional on the book namespace being kept: I'm not sure what actual benefit this brings if we're not getting rid of books entirely (which I do support). Is there much time being spent maintaining these Book-class transclusions? And why is it our jurisdiction to control how individual WikiProjects maintain things? So far as I understand, unless the wider community really establish global consensus to stop us then a WikiProject I'm part of can start an assessment scale with 64 different ratings, from 3 independent 4-valued scales measuring how "well-sourced", "well-written", "well-illustrated" each page is (regardless of namespace). — Bilorv (talk) 22:10, 16 May 2021 (UTC)
  • Suppport per above. EpicPupper (talk) 04:16, 17 May 2021 (UTC)
  • Support as a consequence of removing the books namespace. No point in doing this otherwise. Ajpolino (talk) 05:53, 17 May 2021 (UTC)
  • Oppose These are useful in evaluating the aggregate score of articles in a given topic. Dobbyelf62 (talk) 23:25, 18 May 2021 (UTC)
  • Oppose. Many books are cruft, some are worthwhile about different things. It is actually useful to know which is which. — Cheers, Steelpillow (Talk) 09:11, 20 May 2021 (UTC)
    Steelpillow, this "assessment" isn't sorting books by quality, but (roughly) by topic. The book quality assessment (via User:Cyberbot I/Book Reports) seems independent of the WikiProject assessments. —Kusma (t·c) 10:26, 20 May 2021 (UTC)
    OK, I have updated the detail but the principle is unchanged. — Cheers, Steelpillow (Talk) 12:05, 20 May 2021 (UTC)
  • Neutral on this. I think the books should go, but if they're kept then it makes sense to keep the assessments unless WikiProjects feel otherwise. If the books are all deleted, the categories become eligible for speedy deletion under C1, and the necessary adjustments can be made to the templates. Either way there's no action required now. the wub "?!" 13:56, 23 May 2021 (UTC)
  • Oppose per Headbomb, Dobbyelf62, and Steelpillow. See also my !vote and comments in the section below. Cordially, History DMZ (HQ) (wire) 16:17, 28 May 2021 (UTC)
  • Support per above. –Fredddie 19:05, 30 May 2021 (UTC)
  • Support per all of the above. UnitedStatesian (talk) 01:30, 1 June 2021 (UTC)
  • Support as above. MichaelMaggs (talk) 09:04, 1 June 2021 (UTC)
  • Support There is no real point for all Wikiprojects to track a depreciated namespace. Terasail[✉] 10:59, 1 June 2021 (UTC)
  • Question: do you mean that they should be N/A class, or that the WikiProject banners on books should be removed entirely? ―Jochem van Hees (talk) 12:12, 4 June 2021 (UTC)
  • Support as Books are no longer functional or useful. --SilverTiger12 (talk) 22:15, 5 June 2021 (UTC)
  • Support this. I would note that in most cases this class was foisted on the individual WikiProjects in 2010 without consultation, by adding |Book=yes to each project's custom class mask. Technically, this will require a bot to remove |Book=yes from each class subtemplate. I would add that I would support a local decision by any WikiProject to keep supporting this (or any other) class, but that would require a local discussion by the project. — Martin (MSGJ · talk) 10:29, 10 June 2021 (UTC)

Delete all books within the book namespace

WP:REFUNDs to user space would be possible. If all books are deleted the namespace should be uninstalled if deemed appropriate by the developers. This would remove it from lists of namespaces in places like Special:Search and Special:RecentChanges and allow pages like Book – A Novel to be located at the correct title. Special:Book will continue working like normal and saving books in user space is still possible. PediaPress would continue to work except for possibly the catalog depending on their implementation. --Trialpears (talk) 18:27, 15 May 2021 (UTC)

  • Neutral It would be nice to never have to worry about the namespace again and to remove the possibility of vandalism staying for months or the namespace containing a safe harbor for unsuitable pages. There is however some non-zero value from some of these pages for a small number of users. Since the previous link hiding combined with proposals here (mostly noindexing) would prevent people from accidentally coming to the namespace I believe it's fine to leave it like this. While we would still have a small amount of vandalism going uncaught for months, vandalism on a page with just a handful of views isn't that bad. --Trialpears (talk) 18:27, 15 May 2021 (UTC)
  • Support Each of these proposals is making the namespace more and more like a second user namespace and less and less a functioning namespace (to the extent it ever was one). Once each of these are implemented, there will be no meaningful difference between books in the book namespace and books in the user namespace, and thus no reason to keep them separate. I would suggest userfying books whose creator is still active rather than deleting them, however. This renders all of the above proposals moot, so I'm not commenting in any other sections * Pppery * it has begun... 18:36, 15 May 2021 (UTC)
  • Oppose This is an overreaction to a software issue. The solution is to fix the software, not throw out the baby. Headbomb {t · c · p · b} 18:41, 15 May 2021 (UTC)
  • Oppose. Fix it rather than remove it. Littleolive oil (talk) 18:50, 15 May 2021 (UTC)
  • Support per nom. I'm convinced 99.99% of our readers don't know about or have ever used books. Most of those who have probably clicked on them accidentally... We already have built in options (PDF & printable version), as well as 3rd party options, for the truly desperate 0.01%. Aza24 (talk) 19:24, 15 May 2021 (UTC)
  • Support - per my comments in support of deprecation. Userfication, where practical, makes sense as an alternative to deletion. Levivich harass/hound 19:25, 15 May 2021 (UTC)
  • Support per nom, Aza24, and Pppery. — Ched (talk) 20:06, 15 May 2021 (UTC)
  • Support with userification, per Pppery. {{u|Sdkb}}talk 20:25, 15 May 2021 (UTC)
  • Support as first option - I do not see the software becoming functional any time soon, and personally I feel developer time could be better spent elsewhere. As such, there is no point in keeping the namespace around. ƒirefly ( t · c ) 20:28, 15 May 2021 (UTC)
  • Support the history of this project is littered with ideas that were given a fair chance and just didn't work out in the long run. Nobody is going to come along and magically fix all the software issues for a sidelined,disused project that so few find useful. There are far more important and actually useful things for both the community and the staff to be doing. Let's just admit the obvious, this is over. Those people that really want them they can still have them in userspace. Beeblebrox (talk) 21:01, 15 May 2021 (UTC)
  • Oppose - Wikipedia:Featured and good topic candidates/Nomination procedure instructs that books be created as part of the process for nominating featured and good topics. Some of the books will have some historical value through featured and good topics. I don't think blanket deletion of all is a particularly good step, although many are useless. Hog Farm Talk 21:04, 15 May 2021 (UTC)
  • Sort of support - I think it would be better to move the books to the userspace of the original creator, rather than outright deletion, but I agree with removing them from a public facing "Community maintained" section if the encyclopaedia. 192.76.8.91 (talk) 21:23, 15 May 2021 (UTC)
  • Oppose because the "books" are just collection of links, which work perfectly fine with adequate software. Users can still use them right now to produce their own derivative products, e.g. for Kiwix or PediaPress. Nemo 22:00, 15 May 2021 (UTC)
  • Support, per nom and Firefly. Gog the Mild (talk) 22:02, 15 May 2021 (UTC)
  • Oppose, don't hide history. At least get a bot to move it all to subpages of Wikipedia:Books/Old/ or something so the connection to Featured Topics stays comprehensible. —Kusma (t·c) 22:32, 15 May 2021 (UTC)
    • ?? The featured and good topics are barely connected to the books—they provide no more connection than the topic box itself. They're not even displayed in the topic boxes. Aza24 (talk) 22:44, 15 May 2021 (UTC)
      • I still think that some of these may have some historical value. Not a majority, but some. I don't think nuking an entire namespace indiscriminately is going to be helpful here. I support deleting most of these, but I'm not convinced the blanket approach is the best route as some of these may be historically useful and need more attention before deletion. Hog Farm Talk 22:58, 15 May 2021 (UTC)
      • Aza24, they were in the not so distant past: [11] By all means delete those that do harm, but don't delete everything just because it's not "useful" anymore. —Kusma (t·c) 23:03, 15 May 2021 (UTC)
    • I guess it's worth noting that not all featured topics have an associated book. Checking ~20 random topics only a bit over half had one. --Trialpears (talk) 23:30, 15 May 2021 (UTC)
  • Support per above. ~ HAL333 23:56, 15 May 2021 (UTC)
  • Support. The feature is dead and has been for a long time now. The foundation devs have a huge backlog of other bugs which they aren't fixing, and there is no reason to believe they are going to start on this any time soon. The dev time is anyways better served elsewhere. --Gonnym (talk) 00:00, 16 May 2021 (UTC)
  • Support deletion Feature is not supported, never was well supported, and there is no plan to support either in terms of software or volunteer community organization. I have made books in the past and later felt that the process was disappointing. Since it was an option in Wikipedia, I assumed that it was useful, when in fact, the process gets no support, is not part of a tool suite of other useful functions, and does not give benefits that I expected. Unless somehow someone shows evidence of an existing active book development and maintenance community, and unless there is a plan to make a serious Wikimedia community request for Wikimedia Foundation financial investment in this tool's development, then I say delete what exists and remove the option so as not to distract anyone else from more useful and supported tools. Keeping unsupported tools around is not a benefit. The books function as I know it could be recreated as some kind of tool in Wikidata for sharing lists of articles to run reports on them, print them as a book, or coordinate translation of important articles across languages. By putting this in Wikipedia instead of Wikidata the machine readability benefits are not there. Blue Rasberry (talk) 00:06, 16 May 2021 (UTC)
  • Meh and kind of leaning oppose although mass userfication would be fine. These are already very difficult to stumble across, and if the proposals above trend as they currently are it will become essentially impossible to do so. Basically these are nowhere facing, but there's no need and nothing to be gained by hiding history. If people feel things will somehow be tidier without an extra namespace then sure userfy them, but really once these are unfindable any further steps, be they deletion, userfication, etc. sound like extra work for no discernible benefit. Regards, 31.41.45.190 (talk) 01:38, 16 May 2021 (UTC)
  • Meh, also, get rid of the book namespace. Nobody seems interested in maintaining any of this. If volunteers apply, perhaps it could be revived one day. For now, let it continue in userspace. Mass userfication should work. Any "books" that are clearly garbage could be deleted. — Alexis Jazz (talk or ping me)
  • Oppose for now - if the namespace is deprecated this might be good to do next year. Doing it right now is too soon. User:力 (power~enwiki, π, ν) 03:21, 16 May 2021 (UTC)
  • Support the end objective of remove the namespace given the evidence presented. I think deletion of the books should occur, but perhaps only after they have been moved out of the namespace so that REFUNDs can indeed take place. --Izno (talk) 03:23, 16 May 2021 (UTC)
  • Support – This feature is not supported, and no one has any good reason devote the time necessary to make it work. We should not leave a mess like this around, like an abandoned ruin. I support deletion, which will simply be representative of the reality that the 'Book' namespace is and has been dead for a very long time. RGloucester 04:10, 16 May 2021 (UTC)
  • Support the end objective of removing the namespace. However, to preserve the history per Hog Farm and Kusma, I would prefer "archiving" these and moving them to a location like like the subpages of "Wikipedia:Books/Old/" or something. – SD0001 (talk) 07:44, 16 May 2021 (UTC)
  • Note: Before any actual deletion occurs, the pages should all be properly tagged so any interested parties are notified. The deletion notice should not be at the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying "Beware of the Leopard." (I'm wondering whether I should write a WP:LEOPARD essay). —Kusma (t·c) 08:40, 16 May 2021 (UTC)
    Kusma Sure. I'm guessing you want the almost thousand Category:Book-Class articles sub cars tagged as well? Worth noting that WP:CENT and the village pumps really isn't at the bottom of a locked filing cabinet stuck in a disused lavatory while books not getting a single view most months are. --Trialpears (talk) 09:23, 16 May 2021 (UTC)
    Would adding it to {{Saved book}} with namespace detection be sufficient? That would save like 12k unnecessary edits. --Trialpears (talk) 09:33, 16 May 2021 (UTC)
    Trialpears, ideally we just move the whole book namespace back to where it came from (used to be subpages of Wikipedia:Book), then we can avoid notifying people. (For casual users, I think anything other than their talk page and watchlist could just as well be on Alpha Centauri). —Kusma (t·c) 09:56, 16 May 2021 (UTC)
    I've now added a custom deletion notice through the templates {{Saved book}} and {{Category class}}. --Trialpears (talk) 19:48, 16 May 2021 (UTC)
  • Support, with proper warnings for interested parties (eg the book's creator). Let's just kill this failed experiment off. Remagoxer (talk) 11:45, 16 May 2021 (UTC)
  • Oppose This is a little extreme, I support deprecating the namespace, but not deleting everything in it.Jackattack1597 (talk) 13:04, 16 May 2021 (UTC)
  • Support but prefer if we could proactively archive them all to somewhere accessible to regular users before deleting the namespace, rather than requiring that books individually go through the WP:REFUND process after deletion. I don't see a lot of value in preserving them, but all else being equal, it's better not to erase history. Colin M (talk) 13:50, 16 May 2021 (UTC)
  • Comment This is the only important decision in this RfC, it is the endpoint of the death by a thousand cuts the others are perpetuating. Let's just get on with it, one way or the other. Whichever way this goes, we have to accept that we are voting on whether to revive or kill the initiative. — Cheers, Steelpillow (Talk) 14:20, 16 May 2021 (UTC)
    Subsequently you oppose because "it's useful" even though it doesn't work. "Let's get on with it", indeed. Izno (talk) 15:47, 16 May 2021 (UTC)
    @Izno: Why so snarky? Have I upset you or something? Darn, where's the cup of tea template when you need it? — Cheers, Steelpillow (Talk) 15:13, 18 May 2021 (UTC)
    It's not snarky to say "Let's just get on with it"? :) Izno (talk) 19:52, 18 May 2021 (UTC)
  • Oppose I find the Books feature useful; I would use it more if it still worked as well as it used to. I shall be sad to lose it. — Cheers, Steelpillow (Talk) 14:20, 16 May 2021 (UTC)
  • Oppose Too much for now. Revisit when the future of the technology is clear. We currently have 51,546 books in user space and only 6,198 in Book space, so "just" move all of the books in Book space to a sub-page of the user that created them. — Preceding unsigned comment added by GhostInTheMachine (talkcontribs)
    The future is clear: the technology is dead and will not be resurrected at this point. --Izno (talk) 15:46, 16 May 2021 (UTC)
    We are probably talking about different things. The gadget that collects articles worked when I tried it. The gadget that converts these article lists into a PDF worked when I tried it. The question here is should we delete all books within the book namespace and I think we should just move them. Once the namespace is empty, then we have the option to turn it off — GhostInTheMachine talk to me 11:52, 17 May 2021 (UTC)
  • Oppose As this seems to be a technical matter controlled by PediaPress and the WMF/MediaWiki, governed by a legal contract between them, then this is none of our business. If editors or readers do not find the facility useful then they are not required to use it. Andrew🐉(talk) 17:30, 16 May 2021 (UTC)
    I do not think there ever was any legal contract - both sides have behaved far too off-hand for that. Besides, whatever the WMF may or may not have signed up to without telling us is nothing to do with us - there's no mention of such a thing in the code of conduct etc. If the WMF were to have a sudden "Oh, sh*t!" awakening and change their tune, that would be their problem not ours. — Cheers, Steelpillow (Talk) 17:43, 16 May 2021 (UTC)
    Unless I am massively misunderstanding something, any contract between the WMF and PediaPress has absolutely no bearing on whether we have a specific namespace on enwiki or not, nor on whether we choose to deprecate the feature given that it hasn't been working properly for years. ƒirefly ( t · c ) 17:44, 16 May 2021 (UTC)
  • Support with no rush—give an ample window for anyone who wants to repurpose the content to do so and delete at the end of that generous period. czar 18:27, 16 May 2021 (UTC)
  • Prompted by Iznos comment above I have looked into what happened when the education program namespace was temporarily uninstalled. While the namespace was uninstalled it was impossible to access or undelete pages (even for admins). To avoid this all books should be moved to Wikipedia:Books namespace before a possible deletion to avoid this technical issue this time around. --Trialpears (talk) 21:41, 16 May 2021 (UTC)
  • Strong support: per my reasoning above. We need to solve the problem at its root. A refund process or archive of the namespace (on another wiki? Even just a nod towards some fork of Wikipedia on a guideline page?) should be made for individuals who have been using the namespace for personally helpful activities—I don't want to delete what you've worked on, but I don't want to be broadcasting it as reader-facing content. — Bilorv (talk) 22:10, 16 May 2021 (UTC)
  • Transwiki them to English Wikibooks per m:Keep history. Many of these are useful and we have a WMF project that can easily house them. We should not delete them and hope someone decides to dig around our dead namespaces before starting a new effort. Instead, we should move the content to an appropriate place: Wikibooks. Wug·a·po·des 23:03, 16 May 2021 (UTC)
    Wugapodes That really won't work. The books in the book namespace aren't the same type of book wikibooks focus on. While Wikibooks also contain some of this type of books as well at wikibooks:Wikibooks:Collections they won't work since Wikibooks don't contain the Wikipedia articles these books consisted of. If this was done they would literally just be useless lists of red links. I can't imagine Wikibooks would want that. --Trialpears (talk) 23:13, 16 May 2021 (UTC)
    Ah so I was confused about how the software worked. I thought the books namespace held the output of the program (you can tell how much I use the namespace) but yes, looking through them they would be largely useless to wikibooks unless we copied all the articles over too which would be a bad idea. I've struck my comment. I'm fine with whatever as long as the content is recoverable in the future. Wug·a·po·des 23:44, 16 May 2021 (UTC)
    I think that the book ns is and always will be pointless. But why can't the related articles stay here and the links can easily be changed? -Killarnee (CTU) 17:35, 18 May 2021 (UTC)
    The book creator is designed to work on pages that are all within the same wiki - when you use it to create or edit a book it adds a banner at the top of the page that you can use to add articles to your book as you browse. I don't know if it would work with cross wiki links, but it really isn't intended to be used in that manner. Also being blunt for a minute, the book namespace is full of crap and I would strongly oppose dumping our rubbish on another wiki with the expectation that they'll either have to preserve it and maintain it for us or turn it into something worthwhile. Is wikibooks going to want Book:Blakfacts: Volume 4.5, which starts with a section on "Short Little Black People"? How about it's companion Book:Blakfacts Volume 12:, which is literally just someone's list of top Africans? Is anyone going to read Book:American Holocaust which is 50% about the extinction of the American bison and 50% about the colonisation and oppression of the native Americans? Is wikibooks going to want Book:Pirates1 a world first in the cosmology/piracy/sci-fi genre? What about Book:Political Alternatives, which lists "valid alternatives to the current political system" which consists entirley of links to articles on socialism? Is anyone ever going to read Book:Gemology and Jewelry, an unsorted 500 article long book including everything vaguely related to jewellery, or Book:Ancient Monuments In The UK, a 350 article long book on ancient monuments in the UK. What's the inclusion criteria that was used to select articles for Book:Core biographies (A–D), is it just some readers list of their favourite articles? Do you want a book containing countries that were featured articles in 2012? Don't worry Book:Featured Country Articles has you covered. I already talked through my experience of searching for a history book above, but the vast majority of the namespace is abandoned personal projects that we should not be presenting to readers as "community maintained". If they're going to be kept then userfying them to the userspace of the original creator is probably the best way of dealing with them IMO. 192.76.8.73 (talk) 22:00, 18 May 2021 (UTC)
  • Support per nom and extended discussion above. EpicPupper (talk) 04:17, 17 May 2021 (UTC)
  • Support provided there's some path to refund requested material. Ajpolino (talk) 05:53, 17 May 2021 (UTC)
  • Oppose. The reason the Book namespace is filled with garbage isn't because books are a bad idea, it's an artifact of historical factors (primarily the book rendering service being fucked up). If there is no longer an influx of crappy books (i.e. disabling the feature to make them easily), I think it would be easy to clean them up and write good ones. jp×g 06:30, 17 May 2021 (UTC)
  • Oppose - No reason to obscure them from public sight. No-indexing and the removal from certain forms of the search engine is more than adequate. — Godsy (TALKCONT) 07:02, 17 May 2021 (UTC)
  • Support Or what about moving the pages to Wikibooks instead of deleting all the pages? -Killarnee (CTU) 17:25, 18 May 2021 (UTC)
    See the replies to Wugapodes, who made an identical suggestion a few comments up. * Pppery * it has begun... 17:28, 18 May 2021 (UTC)
  • Oppose I often use the Book tab to track changes for specific topics. I get far more use out of this than the Watchlist. Dobbyelf62 (talk) 23:27, 18 May 2021 (UTC)
    Presumably you could use a userspace book (which won't be affected by this proposal) or Special:RecentChangesLinked for the same purpose. * Pppery * it has begun... 02:43, 19 May 2021 (UTC)
  • Support with the goal of removing the namespace clutter. Also fine with moving to an archive location in another namespace as a few have suggested e.g. Wikipedia:Books/Old. the wub "?!" 13:56, 23 May 2021 (UTC)
  • Support if they can't/shouldn't be moved to WikiBooks  – John M Wolfson (talk • contribs) 14:42, 23 May 2021 (UTC)
  • Support Which other wiki uses this namespace? We're the only one that uses it, and it's currently deprecated. We can download pages as PDFs, and there's already another wiki for books. Why keep a namespace that's not used? I think one possibility would be to delete all pages in the Book namespace and to blacklist the namespace. It would be a lot easier than deleting the namespace. If all pages in this namespace do get deleted, please refund all of my edited pages in book ns, and in book talk ns as well if those get deleted. 54nd60x (talk) 03:03, 25 May 2021 (UTC)
  • Oppose Wikipedia:Books are very useful, they logically group and consolidate articles and information in a streamlined and *accessible* manner that cannot be done elsewhere in the encyclopedia. They offer quick links to important services for our readers like the ability to download them as PDF versions (see Book:Jane Austen for example). Additionally, the Book_talk pages come with some vital tracking tools like Template:Book report which gives us a good overview of all the statuses (cleanup, non-free media, etc) of each article within each book. Click "show" in the template to see full functionality and see also Book talk:Jane Austen as an example. Whatever technical action or solution you choose to apply, please *do not delete* our wonderful Wikipedia Books. Remember the WP:READER. Thank you, History DMZ (HQ) (wire) 15:53, 28 May 2021 (UTC)
Oppose for historical reasons. Books should be deprecated instead and left at that. Tyrone Madera (talk) 20:13, 28 May 2021 (UTC)
  • Support deletion Time to let go of this failed experiment. oknazevad (talk) 22:20, 28 May 2021 (UTC)
  • Support after giving the book creators a chance to download their books. –Fredddie 19:07, 30 May 2021 (UTC)
  • Support - A much better solution will make itself obvious in the future. Until then, delete. Schierbecker (talk) 07:26, 1 June 2021 (UTC)
  • Support - little point in keeping around stuff that's almost entirely unused, and that never will be usable. MichaelMaggs (talk)
  • Support per above. --SilverTiger12 (talk) 22:15, 5 June 2021 (UTC)
  • Support - Favre1fan93 (talk) 13:54, 8 June 2021 (UTC)
  • Support —¿philoserf? (talk) 00:34, 10 June 2021 (UTC)
  • Support Whenever I come across an item in Book namespace, it is either no better or worse than the same exact thing in the main space. Ocasionally, I see Books which were clearly created by a mistake with a poorly executed template and obviously are not used by anyone, including their creator. When content is updated in the main space, the changes do not necessarily get propagated to Book space, creating duplicate putdated content. Books have been deprecated for some time now, so the only logical follow up is to post warnings about future deletion for anyone still using Books (already happened) and then delete all remaining books. Also, there exist other equivalents like offline Wiki readers and Wiki exports which can serve the same purpose as Books. Anton.bersh (talk) 18:33, 10 June 2021 (UTC)
  • Comment A good many of the "support" votes are based on "I don't see anything in it for me" arguments. Plenty of other users do, and should be allowed to get on with it. If a given book offends you, WP:MfD is your friend, there is no need to throw out the baby with the bathwater. — Cheers, Steelpillow (Talk) 20:51, 12 June 2021 (UTC)
  • Oppose I would prefer the namespace be archived instead of deleted. SportingFlyer T·C 21:01, 12 June 2021 (UTC)

Hide TfD notices for non-autoconfirmed users

Following a discussion at WT:TFD I would like proposing hiding TfD notices (the default appearance shown above) from users who aren't autoconfirmed. This would hide content only of interest to editors from readers. It is very important that editors are aware of big TfD discussions since they can have wide ranging effects however and there are at times IPs or new accounts that make their first comments at TfD. I feel like the trade off here between IP input and unnecessary notices is acceptable, but I feel like this is something people who aren't TfD regulars should weigh in on as well. --Trialpears (talk) 19:29, 15 May 2021 (UTC)

Survey (TfD notices)

  • OPPOSE - While I sympathize with the intent, it ignores the fact that we have long-term editors who, for various reasons, continue to edit as IPs and do not log on with user names. They may wish to be participate in TfD discussions, and so should be informed of them. Blueboar (talk) 19:45, 15 May 2021 (UTC)
  • Support—I am sympathetic to the IP users who are actively editing, but (as I understand it) in the grand scheme of Wikipedia virtually none of our readers are registered users, and the number of IP editors who are regularly and actively editing is equally miniscule. As such, it makes no sense to shove these notices in their face and if we truly want to prioritize reader-facing pages—we should remember that. Aza24 (talk) 19:57, 15 May 2021 (UTC)
  • Support Most of the time this is a confusing waste of space. When a large template (such as a widely used infobox) gets nominated at TfD a notice is shown often across hundreds of thousands (sometimes millions) of pages, each with many readers. So basically we have millions of readers seeing a confusing ugly "templates for discussion" notice on the top of pages. As a TfD regular, I can say that IP participation there is not that high anyway. And unfortunately, if one makes the choice to keep using an IP, they need to accept the inconveniences that result, such as article creation limitations, captchas, being more subject to edit filter false positives, unable to edit pages due to semiprotection, etc. Compared to all those, this is a rather minor inconvenience. It's the same as the fact that users too paranoid to enable JavaScript have to accept that many websites will not work properly as a result. ProcrastinatingReader (talk) 19:59, 15 May 2021 (UTC)
  • Support, as something that strikes a much better balance between reader and editor needs than the status quo, which (like many things) is too heavily weighted toward editor needs. Aza24 and ProcrastinatingReader successfully rebutted Blueboar's opposition argument. {{u|Sdkb}}talk 20:29, 15 May 2021 (UTC)
  • Support - largely per ProcrastinatingReader. This is just going to be an annoyance to most readers who aren't registered editors. The average non-registered reader doesn't care too much about the background processes, so we shouldn't be shoving background processes into their faces with notices. Hog Farm Talk 21:12, 15 May 2021 (UTC)
  • Support Honestly we could probably hide a lot of the other notifications as well. This is one of the worst in terms of spamming and use to readers (and many editors). Aircorn (talk) 21:51, 15 May 2021 (UTC)
  • Oppose non-autoconfirmed users are human too. The last time I checked, making edits like this was not a crime. Unless it becomes policy to semi-protect all XfD pages, why should we deny them the right to see the TfD messages? If they don't see the messages, how will they know that a discussion is ongoing, let alone know that they are welcome to participate? TfD participation is low enough already without lowering it still further. Also, I'm certain that this has been proposed and rejected at least twice before. --Redrose64 🌹 (talk) 22:13, 15 May 2021 (UTC)
    Indeed, it has been. * Pppery * it has begun... 22:26, 15 May 2021 (UTC)
    re "why should we deny them the right to see the TfD messages"—because giving irrelevant notices to millions of readers every month overwhelmingly outweighs the needs of the few active IP editors. We are here first and foremost for our readers. Aza24 (talk) 22:58, 15 May 2021 (UTC)
    Not to mention very few to no IP editors participate at TfD. Consider this on 51k pages (with a combined readership of probably 100k-1M over the TfD period), this on every US SCOTUS case, this on 1,956,845 transclusions (later had to be disabled), this on 5k transclusions, this on all US legislation pages. None of them had any IP participation; this is the norm at TfD. ProcrastinatingReader (talk) 23:10, 15 May 2021 (UTC)
  • Oppose I fail to see what has meaningfully changed since the previous discussions I linked above. * Pppery * it has begun... 22:26, 15 May 2021 (UTC)
    Which is... not an oppose rationale? Because WP:CCC. And there are some IMO poor arguments in those discussions, for example that some Wikipedia editors read Wikipedia logged out, and hence we should show the notice to millions of readers(?). The idea that it encourages editor participation is also shaky. Templates are not an area where a complete newbie can go and can meaningfully contribute to a TfD. No, and what's more likely is far more people go "WTF is this thing? Why does the page look so messed up? What is a "template for deletion" and why am I being shown this?" ProcrastinatingReader (talk) 22:57, 15 May 2021 (UTC)
  • Oppose per all opposes above.   ~ Tom.Reding (talkdgaf)  23:01, 15 May 2021 (UTC)
  • Oppose, what is interesting or useful to anyone is not defined by their autoconfirmed status. We show millions of other maintenance messages to all of our users (and many of them are irrelevant to readers not wanting to edit, like {{orphan}} or {{Chinese script needed}}), and TfD is on for only a few days, not many years like some others. (And it is generally a good thing to remind people that Wikipedia is not a finished product and that there does not need to be a distinction between "readers" and "editors"). —Kusma (t·c) 23:14, 15 May 2021 (UTC)
    You just made a good argument for not displaying {{Orphan}} to readers (and indeed we don't show it to anyone when it's more than a month or so old), but that's a discussion for another time. Ultimately, it'd be nice to have a user preference for displaying editor-focused things like orphan tags or TfD notices, but until that functionality is implemented, autoconfirmed vs. not is the best proxy we have. {{u|Sdkb}}talk 06:47, 16 May 2021 (UTC)
  • Support per arguments presented by Aza24 and ProcrastinatingReader. ~ HAL333 23:55, 15 May 2021 (UTC)
  • Oppose There are some IP editors out there. And sometimes participation in xfds is the first step towards more active participation in the project. We could just as easily suppress afd notices, and maintenance templates but we don't, why? Well sometimes they are useful in getting people involved or just getting an outside opinion, and these are far less intrusive than either of those two. Regards, 31.41.45.190 (talk) 01:30, 16 May 2021 (UTC)
    • Templates are one of the most complex areas of Wikipedia; TfD is not the best place for beginners. {{u|Sdkb}}talk 06:40, 16 May 2021 (UTC)
      • I have to respectfully disagree Sdkb, from the perspective of complexity in terms of policies/guidelines as well as unwritten norms afd is far more daunting. I don't dare to comment on those without reviewing at least some of the guidelines so I'm not spewing nonsense. OTOH I've dropped in on tfds without doing more than re-skimming the top of the page and I've yet to be accused of being a cir case or of making assessments based off out-of-date guidelines. Regards, 31.41.45.190 (talk) 14:11, 16 May 2021 (UTC)
  • Support solves more issues than it creates. Headbomb {t · c · p · b} 03:16, 16 May 2021 (UTC)
  • Oppose having these notifications for merge discussions with very common templates such as {{tl}}, {{talk header}}, and {{infobox person}} are annoying for all editors. For less common templates, I would want to see these notifications if I am not logged in and constructive IP editors probably would want to see them as well. There are certainly a few notifications that aren't helpful to readers, but I don't think that's a wide enough problem to justify this solution. User:力 (power~enwiki, π, ν) 03:20, 16 May 2021 (UTC)
  • Oppose the implication being that IPs aren't welcome to participate. SpartaN (talk) 07:12, 16 May 2021 (UTC)
  • Oppose Displaying editor-related things to everyone is one of the ways that we are 'the free encyclopedia that anyone can edit.' If you start hiding things because only editors should see them, you will end up with less editors over time. Mike Peel (talk) 07:47, 16 May 2021 (UTC)
  • Oppose these notices do no harm to see. Should we also hide AfD notices? I think it's good to give readers the chance to know about any discussion impacting the content on the page they're reading. Elli (talk | contribs) 10:28, 16 May 2021 (UTC)
    Elli The comparison to AfD notices isn't particularly fair. An AfD notice is placed on one page where the outcome affects the article a ton while TfD notices can be present on tens or hundreds or thousand of pages with minuscule impact on that page. Here are some examples: Removing a feature that haven't worked for years with around 100k notices, change the internals of in language tags around 300k notices and infobox merge targets whose appearance or parameters won't be affected at all (30k for a currently open discussion over 500k when infobox settlement is involved). --Trialpears (talk) 10:51, 16 May 2021 (UTC)
    @Trialpears: I guess, the other reason for my reaction against this is for the same reason Kusma has said - In my personal fantasy world "the free encyclopedia that anyone can edit" means, among other things, that we consider every reader to be a potential editor.
    Is it a fantasy that a high percentage of our readers are interested in contributing? Yes. Should we hide the contribution-side of the site from them? Not at all. It's still in the site's vision to include these people.
    Additionally, I think a lot of TfDs do have an appreciable effect on their transclusions (for example, navigation templates). Elli (talk | contribs) 10:55, 16 May 2021 (UTC)
    Elli, we include AfD notices because they're of substantial use to non-editing readers. They tell readers that the page may have substantial issues, functioning as a kind of stronger version of {{Notability}} or other maintenance tags. They also help out readers who might otherwise try to re-read an article at a later date and be confused when they can't find it. These factors do not apply for TfDs of templates used on a page. The situation here is more akin to a major RfC on an article's talk page. There's no notice about it because it's not something readers need to know to be able to use the page effectively. {{u|Sdkb}}talk 22:01, 17 May 2021 (UTC)
    @Sdkb: we sometimes do have such a notice in articles, such as merge notices (which most readers probably don't care about), RMs (again, and these like to persist at the top of any controversial current event), and tags like {{disputed inline}}. Elli (talk | contribs) 01:21, 18 May 2021 (UTC)
    The point about RMs having limited relevance to readers is what motivated this whole proposal. I think merge notices and disputed inline both have relevance to readers: a merge notice signals a potential article change that might otherwise be confusing, and inline disputed warns the reader of potentially biased information. {{u|Sdkb}}talk 02:20, 18 May 2021 (UTC)
  • Oppose. We should hide these TfD notices because, there are few IPs participating in TfD. So the solution is, to even decrease the already small amount of IPs participating in TfDs. Sorry, but this just sounds like something Mozilla would do. Don't repeat the same mistake Firefox did, which is to remove features because "nobody is using them".

    However, I would be open to any method that allows to hide these notices. I understand that not everyone is interested in such discussion, but this also applies to autoconfirmed users as well. So I think the best solution here would be to allow an option to hide these notices without discriminating against very new and IP editors. pandakekok9 (talk) 11:01, 16 May 2021 (UTC)

  • Oppose per Elli. We do not need to make it harder for readers to become editors. (I'm reminded that a certain former functionary's first edit was to a TfD he saw transcluded.) Vaticidalprophet 11:26, 16 May 2021 (UTC)
    I was told that former functionary was hounded for allegedly being a sockpuppet and is now vanished? ProcrastinatingReader (talk) 12:06, 16 May 2021 (UTC)
    Indeed. The first-edit in question looks very 'convincingly' first-edit to me (it reminds me of my own early XfD !votes). Ironically, a lot of the criticism seemed to be disbelief a new user could possibly find the well-hidden realm of TfD... Vaticidalprophet 12:22, 16 May 2021 (UTC)
    So, just making sure I got this right, the opposition is arguing here that users should be encouraged to go to TfD because this is the encyclopaedia that anyone can edit. But when someone does that competently, we (with impunity) accuse them of being a sockpuppet. So basically the acceptable threshold is incompetent IP contributions to TfD? ProcrastinatingReader (talk) 12:33, 16 May 2021 (UTC)
    The acceptable threshold is that the "guilty until proven innocent" way we treat new-through-newish editors as either CIR cases or socks is utterly bizarre and awful, and that we need to get over ourselves. I do not think hiding ever more of the backstage from readers is particularly useful for solving that problem, as it only makes the community even more closed-up. Vaticidalprophet 12:36, 16 May 2021 (UTC)
  • Oppose because most of the opposed arguments make sense to me, and I am in favor of equal transparency for all Wikipedians including both readers/editors and registered/IP users. Huggums537 (talk) 17:41, 16 May 2021 (UTC)
  • Support, per Sdkb. The potential exclusion of a comparatively small number of IP editors from TfD discussions is far outweighed by the mild inconvenience to potentially millions of readers of having confusing clutter at the top of a page. Remember our WP:AIM: an accessible encyclopedia. Making thousands of articles slightly less accessible to readers for the benefit of a small subset of editors is contrary to this purpose. 129.49.100.55 (talk) 18:57, 17 May 2021 (UTC)
    I'm not sure why you are thinking that the TfD notices are making articles less accessible. It's annoying, sure, but makes the article less accessible? There are literally other notices worse than that and arguably makes the article less accessible. Inline {{cn}}s are one thing. There's the stub notice as well. Oh, and did I mention the {{more sources needed}} template? pandakekok9 (talk) 09:17, 18 May 2021 (UTC)
  • Support per ProcrastinatingReader. KevinL (alt of L235 · t · c) 07:02, 18 May 2021 (UTC)
  • Oppose: While a grand idea there is a fundamental flaw. Since the "internet at large" uses registration, it is strange that Wikipedia fights against it so hard. I have to register on any place I go on the internet and cannot fathom how registering would place a stumbling block to "allowing anyone to edit". I would not have been hit with two unexplained range blocks (one global) if all registered. However, unless or until there is a change to mandatory registration we cannot tout being an encyclopedia anyone can edit and claim Any contributor to this encyclopedia, unregistered and registered alike, is called a "Wikipedian" and offer restrictions like this. Currently, an unregistered editor (IP editor) holds the same position as I do as a registered editor of over a dozen years. A few of us concerned with the politics of Wikipedia still have to consider the possibility that a reader might see a notice of interest and become an involved "editor" or that currently, although with some restrictions, an IP editor is still a member of the editing community and I am sure many do get involved in TfD discussions. Otr500 (talk) 12:40, 18 May 2021 (UTC)
    "Restriction" is quite a strong term to use here. We're not talking about semi-protecting WP:TfD to prevent IPs from !voting there; any IP that wants could still go there and contribute to the discussions. It'll be less likely they'll find out about a particular situation, yes, but see comments above and below about that being an easy tradeoff to make. {{u|Sdkb}}talk 23:50, 18 May 2021 (UTC)
  • Oppose The notion that most readers aren't registered (or even unregistered) editors is hard to credit. Every other "for discussion" template is posted on its article or talk page to bring wider input to the discussion so it makes no sense to try and reduce that input for templates. TFD templates in no way shape or form reduce the access to articles. They are there for a relative short space of time and are much smaller than most FD messages. The fact that some find them aesthetically unappealing is hardly a reason to remove them. MarnetteD|Talk 14:36, 18 May 2021 (UTC)
  • Oppose – I find the proposal confusingly worded. What does the last sentence mean (I feel like the trade off here between IP input and unnecessary notices is acceptable, but I feel like this is something people who aren't TfD regulars should weigh in on as well.? IP editors are often experienced editors who are signed out and who may gain earlier notification of templates they're interested in and qualified to comment on than if they were excluded from such notifications. Dhtwiki (talk) 22:53, 18 May 2021 (UTC)
    Dhtwiki If we only showed the notice to IP editors I would definitely agree with your analysis but we show them to all IPs. A vanishingly small proportion of views are from editors. We get about 250,000,000 views each day, assume the average person visit 5 pages and we have 50 million unique viewers each day. Perhaps there are 100 IP editors that may be interested in TfDs if they see a notice (I think that would be more than the number of IPs that contributed in the past year). That means with what I think are generous estimates we would get 0.0002% of readers that may be interested. That is several 100,000 readers who don't care about TFD seeing a notice about it for each person who may care. There are lots of things you could debate in this guesstimate, but I have a hard time seeing any somewhat reasonable method getting values other then tens of thousand of notices going out for each relevant one.
    My analogy here would be putting up thousands of posters everywhere in a big city in the hope that you will find one stranger who dropped their hat. Sure, it isn't a big deal at all seeing an irrelevant poster but would it be sensible to put up thousands of them? --Trialpears (talk) 00:30, 19 May 2021 (UTC)
    How many readers-who-are-not-editors access the talk page at all? How much does it cost to post the message in terms of I/O as opposed to *conditionally* posting the message with the added attendant processing (I know we're not supposed to worry about server-side performance, but still). Dhtwiki (talk) 02:56, 19 May 2021 (UTC)
  • Support. Can anyone think of a single example of a reader who we converted into a prolific editor as a result of a TfD notice? The inconvenience dealt to readers across millions of pages far outweighs any effect on editing. And who is to say that that effect is necessarily positive? It could be that seeing such a scary sign actually puts off potential editors, making them think that Wikipedia's processes are too esoteric for them to learn. -- King of ♥ 03:51, 19 May 2021 (UTC)
  • Oppose, solution looking for a problem. Stifle (talk) 09:15, 19 May 2021 (UTC)
  • Oppose. With these reasons one could suppress the display of all maintenance templates for IP users. But they serve an important function even for readers: they make clear that Wikipedia is a work in progress, that it is based on community discussion is consensus, and that all are free to participate in it. Sandstein 13:19, 19 May 2021 (UTC)
    For the record, maintenance templates are applied on an article specific basis, usually give tasks that are not technically difficult or require extensive policy knowledge, and probably have better conversion rates. TfD notices tend to be over minor, often housekeeping, merges, often require knowledge of policy and templates, and are broadcasted at scale, and evidence shows do not invite participation. A more apt comparison would be WP:CENT and WT:MOS discussions, which are far more impactful at scale and not widely advertised to our readers. ProcrastinatingReader (talk) 12:46, 20 May 2021 (UTC)
  • Oppose A username should not be required for participation in any part of Wikipedia. IP editors should have the same expectation to be notified of relevant discussions that may interest them as do autoconfirmed users. --Jayron32 14:32, 19 May 2021 (UTC)
  • Support: Especially when the template is based entirely in text, lately Template:Rotten Tomatoes prose was nominated for deletion and as a result every single transclusion of this template, which is supposed to look like normal text, got tagged with a deletion notice. This is a big inconvenience to our readers who we should always put before our editors. versacespaceleave a message! 13:16, 20 May 2021 (UTC)
  • Oppose O, ye of little faith in readers having the ability to ignore irrelevant TfD messages. Its an intentionally minimally-invasive template that takes almost no effort to mentally dismiss. I suspect strongly that this has almost nothing to do with paternalistically "protecting" users but that the real driver is a desire to not have to deal with input from the hoi polloi of unregistered users which are perceived as uninformed. If they are uninformed, inform them. If they post irrelevant input, give them the tools to make it relevant. This is pretty basic stuff. AfD deals with this on a daily basis and shutting out unregistered users there is an absolute last resort in cases of obvious disruption. This proposal would anomalously make TfD treat unregistered users as shut out by default. Eggishorn (talk) (contrib) 15:30, 21 May 2021 (UTC)
    I highly doubt your unsupported speculation. Speaking as someone who is both a regular at TfD and who regularly seeks out interacting with newcomers as a Teahouse host, the newcomer presence at TfD is so small that "disruption" from it is essentially a non-issue. Why is it so difficult to AGF believe that some editors care about usability and make related proposals? {{u|Sdkb}}talk 16:36, 23 May 2021 (UTC)
  • Oppose per Jayron32's eloquent comment below: There are no such things as "noneditors". There are just "editors that haven't started editing yet". the wub "?!" 13:32, 23 May 2021 (UTC)
  • Strongest oppose per the insightful comments above, and especially the reader-foucused editing observation below. EpicPupper (talk) 16:56, 25 May 2021 (UTC)
  • Oppose philosophically. IPs are human, too (was one at some point, can confirm). Unless one can present significant evidence of long-term abuse by non-ACs in TfDs, I fail to see what would be gained by the proposal, except the removal of some minor visual annoyance for some users. As for disruption, if one was really intent on doing that, they can just go directly to WP:TFD. I don't see what the proposal would even achieve, beyond giving credence to some editor's sentiments about IPs. AfD (and occasionally MfD) are far more prone to the expected kind of disruption, anyway, and when that does happen it's a simple matter. Hence, non-solution to a non-problem. RandomCanadian (talk / contribs) 19:26, 25 May 2021 (UTC)
  • Support any measure that would diminish the eyesore of TfD notices. For all of our readers and 99.9% of our editors, these notices are irrelevant noise. Ugly, confusing notices like these are more likely to dissuade new IP editors from getting involved in the first place. gobonobo + c 07:25, 30 May 2021 (UTC)
  • Oppose. Wikipedia is a construction zone, and sometimes readers will see a little dust. That may even get a few curious as to how they can join in and participate. For the rest, the notices are neither common nor terribly intrusive. (If an extremely widely used template were up for discussion, an alternate means of notifying the community of the discussion may be reasonable.) Seraphimblade Talk to me 03:54, 31 May 2021 (UTC)
  • Oppose. Many people choose to edit without registering, or have only just registered, or prefer not to remain logged into accounts, or would be galvanised to participate by a TfD. There are templates that I would've become active for before I joined - the proposer even mentions that this occurs. I also often look at WP when I'm not logged in (e.g. I could get fired for logging into my WP account on a work computer), and have in the past participated in a TfD later after seeing a notice. Why should we hide from readers that they can become involved? Why should they be ignorant that WP isn't in a perfected final form? We have no issues asking for donations or for people to join editing events, but a small line about a TfD is too much. Or are we just not interested in hearing readers' opinions? For people that support removing it because it's messy or noisy, I agree that it's aesthetically bad, but we can try to make it less upsetting first rather than slowing closing WP's doors. Oh, and remember that we have that pesky bias problem - this sure wouldn't make that better. --Xurizuri (talk) 08:09, 31 May 2021 (UTC)
  • Oppose, i.e. keep the notifications. Modifying a template will potentially modify what the reader will read in the future. Therefore, even pure readers have a right to know what will happen next time. Pldx1 (talk) 07:59, 1 June 2021 (UTC)
  • Support TfD notices aren't relevant for almost all readers. This discussion seems poised to continue a disappointing trend where the desires of a tiny minority of elite editors are upheld, to the detriment of the vast but silent majority. – Teratix 05:45, 2 June 2021 (UTC)
  • Oppose, the negative effect of normal readers seeing TfD templates is less than the positive effect of long-time IP editors being informed of TfD discussions. Devonian Wombat (talk) 23:06, 2 June 2021 (UTC)
  • Oppose Every reader is a potential new editor. Plus, there are many long-term good IP contributors. Nguyentrongphu (talk) 12:59, 4 June 2021 (UTC)
  • Oppose I think it's good to be transparent about how we do things. SportingFlyer T·C 23:03, 9 June 2021 (UTC)
  • Oppose. IP editors and non-autoconfirmed editors are allowed to post comments at TfD. They're likely not always good ones but I don't see why the existing structure can't handle bad !votes and we gain a lot more by getting people into participating in Wikipedia. On the idea that it would be "better" for the UX from a reader's perspective, sure. You're getting more focus on the content by removing all project related tags or notices from the article. But part of our goal on Wikipedia is to blur the line between a reader and an editor so we get people to become editors. While I doubt there'll be much people getting into editing from TfD notices I also doubt that the even more minuscule inconvenience readers who don't care about TfD have to endure outweighs the potential new editors. Chess (talk) (please use {{reply to|Chess}} on reply) 07:09, 11 June 2021 (UTC)
  • Support IPs interested in such discussions should be systematically pressured into become editors, and this would work to that effect.  – John M Wolfson (talk • contribs) 12:37, 13 June 2021 (UTC)

Reader-focused editing

I can already see the way this is going, and it's depressing. Systemic bias toward the needs of editors compared to readers is probably the most severe form of systemic bias on Wikipedia—it's snarled usability reforms on way too many past occasions, and it's rearing its head yet again in the main oppose argument here. Yes, this proposal involves a tradeoff between the preferences of readers and those of (a few) editors—it's a ridiculously easy trade to make, since IP participation at TfD is miniscule, whereas the prevalence of these notices is enormous. Plenty of IPs are fine editors, but a comment from one of them once a week or so is not worth disrupting literally millions of readers. Please, folks, when you weigh your !vote, keep in mind who we're actually writing Wikipedia for. {{u|Sdkb}}talk 06:34, 16 May 2021 (UTC)

  • In my personal fantasy world "the free encyclopedia that anyone can edit" means, among other things, that we consider every reader to be a potential editor. Non-editing readers do not need the "edit" button or the toolbox on the left. If they really don't want to engage with this, they can go to Wikiwand. —Kusma (t·c) 10:04, 16 May 2021 (UTC)
    • This. And the TfD notices remind the reader that Wikipedia is a work-in-progress, and always will be. Remember, perfect is the enemy of good.

      I also don't see how keeping those notices makes Wikipedia less usable. It can be annoying, sure, but unusable? That's a bit of a stretch. pandakekok9 (talk) 11:05, 16 May 2021 (UTC)

I'm a big fan of reader-focused editing. I don't think this is anything near reader-focused editing -- it's, like, one line. What I think of when I think of "reader-focused editing" is the fact literally every non-editor I've happened to discuss the matter with thinks I'm a rabid deletionist. Hate to think what they think of actual deletionism. (That is: reader priorities aren't only not our priorities, but they're often totally different to our priorities in ways that would give the average editor apoplexy.) Vaticidalprophet 11:29, 16 May 2021 (UTC)

I think it's completely fair to say that the bad of having an unnecessary and potentially confusing notice is many times smaller than the good of a notice reaching someone who is interested. The question is if it's somewhere around 100,000 more good, which is the order of magnitude of the ratio between pageviews of notices to number of non-autoconfirmed editors participating at TfD according to my back of the envelope calculations. I understand that there may be philosophical reasons for not hiding it but purely in practical terms I have a hard time believing it's justifiable to show these notice. --Trialpears (talk) 10:57, 16 May 2021 (UTC)

I find it unlikely the little bar that appears from this is what turns IPs off when simultaneously we have huge squares at the top of pages about citations and other issues in an article. In fact it's barely noticeable in comparison. I feel we are acting a little too certain maybe it's ugly and they won't like it that we're just assuming that's the case. SpartaN (talk) 12:03, 16 May 2021 (UTC)
That's how this entire interface is built - from assumptions and extending generally accepted principles to aspects of our interface. We can't commission a WMF research study for every proposal we make. It just seems like Wikipedians are more comfortable relying on assumptions when it means adding something than removing something. ProcrastinatingReader (talk) 12:46, 16 May 2021 (UTC)
@Sdkb: if the support is about preference for readers, then where did the understanding of readers' preferences come from? Whether I support or oppose hinges on this: do readers actually care about these notices? I don't care if a million pages are loaded with a TfD notice on it if only 1,000 readers actually notice, 50 of them click through and the 49.9 of those who don't leave a comment either go "huh, I wonder how Wikipedia is actually written. Maybe I'll look behind the scenes in some other way" or "Boring, this isn't useful to me". I do care if 10,000 readers find it an eyesore and none learn anything from it. How do I know which is which? No-one seems to have any evidence either way. But if 10,000 found it an eyesore surely some would be clicking through and leaving test comments like "why did you put this notice on the Roman Empire page?" or "are you going to delete the page I was reading? I don't get it". — Bilorv (talk) 22:24, 16 May 2021 (UTC)
Some evidence: Every time a widely used template is sent to TFD/TFM, crowds show up to say "WHY IS THIS NOTICE HERE?!?!?!?! PLX REMOVE THE NOTICE IT IS DEFACING THE ARTICLEZ" (for some amount of capitals or another). Izno (talk) 01:02, 17 May 2021 (UTC)
Those crowds tend to be editors, not readers, though. Elli (talk | contribs) 12:53, 17 May 2021 (UTC)
Why do these kinds of discussions always get framed in a "think about the children" manner. Is their a scrap of empirical evidence that readers stop reading articles because of the TFD notice? Or any of the other discussion notices for that matter. Until well researched studies about people who are only readers react to these the only systemic bias I am seeing is toward the needs of editors who dislike the TFD notice. MarnetteD|Talk 23:25, 18 May 2021 (UTC)
  • There are no such things as "noneditors". There are just "editors that haven't started editing yet". There is no meaningful distinction to be made between "readers" and "editors". We invite all people who read Wikipedia articles to join in on editing them. There is no need to create such imaginary classes of people. The idea itself is antithetical to the very ethos of Wikipedia itself. It is not a finished product, it has no end point, and we don't think of users of Wikipedia as being either readers or editors. All users are invited and encouraged to help out as they see fit, and I find the notion that some people should be classified as "readers" and actively discouraged from helping out is just wrong. --Jayron32 14:32, 19 May 2021 (UTC)
    I'm very much on board with inviting readers to become editors, but the invitations will be much more likely to work if they're made for newcomer-appropriate tasks. Asking readers to try editing by finding a missing citation is good; asking them to make their first edit by wading into the infobox consolidation wars (probably the most frequent way someone would come across a TfD notice) is not. {{u|Sdkb}}talk 16:42, 23 May 2021 (UTC)
  • Sdkb hits the nail on the head as usual. In my view, the opposition to this proposal is the perfect example of Wikipedia's systemic bias towards editors over readers. – Teratix 05:53, 2 June 2021 (UTC)


Alternate solution to the underlying problem?

The underlying problem here is that TfD notices on popular templates (say, biographical or geographical infoboxes) appear on hundreds of thousands of articles. It is mildly annoying to see notices about some obscure merger proposal that doesn't affect the vast majority of readers (whether they edit or not) on every page you look at. Is it technically feasible to have "dismiss" links on TfD notices? I assume there are good reasons not to have them on every TfD (and on templates with only three transclusions, they aren't so annoying anyway) but could something like this be made to work for templates with more than 1000 transclusions? —Kusma (t·c) 14:00, 16 May 2021 (UTC)

Sure, if you insert JavaScript to load on every page to allow dismissing functionality. Something like with watchlists at MediaWiki:Gadget-watchlist-notice-core.js, but I imagine the intadmins might have performance concerns with that proposal. I don't think that's the underlying problem anyway; your suggestion is helpful for editors but doesn't fix the problem for readers. I mean yes a global change to templates can alter article pages. But so do CENT RfCs and MOS proposals and we (rightly) don't advertise those to our readers. A dismissible useless notice is still a nuisance. All in all, banner blindness of all forms is a mostly insoluble problem, one of the community's own making and thus no consensus process can fix it. ProcrastinatingReader (talk) 14:22, 16 May 2021 (UTC)
Why does allowing everyone to dismiss notices not solve the problem that people don't want to see these notices repeatedly? My proposal is to treat editing and non-editing readers exactly the same. —Kusma (t·c) 14:43, 16 May 2021 (UTC)
I think the ability to dismiss these is an amazing idea. I understand the apprehension behind loading javascript on every page, but this strikes me as similar to the javascript we use to make navboxes collapsible: the implementation opens up a lot of options beyond TfD notices. Personally, I would like the ability to hide TfD notices because they can drag on and I'm not usually interested. But there are tons of notices that readers (and me) might want to dismiss like AfD or CSD notices. It's not even limited to deletion notices, we have templates like {{Current event}} that are informative but quickly become redundant---the reader probably knows it's a current event (since they're looking it up) and even if they didn't once they see the banner they probably don't need to keep seeing it if they don't want to. It also opens the door to new use-cases for existing templates like the padlock template {{pp}}. I've protected pages where there is a high level of public interest; readers may not understand why a page is protected and draw the wrong conclusions ("Wikipedia is siding with FooBar!"), so instead of using {{pp|small=yes}} which produces a padlock icon in the top right, I use it to display a banner which explains page protection and the reason behind it. This is rare (I think I've done it maybe twice) partly because it is incredibly intrusive, but if readers could easily dismiss the banner, the cost of placing it is lowered and we can be more up-front with our readers about when and why a page is protected (not always, but useful for things like BLPs of people in the news for example). So yeah, I think this is an amazing idea regardless of how this RfC goes. Wug·a·po·des 22:52, 16 May 2021 (UTC)
  Administrator note Having to manage unique client-side data for each dismissable element can quickly get out of control, as every one would need a unique identifier, relisting would need a new unique identifier, etc. — xaosflux Talk 22:05, 17 May 2021 (UTC)
Xaosflux, that's why I would like to limit this to just a few discussions per month if it is done manually. Or hope for some of our amazing bot coders to work something out :) —Kusma (t·c) 10:39, 18 May 2021 (UTC)
Do you have an estimate for how many templates for discussion per month are for template with over 1,000 transclusions? If its about 1-10 this alternative sound good, but if its dozens or even hundreds, the burden on the developers/ intadmins might be too large for it to be feasible. Jackattack1597 (talk) 00:45, 20 May 2021 (UTC)

Time-limited display?

Another possible at least partial solution would be for an agreement that the TfD notice should be shown for a certain period, but then removed. For example, 24 or 48 hours of display would be enough to alert most people interested in such things and removing the notice after that would remove most of the ugliness. Johnuniq (talk) 23:11, 16 May 2021 (UTC)

This assumes that everyone who is interested in a given template reads a page on which it is transcluded at least once every 1-2 days. I don't think we can reliably make that assumption. While it's likely that someone who reads multiple Wikipedia articles every day will see a noticed that relates to all/most infoboxes within that timeframe, that same reader will be much less likely to see a notice that relates to say {{inflation}}, let alone someone who only looks at Wikipedia once a week. As a real-world example, I look at lots of Wikipedia articles (In the last ~3 months I've visited over 7400 pages on en.wikipedia.org in this browser alone), {{Use Commonwealth English}}/{{Commonwealth English}} have been at TfD since the 14th, yet I've seen a banner about the discussion exactly once (at Head of the Commonwealth). In the past theww days I'm unlikely to have seen a template relating to articles about linguistics, palaeontology, or flags, despite often reading about those subjects. Thryduulf (talk) 00:55, 17 May 2021 (UTC)
My editing runs in streaks according to my job. I may work 40 hours or 80 and I never sleep much so my editing time is all over the map. I was upset about being hit with a global IP ban (the second so far) so I took a break. When I finally get as trustworthy as an IP editor I am going to try again to get an IP block exemption. The point is that I can't keep up with all the things I would like to do so might miss something in a 48-hour window. I am sure this would be a problem for many. Otr500 (talk) 14:27, 18 May 2021 (UTC)
It already is a time limited display. It goes away when the TFD is closed. Editors lead lives in the real world that can keep them away from the 'pedia for days at a time. This proposal seems to say that if you haven't seen the TFD in the 48 hours after it is initiated you are out of luck in knowing about the discussion and your input isn't wanted. MarnetteD|Talk 23:13, 18 May 2021 (UTC)

Feasibility

Is there even a technical way to achieve this? CaptainEek Edits Ho Cap'n! 01:06, 18 May 2021 (UTC)

This is technically trivial: add the autoconfirmed-show class to the output of {{tfm/dated}} and {{template for discussion/dated}} * Pppery * it has begun... 01:09, 18 May 2021 (UTC)

Mobile users

  • Does this notice even display for mobile users? If not, then most of this conversation is practically moot. –MJLTalk 03:48, 23 May 2021 (UTC)
It does.Gluons12 t|c 01:25, 24 May 2021 (UTC)
Yup, it does display on mobile.--Vulphere 08:55, 27 May 2021 (UTC)

RFC on moves being marked as minor

There are many autoconfirmed editors who have no idea that their article is not ready for mainspace. The tag #new user moving page out of userspace is quite a good example of this. If you surf through the list of articles at https://en.wikipedia.org/wiki/Special:RecentChanges?hidebots=1&hidecategorization=1&hideWikibase=1&tagfilter=de-userfying&limit=50&days=7&urlversion=2 you will see many articles that could definitely be speedy deleted and others that just need to be improved more. And of course, there is some legitimate minor page moves like this move per WP:ENDASH. So here are the options I came up with:

  1. Status quo. Automatically mark moves as minor.
  2. Optional. Leave the option to mark moves as minor or major.
  3. Required. All page moves are marked as major.

Yes, this is not a major issue, but I had to bring it up anyways for the editors that do hide minor edits. Sungodtemple (talk) 14:40, 22 May 2021 (UTC)

  • No article title changes are never minor. The suggestion that articles being moved to draftspace should be considered a "minor" edit is too wrong to even engage with. User:力 (power~enwiki, π, ν) 16:20, 22 May 2021 (UTC)
    • Hmm ... apparently there are minor edits being made along with the log entries. I assumed this was suggesting something about the log entries being considered "minor" edits. This looks like "software weirdness" that nobody noticed. User:力 (power~enwiki, π, ν) 18:24, 22 May 2021 (UTC)
  • I must agree with the above comment. I can't understand the rationale behind marking any move, especially one between namespaces, as minor. Can anyone explain why that is done automatically? I can't believe that that is done without a good reason, but, for the life of me, I can't see what possible reason there might be. Phil Bridger (talk) 16:48, 22 May 2021 (UTC)
  • @Sungodtemple: Note, this isn't really something we have a choice on unless this becomes a software option - so a local RfC is going to be advisory at best. See phab:T176053 and linked tasks. — xaosflux Talk 19:54, 22 May 2021 (UTC)
  • A page move should NEVER be marked as “minor”. I suspect that the intent was to indicate that the moves are “routine” and probably “not controversial”... but “routine” and “not controversial” are not the same as “minor”. Blueboar (talk) 22:22, 22 May 2021 (UTC)
    Per WP:Minor, a minor edit is one that the editor believes requires no review and could never be the subject of a dispute. So "routine" and "not controversial" are actually a pretty good way to describe them. {{u|Sdkb}}talk 20:30, 23 May 2021 (UTC)
    Note, moves are not "edits" at all; that a null-edit is placed in the history is purely for convenience - moves are recorded in the move log which doesn't have a "minor" indicator. — xaosflux Talk 01:28, 24 May 2021 (UTC)
  • No, unfortunately or otherwise, changes of article title can be controversial or just plain vandalism. They're not minor, though in some circumstances they may be easily agreed. Chiswick Chap (talk) 10:39, 24 May 2021 (UTC)
  • The feature of marking edits as minor isn't particularly useful as a whole, so it doesn't matter very much. But given that a move from draft or user space into main space suddenly makes a lot of content appear, so isn't "minor" even from the point of view that edits not changing content are minor: if we do continue to make the distinction between major and minor edits, moves should not be marked as minor. —Kusma (t·c) 10:54, 24 May 2021 (UTC)
  • Two issues are being conflated here. Moving new articles out of draft/sandbox and existing article rename/moves. The latter is almost never going to be a minor edit. The former is almost always going to be minor by the definition we use (with the exception being articles which have been moved back from article space already). Completely new articles by their nature do not *require* review prior to being made live. Our policies and guidelines are clear on this. And until the article is live, realistically there is not going to be much dispute unless its an editor with a history of problematic article creations. The move log already adequately records them, so whats the purpose in having the article history have the minor tag not attached to moves from draft/sandbox? The only real current use of minor flag is to stop cluttering up watchlists. And if you have a new article that is not in article space watchlisted you are either the primary author or someone involved in writing it, in which case you will be aware anyway. This seems like process-wonkery for the sake of it. For existing articles being renamed/moved, what is the practical purpose in preventing the move being listed as minor? What problem does that solve? Only in death does duty end (talk) 11:56, 24 May 2021 (UTC)

Two-year range date-of-birth categories

Before I embark on a quixotic quest to create a bunch of categories that could potentially prove controversial, I thought I'd throw it out here for community approval.

Here's the situation. We generally categorize biographical subjects by year of birth (e.g., Category:1965 births). We have thousands of subjects for which we know their age as of a certain date, but don't know which of two potential years was their actual year of birth. For example, Sheri Benson (born 1962/1963), Helena Brunner (born 1957/1958), Matt Galloway (born 1970/1971). Currently all of these subjects are categorized by decade of birth (e.g., Category:1960s births), but I think we could be more precise by creating categories like Category:1962–1963 births. This would also separate out the subjects for whom we have that sort of two-year window from subjects for whom we have much vaguer knowledge that they were born in a certain decade, but could have been born any time in that decade. BD2412 T 04:51, 29 May 2021 (UTC)

That seems unnecessary to me. It would just create a bunch of very short categories, and very short (non-maintenance) categories are usually discouraged. Chicdat (talk) 11:11, 29 May 2021 (UTC)
Why not just categorize them in both years? It's not not accurate, it's just the best we can do based on the best information we have. Categorizing by decade seems like it doesn't cover someone born in say 1959-60, or 1899-1900, and I agree that creating a series of very short categories for all of these unusual occurrences seems like over-categorization. Ivanvector (Talk/Edits) 11:31, 29 May 2021 (UTC)
Putting them in both would be my instinct too, and I'm pretty sure I've seen it before for historical figures though I can't think of examples off the top of my head. —Nizolan (talk · c.) 22:33, 29 May 2021 (UTC)
After some searching I can say that Andrew Marcus is the only article about a single person in two 1980s birth categories, so it basically doesn't happen currently. --Trialpears (talk) 22:37, 29 May 2021 (UTC)
Right, by "historical" I meant pre-20th century but granted I can't find examples right now either. —Nizolan (talk · c.) 22:46, 29 May 2021 (UTC)
Same result for the 1850s but here Max Hirsch (economist) is the only article. --Trialpears (talk) 22:49, 29 May 2021 (UTC)
I'm not really thinking of very old article subjects, as I think the convention of saying 'so-and-so, age' is fairly recent. However, I would consider it problematic to list, e.g., Sheri Benson above in both 1962 births and 1963 births because one of those is factually incorrect, and we know it. I hope to some degree that having range categories like those proposed would lead some editors to dig in and find more accurate date-of-birth information for the subjects in those categories. BD2412 T 00:34, 30 May 2021 (UTC)
@Trialpears: I just realised that I was remembering Wikisource, where the double category is the (automatic) convention, and not Wikipedia, e.g. s:Author:Thomas à Kempis. Confusion on my part, sorry. —Nizolan (talk · c.) 14:23, 30 May 2021 (UTC)
Another option would be to create a set of, e.g., Category:Circa 1965 births, which would include people probably born in (or around) 1965, but would not project inaccurate claims that we know the person to have been born in that specific year. BD2412 T 04:40, 30 May 2021 (UTC)
  • Remember that the purpose of categorization ISN’T to pigeon hole the subject ... it is to aid navigation between articles.
I have no problem listing someone in two “birth year” categories if we are not sure which applies. For the purpose of navigation to and from the article, it is better to be overly inclusive. Presumably the relevant bio article would make the uncertainty about the subject’s birth date clear in the first few sentences. Blueboar (talk) 15:24, 30 May 2021 (UTC)
I have seen such category additions reverted in the past, where there was no source for the specific year. BD2412 T 16:55, 30 May 2021 (UTC)
  • Why is Category:Year of birth uncertain inappropriate in these cases? --Jayron32 15:25, 1 June 2021 (UTC)
    • It's a separate inquiry. An uncertain birth year could be any year. I suppose we could put someone with, for example, a possible 1964/1965 range in both Category:1965 births and Category:Year of birth uncertain, and leave it to researchers to make the connection. BD2412 T 23:26, 2 June 2021 (UTC)
  • Oppose using categories that are known to be wrong. If someone was born in 1964 or 1965, you know that one of the categories doesn't apply. —Kusma (talk) 17:55, 3 June 2021 (UTC)
  • If categorizing in both categories is off the table (and I agree with the rationale) then probably they should be categorized in neither. What about a maintenance category for something like Category:Date of birth extrapolated from verified age as of date, and leave it up to editors to categorize in an appropriate existing date range category? Ivanvector (Talk/Edits) 12:13, 6 June 2021 (UTC)
  • The Category:1960s births trick of course only works when the two possible years in question fall into the same decade. I think the best thing would be to just put them in both year categories, and also in Category:Year of birth uncertain. It's not a perfect solution, but a perfect solution doesn't exist and this is good enough. I'm looking at this from the point of view of somebody wanting to write code to do automated processing. Let's say I wanted to find all the people born within 5 years of when Person X was born. With my scheme, we'd find them, and then could do some additional filtering if we wanted. If you take them out of the year category and put them in a dual-year category, you'd have to search all the possible dual-year categories, most of which wouldn't even exist. Likewise with queries like, "who was born exactly 100 years before Person X?". Also, the snot-nosed obnoxious pedant in me immediately thought of the case of an article about a pair of twins, one of whom was born just before midnight on December 31st, and the other just a few minutes later, in January 1st of the next year. Surely that would belong in both categories? -- RoySmith (talk) 14:43, 6 June 2021 (UTC)
    • I had not even thought about people who, based on an age as of a specified date, could be born in one of two decades. BD2412 T 02:31, 9 June 2021 (UTC)
Or two centuries. Or millennium. Then there are time zone issues, relative to place of birth. IMO this discussion is an artifact of computer architecture which wants 1 or 0, and has trouble with gradients and nuance. Maybe pick one (best) version of the truth for the black and white stuff like categories, and explain nuance in the body of the article. Creating duplication in categories is breakage IMO. -- GreenC 03:20, 9 June 2021 (UTC)
The original proposal is to avoid duplication in categories by creating a new set of categories like Category:1962–1963 births where the subject is known to have been born sometime during that span. It would work just as well for a Category:1959–1960 births or a Category:1999–2000 births. Articles in those categories would not be in any other date of birth categories. If the subject's actual birthdate was determined, they would be recategorized to the specific year. BD2412 T 04:38, 9 June 2021 (UTC)
Each sibling would only belong in one year. I couldn't see why you would have a combined article unless they were conjoined. And having conjoined twins born in different years would be next to impossible.--Khajidha (talk) 17:11, 7 June 2021 (UTC)
Khajidha, regarding I couldn't see why you would have a combined article unless they were conjoined, see Dionne quintuplets, which is in all of Category:1954 deaths, Category:1970 deaths, Category:2001 deaths, and Category:Living people. -- RoySmith (talk) 02:45, 9 June 2021 (UTC)
I'd think the thing to do in such instances would be to create redirects from the individual names and put the year-of-death categories on the redirects. BD2412 T 03:09, 9 June 2021 (UTC)
Sorry, but if we don't know the exact year of birth, we should not be trying to put them in categories based on exact years. I don't care how much "easier" it makes some things. This strikes me as lying to our readers. It makes no sense to be "easy and wrong". If the two years are in the same decade, I could see a category like Category:1960s births with uncertain years. --Khajidha (talk) 14:00, 7 June 2021 (UTC)

Process request: A requested edit template and queue for partially-blocked editors

I partially blocked an editor from article-space today for a three-year history of unreferenced changes and inappropriate categorizations of BLPs. In my advice to the user I started to suggest that they request edits on talk pages, and then realized that we don't have an edit request process specifically for this. We have {{request edit}} for COI editors, and the {{edit protected}} series for pages that are protected, but none (that I know of) for parblocked editors. I ended up suggesting they use {{edit fully-protected}}, but that's a half-solution, and requests with those templates on articles that are not protected are routinely rejected for only that reason.

I propose creating an {{edit partially blocked}} request template (with instructions to reviewers to check the requester's block log, similar to how we advise reviewers to check the protection log for pending changes) which would populate Category:Wikipedia partially blocked edit requests, and adding a sublisting of pages in that category to Wikipedia:Dashboard in the requested edits section. I could do this boldly myself, but creating a new queue could have wide-reaching implications, so I'd like to gauge consensus first. Ivanvector (Talk/Edits) 11:27, 29 May 2021 (UTC)

@Ivanvector: I am amazed that you do not know of Template:Edit partially-blocked. 🐔 Chicdat  Bawk to me! 12:34, 29 May 2021 (UTC)
Putting Chicdat's somewhat unnecessary tone aside, that template seems to be a good solution. It doesn't categorise into a specific category, and I agree with Ivanvector that it should to allow for easy reviewing. I've also created {{edit partially blocked}} as a redirect to match the other edit request templates. firefly ( t · c ) 14:28, 29 May 2021 (UTC)
It's not clear to me that edit requests from editors blocked from editing a given page should be given a separate queue from all edit requests (and thus potentially higher prioritization), given that their contributions have been deemed disruptive for that page. isaacl (talk) 15:06, 29 May 2021 (UTC)
Personally I think it's less about giving them higher priority and more ensuring that they get the higher scrutiny they no doubt require - with a separate queue they are easily identifiable as request that require handling more carefully. firefly ( t · c ) 15:15, 29 May 2021 (UTC)
Also there may be editors who are willing to handle COI edit requsts but not partially blocked edit requests or vice versa making it easier for them to find the ones they want to process. --Trialpears (talk) 15:21, 29 May 2021 (UTC)
True enough that edit requests from editors blocked from a page are likely to be more contentious, and it might be nice to flag this without putting the request into a separate stream where it may jump ahead of other requests. It's not clear to me though if there are a lot of admins unwilling to deal with the usual queue of requests (generally conflict-of-interest situations) that are only looking for contentious requests to process. isaacl (talk) 15:44, 29 May 2021 (UTC)
Putting these requests in a separate stream could just as well result in them jumping behind other requests. It is just an acknowledgement that they are different from other types of request. Phil Bridger (talk) 17:45, 29 May 2021 (UTC)
I'm dubious as to how different they really are in essence. Edit requests using the template are from editors whose edits require additional review for the page in question. Whether that's due to a conflict of interest or a prior dispute, the responding editor is going to have to examine the past history of the requestor and the page to establish context and the best steps forward. isaacl (talk) 23:28, 29 May 2021 (UTC)
Regarding hinting at level of scrutiny, I think once the request is read, even ignoring the different template that is assumed to be used correctly, the request text will make it evident. isaacl (talk) 15:44, 29 May 2021 (UTC)
Who is going to volunteer to fulfill edit requests from partially blocked editors??? I cannot comprehend the notion that there is a person who is disruptive enough that they they need to be blocked from mainspace but we still want them to make edit requests. I mean, just indef them. This isn't a day care, right? Levivich 17:00, 29 May 2021 (UTC)
If they are only partially blocked then the partially-blocking admin has seen a spark of potential redemption. Surely making edit requests is a way towards this? Phil Bridger (talk) 17:45, 29 May 2021 (UTC)
I've used p-blocks this way and I've answered edit requests from them on my user talk. Some people do useful, gnome-ish work, but for whatever reason won't follow particular policies like WP:NOTBROKEN. Requiring review of their edits before going live is a good compromise between losing a useful volunteer and letting reports about them clog up ANI. Technical restrictions like blocks and protection should be sparing and only as much as we need to prevent disruption (i.e., create a net-positive outcome). Blocks are one way to handle WP:CIR issues, but competence is a spectrum and completely prohibiting editing is not always the best solution to the problem. I think adding a (sub-)category for these kinds of requests would be useful for sorting them out per Trialpears. Wug·a·po·des 23:04, 29 May 2021 (UTC)
Indeed I did not know about {{edit partially-blocked}} (or I wouldn't have posted this in the first place, of course) and I appreciate that Chicdat pointed it out. Still, I do think that this sort of edit request ought to be categorized separately from COI and protected requests, since they require a different sort of scrutiny. Not necessarily more, just different. And if they're not being categorized at all, then who is answering them? Ivanvector (Talk/Edits) 23:27, 29 May 2021 (UTC)
The template is a wrapper for the {{Request edit}} template and thus is categorized as an edit request. It's not clear to me that the scrutiny is substantially different: the responding editor needs to familiarize themselves with the background context and determine the best next steps to determine if the edit can gain consensus support, or act as a starting point for an edit that the interested parties can agree upon. isaacl (talk) 23:36, 29 May 2021 (UTC)
I agree, I don't think it's different scrutiny so much as just editor interest. Dealing with COI edits doesn't interest me (partly because I don't know that area of policy well enough to handle requests), and I think protected edit requests are better answered by talk page watchers when possible since they can review the content better than I likely would. So I don't answer edit requests much, but I'd be interested in answering p-block requests if there was a category. Whether that's useful for the project as a whole, maybe, but I like it. Wug·a·po·des 00:06, 30 May 2021 (UTC)
I don't know if I fully agree regarding categorization or requiring the same scrutiny, but insofar as the request to create a template for pblocked editors to request edits, this can be considered resolved. Thanks to all. Ivanvector (Talk/Edits) 18:19, 2 June 2021 (UTC)

Change the partial block message to be orange or yellow instead of red

This proposal is clearly successful, and at this time, I think we should transition to talking about how we're going to implement the proposal. Mz7 (talk) 19:12, 11 June 2021 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Tech note: this is about styling the child div box .mw-contributions-blocked-notice-partial .mw-warning-with-logexcerpt in Special:Contributions that displays this text when a user is partially blocked.

If at all possible, I think that we should change the partial block notification box from red to either orange or yellow in order to differentiate partial from full blocks. This would be helpful to reduce confusion - most obviously for sysops who might not notice the message says "partially blocked" instead of "blocked" and not take action on disruptive editors, but also for other patrollers who might refrain from reporting a problematic editor if it seems at first glance like they have already been blocked. This was brought up a couple months ago, but there was not a substantial amount of discussion beyond determining that it may be technically possible to do something like this. Aspening (talk) 03:02, 1 June 2021 (UTC)

I agree - the present notice looks too much like a siteblock. This is particularly confusing when encountering partial blocking on ranges. Acroterion (talk) 03:10, 1 June 2021 (UTC)
  • I agree as well, full blocks and partial blocks should be more quickly and easily distinguishable. —El Millo (talk) 03:39, 1 June 2021 (UTC)
  • Support this as well. — Ched (talk) 09:18, 1 June 2021 (UTC)
  • Sure. ProcrastinatingReader (talk) 09:25, 1 June 2021 (UTC)
  • Great idea. Slightly embarrassing it's taken us so long to notice actually! ——Serial 09:44, 1 June 2021 (UTC)
  • Seems entirely reasonable, no real reason not to and plenty of good reasons for doing this. firefly ( t · c ) 10:13, 1 June 2021 (UTC)
  • I would support orange; yellow is usually considered to be more cautionary. 331dot (talk) 10:15, 1 June 2021 (UTC)
  • Are we talking about {{uw-pblock}} or something else/more? --Trialpears (talk) 10:18, 1 June 2021 (UTC)
    That's not very red. I assumed the log notice when you open a user's page to edit? ([12]) ——Serial 10:37, 1 June 2021 (UTC)
  • Looks entirely reasonable. Support. EpicPupper (talk) 18:06, 1 June 2021 (UTC)
Some notes for nerds are in here. See the mini-hatnote above for what the specific box is being disucssed
  • @Aspening: can you be more specific, exactly what templates/messages/etc do you want to change? (I have no idea what the partial block notification box is referring to). For example, here is a recent partially blocked user - what specifically do you want to change? This may very well not require a full VPPR discussion to make a color tweak. — xaosflux Talk 14:51, 1 June 2021 (UTC)
    Xaosflux: Aspening is probably referring to the red box on the top of this page: Special:Contributions/Ioannesko Sungodtemple (talk) 14:53, 1 June 2021 (UTC)
    @Xaosflux: I'm referring to the box that appears on the user's special:contributions page that says "This user is currently partially blocked." I am suggesting that that box should be orange or yellow for partial blocks to reduce confusion per the reasons listed above by myself and other users. 331dot also brings up a good point that yellow is more cautionary, so I'm now leaning more towards having this box be orange. Aspening (talk) 14:57, 1 June 2021 (UTC)
    @Aspening: OK, so that box is wrapped in a class, "mw-contributions-blocked-notice-partial", but itself is in a div with classes "warningbox mw-warning-with-logexcerpt mw-content-ltr". The second of those classes is being used for the styling from common.css. The message itself is from MediaWiki:sp-contributions-blocked-notice-partial. So adjusting the color style is not super-easy, but markup can be added to the message very easily (see example at testwiki:Special:Contributions/Example~testwiki). Would markup something like that be enough to address your concern? — xaosflux Talk 15:11, 1 June 2021 (UTC)
    @Xaosflux: Possibly - I think a color change would be preferable, but if that is difficult or impossible I think that emphasizing the partial block in that way could be satisfactory. Aspening (talk) 15:17, 1 June 2021 (UTC)
    @Aspening: I added the emphasis to to the text at least for now. Coloring may be blocked on a technical challenge as there is a class collision with mw-warning-with-logexcerpt there. Perhaps someone else has a technical idea that isn't an ugly hack. — xaosflux Talk 15:29, 1 June 2021 (UTC)
    Uh, is it an ugly hack to just overwrite it with .mw-contributions-blocked-notice-partial .mw-warning-with-logexcerpt {border-color:#fc3;background-color:#fef6e7;}? I didn't think that was verboten in CSS practice, but I'm no expert... Writ Keeper  15:36, 1 June 2021 (UTC)
    @Writ Keeper: I only said "may" :) Something like that could work, putting in hyper-specific styles in the common.css isn't ideal, but we don't have much else to work with on this message so may be the way. — xaosflux Talk 15:47, 1 June 2021 (UTC)
    The box is yellow per the MediaWiki defaults. Our common.css code is making it red. So having another rule to put it back to yellow may not be unreasonable. – SD0001 (talk) 15:52, 1 June 2021 (UTC)
    @SD0001: I'm not disagreeing with the color choices, just that applying layer after layer of overlapping css via common.css isn't ideal (even when it is the only tech option), that specific implementation isn't a hard blocker. That we are currently styling on "warning-with-logexcerpt" there isn't ideal either, but it is what it is. If this proposal keeps trending towards support we can mock up some technical solutions. — xaosflux Talk 16:04, 1 June 2021 (UTC)
  • Support Seems reasonable. --Jayron32 15:22, 1 June 2021 (UTC)
  •   Administrator note I've added some emphasis to MediaWiki:Sp-contributions-blocked-notice-partial while this is being discussed. If this proposal is implemented ideally that message can be deleted to default. — xaosflux Talk 18:12, 1 June 2021 (UTC)
  • Makes sense to me. ~ HAL333 01:04, 2 June 2021 (UTC)
  • I support orange because it's generally easier to read than yellow. —pythoncoder (talk | contribs) 20:16, 2 June 2021 (UTC)
  • Support To reduce confusion between partial and full blocks. — Preceding unsigned comment added by Jackattack1597 (talkcontribs) 01:26, 4 June 2021 (UTC)
  • Support either colour. Distinguishing full and partial blocks will reduce confusion and reduce the likelihood of unfortunate misunderstandings. Thryduulf (talk) 20:34, 4 June 2021 (UTC)
  • Support. Current display is confusing. – SD0001 (talk) 07:01, 6 June 2021 (UTC)
  • Support per everyone. Distinguishing partial blocks from site blocks is an improvement. No colour preference. Ivanvector (Talk/Edits) 12:08, 6 June 2021 (UTC)
  • Support per WP:SNOWPRO with preference for orange. Huggums537 (talk) 17:46, 6 June 2021 (UTC)
  • Support It's more intuitive, which helps the 'pedia. Tyrone Madera (talk) 19:22, 7 June 2021 (UTC)


Technical implementation

@Xaosflux, Aspening, Writ Keeper, and SD0001: I can see in your collapsed conversation that there is a potential MediaWiki:Common.css hack that could do this (e.g. to change the red back to the default yellow), but it seems more discussion on the technical implementation is needed. What would be necessary to implement this proposal? Mz7 (talk) 19:12, 11 June 2021 (UTC)

Testing on testwiki (testwiki:MediaWiki:Common.css) - waiting for update to populate it. — xaosflux Talk 21:07, 11 June 2021 (UTC)
Test cases:
  1. Normal block: testwiki:Special:Contributions/Xaosflux2
  2. Partial block: testwiki:Special:Contributions/Xaosflux2a
@Mz7: that what you are looking for? — xaosflux Talk 21:12, 11 June 2021 (UTC)
@Xaosflux: Ooh, yeah. That looks really nice. Mz7 (talk) 21:27, 11 June 2021 (UTC)
  Doing...xaosflux Talk 21:49, 11 June 2021 (UTC)
  Done @Mz7: see live example at Special:Contributions/Example. If there are any issues please post at MediaWiki_talk:Common.css#pblock-style. — xaosflux Talk 21:58, 11 June 2021 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Display UTC with current UTC time

I propose that instead of displaying the Time Zone as "UTC" plus an offset, it should be displayed as the current UTC (at time of page load) in addition to a refresh link.

- Current: UTC+05:00
- Proposed: 04:33, 5 June 2021 (UTC) + 05:00 [refresh]

This format will allow the viewer to easily compute the local current time while avoiding the complexities of trying to dynamically display the correct current time at that place. Nbardach (talk) 04:44, 5 June 2021 (UTC)

Please take the hint: it's not going to happen. Someone looking at the page on 1 July 2021 is going to be totally confused when seeing a cached time such as 04:33, 5 June 2021. Wikipedia does not support dynamic displays and displaying confusing text is not a good replacement. Johnuniq (talk) 04:54, 5 June 2021 (UTC)

@Johnuniq: It already happens on all of the Time Zone pages (ex: UTC-08:00), which each display the Current Time in that Time Zone plus the [refresh] link. Why should this be any different? — Preceding unsigned comment added by Nbardach (talkcontribs) 06:08, 5 June 2021 (UTC)

Hi, MediaWiki developer here. I think displaying the current time is a (technically) perfectly reasonable and trivially achievable proposal to implement on Wikipedia.
I do fully agree with the concerns laid out above in this section and the previous, in so far that it would be absurd to implement this with wikitext in a server-side fashion. However, such thinking is exactly why ideas and technical implementation need to be more separated from one another. Doing this server-side would require software changes to allow minute-level parser cache expiry (which I would not approve), or a fragile community-run purge bot (which I'd likely block). Apart form that, there'd still be the issue of punishing at least one visitor — every minute — with an unusually slow page load due to the server having to parse the page in its entirety. (I say at least one, since visitors will be queued behind one another; with a maximum queue length after which the copy from prior to the purge will be revived and served instead.) And after that, a high likelihood the result would still be off by a few minutes due to clock differences between the server and client, and the time it takes to transfer the data over the Internet. After that, the text would remain static while in the reader's browser and not update. Thus by the time someone actually looked at it, I'd give it a 50% chance of being off by at least two minutes compared to their own clock, growing more stale with every passing second/minute while they scroll up and down the page. So apart from any infrastructure concerns, I think this would offer a slow, confusing, and unprofessional experience to readers; even if it the servers did somehow instantly update it every minute (which they won't).
The appropiate way to implement something like this would be with a few lines of client-side JavaScript (via MediaWiki:Common.js, or a default-enabled gadget). Such script would be very trivial to write, and would not require any modern or complex APIs (I see Intl.DateTimeFormat was mentioned above, but this isn't needed). Assuming we aim for displaying hours and minutes (not seconds) this would not incur any notable performance cost on the browser.
The way I would approach this:

  • The infobox reserves a spot for the clock to be. If your preferred styling results in the spot being noticable if empty, then one could hide this reserved spot in CSS via .client-nojs. Thus hiding it in contexts where there is no JavaScript provided/enabled/supported.
  • The infobox annotates the spot with an HTML data attribute, indicating the offset in a way that is extra easy for JavaScript to pick up. E.g. <p data-tzoffset="-90">Offset: -01:30 <span class="tpl-place-currenttime"><!-- placeholder --></span></p>.
  • The JavaScript would be a small handful of statements to find this element, find the offset, substract it from the current minutes, and then simply render the hour and minutes. The ancient and widely-supported Date#setMinutes browser function even automatically takes care of rolling over the hours and such.

--Krinkle (talk) 23:48, 5 June 2021 (UTC)

  • If someone wants a UTC clock on their screen, they can enable it via gadgets already, it will be available on all screen at all times and can be useful for things like looking at discussion timestamps as well. — xaosflux Talk 03:19, 6 June 2021 (UTC)
  • This doesn't fix the summertime problem discussed above either, as the goal of this is to still compute the local current time and the local summertime state and offset would also be needed to accomplish that. — xaosflux Talk 03:21, 6 June 2021 (UTC)
  • Grateful to everyone, especially the dev Krinkle, for diving deeper on the display of the current time. Not sure how to address Xaosflux's concerns about local summertime states and locality's irregular time zone implementations, but hoping Krinkle and others will have some good ideas. Nbardach (talk) 06:15, 6 June 2021 (UTC)
  • @Krinkle: Your suggestion would work for static UTC offsets, but the original discussion was about times in locations. Many locations need daylight saving time to be taken into account for correct time display. Anomie 11:55, 6 June 2021 (UTC)
    • @Anomie: I understand, but things like that also affect the offset that the infobox would display today without a live time. I assumed that this is already handled in some way. That information, I would expect, is preprocessed by the template output to inform the JS code the same way it would inform a human today. I don't know what the preferred way to encode this information is nowadays, but wherever/however we do it elsewhere, I suppose we could do it the same here. E.g. add the UTC timestamp of the next switch and encode it into another attribute. Again, this motivated by wanting to improve the way the information is presented even without a live clock. I think I understand better now why you opted for Intl.DateTimeFormat, and perhaps that could still work with the fallback being to hide the destination box. The downside of that approach, however, is that it suggests to me that we haven't actually figured out a way to explain/present this information to readers in general, which to me is the more impactful problem to solve, if we haven't already. --Krinkle (talk) 15:53, 6 June 2021 (UTC)
      • You assume incorrectly. There's no attempt in articles to say what the current timezone offset is, infoboxes just state what the normal and summer offsets are. Which is fine, people who don't already know how DST works can follow the included wikilinks to learn about it. But saying "The current time is 13:20 or 14:20 depending on whether it's DST or not" wouldn't work very well. Encoding a switch in wikitext somehow (probably via a template or module, like we do with Template:Calendar date for some holidays) could work, but would still need mass purging semiannually. Anomie 17:25, 6 June 2021 (UTC)
    • Could a dev please explain why client-side JS like this wouldn't work?
          function calcTime(city, offset) {
              // create Date object for current location
              var d = new Date();
              // convert to msec
              // subtract local time zone offset
              // get UTC time in msec
              var utc = d.getTime() + (d.getTimezoneOffset() * 60000);
              // create new Date object for different city
              // using supplied offset
              var nd = new Date(utc + (3600000*offset));
              // return time as a string
              return "The local time for city"+ city +" is "+ nd.toLocaleString();
          }
          alert(calcTime('Mumbai', '+5.5'));
          }
      
      Nbardach (talk) 18:02, 6 June 2021 (UTC)
      • @Nbardach: That's the general idea of Krinkle's suggestion. But figuring out what to pass for offset for a place like New York is problematic. There it would be -4 from mid-March to the beginning of November and -5 for the rest of the year. Anomie 00:22, 7 June 2021 (UTC)
        As you've hinted at above, new Intl.DateTimeFormat('en', { timeZone: 'America/New_York', hour: 'numeric', minute: 'numeric' }).format(new Date()) gives the current time in New York, taking into account DST. Doesn't work in older browsers, those could fallback to non-JS behaviour. – SD0001 (talk) 04:23, 7 June 2021 (UTC)
      • Perhaps you can discuss your ideas at mw:MediaWiki_talk:Gadget-UTCLiveClock.js, as it might be a good place to implement it. isaacl (talk) 04:49, 7 June 2021 (UTC)

Wikipedia should Celebrate Autistic Pride Day

There is consensus against this proposal. Closing per WP:Snowball clause. —pythoncoder (talk | contribs) 13:44, 9 June 2021 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.


Upcoming 18th June is Autistic Pride Day. Can wikipedia celebrate that day, such as by showing an infinity badge on the front page? Where is the right forum to discuss this proposal? Regards. RIT RAJARSHI (talk) 03:59, 7 June 2021 (UTC)

@RIT RAJARSHI: Generally there hasn't been much support for celebrating individual events, and I don't think the community would support adding an infinity badge to the main page. I think the best thing you could do would be to have a read of the guidelines for selected anniversaries, and if the event/article meets the criteria to add it to the page for June 18. 192.76.8.73 (talk) 11:25, 7 June 2021 (UTC)
This is an issue dear to my heart, as I am a trustee of a small charity whose mission is to stage plays that raise awareness of autism (and I am deeply honoured to have been invited to become the only trustee without autism), but I would oppose this. I think a slippery-slope argument is valid here. Why shouldn't we do something for Mental Health Awareness Month, or AIDS Awareness Week or International Tea Day, which I am sure are dear to some editors' hearts? The only such day that we should take note of, if it exists, is one to raise awareness of open encyclopedias that anyone can edit. Phil Bridger (talk) 12:50, 7 June 2021 (UTC)
We don't celebrate individual days in a formal way, but relevant submissions of articles following our gazillion other rules can be highlighted on the Main Page on a given day. Did you know allows for special date requests for a given new article, and so does Today's Featured Article. If you have an article that meets the rules and is appropriate for Autistic Pride Day, you'll be welcomed with (fairly) open arms. (18 June this year might be too close, though). —Kusma (talk) 13:09, 7 June 2021 (UTC)
@Phil Bridger: One thing to be make clear; Autism awareness and autism pride isn't same thing. Autism pride stresses on the thing that autistic individuals have right to be ourselves and we do not have to force mask ourselves into a broken version of neurotypicals. We have the infinite potential but for that we need the niche which is accessible for us. We also speak that world needs more of us. We speak against eugenic elimination of genetic diversity. We encourage cognitive diversity. We believe that strength lies in diversity and not in sameness. We say "Nothing about us without us. We share day to day our experience about hidden disability and how the disability doesn't belong to the affected person but it belongs to an inaccessible world. As a person in the spectrum, I feel these messages are missed or omitted in the autism awareness programs; and both are very different.
Now why to spread autism pride? Because awareness is misleading. Awareness often leads to fear about autism. What helps us, is understanding, acceptance and confidence. Yet awareness is a majoritarian (neurotypical) view, funded by neurotypical agencies, governed by mostly neurotypical-led charities. Awareness programs are something about us without us. In contrast, what actually helps us to flourish and expand our potentials, is not promoted by neurotypical authority. It is promoted by our little efforts.
Now I agree its primarily an encyclopedia, but since it perform various anniversaries, an 1 day anniversary would not be a big deal. Regards. RIT RAJARSHI (talk) 13:22, 7 June 2021 (UTC)
This article was presented several times on this day series
So it should be made a regular anniversary. RIT RAJARSHI (talk) 13:30, 7 June 2021 (UTC)
I agree that awareness and pride are different things, but disagree that there is anything bad about awareness, or that it in any way excludes pride. Quite the reverse. Much fear stems from a lack of awareness, and, as I said, I am the only trustee of the charity that I am involved in who doesn't have autism, so it can't be accused of being run by neurotypicals or being a "without us" organisation. Indeed that is a criticism that would be better levelled at Wikipedia if this proposal was agreed. Let's think about what's best rather than indulge in infighting about words, over which we would find it just as difficult to get agreement among diverse people with autism as among diverse neurotypicals. Phil Bridger (talk) 16:26, 7 June 2021 (UTC).
@Phil Bridger: Thank you for all your inputs. "Lets think what's best"... yes definitely, everyone deserves the niche where they can function at best. Instead of moulding oneself. We appreciate the whole diversity (not only autism and ASD), that includes neurotypicals, and we are thankful to the little number of neurotypicals who tries to understand instead of moulding us. RIT RAJARSHI (talk) 02:06, 8 June 2021 (UTC)
  • OPPOSED - It is not our job to promote pride days… no matter how worthy the cause. Posting a DYK or featuring a related article is fine, but placing banners and emblems on our main page is not. Blueboar (talk) 14:13, 7 June 2021 (UTC)
  • Oppose adding any sort of special logos to the MP for any of these condition-recognition-days; however assuming the article is in good shape feel free to drop an edit request at Wikipedia talk:Selected anniversaries/June 18 to have it listed at OTD again. — xaosflux Talk 14:36, 7 June 2021 (UTC)
  • Oppose per others above. I'm glad Autistic Pride Day exists, and it's a great way to help combat stigma/discrimination, but that is simply not our role and this would open up a can of worms. {{u|Sdkb}}talk 14:54, 7 June 2021 (UTC)
  • Oppose. Major NPOV issue, along with other concerns mentioned above. Sungodtemple (talk) 15:27, 7 June 2021 (UTC)
  • Oppose. We already have a process and set of guidelines for determining what gets to go on the main page; we shouldn't be overriding that process to add events with substandard articles simply because they're for a worthy cause - that will open a massive can of worms. If you want to see the event on the main page it should have to go through the same process as everyone else, which in this case will involve fixing up the clean-up tagged under referenced section which caused it's removal in the first place. 192.76.8.73 (talk) 16:01, 7 June 2021 (UTC)
  • Oppose per all Opposes above. Tyrone Madera (talk) 19:23, 7 June 2021 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Archive RfPP reports (again)

It's snowing in June, and withdrawn by proposer. ProcrastinatingReader (talk) 13:11, 12 June 2021 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.


Back in April, I proposed that RfPP reports be archived. However, no action was taken on this, and the discussion itself was archived. I was just wondering if this will happen, and if so, when. 🏳️‍🌈 Chicdat  Bawk to me! 11:41, 7 June 2021 (UTC)

Chicdat I'm still not clear on why it is needed. I'm frequently reviewing RFPP and I never felt the need to look into an archive. I also use WP:Twinkle which tells me if the page has been protected before and links to the protections page. The bot will tag some some requests with "Automated comment: A request for protection/unprotection for one or more pages in this request was recently made, and was denied at some point within the last 8 days". Even then I don't go back into the archive to see. I go the page and see if it is necessary now. CambridgeBayWeather, Uqaqtuq (talk), Huliva 00:51, 11 June 2021 (UTC)
CambridgeBayWeather Just because you wouldn't find it useful doesn't mean others wouldn't. 🏳️‍🌈 Chicdat  Bawk to me! 10:11, 11 June 2021 (UTC)

I'm pinging the editors involved in the last discussion. @ProcrastinatingReader, PEIsquirrel, Jayron32, Pppery, Xaosflux, Cyberpower678, GenQuest, Malcolmxl5, CaptainEek, Beeblebrox, Nosebagbear, Fastily, and ToBeFree: 🏳️‍🌈 Chicdat  Bawk to me! 10:11, 11 June 2021 (UTC)

  • That a proposal is archived with no action is usually a good indicator that there is little interest in it. I am not enthused by it. It’s not clear to me how it would be used or what the benefits would be. --Malcolmxl5 (talk) 10:28, 11 June 2021 (UTC)
  • Please explain clearly why this should be done? and, what are the benefits of this action? I thought this was done and put to bed. Right now, this sounds like you want to take clutter from a pile over 'there,' and start a new pile for it over 'here.' But, what is your reasoning, and how is that a benefit in any way to WP? GenQuest "scribble" 12:31, 11 June 2021 (UTC)
  • I'm also struggling to see why we should bother with this? it seems like a change that will simply create hundreds of useless archive pages that no-one is ever going to look at. These aren't like deletion discussions or arbitration enforcement reports where someone might need to pull them up again in 10 years time for a related deletion discussion/arb case/RFC, basically every one of these reports is a standard template and one line sentence, with a template response from an administrator. If a request at RFPP is acted upon then there will be an entry in the protection log for the page which already serves as a reasonable record of what kind of disruption has occurred historically, and if a request for page protection is declined then I fail to see any reason we would need to access it again. The fact that a page wasn't protected 6 months ago should have no relevance at all on a new report - a decision on whether a page should be protected or not should be based on what disruption is occurring now. 192.76.8.73 (talk) 13:30, 11 June 2021 (UTC)
  • My opinion has not changed; I would find such a process completely useless, but will not get in the way of anyone doing the work necessary to make it happen. It serves no purpose to myself, as an admin, in doing my work at RFPP, and provides no benefit in that area. I'm also neither smart enough nor imaginative enough to see how any admin could find any use in such a system, but I'm a pretty low bar in that regard, which is why I won't stop anyone... --Jayron32 13:42, 11 June 2021 (UTC)
  • There was actually a consensus in the previous section; 7 leaning oppose/not useful, 2 support, and 1 indifferent. Combined with unique responses above, that's 9 oppose, 2 support, 1 neutral. ProcrastinatingReader (talk) 13:45, 11 June 2021 (UTC)
  • Archiving the pages makes them available to Search and Whatlinkshere. This has advantages and disadvantages: sometimes forgetting things is better. I haven't seen a convincing use case yet. —Kusma (talk) 13:47, 11 June 2021 (UTC)
  • Meh, but I don't think these are really needed. They don't really set precedent like an xFD does. If it is granted, the protection log can link to whatever the protecting admin wants to link to; if it is declined that won't preclude a non-extremely-short-time-in-the-future request from being able to be reviewed on its own merits. — xaosflux Talk 15:22, 11 June 2021 (UTC)
  • Why not automate adding a summary that includes the permanent link to the RfPP revision ID if the fulfilling admin is taking action from there. This is how the fulfilled WP:RM/TR requests are now tracked without creating archive bloat. -2pou (talk) 15:49, 11 June 2021 (UTC)
  • Again, not sure what problem this would solve. There is already a quite useful protection log for pages. CaptainEek Edits Ho Cap'n! 18:58, 11 June 2021 (UTC)
  • I agree with everyone above. No convincing reason (or, frankly, any reason at all) has been articulated for why this is necessary. Mz7 (talk) 19:03, 11 June 2021 (UTC)
  • Can someone please withdraw this discussion for me? It's obviously not going to get anywhere, but I am banned from closing discussions, so I can't do this myself. Chicdat (talk) 12:38, 12 June 2021 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Growth team feature test begins tomorrow (June 8)

Hello everyone -- I'm Marshall Miller; I'm the product manager for the WMF Growth team. I'm following up on @Nosebagbear's post from April 23 about testing the Growth team's features here on English Wikipedia. In short, the Growth team features provide new account holders with important tools to get started: they're suggested articles that need simple edits (based on maintenance templates) and they are assigned a mentor to whom they can ask questions.

In the past weeks, lots of English community members have tried out the features, and we've heard largely positive reactions and ideas. We also have 16 mentors signed up (we don't need more for this test, but we will need more in the future!) After discussing it with the most involved community members, we set a date to begin testing the features on this wiki. Our plan is to start giving the Growth features to 2% of newcomers starting tomorrow, June 8. This means that for all new accounts created starting tomorrow, 2% of them will have the Growth features and the rest will not. Because English Wikipedia gets about 130,000 new accounts per month, we expect this will amount to 2,600 newcomers having the features over the course of the month. They'll mostly be visible in Recent Changes and watchlists by completing suggested edits and asking questions to their mentors. These edits can be found with the tags #Newcomer task, #Mentorship module question, and #Mentorship panel question.

While the test is running, the Growth team will monitor newcomer activity to identify if anything negative is occurring (like an increase in vandalism) -- if something goes wrong, we'll be able to quickly make changes. At the end of about four weeks, we'll reflect on the data and ask mentors about their experiences to decide how to proceed, in terms of whether to increase the number of newcomers who receive the features.

I hope this sounds good to everyone here -- we think we've planned this carefully with community input, but I definitely want to hear if anyone has questions or concerns. I'll plan to post again tomorrow to confirm that the test has started. MMiller (WMF) (talk) 18:42, 7 June 2021 (UTC)

Also would like to mention, please don't be a mentor, there already are more than 15 of them. Oh shoot, Streisand effect. Sungodtemple (talk) 22:10, 8 June 2021 (UTC)
Hi all -- we began the test today, giving the Growth features to 2% of new accounts being created. Please follow along with the progress on the project's talk page! MMiller (WMF) (talk) 04:51, 9 June 2021 (UTC)

Allow links to multiple articles in other languages/to sections of articles

The current method of allowing only one link between articles of different languages assumes that a concept that is sufficient to make an article in one language will always be one article in another language, and never multiple articles. However, there are many instances when this is not the case. For example, there is the English Changchun which discusses its history as Hsingking in the same article. However, in the Japanese Wikipedia, Hsingking has one article, while Changchun also has one article. Both Japanese articles are long enough that it seems impracticle to merge them, and it doesn't seem right to make the Japanese Wikipedia change their articles based on the English Wikipedia.

My suggested solution would be to allow articles like the Japanese Hsingking article to link to the section of the English Changchun article that discusses Hsingking. The English article could still link to the Japanese Changchun article, as there is a disambiguation at the top of the Japanese Changchun article that would allow people to make their way to the Japanese Hsingking article. Erynamrod (talk) 16:16, 10 June 2021 (UTC)

@Erynamrod: You're talking about the interlanguage links that appear in the sidebar aren't you (just to be sure that I'm writing about the same thing)? These are currently populated using wikidata, which only supports 1:1 linking of articles and does not support linking to sections, but there is a workaround - you can still use the old style manually entered links. You can only have one link for each language in the sidebar of each article, but you can have multiple pages on other wikis linking to the same article, e.g. to add a link to the Hsingking article on the Japanese article just add something like [[en:Changchun#Manchukuo and World War II]] anywhere on the page. The English article can only have one link in it, so as you note the only way of dealing with it is to have disambiguation on the Japanese side. 192.76.8.73 (talk) 18:03, 10 June 2021 (UTC)
Hsinking is a redirect to Changchun. If you like, you can link the redirect page to the Japanese Hsingking on Wikidata and add a {{Wikidata redirect}}. – Finnusertop (talkcontribs) 18:44, 10 June 2021 (UTC)

Mis-placed RfC to elevate WP:DUCK to guideline status

  FYI – Pointer to relevant discussion elsewhere.

Please see Wikipedia talk:The duck test#RfC on making this a guideline. This is a regular RfC that would elevate that {{Essay}} to {{Guideline}} status. It really belongs as a WP:PROPOSAL on this page. I suggest that it be shut down there and moved here, actually. If it's worth bothering. We didn't even make WP:BRD a guideline, after many proposals to do so.  — SMcCandlish ¢ 😼  18:28, 12 June 2021 (UTC)

Idea lab

Making Wikipedia More Welcoming To The Modern User

I may be wrong, but in 20 years, Wikipedia's design has not changed much. The design was great for the online innovations of 2001, but... not so great now. Websites nowadays have simple, user-friendly buttons, accounts systems that have cross-platform "read later" lists (or better yet, folders too), personalised feeds, etc. Wikipedia still has a fairly limited UI, while the rest of the internet has moved on. The app has some modern intergrations, but these don't sync with the website so it's still limited in scope.

Now obviously a "For You" feed would include countless data and privacy concerns but surely there could be some sort of opt in system for a user-data driven, modern UI? Like a personalised feed that simply recommends new articles based on ones you have read would do wonders for this. Is there any reason why this can't happen? Squid45 (talk) 17:38, 17 May 2021 (UTC)

In your user preferences, you can change your skin and even create your own. There is even a list of cool skins. 'Read later' lists can be bookmarked in-browser. And note that Wikipedia is an encyclopedia, not a social media website or dictionary. A personalized feed would defeat the purpose of Wikipedia. Sungodtemple (talk) 17:53, 17 May 2021 (UTC)
One of the attractions of Wikipedia is that it doesn't make silly suggestions of what we might like in the way that many other web sites do. It is a way of selling you more or telling you what you should think rather than anything that benefits the reader. If that's modern, then I'm proud to be old-fashioned. Phil Bridger (talk) 18:10, 17 May 2021 (UTC)

Can I also say that one of the positive attributes of Wikipedia is that, unlike many other websites, it does not ask us whether we want to accept cookies? Rollo August (talk) 20:12, 17 May 2021 (UTC)

I'm really not too keen on the idea of a "For You" feed, or user data driven navigation. For starters there's the privacy issues alluded to in the op. Tracking and storing user movement around the site so that an algorithm can guess what readers might be interested in would be a massive divergence from current policy where even stuff like checkuser data is only kept for 60 days for user privacy, and if it's an opt-in system you'll never get enough data to produce meaningful results (most of our readers do not have accounts, and I imagine only a fraction of registered users would be happy with the WMF tracking their reading). How do you propose to separate user data from reading from user data from editing? Any tracking of where our registered users go is going to be massively polluted with nonsensical page jumps from things like Auto wiki browser, new page patrol, anti-vandalism work, sorting through cleanup categories, etc.
Fundamentally though the idea of driving user navigation by page views should be unnecessary - navigation should be built into articles. If a paragraph mentions something that a reader might be interested in it should be a wikilink, if there's a series of articles on a topic that make sense to read together they should be presented together in a navbox, if there are articles that are a natural follow on from the article a reader has just read they should be listed in the "see also" section, and all articles should be sorted into appropriate categories to make it easy for editors to find related content. We also have a huge number of volunteers working on maintaining the front page as a showcase of high quality content from around the site, which has enough variety to serve\ well as a list of recommendations for things readers might be interested in reading. 192.76.8.91 (talk) 22:41, 17 May 2021 (UTC)

When the "modern user" gets used to something which is 'convenient' but not actually in their interests and asks us to implement it too, our best option is to politely say "We won't give you that, but we're not refusing out of malice; here are the reasons why this change is actually not in your interest". It's a good opportunity to try to teach people to respect themselves, actually. DesertPipeline (talk) 05:53, 18 May 2021 (UTC)

I do like the reading lists feature in the iOS app, and wish that was available in the browser version. ⁓ Pelagicmessages ) – (14:07 Sun 30, AEST) 04:07, 30 May 2021 (UTC)

Minerva and Timeless skins have a "related articles" widget which works in mysterious ways, but I don’t see it "driving user engagement" the way YouTube's suggestions do. When I'm reading articles, I tend to use navboxes and the See also section, though sometimes Related Articles does surface something pertinent. ⁓ Pelagicmessages ) – (14:07 Sun 30, AEST) 04:07, 30 May 2021 (UTC)

@Pelagic, the "Related articles" feature is available on the desktop site (just not here, because editors didn't want it). It's just the top three search results, preloaded for convenience. Put morelike:Article_title into the regular search box, and you'll get the same effect. Click here to see the results for morelike:fish.
(You can manually control the search results if the results are poor. This sometimes happens with very short articles (e.g., "Joe Film is an actor known for once voicing a My Little Pony character", which can rate pretty high in searches related to the only thing linked in that substub). Whatamidoing (WMF) (talk) 02:55, 3 June 2021 (UTC)

Watchlisting a specific user’s contributions

I have an idea I'd like to suggest. So recently, InedibleHulk commented on my talk page. I absolutely LOVE the sense of humor he frequently uses during discussions and in the edit summary, whatever the circumstances are he somehow has me laughing my ass off all the time whenever I encounter him. I realized that if I have a bad day, I can just go to his contribution hostory and see posts of his that are guranteed to make me laugh. This made me think, why not make it possible to watchlist contributions? Primarily it can be used for legitimate purposes (like monitoring a new user's contributions for mentorship purposes or a recently unblocked or otherwise scrutinized user to monitor their edits and behavior, or to keep track of edits and improvements for a particular topic if the user specializes in that topic), but it also has the potential to be used for personal pleasure too such as in the case I provided. Would this be a good idea to extend watchlist abolities to a specific user's contributions? DrewieStewie (talk) 03:17, 18 May 2021 (UTC)

DrewieStewie, m:Community Wishlist Survey 2021/Admins and patrollers/Watchlist of usersAlexis Jazz (talk or ping me) 03:29, 18 May 2021 (UTC)
phab:T2470 has been opened for this since 2004! — xaosflux Talk 15:36, 18 May 2021 (UTC)
See also phab:T33105. — xaosflux Talk 15:37, 18 May 2021 (UTC)
It's not quite what you want in this particular situation, but you can set up RSS feeds for individual user contributions as well as page histories. Not many people regularly use RSS readers any more, but I think I had a couple of these set up back when I did do so. Andrew Gray (talk) 16:47, 18 May 2021 (UTC)
Anyone who actually wrote a script for this would have a very high likelihood of being SanFranBanned and having the source code oversighted, unless the person you want to follow has to approve you running such a script on them (and I can't imagine many people giving such approval, except in a few very limited training/mentoring situations). To quote the WMF on exactly this proposal:

Following and being followed must be a mutual agreement. The idea would be to have a way to give agreement on the fact that you can be followed. On the watchlist, when you add a user, that user will receive a notification to agree (or not). That notification would gather a message from the follower and a link to the follower's talk page. Resume that following may be possible on the watchlist or into preferences page.

 ‑ Iridescent 19:04, 18 May 2021 (UTC)
This WMF statement sounds incompatible with the CC-BY-SA license that writers here agree to. The right to copy someone's work, must surely also include right to the awareness that the work exists. And the knowledge of each individual piece of work implies being able to know everything a user does under that license, from the time they release the copyright, ie when they save. Graeme Bartlett (talk) 23:12, 18 May 2021 (UTC)
The licence does not include a requirement to notify the authors of all copies or derived versions, to have a central registry of all copies or derived versions, or other comprehensive awareness mechanisms. It would be a significant burden and potential privacy concern for distributing or modifying works in a free (libre) manner. That being said, the recent changes feed and the watchlist are awareness mechanisms for changes made on Wikipedia. User contributions are already fully visible, either through the special contributions page or through the recent changes feed. Anyone can build an interface to display them as they wish (they can create a client that tracks which contributions they have already clicked through to see, for example) and make use of it on their own computer. isaacl (talk) 02:25, 19 May 2021 (UTC)
Um... no? I thought we discouraged hounding. Seems like this would just provide an easy tool to make it worse. 🐔 Chicdat  Bawk to me! 10:41, 19 May 2021 (UTC)
  • It's as was the result from the Community Wishlist - no-one thought it had been requested in bad-faith, or that the supposed positives weren't, in fact, completely possible. It was just that the ease of negatives that can come from this are also obvious and not really viable enough to avoid to make it worthwhile doing, or even enabling. It'd be a bit OTT for a SFB if someone did this unless there was evidence of serious misuse or they duplicated the work after having it removed once, but it would certainly not be wanted. I would not advise creating a method of doing so. Nosebagbear (talk) 22:22, 30 May 2021 (UTC)

Syncing of Reading List Across the App and Website

On the iOS and the Android Wikipedia apps, there is a "Reading List" feature. Would it ever be possible for this to sync with the website too, and not just other apps? A new "reading list" button on the website would be very helpful! Squid45 (talk) 14:44, 22 May 2021 (UTC)

There are some browser extensions that allow you to save articles to the apps' reading list. I don't know how well these work, or if they work the other way round (i.e. view articles in the apps reading list from your desktop browser). the wub "?!" 14:29, 23 May 2021 (UTC)
Tehehe, when I said the same thing up above, I wasn’t aware of this section! If logged in the iOS app seems to sync the reading list to your Wikipedia account, so it must be in the MediaWiki database somewhere? ⁓ Pelagicmessages ) – (15:15 Sun 30, AEST) 05:15, 30 May 2021 (UTC)

Citation needed tagging in VisualEditor

  Moved from Village pump (proposals) – Tol | Talk | Contribs 05:10, 25 May 2021 (UTC)

I think the ability to be able to select and place "citation needed" through the cite feature in the visual editor with a single click would be helpful. Not needed but it would save time. TigerScientist Chat > contribs 21:05, 18 May 2021 (UTC)

Copy the following text and paste it in any article: {{cn}} This will simply work with the visual editor in the way you're requesting. ~ ToBeFree (talk) 21:09, 18 May 2021 (UTC)
ehh I guess maybe. TigerScientist Chat > contribs 15:10, 19 May 2021 (UTC)
You may want to post this on Phabricator if you really want this, however I think that just using the template is easy enough personally. EpicPupper (talk) 19:00, 19 May 2021 (UTC)
@TigerScientist: If you'd like, I can see if I can put together a user script which could add another button to to this. Tol | Talk | Contribs 05:28, 25 May 2021 (UTC)
Tol not needed but if it doesn’t take much time or effort go ahead. Thank you for even suggesting this. TigerScientist Chat > contribs 05:30, 25 May 2021 (UTC)
@TigerScientist: No problem. I haven't worked with VE before, so I don't know how long it'll take, but I'll try to get something to you within about two weeks. Tol | Talk | Contribs 18:24, 26 May 2021 (UTC)
  Done: The script's documentation is at User:Tol/VECN, including installation instructions. Let me know if you have any questions! Adding stuff to VE is remarkably simple. Tol | Talk | Contribs 20:36, 26 May 2021 (UTC)
WOAH thank you Tol! TigerScientist Chat > contribs 16:01, 27 May 2021 (UTC)
@TigerScientist: You're welcome! Tol | Talk | Contribs 20:19, 27 May 2021 (UTC)
@Tol, you are the only person I have ever heard say that adding a script to VisualEditor is easy. Would you please put mw:VisualEditor/Gadgets, mw:VisualEditor/Gadgets/Creating a custom command, and mw:VisualEditor/Gadgets/Add a tool on your watchlist? They're very low traffic pages, and Flow/Structured Discussions will ping you in Echo/Notifications if anyone ever posts anything to their talk pages. Also, you might be interested in mw:New Developers. Whatamidoing (WMF) (talk) 03:07, 3 June 2021 (UTC)
@Whatamidoing (WMF): Wow; alright! I still don't fully understand VisualEditor, but I'm more than happy to watchlist those pages. Thank you for the resource! Tol | talk | contribs 05:48, 3 June 2021 (UTC)

Report a page

Can you create a button "Report this page to the administrators" like on other sites? It was very hard to find the page to call administrators.Tint Last (talk) 04:24, 28 May 2021 (UTC)

Could you give us examples of those "other sites"? Nardog (talk) 04:27, 28 May 2021 (UTC)
On https://www.reddit.com/r/pics/comments/nmy9sd/at_the_salt_lake_city_farmers_market_a_few_years/ there is a small flag and the word "report" to report the post. On Twitter I can use "Report Tweet". Tint Last (talk) 17:23, 28 May 2021 (UTC)
If you see an error, just fix it. Sungodtemple (talk) 17:24, 28 May 2021 (UTC)
More often than not, new users don't know what the role of administrators is on Wikipedia. The rule of thumb is that any normal process starts with editors who are not administrators, and only when a decision is made are administrators called to implement it. There are ways administrators find such pages and usually don't need to be specifically alerted for them. It's quite rare for administrators to be called to act straight away without some editor-driven process preceding it. – Finnusertop (talkcontribs) 08:23, 28 May 2021 (UTC)
{{sofixit}} or send to CSD are "expected" responses for the most obvious "problem pages" - but these are not necessarily intuitive for brand new editors. (c.f. why edit requests get sent to OTRS by brand new editors) -- ideas for improvement could be useful. — xaosflux Talk 12:43, 28 May 2021 (UTC)
I'm sorry. I thought I had found the page to report to administrators:Wikipedia:Administrators' noticeboard and the dispute on Bob Coronato was settled by the administrators. But the other administrator told me I should have reported List of songs about Alabama by email? With a button to report pages to the noticeboard it would be easier to make a report. Tint Last (talk) 17:35, 28 May 2021 (UTC)
@Tint Last: comparatively few of the issues you might want to report are really "something for the admins" - unlike most sites, there is little that admins can do unilaterally that any regular editor cannot also do, and in the field of content, admins don't have any special authority. The majority of what we do is execute what the general Community (or the little bit of it interested in a particular article) decides, if that needs any of our broader tools. There's a few bits where that's not true - e.g. I can and do unilaterally block an obvious vandal while a normal editor would report to The board for vandalism, if I wasn't "involved". Nosebagbear (talk) 13:27, 30 May 2021 (UTC)

Sometimes AIV is too slow.

I’ve reported a lot of vandals to administrator intervention against vandalism, and while I think AIV is great for most cases, I think that it can be too slow in some serious cases. Last night was one of those— there was a group of trolls attacking Waiuku; I took them on with the help of two others, but the edits kept coming. LizardJr8 reported them, but I knew it would be a while before an admin came to help. The vandals were destroying the page quicker than we could fix it. Then I decided to cut the AIV line and go straight to Liz. She speedily dealt with it. What I think we should do is create a new template. It will serve as a kind of Bat-Signal to quickly get an admin’s attention for cases of vandalism that need to be dealt with immediately, not to be dealt with at the whim of anyone that’s just passing by. Of course, I recognise there would be an issue with new users thinking that their cases of vandalism trump all other cases in importance, and admins would be flooded with requests. I’m not sure if this is possible, but perhaps we can make it so that only more experienced editors have access to the template (maybe as a part of Twinkle?). That way, they have enough experience under their belt to know what cases are high priority and what cases aren’t. It would work like this— once a user finds an admin, they go the the admin’s talk page, open the Twinkle menu, and select the template. Maybe there’s one or two boxes they should fill out, such as the name/IP address of the vandal or amount of disruptive edits they made. In summary, this feature would help users in an active vandalism crisis quickly get hold of an admin. A Twinkle template would allow them to quickly get the information conveyed instead of creating a lengthy plea for help (like what I do, LOL). I would love to hear your thoughts on the matter. 🐍Helen🐍 20:27, 28 May 2021 (UTC)

HelenDegenerate, See Wikipedia:Requests for comment/Responder role for a proposal (which doesn't appear to be making any progress) from ProcrastinatingReader for one way to deal with this. -- RoySmith (talk) 21:46, 28 May 2021 (UTC)
I think we had a few more things to figure out, but to some degree I don't think it would pass if it went live now. It's probably better to try it if/when a greater portion of the community feels there is a problem here. ProcrastinatingReader (talk) 21:57, 28 May 2021 (UTC)
Oh yeah, this problem. I think we should have a chat room (IRC, Matrix, Discord, whatever) where some admins hang out, and there could be a command that'll ping one of them, rotating among the admins in the room. There should be either a Twinkle button or a separate user script that'll send the command with a link to a specific AIV case. We can figure out access control later. I've been meaning to slap together a prototype for a while now - we don't even need to ping anyone for starts, just post a message - and thanks for the reminder. Enterprisey (talk!) 03:22, 29 May 2021 (UTC)
Did you know that... believe it or not, we need more administrators? The solution is actually things like: a) making RfA more active. b) making RfA less toxic. c) making RfA more encouraging. If we could do that, then this thread never would have started. 🐔 Chicdat  Bawk to me! 12:16, 29 May 2021 (UTC)
What is the difference between (b) and (c), between making RFA less toxic and making RFA more encouraging? Robert McClenon (talk) 22:53, 30 May 2021 (UTC)
From what I have heard, d) be more circumspect before reporting things to AIV might also help. Anecdotally, there are a lot of questionable reports. Jo-Jo Eumerus (talk) 13:06, 29 May 2021 (UTC)
What about having the bot move to the top reports where the user has fresh reverted edits after the report tinestamp? –xenotalk 13:15, 29 May 2021 (UTC)
Xeno, that sounds intriguing S Philbrick(Talk) 19:17, 29 May 2021 (UTC)
@Xeno:, I like that idea. I wonder— would we create a new bot to do the job, or would a preexisting one be in charge of moving the reports? If we used a preexisting one, maybe we can make ClueBot NG do it— it is an anti-vandal bot, after all. And one other thing: to draw extra attention to serious vandalism crises, perhaps the bot puts some kind of brightly-coloured symbol by it to show it is a high-priority case. What do you think? 🐍Helen🐍 23:56, 29 May 2021 (UTC)
HelenDegenerate: it would probably just be a new feature request for the AIV helperbot, but the first step would be confirming with AIV regulars to ensure it's a desirable change. –xenotalk 00:27, 30 May 2021 (UTC)
This is interesting. The bot would need to be running every minute or two to be useful, but I'd have no objections. I can't see any way to avoid a large proportion of the vandalism reports wanting to use the special template. IRC obviously has requests for this. Discord has informally - you can just ask if someone is free to help, but we are not a semi-formal adjunct like the IRC and we like to keep stuff on-wiki where it belongs Nosebagbear (talk) 13:30, 30 May 2021 (UTC)
@Nosebagbear:, I think I have the solution to that: simply restrict the use of the feature to extended confirmed users. Or if we’re talking about Xeno’s idea, there won’t be a problem with that, as only one entity would be able to use it— AIV Bot. 🐍Helen🐍 22:08, 30 May 2021 (UTC)
While I like the idea of sorting the reports, I am a bit afraid of edit conflicts. Constant bot edits will make it difficult to annotate reports. —Kusma (talk) 22:44, 30 May 2021 (UTC)

@HelenDegenerate: the vast majority of AIV notices are already done by EC-editors. It's not that I think they'll spam it to be annoying, I just think that anywhere up to a third of AIV reports (given that by the time someone does that it's already the 3rd (or more) issue) are going to make individuals "this is a bad, rapid case, I should use this" or "they've vandalised after being reported to AIV, we should use it now". Limiting it in that way will not avoid the issue. Nosebagbear (talk) 22:12, 30 May 2021 (UTC)

@Nosebagbear: True. I myself am staring to lean towards Xeno’s idea, because it’s up to the bot when to move certain cases to the top. Perhaps we can program it like this: if a particular vandal edits x or more times after the report, or has made over x amount of disruptive edits in the past 24 hours, then the program moves to the top and tags it as priority. 🐍Helen🐍 22:17, 30 May 2021 (UTC)
Yeah, a separate sub-section that things that had been bumped to the top a certain number of times would be good. However, this (and, to be fair, any solution) is still contingent on someone being around to process it. Dire emergencies are occasionally dropped on AN/ANI, but I suspect most admins are like me and are mildly unhappy if the request is not a standout issue, lest it become the norm. Could also add a bot task to drop a notification onto ANI if something had been in the "uber-crit" box for, say, 3 hours? Nosebagbear (talk) 22:25, 30 May 2021 (UTC)
@Nosebagbear: That could be fixed by having the AIV bot figure out which admins have made edits in the past minute (so they'll probably still be online), then leaving an automated urgent help message on their talk page. Same criteria still apply-- vandal must have edited x or more times after the report, or has made over x amount reverted edits in the past 24 hours. If the admin doesn't respond to the request within, say, 10 minutes, the notice is removed from their talk page and AIV bot chooses the next admin that makes an edit. I know this sounds complicated, but it might be able to solve both problems that you've brought up. 🐍Helen🐍 17:56, 31 May 2021 (UTC)
So, you'd need this to be opt-in by admins, and I'm not sure how many you'd get given the problematic bit is 0200-0800 UTC. I also suspect that this system wouldn't be able to remove the notifications, and the wiki equivalent of deleted Discord pings are really annoying, because I have to go investigate the history every time to figure out what it was. Nosebagbear (talk) 18:21, 31 May 2021 (UTC)
 
A concept for a possible notification. Anarchyte (talk)
I really like this idea in theory, but I would hate having a dozen messages posted on my talk page each day. What would be perfect is if we added a way to push a notification (example on the right) when various pages (AIV, RFPP, etc) reach n outstanding reports. It would of course be opt-in and would only ping people that have made an edit in the last 30 or so minutes. Anarchyte (talk) 16:03, 7 June 2021 (UTC)
@Anarchyte: Without any software changes, there could be a mass ping template like Template:@MILHIST containing a bot-maintained list of currently active admins that have opted in to "attention to AIV" pings? —Kusma (talk) 16:10, 7 June 2021 (UTC)
@Kusma: Interesting. I'd hope that only a bot could ping the list though, or we'll get some very cranky admins. Anarchyte (talk) 16:14, 7 June 2021 (UTC)
@Enterprisey The #cvn-wp-en and #wikipedia-en-help channels already exist on IRC --Ahecht (TALK
PAGE
) 16:35, 7 June 2021 (UTC)

Article talk pages

Most article talk pages are ghost towns, filled only with assessment templates. A lot of article related discussion happens on user talk pages, wikiproject talk pages or in edit summaries instead of on the article talk page. In the rare case where people come and try to discuss actual article content on article talk pages, they tend to get ignored for years, as nobody notices their contribution to the talk page. Should we encourage people to try to find out who the actual page authors are and ping them when they try to write a new talk page post? The suggestion to do so would need to be in {{talk header}} and/or the editnotice to have any chance of being seen. Or should we try to encourage people to go to a more widely watched forum when they want to say something about an article? —Kusma (talk) 10:12, 29 May 2021 (UTC)

@Kusma: If the users never go to the talk page, then how, if I may ask, would a notice on the talk page help? 🐔 Chicdat  Bawk to me! 10:42, 29 May 2021 (UTC)
@Chicdat: I am trying to solve the problem that people who have managed to use the talk page are being ignored. The alternative is to change the talk page header to discourage people who have found it from using the talk page. —Kusma (talk) 11:12, 29 May 2021 (UTC)
@Kusma: Can you give me a few talk page examples with years-old, unnoticed posts? 🐔 Chicdat  Bawk to me! 11:15, 29 May 2021 (UTC)
@Chicdat: From my own contributions: Talk:Leningrad Cowboys Go America, Talk:Ursula von der Leyen (although this is an article with 1.2 million views per year, none of the talk page posts get actual discussions). Additionally, I have noticed that I don't go to article talk pages to discuss the article. I think I should have posted this at Talk:Lynching of John Carter, with a ping to Drmies and Uncle G. I posted at a user talk instead because I'm used to ignoring article talk pages. I think that is a bad habit, but it is a common habit. I am trying to propose we all use article talk pages more, and use pings to make sure the right people get notified of the discussion. —Kusma (talk) 12:05, 29 May 2021 (UTC)
@Kusma: Wow... you're right! I never noticed any of this before. The Talk: namespace really is quite inactive. Thank you for noticing this problem. 🐔 Chicdat  Bawk to me! 12:08, 29 May 2021 (UTC)

Ok, so TLDR: Article talk pages are dead. Should we bury them or revive them, and if we want to revive them, should we try to use pings to do so? —Kusma (talk) 13:07, 29 May 2021 (UTC)

First, yes - I agree it's a problem. Often if something I wrote sits more than a day or two then I'll check history and go to one of the recent editors to discuss. I like the idea of notifying the original author, but I'd include the editor with the most edits as well. Also, should it be a "ping" on user talk, or just an email that someone has posted to the article talk and it hasn't been responded to in x hours, or x days? — Ched (talk) 13:25, 29 May 2021 (UTC) edited: revived implied by my response. — Ched (talk) 13:27, 29 May 2021 (UTC)
To expand a bit on the why notify the most prolific editor as well: There are a TON of articles where the original author simply isn't editing wiki anymore. Even the most prolific editor of that article may be long gone. At that point, I guess you just look at page history and try to find someone still active. (which doesn't really solve the problem, I know.) — Ched (talk) 13:33, 29 May 2021 (UTC)
The question is whether we can/should have some automation for the task of "find the people most likely to be interested in a talk page query". Could be something like "from the article statistics, check who has been active in the last month, and then take the top two of those". Once I have to personally look through the history page, it is easier to just post on a user talk page. —Kusma (talk) 14:01, 29 May 2021 (UTC)
Ummm .. ok? "Yes"? - I'm agreeing with you Kusma. The "can we" - I don't know. Sorry, I'm not familiar with the actual coding of such things. The "should we" - yes, I think so. I wasn't trying to restate anything, I was just agreeing with you. Apologies for the confusion if I wasn't able to express myself more clearly. — Ched (talk) 14:33, 29 May 2021 (UTC)
Oh, I also thought I was agreeing with you, and just tried to clarify who should be notified. :) —Kusma (talk) 14:40, 29 May 2021 (UTC)
  • I suspect that editor participation in talk page discussions varies greatly from article to article. I could certainly point to articles that currently have very active talk pages, and lots of people watching and replying to new comments. Others (as you have noted) have no one watching them. Blueboar (talk) 15:29, 29 May 2021 (UTC)
  • Kusma has identified a genuine problem here. I don't think the solution is to use user talk pages, because that excludes other interested editors from any discussion. I think we need to get better at telling people who post about specific articles on user talk pages that that is the wrong place, and the discussion should take place on the article talk page, and at encouraging people to watchlist articles that they contribute significantly to (I don't know what the default of the "add pages and files I edit to my watchlist" preference is, but I certainly have it set). I admit that I tend to respond to queries on my user talk page rather than tell people to go to the article talk page. I'll try not to do so in future to encourage good practice, but I can't guarantee to be perfect. Phil Bridger (talk) 16:33, 29 May 2021 (UTC)
    I watchlist all articles I have significant contributions to, but I often don't notice edits to the talk page (there's too much other drama on my watchlist). The namespace filter helps a bit, but I would still prefer to get a ping whenever possible. —Kusma (talk) 17:18, 29 May 2021 (UTC)
    I disagree. I don't think there should be any "pinging", or other features that have been only introduced to Wikipedia because of some wish to emulate "social media" sites. Then there wouldn't be any expectation that people would use them. I recently culled my watchlist from many thousands to a few hundred. I suggest that you do the same so you are not flooded with updates. Phil Bridger (talk) 18:02, 29 May 2021 (UTC)
    I don't understand this comment about social media. Pings are much faster, easier and less disruptive for both sides than user talk page messages, and one of the best innovations I have seen here in a long time. —Kusma (talk) 18:29, 29 May 2021 (UTC)
    @Kusma An upcoming feature in MediaWiki will let you "subscribe" to talk page sections for getting ping-like notifications on new comments (phab:T263820 - in progress). There is also a planned feature for enabling notifications when new sections are added (phab:T263821 - not yet prioritised). The tracking ticket is phab:T273920. – SD0001 (talk) 19:13, 29 May 2021 (UTC)
    That's great, especially phab:T263821. If this gets implemented (and widely used), it would provide another approach to solve the problem I describe. Thank you for telling me about this! —Kusma (talk) 19:27, 29 May 2021 (UTC)
    hi @Kusma . @Whatamidoing (WMF) alerted me of this conversation. It sounds like we – the Editing Team and you all in this conversation – share an interest in exploring changes that could encourage people to discuss edits to a given article in places where, as @Phil Bridger noted above, increase the likelihood that other interested editors will see, and potentially participate in.
    With the above in mind, a couple of questions for you all:
    1. As @SD0001 mentioned, the Editing Team is actively working on new functionality to help people increase their awareness of activity in conversations they deem interesting by enabling them to elect to be notified when new comments are posted in the specific section(s) they subscribe to. Would you all be up for trying an early version of this feature when it's available in the next couple of weeks and sharing what you think of it?
    2. @Kusma, in this comment, you entered the idea of the interface doing more to suggest to people starting a new discussion topic on a talk page who they might consider pinging about said discussion topic. This intersects with functionality we've been thinking about and leads me to wonder: what do you see as the risks of assuming that people who have participated in a conversation on a particle article's talk page at some point in the past would be interested to know about a new conversation that is started on said article's talk page?
    And by the way, I'm Peter! I work as the product manager for the Editing Team. Right now, we're focused on the Talk pages project. PPelberg (WMF) (talk) 01:15, 11 June 2021 (UTC)
    Hi Peter, nice to meet you! It's a difficult question, as you need to make sure that people don't get so many pings that they start turning Echo off. For active talk pages (more than 10 people editing in the last 6 months, numbers pulled out of a hat), I'd oppose such a notification as I think they could quickly become overwhelming to the Echo system. For less active talk pages, the issue is whether any of the relevant people have even used the talk page. From my own articles, let's look at Story in Taipei. I may be the only person aware of this article with subject matter knowledge, but the talk page gives zero indication of that. Other conversations may be invisible in the wikitext. Consider Talk:A Voyage Round the World, which tells you that you could ask me or possibly my GA reviewer a question, but the wikitext doesn't show it. Or Talk:1773 Phipps expedition towards the North Pole. Sometimes the people who have used the talk page are people who ask questions about the article topic, and not people who can answer such questions. I'm very happy that devs are looking at the issue, but I don't see any super easy solutions, especially not easy technical ones; anything good would need to be combined with some social change. —Kusma (talk) 10:45, 11 June 2021 (UTC)
    The existence of such a feature leads people to believe that they can ignore everything that doesn't use it, with the consequence being the problem that you have identified. And I thought that my reference to social media was pretty self-explanatory. Phil Bridger (talk) 19:46, 29 May 2021 (UTC)

Watchlist folders

I've been wanting to bring this back up for some time but never got around to doing it until now. The watchlist is a very useful tool designed to help us users keep track of recent changes, but I find the current A-Z listing system a bit tedious. As I write this, I have 188 articles on my watchlist. I don't think that's such a huge number compared to other experienced users, but it's big to me, and I often find myself going through my list and asking myself, "Why is this article still here? It hasn't been vandalized for months. I don't need to keep an eye on it anymore." The problem is with a long list, I often miss a page or quickly get tired of checking it. With watchlist folders, users such as myself would be able to have an easier time locating articles.

I've searched through the archives and found three discussions about topics like this (1, 2, 3), but none of them really lifted off the runway. I want to keep my watchlist private (so no subpages), and bookmarking watchlisted pages seems redundant. The latest entry is from 2013, so maybe we've come far enough to make this possible. Perhaps watchlist folders could be part of our Preferences as a Beta feature. I'm not a very technical user, so I'm not sure if this is possible, but I'd like some feedback on the idea of watchlist folders. It'd certainly make my Wikilife easier if this is utilized, and the only reason I'm not watching more articles than I am now is because they'll just get lost in the long, long list. Regards. ResPM (T🔈 🎵C) 01:32, 2 June 2021 (UTC)

@ResolutionsPerMinute: it sounds like you want to have more than one watchlist for different things (in this case organized in to "folders" of some sort) correct? If so, this is phab:T3492 (now celebrating its 15th year of not being implemented!). — xaosflux Talk 01:49, 2 June 2021 (UTC)
@Xaosflux: This does look like what I'm talking about, but 15 years in the works without being implemented? Am I hearing that right? ResPM (T🔈 🎵C) 02:05, 2 June 2021 (UTC)
@ResolutionsPerMinute: yup - seems there are a couple of problems: (a) no one can decide on what exactly it should be, (b) no volunteer wants to take over actually managing it, including the software developement, to completion. — xaosflux Talk 02:10, 2 June 2021 (UTC)
@Xaosflux: Drat. Well, I'll take solace in the fact that its foundations exist. I wish I could help, but I'm a citer, not a developer. I would if I could. Thanks for filling me in. ResPM (T🔈 🎵C) 02:16, 2 June 2021 (UTC)
User:MusikAnimal/customWatchlists exists, but with watchlists being publicly visible. It's also possible to implement private watchlists in JavaScript (thus bypassing phab hurdles) by using mw.user.options, though no one seems to have done this yet. You could file a request at WP:US/R. – SD0001 (talk) 08:21, 4 June 2021 (UTC)
ResolutionsPerMinute, I'm desperately trying not to comment on how big your watchlist is (mine is 12,929) and I won't comment on the folder proposal but I want to make sure you are aware that there is a timed option now available. Click on the star, note the dropdown box and pick an option other than permanent. I work on a lot of copyright situations and I want the related article on my watchlist for a little while case they don't know to contact me but I don't want it on forever, so I used one of the temporary options. Believe it or not that's helped keep my watchlist from getting completely out of control. That option sounds like it might apply when you decide to watch an article that has had some vandalism. S Philbrick(Talk) 01:08, 11 June 2021 (UTC)
@Sphilbrick: I've known about the timed options since they were first implemented, and I've decided to utilize this option as a substitute for now. I'm not my ideal solution, but it works. ResPM (T🔈 🎵C) 01:17, 11 June 2021 (UTC)

Radical reform of DYK

I start from the premise that, from a reader-perspective, WP:DYK is fundamentally broken, in that very many of the entries on it are just plain boring. I'm thinking about starting a proposal to have us conduct a trial in which we eliminate all the eligibility requirements and instead allow facts from any page to be nominated but require !voting on all proposals such that only the ones judged most interesting get selected.

I anticipate that this would draw quite a bit of opposition just by virtue of being such a radical departure from the status quo. Per the idea lab's instructions, I'm not looking for supports/opposes here, but I would like to get a bit of a sense of just how likely this would be to get snowed and if there's any way I could set it up that might reduce the chances of that or more generally any big considerations I should have in mind. Cheers, {{u|Sdkb}}talk 07:24, 4 June 2021 (UTC)

The real question is what the goal of DYK is and should be. Is it supposed to be fun and exciting to read? Then why limit to new articles, the vast majority of which is about obscure topics? From a reader's short term perspective, why should it be on the Main Page at all?
What I like about DYK is that it encourages new articles to be of a decent standard. Which is useful for readers, and more so than reading the articles while they are on the Main Page.
Anyway, back to your idea: I don't really see voting as a viable way out unless there is massive participation. And DYK is already quite process heavy, so perhaps we would need to reduce complexity elsewhere. —Kusma (talk) 07:59, 4 June 2021 (UTC)
For me the purpose has always been to casually highlight some of our more obscure articles of non-FA quality for readers and editors alike by making use of a specific style form (DYK) which might spike their interest. I never understood why we limited it to new articles. —TheDJ (talkcontribs) 10:01, 4 June 2021 (UTC)
We don't quite limit to new articles: 5x expansions (so stub->real article) and freshly promoted Good Articles are also eligible. —Kusma (talk) 15:38, 4 June 2021 (UTC)
DYK in its current form definitely fills a role as an editor incentive. It's a little hard to balance that against readers losing out on more interesting hooks. Part of what appeals to me about a trial is that it'd allow us to be more clear-eyed about what the tradeoff is. If we see hooks getting significantly more pageviews, we'll know that's a possibility; same with the converse. {{u|Sdkb}}talk 15:39, 4 June 2021 (UTC)
I think we should consider clearly what we want. Should all hooks appeal to everyone? [I think that rules out too many subject areas.] Or is it OK that there are some articles about topics of limited appeal (Latvian mariachi band conventions, extinct amoebae, Peruvian radio stations) in the mix? We have some diversity criteria for prep builders that make sure we don't have eight buildings in New York or eight Catholic hymns or eight politicians on at the same time. If that isn't enough to find two or three interesting ones every day, maybe we need to recruit more nominators with more mainstream interests. —Kusma (talk) 15:51, 4 June 2021 (UTC)
I'm not sure I buy that there's that strong of an inverse relationship between obscurity and interestingness. Much of the appeal of Wikipedia as a place for entertainment comes precisely from the fact that it contains so much on obscure topics, and several of the top DYKs of all time are on quite obscure topics. {{u|Sdkb}}talk 16:40, 4 June 2021 (UTC)
I agree that many entries are boring. My reaction to most of the hooks is "so what?" The satisfaction of editors should be in creating something that is exciting for readers, rather than in the mere fact of "their" creation being on the main page. Many subjects are simply boring, so however well-written the articles they shouldn't qualify for this section. Phil Bridger (talk) 08:27, 4 June 2021 (UTC)
If I can tell from the hook that an article is about a boring topic like baseball or cricket, I just ignore it, no matter how interesting the hook sounds. But a lot of people will care and actually enjoy the very same article. I guess we need some variety. —Kusma (talk) 09:07, 4 June 2021 (UTC)
Kusma, almost all of my hooks have been about historic buildings in Scotland. A niche interest perhaps, but they mostly garner 5-10,000 views - I like to think that some of the readers must have found a few of them interesting... GirthSummit (blether) 16:06, 4 June 2021 (UTC)
The point is not whether the general topic interests a particular person, but whether the hook is interesting. For example yesterday's hooks included "... that concert pianist, composer, and opera librettist Leonard Liebling was the editor-in-chief of the Musical Courier from 1911 to 1945?" and "... that the principal of Big Tree Elementary read a book from a hot-air balloon to honor her students for having collectively read more than 2.5 million minutes in 2006?". Isn't it obvious which would be the more interesting hook to over 99% of our readership? That is true for me even though I happen to be more interested in reading about Leonard Liebling than Big Tree Elementary. Surely someone had to be editor of a published journal, so that hook is very definitely a "so what?". Phil Bridger (talk) 18:40, 4 June 2021 (UTC)
Yep, this. The fact that hooks like the Liebling one aren't being insta-rejected illustrates just how low our standards are. No other fun fact list on the internet would look themselves in the mirror after publishing that. And readers can seek out any other list they want. We can't compete when we're tying our hands behind our back by limiting our scope to new content, which is why I think we need to consider removing the eligibility requirements, even if it totally upends the way DYK has traditionally worked. {{u|Sdkb}}talk 19:20, 4 June 2021 (UTC)
There's two things I'd like to say here: (a) DYK currently has more submissions than people are happy about (many would prefer DYK to update only once in 24 hours, not once in 12) so widening eligibility may not be necessary and (b) why should we compete with fun fact lists elsewhere? What's in it for us if we try to do that? —Kusma (talk) 19:36, 4 June 2021 (UTC)
Well, as Wikipedians I think we want people to read Wikipedia, which includes our Main Page. And if so, that means we have to compete for their attention, which means competing against other places they might go instead to find trivia facts. In the sense I mean it, it's not really a choice, it's something we're already doing and have to do if we continue having DYK. {{u|Sdkb}}talk 21:27, 4 June 2021 (UTC)
It comes down to what are the primary goals people feel should be met by Did you know? Going by what others have said, learning trivia might not have consensus support. On a related note, I once engaged in discussion about having featured content on the main page with an editor who couldn't understand why I was raising goals from a reader's perspective. To them, the primary objective was to act as an editor incentive. I agree though that in addition to thinking about editor goals, we ought to consider the value to readers for items on the main page. isaacl (talk) 22:05, 4 June 2021 (UTC)
This. Infinity times THIS. A hook that combines "Music dude does music stuff" and "published journal has editor" is boring. If the editor of the music journal was an auto mechanic or if this noted musician edited a science fiction magazine, that would be interesting. --Khajidha (talk) 12:39, 7 June 2021 (UTC)
"The internet encyclopedia distinguishes itself from other web resources because it strives only to include information from reliable journalistic sources. That’s the value of the project: sticking to its own boring processes even if it means the encyclopedia version is less dramatic than the tabloids." - Stephen Harrison, Slate Gråbergs Gråa Sång (talk) 09:53, 4 June 2021 (UTC)
I take a similar view to Kusma above - what I like about DYK in its current form is that it celebrates content-creation. It encourages editors to write new articles up to a decent standard, and it gets others to come along and review, copy edit, tweak those articles. Newer editors can learn a lot by watching the changes experienced reviewers make in the short time their creation is in the preps and queues. I think that kind of encouragement can only be a good thing, both for editors, and for readers who benefit from the new, decent-quality articles. Whether the DYK hooks themselves are of much benefit to the reader is a slightly different question, but the difference between boring and fascinating is very subjective. I've clicked on a few DYKs and thought 'so what?', but they probably made other people think 'wow, really?' or 'cool - I didn't know that'. Tens of thousands of people click on our hooks every day - are those numbers declining, indicating that regular readers are losing interest in them because they find they're usually boring? I'm also slightly worried that by raising the bar on how interesting/surprising a hook has to be, we might be encouraging sensationalist writing, which we don't want. (Also: Change? Argh, I fear change!) GirthSummit (blether) 10:21, 4 June 2021 (UTC)
That's a very good point about encouraging sensationalist writing. {{u|Sdkb}}talk 15:40, 4 June 2021 (UTC)
  • If the chief complaint is the OP's personal interest in the hooks (they describe them as "boring"), then this is a non-issue for me. We have no way of knowing what excites the OP and why a particular DYK blurb may or may not bore them, but changing around the entire section just to entertain one person seems like an unwise thing to do. Furthermore, being "not boring" doesn't seem like a particular goal of DYK. The section is supposed to highlight the fact that Wikipedia is being constantly updated and expanded by directing readers to the newest such expansions. While I do believe that we should do our best to find the most interesting thing to say about an article once it is eligible for DYK, the blurb itself is of secondary concern to me. I am more interested that the article is new or recently expanded; the blurb is entirely incidental. If you can write an interesting hook, then go for it. But if the expanded text doesn't contain anything that someone finds interesting (again, where "interesting" can only be a personal preference, and that there is nothing objective or universal around what one person may or may not find interesting), then whatever, that should NOT be a disqualifying thing from appearing in DYK. If we reform DYK, in my mind, it's that we widen and allow more blurbs through, not less. --Jayron32 16:02, 4 June 2021 (UTC)
    99% of readers have absolutely no clue that DYK is limited to new/recently expanded articles, so I have to strongly disagree with you that it somehow highlights for them that Wikipedia is being expanded/updated. I also think the fact that DYK hooks have a severe interestingness issue is utterly self-evident; Goszei mentioned the other day on WP:Discord that it's something they've heard non-editors say. We can sometimes be so deep in the weeds that our sight becomes blinkered; let's try to rise above that. {{u|Sdkb}}talk 16:19, 4 June 2021 (UTC)
    Sdkb, wouldn't the answer to that be to have a short snippet of text on the main page explaining that? 'Did you know... a few interesting facts from recently written or expanded articles'. Or something like that. And FWIW, I just surveyed today's DYK, and found four hooks that I would want to click on because they look interesting, and four that I thought I wouldn't bother because they look boring. That's not a bad hit rate, in my view; I can't see how we could expect to make them all interesting to the same person, unless we were trying to cater to a very homogenous audience. GirthSummit (blether) 16:27, 4 June 2021 (UTC)
    Once upon a time, under "Did you know . . ." it used to say, "From Wikipedia's newest articles:". It would solve the problem that Sdkb points out above if we reinstated that or similar language, such as, "From Wikipedia's new and recently expanded articles:". ~ ONUnicorn(Talk|Contribs)problem solving 16:31, 4 June 2021 (UTC)
    What was the reasoning for removing it in the first place? IMO "newest content" might be more parsimonious, including both new articles and new content added to old ones. And my view of the boringness is about the same Girth Summit, right now there are only 3 hooks I don't personally find particularly interesting and even then none of them strike me as obviously tedious. —Nizolan (talk · c.) 18:39, 4 June 2021 (UTC)
    In 2015 someone mentioned that having that line directly below "Did you know..." before the hooks interrupted the flow of the sentence. They wanted to move it to the bottom. A discussion on the DYK talk page settled on replacing that clause with a link at the bottom that read, "Recently improved articles". I don't know when or why that link got removed, but at present it seems to have been replaced by the archive link. ~ ONUnicorn(Talk|Contribs)problem solving 22:48, 4 June 2021 (UTC)
    I think reinstating that line would definitely be an improvement over the status quo. I'm not sure it'd do to solve the interestingness problem we're considering here, but I'd love to see a separate discussion proposing to bring it back. {{u|Sdkb}}talk 23:54, 4 June 2021 (UTC)
    Absolutely we should restore the explanatory text, in fact I brought up this very issue at WT:DYK just a week or two ago, I believe it's essential that readers understand what the DYK section represents. Gatoclass (talk) 03:28, 8 June 2021 (UTC)
  • One other half-baked idea to make DYK more interesting would be to discard noms that are so boring that nobody has reviewed them in a month or that haven't been promoted to queue for a month. But I'm not sure how unhappy that would make people. —Kusma (talk) 16:04, 4 June 2021 (UTC)
    Kusma, I actually don't think that's a bad idea. If a nom has been hanging around for a month and nobody has reviewed it, it's probably because (a) the hook is boring, but nobody wants to be mean enough to say so, or (b) the article is long and boring, and nobody can be arsed to review it properly. Either way, it should probably be allowed to fall off the edge of the conveyor belt after a certain period, and a month feels like the right sort of ballpark to me. GirthSummit (blether) 18:18, 4 June 2021 (UTC)
    That is just a guess. I think it is equally likely that many reviewers look for DYKs that they think would be easiest/quickest to review just to get a QPQ credit for their own hook. MB 17:09, 7 June 2021 (UTC)
    We could also allow reviewed noms to time out, moving the pocket veto from reviewers to prep builders. —Kusma (talk) 17:40, 7 June 2021 (UTC)
  • I think we're slowly getting to a point where most "interesting" topics have already been written about. I'm not saying we're running out of topics at all - I'm basing this on new page/AfC patrolling. I haven't really noticed DYK getting "more boring" but I have noticed there's a lot of hooks which don't adequately describe why someone is notable. For instance, there's one on the front page right now: ... that Richard Hatherill survived a mutiny and a shipwreck, only to die from an illness at the age of 35? That's all good and fine, but who the hell is Richard Hatherill anyways? (It doesn't help that article has only one source which looks to paraphrase the three sentences I have access to.) I've noticed a couple of these recently, and I think this is a fixable problem. I'm not entirely sure DYK needs a re-think, but I'd be open to listening to a proposal to change it. SportingFlyer T·C 18:34, 4 June 2021 (UTC)
    I'm not sure that we're running out of interesting topics per se—Wikipedia's still very skewed to the kinds of things Wikipedia editors like writing about and there are huge gaps in coverage of certain fields with plenty of interesting things to say about them (my IRL research field of history of political thought is one of them), not to mention huge swathes of non-Western history. But I do agree that hooks ought to give some basic degree of detail introducing the things they're talking about where it's not otherwise obvious. That was one thing I looked out for in my brief spells reviewing at DYK in the past. —Nizolan (talk · c.) 18:49, 4 June 2021 (UTC)
    That's true - there's lots of notable topics we haven't touched yet. My argument's that the easy ones have been done. But this is all a tangent. SportingFlyer T·C 21:57, 4 June 2021 (UTC)
    I'm still constantly amazed how many things we don't have articles about yet (including reasonably easy ones where free sources in English exist). Anyway, I'm not sure that the availability of topics really affects DYK much. Look through the archives of Wikipedia:Recent additions. Was DYK more interesting 15 years ago, when not everything was written? —Kusma (talk) 22:51, 4 June 2021 (UTC)
  • The function, as per WP:DYK, is to showcase new or expanded articles. It is, as Jayron put it, supposed to highlight the fact that Wikipedia is being constantly updated and expanded by directing readers to the newest such expansions. It is also, practically speaking, a motivator for contributors. When I work with a newbie on a new article, the DYK process is always intimidating but when it finally gets to be the main page that feeling of "look at what I did!" is extremely powerful. For people who contribute because they want to have an impact on the world by contributing to a free knowledge resource, the spike in readership reassures them that yes, people are indeed reading what you're writing. It's a big deal to be on the main page.
    ...But, I think Sdkb has a good point that by framing it simply as "Did You Know," we're priming readers to expect a list of weird, wild, interesting, and exciting facts from across Wikipedia. Maybe adding a line contextualizing the section would help, but it seems at least worth talking about other options.
    What I think is not going to work well is to try to write rules which seek to accomplish the goals of DYK but attempt to qualify what is/isn't interesting. We risk marginalizing whole topic areas, and invite endless culturally relative debates over what is/isn't "interesting enough."
    In the end, I think a main page section dedicated to new/newly expanded content is important, but there are possibilities to clarify/contextualize or even, I don't know, splitting that main page real estate into two sections or something. — Rhododendrites talk \\ 22:05, 4 June 2021 (UTC)
  • Rhododendrites nailed it. I am ambivalent on the re-addition of a "from Wikipedia's recently created or expanded articles" tagline, but I am curious where the community stands. That tagline itself may be a good "hook" for the others, or even an interesting meta-"did you know". — Goszei (talk) 02:44, 7 June 2021 (UTC)
  • I think adding a from Wikipedia's recently created or expanded articles tagline to contextualise DYK is a fantastic solution with zero downside. firefly ( t · c ) 10:51, 7 June 2021 (UTC)
The last slot in DYK should always be "...that the above facts were taken from Wikipedia's recently created or expanded articles?", with "recently created or expanded articles" linking to the description of how to nominate an article for DYK. --Khajidha (talk) 12:36, 7 June 2021 (UTC)
@Firefly: Clarifying the scope of the DYK section is great. The downside is that a tagline (or Khajidha's idea of a final DYK) will take Main Space screen estate, which isn't as infinite as it may look. Going from 8 to 7 DYKs might be part of such a change. I guess it's worth it, but others might disagree. —Kusma (talk) 12:46, 7 June 2021 (UTC)
The only problem with "Main Space screen estate" is that we have chosen to give this one page a two-column layout unlike any other page on the site. This forces us to add and subtract items from various sections to maintain "balance". Which everyone complains about, but it seems that most of them find the obvious answer of "make the **** thing a single column and the problem goes away" even more objectionable. --Khajidha (talk) 13:07, 7 June 2021 (UTC)
@Kusma: I've had a go at including the explanation without affecting anything else. It's a crude first-approximation, so please only take it as proof that it's possible and nothing more! :) firefly ( t · c ) 13:15, 7 June 2021 (UTC)
Thanks @Firefly! The small font size might not fly for accessibility reasons, but perhaps we can merge this with some of the links. Here's a variation that integrates the links into what @Khajidha said:
... that these facts are from recently created or expanded articles, and that you can start or nominate your own?
Or something like that? —Kusma (talk) 13:36, 7 June 2021 (UTC)
@Kusma: That's far better than my attempt from an accessibility standpoint, although we may get pushback on the grounds that it breaks consistency with other sections of the Main Page. I've added your idea into my sandbox so we can all see what it could look like in practice. firefly ( t · c ) 13:44, 7 June 2021 (UTC)
Might still need some fine tuning (tried an alternative, not yet convinced), but it should be possible to get this to work. —Kusma (talk) 16:31, 7 June 2021 (UTC)
FWIW Kusma, feel free to use the sandbox I linked to experiment if you wish. firefly ( t · c ) 12:19, 8 June 2021 (UTC)
  • Oppose It's the premise that is broken. DYK is not boring; it's one of the most interesting sections on the main page. Consider the alternatives:
  1. FA – this usually goes on at length about a niche topic such as Interstate 69 in Michigan – today's conversation stopper. DYK is better because it is more varied, briefer and more focussed on being hooky.
  2. ITN – this is usually quite stale with up to a week or more between new blurbs, whereas DYK is much more productive, running 8–16 new items every day. And the ITN blurbs focus on a narrow slice of what's actually in the news and seem utterly obsessed by death
  3. OTD – a tired format with the same stuff recycling year after year
  4. FL – the poor man's FA
  5. FP – the pictures are often quite good but the attached blurbs are usually dire
And then there's all the main page boilerplate – dozens of links and slogans which may be useful but are hardly exciting
But, in any case, Wikipedia is an encyclopedia not a comedy, drama or thriller and so our readership will be expecting the content to have a comparatively educational tone – "worthy but dull". If you find it boring then you've come to the wrong place.
Andrew🐉(talk) 16:13, 7 June 2021 (UTC)
@Andrew Davidson, per both my initial post and the idea lab rules, please do not !vote here. Regarding your comment, the other sections of the main page each have their own issues, most of which have been discussed at length in other places. They are beyond the scope of this discussion, though; let's try to stay somewhat focused. {{u|Sdkb}}talk 18:09, 7 June 2021 (UTC)
So, the OP doesn't want !votes on their proposal to introduce !votes to DYK. WP:SAUCE!
And the other main sections are relevant because they demonstrate what happens when you have a peanut gallery of !voters. ITN is quite broken because it works in that way and so most nominations get shot down. The only part of ITN that is as productive as DYK is RD and that's because it was reformed to eliminate opinionated !votes about the worthiness of the subjects.
Andrew🐉(talk) 08:38, 9 June 2021 (UTC)
No idea what you're talking about. The entire point of the idea lab is discuss ideas, not vote on them, how much more explanation do you need? Aza24 (talk) 22:27, 9 June 2021 (UTC)
I agree with all the points made by Andrew Davidson. DYK is for new articles that are accessible to read, which makes it better than most content on the front page. "Interesting hooks" are totlly subjective, and if you don't like a couple of hooks, don't read them. It seems like Sdkb is trying to ignore all the valid points made above by wikilawyering over the use of the word oppose, instead of actually replying to any of the comparison to much worse front page content. I cannot for example remeeber the last time I ever read a FA/FL on front page, as they're too long and too niche topics. On the other hand, DYK reviewers are encouraged to make hooks accessible to a broad audience, which mostly they do. Joseph2302 (talk) 08:42, 10 June 2021 (UTC)

I don't think I like this proposal. DYK is a place that motivates editors, particularly new ones that want to have their work seen by more readers. If hooks are boring, I would like the reviewer or promoter to suggest ALT hooks. I am also in favour of increasing the 1500 minimum word count for DYK articles, as this will generate more text and possibly provide better hooks. I am concerned that "Allowing facts from any page" to be nominated will cause DYK to highlight popular articles instead of a diverse set of topics, as those are the articles that are frequented the most by readers and editors. If this idea was implemented, I would like a new rule set to be established for the trial run so that articles with tags, source problems, or have already been featured on DYK within the past few years are not eligible. I like the above conversation to add a sentence about what DYK is, and encourage more editors to get involved. Z1720 (talk) 00:00, 8 June 2021 (UTC)

  • Comment As the creator of the Leonard Liebling article, I find it a little disheartening to read that others think my hook is so boring that it's the prototypical example of what's wrong about DYK. Personally I thought it