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 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
post, watch, search
Discuss existing and proposed policies
Preferences-system.svg
post, watch, search
Discuss technical issues about Wikipedia
Dialog-information on.svg
post, watch, search
Discuss new proposals that are not policy-related
Tools-hammer.svg
post, watch, search
Incubate new ideas before formally proposing them
Wikimedia-logo black.svg
post, watch, search
Discuss issues involving the Wikimedia Foundation
Help-browser.svg
post, watch, search
Post messages that do not fit into any other category
Other help and discussion locations
I want... Where to go
...help using or ing 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 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[]

RfC: Updating BLOCKEVIDENCE[]

The following discussion is an archived record of a request for comment. Please do not modify it. No further s should be made to this discussion. A summary of the conclusions reached follows.
While this discussion could've been closed earlier due to a clear consensus against the change, the debate among ors was still ongoing. Now that it's slowed down, it seems a good time to take a summary of what was discussed (and it seems some others agree).

This proposal began after an update by the ArbCom called "Special Circumstances Blocks", which specified that administrators were to "contact the appropriate group rather than issue a block" depending on the circumstances. This led to a discussion in which users were divided on the wording of WP:BLOCKEVIDENCE, specifically, what "information to which not all administrators have access" meant.

An initial wave of supporters noted that allowing administrators to block users based on off-wiki evidence (to be emailed to ArbCom afterward and to any admin that requested it) would be helpful in fighting UPE and sockmasters, while at the same time offloading some work from CUs. Some noted that these types of blocks are already commonplace and, as such, a good reason to rewrite the policy to reflect current practices.

While some opposing saw this as a breach of WP:OUTING, the discussion eventually drifted away from this topic after explanation that using off-wiki evidence of misconduct is not prohibited, but should be sent to the appropriate functionary queue, where they can act on that information. But, even ignoring those !votes that were solely based on this reasoning, it is quite clear that a big part of the community feels uncomfortable with administrators issuing blocks that depend on off-wiki info, which should be done by functionaries.

Editors made it clear that, while administrators are trusted members of the community, they haven't signed the confidentiality agreement and shouldn't be the ones making blocking decisions based on that kind of information. Editors rejected the proposed rewording of the blocking policy presented here saying administrators should be able to justify their blocks using on-wiki evidence, even if it includes aspects only accessible by other administrators (eg., revdel'ed s and deleted pages). Any block that depends on off-wiki evidence should be issued by the proper group of functionaries. This falls in line with the guidance published by ArbCom.

Considering this happened due to differing interpretations of WP:BLOCKEVIDENCE, the following paragraph should be amended to clarify that blocks that can't be justified without the use of off-wiki evidence must go through the appropriate group of functionaries (CU, OS or ArbCom): "If a user needs to be blocked based on information that is not available to all administrators, that information should be sent to the Arbitration Committee, a checkuser or an oversighter for action. These ors are qualified to handle non-public evidence, and they operate under strict controls. The community has rejected the idea of individual administrators acting on evidence that cannot be peer-reviewed." (no specific wording was suggested) (non-admin closure) Isabelle 🏳‍🌈 01:33, 23 September 2022 (UTC)Reply[reply]



Should WP:BLOCKEVIDENCE be updated to explicitly allow administrators to consider off-wiki evidence when making blocks for on-wiki misconduct, as long as that evidence will be made available to all uninvolved administrators and recorded with the Arbitration Committee? 21:52, 6 September 2022 (UTC)

It is well-established that blocks for off-wiki conduct fall outside of individual administrators' blocking authority. However, the situation is less clear when off-wiki evidence contributes to a decision to block a user for on-wiki misconduct: for instance, a user who denies a COI on-wiki, while a LinkedIn profile tells a different story. Currently, WP:BLOCKEVIDENCE, WP:ADMIN § Special situations, de facto community practice, and ArbCom's recent statement on Special Circumstances blocks provide guidance to administrators in inconsistent ways, open to varying interpretations. This disagreement recently received significant attention at the arbitration noticeboard talk page. The proposers of this RfC disagree on the current meaning of BLOCKEVIDENCE, but agree that it is both ambiguous and out-of-date with respect to current practices.

This proposed change to BLOCKEVIDENCE would explicitly allow administrators to block based on off-wiki evidence as long as that evidence will be made available to any uninvolved administrator upon request. In order to ensure the retention of evidence supporting these blocks, administrators would be required to record the evidence supporting these blocks with the Arbitration Committee when making these blocks. The intent of this proposal is to allow administrators to continue to make blocks for spam and undisclosed paid ing, while establishing safeguards for evidence retention.

Proposed new text

If an administrator blocks a user based on information to which not all administrators have access, that information should be submitted to the Arbitration Committee before the block to ensure that the information is recorded in the event of any appeal.[1] Evidence supporting these blocks must be made privately available by the blocking administrator to any uninvolved administrator upon request (for the purpose of peer review or appeal). In the event that the blocking administrator is unavailable to transmit the evidence, the Arbitration Committee will do so. These blocks typically should not be marked as "appealable only to ArbCom" and are reviewable by any uninvolved administrator.

If the blocking administrator is unwilling to share this evidence with any uninvolved administrator upon request, the administrator may not issue a block. The community has rejected the idea of individual administrators acting on evidence that cannot be peer-reviewed. Instead, the administrator should request action from the Arbitration Committee, or from the Checkuser or Oversight team, as appropriate. These ors are qualified to handle non-public evidence, and they operate under strict controls.

A separate set of requirements apply to administrators holding checkuser or oversight privileges. Those administrators may block users based on non-public information accessible only to checkusers and oversighters without emailing the Arbitration Committee. This may include information revealed through the CheckUser tool, s that have been suppressed ("oversighted"), and information recorded in the checkuser-en-wp or paid-en-wp VRTS queues. These blocks are considered to be Checkuser or Oversight actions, as appropriate, although the technical action to issue a block is an administrative one. All such blocks are subject to direct review by the Arbitration Committee.

Unified diff

If a user needs to be blocked an administrator blocks a user based on information that will not be made available to all administrators to which not all administrators have access, that information should be sent to the Arbitration Committee or a checkuser or oversighter for action. These ors are qualified to handle non-public evidence, and they operate under strict controls. submitted to the Arbitration Committee before the block to ensure that the information is recorded in the event of any appeal.[1] Evidence supporting these blocks must be made privately available by the blocking administrator to any uninvolved administrator upon request (for the purpose of peer review or appeal). In the event that the blocking administrator is unavailable to transmit the evidence, the Arbitration Committee will do so. These blocks typically should not be marked as "appealable only to ArbCom" and are reviewable by any uninvolved administrator.

If the blocking administrator is unwilling to share this evidence with any uninvolved administrator upon request, the administrator may not issue a block. The community has rejected the idea of individual administrators acting on evidence that cannot be peer-reviewed. Instead, the administrator should request action from the Arbitration Committee, or from the Checkuser or Oversight team, as appropriate. These ors are qualified to handle non-public evidence, and they operate under strict controls.

An exception is made for A separate set of requirements apply to administrators holding checkuser or oversight privileges; such . Those administrators may block users based on non-public information accessible only to Checkusers and Oversighters without emailing the Arbitration Committee. This may include information revealed through the checkuser CheckUser tool, or on s that have been suppressed ("oversighted") and are inaccessible to administrators , and information recorded in the checkuser-en-wp or paid-en-wp VRTS queues. As such, an administrative action is generally viewed to be made in the user's capacity as an oversighter or checkuser, although the action itself is an administrative one. These blocks are considered to be checkuser or Oversight actions, as appropriate, although the technical action to issue a block is an administrative one. All such blocks are subject to direct review by the Arbitration Committee.

Side-by-side diff
If a user needs to be blocked based on information that will not be made available to all administrators, that information should be sent to the [[WP:ARB|Arbitration Committee]] or a [[Wikipedia:Checkuser|checkuser]] or [[WP:SIGHT|oversighter]] for action. These ors are qualified to handle non-public evidence, and they operate under strict controls. The community has rejected the idea of individual administrators acting on evidence that cannot be peer-reviewed.<div class="paragraphbreak" style="margin-top:0.5em"></div> An exception is made for administrators holding [[Wikipedia:Checkuser|Checkuser]] or [[Wikipedia:Oversight|Oversight]] privileges; such administrators may block users based on non-public information revealed through the checkuser tool, or on s that have been suppressed ("oversighted") and are inaccessible to administrators. As such, an administrative action is generally viewed to be made in the user's capacity as an oversighter or checkuser, although the action itself is an administrative one. All such blocks are subject to direct review by the [[Wikipedia:Arbitration Committee|Arbitration Committee]].
+
If an administrator blocks a user based on information to which not all administrators have access, that information should be submitted to the [[WP:Arbitration Committee|Arbitration Committee]] before the block to ensure that the information is recorded in the event of any appeal. Evidence supporting these blocks must be made privately available by the blocking administrator to any uninvolved administrator upon request (for the purpose of peer review or appeal). In the event that the blocking administrator is unavailable to transmit the evidence, the Arbitration Committee will do so. These blocks [[Wikipedia:Arbitration_Committee/Noticeboard/Archive_13#Special_Circumstances_Blocks|typically should <em >not</em> be marked]] as "appealable only to ArbCom" and are reviewable by any uninvolved administrator.

If the blocking administrator is unwilling to share this evidence with any uninvolved administrator upon request, the administrator may not issue a block. The community has rejected the idea of individual administrators acting on evidence that cannot be peer-reviewed. Instead, the administrator should request action from the Arbitration Committee, or from the [[WP:Checkuser|Checkuser]] or [[WP:Oversight|Oversight]] team, [[Wikipedia:Arbitration_Committee/Noticeboard/Archive_13#Special_Circumstances_Blocks|as appropriate]]. These ors are qualified to handle non-public evidence, and they operate under strict controls.

A separate set of requirements apply to administrators holding checkuser or oversight privileges. Those administrators may block users based on non-public information accessible only to checkusers and oversighters without emailing the Arbitration Committee. This may include information revealed through the CheckUser tool, s that have been suppressed ("oversighted"), and information recorded in the [[Wikipedia:Arbitration_Committee/Noticeboard/Archive_13#Special_Circumstances_Blocks|checkuser-en-wp or paid-en-wp VRTS queues]]. These blocks are considered to be Checkuser or Oversight actions, as appropriate, although the technical action to issue a block is an administrative one. All such blocks are subject to direct review by the Arbitration Committee.

References

  1. ^ a b c Administrators are also encouraged to do the same where their interpretation of on-wiki evidence might not be obvious to an administrator reviewing an unblock request—for instance, a sockpuppetry block justified by subtle behavioral "tells".

If this proposal is successful, the change would be communicated to all administrators via MassMessage, as has been done with past changes to blocking procedure. Wikipedia:Appealing a block would also be updated to reflect this change to blocking policy. Finally, the Arbitration Committee would be recommended to establish a new unmonitored VRTS queue to receive evidence supporting these blocks (distinct from its handling of "appeal only to ArbCom" blocks), with ticket numbers that can be included in the block log.

Co-signed 21:52, 6 September 2022 (UTC):
-- Tamzin[cetacean needed] (she|they|xe)
KevinL (aka L235 · t · c)

Discussion (BLOCKEVIDENCE)[]

  • Support as proposer. I thank L235 for suggesting creating this RfC, in light of our disagreement about the policy's current meaning, one that sees multiple experienced administrators on both sides. It's clear to me that BLOCKEVIDENCE is not in keeping with current practices, and creates a dangerous dead letter of essentially unenforced wording amidst a very important policy. As a new administrator, I have already run into scenarios several times that fall into this ambiguity. To highlight a few examples:
    1. A user recreated an article on a non-notable person, which had been deleted several times in the past. Past versions appeared autobiographical, but the new account seemed to be someone different. I Googled the username and found that someone with that exact name worked in marketing for a company affiliated with the article's subject. I blocked for meatpuppetry, directing other admins to contact me for evidence.
    2. A user was reported to SPI for AfD !votestacking. At issue was whether they knew another user off-wiki, so I Googled their username and found a LinkedIn profile where someone with that name claims to be a Wikipedia or and claims to work for a company that the user had ed about extensively. I asked the user if they were affiliated with the company. They denied it, and I blocked for UPE, directing other admins to contact me for evidence.
    3. The other day, GoodPhone2022 (talk · contribs) emailed me, (mostly-)[1]confessing to being a sock of AlfredoEditor. In this case, given the username similarity to past sock GoodPhone2020 (talk · contribs), I was comfortable blocking, but if not for that, I would be in an area of policy ambiguity.
  • In each of these cases, ArbCom's current prescription is that I would have had to forward the email to a CU-staffed queue, in two out of three cases for a routine sockpuppet. In all three cases, the reason for blocking is on-wiki misconduct, most of the evidence is on-wiki, and the off-wiki evidence was straightforward.[2]
    We have four conflicting rulesets here: BLOCKEVIDENCE, if interpreted to forbid all blocks based on private evidence, forbids these three blocks, even the routine sockblock. If interpreted to forbid only blocks based on evidence that cannot be shared off-wiki with other admins, it allows this (since under WP:OUTING admins can discuss such evidence by email). ADMIN § Special situations, meanwhile, complicates this, in that it could be interpreted to allow these blocks but require making them "appeal only to ArbCom". ArbCom's recent statement, however, forbids that designation for the most part, and, depending on how literally one sentence is taken,[3] forbids making the block at all. And finally, de facto current practice is that administrators do make such blocks and either explicitly or implicitly direct other admins to contact them off-wiki for evidence.
    Since ArbCom has sent no admin-wide bulletin, I suspect that the upshot of ArbCom's recent statement is that it will be ignored and business will continue as normal until someday it doesn't and we get some drama-filled desysop or admonishment that pits admins saying "But we all do this!" against arbs saying "But we said you can't!" I don't like that outcome, and I don't like the status quo of a policy that is both ambiguous and ignored. Critically, even if BLOCKEVIDENCE does allow these blocks, we have the problem that it's not a very good system. Admins resign or get for-caused or die. Admins forget why they blocked someone. LinkedIn profiles get taken down, Upwork contracts get closed. By both formalizing the permissibility of blocks like these and creating a system for admins to store evidence (mandatory when off-wiki evidence is involved, optional but encouraged for complex interpretation of on-wiki evidence), we solve that problem while clarifying the situations under which admins can and can't make blocks like these. -- Tamzin[cetacean needed] (she|they|xe) 21:57, 6 September 2022 (UTC)Reply[reply]
    @Tamzin: I would be very surprised if it is "current practice" for admins to make blocks based on nonpublic evidence without having signed the confidentiality agreement for nonpublic information. Do you have any examples of anyone other than yourself doing it? Historically as a project we are very careful about private information and, while I have no doubt that your different interpretation of WP:BLOCKEVIDENCE was reached in good faith, in the subsequent discussion on ARBN, the majority of admins, including functionaries with years of experience in actually handling these kind of blocks within the established processes, agreed with ArbCom's interpretation. – Joe (talk) 09:17, 7 September 2022 (UTC)Reply[reply]
    @Joe Roe: Just sent a brief email. Best, KevinL (aka L235 · t · c) 15:52, 7 September 2022 (UTC)Reply[reply]

References

  1. ^ You deleted my sock's subpage, User:GoodPhone2020/List of islands by area [...] I'm not a sockpuppet
  2. ^ In the second case, the unblock-reviewing admin didn't even consult me for evidence, but found it themself.
  3. ^ Administrators should contact the appropriate group rather than issue a block covered above.
  • Support as proposer. In my view, policy currently prohibits many blocks that are frequently made by administrators (e.g., low-level UPE blocks based on Upwork profiles). But those blocks seem to have become accepted by the community and the administrative corps. This proposal catches policy up to reality while adding a safeguard: the evidence will be recorded in case it’s needed in the future. I therefore support the change.
    Also, because there’s disagreement about what policy currently requires, I’d ask any folks who oppose this proposal to indicate what they think the current policy says. (Are blocks based on info with an “email me for the evidence” note permissible? Does that count as information that will [] be made available to all administrators?) With thanks to Tamzin and everyone who discussed and ideated on this, KevinL (aka L235 · t · c) 21:58, 6 September 2022 (UTC)Reply[reply]
  • Support - currently we are caught between the former status quo, with the risk of block evidence being lost putting appellants and unblocking admins in an unenviable position and the Arbcom created new rules that simply would put too many tasks on CU-only where they don't need to be. This proposal offers a solution to that, especially in the "low-hanging fruit" part of off-wiki evidence. Tamzin's reasoning is detailed and the examples are a good set of those frequently seen. Nosebagbear (talk) 22:04, 6 September 2022 (UTC)Reply[reply]
  • Support. Seems pretty straightforward to me. –MJLTalk 22:24, 6 September 2022 (UTC)Reply[reply]
  • Support. We shouldn't prohibit good blocks just because policy doesn't allow the evidence to go public. I do have one quibble with the proposed text. It says the info will be recorded by arbcom and can be retrieved there by admins, but it also says the blocking admin MUST supply the info to other admins on request. That implies all admins using this policy must retain a permanent duplicate record of the info. That seems pointless. I'd drop the unreliable requirement for admins to supply the evidence. Alsee (talk) 22:26, 6 September 2022 (UTC)Reply[reply]
  • Support, with thanks to both proposers. The problem of UPE is a significant one, and I'm pretty sure there is community consensus that we need to allow some degree of "research" about users suspected of UPE or even just COI, regardless of the WP:HARASS prohibition of "opposition research". This proposal makes it clear how admins can be effective while still protecting private evidence, and solves problems with forgotten evidence. --Tryptofish (talk) 22:30, 6 September 2022 (UTC)Reply[reply]
    @Tryptofish: We already allow this kind of research, by anyone, just with the caveat that only functionaries can make a block based on it. The evidence for these blocks is then logged in one of various VRT queues or private wikis (depending on the kind of block). For example, if you find evidence that a user is making undisclosed paid s, you can email it to paid-en-wp@wikimedia.org for recording and action. – Joe (talk) 09:02, 7 September 2022 (UTC)Reply[reply]
    I think it's pretty obvious from subsequent discussion below, that the community is divided over whether or not that is, or should be, true. --Tryptofish (talk) 18:35, 7 September 2022 (UTC)Reply[reply]
    As I read comments by other ors, I want to add to my original comment. As much as I consider doxxing to be appalling, I think there are shades of gray when it comes to people who are openly engaging offsite in for-profit abuse of the community's trust. Deceiving other ors by hiding one's actual agenda in order to slant our content to serve a corporate or political purpose is not OK. And anyone who thinks it's not happening on a large and growing scale is kidding themselves. Wikipedia is a very attractive target for self-promotion. That's nowhere near to regular good-faith contributors who want to be able to anonymously (like me). Our policies should not be suicide pacts, and we should not make our belief in the right to anonymity into a cultish Thing-That-May-Not-Be-Questioned. --Tryptofish (talk) 23:11, 7 September 2022 (UTC)Reply[reply]
  • I support the idea behind this proposal. However, I'm unsure about the following sentence: "In the event that the blocking administrator is unavailable to transmit the evidence, the Arbitration Committee will do so." Can we really require them to do so? This seems to convert ArbCom into a marketplace for off-wiki outing. I guess "will do so if possible" or "may do so" would be more precise. ~ ToBeFree (talk) 22:39, 6 September 2022 (UTC)Reply[reply]
    I'm definitely OK with "if possible" or "may do so" if people feel very strongly, but my first thought is that it seems like this is an edge case that doesn't need to be spelled out – presumably we can trust ArbCom not to engage in impermissible OUTING, as they handle all sorts of private information normally. Best, KevinL (aka L235 · t · c) 22:52, 6 September 2022 (UTC)Reply[reply]
    Well, as mentioned in Tamzin's support comment, the harassment policy does contain an outing exception specifically for emailing, so it's less of a concern than it looked to me first anyway. Formalizing the existing way for all administrators to access the evidence behind such blocks is a positive development.
    I have reviewed paid-ing blocks based on admin-only evidence (and requests for them) a few times and found it difficult to come to a clear conclusion whether the blocked user was actually lying into our faces or genuinely pointing out a case of mistaken identity. I guess those active at WP:SPI got used to this feeling. Transparency, as far as possible, increases the number of eyes that need to make the same mistake for an incorrect block to happen/stay. I can't really complain about that. ~ ToBeFree (talk) 23:14, 6 September 2022 (UTC)Reply[reply]
  • Support. This is a reasonable way out of the current conflicting-norms problem. Unlike ToBeFree, I have no issue with the fact that the en.WP community can require its own ArbCom to do something. ArbCom answers to us, not the other way around.  — SMcCandlish ¢ 😼  23:11, 6 September 2022 (UTC)Reply[reply]
    (Now that might be oversimplified as ArbCom consists of volunteers... somehow... within the boundaries of WP:ADMINACCT and similar principles. And, although probably not applicable to the type of evidence we're discussing, there are of course even additional restrictions on what we can require them to do, described in their NDAs.) ~ ToBeFree (talk) 23:20, 6 September 2022 (UTC) Reply[reply]
    I agree the community can compel arbcom to do something through Arbpol. This is not that. However if this passes I will absolutely be in favor of setting up an email queue for things to be sent to. Best, Barkeep49 (talk) 06:14, 7 September 2022 (UTC)Reply[reply]
  • Support This is a good solution for a difficult problem and is necessary to reduce disruption. Johnuniq (talk) 23:26, 6 September 2022 (UTC)Reply[reply]
  • Support makes sense and clears up an ambiguity/conflict in policies/procedures/best practices. I don't see any reason not to make this change. --TheSandDoctor Talk 23:46, 6 September 2022 (UTC)Reply[reply]
  • Absolute and unequivocal Oppose. While clearly a good-faith proposal, I think this may be the single worst idea I've seen advanced to the community in quite some time, full of ill-considered potential knock-on effects that aren't even contemplated within the proposition, let alone addressed. With due respect to Tamzin, I think they have seriously misinterpreted both the wording of relevant policy and the established community consensus on which it is based.
    For example, the first scenario that they use as evidence for why this system is needed (in their support !vote)... I'm sorry Tamzin, but that's just not the kind of investigation I want you to be undertaking under any circumstances, nor do I think it is properly within your remit as an admin: in fact, I think it is a brightline violation of the wording of WP:OUTING. The exception contemplated in that policy is that a user might utilize information relating to a generic posting by a company seeking COI ors--not the notion that users (admins included) would be tracking down potentially doxxing information regarding specific ors, just so long as they have socking concerns to justify it. That clearly goes against the spirit of the policy and longstanding community consensus.
    I suppose it's true that nothing currently prohibits any community member from acting as a non-sanctioned investigator and submitting such information to VRTS--whom I hope routinely ignore it in the (probable majority) of problematic cases and focus on on-project information and technical assets. But I am deeply concerned about how enabled similarly-thinking admins as Tamzin (again, no personal offense intended, but I feel strongly about this issue) might feel if they perceive a further institutional greenlight on such activities. And note that the outing policy would also need to be rewritten here in order to facilitate this new system, since it currently expressly forbids some of the activity that would be involved, and expresses a very different philosophy with how off-wiki information (and linking it to on-project accounts) is meant to be handled.
    Whats more, in order to facilitate this new and highly problematic role for admins, there is to now be a new log of sorts containing any amount of potentially sensitive personal information on any number of community members (and indeed, where the admin-inspector's instincts are off, personal information of people who may have nothing to do with the project whatsoever), creating one of the greatest systematic doxing risks generated by the project? All it would take is one bad actor getting access to that system, through legitimate or illegitimate means to create a world of harm. Nor should we expect any potential disruption to be limited to just a handful of overzealous admins, since this new system would encourage anyone of such a mindset, and on good terms with an admin who views their authority in this new area as broad, to seek out potentially damning information on other ors to relay it to said admins.
    I'm sorry, but our current policies with regard to the collection, dissemination, and storing of off-project personal information (which may or may not relate to community members) did not evolve in a vacuum: they are meant to place a premium on the protection of anonymity on a project that presents a massive risk of real world harm for many of its members. This proposal would be a significant erosion of that framework, which would invite all manner of potential problems. Far from being a "constitutional overreach", the rules promulgated by ArbCom (which have in any event been status quo for a long time), are, by comparison, much more in conformance with the traditional principles and concerns regarding privacy on this project, and it is (in my opinion) this proposal which would violate existing community norms and important checks and balances.
    In short, very much a case of the cure being much worse than the disease it proposes to address (and which is already effectively controlled by an existing treatment, if one that moves a little slower. I'm sorry, but we cannot, in the name of combating paid ing, vitiate some of our most important privacy policies. It just is not remotely a balanced reaction to that situation. SnowRise let's rap 01:50, 7 September 2022 (UTC)Reply[reply]
    The outing policy, a section of the harassment policy, does not prevent administrators (or anyone for that matter) from investigating users' off-wiki activities, and explicitly notes Nothing in this policy prohibits the emailing of personal information about ors to individual administrators, functionaries, or arbitrators, or to the Wikimedia Foundation, when doing so is necessary to report violations of confidentiality-sensitive policies. If you think it ought to prohibit these things, you should propose a change to that policy. But the status quo is that such investigations and discussions are allowed; the question we're discussing here is who should block based on them, and how. -- Tamzin[cetacean needed] (she|they|xe) 03:02, 7 September 2022 (UTC)Reply[reply]
    I find that quoting of the policy incredibly selective, considering the very next two sentences read: "Only the minimum information necessary should be conveyed and the minimum number of people contacted. Editors are warned, however, that the community has rejected the idea that ors should "investigate" each other."(emphasis added). The expansion of an administrator's permitted activities that you are proposing (and at least one of the examples of conduct which you seem to already engage in) are clearly not in keeping with that principle. You are just fundamentally wrong about what the kind of behavior the community has long proscribed with that rule: no, neither admins nor rank-and-file community members are meant to be tracking eachother off-project--that is quite simply a very foolish (and for some, expressly dangerous) notion, and the outing policy is the first and perhaps most fundamental layer in a firewall that exists to protect the privacy (and in many cases even the safety) of our volunteers.
    There is already a system in place for users (admins included) to act on off-project information suggestive of on-project disruption: WP:VRTS. That system seems to aggrieve you because you perceive it as ArbCom somehow dictating the purview of administrators, but there's clearly a lot of important policy rationale for why the system is set up like that in the first place: that information is simply not meant to become part of the record on contributors here, even in cases of disruption. Nor are our community members meant to be openly policing eachother in the manner you would have use normalize.
    What's more, you would have us log all the information thus collected in some fashion broadly available to at least ors of a certain class of permissions--and all that would need to happen in order for such doxxing data to be collected and retained for a user is that any one of our admins thought that maybe it was possible that they were socking... I'm sorry, but do you really not see all the ways that any such system would be vulnerable to exploitation or penetration, deeply undermining our traditional commitment to prioritizing the privacy and safety of our volunteers? I'm afraid that neither allowing for slightly speedier responses to a small subset of COI cases, nor giving a particularly defensive segment of the administrative corps an opportunity to thumb their nose at ArbCom are sufficiently good reasons to abrogate the principle of user anonymity so significantly. SnowRise let's rap 06:15, 7 September 2022 (UTC)Reply[reply]
    ( conflict)There's a clause in the outing policy that Editors are warned, however, that the community has rejected the idea that ors should "investigate" each other. My reading of the proposal is that this policy is complimentary with WP:OUTING and that both the public meaning and intent of this proposed policy maintain respect for the principle that ors should not investigate each others' private lives. @Tamzin and L235: Yes or no, is this reading of policy yours as well? — Red-tailed hawk (nest) 06:20, 7 September 2022 (UTC)Reply[reply]
    Kevin and I are not suggesting any change to WP:OUTING. My reading of that clause in OUTING—taken in context alongside other language that, as noted, explicitly allows reports of sensitive information—is that ors should not try to "dig up dirt" on one another, especially not speculatively or vindictively. OUTING is not a blanket ban on ever looking at anything anyone does off-wiki, and the community has repeatedly rejected attempts to make it one, something reflected in its current wording. Give that functionaries and ArbCom are bound by OUTING too, any stricter reading of that clause would mean that they commit blockable/desysoppable offenses anytime they block someone for off-wiki harassment—a block that by necessity involves some level of looking at what someone has been doing off-wiki. -- Tamzin[cetacean needed] (she|they|xe) 06:43, 7 September 2022 (UTC)Reply[reply]
    That's clearly a non-sequitor: no one (that I have seen anyway) is suggesting that an admin who in good faith comes into possession of evidence of off-wiki harassment should refuse to act to protect the harassed party. And in fact, that's the very reason we have the system that we presently have, which balances user privacy with the possibility of administrative action in the fashion it does (with appropriate non-public oversight). But that is a very different animal from permitting admins (and potentially cohorts working in close collaboration with them) to unilaterally (and on their own onus) begin digging into the off-project identities of users. That is an exception that just cannot do anything but ultimately swallow the rule. It's very clearly the exact bridge too far that inspired the very plainly worded prohibition on investigating your fellow ors in the outing policy. Acting on information brought to you about an especially harmful and chilling class of harassment is one thing; every admin having the power to self-appoint themselves an inspector-general, in any random case of any user they can say they genuinely thought might be a sock, is a very different thing, and something I pray the community will have the good sense to reject here. SnowRise let's rap 07:11, 7 September 2022 (UTC)Reply[reply]
    @Red-tailed hawk: Yes, I believe that the proposal here is consistent with and should be read together with WP:OUTING, and that no changes to OUTING are implied by this proposal. Best, KevinL (aka L235 · t · c) 17:05, 7 September 2022 (UTC)Reply[reply]
    Even though I still support the proposal, I actually think that it contradicts the current understanding by the community of what the outing policy says. This proposal, taken along with the harassment policy, is basically saying that a non-admin can be sanctioned for doing opposition research, but it's OK for admins to do it, so long as they are simply doing it to enforce policy, rather than to push a personal grudge. That said, I believe this to be the actual existing practice of how things are done, but we continue to have policies that say something different, and some very strong sentiment in the community that we need to keep hands and eyes off of off-wiki everything. --Tryptofish (talk) 18:42, 7 September 2022 (UTC)Reply[reply]
  • Support, obviously. If you organized a gang of vandals off-wiki, you should be blocked. Not blocking due to the coms being off-wiki is just taking advantage of a technicality to me. CactiStaccingCrane (talk) 02:10, 7 September 2022 (UTC)Reply[reply]
    As for the potential for a power-grab/privacy concerns raised by SnowRise, I agree that the proposal should be flushed out before being implemented. But you need to propose your idea first. CactiStaccingCrane (talk) 02:11, 7 September 2022 (UTC)Reply[reply]
  • Support admins need more help and more tools to prevent bad ing and problematic accounts. Andre🚐 03:56, 7 September 2022 (UTC)Reply[reply]
  • Support in principle. The particular part of the policy that states that the information has to be submitted strictly before the block seems to be a bit arbitrary and might delay an admin taking action against actively coordinated off-wiki vandalism organized on something like Twitter. Giving the admin some time after making the block (i.e. within 24 hours or something to that effect) would be superior to strictly requiring administrators to submit evidence before a block is made. — Red-tailed hawk (nest) 06:20, 7 September 2022 (UTC)Reply[reply]
  • Oppose largely per SnowRise. I find Tamzin's examples bizarre; they seem to me to be right on the line of desysopable offences (even blockable ones), if not over it. Blocking someone because you googled their user name and found apparent connections to their ing is not okay. Sharing personal information of other ors by email (as proposed here) with any admin who asks for it is not okay. We have teams of people who deal with off-wiki evidence precisely to avoid this situation - those people have to have signed an agreement with the WMF to protect the confidentiality of data they use. Normal admins have not. GoldenRing (talk) 08:45, 7 September 2022 (UTC)Reply[reply]
    Also, I really think WMF Legal need to be involved here, as I can see potential implications for the site ToU and privacy policy. IANAL but if admins are sharing ors' personal information at will for the purposes of maintaining the site, does this not expose the foundation to a degree of legal risk? GoldenRing (talk) 08:50, 7 September 2022 (UTC)Reply[reply]
    I agree that this should be run past WMF Legal if implemented. Especially the part where ArbCom is supposed to act as a sort of information broker that provides personal information on ors to any admin that asks. – Joe (talk) 12:04, 7 September 2022 (UTC)Reply[reply]
    WP:Wikimedia Foundation statement on paid ing and outing exists. ~ ToBeFree (talk) 18:23, 7 September 2022 (UTC)Reply[reply]
    I'm well aware of that, thanks. It also doesn't say anything at all that would be relevant to the Arbitration Committee, whose members are all signatories to the WMF's confidentiality agreement, sharing personal information on third parties with people who are not. – Joe (talk) 18:55, 7 September 2022 (UTC)Reply[reply]
    Which part of the WMF's confidentiality agreement prevents an arbitrator from saying "When X blocked Y, they said it was because if you Google Y's username, you get a Twitter profile for the director of marketing at the company Y was making promotional s about"? Genuine question. -- Tamzin[cetacean needed] (she|they|xe) 19:25, 7 September 2022 (UTC)Reply[reply]
    All arbitrators have agreed to refrain from disclosing nonpublic personal data to anyone. If they have access to the identity of Y because of their role, e.g. they got it from the WMF-hosted VRTS you've suggested setting up, that could be nonpublic personal data covered by the access policy. In the specific example you've chosen, you could probably argue that the Twitter profile was excepted because it is or was public (but off-wiki) information, but that isn't the case for all off-wiki blocks by any means. Also, importantly, IANAL, which is why I said I supported checking this with Legal – I'm not saying I have all the answers. That, generally, is another good reason to continue leaving this kind of work to functionaries: we tend to be a cautious bunch that will err on the side of privacy unless told otherwise. I can't say the same of the admin body at large. – Joe (talk) 20:07, 7 September 2022 (UTC)Reply[reply]
    The quote above seems to come from [1]. It should perhaps be noted that the sentence continues with "except as permitted under those policies" ("the Privacy Policy; the Access to nonpublic personal data Policy; and any other applicable and nonconflicting community policy relating to nonpublic information"), and that "Nonpublic Personal Data" (capitalized in [2]) refers to a term defined earlier on the page. ~ ToBeFree (talk) 20:36, 7 September 2022 (UTC)Reply[reply]
  • Oppose. This is a terrible idea. as long as that evidence will be made available to any uninvolved administrator upon request – what if the blocking administrator isn't available? Or has left the project? Or lost the evidence? Or died? Just as the evidence for regular blocks are documented on-wiki, blocks for private evidence need to be documented somewhere so that no one person is a bottleneck for an appeal or unblock request, which could (and regularly does) come years after the initial block. ArbCom set up processes for doing precisely that years ago, using secure, WMF-maintained software, staffed by experienced and vetted functionaries who have signed the confidentiality agreement for handling nonpublic information, and it has been working perfectly fine for years. I don't see what problem this is supposed to solve and frankly it seems to stem entirely from one of our newest admins misunderstanding WP:BLOCKEVIDENCE. – Joe (talk) 08:51, 7 September 2022 (UTC)Reply[reply]
    I'm also a bit worried that good number of the supporters so far seem to be supporting because the opening text of this RfC gives the impression that we currently don't block people based on non-public information (e.g. of UPE). This is not correct. Users are regularly blocked based on non-public information, but policy restricts these blocks only to CheckUsers, Oversighters, or Arbitrators who have signed the confidentiality agreement. The proposal here is to alter WP:BLOCKEVIDENCE so that all administrators are permitted to make these type of blocks. – Joe (talk) 08:59, 7 September 2022 (UTC)Reply[reply]
    @Joe Roe: I'm a bit confused by your reasoning here, with respect to admin resignation/death/etc. The entire "send evidence to ArbCom" portion of this proposal is meant to address that scenario, filling a gap that currently occurs any time an admin makes a block like this. Which is a fairly common occurrence, particularly for admins who do a lot of anti-UPE work; the fact that you were unaware of that is a good example of the disconnect between different groups of admins that prompted me and Kevin to start this RfC. (FWIW, of the 1,015 blocks I've made since becoming "one of our newest admins", I reckon there's 5 or fewer that fall under the scope of this RfC. In all cases I have said I was willing to share evidence with inquiring admins, in line with my and many other admins' interpretation of BLOCKEVIDENCE's current meaning.) -- Tamzin[cetacean needed] (she|they|xe) 16:54, 7 September 2022 (UTC)Reply[reply]
    Sorry, I was in a hurry and wasn't clear. The thing is that that gap only exists if you are making blocks against policy, hence this is a proposal that only solves a 'problem' of its own creation. If we stick to current policy, there are already robust processes that don't make one person the bottleneck and don't involve passing nonpublic personal information around a group of over a thousand people. I've yet to see any evidence that the latter is a "common occurrence" or that "many other admins" have the same misunderstanding about BLOCKEVIDENCE that you did. If I'm wrong, then as Thryduulf says below, they need to stop now and start following policy as it's currently written, not how they'd like it to be, before this ends up with ArbCom. – Joe (talk) 18:26, 7 September 2022 (UTC)Reply[reply]
    @Joe Roe: The whole point of this RfC is that policy as it's currently written is ambiguous. I and many other admins interpret will [ ] be made available to all administrators to require admins to be willing to share evidence privately when asked, but not to require them to present it on-wiki. That is not a "misunderstanding". It is a good-faith interpretation of an unclear clause. If you want to change BLOCKEVIDENCE to be more clear in your proposed direction, you should make a counter-proposal; but acting like the current meaning is crystal-clear is disingenuous. -- Tamzin[cetacean needed] (she|they|xe) 19:22, 7 September 2022 (UTC)Reply[reply]
    I look forward to hearing from these many other admins. So far it seems there is a unanimous consensus amongst functionaries (who have been dealing with these kind of blocks day-in-day-out for years), that will not be made available to all administrators means will not be made available to all administrators, not just to individuals on request. I can't see why I would need to make a "counter-proposal" to keep a policy as it has been for fifteen years, apparently without any problems. – Joe (talk) 20:22, 7 September 2022 (UTC)Reply[reply]
    You've already heard from several, both here and at WT:ACN. It's not exactly surprising that many functionaries, who are allowed to make these blocks under either interpretation, don't care about the distinction. Incidentally, your and several other functionaries' statements squarely at odd with multiple policies, including WP:OUTING (RoySmith, Thryduulf), the m:ANPDP (you, Thryduulf) and WP:UPE (Thryduulf), does not exactly bode well for the premise that functionaries (who need only finish in the top ~8 out of ~10/12 in an ACE to have that status for life) are somehow a more responsible body than their fellow administrators. Your attitude here reeks of superiority. You are not better than me or any of my ~1,000 non-funct admin peers just because 71% of voters 4 years ago thought that you should be on ArbCom. -- Tamzin[cetacean needed] (she|they|xe) 20:35, 7 September 2022 (UTC)Reply[reply]
    Read the threads again Tamzin, it's pretty much just you. Nobody is saying they're superior to you, but knowledge of how policy operates comes from experience in applying it. The functionary team (who are not all former arbs, by the way) have a collective experience of handling nonpublic data stretching back decades. They are vetted by the community and the WMF at a higher standard than RfA, and work within an established system of documentation and oversight (inc. ArbCom, OmCom and WMF T&S). It's astounding to me that, less than six months after you got the bit, when the Arbitration Committee told you that you'd misunderstood a part of the blocking policy that they originated, and posted a formal statement clarifying what to do in similar situations in future, you decided it must be they and/or the policy that was wrong. – Joe (talk) 06:11, 8 September 2022 (UTC)Reply[reply]
  • Comment The more I think about it, the less comfortable I am with this solution. I like it in principle, but I do think it needs a bit more consideration regarding the personal information. In Europe, we are governed by GDPR with regards to data protection, how long data can be kept, what purposes it can be kept for. Legally, the servers may be in the USA, if a user is accessing the data from Europe I'm not sure how that falls - and that's assuming the data is all held on the servers in the US. At present, the suggestion is that data is sent to the arbcom list, which is then immediately disseminated to Arbitrators mail boxes, which they have full control over. It's hard to argue the "US servers" point of view there, an arbitrator is clearly a data controller.
    Then there's the technical side of things. Based only on information that the user chooses to share - username they created, information they've given etc, you are investigating the individual online. That opens up a lot of risk - of mistakes, of joe jobs, of abuse. We shouldn't be encouraging this sort of behaviour, especially in our administrators.
    I still need to think more about it, so won't outright oppose, but I'm certainly uncomfortable. WormTT(talk) 09:01, 7 September 2022 (UTC)Reply[reply]
  • Strong oppose per GoldenRing, Joe and SnowRise. This is not something administrators should be doing at all, if you are doing it you need to stop it now. Use the existing channels to report any off-wiki coordination you stumble across. Thryduulf (talk) 10:11, 7 September 2022 (UTC)Reply[reply]
  • Strong oppose Run-on-the-mill admin blocks should be for stopping sustained atrociously poor ing that cannot be solved by attempts at communication, and should be held accountable by the community at large. This entire proposal throws out a basic principle of adminship, public accountability, out the window. In the proposal's scenarios with dishonest COI ors, I fail to see any benefits to blocking users just because of their IRL jobs, instead of concretely visible on-wiki activity like actually writing promotional articles, actually posting spam, vexatious restoration of deleted content, and the like. — Ceso femmuin mbolgaig mbung, mellohi! (投稿) 12:53, 7 September 2022 (UTC)Reply[reply]
    To be clear, in both UPE examples given, the or had ed about their employer or someone affiliated therewith and then denied having any COI, a violation of enwiki policy and the Terms of Use. In one case there were blatant spam issues, and in the other there was meatpuppetry to keep a COI article at AfD. -- Tamzin[cetacean needed] (she|they|xe) 17:03, 7 September 2022 (UTC)Reply[reply]
    If there are spam issues then there is ample on-wiki evidence for a block, you don't need anything else. If someone is engaging in sockpuppetry then give the evidence to checkusers who are explicitly empowered by the WMF to deal with that information. If they are engaged in meatpuppetry then there will be ample on-wiki evidence of this behaviour and they can be blocked without needing any non-public information. If they are warring to keep an article then block them for warring, again you don't need anything else. If you believe they are violating the terms of use then you need to make the WMF aware of that, as they are the only ones empowered to enforce that. Thryduulf (talk) 19:11, 7 September 2022 (UTC)Reply[reply]
    There are many situations where the existence of a COI tips the balance of AGF toward blocking. That was the case in both examples I gave. Admins are often fairly patient with users who might be, for instance, just an over-eager fan of a TV show; while someone known to work for the show's production company will get blocked. As to the final sentence of your comment, that is dramatically out of step with current policy. There have been 212 blocks so far this year mentioning the ToU in the block summary, exercising the authority given to admins under WP:UPE. -- Tamzin[cetacean needed] (she|they|xe) 19:33, 7 September 2022 (UTC)Reply[reply]
    A list of 1228 such blocks, forked from the above-linked SQL query. ~ ToBeFree (talk) 04:57, 8 September 2022 (UTC)Reply[reply]
    The last sentence is incorrect. "The Wikimedia community and its members may also take action when so allowed by the community or Foundation policies applicable to the specific Project ion, including but not limited to warning, investigating, blocking, or banning users who violate those policies." ~ ToBeFree (talk) 19:36, 7 September 2022 (UTC)Reply[reply]
  • In general, I think that we should only block people on the basis of on-wiki evidence. With few exceptions, whatever happens off-wiki should be irrelevant. The first exception that springs to mind if off-wiki harassment, but there are also other cases, such as UPE etc. However, those should remain just that: exceptions. After all, opposition research is strongly discouraged even when it is based on information that may be publicly available on-wiki (see WP:OUTING and Wikipedia:Harassment#How to deal with personal information). This policy change, in my opinion, normalises blocks based on off-wiki evidence too much, for my tastes, and risks encouraging opposition research. In addition, it runs counter to two fundamental principles of the project: transparency and the idea that all ors are equal regardless of their user rights. In fact, when an or is blocked on the basis of off-wiki evidence that is only made available to administrators, we are preventing non-administrators from evaluating whether the block was appropriate, without a good reason. We should not forget that administrators are not really qualified to handle non-public information, since they have not signed the WMF confidentiality agreement and have not been vetted for those responsibilities. On the other hand functionaries and arbitrators have been vetted and have signed the confidentiality agreement and policy already recognises that they are qualified to make blocks based on non-public information. I don't think the policy should be changed, I don't find the change necessary or wise. If it seems complicated to have someone blocked on the basis of off-wiki evidence, in my opinion it's because that's how it should be. Salvio 13:34, 7 September 2022 (UTC)Reply[reply]
    @Salvio giuliano: I think it's a valid outcome of this RfC for the community to clarify that it is unacceptable for admins to make many blocks they already make: I know administrators other than Tamzin make those blocks frequently. If the community does so, I would like it to speak clearly – as I wrote above, Also, because there’s disagreement about what policy currently requires, I’d ask any folks who oppose this proposal to indicate what they think the current policy says. (Are blocks based on info with an “email me for the evidence” note permissible? Does that count as information that will [] be made available to all administrators?) If the community says "no", we ought to update BLOCKEVIDENCE to say so. Best, KevinL (aka L235 · t · c) 15:49, 7 September 2022 (UTC)Reply[reply]
    @L235: Are blocks based on info with an “email me for the evidence” note permissible? Does that count as information that will [] be made available to all administrators?) in my opinion no, those blocks are not permissible unless the admin in question can guarantee that they will always be available to promptly respond to requests for that information for the next 5-10 years (possibly longer) in the event of an appeal or other legitimate reason for needing the information and never give it out in other situations. If the information cannot be shared on-wiki then it must be shared, at approximately the same time as the block, with the arbitration committee. Thryduulf (talk) 16:41, 7 September 2022 (UTC)Reply[reply]
    If the information cannot be shared on-wiki then it must be shared, at approximately the same time as the block, with the arbitration committee.
    This is pretty much what the proposal says, though, right? I'm not trying to be obtuse – I just am not quite getting it. Best, KevinL (aka L235 · t · c) 16:55, 7 September 2022 (UTC)Reply[reply]
    @L235 I was answering your question in the quote about whether admin's saying "email me for the evidence" is acceptable. And to reiterate, it absolutely is not. The proposal mitigates that aspect, but that's one part of my opposition. Thryduulf (talk) 19:05, 7 September 2022 (UTC)Reply[reply]
    I agree that it can be useful for the community to reiterate its position, so that everyone is aware of what is and is not proper. However, I've got to say that, the way I interpret policy, blocks with an "e-mail me" note are already inappropriate. The relevant clause of WP:BLOCKEVIDENCE may be argued to be less than clear, but, if we consider the body of relevant policies and their spirit, it's clear to me that admins are supposed to be blocking only when the information the block is based on is available to all administrators, such as when a block is based on deleted s. When it's not, it's not appropriate for an administrator to impose a block, unless it's one of those "appealable only to ArbCom" blocks (or is based on CU or OS data). Salvio 19:18, 7 September 2022 (UTC)Reply[reply]
    I don't know if it's been mentioned, but the sentence in question initially read [...] based on information that cannot be made public, so the original intent was quite clear and, in the fifteen years since, it doesn't look like anyone else has found the reworded version confusing enough to bring it up. – Joe (talk) 20:12, 7 September 2022 (UTC)Reply[reply]
  • Wrong question. Before we figure out how to handle the record keeping for non-CU blocks involving off-wiki evidence, we should figure out if we even want that to be happening at all. If we're going to officially condone people poking around in LinkedIn, UpWork, etc, looking for evidence for blocks, then we need a wholesale rewrite of WP:OUTING. I know it goes on, so I guess it's good that this RfC got started because it brings the practice out in the open for discussion. Only after we figure out if we want admins (or anybody) doing that, then it's time to figure out how we want to handle the record keeping. -- RoySmith (talk) 13:41, 7 September 2022 (UTC)Reply[reply]
    Prodded by Tamzin's comment elsewhere in this thread, I've put in some quality time re-reading WP:OUTING and the documents it references. I'll walk back my "wholesale rewrite of WP:OUTING" partly as an overstatement, but more because it's a non-sequitur. The key point I was trying to make above is that there's two quite distinct issues here:
    • Does the community want admins doing these kinds of off-wiki investigations?
    • If the answer is yes, then what documentation process do we want to build around that?
    It seems to me that this RfC presupposes that the answer to the first question is "yes". Based on what I'm seeing here, I'm unconvinced that's correct. Until we're sure we know the answer to the first question, considering the second one just confuses things. -- RoySmith (talk) 15:12, 8 September 2022 (UTC)Reply[reply]
  • I am a bit surprised to see so many ors suggest that combatting professional, some of it very sophisticated, attempts to manipulate our content through paid ing is not a top flight concern. Our social policies are not a suicide pact and OUTING is a social policy. It is designed to protect good faith and bad faith ors alike. But that doesn't mean we should say to those administrators who wish to stop bad faith ors "oh sorry, you're not fit to do so until you get Checkuser and/or Oversight". L235 makes a crucial point that in actual practice these efforts seem to be accepted. What we are talking about here are efforts to ensure our readers are met with content that matches core policies and pillars like "Wikipedia is written from a neutral point of view". I'm a bit ambivalent on this proposal on the whole - hence why I'm not supporting - but I actually expected to be here with some of my concerns (some of which are capture above) rather than with what I see as the merits of this proposal. Best, Barkeep49 (talk) 14:39, 7 September 2022 (UTC)Reply[reply]
    I'm surprised, disappointed (and frankly a little horrified) to find that so many ors are supporting the principal (and even practice!) of permitting random ors to undertake privacy-violating research into other ors based only on a suspicion that they may, or may not, have done something that may, or may not, have broken a policy an or may, or may not, know about. What matters is that our articles are neutral, whether something is or is not neutral is not something that is determined by whether an or received money for an , it is based solely on the words on the wikipage and the coverage of the topic in (reliable) sources. Even aside from that, not a single one of us has the right to authorise any other of us to invade the privacy of another human being just because we don't like something they might have done on a website. Thryduulf (talk) 16:53, 7 September 2022 (UTC)Reply[reply]
    @Thryduulf I'm not suggesting we allow random ors. I am suggesting that it is current practice to allow administrators to make such blocks. But I certainly can understand why that's not a trade-off you'd be willing to make, even if it is currently common in the community. Some feelings along those lines are a minor reason why I'm here as a commentator rather than !voter. Best, Barkeep49 (talk) 17:35, 7 September 2022 (UTC)Reply[reply]
    I think this line of argument is a bit of a red herring. The question here is not whether we fight spam coordinated off-wiki—of course we should, and we do—but whether enforcement should be open to all admins or restricted to functionaries. I've been fairly deeply involved in the UPE area since before I became an admin and I don't think the former is a common practice or ever has been, so I'm rather surprised to see more than one arb now say that it is. If you guys are aware of admins making blocks that are against current policy, shouldn't you, you know... stop them? – Joe (talk) 17:55, 7 September 2022 (UTC)Reply[reply]
    Exactly what Joe says. If you haven't signed the foundation's agreement related to non-public information then you have absolutely no business dealing with non-public information (and that's the minium requirement imo). If anybody is currently doing that, and you know about it, then (1) why have you not stopped them? and (2) please make sure WMF legal is aware of it so they can take any appropriate action to mitigate the consequences. Thryduulf (talk) 19:01, 7 September 2022 (UTC)Reply[reply]
    The term "non-public information", when used in the context of WMF policy, refers to non-public information held by the Wikimedia Foundation, such as IP addresses. The m:ANPDP does not in any way regulate how community members interact with non-public information that they did not get from the WMF. Similarly, Legal has explicitly said that the m:Privacy policy does not apply to information gleaned from non-WMF sources. -- Tamzin[cetacean needed] (she|they|xe) 19:12, 7 September 2022 (UTC)Reply[reply]
    @Barkeep49: TBH my first thought on seeing this RFC was to file a request for arbitration, requesting that User:Tamzin be desysopped for cause as blocking based on similarity of names between an on-wiki account and a Google search result seems so blatantly wrong. I don't think, given my recent history, that I'm the person to do it but I'm still not sure it would be the wrong move. So I'm rather stunned to see a current arb here treating it as business as usual. WP:OUTING is crystal clear that posting personal information on-wiki unless that user themselves has revealed the information on-wiki - regardless of how really available the information might be offhwiki - is harassment which always merits a block; posting on-wiki "I have this guy's personal information, just email me and I'll provide it" might arguably avoid technically violating that policy but IMO it is a clear attempt at an end-run around it. GoldenRing (talk) 21:22, 7 September 2022 (UTC)Reply[reply]
    @GoldenRing:. So, User:JohnUncommonsurname creates Acme Corp. It's a G11, but not on its own a G11-and-block. I delete it and ask JohnUncommonsurname if he has any connection to Acme Corp., telling him that he's required to answer honestly. He says no. I then Google "John Uncommonsurname." The top result is a LinkedIn profile for the director of marketing at Acme Corp. Your position is that it is "blatantly wrong" for anyone—not just me, but even a functionary—to block based on that? The chance of coincidence in such a situation is considerably lower than the chance of coincidence we see as acceptable in sockblocks, for context. -- Tamzin[cetacean needed] (she|they|xe) 21:32, 7 September 2022 (UTC)Reply[reply]
    Tamzin, while I agree with you that this might be the best thing to do to protect the encyclopedia from bad people, the community has traditionally, AFAIK, frowned on such things, even if communications remained off-wiki. Checkusers, oversight and arbitrators probably have community mandate to do this, but there are 400+ admins and so far, I don't believe this kind of off-wiki investigation used for blocking was explicitly allowed, and it only takes place by WP:IAR. Obviously, you haven't shared this information on-wiki, so it isn't by-the-letter WP:OUTING, but the community has tended to frown on it, and I think it's a fair point that while we like and trust Tamzin, we might not like and trust every administrator. Also, what about unreliable information from a fake social media profile, then getting someone blocked that they deny connection to? If we open the door to Linkedin searches, can I get blocked for an unpaid parking ticket? Joking aside, I supported changing the policy, above, but I also can see why the position is defensible not to permit such things. Andre🚐 21:42, 7 September 2022 (UTC)Reply[reply]
    @Tamzin: I did not say so. As others have repeatedly pointed out to you here, functionaries are in a different position to admins because they have the option to make blocks where evidence is only available to other functionaries and all functionaries must establish their real-world identities with the WMF and sign the non-disclosure agreement. You, as a non-functionary admin, are not in that position and so your only options in this situation are to make the evidence available to all admins (and I question whether a note in the block log meets this requirement anyway - I've been desysopped after disappearing for two and a half years so God help anyone I blocked on non-public evidence who wanted to appeal in that time - but that's beside the point here) or to mark the block appealable only to arbcom and immediately forward the evidence to them. I still don't get how you think what you've done is okay. GoldenRing (talk) 22:00, 7 September 2022 (UTC)Reply[reply]
    @GoldenRing: "all functionaries must establish their real-world identities with the WMF" — this hasn't been the case for a long time (way back when I first got access to OTRS I had to send in a scan of my passport, but that was years ago...), "and sign the non-disclosure agreement" — this is the access to nonpublic personal data policy (the same thing the VRT folx sign), a topic which I muse on below — TheresNoTime (talk • she/her) 22:12, 7 September 2022 (UTC)Reply[reply]
    No, you aren't the best person to be doing so, and it would be the wrong move regardless. Black Kite (talk) 21:35, 7 September 2022 (UTC)Reply[reply]
    @GoldenRing first what I can/have to say as an or and what I can/have to say as an arb are not the same. So playing the "stunned to see a current arb" card in a non-arb context is not my favorite and contributes to me feeling unable to be a part of the community in ways that are unpleasant for me - such as being able to participate in an RfC about policy that I care deeply about.
    But putting on my arb hat, the background here, which you may or may not be aware of, is Tamzin following the blocking policy, leveled an "appeal only to arbcom" block, and reported the evidence to ArbCom as the policy dictated. I had long been aware of the discrepancy Moneytree notes below between Admin and Blocking policies and that block spurred ArbCom to audit "appeal only to arbcom" blocks. Based on that audit, after consulting with functionaries, we updated previous guidance - written before there were OS blocks and before the Foundation had taken over child protection, in other words in a time where a lot of more "private evidence" blocks made sense that had lead to that appeal only to arbcom language being added to the blocking policy. That updated guidance spurred discussion between Tamzin and myself but mainly between Tamzin and L235 who ended up here. As an Arb I stand by everything in that updated guidance and reflects my current approach to any case requests we might get about the topic.
    But yes I also am respectful of the fact that the blocks so many find troubling are very common and have never resulted in a case request or other substantial issue raising suggesting, because policy is practice, and that regardless of my preference the community seems to have been OK with it despite what ADMIN said. Bottomline: I would love to get rid of the idea of those blocks and I would love for the discrepancy in what is allowed between the BLOCKing and ADMIN policies to be reconciled. Best, Barkeep49 (talk) 23:22, 7 September 2022 (UTC)Reply[reply]
    @Barkeep49: I'm sorry to put you in that position but I think it's unavoidable. We are talking here about what is apparently a widespread breach of very longstanding policy by a large group of admins (at least, one admin says it's widespread and a large group of admins) and it is your job as an arbitrator to reign that in. You are the only recourse the community has to stop administrators doing this. You issued guidance which you've linked above which explicitly says this is wrong. I don't see how you can realistically discuss this while pretending you're not an arbitrator; if arbcom is not willing to enforce policy against administrators here then where does that leave us? Why is the approach being taken here to propose a change to policy that would retrospectively make this policy breach okay rather than enforcing policy as written and your own guidance on that policy? I'm not usually one of the ones to moan about arbcom but I just don't get the approach here. GoldenRing (talk) 09:07, 8 September 2022 (UTC)Reply[reply]
    I think we have very different conceptions of what an arb can do. My belief is that the community has intentionally put a check on ArbCom's powers by making it a reactive rather than proactive body. So if I see something that is, in my view, a policy violation I can either file a case request, the same as any other or, or I can hold that opinion and wait until the community decides to raise it with us. And yet in this very specific situation ArbCom did exactly what you wished for here and tried to get the community aligned on policy. We issued a statement about how private information should be handled which was directly based on 2 previous statements arbcom had done (in other words there was clear precedent). And what feedback did we receive? significantly exceeded its authority, an overreach of authority, and an unexpected, significant change to give examples of quotes from three different ors. There were also a couple supportive comments as well. But that statement is my current view, as an arb, about what is allowed under policy today. This, however, is a discussion of what policy should be. And so I feel entitled as a member of this community to comment the same as anyone else. And, as I keep having to point out, not even comment that I think it should pass which is why I haven't voted in favor of it. I'm not opposing it because I would love to get rid of the idea of those blocks and I would love for the discrepancy in what is allowed between the BLOCKing and ADMIN policies to be reconciled. and at minimum this does that even if it's not in my preferred way. But again that's me as an or. If you want to know what I think as an arb about policy today, I already did what you asked, to criticism. Critism I'm willing to handle because that's what I volunteered for. I didn't volunteer to be told I no longer get to have opinions on how to improve our community. Best, Barkeep49 (talk) 13:39, 8 September 2022 (UTC)Reply[reply]
    @Barkeep49: Okay, I think I've been reading more into your comments than was there and I'm sorry for it. I'm afraid arbs could put their socks on in the morning and some would consider it an overreach of authority; I think that statement hits exactly the right note, FWIW. GoldenRing (talk) 16:34, 8 September 2022 (UTC)Reply[reply]
  • Support and question why anything easily google-able is being considered private information for purposes of OUTING. If any or can enter the article subject, connected parties or ors handle into a search engine and find the connection, it's not private. UPE is only getting worse and we need every tool available to shut them down quickly. Slywriter (talk) 14:49, 7 September 2022 (UTC)Reply[reply]
    Because OUTING is rightly very clear that only information an or has voluntarily shared or linked to on-wiki is considered public. Every or, even those suspected of undisclosed paid ing, is entitled to their privacy and we absolutely must not erode that. Thryduulf (talk) 16:45, 7 September 2022 (UTC)Reply[reply]
    The "voluntarily shared" part is the key here. Most people under a pseudonym. That's a public declaration that they have an on-wiki identify and an off-wiki identify and they desire the two to be kept separate. The fact that we may be able to pierce that veil with little trouble doesn't make it right to do so.
    In the real world, I have a cheap padlock on my garage door. Nobody intent on theft would need more than a moment to pop it open with tools available at any hardware store. The real purpose it serves is an unmistakable declaration that "The things behind this door belong to me and you're not allowed to enter without my permission". If somebody cut the lock and stole my bicycle, they wouldn't get very far in their criminal defense with, "It was a crappy lock; it hardly took any effort at all to get past it". -- RoySmith (talk) 19:40, 8 September 2022 (UTC)Reply[reply]
    Slywriter, to answer your question of why "easily google-able" things are considered private information for purposes of OUTING policy: We don't want routine wiki squabbles bleeding over into off-wiki harassment, because we don't want people's off-wiki lives being used as cannon fodder on wiki in routine squabbles, because ors in some parts of the world could be in danger of arrest or death for their on wiki work, and because we tend to highly value privacy as a general principal. So when some sanction or other official action involved off-wiki info, we require it to be handled in a confidential manner. The question here, as I understand it, is basically whether admins are permitted to act on the info or whether they need to pass it to a checkuser/oversighter/arb for possible action. Alsee (talk) 19:19, 8 September 2022 (UTC)Reply[reply]
    The point of "public" in Wikipedia is what is on Wikipedia, not the one on Google. Yes, what is on Google is public, but the Internet is limitless. While you think that it is okay for an admin to look up your username, is it okay to look up your email? Is it okay for an admin to look up Reddit and try to find similar username, and see what kind of subreddit you had subscribed? Is it okay for an admin to look at hacked databases (available in online as well!) to try to find a connection? The potential for overreach is endless. I don't want admins running amok doing fishing expions just to catch some paid ors. ✠ SunDawn ✠ (contact) 12:30, 16 September 2022 (UTC)Reply[reply]
  • I'm a bit confused by the proposal and several support and oppose votes above; there seems to be a pretty fractured understanding of outing vs. pursuing UPE cases vs. disruptive offwiki behavior vs. public and non-public information vs. NDAs vs. etc. above. My main question, though, is the text at Wikipedia:Administrators#Special_situations that appears to approve these sort of blocks and contradicts BLOCKEVIDENCE per my reasoning here going to be changed as a result of this? Or will this just create more policy headaches? Or does this proposal and the text and ADMIN actually align in some way I'm not noticing? Moneytrees🏝️(Talk) 14:57, 7 September 2022 (UTC)Reply[reply]
    @Moneytrees: In answer to your ACN talk message, when I voted for the statement, I did so because the text at Wikipedia:Administrators#Special_situations appeared to be derived from ArbCom's prior statement, not as an independent expression of community policy/consensus. I therefore understood it to be within ArbCom's authority to change it. If this proposal passes, ADMIN will be harmonized to be consistent with it. Best, KevinL (aka L235 · t · c) 15:59, 7 September 2022 (UTC)Reply[reply]
    My thining behind the scenes is that I don't think ArbCom can directly change ADMIN policy. But it absolutely could update its statement and the community could decide how/if to incorporate that into ADMIN. And that's what happened in this situation and now here - this RfC is a reaction to that statement. Best, Barkeep49 (talk) 18:11, 7 September 2022 (UTC)Reply[reply]
  • Oppose. Jayron32 nicely summed up my thoughts. Functionaries are supposed to handle nonpublic information, not admins. Strong oppose until legal is consulted: I agree with the above that this needs to be run through legal before we make this change. Better safe than sorry. Not sure where I land on the merits of the proposal. If/when legal gives the okay, I will strike my oppose. HouseBlastertalk 16:33, 7 September 2022 (UTC) struck and replaced 01:19, 10 September 2022 (UTC)Reply[reply]
    See above ("WP:Wikimedia Foundation statement on paid ing and outing exists") ~ ToBeFree (talk) 18:26, 7 September 2022 (UTC)Reply[reply]
  • I have the same feeling I get whenever there's a major proposal or change (on Wikipedia or in the rest of the world) involving a significant trade-off of privacy for security. There would be a lot of harm that could be prevented if we could connect an abusive user to their off-wiki identities, but there's also harm in removing those protections. Basically nothing to hide argument. I'd tend to oppose based on the reasons articulated in that article. — Rhododendrites talk \\ 17:27, 7 September 2022 (UTC)Reply[reply]
  • Oppose for several reasons. First, I am also leary to advise any or, including admins, to act as real-life investigators to try to dig up information about the real-life identity of Wikipedia users. The kind of un-intended consequences and knock-on effects of such advics is frankly scary; and where policies come into conflict (and policies always will) I tend to grant supremacy to WP:OUTING and privacy concerns over any other policy. On-wiki behavior should be (in most cases) all we should be basing our blocking decisions on; if off-wiki evidence is necessary, it should be turned over to Arbcom or T&S or someone else with advanced positions of trust. There is no way I expect the hundreds of admins to deal with such concerns adequately. I know that WP:UPE exists; but such concerns do not trump privacy concerns, which we should hold as sacrosanct. I am also against the deputizing of other admins to "handle" private information. Some functionaries are vetted and have approval to handle such information. Admins are not and I am not comfortable with that. If a private information must be used as evidence, pass it on to Arbcom or T&S and let them handle it. --Jayron32 17:34, 7 September 2022 (UTC)Reply[reply]
  • Oppose on legal grounds, and this seems to be a massive overreach of Wikipedia's powers. Doesn't seem right to allow Wikipedia to pry into the personal life of users and use that information to interact with the user in any way.--Ortizesp (talk) 18:20, 7 September 2022 (UTC)Reply[reply]
    This doesn't change anything legally or otherwise wrt private evidence being used to block anyone or sanction them - it's just about who is privy to it. And until the foundation itself takes charge of their own legal terms and prohibitions (particularly UPE), that's how it will remain. PICKLEDICAE🥒 19:28, 7 September 2022 (UTC)Reply[reply]
    I'm sorry but that is just factually incorrect: under current rules no admins (who have not also been vetted for particular functionary roles reserved for this exact purpose, and signed agreements on the handling of such private information) are meant to be issuing blocks on the basis of off-project information. They are meant to exclusively forward that information to the Trust and Safety team, to ArbCom, or to the VTRS queue, not take direct action on it. That is precisely the reason Tamzin forwarded the proposal: because they think admins should have that ability. As is expressly stated in the prompt.. And yes, that system is very much entangled with the legal implications of the handling of such of information, as expressed by WMF legal and tghe Trust and Safety team, ArbCom, and other bodies with heightened authority, tools, and concerns in this area. So, without meaning offense, your statement is just plain wrong: this would be a radical departure from the existing community consensus, the existing framework for handling such information and legal considerations and interests for parties on all sides. SnowRise let's rap 20:42, 7 September 2022 (UTC)Reply[reply]
    re-read what I said. Nothing has changed legally or otherwise. PICKLEDICAE🥒 20:57, 7 September 2022 (UTC)Reply[reply]
    Well I guess its possible we are in fact talking past eachother here. But if you're saying that the proposal wouldn't change anything "legal or otherwise", that is quite clearly and massively incorrect. And if that's not what you mean, I'm not sure what you were trying to say in your response to the Ortizesp that would have been accurate. SnowRise let's rap 21:16, 7 September 2022 (UTC)Reply[reply]
    No; there is a disagreement about what "information that will not be made available to all administrators" means, and this is a proposal to clarify it in one specific direction. As a minimum result of this discussion, the wording should be changed to match the actual consensus in a less ambiguous way. Interestingly, even those opposed to the proposal could perhaps agree on the proposed term "information to which not all administrators have access", which is much clearer. ~ ToBeFree (talk) 20:58, 7 September 2022 (UTC)Reply[reply]
    I do tend to agree that any clarity resulting from the discussion can be viewed as good cause for having it. That said: a) this discussion is clearly about more than just how the information would be shared, as it also proposes to allow admins to make blocks in circumstances they are currently proscribed from, and would either tacitly or expressly allow them more latitude in tracking down or identities off project in a manner they (like all other community members) are presently not meant to be doing; and b) even putting all of that aside, the system of logging such personal information as proposed would itself be a change of truly staggering policy and legal implications for the project and the WMF. SnowRise let's rap 21:16, 7 September 2022 (UTC)Reply[reply]
    "in circumstances they are currently proscribed from", according to your interpretation of the current wording. Not according to others'. This is because some interpret "information that will not be made available to all administrators" as meaning "information that will not be made available to any requesting administrator via e-mail request". You don't, some do. ~ ToBeFree (talk) 21:33, 7 September 2022 (UTC)rReply[reply]
    I don't think there is much ambiguity at all, when we consider that the other hald of that sentence, which follows the highly selectively-quoted clause that keeps getting foessed around here says "that information should be sent to the Arbitration Committee or a checkuser or oversighter for action. These ors are qualified to handle non-public evidence, and they operate under strict controls. The community has rejected the idea of individual administrators acting on evidence that cannot be peer-reviewed." That pretty much says it all: blocks based on non-public evidence are specifically and expressly meant to be handled by particular functionaries operating under a higher standard of controls and safety protocols, and this system exists expressly to foreground the privacy and security of our volunteers. I just simply do not see the flex in that wording you suggest is there.
    The WP:OUTING policy also converges on this wording, and there is absolutely no question what ArbCom thinks on the matter. But even if we were to confine ourselves to looking at the exact wording of that one sentence in WP:BLOCKEVIDENCE in isolation, I don't see how any reasonable reading could hold that the major concern is that there was until now not a system for logging that information, since clearly that has always been a trivial technical hurdle. The overwhelming concern meant to be voiced by that language (which becomes clear when you quote the entire sentence and not just five fragmentary words from it), is for the protection of the privacy and safety of our volunteers. It's so obvious in how it is framed when read in full that I don't think anyone can really reasonably take another meaning unless they went looking for it from the outset.
    Which is clearly also what is going on with the supposed "open to interpretation" argument of the ArbCom ruling, since, if the OP really wanted to get to the bottom of that question, a simple request to the committee would have sufficed. It's pretty clear the answer is taken for obvious, hence the strategy here of instead trying to drum up community opposition to ArbCom's read on the issue, which (yes, in my opinion here) is much more consistent with policy, existing community consensus, and common sense, since the knock-on effects of the altenartive proposed here would be nothing short of vitiating of our current privacy standards. SnowRise let's rap 22:30, 7 September 2022 (UTC)Reply[reply]
    Hi @Snow Rise. I am a co-proposer of this RfC and am also on ArbCom and voted for the statement you're quoting from. Speaking personally, I think policy as written does not currently allow these blocks, but I absolutely think the community has come to accept them – it is the prevailing practice. I think you overstate it when you say that It's so obvious and one can't reasonably take another meaning. You may not agree with the interpretation, as I don't, but it's certainly not unreasonable. Best, KevinL (aka L235 · t · c) 22:35, 7 September 2022 (UTC)Reply[reply]
    @L235 I agree that there's been no objection (well, previous to this discussion), but I'm not sure that's the same as acceptance. It may simply be that most people are unaware that these kinds of off-wiki investigations are going on. -- RoySmith (talk) 23:39, 7 September 2022 (UTC)Reply[reply]
    Fair enough--I don't want to seem to be begging the question here. And insofar as the proposal was co-drafted in the fashion it was, it supports a "reasonable minds may differ" take on this. But I do think the argument in advance of the proposition in support of such acitivity does lean awfully heavily on selective quoting (and to some extent perhaps even willfully missing the forest for the trees), in order to validate a behavior/self-assumed authority that is already being engaged in. Obviously any admin already undetaking such blocks and wanting to persist in that habit has a vested interest in a certain interpretation here, whatever policy actually says.
    And even making all possible caveats for good faith differences of opinion, I still feel it is pretty clear from both the express wording of the relevant policies (and the long course of community discussion surrounding them) that the primary concern voiced in BLOCKEVIDENCE is the protection of volunteer privacy and safety. The lack of an existing system to store personal information in order to facilitate blocks by admins in cases of off-project evidence is not just some highly improbable failure of the community to realize that a log could be created for this purpose: the current system exists (and eschews the collection of personal information in this way) expressly and specifically to avoid having the typical admin (or more precisely, anyone who does not operate under the heightened protection and accountability scheme for dealing with private information) behaving in such a fashion--with regard to both the block and the personally-impelled investigations.
    And I don't think I'm the only non-mop veteran community member here who is rather shocked to learn how presumptuos certain admins have become with regard to this kind of thing. If they have in fact been engaging in this activity, I feel not the least bit conflicted in saying it is not because the community has ever greenlit such activity or in any way has voiced support for such a role as part and parcel of the administrative tools. Quite the contrary: this is a major overeeach in defiance of longstanding community principles, and I feel it needs to be made to stop with regard to any admin who thinks it is within their purview. But then, I assume that is precisely the reason you co-endorsed the RfC itself and that I am preaching to the choir on this. SnowRise let's rap 00:26, 8 September 2022 (UTC)Reply[reply]
    I'm a mop-holder and I'm shocked to learn that these sorts of blocks are being made. My understanding is that they are not allowed - the fact that we've site banned folks in the past for doing opposition research or doxxing kinda made me understand that doing that was not allowed, so I never would have considered that an admin would be doing blocks based on behavior that we've site banned folks for. I'm .. rather shocked at the people saying that it's common - and that there aren't ArbCom cases happening because of these blocks. Ealdgyth (talk) 13:05, 8 September 2022 (UTC)Reply[reply]
  • Comment: There's a lot of mentions here of VRT (in regards to "admins shouldn't deal with personal data, but VRT can") — it may be worth noting that the barrier for entry to VRT is much much much lower than our RfA standards. I'm fairly sure any en.wiki admin making a request for VRT access would likely be granted it, which seems to suggest the issues being raised here are more due to the fact that admins have not signed something like the VRTS Users Confidentiality Agreement - Nonpublic Information (which, I believe, anyone can just go and sign?) and less a question of trust/over-reach. Would those opposing this change their mind if we asked admins who wished to do these sorts of blocks to sign such a document? — TheresNoTime (talk • she/her) 21:53, 7 September 2022 (UTC)Reply[reply]
    @TheresNoTime: There are VRT queues only accessible to functionaries (e.g. paid-en-wp@wikimedia.org and checkuser-en-wpwikipedia.org), which is where nonpublic evidence of misconduct is currently supposed to be sent. If I understand the proposal correctly, the new queue for off-wiki block evidence would be similarly restricted. Regular VRT users do sign the same agreements that functionaries do, but it's not the agreement alone that makes someone 'trusted' to handle nonpublic data. It's the prior vetting, peer review, oversight from ArbCom/OmCom/T&S, etc. – Joe (talk) 06:18, 8 September 2022 (UTC)Reply[reply]
    Everyone using the VRT system handles nonpublic data. You can't really run an e-mail-based system without trusting people to handle the nonpublic e-mail addresses that the messages come from. WhatamIdoing (talk) 19:53, 12 September 2022 (UTC)Reply[reply]
  • Oppose per SnowRise, GoldenRing, and JoeRoe. I do not want admins to go playing Private Investigator and am vehemently opposed to the idea that we start keeping data on the folks doxxed in this manner (because, frankly, that's what's happening - the ors are being investigated and then their information is being shared with others ... doxxing.) I am trying to AGF that those supporting this don't really support holding secret files of evidence on ors that get shared around but... Ealdgyth (talk) 22:46, 7 September 2022 (UTC)Reply[reply]
  • Oppose Having witnessed off-site material be used to improperly block users under alternative pretenses, this will only embolden admins with good intentions to make unfortunate mistakes. That said, I appreciate the general concept of this proposal. ~ Pbritti (talk) 23:56, 7 September 2022 (UTC)Reply[reply]
  • Oppose per the above arugments. This would be a slippery slope towards invasions of privacy and administrator overreach. ~Darth StabroTalk/Contribs 00:38, 8 September 2022 (UTC)Reply[reply]
  • Oppose per SnowRise et al. Like others, I had no idea this was going on, and would have objected if I had known. I'm less concerned about people Googling people than I am about admins blocking ors unilaterally based on off-wiki evidence (whether it's public or private off-wiki evidence). If the evidence, for whatever reason, can't be posted on-wiki, then it needs to be sent to paid@ or arbcom@ or whomever, for further action. Recently I sent a report to paid@ and arbcom@ with what I thought was slam-dunk off-wiki evidence. A CU checked it, and after a discussion with the or in question, determined that there were in fact no policy violations. Shortly thereafter, an arb granted the or autopatrolled. Clearly, I was wrong, and there was more information than whatever evidence I had. If I had been an admin and had blocked that or, it would have been a seriously harmful mistake, possibly driving off a good-faith or, even if it was later overturned. We are all capable of making mistakes; sharing evidence on-wiki, or sharing it via email if it's off-wiki evidence, ensures that there are checks and balances, that it's not just one individual acting unilaterally. Levivich😃 01:15, 8 September 2022 (UTC)Reply[reply]
  • Oppose, encouraging admins to essentially stalk people off-wiki is not the way to go about things. Such behaviour is a total violation of privacy, and to my mind has the potential to be very creepy. Take an admin stalking an ors' social media for example, under this proposal this hypothetical admin would be able to explain away their behaviour if accused by stating they were merely "looking for evidence" on whether they should perform a block, and indeed this adminwould be able to doxx the or by storing their personal information in this proposed archive without any method for this doxxing to be undone, since it would have to be maintained indefinitely so the admin could hoof it around to any other admin who wants it in order to explain their block. There is already a way to block ors for off-wiki behaviour, and I have yet to see any evidence that it is not working, only that it's not working as fast as some people would like. Devonian Wombat (talk) 01:27, 8 September 2022 (UTC)Reply[reply]
    This - there is a way to block people for this behavior already. If it ain't broke... ~Darth StabroTalk/Contribs 03:31, 8 September 2022 (UTC)Reply[reply]
    The status quo is in fact that non-CU admins make those blocks. Prohibiting those blocks may well make it broke. Best, KevinL (aka L235 · t · c) 02:07, 9 September 2022 (UTC)Reply[reply]
  • Strong Oppose, mainly for reasons that SnowRise mentioned, as well as legal issues Re GDPR that WMF Legal should probably look into. While this does not go against the letter of WP:DOX "Posting another or's personal information is harassment, unless that person has voluntarily posted their own information, or links to such information, on Wikipedia." - certainly measures against it ae re being discussed, but it seems like a slippery slope. Maximilian775 (talk) 02:31, 8 September 2022 (UTC)Reply[reply]
  • Oppose. Ordinary admins with negative off-wiki evidence about an or should pass it up the tree. They shouldn't act on it themselves. The proposal that any other admin has the right of access to the information is especially preposterous. If this isn't already clear in policy then it should be made clear. Zerotalk 03:44, 8 September 2022 (UTC)Reply[reply]
  • Oppose per Snow Rise et al. I think this is something most rank-and-file ors would not be comfortable with. LEPRICAVARK (talk) 04:23, 8 September 2022 (UTC)Reply[reply]
  • Oppose in parts, support in parts. When once upon a time we elected our functionaries, and the level of support required to gain either CU or OS was far above what it would take to pass RFA, then sure I could see a substantive difference in the level of trust granted to admins by the community and the level of trust granted to functionaries. I suppose I still kinda see that for the functionaries that are that due to their ACE elections, but Tamzin is right that all that really means is that you finished in the top 8 out of 12 people running or so, so I dont even really get the distinction between an arb elected in 2012 and an admin elected in 2021 in terms of level of trust the community has given them. If the functional difference is having agreed to the privacy policy, well as far as I can tell the the Access to nonpublic personal data Policy is about CU data and material that has been oversighted, but also you can just have people sign that agreement as TNT noted above. I dont like the idea that any admin can request that information from an admin who made a block based on off-wiki evidence, but I dont especially have a problem with the scenario outlined above in which say for example somebody's upwork profile provides DUCK level proof of UPE violations and making a block. But the evidence should be sent to whichever group of admins an appeal of such a block would be directed, OS, CU, ArbCom, whatever. It does not need to be spread as widely as "any active admin". So I oppose the sentence on the evidence should be provided to any uninvolved admin, and instead would favor any block issued on the basis of off-site evidence have its evidence forwarded to an appropriate team with advanced permissions so that they may review it, either as the result of an appeal or just as peer-review. And like CU or OS blocks, if there is evidence of an admin going rogue with their blocks, then AC may desysop that admin or restrict them from making such blocks by motion, like they would strip CU or OS from a functionary that was misusing it. nableezy - 16:25, 8 September 2022 (UTC)Reply[reply]
  • That's treading into dangerous territory if you hide evidence. I'd prefer to have this go to an ArbCom type forum, so the evidence can be reviewed and noted; a closed courtroom where the evidence is discussed but only given to those who need to make the decision, preferably the ArbCom people would be otherwise uninvolved in the block decision. We have to keep this as neutral as possible.Oaktree b (talk) 01:36, 9 September 2022 (UTC)Reply[reply]
  • Oppose. I'm in a weird headspace where I am not convinced the process proposed by the RfC is necesssary, but I am also unconvinced it is necessary for the community to clarify that it is unacceptable for admins to make many blocks they already make (quoting L235 above). My interpretation of WP:BLOCKEVIDENCE as currently written is as follows. Administrators may only justify blocks using on-wiki evidence that any administrator has the technical ability to see (including deleted revisions, private filter logs, etc.). If a block cannot be justified using on-wiki evidence alone, then that block would be impermissible unless the user is a checkuser, oversighter, or arbitrator acting within the bounds of their respective roles and responsibilities. The community has never allowed non-functionary administrators to block ors based primarily on off-wiki/private information.
    The key word, however, is primarily. The RfC essentially makes the claim that this policy is too restrictive and that it would require many "routine" spam and sockpuppetry blocks to go to ArbCom or the CU team. That's where I disagree. It's not uncommon to find cases where there is additional off-wiki evidence that the blocking administrator might be aware of (and could be helpful additional information that could be provided on request to administrators reviewing a block), but in the wide majority of these cases, the block could nonetheless be justified just with the on-wiki evidence. Consider one of Tamzin's examples above in which A user recreated an article on a non-notable person, which had been deleted several times in the past. Repeatedly attempting to create an article about an obscure non-notable topic inherently suggests some kind of connection to past socks that tried the same thing; while I'm not familiar with the exact context here, I strongly suspect the block would have been justifiable based on the on-wiki evidence alone (sure, the justification wouldn't have been as strong, but there would have at least been a plausible argument nonetheless). That's the key here. Contacting a checkuser, an oversighter, or an arbitrator would only be necessary if an or needs to be blocked based on private evidence and a block cannot be justified without that private evidence.
    The one pesky policy section that is admittedly confusing is WP:ADMIN#Special situations. I wrote at the ACN discussion that triggered this RfC that I don't see that section as necessarily irreconcilable with BLOCKEVIDENCE as currently worded—but I do wish this RfC were more about clarifying that section (which appears to have been added unilaterally in 2012) rather than BLOCKEVIDENCE. Mz7 (talk) 10:31, 9 September 2022 (UTC)Reply[reply]
    I think this is a reasonable way to look at the current policy. I just ran into this with my block of Quintin-Mills: His one was spammy enough to bring it into the discretionary range between warn and block, but what tipped me in the direction of blocking was a statement he made in a global rename request. With this RfC in mind, I referenced that as additional evidence in the block rationale, but did not make it the primary reason, as I think most admins will agree that Special:DeletedContributions/Quintin-Mills falls within admin discretion to block over. -- Tamzin[cetacean needed] (she|they|xe) 22:16, 9 September 2022 (UTC)Reply[reply]
  • Oppose Nobody should be blocked on evidence which is not available to the Community at large or which cannot be revealed pursuant to a WP:ADMINCOND request. If anyone thinks they possess offwiki evidence that merits a block they should notify the target and open an ArbCom case in which the target can make representations (if necessary by email). For the same reason, the work to mask IP addresses should be stopped dead in its tracks. The damage that this will do to ors fighting vandalism will be incalculable. 2A00:23A8:4C31:5901:9580:C3C4:6DB1:AE40 (talk) 17:14, 9 September 2022 (UTC)Reply[reply]
  • @Tamzin:, back at WT:ACN, you wrote The community's consensus is that admins may issue blocks based on private evidence.... Was there a formal discussion you can link to out of which said consensus emerged, or were you using the term in the more informal sense of "We've been doing it that way for a long time and nobody objected"? -- RoySmith (talk) 21:59, 9 September 2022 (UTC)Reply[reply]
    @RoySmith: I was referring to the consensus behind the current will be made available to wording, and the implicit consensus to not have that say is available to. -- Tamzin[cetacean needed] (she|they|xe) 22:16, 9 September 2022 (UTC)Reply[reply]
  • Oppose If I'm reading this correctly it creates some new responsibilities that I'm not liking: (1) The sitting ArbCom must maintain an indefinite library of these evidences (2) The sitting ArbCom must maintain a process to produce this evidence to any admin on demand. Well, what are you going to do if arbcom doesn't turn up a volunteer to do this? Creating an indefintite responsibility to future volunteers is a bad idea. — xaosflux Talk 22:42, 9 September 2022 (UTC)Reply[reply]
  • Oppose. The only people who should be judging others on/have access to non-public evidence should be those that have signed the Wikipedia:Access to nonpublic information policy. Also, ArbCom is elected on behalf of the community specifically to oversee cases such as these that are not amenable to public review. WP:BLOCKEVIDENCE is fine as-is. If a block is based on evidence that would be WP:OVERSIGHTED if published on Wiki, someone who has WP:OVERSIGHT permissions should be in charge of these blocks. The real issue for me it seems is that our existing policies are not being enforced. Chess (talk) (please use {{reply to|Chess}} on reply) 03:03, 10 September 2022 (UTC)Reply[reply]
  • Support for LTA cases/cases where off-wiki harassment is part of the case, not simply for seeing what else we can find: There should be stringent reasoning behind an administrator choosing to investigate a user's off-wiki activities – either off-wiki conduct is part of the problem, or a user's abusive behaviour is part of a dangerous and wider trend of how they conduct themselves online (as in, LTA cases where "this user may stalk you/send you death threats" has to be added to the LTA case file). Investigating off-wiki behaviour should be unsuitable in the vast majority of cases, but I can see times when it will probably be necessary. In these cases, there needs to be more of a record than "this administrator found it and this administrator saw it too"; having it entered into record somewhere hopefully makes it a more accountable process.--Ineffablebookkeeper (talk) ({{ping}} me!) 13:04, 10 September 2022 (UTC)Reply[reply]
    It seems like you're saying that someone who lives with a very real Wiki-generated threat would benefit by having any admin who requests it be given access to detail which could further endanger the stalked person like, say, information in police records. What if the off-Wiki harassment is from an individual who was an admin? What if the admin who issues a block happens to be an ex-arb? The forced disclosure in this wording would still apply; would it not obligate them to disclose personal information (that could endanger the threatened or) to any admin who is curious about what looks like an odd block, but has signed no confidentiality agreement? The wording of this proposal was perchance conceived to try to address the (relatively less real, 'cuz nobody dies) problem of paid ing, without full consideration to situations of more consequence than someone getting their company promoted on the internet. Not one of the three examples applies to real-life real threats that happen to Wikipedia ors. Perspective, priorities, and reality check, pls. Obviously, I oppose the wording as written, and in fact, would consider the whole matter should probably be reviewed by someone at legal should it advance, because the alarming repercussions to real people in real life if confidential information, revealed to arbs, ends up revealed to any 65% threshhold admin who has not signed a confidentiality agreement and was not elected is dangerous in real ways ... SandyGeorgia (Talk) 17:40, 22 September 2022 (UTC)Reply[reply]
  • Oppose per Ealdgyth et al. I am shocked to learn that an admin (or many) has been doing the off-wiki investigation the opening statement seems to indicate; surely this is contrary to all our privacy values. Happy days ~ LindsayHello 20:59, 10 September 2022 (UTC)Reply[reply]
  • Oppose. I am uneasy that private information might be passed around among people who have not signed up to the WMF access to non public information agreement. There is already a dedicated VRT/functionaries email address for issues concerning undisclosed paid ing so it is not necessary to do this. --Malcolmxl5 (talk) 22:12, 10 September 2022 (UTC)Reply[reply]
  • Hell no. Administrators should never be blocking users based on "nonpublic evidence". Ever. Any "standard" admin actions must be backed up by public evidence. If the evidence can't be posted on-wiki for whatever reason (and it better be a legal reason or a significant privacy concern, nothing else) the action(s) in question need to be carried out by the Arbitration Committee (for local matters) or the WMF Office (for global matters). And frankly, for ArbCom matters, unless the user being sanctioned is an administrator or otherwise in some sort of higher capacity, the action should really just be a quiet {{ArbComBlock}} without a public motion or noticeboard posting. If you can't publicly share the evidence, don't make a public announcement about the fact that you can't share the evidence. But to be clear, this should only be done in cases where the evidence can't be shared for legal or privacy reasons, not just because admins don't feel like sharing it publicly for whatever reason. I see way too much of "I'm not going to share the evidence publicly because the sanctioned user will use it to evade detection next time" (especially in sock puppetry cases but also elsewhere too). This makes it impossible for someone to defend themselves. While we may not be a court of law, we still need to act in the interest of fairness. Refusing to provide the evidence to the accused and to possible witnesses or outside third parties makes it literally impossible for the accused to prove that they are in fact innocent (even cases of serious harassment can be mistaken; there was once a case on a now-defunct community website that I used to administrate where someone pulled off the most elaborate joe job that I have ever seen, and managed to get a completely innocent user blocked for making death threats (among other things) when it was in fact the user that reported the harassment who was doing the harassing. Fortunately in that circumstance the situation was swiftly corrected, but I worry that such a situation here on enwiki would not be. I realize that this is a bit of an off topic tangent, but this is an issue that continues to weigh heavily on me and one that I feel strongly about. The long and short of it is that if an or needs to be blocked for some reason that cannot be stated on wiki, that block must be carried out either by ArbCom or the WMF Office. No exceptions. No regular admin should be acting in their regular capacity and blocking users based on nonpublic evidence of any kind. If there is a situation (alluded to above) where there is both on-wiki evidence and supplemental off-wiki evidence, block only based on the on-wiki evidence and don't even publicly mention the off-wiki evidence. If you can't discuss it publicly, don't mention it publicly. The end. And if the evidence does not violate any privacy or other laws, it must be stated publicly and all of this becomes moot. Evidence must only be kept private if there is a legal reason or a significant privacy reason to do so - not just because an admin feels like it. Taking Out The Trash (talk) 02:46, 11 September 2022 (UTC)Reply[reply]
  • I don't want individual sysops making this call based on fishing expions, but I do think we need a lightweight process in which three or four of our more experienced sysops can reach a quick decision where there's need. An AN/I thread would be an appropriate venue.—S Marshall T/C 23:27, 11 September 2022 (UTC)Reply[reply]
    ...And, a block by an individual sysop with "email me for the evidence" is way, way, way out of line. If Arbcom became aware of that ever happening, I'd look to them for a prompt and summary desysopping of the blocker.—S Marshall T/C 23:37, 11 September 2022 (UTC)Reply[reply]
  • Support I think the problem of UPE is significant enough that additional tools are needed to combat it. I would support the idea of requiring more than one administrator to concur in the block, to prevent abuse. It seems pretty ridiculous that we can't use things like LinkedIn to identify bad-faith ors. Calliopejen1 (talk) 18:45, 14 September 2022 (UTC)Reply[reply]
    @Calliopejen1: We can, you just need to send it to a functionary or ArbCom for action, preferably via paid-en-wp@wikimedia.org. – Joe (talk) 07:06, 16 September 2022 (UTC)Reply[reply]
  • Oppose per Snow Rise. This is clearly outside the remit of admin. What is outside en.wiki should stay outside. We elect admins to clean things up in Wikipedia, not to run checks on people based on off-wiki information. In my opinion, attempts to connect real world identity to or name is a clear overreach of power and a blatant invasion of privacy. I could be a known criminal in my real life, but in the event I got investigated for my on-wiki conduct, my real life should not affect my on-wiki investigation. My off-wiki conduct should never "poison" any investigation on my on-wiki conduct.
And we are talking about non-public information that can't be shared. Yes, the information would be shared among admins. But who will guarantee that the information would not be kept securely? Who would guarantee that the admins would not spread the information off-wiki? Are all admins privy to the information? Will the information be destroyed after a certain time? Who would guarantee that the admin judging the case will be fair and unbiased with the evidence off-wiki?. Will some people with WP:UPE get away because of this? Absolutely. But protecting the privacy of many is more important than attempting to stop a small number of bad actors.Admins should not be doing "fishing expions" through Google to block someone. If the on-wiki evidence is not enough to "convict" someone, the or should not be blocked - just like real life. — Preceding unsigned comment added by SunDawn (talkcontribs) 12:23, 16 September 2022 (UTC)Reply[reply]
  • Oppose Personally I would strip the whole section out of the policy and refer all blocks related to off-wiki evidence to ArbCom/functionaries. It made sense in the mid-2000s but not now. --Rschen7754 05:15, 17 September 2022 (UTC)Reply[reply]
  • Oppose per SnowRise and others. This is highly inappropriate and, IMO, carries real risks of abuse. Blocks should occur for on-wiki actions due to on-wiki evidence. --SilverTiger12 (talk) 00:25, 18 September 2022 (UTC)Reply[reply]
  • 'Support' - administrators are already permitted to speedy delete pages and block users based on the deleted content. This means that they are trusted to take administrative action based on information visible only to admins. The only question is how to ensure that an admin who becomes unavailable can still make sure that other admins can still know the facts behind it. The use of informing ArbCom is intended to solve this problem, and informing them before they take action is to deal with the highly unlikely situation that an admin drops dead immediately after blocking. Animal lover |666| 17:40, 18 September 2022 (UTC)Reply[reply]
    Deleted pages or contents are not off-wiki evidence. Those are still available to all admins, as they are on-wiki. The problem with this new policy is that off-wiki evidence, such as Google searches or LinkedIn pages, that are only available to some admins, will be allowed to be used as an evidence against you. There is no debate about whether on-wiki evidence can be used or not, the debate is about off-wiki evidence. ✠ SunDawn ✠ (contact) 11:38, 19 September 2022 (UTC)Reply[reply]
  • Oppose per Rschen7754. Typically people digging around off-wiki is not a good thing, and on-wiki evidence for the block is substantially stronger. I understand the allure of private block evidence, but I don't think it is a direction we should head as a community. TonyBallioni (talk) 17:50, 18 September 2022 (UTC)Reply[reply]
    • Also, since this was asked by Kevin: my interpretation of the current policy is that blocks by administrators based on off-wiki evidence that cannot be reviewed on-wiki are prohibited in virtually all circumstances. I think Salvio giuliano and Thryduulf sum it up better than I could. My interpretation of the wording The community has rejected the idea of individual administrators acting on evidence that cannot be peer-reviewed is that it requires public peer-review unless a user is making a block in their capacity as a CheckUser or Oversighter. The historical reason for allowing private evidence ArbCom-only blocks had to deal with child protection. That's been handed over to T&S now. TonyBallioni (talk) 18:03, 18 September 2022 (UTC)Reply[reply]
  • Strong Oppose -- the community did not like the whole Fram affair, and whatever exactly happened is still unknown to us. This sounds many times worse. Also, it seems to fly in the face of due process. Can the accused access the evidence that the administrator is using to justify their action? While Wikipedia is not obligated to provide due process, it is, nonetheless, fundamental that everyone have their say and the right to defend themselves. I've seen and experienced how badly social media sites (such as Facebook and Twitter) fail at providing people an adequate defense to challenge blocks, I'd rather not see Wikipedia fall down that same path. --RockstoneSend me a message! 08:09, 19 September 2022 (UTC)Reply[reply]
  • Oppose. If a block must be done for non-public evidence, it should be by ArbCom, not as a standard admin action. Perhaps we could consider a process to make it easier to ask for such blocks from ArbCom or functionaries instead. Regards, User:TheDragonFire300. (Contact me | Contributions). 09:47, 22 September 2022 (UTC)Reply[reply]
  • Oppose, and I would urge Tamzin (and others doing the same) to cease making such blocks and to instead follow actual policy, even if that means some extra red tape or the occasional spammer not being blocked immediately. Continuing to make such blocks should be grounds for a desysop. If selective reading of policies seemed to condone such blocks based on off-wiki hunting, then the policy needs to be made clearer: but it looks as if the policy was clear enough already, and some admins just didn't read the whole policy, only the bits they wanted to see. Fram (talk) 10:31, 22 September 2022 (UTC)Reply[reply]
  • I've commented substantively in this RfC so I am clearly not uninvolved. But in reading over the discussion I think there is a consensus to be had. It's not consensus for what was proposed by Tamzin and L235 but there is a consensus none-the-less and I hope that whoever closes this discussion will note that consensus so relevant policy pages can be updated. Best, Barkeep49 (talk) 21:46, 22 September 2022 (UTC)Reply[reply]
    I agree with this reading of the discussion. Best, KevinL (aka L235 · t · c) 21:55, 22 September 2022 (UTC)Reply[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further s should be made to this discussion.

Speaker biographies on conference websites, is this source neutral and reliable?[]

Conference websites often publish biographies of their speakers, see an example. Usually, these biographies are provided by the speakers themselves. Can such sources be used for articles - biographies of living people? Are such sources neutral and reliable? Is this reflected in any of the policies? --Shvili1962 (talk) 10:53, 20 September 2022 (UTC)Reply[reply]

Neutral? No. Reliable and usable in articles? There is no single answer to that. Like all primary sources, they should be evaluated on a case by case basis. – Joe (talk) 11:55, 20 September 2022 (UTC)Reply[reply]
They are neither secondary nor independent of the subject, and so do not count towards GNG notability. They can be used as sources for non-controversial biographical details, though. JoelleJay (talk) 01:08, 21 September 2022 (UTC)Reply[reply]
I asked a similar question on WP:BLPN. I think your question can be rephrased: "Can any self-published or primary source", e.g web, author forward from book, interview, etc be used for a biography when the source material came directly from the biography subject. My read of the guidelines WP:BLP is that the answer is yes, but must be evaluated for authenticity. because subject's do exaggerate and/or make false claims. [[WP:BLP] stated: Primary and/or self-published sources may NOT be used "as sources of material about a living person, unless written or published by the subject of the article". Note the 'unless' clause. This would be common sense because a subject's early life, education and aspect's of their career can often only be sourced from primary source interviews and/or written material directly from the biography subject. Second, WP:BLPSELFPUB explicitly endorses using self-published material IF "it is not unduly self-serving...there is no reasonable doubt as to its authenticity; and the article is not based primarily on such sources".
Can others confirm or deny this interpretation of the WP:BLP guidelines? MarsTrombone (talk) 19:57, 22 September 2022 (UTC)Reply[reply]
This is a better question for the Teahouse. As others have said, it depends, but in general, non-controversial facts biographical facts such as official job title can come from a primary source. Pyrrho the Skipper (talk) 21:16, 22 September 2022 (UTC)Reply[reply]
Per the above, for noncontroversial, banal CV type information, such sources may sometimes be okay in case no other better sources exist which have the same information, then it can be okay. If better sources exist, use those. If better sources exist and contradict the information, then absolutely don't use it. If the information is controversial or likely to be, also find a better source. Ultimately, though, what you would need to do to get a better answer is "Can this source be used as a citation for this Wikipedia text" and then write the exact block of text you intend to write at Wikipedia with the exact source being used to verify it, and then you'll get a better answer. --Jayron32 17:29, 23 September 2022 (UTC)Reply[reply]
My experience with conferences is that the bios are submitted by the speaker themselves (or an assistant to them, etc.). Thus they should not be considered reliable. --Masem (t) 17:39, 23 September 2022 (UTC)Reply[reply]

Reports published by policy and research organisations, can they be considered generally reliable?[]

also posted at WikiProject Source MetaData since it’s relevant there too

I’m looking for opinions on institutional policy and research reports in general as reliable sources as part of the WikiProject Policy Reports project. The example source types on WP:RS (scholarship, news, vendor etc) don’t quite cover our area of interest: reports, conference papers, discussion and briefing papers, strategies, policies and other docs (sometimes called grey literature). These are generally self-published by organisations (e.g. the WHO publishes WHO reports) but it’s obviously not the same as someone’s self-published blog or book.

I realise that for specific citations in WP it’s case-by-case. However, we’re looking for some guidance on what principles or criteria we could use to prioritise/sort organisations into 1) Generally reliable / 2) unclear / 3) generally unreliable since these sorts of items are likely often useful as potential WP sources in addition to books/journals/newspapers. As part of the project we’re looking to prioritise which organisations’ reports are most useful to upload metadata to Wikidata about.

If general principles aren’t really possible, it’d be helpful to have some examples to calibrate on e.g. these five organisations:

Thanks in advance for the feedback on these! We’ve >70 publishing organisations that we’re focusing on so these will help us calibrate which sorts of organisations are worth focusing on uploading metadata to Wikidata. If anyone has an interest in the full list, please let me know and I can loop you in on the full project. Brigid vW (talk) 06:52, 28 September 2022 (UTC)Reply[reply]

First, please define "generally reliable". Detailed feedback maybe given following your definition. 172.254.222.178 (talk) 12:12, 28 September 2022 (UTC)Reply[reply]
WP:GREL as defined by the WP:RSP Brigid vW (talk) 23:09, 28 September 2022 (UTC)Reply[reply]
@172.254.222.178 Sorry, thats: WP:GREL and WP:RSP Brigid vW (talk) 23:15, 28 September 2022 (UTC)Reply[reply]

Question is very broad but I think WP:RSN is anyway where you want to ask this question (some of your 70 may been discussed before, you can feed them into the search box at WP:RSP to see). Selfstudier (talk) 12:39, 28 September 2022 (UTC)Reply[reply]

@Selfstudier we are searching for all proposed organisations on the WP:RSN and WP:RSP before putting them forward. There is already one Australian Strategic Policy Institute that has been allocated WP:MREL.
@Blueboar So it's possible we could allocated a WP:MREL where attribution is required? Brigid vW (talk) 23:14, 28 September 2022 (UTC)Reply[reply]

FYI I've asked a similar question at Wikipedia talk:Tiers of reliability#Grey literature. Levivich (talk) 18:10, 28 September 2022 (UTC)Reply[reply]

Great thank you. Brigid vW (talk) 23:04, 28 September 2022 (UTC)Reply[reply]

IMO "Generally reliable" is an over generalization that should be eliminated. But on average, I would consider those to be more reliable than an average wp:rs. North8000 (talk) 18:27, 28 September 2022 (UTC)Reply[reply]

I think it depends on the particular publisher. For example, Australian Strategic Policy Institute, Cato Institute, Center for Economic and Policy Research, and Middle East Media Research Institute are all yellow at WP:RSP; Victims of Communism Memorial Foundation is pink (hehe); Poynter Institute's International Fact-Checking Network is green (WP:IFCN). Levivich (talk) 18:46, 28 September 2022 (UTC)Reply[reply]
If the OP list of examples is an indication, there are obvious issues. Any advocacy organization is by definition exclusionary, and its publications may be prudently a priori viewed as such. No amount of outside auditing of any kind can alter the fact that such entities are expressly formed to advance certain positions, and are correspondingly biased towards these positions, which may result in directed research, massaged statistics, and narrow-focus, unrepresentative studies. Strictly technical entities such as statistics agencies that collate data and offer multiple options of presenting such data without interpretation of any kind, may only be technically unreliable (i.e. there may be erroneous or outdated statistical processes employed). Such technical unreliability can often be exposed by outside auditors either official or unofficial (including journalists, interested researchers, and other parties). Government reports have multiple problems of their own. Depending on the issue they may be advancing or justifying the parent government's positions, even when published by so-called "independent" agencies and/or career bureaucrats. "Independent" is not a synonym of reliable. And career bias is a real thing, behind every report are real people whose job/career may be affected by it. 65.88.88.91 (talk) 19:50, 28 September 2022 (UTC)Reply[reply]
@65.88.88.91 Ok so advocacy organisations are definitely out. There are some cases where Australian Council of Social Service (ACOSS) has engaged university researchers to produce reports. This is one example. Would we rule out those as well?
I've tried to provide 5 different types of organisations above to test out different scenarios. The Australia Institute being a research institute with a progressive leaning, Australian Institute of Health and Welfare a government funded research institute, Ministry of Business, Innovation and Employment a government department, and Lowitja Institute a First Peoples research institute (with funding from Government). Brigid vW (talk) 23:32, 28 September 2022 (UTC)Reply[reply]
I went through the examples you provided, and the repository, in some depth. The previous comments were mostly a caveat against putting too much emphasis on the vague term "generally reliable". Imo it is a fuzzy concept, both 1. literally, the criteria used are basically subjective or opaque and 2. mathematically, a non-biased (statistically speaking) probability distribution of expected reliability cannot be determined from data based on the criteria. But the comments were not meant to summarily & ideologically label everything as unreliable, just that imo it is prudent policy, for the purposes of this encyclopedia, to approach sources as unreliable until proven otherwise, on a case-by-case basis. One may bring examples of proven past reliability, which is a descriptive, not predictive quality. Whether this is material in categorizing your various sources is not something that can be decided here, in my opinion. 65.88.88.69 (talk) 19:51, 29 September 2022 (UTC)Reply[reply]
It is looking like the reports we upload in to Wikidata will need to be assessed on a case-by-case basis if used. So we'll be aiming to ensure the reports meet the WP:MREL criteria which will always require in-text attribution. And we'll only be selecting organisations that are either government or academic or established research institutes that are producing research reports (or policy documents in the case of government). Brigid vW (talk) 21:57, 30 September 2022 (UTC)Reply[reply]
Your candor and willingness to apply fact-based principles is refreshing. Best wishes. 69.203.140.37 (talk) 00:46, 1 October 2022 (UTC)Reply[reply]

Is one of the policies here “make an account or get blocked”?[]

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further s should be made to this discussion.


User talk:Jeff G. wants to ban me for “refusing an account”. Is this a policy here? I’m not sure… 2001:8003:B1B8:BF00:9541:78E9:CB4:9EE4 (talk) 10:30, 29 September 2022 (UTC)Reply[reply]

I think the OP is talking about this ANI (Wikipedia:Administrators'_noticeboard/Incidents#2001:8003:b1b8:bf00::/64) - X201 (talk) 10:35, 29 September 2022 (UTC)Reply[reply]
Please keep this discussion in one place on AN/I, where this question has already been raised. CMD (talk) 10:39, 29 September 2022 (UTC)Reply[reply]
The ANI discussion has been closed, and since no one has answered the question: No, you will not be banned for refusing to have an account. While we encourage you to open one, we do not require it. Blueboar (talk) 11:45, 29 September 2022 (UTC)Reply[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further s should be made to this discussion.

WP:V and foreign-language terms, non-Latin orthography in enwiki articles[]

How strictly should WP:V and WP:RS be observed for foreign-language phrases, non-Latin scripts, and transliterations?

Therefore, I have been placing {{citation needed}} in lede paragraphs where I was unable to verify foreign-language names. This has been disputed, so what is the way forward here? Elizium23 (talk) 19:19, 29 September 2022 (UTC)Reply[reply]

Page Nominated for AFD, Then Moved to Draft Space[]

I have asked this question before and will ask it again. A page is in article space (mainspace) and is nominated for deletion. The author of the page moves the page to draft space. The AFD template on the page then displays an error message saying that the template is being used in the wrong namespace, and tells how to nominate the page for MFD. The error isn't use of the wrong XFD template, but a move after nomination, but that isn't the real question. What is the status of the page, and of the AFD? The AFD is still listed in the deletion sorting lists. Does the move to draft space turn off the AFD? If moving an article to draft space after AFD is a standard procedure, does a COI or or an ultra get one free trip into article space to see if their article stays there? Robert McClenon (talk) 14:42, 30 September 2022 (UTC)Reply[reply]

I don't work AfD much any more, but when I was a regular, the rule was that you shouldn't move/rename an article while an AfD is live. It just makes everything confusing. If you think it should be moved to draft, say so in the AfD and that'll be one of the options people can consider. -- RoySmith (talk) 15:00, 30 September 2022 (UTC)Reply[reply]
Yeah moving to Draft before the AfD closes is a bad idea, for a number of reasons, including templates getting messed up as described. -- GreenC 15:07, 30 September 2022 (UTC)Reply[reply]
Maybe I wasn't clear as to what I was asking or why. I agree that it's undesirable. What if anything should be done or is done about it or to prevent it? User:RoySmith says that

the rule was that you shouldn't move/rename an article while an AfD is live

. Where is the rule stated, and how is the rule enforced? It is not uncommon for the originator of a questionable article to move it to draft space in order to stop the AFD. (This may be an or who was previously pushing the page from draft space to article space.) What should be done about the move? Robert McClenon (talk) 20:09, 30 September 2022 (UTC)Reply[reply]
I previously proposed that the AFD template should be modified to say not to move the article while the AFD is in progress. I got pushback, saying that sometimes it may be necessary to rename the article before the AFD is completed. The MFD template says not to move the page that is nominated for deletion, but MFD is a different, although related, process. Robert McClenon (talk) 20:09, 30 September 2022 (UTC)Reply[reply]
Rename in mainspace is sometimes useful IMO but moving namespace if entirely different. That's a defacto deletion. -- GreenC 21:35, 30 September 2022 (UTC)Reply[reply]
User:GreenC - Moving an article to draftspace during AFD is done as an endrun around the deletion process by the author of the article, who is either a COI or or an ultra. Robert McClenon (talk) 05:54, 2 October 2022 (UTC)Reply[reply]
The COI moves to Draft to avoid the tarnish of a AfD, only to get it moved from Draft back into mainspace without a record of a Deletion. Seems like gamesmanship. =-- GreenC 15:29, 2 October 2022 (UTC)Reply[reply]
My own opinion, and I may be in a minority, is that we should either prohibit moving the article while the AFD is in progress, or specify what the effect of a move is on an AFD. Maybe other ors would prefer not to specify because they think that moving the article is a variety of bean to abuse. Robert McClenon (talk) 20:09, 30 September 2022 (UTC)Reply[reply]
Like so many rules, it's part "rule", part "culture". In any case, WP:AFDEQ says, While there is no prohibition against moving an article while an AfD or deletion review discussion is in progress, ors considering doing so should realize such a move can confuse the discussion greatly, can preempt a closing decision, can make the discussion difficult to track, and can lead to inconsistencies when using semi-automated closing scripts. I read that as, "I'm not saying you can't do that, but please don't do that". -- RoySmith (talk) 20:29, 30 September 2022 (UTC)Reply[reply]
The problem with the language in WP:AFDEQ that is cited by RoySmith is that it is addressed to good-faith ors about a problem involving bad-faith ors. Saying "please don't do that" isn't effective with users who are being stubborn, and they are the problem. Robert McClenon (talk) 05:54, 2 October 2022 (UTC)Reply[reply]
I agree with Graeme. Continue the AFD discussion, with a note saying that the page has been moved to Draftspace. What happens next depends on the outcome of the AFD discussion.
This is what I meant by being flexible and applying NOTBUREAUCRACY. It does not matter which “space” a problematic article is located in… nor does it matter which process (AFD or MFD) is used to discuss it… what matters is reaching a consensus as to what to do about the problematic article. That discussion can continue wherever the article is located. Blueboar (talk) 12:28, 2 October 2022 (UTC)Reply[reply]

Increasing Use of Draftification[]

I think that User:BD2412 is identifying a different issue that is not directly related to the issue that I raised, but is a valid issue, and that is that closers should be instructed to consider whether draftification is a proper close. It probably is a proper close if the main issue is that the subject is too soon. This doesn't have anything that I am aware of to do with moving an article to draft during an AFD. Robert McClenon (talk) 05:54, 2 October 2022 (UTC)Reply[reply]

Discussion about soft redirects to sister projects[]

Please see Wikipedia talk:Wikimedia sister projects#Soft redirects to sister projects which needs input from additional ors. Thryduulf (talk) 12:41, 1 October 2022 (UTC)Reply[reply]

WP:proportion and terminology[]

Some terms used in a title of an article receive different definitions by different sources, but yet there is no fundamental disagreement between the sources, because there is an easy translation from one source to the other. For example, traditionally in science, "heat" was often used to mean the internal energy of the medium responsible for its temperature or, depending on the context, it could also traditionally mean the amount of energy transferred that cannot be explained by macroscopic work. More recently, a tendency can be observed to only use "heat" with the second meaning, but it's not universally adopted. For example, Nobel laureate Steven Weinberg is not strict about the use of the term "heat" in his recent 2021 book The foundations of Modern Physics, that is, he adopts the traditional approach in science. However, again, this is very superficial. I suspect Weinberg himself would find this issue completely unimportant, as long as it's clear what the term "heat" means in each context. I mention this, because then it does not seem appropriate to insist that both terminological approaches are presented in respect of WP:proportion, say in the article Heat, because, if we start to do that, then we start to discuss an issue that is not even discussed in the literature, because it's not important. Therefore, it should be acceptable in Wikipedia to agree among ors for a particular terminological approach and simply adopt it, even though it's not the unique approach used in the literature, that is, we can ignore WP:proportion for these terminological issues. Dominic Mayers (talk) 18:14, 3 October 2022 (UTC)Reply[reply]

@Dominic Mayers, this is not a Wikipedia level policy consideration. If you want a wider view than you are getting at Talk:Heat raise the issue at Wikipedia talk:WikiProject Physics. StarryGrandma (talk) 00:02, 4 October 2022 (UTC)Reply[reply]
I asked the question here, because I don't think the issue is specific to heat or even to physics. It's a very general fact that a word in a title can have different meanings (i.e., be given different definitions) in different sources, but it's nothing very deep, not as if it corresponds to different points of view : it's only a superficial change in definitions and one can easily translate from one source to another. They say the same thing in different languages. Still, in these cases, one definition for the term has to be used and ors can have to decide among them. It's a general policy consideration. In particular, I do not think that WP:proportion is a consideration in these cases. The specific definition attributed to the term should be chosen on the basis of other considerations, such as how easy it is for a general audience to understand the definition. However, of course, you are right if you meant to say that the specific case Heat can not be resolved here. I do not hope to resolve the Heat case here. That's not the goal. No, the goal here is only to consider whether or not, in general, WP:proportion is a strict criterion to apply in these cases. This would not resolve the specific case Heat, but it will be helpful in the process and not only for the Heat case. Dominic Mayers (talk) 01:00, 4 October 2022 (UTC)Reply[reply]

Article creation at scale RfC[]

Wikipedia:Arbitration Committee/Requests for comment/Article creation at scale Valereee (talk) 13:59, 4 October 2022 (UTC)Reply[reply]

Technical[]

Extracting WikiProjects on a talk page using template/module[]

I was wondering if there is a way to extract out the names of the WikiProjects used on a given talk page, for example Talk: United States, such that when the particular template/module is used, it will create an array United States; Countries; North America; United States Government. It would be very helpful if there is a way to do just that. Thanks! CX Zoom[he/him] (let's talk • {CX}) 22:17, 25 September 2022 (UTC)Reply[reply]

Why? Izno (talk) 22:44, 25 September 2022 (UTC)Reply[reply]
Given the huge backlog of COI requests, I figured out that topic-wise categorisation (inbuilt from {{ request}}) might be more helpful than a list all category. It helps in finding the requests that you might be more interested in reviewing because you primarily work in that area, potentially reducing the backlog. If template/module cannot do it, alternatively, I may have to file a bot request. CX Zoom[he/him] (let's talk • {CX}) 07:11, 26 September 2022 (UTC)Reply[reply]
Would a PetScan to intersect Category:Wikipedia conflict of interest requests and Category:WikiProject United States articles work for your use case? —⁠andrybak (talk) 11:05, 26 September 2022 (UTC)Reply[reply]
@Andrybak: Looks like it could work but I'm having troubles with it. Anything I search shows 0 results even though it should not. Maybe I'm putting in the wrong input. Can you please give an example input? Thanks! CX Zoom[he/him] (let's talk • {CX}) 12:27, 26 September 2022 (UTC)Reply[reply]
Here you go. Most likely you weren't setting the namespace in the Page Properties tab; by default, it'll only show pages in the main namespace, and you want Talk: instead for both of those categories. —Cryptic 13:10, 26 September 2022 (UTC)Reply[reply]
Thank you very much. CX Zoom[he/him] (let's talk • {CX}) 13:21, 26 September 2022 (UTC)Reply[reply]
@Hellknowz, is this something you could add to Wikipedia:Article alerts? WhatamIdoing (talk) 17:02, 26 September 2022 (UTC)Reply[reply]
@WhatamIdoing: In theory. The problem is that the bot can only do 1 workflow per page. The first page I clicked for an example had like 5 of them. I see many have multiple. The bot won't recognize that a page has 2+ different requests - it will list only one of them, pick one of the dates/authors and won't close or update it until all requests are done. Basically, as long as the page is in the COI request category. So it will basically show incorrect values for those cases (although it will still report them). There's no easy way for me to work around this (other than to hide the values, but then that will make the entries undated). Also, a bigger question is the scope of bot reports. Are COI requests more important than the thousands of regular ones? In theory, the bot can just have an request section for each project, including COI reports, which would be ideal. But that still leaves the problem of multiple requests. —  HELLKNOWZ  TALK 17:20, 26 September 2022 (UTC)Reply[reply]
For myself, I'd rather see all the pages with an open request, not just the COI ones. One per page is probably enough, because (a) if you're on the page anyway, you can see what other requests are there and (b) even if you don't, if you close that one, then tomorrow the bot will presumably notice and report the next one on the page.
If it could be coded in five minutes or less, I'd also rather not see extremely recent requests (say, less than 12–24 hours old), because that would give the regular patrollers a chance to remove empty/accidental requests. This should improve the signal-to-noise ratio for Article Alerts. WhatamIdoing (talk) 00:39, 28 September 2022 (UTC)Reply[reply]
"if you close that one, then tomorrow the bot will presumably notice and report the next one on the page." That's the problem - the bot won't notice that anything has changed because the page will still be in the same category. It will continue reporting the first request until every request is closed. It will continue reporting the date, the author and the section link of the old request. Even after all are closed, it will still only list the page as if it had one request during that time and was closed when the last request was closed. If a new request is added soon, the bot will think the old request was reopened.
"If it could be coded in five minutes or less, I'd also rather not see extremely recent requests" Unfortunately, this would take way longer to implement than that. Without going into technicals, everything assumes that "active means active" and I cannot filter entries like that without breaking things. And yeah, knowing how many empty and useless request I've seen that need no action expect be closed, I can see how early reports like this would be a problem. —  HELLKNOWZ  TALK 10:06, 28 September 2022 (UTC)Reply[reply]
Avoiding the new ones has some obvious benefits to "me" (=whoever is reading the AAlerts page) and some not-so-obvious costs, like an inaccurate perception of reality. This is why I suggest that "my" convenience be factored in if the cost to you for doing so were very small.
As for the other problem, it sounds like it's a bug that can be addressed in documentation. Instead of "Edit requests", it should say "Edit requests – due to technical limitations, only one is shown per page. If the linked section is closed, check for other open requests on the page". You could alternatively address it by linking only to the whole page, with no section/date information. Then it would always be correct. WhatamIdoing (talk) 15:57, 29 September 2022 (UTC)Reply[reply]

Re: Pushpin map of the world's FAs (discussion from March)[]

Map of Featured Articles with locations

Hello, a little update to everyone involved in the discussion "Pushpin map of the world's FAs" from March, @Sdkb, Jéské Couriano, Pppery, The wub, Donald Albury, NguoiDungKhongDinhDanh, TheDJ, Agathoclea, Whatamidoing (WMF)):

As of yesterday, it is possible to use geopoints from Wikidata in Kartographer maps, via QID or SPARQL query. -- Best, Johanna Strodt (WMDE) (talk) 10:09, 27 September 2022 (UTC)Reply[reply]

How cool, thanks very much Johanna! And please pass on my thanks to those who worked on this improvement, I'm sure it will be useful for a lot of other applications. Only just saw this as I didn't get a notification about your message for some reason. I had a go at making a map for the featured articles, pinging Sdkb as the person who originally requested it. the wub "?!" 23:25, 2 October 2022 (UTC)Reply[reply]
Amazing; thanks so much! I'm going to go ahead and add it to WP:FA. A future improvement might be to color-code the icons by type. {{u|Sdkb}}talk 22:38, 3 October 2022 (UTC)Reply[reply]
Thanks for your replies. I've passed the feedback on to our team. -- Best, Johanna Strodt (WMDE) (talk) 08:41, 4 October 2022 (UTC)Reply[reply]

Dumber search?[]

When I search for the word "alarmism" [3], I get hits for "alarm", which is not what I want. I know what I want and I try to tell the search algorithm what I want, but it thinks it is smarter than me and knows better. If I try to exclude "alarm", I get no hits, probably because that also excludes "alarmism".

Is there a way to stop the search algorithm from dunning-krugering like that? --Hob Gadling (talk) 15:57, 27 September 2022 (UTC)Reply[reply]

You can try something like Special:Search/Alarmism insource:/alarmism/. Add i to the end if you also want to include Alarmism, etc. Certes (talk) 16:08, 27 September 2022 (UTC)Reply[reply]
@Hob Gadling: It's better to use quotation marks like you did in the post but not the search. insource:/.../ is called a regex search. It's expensive and may not have time to search all pages. It helps if you combine it with a normal search like alarmism insource:/alarmism/ but for this purpose, you can just use "alarmism". See more at Help:Searching. PrimeHunter (talk) 16:12, 27 September 2022 (UTC)Reply[reply]
Ah! Thank you both! I did not think of Help:Searching or of quotation marks. --Hob Gadling (talk) 16:22, 27 September 2022 (UTC)Reply[reply]
This may be a goofy question, but: Why does WP return results that don't include the searched-for term (especially if the term is in quotes—which, on most search engines, indicates it's mandatory)? If that happened to me, I'd assume no pages existed with the searched-for term, but the search feature was trying to be helpful. – AndyFielding (talk) 01:03, 28 September 2022 (UTC)Reply[reply]
@AndyFielding: Help:Searching#Stem matching says: "Search results will include the roots of words included in the search string, and their various tenses (plural, past-tense, etc.). If stem matching is not wanted, use double quotes around the word or phrase you want to match verbatim." Do you have an example where a search term in quotes returns results without the term? PrimeHunter (talk) 01:15, 28 September 2022 (UTC)Reply[reply]

It's interesting to me that insource has been shown in examples, but what it does has not actually been mentioned, and it's pretty critical to know whether or not it's appropriate. IMO, the first thing you should consider is whether you want to search the page source or the rendered text. The default is the rendered text. Use insource: only if you want to search the page source. Also, it seems that Wikipedia search treats the content as a series of words, and delimiters (the characters that separate words) are not considered, e.g. unless you're using a regex search, search terms "foo/bar" and "foo+bar" will return identical results. Keep in mind also that Wikipedia search isn't google search, it's not going to guess at what you might really have wanted. Fabrickator (talk) 01:50, 28 September 2022 (UTC)Reply[reply]

AndyFieldingCertes only suggested alarmism insource:/alarmism/ as a way to get an exact match (quotes is a better way here). A regex search insource:/.../ cannot be used on the rendered result. By the way, insource:/alarmism/ doesn't find Alarmism while "alarmism" does find it. Add i like insource:/alarmism/i for a case insensitive regex search. It goes from 97 to 134 results. "alarmism" gives 129 results. The five "missing" pages can be seen with alarmism insource:/alarmism/i -"alarmism". Three only has "alarmism" in the source and two say "Alarmism's" which is treated as one word and not found by "alarmism". PrimeHunter (talk) 02:25, 28 September 2022 (UTC)Reply[reply]
Quoted text probably gives what you need here and is much more efficient than my original suggestion of insource:. There is more help at mw:Help:CirrusSearch, and an explanation of the very limited and non-standard regular expression syntax here. Certes (talk) 08:36, 28 September 2022 (UTC)Reply[reply]
Thanks for your thoughtful explanations. I may have misinterpreted the OP's post, thinking his quotation marks were literal. (Discussing search strings, perhaps italics would've been a better idea—or putting the search terms on their own indented lines?) – AndyFielding (talk) 12:35, 2 October 2022 (UTC)Reply[reply]

Template:Television network original programming category puts cats inside themselves[]

Gonnym (talk · contribs) isn't around much these days, so I'm asking here. Under certain circumstances, {{Television network original programming category}} puts categories inside themselves unless it's configured properly; twice in the past Gonnym has fixed up such problems as requested at User talk:Gonnym/Archive 3#Template:Television network original programming category, User talk:Gonnym/Archive 4#Television network original programming category and User talk:Gonnym/Archive 4#Zee Marathi Original Programming, but didn't explain what actualy needed doing (there is an expln of sorts on the last one, but it's not at all clear). Now Category:Fox Kids is suffering the same problem: it's inside itself (reported at Wikipedia:Database reports/Self-categorized categories). Does anybody know what needs doing to the template in order fix the cat? --Redrose64 🌹 (talk) 20:34, 28 September 2022 (UTC)Reply[reply]

I have added |no_cat=1.[4] PrimeHunter (talk) 20:45, 28 September 2022 (UTC)Reply[reply]
I have also made a more general solution which automatically omits adding a category to itself.[5] PrimeHunter (talk) 21:05, 28 September 2022 (UTC)Reply[reply]
In general, if you want to prevent a template from categorizing pages, try |no_cat=1 before asking for help. This frequently will solve the problem. Animal lover |666| 08:04, 29 September 2022 (UTC)Reply[reply]
The param is mentioned in the templatedata, but is otherwise undocumented. The impression that I got was that it concerned parent cats, which I wanted left alone. --Redrose64 🌹 (talk) 08:29, 29 September 2022 (UTC)Reply[reply]
It does concern a parent cat. Adding the cat itself (usually unintentionally) is a special case of a parent cat. no_cat is a non-standard parameter name only used in this template. nocat is the common name recommended at Wikipedia:Category suppression. Category suppression usually suppresses all parent categories but in {{Television network original programming category}} it only suppresses one of two. That is confusing when it's undocumented. PrimeHunter (talk) 20:14, 29 September 2022 (UTC)Reply[reply]
I have changed the non-standard no_cat to nocat in the template [6] and the six calls which used it. PrimeHunter (talk) 13:26, 30 September 2022 (UTC)Reply[reply]

Check if all transclusions of a specific template are done via an other specific template[]

I would like to check if all transclusions of several templates (such as Template:Ethnologue25) are done via Template:Infobox language/ref, and if this template (except on the template's own documentation) is only called via Template:Infobox language. Note that I'm talking about the actual specific transclusions, not just appearance on the same page. Is there any way to do this? Animal lover |666| 07:59, 29 September 2022 (UTC)Reply[reply]

@Animal lover 666: hastemplate:"Ethnologue25" -hastemplate:"Infobox language/ref" finds four articles which transclude {{Ethnologue25}} without transcluding {{Infobox language/ref}}. The search is based on the whole page so there may be other pages which transclude both in different places without one of them calling the other. I don't think there is a general way to search for that. For specific cases there may be ways by searching the source for how the templates are used. For example, hastemplate:"Ethnologue25" insource:Ethnologue25 finds three articles which call {{Ethnologue25}} in their own source. There could be other cases where {{Ethnologue25}} is called via a template but not via {{Infobox language/ref}}. But insource:Ethnologue25 in template space only finds {{Infobox language/ref}} and a non-transclusion link in {{Ethnolink/doc}}. hastemplate:"Ethnologue25" only finds 23 articles in total so they could also be examined manually with some work. PrimeHunter (talk) 14:29, 29 September 2022 (UTC)Reply[reply]

Preference "Expand watchlist to show all changes, not just the most recent" doesn't seem to work[]

I've always had "Expand watchlist to show all changes, not just the most recent" enabled, but suddenly (probably because it's WP:THURSDAY?), changes are grouped anyway. I've tried disabling and re-enabling the preference, but I see no difference in my watchlist one way or the other. I'm using Chrome 105.0.5195.127 on Windows 10. --rchard2scout (talk) 13:22, 29 September 2022 (UTC)Reply[reply]

Block[]

For the last two-three days, I have been blocked and then unblocked. I have done nothing wrong. Any help and suggestions would be appreciated. This has happen several times in the past. Thank You-RFD (talk) 20:59, 29 September 2022 (UTC)Reply[reply]

What is the message that appears when this happens?(you may leave off any IP that appears) It's not your account(which has never been blocked). 331dot (talk) 21:11, 29 September 2022 (UTC)Reply[reply]
There's actually no need to answer that. RFD: I'm going to grant you block exemption, as I did before, which should allow you to whenever. This time it'll be good for the next two years. -- zzuuzz (talk) 21:26, 29 September 2022 (UTC)Reply[reply]
Thank You-RFD (talk) 21:27, 29 September 2022 (UTC)Reply[reply]

Chinese Wikipedia[]

I cannot log on to Chinese Wikipedia, help please? Taiwanrailtransportfan (talk) 23:50, 29 September 2022 (UTC)Reply[reply]

What goes wrong? Can you view pages at zh:? PrimeHunter (talk) 00:04, 30 September 2022 (UTC)Reply[reply]
Yes, but not logged in. The problem is if I want to with my account there - it's not possible now, since I can't log in. Taiwanrailtransportfan (talk) 00:06, 30 September 2022 (UTC)Reply[reply]
But what happens when you try to log in? "I cannot" and "it's not possible" are very vague. PrimeHunter (talk) 00:15, 30 September 2022 (UTC)Reply[reply]
The action gets cancelled, according to Chinese Wikipedia, as a "precaution against session hijacking." Taiwanrailtransportfan (talk) 00:20, 30 September 2022 (UTC)Reply[reply]
Try reloading a zh: page with Ctrl+F5. Try logging out here first. If it doesn't work, try another browser or device if possible. If that works but you want to use your current device and browser, try deleting cookies for wikipedia.org and wikimedia.org. PrimeHunter (talk) 00:37, 30 September 2022 (UTC)Reply[reply]
I'm browsing in guest mode, so I don't think I have cookies in the first place. Is there a possible way to log in? Is my username an issue? Taiwanrailtransportfan (talk) 22:15, 30 September 2022 (UTC)Reply[reply]
@Taiwanrailtransportfan you are not able to create an account at zhwiki because of your username. I can't give you any more details then that. Perhaps there is a part of your username that may be problematic on zhwiki. You can request a username change at Special:GlobalRenameRequest. I don't know of ways for you to contact the zhwiki admins by email, but that could also be an option. — xaosflux Talk 22:23, 30 September 2022 (UTC)Reply[reply]
@Xaosflux: Are you sure of that? It would be an odd error message for that. I can create (didn't save it) the user page zh:User:Taiwanrailtransportfan but not the article zh:Taiwanrailtransportfan. zh:MediaWiki:Titleblacklist says (?!User:|User talk:).*(Taiwan).* <autoconfirmed> This disallows the page name Taiwanrailtransportfan but only outside userspace. zh:Special:Listusers/Taiwan shows many usernames with "Taiwan", also from 2022. PrimeHunter (talk) 23:22, 30 September 2022 (UTC)Reply[reply]
@PrimeHunter yes I am, the condition that would have precluded this has been around for about 5 months. — xaosflux Talk 23:32, 30 September 2022 (UTC)Reply[reply]
As far as the error message goes, perhaps there is some translation messed up somewhere, it appears that it should have a fairly generic denial message. — xaosflux Talk 23:36, 30 September 2022 (UTC)Reply[reply]
@Xaosflux: Thanks for the explanation. The 2022 usernames are from January to April. PrimeHunter (talk) 23:39, 30 September 2022 (UTC)Reply[reply]

Template:Code and Too many expensive function calls[]

Comparison of programming languages (basic instructions) is in Category:Pages with script errors. Searching the article shows that "Lua error: too many expensive function calls" occurs twice. However, that is misleading because preview reports "Expensive parser function count 683/500" so there is a big problem. It turns out that {{code}} is used 671 times and each call uses one expensive function due to use of syntaxhighlight (and there are 8 direct calls to syntaxhighlight). Assuming that the article is kept at its current size, are there any suggestions for a simple replacement for {{code}}? An example with a simple argument is:

That could be replaced with

The nowiki is not needed in this case but my guess is that lots of the more complex examples would need it and making a manual choice 671 times would not be desirable. Is there anything better? Johnuniq (talk) 04:54, 30 September 2022 (UTC)Reply[reply]

Can we teach {{code}} to not invoke <syntaxhighlight> if lang=text (probably this should be done on the MediaWiki side too)? Also the last few comments on T316858 are relevant here. Legoktm (talk) 05:12, 30 September 2022 (UTC)Reply[reply]
@Legoktm, I've hastily done this with {{Code/sandbox}}— Qwerfjkltalk 10:16, 30 September 2022 (UTC)Reply[reply]

Expensive parser functions[]

C Sharp syntax has had this problem since yesterday. It has not been ed in months so something else must have changed. It uses {{C sharp}} a lot, but that hasn't changed either. MB 16:30, 2 October 2022 (UTC)Reply[reply]

This is phab:T316858/#Template:Code and Too many expensive function calls; <syntaxhighlight>...</syntaxhighlight> is now expensive. * Pppery * it has begun... 16:33, 2 October 2022 (UTC)Reply[reply]

And now Comparison of programming languages (basic instructions). Johnuniq (talk) 05:47, 3 October 2022 (UTC)Reply[reply]

Page moves without moving archives[]

In the past 3-4 months, I encountered 2 instances of page moves without moving talk page archives. And had to do that myself. In the older case, it took less than a day to find it out, in the latter case, it took over a month, and lowercase sigmabot had already created brand new archives at new title. I wonder how prevalent it is and what can be done to prevent it. Note that move subpages option is available only to page movers and administrators because of its disruption potential. CX Zoom[he/him] (let's talk • {CX}) 14:18, 30 September 2022 (UTC)Reply[reply]

Previously the archiving would have stopped after the move because the archive parameter no longer pointed to a subpage per User:MiszaBot/config#Parameters explained. If movers forget to move old archives then they usually also forget to update archive. Since July Aidan9382-Bot by Aidan9382 has automatically updated the parameter [7] without checking for old archives. The archive issue is mentioned in Category:Pages where archive parameter is not a subpage where the bot finds the pages but it wasn't brought up in Wikipedia:Bots/Requests for approval/Aidan9382-Bot 2. Maybe the bot should check for archives under the old archive value and do something else like flag it for or attention. It probably shouldn't move archives automatically. A counter (the current archive number) above 1 is also a strong hint that there may be archives somewhere. PrimeHunter (talk) 20:38, 30 September 2022 (UTC)Reply[reply]
@PrimeHunter: Thanks for the notice, I'd be glad to make this a feature of the bot. Question is, how do you suggest implementing this? Currently, my bot has a safety feature where if it 1) Can't find existing archives (Specifically archives 1 and archives counter) and 2) Notices the page already has some other subpage, it'll refuse to fix it and leaves a notice for another person (usually me) to clear it up manually. This was so it would never try to do anything as wild as this spectacular fail. Perhaps removing the second check and just having the first one would create a check like you suggested. Would that work for you? Aidan9382 (talk) 04:46, 1 October 2022 (UTC)Reply[reply]
@PrimeHunter: Thanks. I was wondering if it would help if a bot could compile a list of talk page subpages whose parent page is a redirect. But that has it's own limitations, it would leave out pages like this one (3rd example) which was a wrongly created talk page because one of the mover moved the article without talk page, and thus the actual talk page became orphaned. CX Zoom[he/him] (let's talk • {CX}) 08:15, 1 October 2022 (UTC)Reply[reply]
@Aidan9382: It sounds like you check more than I thought. Does "Can't find existing archives" and "page already has some other subpage" refer to the wrong archive value or the current page name? Why did the bot make the I linked [8] when there was an archive at Talk:List of rivers by length/Archive 1? CX Zoom moved the archive later and posted here. PrimeHunter (talk) 13:41, 1 October 2022 (UTC)Reply[reply]
@PrimeHunter: Let me elaborate - the bot checks the current location of the page for any existing archive subpage, not any previous name of the page due to reasons. My proposed idea is that I could have it so the bot wouldn't fix an archive if it found no existing subpages, which would imply they either havent moved over yet or dont exist, which would fix your issue here and allow a human to check it instead. Sorry if my explenation was a little poor. Aidan9382 (talk) 14:12, 1 October 2022 (UTC)Reply[reply]
@Aidan9382: If you don't want to check for archives at the wrong archive and are willing to examine the extra cases manually then that sounds OK. PrimeHunter (talk) 14:28, 1 October 2022 (UTC)Reply[reply]
@PrimeHunter: Dont worry, I used to do it manually before hand - its the whole reason I made the bot after a while. Anyways, the change is now  Done, so I'll see how this goes over the next few days. Thanks for bringing this to my attention. Aidan9382 (talk) 14:34, 1 October 2022 (UTC)Reply[reply]
@Aidan9382: Thanks. And thanks for working on Category:Pages where archive parameter is not a subpage. I made the category and automatic population [9] but only fixed a few pages. There were originally more than 2700. PrimeHunter (talk) 15:15, 1 October 2022 (UTC)Reply[reply]

ing glitch which moves cursor, disallows my use of capital letters[]

"II())NWhen I am ing in Wikipedia sometimes, nowadays, it seems I am allowed to use capital letters some of the time, as here where I have used "When" and "I". But some of the time, even within the same where I have successfully used some capital letters, I am disallowed: when I type a capital letter the cursor is moved to the beginning of the of the posting. I think this may occur only when I open a new discussion section on a Talk page, as here, by selecting the "+" option, which brings me into some kind of source mode with "Source" highlighted (rather than showing "Visual" highlighted). But it is different than regular source mode in that a--my posting will end by selecting "Add topic" and b--a continuously updated preview shows below. As opposed to if I am adding (in source mode) to an already-started discussion, where I can see a preview only by requesting it, and my posting will end by selecting "Publish changes". Sometimes the only way I can proceed is to use lower-case letters only. so i would be coming across more informally than i intend. I'm not sure, but the glitch may kick off only when I go back within the text I have already written, say I went back to change "nowadays" to "Nowadays". Then the cursor would move to the beginning and put "N" there, so this section would start "NWhen", while the word would have been changed to "owadays". Apparently also typing a parenthesis will do the same, because in this i tried that. the gibberish word which now starts this discussion is the result of cursor moving there. in this it has become impossible to type a capital letter or a quote mark or a parenthesis.

What gives? Is there something in my account which needs to be changed? --Doncram (talk) 18:27, 30 September 2022 (UTC)Reply[reply]

@Doncram: Are you using a mobile device? CX Zoom[he/him] (let's talk • {CX}) 20:12, 30 September 2022 (UTC)Reply[reply]
CX Zoom, I am not on a mobile phone. I'm on an Acer "Spin 3" laptop, apparently running Windows 11 ("Windows Update" says that Windows 11, Version 22H2 is coming soon). --Doncram (talk) 20:51, 30 September 2022 (UTC)Reply[reply]
@Doncram, you're using the New Topic tool in mw:Help:DiscussionTools. I think you're the second or third person to report this problem this year.
The first question is whether you have the GoogleTrans gadget enabled. If so, disabling that should solve the problem.[10]
If not, the second question is whether any part of this description sounds familiar. If so, I'm not sure how to fix it, but I have experienced it myself (usually in Firefox/Mac). Whatamidoing (WMF) (talk) 00:32, 1 October 2022 (UTC)Reply[reply]
Yes there have been some mildly irritating mini-popups opening up, which I suppose were Google translation gadget offers to translate a given word like "owadays" (after the "n" was deleted by me from "nowadays", then I hit shift-n to try to enter "N") to some other language... I think it was sometimes offering to translate to Vietnamese!!! I simply did not understood what that was, and the mini-popups might have closed on their own and gone away. I suppose I did not describe them above because I didn't have the vocabulary to do so. I see now at my User preferences that indeed my user preferences show the feature is turned on ( "GoogleTrans: open a translation popup for the selected text or the word under the cursor when pushing the shift button". ) I did not knowingly turn that on. The mini-popup seems like a weird little thing, which would just translate a single word, from English to some other language? Yes, I was pushing the shift button to try to type (N) or quote mark (") or parenthesis "(" or ")".
Recently, however, I was interested to try to translate some full articles from Norwegian and French wikipedias, and I think i looked up Wikipedia:Translation first and then followed link to Wikipedia:Content translation tool, where per instructions I clicked the "blue button" labelled "Go to Special:ContentTranslation" and selected "Try it now!". I did succeed in translating and "publishing" one or two articles. I suppose that the blue button thing changed my User preference on that GoogleTrans gadget? At user preferences, I have just now turned it off, and I assume that will fix my problem raised here.
I am actually confused now about how I did successfully launch and use a big translation tool which set up side-by-side blocks of text from the source article, for me to translate from Norwegian or French into English ... maybe I was able to start up an article's translation when I was at the article in the Norwegian or French language Wikipedia? But anyhow I did not understand I was also enabling this small one-word-at-a-time thing. And now it is turned off and I dunno if i can find my way back to the one or two article translations I had left in progress. Maybe I will have to change the user preference back, in order to see/find my translations in progress? But that is a different problem than I posed here. Thanks, Whatamidoing (WMF) and all others here. --Doncram (talk) 02:40, 1 October 2022 (UTC)Reply[reply]

HotDefaultSort setting[]

I've noticed that User:BrandonXLF/HotDefaultSort sets {{DEFAULTSORT}} in a manner that omits the word "list" when this may be desirable in some categories. E.g. at List of existing technologies predicted in science fiction the defaultsort is set at "Existing technologies predicted in science fiction", even though sorting as "list" is desirable in non-list categories to show that a given page is a list rather than article. Because of that I personally favor manual setting of sortkeys depending on category. Should HotDefaultSort be amended in that regard? Brandmeistertalk 16:05, 2 October 2022 (UTC)Reply[reply]

@Brandmeister, you should discuss this with @BrandonXLF at User talk:BrandonXLF. There is no technical problem here, so this isn't the right place. — Qwerfjkltalk 17:14, 2 October 2022 (UTC)Reply[reply]
Actually, this was done manually, nothing to do with HotDefaultSort. You can instead discuss this with the or that added the DEFAULTSORT. (Sorry for the ping, BrandonXLF.) — Qwerfjkltalk 17:22, 2 October 2022 (UTC)Reply[reply]
Yep, that was me. I was sorting through stub articles and probably made some s that don't coordinate with the organization of some categories. Please do re- to reflect that organization; my only request is that the lists don't get tagged as stubs. Also, thanks for the idea that lists are not articles, which hadn't occurred to me. Her Pegship (?) 18:34, 2 October 2022 (UTC)Reply[reply]
Technically, lists are articles. All pages in mainspace are articles apart from dabs, redirects, the Main Page and any other exceptions I forgot. Certes (talk) 18:38, 2 October 2022 (UTC)Reply[reply]
Ok, I've adjusted sortkeys. The summary said "using Hot Default Sort", so I thought it was done automatically and was agreed before. Brandmeistertalk 19:29, 2 October 2022 (UTC)Reply[reply]
@Brandmeister, typically, fully automatic ing is done by bots. HotDefaultSort is a semi-automatic tool for modifying DEFAULTSORTs. — Qwerfjkltalk 19:53, 2 October 2022 (UTC)Reply[reply]

Amazon Kindle Compatibility[]

Amazon Kindle: a good device for reading. The Wkipedia: a lot of articles.

I know the browser is experimental, but I think Wikipedia should become more bare bones, so the kindle could run it better.

Best Regards Anon — Preceding unsigned comment added by 185.91.165.192 (talk) 18:59, 2 October 2022 (UTC)Reply[reply]

Well, ok, I guess. 50.74.165.98 (talk) 19:32, 2 October 2022 (UTC)Reply[reply]
Which Kindle model are you referring too? Kindle Fire models have the Silk Browser, and my Kindle Fire has the Wikipedia App installed. Both work well for reading Wikipedia. I agree that the browser on the original Kindle was very clunky. Wikipedia currently supports both desktop and mobile versions. - Donald Albury 21:44, 2 October 2022 (UTC)Reply[reply]

Watchlist glitch[]

The page Patty Loveless is on my watchlist. But for some reason, the watchlist is only showing s made by me and not by others (for instance, it's not showing the by GünniX on October 1). Anyone know what's going on? Ten Pound Hammer(What did I screw up now?) 01:04, 3 October 2022 (UTC)Reply[reply]

The other recent s (and some of yours) are marked minor. If "Hide minor s from the watchlist" is enabled at Special:Preferences#mw-prefsection-watchlist then disable it. PrimeHunter (talk) 03:42, 3 October 2022 (UTC)Reply[reply]

Automatic xmbox template dependent on namespace[]

Hi, is there a xmbox template that changes the mbox type depending on the namespace, for example, ambox for article, cmbox for categories and so on automatically, with the same text, image and other parameters. CX Zoom[he/him] (let's talk • {CX}) 11:43, 3 October 2022 (UTC)Reply[reply]

@CX Zoom: That's {{mbox}}, I think. -- John of Reading (talk) 12:14, 3 October 2022 (UTC)Reply[reply]
Thanks, I think this one is it. CX Zoom[he/him] (let's talk • {CX}) 12:30, 3 October 2022 (UTC)Reply[reply]

Coolest Tool Award 2022: Call for nominations[]

The fourth ion of the Coolest Tool Award welcomes your nominations! What is your favorite Wikimedia related software tool? Please submit your favorite tools by October 12, 2022! The awarded projects will be announced and showcased in a virtual ceremony in December.


MediaWiki message delivery 18:30, 3 October 2022 (UTC)Reply[reply]

Hiding certain images[]

Hi. I need help hiding certain images. Tried using "importScript", "mw.loader.load", and "iusc" and even tried a :. It still says error on bottom in box. I'm trying to create Special:MyPage/common.js Cwater1 (talk) 21:53, 3 October 2022 (UTC)Reply[reply]

For context, see this discussion at the Teahouse. 199.208.172.35 (talk) 22:33, 3 October 2022 (UTC)Reply[reply]
That is the discussion I started. Cwater1 (talk) 00:27, 4 October 2022 (UTC)Reply[reply]
I just noticed that I didn't link it to the teahouse. Sorry. Cwater1 (talk) 00:43, 4 October 2022 (UTC)Reply[reply]

Protected request[]

See MediaWiki talk:Titleblacklist-forbidden-#Protected request on 2 October 2022 Railtransportfan (talk) 22:15, 3 October 2022 (UTC)Reply[reply]

Displaying 0–0 as 0 %, instead of —[]

Hello, I was wondering, whether it's possible to modify the code of the following template so it displays the following win-loss percentage as 0%, instead of a dash ? Best, Qwerty284651 (talk) 23:01, 3 October 2022 (UTC)Reply[reply]

Why would you want to? --Trovatore (talk) 00:16, 4 October 2022 (UTC)Reply[reply]
Qwerty284651: That's bad math. See division by zero. – Jonesey95 (talk) 00:17, 4 October 2022 (UTC)Reply[reply]
@Trovatore and Jonesey95: I know it's bad math, but this format is primarily used for games/set win % in ATP Finals tournament as it's common practice in those situations. Would be nice to have it display the 0%, instead of -, regardless of it being bad math or not. Can you give me a few coding pointers, or what? Qwerty284651 (talk) 00:43, 4 October 2022 (UTC)Reply[reply]
0-0 is already treated as a special case with explicit result &nbsp;–&nbsp; so all you would have to do is replace that with 0%. But the template is used in 2622 articles and 0% would probably look wrong or dumb in a lot of them. If it's only wanted in certain articles like ATP Finals then the code could make the result depend on whether at least one of certain strings appear in the page name. For example {{#ifexpr:{{#invoke:string|find|{{PAGENAME}}|ATP Finals}}+{{#invoke:string|find|{{PAGENAME}}|WTA Finals}}|0%|&nbsp;–&nbsp;}}. PrimeHunter (talk) 01:57, 4 October 2022 (UTC)Reply[reply]
Rather than hardcode page names into the template, I feel it is preferable to have a parameter to control the output. isaacl (talk) 02:09, 4 October 2022 (UTC)Reply[reply]
That could enable any displayed value with {{{none|&nbsp;–&nbsp;}}}, e.g. called with none=0%, or an empty none= to display nothing. PrimeHunter (talk) 02:29, 4 October 2022 (UTC)Reply[reply]
So just replace &nbsp;–&nbsp; with {{{none|&nbsp;–&nbsp;}}} and it should work or would I need to make any other changes/modifications? Qwerty284651 (talk) 03:02, 4 October 2022 (UTC)Reply[reply]
@PrimeHunter, using none as a param for 0–0, when none=0%, {{#ifeq:{{{none|{{&nbsp;–&nbsp;}}}|no||0%}} isn't working. See here. What am I doing wrong? Qwerty284651 (talk) 04:23, 4 October 2022 (UTC)Reply[reply]
That code is all wrong. Just make the replacement in your 03:02 post, nothing else. That should work if calls in relevant articles like ATP Finals add |none=0% to say they want that displayed instead of &nbsp;–&nbsp;. I haven't examined whether {{Tennis win percentage}} is called indirectly via other templates which need updating if 0% should be displayed. PrimeHunter (talk) 04:37, 4 October 2022 (UTC)Reply[reply]
@PrimeHunter:, the code works, finally. I replaced it as you said and then added parameter none=0% to the second template to invoke it. Thank you very much. Qwerty284651 (talk) 12:24, 4 October 2022 (UTC)Reply[reply]
@PrimeHunter param update. The added parameter was causing 0–0 to display as 0% even without the param being added via {{twlp}}, meaning all 20,000+ pages with the {{tennis win percentage}} transcluded were displaying it 0% instead of as –, so I resorted to other alternatives for this issue. Anyway, thanks for helping me, albeit unsuccessful on my end. Qwerty284651 (talk) 20:20, 4 October 2022 (UTC)Reply[reply]
I'm sure that it can be made to work, but it is still invalid to write that Matteo Berrettini's Game W–L percentage (at ATP Finals) is "0%". I recommend against it. "N/A" or "–" would be more appropriate. – Jonesey95 (talk) 04:49, 4 October 2022 (UTC)Reply[reply]
@Fyunck(click): What is your take on this? Is it common practice to write win % for 0–0 as - in tennis-related articles? Qwerty284651 (talk) 13:03, 4 October 2022 (UTC)Reply[reply]
Sort of beyond my knowledge on what is appropriate. All I could give is my own opinion. If I was doing it I would probably use N/A rather than 0% or an ndash. Fyunck(click) (talk) 20:10, 4 October 2022 (UTC)Reply[reply]

Tech News: 2022-40[]

MediaWiki message delivery 00:21, 4 October 2022 (UTC)Reply[reply]

Authority control[]

Hello, where do we report links in the {{Authority control}} that do not work? I checked out a few in Category:Articles with WorldCat-VIAF identifiers and get "404: Document not found" messages. Example article A5 road (Great Britain). Why are we adding links that do not work to this template? Keith D (talk) 11:27, 4 October 2022 (UTC)Reply[reply]

Not a new problem, sadly: Template talk:Authority control/Archive 11#Thousands of WorldCat links don't work. Fram (talk) 11:36, 4 October 2022 (UTC)Reply[reply]
There seems to have been some discussion in 2018 to suppress these links if the article subject isn't a person. But I don't see that it was ever implemented. -- LCU ActivelyDisinterested transmissions °co-ords° 20:17, 4 October 2022 (UTC)Reply[reply]

Planck mythology[]

Various claims relating to effects at the Planck scale have been included in WP over the last years, often vociferously defended, but never reliably sourced. This mythology seems to have permeated to where it is mentioned in print outside WP, and that WP ors seem to accept it as a given. An example that I came across recently where apparently reasonable ors simply fail to understand this effect because it is:

In neither case could the restored source be checked: the link is dead and neither the ISBN nor the author/title combination appears to exist. The statement "it is thought that the short wavelength limit is in the vicinity of the Planck length" is given undue prominence, given that it can be, at best, described as pseudoscientific speculation (that may even have gained visibility through WP). How should we deal with this kind of self-perpetuating topic that draws its strength from WP folklore? —Quondum 11:57, 4 October 2022 (UTC)Reply[reply]

@Quondum: This is for technical problems related to mediawiki and using wikipedia in general. You might want to move this to WP:Fringe theories/Noticeboard. 0xDeadbeef 12:05, 4 October 2022 (UTC)Reply[reply]
Thanks for the suggestion. Moved to Wikipedia:Fringe_theories/Noticeboard#Planck_mythology. —Quondum 12:14, 4 October 2022 (UTC)Reply[reply]

Is Special:EditWatchlist Broken[]

Is Special:EditWatchlist broken for everyone or just me? When I load the page I get:

Internal error
Fatal exception of type "Wikimedia\Assert\ParameterAssertionException"

and trying to load using a different skin doesn't seem to work either. Chris 12:57, 4 October 2022 (UTC)Reply[reply]

Works for me (legacy Vector, Firefox, Ubuntu). Certes (talk) 13:02, 4 October 2022 (UTC)Reply[reply]
Thanks, must just be me then. I cleared my watchlist, and that seems to have fixed it. --Chris 13:50, 4 October 2022 (UTC)Reply[reply]

The "reply" link cannot be used to reply to this comment[]