The policy section of the village pump is used to discuss proposed policies and guidelines and changes to existing policies and guidelines.
If you want to propose something new that is not a policy or guideline, use Village pump (proposals).
If you have a question about how to apply an existing policy or guideline, try one of the many Wikipedia:Noticeboards.
This is not the place to resolve disputes over how a policy should be implemented. Please see Wikipedia:Dispute resolution for how to proceed in such cases.
Please see this FAQ page for a list of frequently rejected or ignored proposals. Discussions are automatically archived after remaining inactive for two weeks.
"A statement in the edit summary such as copied content from page name; see that page's history for attribution will direct interested parties to the edit history of the source page, where they can trace exactly who added what content when. A disadvantage with this method is that the page history of the original article must subsequently be retained in order to maintain attribution."
Do we want to consider this to be proper attribution? -Guy Macon (talk) 16:57, 21 March 2021 (UTC)[reply]
No: as proponent. In my opinion, this creates a copyright land mine. Requiring that a page never be deleted because someone made a copy isn't reasonable. It would be too easy to miss the one edit summary that makes the page undeletable and delete it anyway, thus creating an inadvertent copyright violation. Making a page undeletable could be abused by someone who opposes deletion. --Guy Macon (talk) 16:57, 21 March 2021 (UTC)[reply]
No it isn't. That page says "a hyperlink (where possible) or URL to the page or pages you are re-using" (along with two other ways to do it) A hyperlink to a page that no longer exists does not qualify. If you allow hyperlink attribution, you must make the page you hyperlink to undeletable. --Guy Macon (talk) 17:49, 21 March 2021 (UTC)[reply]
I'm simply not convinced that this is a problem unless you get WMF Legal to say that it is. – Finnusertop (talk ⋅ contribs) 18:53, 21 March 2021 (UTC)[reply]
Yes. As Finnusertop points out, including a link to the original source page is one of the three explicitly mentioned methods of attributions allowed under our legal policies. As ProcrastinatingReader mentions below, if you are legitimately concerned that the source page may be deleted at some point in the future, you could add {{Copied}} to the source page's talk page to inform deleting admins of the copyright issue. In the event that someone uses this strategy to game the system to make a page that should be deleted undeletable, the situation could be repaired by moving the page out of the mainspace, e.g. to a subpage of the destination article's talk page, and then updating the attribution accordingly. In practice, this seems to be an issue very rarely, and I would want to see evidence that this is an actual recurring problem before considering a change to our guidelines here, as well as a viable alternative solution beyond the "list of authors" idea. Mz7 (talk) 17:24, 21 March 2021 (UTC)[reply]
A link to the a the original source page or a link to the missing page where the original source page used to be before it got deleted a year later? --Guy Macon (talk) 17:49, 21 March 2021 (UTC)[reply]
If the page were deleted, that would of course be problematic, but the situation would not be irreparable: we can simply undelete the page and move it to an obscure location, then add a new dummy edit with an edit summary that links to the new location of the page history. If we had to do this constantly, then perhaps I might support some kind of process reform, but as it stands, I doubt this scenario happens more than a couple of times every year. Mz7 (talk) 19:22, 21 March 2021 (UTC)[reply]
Yes. This is already allowed, and recommended, in the copyright policy. The alternative – tracking down and listing authors – is often impractical. The biggest problem is not source pages getting deleted, but editors not providing attribution in any way when copying, and this is not going to get any better if we make the required process more burdensome. As for preserving histories - this is done not just for attribution, it's best practice anyway. I really don't see any issue with "undeletables". If the source page needs to be removed for whatever reason, then it's history should just be kept under a redirect, possibly at a different title. There's no benefit to deletion here. If under some exceptional circumstance the page does need to actually be deleted, then the deleting admin can extract the list of authors and mark it on the destination page; there's no need for this to be forced in all other cases. – Uanfala (talk) 22:50, 21 March 2021 (UTC)[reply]
Well, I would be disappointed that deleting admins don't know what it means and what happens when they delete page history. I think, I was aware of what happens on deletion in wiping out history very early. Has not someone written instructions for admins about preserving history, when needed? -- Alanscottwalker (talk) 23:44, 21 March 2021 (UTC)[reply]
Yes, obviously this should be allowed. Despite the policy page saying there are "three" methods, two of them are "hyperlink" based. The third method is listing every individual contributor. Listing every contributor in the edit summary is often impossible due to character limits, and is always inconvenient. So as I understand it, this will often make splits/merges impossible. There's already a template for talk pages when there is substantial edit-history relevant to content on other pages, so accidental deletion isn't really a concern. 力 (power~enwiki, π, ν) 00:54, 22 March 2021 (UTC)[reply]
Yes no good reason to change the status quo. Elli (talk | contribs) 05:40, 22 March 2021 (UTC)[reply]
Does this exclude the use of oldid/diff links? I understand the concern to the base bare article name, but using links w/ oldid/diff that contains the text that was copied should be fine? --Masem (t) 17:03, 21 March 2021 (UTC)[reply]
Would that make the original page undeletable? I am not sure if the diffs work after deletion. An edit summary like "Added 'I like cake!', originally posted by User:Masem" along with the diff would preserve attribution even if the diff no longer works. --Guy Macon (talk) 17:27, 21 March 2021 (UTC)[reply]
How else would we maintain attribution when merging articles or copying content? – Joe (talk) 17:05, 21 March 2021 (UTC)[reply]
Merging deletes the source without deleting the history, so we would have no undeletable article. For short sections of content, see my answer to Masem. If someone wants to copy a large page with many editors, preserving the history for attribution is an absolute requirement; failing to do so violates the CC BY-SA 3.0 License. --Guy Macon (talk) 17:28, 21 March 2021 (UTC)[reply]
This is the only feasible way to do attribution in many cases. For example: copying a template or another page into a sandbox. I'm not going to sit and dig through the page history and write down the name of everyone in the edit summary every time I create a sandbox. It's not really reasonable to expect when splitting or merging pages either. {{Copied}} exists to make sure the page doesn't get deleted. ProcrastinatingReader (talk) 17:09, 21 March 2021 (UTC)[reply]
Then you are saying that it is OK to make the page you copied from undeletable. Preserving the history for attribution is an absolute requirement; failing to do so violates the CC BY-SA 3.0 License. I don't like it either, but following copyright rules is not something that we abandon when it becomes inconvenient. --Guy Macon (talk) 17:29, 21 March 2021 (UTC)[reply]
It's well and good that you say this is an absolute requirement, but that is really a question for the Foundation's lawyers. If they feel it necessary, a list of editors who contributed to a deleted article could be provided for compliance, avoiding all the practical problems of the proposal. In practice, these pages are generally kept as redirects with revision history. 力 (power~enwiki, π, ν) 00:57, 22 March 2021 (UTC)[reply]
Could we have some background, please, like what exactly is the issue and where have the previous discussions on the topic been? Does the proposal aim to ban editors from linking, or to force them to always provide a list of authors? This can work if the number of contributors is small, but how do you trace all the contributors to a section of a large established article when splitting it out? Also, a list of contributors may be sufficient for copyright purposes, but having the actual history of that content is always preferable: it shows how the content has developed, it allows in principle to see who wrote what exactly (helpful, for example, if one of the contributors later turns out to have been partial to creating hoaxes), and it preserves a record, in the edit summaries, of justifications for parts of that content. And why would the original page need to be deleted? It can always be turned into a redirect (and also potentially moved to a different title), preserving the history, and if there's anything actually nefarious in that history, it can be revdeled. And as for inadvertent deletions, when are these actually likely to happen? The copying is normally indicated in a talk page template, or sometimes in the edit summary of the source page; even if it's not, then the source and the destination pages would almost always have some obvious connection, like one being a redirect to the other. – Uanfala (talk) 17:23, 21 March 2021 (UTC)[reply]
Re: "And why would the original page need to be deleted? It can always be turned into a redirect (and also potentially moved to a different title), preserving the history", that's not the problem. The problem is when you copy a chunk of a page to another page using a hyperlink for attribution and then years later the original article gets deleted at AfD. Bam. Instant copyright violation.
The problem is real. Not allowing hyperlink attribution is one solution. Making an ever-increasing number of pages undeletable is another solution (but we would need some way to keep track of which articles can never be deleted). I would love to hear a solution that is better than the above two, but "Ignore the Creative Commons Attribution-ShareAlike License and purposely create copyright violations because it is convenient" is not an acceptable solution. --Guy Macon (talk) 17:41, 21 March 2021 (UTC)[reply]
Not allowing hyperlink attribution is not a solution by itself; we still need a way to attribute the text. Should we be dumping the authors to a list and including it on, say, a subpage of the corresponding talk page? It would be helpful in that case for the software to provide additional support for this. isaacl (talk) 18:02, 21 March 2021 (UTC)[reply]
Another possible software enhancement would be for it to support a "link to history" mechanism, so you could link a new article to the history of any ancestor articles. If an ancestor was deleted, then the software could provide a way to still extract the editor names. But something else still has to be done until any new feature work gets planned, scheduled, implemented, tested, and delivered (if it ever happens). isaacl (talk) 18:06, 21 March 2021 (UTC)[reply]
The relevant bit in the AN/DRV threads – as far as I can tell from all the layers of procedural wrangling – is to do with the Squid article, and the fact that an admin was presumably aware of the issue of attribution, but decided to delete the article anyway. As for the MFD case, as far as I can tell from a quick glimpse, what is at stake is the deletion of a target of a merge, and not its source, so attribution shouldn't really be an issue at this stage, should it? – Uanfala (talk) 19:53, 21 March 2021 (UTC)[reply]
Thus my statement, "This has pretty much nothing to do with the general question I am asking". I original ignored your request for "context" because there is no context, just a general question about our policies. Then Izno answered for me and got the answer wrong. None of this has anything to do with the question I am asking in this RfC. --Guy Macon (talk) 20:12, 21 March 2021 (UTC)[reply]
Does this not have legal implications? Is this not an office matter? Emir of Wikipedia (talk) 22:57, 21 March 2021 (UTC)[reply]
No, for two reasons. First, Wikipedia:Copying within Wikipedia#Hyperlink is an English Wikipedia editing guideline controlled by Wikipedia editors. Second, you only have to contact legal when allowing something forbidden by legal or lifting a restriction mandated by legal. We are perfectly free to add restrictions. We could decide that nobody is allowed to use the letter "E" and legal would have no say in the matter. --Guy Macon (talk) 23:27, 21 March 2021 (UTC)[reply]
What it sounds like we need is a mechanism to handle the following situation:
Article X is created and expanded over time
Article Y takes a sufficient amount of article X to require attribution (eg not just a citation, but like a whole paragraph). Attribution is added by linking of some time
Sometime after this content is added to Y, article X is sent to AFD and determined to be deleted (not merged nor redirected, nor where it would make sense to history merge X into Y).
So that the deletion "breaks" the attribution that was on Y that pointed back to X that would have been there by X's page history, which would likely still be there to admins but not to regular users. We need to find a way that keeps the history of X available but without having the article of X there. Perhaps when we know that there has been some copying done (can it be possible to automate this check?) that we cannot delete articles but make a deleted target a redirect to some common special page that talks about the history being retained for proper attribution and how the user can go back to the redirect's history to explore that? --Masem (t) 18:12, 21 March 2021 (UTC)[reply]
That's essentially what I was brainstorming as a possible software enhancement, though I don't see how the check can be automated, so I think the editor creating page Y would have to explicitly link to the history leading up to a specific version of page X. Note this applies to all Wikipedia pages, not just articles. isaacl (talk) 18:19, 21 March 2021 (UTC)[reply]
I'm sure there's a few checks that can be made if the {{copied}} template is found on the talk page, or if the history edit summaries contain a diff or oldid (which is uncommon, so this could at least be a list that can be checked manually). But we're likely going to miss other ways that the current language currently allows for (the plain hyperlink w/o oldid or diff), so maybe there's almost a need in Wikimedia that if someone clicks on an oldid/diff of a page that is deleted, that they are taken to a special page to explain what they may be able to do from there; thre we can explain they can contact an admin to help - and if we have this redirect system in place, then the admin can restore+redirect to suit the purpose. I can't see any easy way to do a full Wiki-wide search this way, but we can set up processes to prevent the issue in the future and respond when the need from past deletions comes up. --Masem (t) 18:25, 21 March 2021 (UTC)[reply]
Yeah, that's what I mean by needing an editor to explicitly link the history, whether it is through the {{copied}} template or a new user interface. To help reduce the window for race conditions, I think a new user interface would be better. isaacl (talk) 18:29, 21 March 2021 (UTC)[reply]
RfC: Can editors request community review of the blocks of others?
Option 2. A summary precedes the discussion. — Wug·a·po·des 05:52, 27 April 2021 (UTC)[reply]
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
The two main points of debate were: should third party appeals be allowed and in what circumstances? this is reflected in the three options under discussion, summarized as:
No third-party appeals of blocks
Third party appeals are allowed but discouraged
No explicit guidance on third party appeals
Consensus strongly favors allowing third-party block appeals. Option 1, which would have prohibited third party blocks, received about 8 support comments. These editors generally argued that the harms of allowing third-party appeals outweigh the benefits. Allowing third-party appeals removes the right for editors to decide when and how to argue for an unblock, and since our blocks are preventative lifting them without (or despite) the input of the blocked editor is pointless. It also opens the door for harassment or increased sanctions against the will of the blocked editor. The outright prohibition was countered by WP:IAR and WP:ADMINACCT---community consensus can overturn any action, and admins are required to explain their actions (including blocks), so a blanket prohibition is out-of-line with policy. While consensus was against a blanket prohibition, the arguments were well received and informed the second part of the discussion: under what circumstances should third party appeals be allowed?
This question was discussed mostly by those in favor of options 2 and 3, and both groups were generally sympathetic to the concerns brought up in favor of option 1. In general, both camps agreed that blocks, like all admin actions, are subject to community review, but third parties should request community review only when the block is out-of-policy or procedurally deficient---not just a proxy unblock request. Some editors point out that third party appeals can help editors who may not be able to navigate the unblock process and prevent admin abuse, but editors generally saw those benefits as outweighed by the harms brought up by option 1 commenters. Instead, unblocks "on the merits" should still be initiated by the blocked editor, with others intervening in rare cases. This interpretation was even shared by a sizeable number of option 3 commenters.
The main difference between 2 and 3 then was whether this needs explaining or not. Some editors note that this solution seems to be how we are already resolving the policy conflict, but disagree on whether that means we should document it or not. Editors in favor of option 3 generally point to WP:CREEP and note that the text proposed for option 2 is largely redundant with IAR and ADMINACCT so it is better to avoid needless instructions. While this point was never directly refuted, the numerical majority for option 2 cannot be ignored as most editors seem to prefer documenting the expectation over leaving it implicit in other policies.
Given the discussion, there is a general consensus to use the text in option 2. Third party block appeals are not forbidden, but they should be used sparingly. Per WP:ADMINACCT) editors should generally only start a community discussion after trying to resolve the issue with the blocking administrator. The blocked editor should, ideally, play some role in unblock requests or appeals, and this discussion should not be read to condone making unblock requests for editors in absentia. While third party appeals should not become the norm, neither should they be dismissed out of hand. Without a firm distinction between procedural review requests and unblocks on the merits, editors should weigh potential harms to the blocked editor against the need for community oversight when deciding how to handle third party block appeals. — Wug·a·po·des 05:52, 27 April 2021 (UTC)[reply]
Can editors request community review of blocks of other editors, particularly problematic and/or out-of-policy ones? ProcrastinatingReader (talk) 16:33, 22 March 2021 (UTC)[reply]
Proposal (block review)
In July 2019 a section titled "Appeals by third party" was boldly added to the Wikipedia:Appealing a block guideline stating that appeals may only be made by editors subject to a currently active block; other editors may only discuss the block with the blocking admin (but cannot request review). This text was removed a few times by different editors, but was restored by Sandstein who stated consensus is needed to remove or modify the text. Talk page discussions to remove/alter the text didn't reach a consensus on whether to retain the text.[1] This section is currently in conflict with WP:ADMINACCT and WP:Blocking policy, namely: If editors believe a block has been improperly issued, they can request a review of that block at Wikipedia:Administrators' noticeboard/Incidents. Some editors have tried to cite this section in WP:AN block reviews, as a rationale for why the review cannot happen. De facto, block reviews still occur with some regularity.
This RfC is started to get broad community consensus of this addition, with three presented options:
Option 1: (text) Retain the current text: Appeals of blocks may be made only by the editor under a currently active block. Other editors may discuss the block with the blocking admin. The WP:Blocking policy should also be altered to this effect, to resolve the conflict.
Option 2: (sample text) Blocks should generally only be appealed by the editor subject to the block. Additionally, other editors may request community review of blocks they believe are problematic or out-of-policy (per WP:ADMINACCT) after attempting to discuss their concerns with the blocking admin first.
Option 3: Remove the section entirely.
Survey (block review)
Option 3, second preference option 2: The text at Wikipedia:Blocking policy is just fine and this section unnecessary. In my opinion even option 2 does not accurately represent the status quo (I only tried adding it in an attempt to compromise with Sandstein). I find the position advanced by some admins to be concerning, as illustrated by one example: last year I came across a problematic indefinite full protection which an admin made after receiving a phone call from the subject, saying that all future edits should be run through the talk page as edit requests. The protection was totally out of line with policy, but was defended by some admin wagon-circling on some low-watched talk pages. Once it reached AN, it was near-unanimously overturned.[2] I've also successfully requested block reviews before for good-faith but problematic blocks, which would likely have remained in place had a review not been made. That editors can request review of admin actions to the wider community is a fundamental safeguard against any kind of 'miscalculated' admin action, and this safeguard shouldn't be weakened by bold attempts to introduce a non-consensus change into a low-profile guideline page, which is in direct conflict with policy and precedent. ProcrastinatingReader (talk) 17:06, 22 March 2021 (UTC)[reply]
Option 1. There are good reasons why only the blocked editors themselves are and should remain be able to appeal their blocks.
First, it's a matter of basic individual self-determination and autonomy. Blocked editors are people, not the objects of our entertainment. They are the persons best able to decide whether, when and how they want their block discussed in public - including, of course, their own presumably disruptive or embarrassing conduct that led to the block.
Second, and in the same vein, it's a matter of enabling the blocked editors themselves to frame the unblock discussion, including its timing and forum, and the arguments they want to advance. They may want to discuss the matter with the blocker first, or let another trusted editor do so. They may want to make arguments that might not occur to whoever else makes an unblock request, or they might want to ensure that any unblock discussion occurs at a time when they are available to participate. They might want to have the discussion individually with {{unblock}} reviewers on their talk page, rather than in a public forum.
Third, it's a matter of protecting blocked editors from well-meaning, but incompetent or detrimental unblock requests by others. If a poorly thought-out or disruptive unblock request by others is rejected in a public forum, any subsequent unblock request might be rejected out of hand because there is a perceived community consensus in favor of the block.
Fourth, it's a matter of not wasting the community's time with unblock discussions that presumably even the blocked editor themselves considers meritless (or they'd have made the unblock request themselves).
But, fifth, and perhaps most importantly, serious unblock discussions are impossible without the input of the blocked editor. A core principle of our sanctions mechanisms is that blocks are preventative, not punitive. Unblock requests are not about "does the punishment fit the crime?", they are about "is the block needed to prevent disruption to the project?". And this, in turn, means that we need to know whether the blocked editor themselves considers their own conduct at issue to be a problem, and whether they intend to continue with it when unblocked. Without hearing from them in their own words, we're in pure punishment mode, not in damage prevention mode, and I don't think we want to be there.
Insisting that unblock requests are only made by the blocked editor does not prevent admin accountability at all, because it does not foreclose any avenue of appeal. It just makes sure that a useful and productive discussion can be had that takes into account the interests of the blocked editor as well. Sandstein 17:38, 22 March 2021 (UTC)[reply]
Option 3. The other two options reflect text that was recently added to the guidelines, which contradicts the already pretty detailed policy section Wikipedia:Blocking policy#Unblock requests. I know a few admins are unwilling to countenance feedback on blocks coming from third parties, but this unwillingness leaves the impression of avoidance of accountability. (This impression may not be correct, but the fact that it's there already undermines trust in the system). I imagine that these admins' assumption is that all blocks are good, and so the only conditions under which they can be lifted is when the blocked editor themselves shows readiness to change their ways. But not all blocks are good. There may, for example, be a misunderstanding, and this is sometimes easier to catch by an experienced observer than by the involved party. We should be aware that there are different temperaments as well – some editors would rather leave for good than swallow their pride and ask to be let back in, particularly if they don't agree with the block. Sandstein makes some good points above, and they show it's important to always let blocked editors take part in any discussion about their block. However, this misses the fact that in most cases where third-party appeals are on the table, it's not so much the blocked editor's conduct that's in focus as the blocking administrator's. – Uanfala (talk) 17:57, 22 March 2021 (UTC)[reply]
Option 2, with possibly Option 3 as the second choice. The basic principle of WP:ADMINACCT demands that every admin action, including a block, be accountable to and reviewable by the community. There may be many situations where a block was abusive or just bad and against policy but where the blocked editor is for some reason unavailble or unwilling to lodge an appeal. New editors in particular may not understand how to do that. Editors may get sick or have family or other types of real life emergencies or committments making them unavailable. Or they may simply wish to avoid the drama. If a block was bad and against policy, the community still has an interest and the right to hold the administrator who issued that block accountable. That's why a community review of a block needs to remain available as an option even if the blocked editor does not appeal their block. Nsk92 (talk) 18:13, 22 March 2021 (UTC)[reply]
Option 3 per WP:CREEP, WP:IAR and the points made by the OP. Also, the blocking admin or the blocked editor might not be available for a variety of reasons. Andrew🐉(talk) 18:58, 22 March 2021 (UTC)[reply]
I support keeping the existing text where blocked editors are the ones empowered to appeal their blocks. As they are the ones who face the consequences of an appeal, they should retain control over when and how an appeal is made. Generally, due to community fatigue, there is one initial chance to word an appeal optimally. Other editors should not be allowed to preempt blocked editors from being able to craft their own appeals, in their words and when they are available, or to explicitly delegate this responsibility. I do appreciate there is overlap with the community's responsibility to provide oversight of administrator actions. Nonetheless I feel it is important to allow those most affected by an appeal to be able to manage their appeal. isaacl (talk) 19:53, 22 March 2021 (UTC)[reply]
Option 2 Policy says there can be a review, I agree with that and I also agree that it is desirable that an appeal come from the blocked party in the first instance.Selfstudier (talk) 20:01, 22 March 2021 (UTC)[reply]
Option 2 per the points made above.Sea Ane (talk) 20:41, 22 March 2021 (UTC)[reply]
Option 2 as the full rationales for blocks are often not disclosed on-wiki, having unrestricted third-party appeals will be problematic. Having third-party appeals to change a block "to time served" often will not help the editor blocked. For blocks that are made in error, there isn't the same problem. 力 (power~enwiki, π, ν) 23:02, 22 March 2021 (UTC)[reply]
Option 3, with Option 2 as a second choice. The user who is blocked is just a witness to the event; they are not necessarily equipped with the knowledge, skill, or equanimity to argue policy to defend themself. I point to my improper block from December which was overturned because I was lucky enough to have support from others at my appeal when I felt helpless and lost (although I did make the initial appeal statement). Kolya Butternut (talk) 23:08, 22 March 2021 (UTC)[reply]
Option 2, with Option 3 as a second choice. Admins must be accountable to the community, and that includes having blocks they make reviewed by the community. It is generally preferable that reviews are initiated by the blocked party, but there are exceptions - not least because admins are humans and humans make mistakes. The only reasons why it is acceptable to review a block without having discussed it with the the blocking administrator first are where that administrator is unable or unwilling to discuss it (e.g. they don't have time, they apparently aren't around, or are just not responding) or have indicated that they prefer it to be discussed in a wider environment right away. Option 2 is the one that best captures this imo. Thryduulf (talk) 23:53, 22 March 2021 (UTC)[reply]
Comment - Would contemplate an appeal by another member of the community besides the blockee, but only with a short time limit (i.e. a week or month). One should not appeal the blocks of others 3 months, 6 months, or a year(s) after the fact (i.e. after a community member has not been around for a middling to substantial period of time) because that would be problematic in various ways. That aside, once in a while disagreement over blocks metriculate to AN rather quickly by interested parties; would prefer a just slighly softer wording of Option 1. — Godsy (TALKCONT) 02:41, 23 March 2021 (UTC)[reply]
Option 1 - anything else would potentially open up a Pandora's Box of frivolous appeals. Beyond My Ken (talk) 03:04, 23 March 2021 (UTC)[reply]
I see option 2 as a line of defence against such appeals, which I agree are undesirable, but would happily support something explicit. I currently have no good suggestion for how to word that though. Thryduulf (talk) 03:39, 23 March 2021 (UTC)[reply]
Option 1 Unless there is some other iron-clad way that the blocked user is informed and explicitly consents to be being dragged through a high profile AN. Alanscottwalker (talk) 23:24, 23 March 2021 (UTC)[reply]
Option 2 Before I had experience on arb com I would have said option 3, but we encountered several instances where the blocked party did not want to be unblocked, and did not even want the matter discussed again. At least one or two of these was clearly a matter of someone else trying to harass the individual who had been blocked, which is of course entirely unfair. There has to be some discretion involved here, and #2 is a good compromise solution. DGG ( talk ) 01:58, 24 March 2021 (UTC)[reply]
@DGG: has this been a problem on AN before, though? (if so, any links/examples?) I presume someone harassing someone under the pretence of unblock requests would face a harsh WP:BOOMERANG? ProcrastinatingReader (talk) 17:19, 24 March 2021 (UTC)[reply]
like this normally fall under arb com. DGG ( talk ) 17:59, 24 March 2021 (UTC)[reply]
Option 2 An administrator's actions have to be reviewable by others. If a block is grossly out of policy, it should be brought to the community's attention. I hope this does not become a regular occurrence, but it should be possible when needed. Tamwin (talk) 06:08, 24 March 2021 (UTC)[reply]
Option 3 largely per ProcrastinatingReader and Kolya Butternut. A blocked user may not always have sufficient know-how to file an effective unblock request. A third-party review request is likely to be more convincing as its initiation by itself means there is at least one person who feels that the block is wrong and cares enough about it to request a review. – SD0001 (talk) 11:05, 24 March 2021 (UTC)[reply]
Option 2 mostly per Power and DGG, though I'm sympathetic to the arguments of option 3's proponents regarding forced compromise and would certainly prefer it to option 1. Vaticidalprophet 13:53, 24 March 2021 (UTC)[reply]
Option 1 per Sandstein, Option 2 to seems fairly reasonable too. wikitigresito (talk) 19:33, 24 March 2021 (UTC)[reply]
Option 2 or 3 - I think those esteemed members of our community who have passed RfA and have never before been blocked dont quite get how infuriating it can be to be blocked for what you feel to be a bogus reason. Now in my lengthy block log there's only one or two that I felt that way about, and those definitely were not ones I was going to file an unblock request for. It felt almost demeaning to request to be unblocked for something that I felt I should never have been blocked for. And demanding that somebody do that strikes me, as somebody who has been on that side of things, as just one more affront. If a block is improper it should be lifted. It should not matter who makes the formal request to determine if the block is improper. We should not be demanding that people be contrite when they have been wronged, and yes some blocks are wrong. nableezy - 00:33, 25 March 2021 (UTC)[reply]
Option 2.1 If a bad block drives someone off the site, then as it is, there isn't really a set-up to call it to the attention of the Community. Unblock requests are also difficult for new editors to fully get, especially if they're doing so while impacted by the block. I personally don't mind third party reviews. However, as well as prior contact to the admin, I would also require a) the 3rd party ask the blocked editor if they want to appeal and, if not, do they mind the 3rd party appealing? b) Wait 48 hours after a. If there is no response, or the blocked editor goes "no, and no", then an appeal can be made. If the blocked editor doesn't want the appeal (or makes it themselves) then obviously the 3rd party shouldn't be able to make one anyway. Nosebagbear (talk) 11:48, 25 March 2021 (UTC)[reply]
Option 3, with option 2 as second choice. I have been the victim of a bad block and I can fully understand why someone who's received one would quit. Under the current rules, this leaves the community with no jurisdiction to deal with the matter. We must be empowered to supervise, review and give feedback on blocking sysops' use or misuse of the tools. Some sysops are considerably more block-happy than others which leads to significant levels of inconsistency in our block-related decisions. As of now, any attempt to address problem blockers is hamstrung in every case where the sysop has successfully driven off their target. I believe that there should be a dedicated forum, separate from the Administrator's Noticeboards, for block reviews.—S MarshallT/C 10:05, 26 March 2021 (UTC)[reply]
Option 2 Seems a good compromise between conflicting concerns.--agr (talk) 12:32, 26 March 2021 (UTC)[reply]
Option 3 1st choice, Option 2 2nd choice. #3 because, more or less of instruction creep: we don't need to have this section specify who can make the request and under what circumstances; there isn't a problem of bad block appeals that we need to head off with instructions on a policy/guideline page. The PAGs should be as short as possible and this just doesn't make the cut for me. Option 2 as a second choice, because if we are to have a written rule about this, Option 2 is what it should say. Levivichharass/hound 03:38, 27 March 2021 (UTC)[reply]
Option 1 as first choice; mix of option 2 as second so I think the reason there are so many "Option 2"s above is that we already have a mix of option 2 in practice. We allow third party appeals in extraordinary circumstances already, and what I'm concerned about with the wording use for the option 2 is that it would expand past the existing practice, which is somewhere in between option 1 and option 2. In other words, alleging your friend's block violated policy to appeal on their behalf will be much easier if we don't word an update correctly.In other words, I generally agree with Thryduulf above, but I would prefer this be eased into the existing wording rather than seen as something new. I don't see this as new (it can happen as an outside the norm thing when there's a serious error or something similar already.) Making sure that it retains the sense of being not-the-norm would be something I'd want to see in any wording. TonyBallioni (talk) 20:56, 27 March 2021 (UTC)[reply]
Option 2 seems like the best option. This is not a "never" or "always" situation. Some blocks should NOT be overturned if the blocked user does not request it. Some blocks should. We neither want to encourage wikilawyering and excessive hounding of admins in cases of uncontroversial blocking, but neither do we want to hinder community review of bad blocks, even un-appealed ones. This is a case-by-case issue. For garden-variety, bog-standard blocks, it would be unusual to allow a third party to request an overturn, but practice CLEARLY dictates that we discuss controversial blocks at WP:AN, even if the blocked user does not request it. We're already basically doing 2, and that represents what has been standard practice for years. --Jayron32 16:42, 29 March 2021 (UTC)[reply]
Not commenting on the merits here, but I just want to note that RfC's are supposed to be able to change practice. Admins are supposed to follow the will of the community, especially when formally expressed in a well-advertised and -conducted RfC. --Trovatore (talk) 18:51, 29 March 2021 (UTC)[reply]
Yes, you're right, but your point is irrelevant. What I am saying is not "never change practice". What I am saying is "the alternatives proposed by the current RFC to current practice are bad. Don't do them. What we have works and is best". --Jayron32 11:15, 30 March 2021 (UTC)[reply]
Option 2, now that I've had a chance to look at the merits. The problem with Sandstein's argument is that it assumes that there is something about the blocked editor's conduct that does need to change. This is not always the case; sometimes the block is just incorrect, and never should have been made in the first place. In that case it should not be necessary for the editor to come hat in hand and ask for review. --Trovatore (talk) 19:00, 29 March 2021 (UTC)[reply]
Option 2 followed by 3, per Jayron32 and S Marshall. No such user (talk) 08:13, 30 March 2021 (UTC)[reply]
Option 2. I think that Option 2 harmonizes the best with other policy pages, and it also is the most reasonable way for us to go about it. It's a sensible middle. Option 1 is too rigid and is insufficient for the correction of mistakes, and is inconsistent with other policy pages. Option 3 needlessly opens up too many ways to game the system. But Option 2 sets the right balance, with self-appeals the norm, combined with appropriate ways to have more eyes on a problem. I endorse Nosebagbear's suggestions about including some sort of requirement that third parties attempt to get permission from the blocked user before going forward. --Tryptofish (talk) 18:51, 30 March 2021 (UTC)[reply]
Option 2 (second choice option 3) as there should be no prohibition on discussion bad blocks or reviewing them by others. Frivolous requests are not encourage and can be quickly concluded. Graeme Bartlett (talk) 22:38, 30 March 2021 (UTC)[reply]
Option 2 first choice; option 3 otherwise. While third-party requests for reviews of blocks – or any other sanctions – are uncommon, there's not a central policy basis to forbid them, and in fact they are accepted sometimes, including by ArbCom (I've seen it happen at least twice at WP:AE, including once within the last year or so). The most obvious reason they should be permissible is that a restriction against one editor is often going to secondarily restrict another (e.g. bring a halt to a then-ongoing collaboration, or restrain the other editor in what they may discuss with the editor subject to explicit remedies). Given the lack of anything like a disruptive firehose of third-party unblock-related "noise", there is no actual reason for the page in question to attempt to excessively nit-pick about these matters, especially as a) WP:ISNOTABUREAUCRACY and b) our policies exist to serve us, not the other way around, and should not be restraining good-faith editorial action of any kind without very good reason (cf. WP:EDITING policy). Whatever option is selected, yes do make sure there is not a WP:POLICYFORK going on between these pages. PS: I agree with Sandstein's criticisms, below, of the phrasing of the RfC question, but I think most of us understood the meaning and intent without any difficulty. But do try to write RfCs more neutrally, per instructions at WP:RFC. — SMcCandlish☏¢ 😼 05:29, 31 March 2021 (UTC)[reply]
Option 1 per Sandstein Majavah (talk!) 12:25, 31 March 2021 (UTC)[reply]
Option 2. The community is able and must be able to override almost everything else by consensus, if need be. Policy stating otherwise would be just plain wrong. Mentioning that possibility in policy will help a review actually get started when necessary, while telling editors to first try to take it up with the blocking admin before starting an ANI thread will help prevent things from being blown out of proportion when maybe they could have been resolved much more simply. I agree with some others' secondary proposal that the blocked user should have to be asked first – starting a discussion on somebody's behalf only for it to turn out they didn't even want to be unblocked would be disrespectful of them and a waste of time. Finally, frivolous requests happen anyway, and this RFC isn't going to change that, regardless of outcome. – Rummskartoffel (talk • contribs) 21:42, 1 April 2021 (UTC)[reply]
Option 2: any administrator action should be open to community review, blocks included. A community member may have a legitimate concern about an administrator action even if they were not the target of the action, and even if the target of the action does not wish to appeal it. An editor having a concern about an administrator action should discuss the action with that administrator first, and only bring their concern to the wider community if that initial discussion failed to resolve it. Mr248 (talk) 05:00, 2 April 2021 (UTC)[reply]
Option 3 first choice. Option 4 (just let us make third party requests} real first choice (were it available). We already have ADMNACCT and the blocking policy that is very clear, and we have trusted it to tell us we can make these appeals if we think there is problem. We should either support that policy in other places, or remove it from the other places where it conflicts. Huggums537 (talk) 09:36, 2 April 2021 (UTC) Also, most of Sandstein's arguments are based on the assumption that a blocked editor would somehow have no way at all to have any say so in the matter, or otherwise have no way to participate in the third party review process of their own block. There is no evidence of this because most blocked users still have talk page, and email access available to them, and even if they don't, they can still email someone. So, I have to disagree with his points based on that alone. Huggums537 (talk) 03:46, 6 April 2021 (UTC)[reply]
Option 2 simply brings WP:AAB in line with the policy page it's meant to supplement and as such can't be reasonably opposed. Option 3 is my second choice—a very close second choice. Iaritmioawp (talk) 22:12, 2 April 2021 (UTC)[reply]
Option 2 – The wording that is most conducive to handling unblock discussions on a case-by-case basis. Kurtis(talk) 13:04, 9 April 2021 (UTC)[reply]
Option three. Administrators have to be accountable to the wider community with regards to the actions they take and sanctions have to be subject to review. Where the editor that has been blocked is unfamiliar with relevant policy or generally-accepted practices, it would be unfair to expect that editor to be able to compose an unblock request with a good chance of success. I feel that option one is incompatible with the ideas of accountability, while option two is unnecessary advice that unfairly constrains those who wish the block to be reviewed. Sdrqaz (talk) 20:49, 9 April 2021 (UTC)[reply]
Option 3 - The section was improperly added without a formal consensus and it never should have been added in the first place. That's not how policy works, we just don't write up new policy based on vague "previous discussions" and say "feel free to revert". The clause is completely illegitimate. ~Swarm~{sting} 22:28, 9 April 2021 (UTC)[reply]
I think you make an excellent point here Swarm. The proof the entry was invalid is the fact it has been much objected here or challenged so many times since it was added, and even if it were somehow valid by some stretch of the imagination, I agree with comments made by Trovatore above that the arguments for it made by Sandstein and others make too many unrealistic assumptions about the circumstances involving blocked users as pointed out in my vote above as well. Huggums537 (talk) 03:00, 10 April 2021 (UTC)[reply]
@Swarm: I agree that the said provision might have been "sneaked" into the policy without due consensus but your opposition based on that mere fact should bear no weight here since the very consensus may be build regardless of the way it was initiated. (please reply into the discussion below) --AXONOV(talk)⚑ 11:14, 10 April 2021 (UTC)[reply]
Sorry, but that's not how any of this works. New policies must be proposed and require a high level of consensus from the entire community to be implemented. You can not simply add text without meeting this requirement, that itself is the community's policy requirement for the creation of new policies. This RfC does not frame the existing policy clause as an illegitimate policy in need of retroactive community validation, it frames it as an existing status quo to either be maintained or changed or removed, while glossing over the fact that it is not, in fact, even a real policy to begin with. ~Swarm~{sting} 00:13, 12 April 2021 (UTC)[reply]
As I said elsewhere, I feel this change was an instance of this. Other editors discussed it in good faith on talk in October, but it blatantly failed to get consensus and was still being forced in. This is not how we should be editing policies. It's worrying, the idea of non-consensus text added to policies like this and then (according to Nsk92 below) used in discussions. More generally: portions of PAGs are quoted in dispute resolution all the time and used as a basis for sanctions / resolving RfC disputes, but some of these texts don't even have consensus, and most people don't use WikiBlame all the time to figure out when the text was added and after how much conversation. This can result in bad outcomes. ProcrastinatingReader (talk) 14:22, 10 April 2021 (UTC)[reply]
Option 2 - I hate indefinite bans. We shouldn't deprive third-parties from an opportunity to bring controversial bans (or evidence of wrongful ones) under the light of broader community reviews. This should be a first step preventing all sorts of hard-to-notice WP:GANGings-up and witch-hunts, make the process of behavioral-scrutiny more transparent and harder to misrepresent victims altogether or harder to make non-appealable bans. Considering that application of this provision may involve broader community attention it won't be abused. The lack of thereof would certainly embolden those with ill-intent. The WP:ARBCOM also routinely reviews some blocks so I don't see why community should be prohibited from doing so. This is a good proposal.--AXONOV(talk)⚑ 11:14, 10 April 2021 (UTC)[reply]
Option 2 - if a block is within a reasonable interpretation of policy, then indeed the blocked user's own appeal should be the only grounds for unblocking. However, if the block is outside of the reasonable range of policy, it should be undone as soon as possible even without such an appeal; any user who notices such a problem should be allowed to request community feedback about it. 147.161.8.7 (talk) 23:05, 12 April 2021 (UTC)[reply]
Option 2. Admins should be accountable to the community in the utmost. Benjamin (talk) 03:16, 14 April 2021 (UTC)[reply]
Option 2 Only the blocked editor can give assurances that a good block won't need to be repeated. But anyone should be able to challenge what they consider to be a bad block. ϢereSpielChequers 23:49, 14 April 2021 (UTC)[reply]
Option #1 #3 & #2 There is a math problem here. The fundamental question is whether or not to have such a process, and the "yes" support is split between two different options. You need to combine the #1 #3 and #2 support as a "yes" to answer that main question. North8000 (talk) 18:21, 16 April 2021 (UTC)[reply]
I don't follow, North8000. I view option one as being very different to options two and three, as option one effectively prohibits community review of blocks, while the others do not. Sdrqaz (talk) 18:59, 16 April 2021 (UTC)[reply]
I agree with Sdrqaz. My understanding of the question is "Should third-party appeals of blocks be allowed?" (1) No, (2) Sometimes, (3) Yes. I don't think that any of them can reasonably be combined, but if you insist on merging any two it would be 2 and 3. Certainly I intended my expression of support for option 2 with option 3 as a second choice to indicate my opposition to option 1. Thryduulf (talk) 19:43, 16 April 2021 (UTC)[reply]
@Thryduulf:@Sdrqaz: I made an error in my post. Thanks for catching it. I'll need to figure out the best way to fix it. Sincerely, I made an error in my post. Thanks for catching it. I'll need to figure out the best way to fix it. North8000 (talk) 21:16, 16 April 2021 (UTC)[reply]
Thanks. I fixed my error. Just reinforcing, I didn't mean to merge for all purposes. More like combining #2 & #3 to to see if people say "yes we want a way to do that" and, if so, then seeing whether #2 or #3 has greater support regarding how to do that. North8000 (talk) 21:29, 16 April 2021 (UTC)[reply]
Option 3 I see no reason why a noticeboard like WP:MOVEREVIEW or similar wouldn't be useful for something like this. Holding admins accountable should be a goal of wikipedia and it would be best to do so in a transparent way. Getting these types of conversations off ANI would be best considering how busy that place is. Also, this prevents some things going to Arbitration which is good. Swordman97talk to me 03:52, 19 April 2021 (UTC)[reply]
Option 2 or 3, there are many situations where a user has been blocked without knowing what they did because of how broken the mobile app is. So allowing a community review of the block would be a good idea. However, there is a chance the editor who has been blocked could create alt accounts to try and get them unblocked by requesting community review and persuading those who are reviewing the block that the block should not have been placed in the first place. Blaze The Wolf | Proud Furry and Wikipedia Editor (talk) 20:10, 20 April 2021 (UTC)[reply]
Option 3; second choice option 2. The section overall is too bureacratic/instruction creep for my liking, but if there is no consensus to scrap it completely I would much prefer option 2 to the status quo. (option 1)Jackattack1597 (talk) 22:33, 24 April 2021 (UTC)[reply]
Discussion (block review)
The question posed in this RfC ("Can editors request community review of blocks, particularly problematic and/or out-of-policy ones?") is not neutral or sensible. It should be rephrased as "Can editors request the community review of blocks of other editors?". The question omits that this RfC is only about blocks of others, not of one's own blocks. And presumably everybody who appeals a block believes that the block is problematic or violates policy, else why appeal it? This qualification is therefore also not needed. Sandstein 17:46, 22 March 2021 (UTC)[reply]
Some questions: (1) If there is an improper block, and after discussion with an administrator it is not resolved, does that mean a discussion has to be about whether there should be action taken against the administrator? (2) Sometimes an satisfactory unblock request is declined because an administrator has not read it properly (3) There can be other exceptions such as misunderstandings [3] or blocking the wrong user. The unblock process is too slow, there is at least one unreviewed request from January. Peter James (talk) 18:13, 22 March 2021 (UTC)[reply]
I see your point on the first (that it should be clear it's about other editors); I will tweak. On the second point: I think the qualification is necessary. There are different reasons to appeal/review, such as on the basis that the block is no longer necessary or that the editor has learned, etc, which doesn't mean that the original block was out-of-policy (though, it could still be misguided). Such discussions also happen with some regularity. I feel like introducing these two separate details directly into the RfC question will make this discussion a slight WP:TRAINWRECK. I have no particular opinion on appeals for other reasons and am happy with the actual status quo as it exists at AN. ProcrastinatingReader (talk) 18:23, 22 March 2021 (UTC)[reply]
I have always assumed that if an administrator takes an action against another editor, and I see a problem with that action, I could contact that admin to discuss it... and (if need be) I could post a thread at WP:AN to discuss the issue with the rest of admindom. Is this not the case? Blueboar (talk) 18:50, 22 March 2021 (UTC)[reply]
Not when it comes to blocks. Or at least the situation is unclear when the matter comes to blocks. I am pretty sure that every time I have seen a community review of a block being started at AN/ANI without the blocked editor requesting an unblock, Sandstein brought up this particular provision of Wikipedia:Appealing a block ('third-party block appeals are not allowed'), usually resulting in protracted discussions of the matter. Nsk92 (talk) 23:19, 22 March 2021 (UTC)[reply]
What if there is a potential pattern of bad blocks? Surely we should be able to discuss the individual blocks to determine whether there is a pattern of poor judgement on the part of the admin. SOME flexibility is needed here. Blueboar (talk) 00:44, 23 March 2021 (UTC)[reply]
It seems like a potential other option is to require the blocked person to consent to a third party requesting review (or to provide a window of time in which to object). I think some of Sandstein's objections are persuasive, but also know that blocks are emotional and confusing times, such that third party review is potentially extremely helpful to some users who don't feel equipped or otherwise feel overwhelmed/uncertain about the situation. — Rhododendritestalk \\ 19:45, 22 March 2021 (UTC)[reply]
I do appreciate that being blocked is a confusing time, and I sympathize with blocked parties feeling overwhelmed. I think it is important, though, to try to guard against this becoming a situation where they agree out of distress to a third-party appeal, without taking time to consider what is the best course of action. In a different context, Bilby suggested having advisors provide guidance to aggrieved parties on possible future steps. This could be useful for this scenario. isaacl (talk) 20:01, 22 March 2021 (UTC)[reply]
If I understand the intent of Option 1 correctly, I think it is a reasonable description of common practice that doesn't necessarily conflict with WP:ADMINACCT or the blocking policy, although it could definitely be worded better. Essentially, whenever a third-party editor posts on AN or ANI asking for a block to be reviewed, the community will generally want a statement from the blocked user that explains their view on the situation. Outside of situations where a block is a clear error or clear misapplication of policy, I can't think of a situation where we would unblock someone without hearing from the blocked user first. The intent is not to give administrators carte blanche to make bad blocks with impunity as long as the blocked editor refuses to appeal their blocks, but merely to convey that in the wide majority of cases, appeals will be unsuccessful if we don't have a statement from the blocked user themselves. Mz7 (talk) 21:24, 22 March 2021 (UTC)[reply]
Block reviews are generally distinct from appeals (usually being made on the basis of being out of policy; Sandstein reverted this change too so I presume he disagrees with it). The community is generally inconsistent on what to do about actual third party appeals ime, often it depends on the editors participating in a given discussion on a given day. ProcrastinatingReader (talk) 21:51, 22 March 2021 (UTC)[reply]
Hmm, having looked into this a little more, I think I better understand the context of the dispute here. I would agree with you that if a third-party user comes to ANI asking that someone else's block be reviewed, e.g. accusing the administrator of being WP:INVOLVED or some other clear policy violation, we should not dismiss their argument just because it did not come from the blocked editor themselves. The rationale for this would be WP:NOTBURO: in legal disputes in the United States, it is not uncommon for a court to dismiss pending litigation purely on procedural grounds before reaching "the merits", e.g. if the plaintiff lacks standing to bring the case; Wikipedia is not a court, however, and NOTBURO states that A procedural error made in a proposal or request is not grounds for rejecting that proposal or request. With all of this being said, I think I would still support adding language that discourages most forms of third-party block appeals/reviews, unless a block is obviously flawed. The status quo seems to be fine, but I am concerned that with this RfC, we will inadvertently tip the status quo towards encouraging more third-party reviews to the detriment of our time and energy. Among the options here, it looks like Option 2 is the closest to my views, although I feel that a bit more emphasis should be placed on the "should generally only be" part. Mz7 (talk) 22:31, 22 March 2021 (UTC)[reply]
The problem is a bad appeal can ruin the opportunity for a reasonable appeal in the short-term. It's not an issue of ignoring arguments, but letting the party most affected by the appeal manage when and how those arguments are made. It's unfair to blocked editors to allow anyone to make an appeal, without any co-ordination on its form, wording, emphasis, or other aspects. isaacl (talk) 22:42, 22 March 2021 (UTC)[reply]
I think trying to invoke WP:NOTBURO or WP:IAR as a reason for allowing is not an ideal approach. It tips the scale in favour of editors who understand community norms, or editors with lots of TPWs of such editors, who can reconcile different policies together and know how the community responds to different issues in practice. Guidelines should reflect that status quo, documenting it so that people less familiar with back-office operations can also request the community review issues (and indeed, many times such editors have picked up on valid problems). It's probably undesirable not to make this clear for all editors, and unacceptable to provide a misleading image of this (which is what the current section does). I am aware folks get overly cautious on 'tipping the scales' too far, which is why I tried to compromise with Sandstein in what was, in my opinion, a careful worded change opening the door to block reviews for out-of-policy issues but not too wide. (my actual opinion is slightly more wide, though acknowledging isaccl's concerns on something too wide.) None of the choices explicitly say "any editor can appeal for any reason they want". So at best option 2 is still carefully worded and option 3 just reverts to whatever editors believe the status quo is (without documenting such) (which is pretty much in WP:BP: you can, but use common sense). ProcrastinatingReader (talk) 22:44, 22 March 2021 (UTC)[reply]
I'd add that, in my experience, the admin making the allegedly problematic action rarely ever backs down in local discussions (possibly because they firmly believe in their action, or the saving face aspect, or both). Indeed, in all the actions I've appealed to AN that were overturned the admins all declined to reverse themselves. This isn't really an indictment of the admins (people can naturally disagree on application of policy), just the fact that I think "you can discuss with the blocking admin" (from the current text) is toothless/unhelpful in practice. ProcrastinatingReader (talk) 22:54, 22 March 2021 (UTC)[reply]
Regarding those supporting option 3 as editors may not know how to appeal or are overwhelmed: I dislike the community making an appeal on their behalf without discussing it with them first. Communication is a bedrock principle for a collaborative project. We should be attempting to work with the blocked editor to determine the best path forward, and not assuming we know best. isaacl (talk) 23:29, 24 March 2021 (UTC)[reply]
IMO: the immediate problem with that view is [4]. There are several secondary issues, ranging from confrontation and high-profileness (similar to fears against running RfA), to the community's role in admin accountability (if a poor action is so painful it causes an editor to quit, and other editors can't request review with the community, is ArbCom now the only choice?). Blocking is the pointiest stick in the toolbox. It should also be the one used most cautiously, and subject to the most avenues of review when it is not. ProcrastinatingReader (talk) 23:34, 24 March 2021 (UTC)[reply]
There are always special circumstances that can be handled differently. This does not warrant, in my view, removing any restrictions (as per option 3) on who can initiate an appeal. When it is possible to communicate with a blocked editor, we should be trying to do so, and it poses no significant barrier for reviewing an administrator's actions. isaacl (talk) 00:16, 25 March 2021 (UTC)[reply]
I presume you don't object to option 2, then? As I feel like your statement does lead to significant barriers if you also oppose option 2 (it would mean ArbCom is the only viable option [though, per remedy 5.x, that viability is in question]).
For option 3: I've seen thoughtful appeals come from third parties, like Ritchie333, which have helped in cases (in some they don't, but usually because editors say third party appeals bad, which comes around into a loop to this very RfC). I believe WP:UBCHEAP can apply in many cases, and more importantly don't really believe the art of crafting a persuasive block appeal / wider community relations has much to do with whether someone has learned and can be a productive editor. ProcrastinatingReader (talk) 00:46, 25 March 2021 (UTC)[reply]
I don't like trying to list specific circumstances; I think individual cases should be evaluated on their own merits. I don't like that there isn't any mention of trying to work with the blocked editor. There have been fine third-party appeals; I've also seen poor third-party appeals. It's not about the blocked editor having to learn how to do the lobster quadrille. It's inconsiderate to take an action on someone's behalf without even trying to co-ordinate with them and understand what they want to do next. isaacl (talk) 01:00, 25 March 2021 (UTC)[reply]
On the second half that's a fair point. It's worth noting that both option 1 and option 2 were each mostly written by a single editor without being churned through stages of policy-writing (hence my emphasis on sample text). I didn't feel extra specifics mattered because in this particular RfC I'd like to see the broader ideological issue resolved. I agree to adding text regarding best practices in third party appeals if option 2 passes. Although, I do think block reviews or criticism of the blocking admin is distinct from appealing on behalf of a person (a fine line, admittedly). On the first part I still don't follow; surely with option 1 cases can't be evaluated on their own merits, since it's a blanket ban on third party appeals? ProcrastinatingReader (talk) 01:16, 25 March 2021 (UTC)[reply]
On general principle, special circumstances can always apply to any guidance; start listing some exceptions out, and people can start thinking those are the only special cases. In this particular case, "problematic" is so broad that almost anything could be put into that category. isaacl (talk) 01:31, 25 March 2021 (UTC)[reply]
Genuine question, could I ask the option-3 !voters why they think option 2 (or whatever tweak someone might want) wouldn't be your preferred choice? If it's just "prefer not to have more rules" that makes sense, but presumably any block someone would question they must think is problematic? Nosebagbear (talk) 13:58, 26 March 2021 (UTC)[reply]
Because the community needs maximal freedom to address issues of poor sysop judgment. If I see a sysop handing down a problematic block, I would like to be completely free to raise that with the community. And it might well be that my unprompted, disinterested expression of concern about a block is more convincing to the community than the target's concern.—S MarshallT/C 18:03, 27 March 2021 (UTC)[reply]
@S Marshall: but you say it's a problematic block, so it would fall within proposal 2, surely? Nosebagbear (talk) 16:28, 31 March 2021 (UTC)[reply]
Just as a general note; I didn't see a fourth option available to just simply allow for third party requests regarding block reviews. This didn't seems to offer an entirely unbiased amount of options to everyone from a totally neutral point of view. Huggums537 (talk) 09:03, 2 April 2021 (UTC)Strike that last part. I don't like the way it sounds. I was just curious why a fourth option wasn't thought of that's all. No offense to the OP. Huggums537 (talk) 10:27, 2 April 2021 (UTC)[reply]
Also, I've been gone from the project for a while. What's all this first choice, second choice crap about? How's a closer supposed to tally that up? Huggums537 (talk) 12:58, 3 April 2021 (UTC)[reply]
I've seen a great deal of people talk about adjusting the guideline according to what the "regular practice" and "current norms" are, but what does that really have to do with anything? That's like saying, "Our crime rates are very low, and it is the current norm to have little crime so we should write our criminal laws to notate that crime is not the regular practice." It makes no sense whatsoever, and really serves no obviously valid or useful purpose. It also begs one to wonder why anyone would want such notations in the guidelines. Huggums537 (talk) 01:19, 5 April 2021 (UTC)[reply]
@Huggums537: The answer is a bit of a cultural one: Wikipedia is not a legal system, and our policies and guidelines are intended precisely to describe regular practice and current norms, not prescribe them. See WP:PG (Wikipedia's policy and guideline pages describe its principles and agreed-upon best practices) and WP:NOTBURO (Although some rules may be enforced, the written rules themselves do not set accepted practice). In general, the reason why we refer to "regular practice" is because that is typically what has been tried and tested through experience. Sometimes, that experience informs us that we need to change our practices, and then consequently the policies and guidelines, which is the purpose of these kinds of discussions. Mz7 (talk) 03:32, 16 April 2021 (UTC)[reply]
Mz7, thanks for responding. Wikipedia might not be a legal system, but many people still frequently make the comparison to a legal system in order to illustrate stupidity, as I did above, and I see nothing wrong with that. I have a very "culturally" different interpretation of what you have provided. I like to think of myself as someone who is able to interpret things from an "un-Wikipedified" point of view. In fact, the first quote you gave above seems to indicate to me that the order in which things should follow are that policy makers first decide what it's principles are, then agreed upon best practices are described in guidelines, not the other way around. In other words, it's not the current practices driving policy, but rather a predetermined set of principles with best practices that have been discussed, and agreed to beforehand. The lead of WP:PG mentions "standards" and "principles" multiple times. These are things typically associated with predetermined sets of values. It prominently mentions the WP:Five pillars as one of these predetermined sets of principles. I think my interpretation is very fair when you put it in this context with all the rest of the lead. Your interpretation of it only seems fair if you take a portion of it out of context, and interpret with your own narrative of what you think it ought to mean, and I have no doubt you would "in practice" have many who might not agree with me on that, and therein lies my actual point, you see very little clearly succinct policy to back up actual practice in many cases, while the majority of policy seems to indicate something else. It's contradictory, and seems to set a double standard. This appears to be a pervasive issue on Wikipedia. Additionally, the second quote you provided makes it a point to mention, "some rules may be enforced", and references WP:ENFORCEMENT. It must have been mentioned in the policy because it is relevant, particularly in this discussion where we are determining the issue of potentially bad blocks and the conduct of admins., so I still think an over-emphasis on "regular practice" is both unwarranted and senseless in this case as I pointed out before when I made the comparison to the legal system. Huggums537 (talk) 10:18, 16 April 2021 (UTC)[reply]
I also want to add to my comment that I think adding such senseless and unwarranted "regular practice" insertions are an actual detriment to policy and contribute to the pervasive issue of creating contradictions that lead to the double standard problem I mentioned earlier. Huggums537 (talk) 14:42, 16 April 2021 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Define "recently" for CSD R3
Wikipedia:Criteria for speedy deletion#R3: "This criterion does not apply to redirects created as a result of a page move, unless the moved page was also recently created."
Proposal: define "recently" as "less than a month ago". (i.e. if a page is created on 2 February, last day to be eligible for CSD R3 is 1 March) — Alexis Jazz (talk or ping me) 15:32, 23 March 2021 (UTC)[reply]
I think a month is about right. The big hurdle for R3 should really be the obvious implausibility, not the exact recentness - and something that made sense in 2006 might look implausible now but should be discussed, but something that looks implausible now probably still looked implausible in February 2021. I've previously not really thought this needed to be codified, but if people are really raising a stink on the basis of recentness when it happens to a day-old redirect, maybe it's worth making an actual solid line. I'd also like to mention that I just can't read {{db-redirtypo}} without my brain reading it as "re-dirty-po". ~ mazcatalk 15:47, 23 March 2021 (UTC)[reply]
As I indicated at WP:VPI#Define "recently" for CSD R3, I'd prefer a bit longer, but this is acceptable. I'd also prefer if we didn't have to spell it out, but clearly we do - not so often in practice about people complaining about the speedy deletion of days-old redirects as about people complaining about the declination of years-old ones. —Cryptic 16:07, 23 March 2021 (UTC)[reply]
This has come up lots of times at RfD over the years and the rough consensus has always been that there isn't a firm cutoff but it's measured in weeks not months (or, by implication, days but I don't recall that coming up). Generally the more implausible it is the more lenient people generally are about recentness. If there is really a need to define it rigidly then certainly 1 month is acceptable, but I'm not convinced that there is such a need. Simply writing down the consensus of "weeks, not months" as guidance somewhere would seem sufficient to me. Thryduulf (talk) 16:54, 23 March 2021 (UTC)[reply]
There's not real problem here, just Fastily being more conservative than they need to be. The redirect in question probably could have been speedy deleted as a request by the only creator of the page anyway. No big deal, let's move on with our lives. Oiyarbepsy (talk) 17:24, 23 March 2021 (UTC)[reply]
I'm with Oiyarbepsy on not seeing any problem here, unless one can be shown by a link to the actual screaming rather than a second-hand report of it. Like most things its best left rather vague because bright lines tend to lead to gaming. Phil Bridger (talk) 19:39, 23 March 2021 (UTC)[reply]
Regarding "link to the actual screaming", Alexis Jazz already asked for it, and I declined because this site really doesn't need the extra drama. Let's keep the focus on defining a suitable interval based on its own merits please. -FASTILY 22:41, 23 March 2021 (UTC)[reply]
This gets brought up from time to time (for example, in these twodiscussions from 2019). One month is consistent with most people's views, but my impression has been that there is broad agreement that flexibility is good and that having an explicitly set cut-off point is undesirable. – Uanfala (talk) 11:57, 27 March 2021 (UTC)[reply]
@Uanfala: The problem is that some people interpret "recently" as "24 hours" and others as "a few years". (Wikipedia is 20 years old, so anything created in past 2 years was recently created) My personal interpretation was about a week, but I'll use a month as a guideline now that I've seen that that is how most people interpret it. Couldn't we at least change "recently" to "recently, typically about a month" or something to give readers a ballpark? — Alexis Jazz (talk or ping me) 05:36, 28 March 2021 (UTC)[reply]
Given that others have caused a concern, perhaps putting a suggestion would be a good thing. --TheSandDoctorTalk 05:46, 28 March 2021 (UTC)[reply]
I'd support noting in the documentation something along the lines of "Users and admins are expected to show discretion, but a rough guideline for 'recent' should be one month". Elli (talk | contribs) 01:48, 31 March 2021 (UTC)[reply]
well that previous discussion was closing in on 30 days being added to the text, But now the debate starts all over again. I think we should add that 30 days in to give a guide and a bar. It many mean that the deleter has to check when the redirect was created, but I hope they already do that! Graeme Bartlett (talk) 07:21, 31 March 2021 (UTC)[reply]
The word "recent" needs to be defined for the first mention in R3; when used later (such as in the section quoted by the OP), it should?mean precisely the same thing. 147.161.8.151 (talk) 23:32, 12 April 2021 (UTC)[reply]
30 days sounds long enough for people to notice it. I note that CSD A10 also lacks a defined "recent" cutoff, and I'd recommend the same threshold there. –LaundryPizza03 (dc̄) 21:17, 14 April 2021 (UTC)[reply]
RfC: Notability of fictional characters
The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion.A summary of the conclusions reached follows.
Consensus was reached that an award does not imply notability Consensus was reached that characters should not be presumed notable simply because the portrayer of the character has received a major award for their work. However, that doesn't mean the character is non-notable. theleekycauldron (talk • contribs) (they/them) 21:22, 27 March 2021 (UTC)[reply]
Should a fictional character in film or television be presumed notable if the portrayer of the character received a major award for their portrayal of the character? theleekycauldron (talk • contribs) (they/them) 07:01, 27 March 2021 (UTC)[reply]
No — the award means people have praised the actor. That doesn't mean the character is notable.--Jack Upland (talk) 07:53, 27 March 2021 (UTC)[reply]
Enough for an individual article for the character? No. There needs to be ample coverage on the character's conception, characterization and reception. —El Millo (talk) 08:02, 27 March 2021 (UTC)[reply]
No, the award of the actor does not imply notability of the character. For an example, I don't think anyone would reasonably presume that the character Hal Fields in Beginners is notable enough to warrant an article, despite the actor who portrayed him, Christopher Plummer, receiving an oscar for his performance. --Volteer1 (talk) 08:52, 27 March 2021 (UTC)[reply]
No - Acting awards rewards just that, acting. There's little to no connection between how well a character is played and how notable that character is. Volteer1's example above is right on the money. PraiseVivec (talk) 10:56, 27 March 2021 (UTC)[reply]
Of course not. It is instructive to look at Academy Award for Best Actor and see how many of the roles portrayed do not have standalone articles (the vast majority of bluelinked roles are not fictional characters). —Kusma (t·c) 11:15, 27 March 2021 (UTC)[reply]
No, and suggest snow close. {{u|Sdkb}}talk 14:11, 27 March 2021 (UTC)[reply]
No - The fictional character needs to be notable themselves; the notability of the actor who plays that character is not so important. Agree with the comments above. Netherzone (talk) 14:37, 27 March 2021 (UTC)[reply]
No As per other editors, the character has to be notable because of articles and reviews, not because someone played them won an award. Characters like Lady Macbeth and Bill Sykes have pages because they have been discussed and written about.Davidstewartharvey (talk) 14:57, 27 March 2021 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
A late comment - I agree with the above comments, with one addition: There is a reasonably good chance that if the actor portraying a character has won an award for the portrayal, the character has also received at least some coverage. Do a thorough search for that coverage WP:BEFORE nominating. Blueboar (talk) 21:32, 27 March 2021 (UTC)[reply]
@Theleekycauldron: Could you please clarify the close statement? Right now it technically states that someone winning a Grammy isn't notable nor someone who won a Nobel prize etc. Those things can make someone notable on their own for having received it per WP:NMUSICIAN/NBAND, Wikipedia:Notability (academics), (parts of) Wikipedia:Notability (sports), and WP:ANYBIO/NBIO itself. The close statement should oull specifics from the question to indicate its scope (i.e. something like "Consensus was reached that a fictional character in a film or television series is not presumed notable solely due to the real-life portrayer of the character having received a major award for their portrayal of the character.") --TheSandDoctorTalk 04:06, 28 March 2021 (UTC)[reply]
@Theleekycauldron: All good! We all make mistakes etc. Thanks for fixing the scope of the closing statement. --TheSandDoctorTalk 08:56, 28 March 2021 (UTC)[reply]
LOL. This one was pretty obvious. VP need not be mired in predictable-outcome RfCs. Just look for extant examples that prove the case. E.g., Linda Hunt (unquestionably notable actor) received an Oscar (unquestionably notable award) among other awards for her cross-gender and cross-ethnic role in The Year of Living Dangerously (unquestionably notable film). But the character is not independently notable and pretty much no one remembers the name. Similarly, Fisher Stevens (notable actor) played a cross-ethnic role in Short Circuit (notable film) and (with the character's surname inexplicably changed in a pointless retcon) its straight-to-video sequel Short Circuit 2 (marginally notable film). Yet the character, whose confused name no one remembers either, is not independently notable – despite a great deal of controversy around these portrayals, which even resulted in Stevens being indefinitely persona non grata banned from traveling to India. Such fame and notoriety adhere to the actors, not the characters. — SMcCandlish☏¢ 😼 05:11, 31 March 2021 (UTC)[reply]
Administrator note I left this section open (separate from the close above) as I believe this discussion is badly needed. However it's not a discussion that requiers admin attention, and should probably be moved elsewhere. Ivanvector (Talk/Edits) 14:13, 11 April 2021 (UTC)[reply]
Is there are any interest in drafting a policy which would determine when standalone stubs of locations are allowed, and when they must be bundled into lists? Does anybody knows whether such a policy has been attempted, and whether it is an evergreen proposal? Pinging @Iridescent: who might know this.--Ymblanter (talk) 07:40, 9 April 2021 (UTC)[reply]
Just to make it clear, list vs standalone articles is a very broad scope questions; I am now only talking about localities (which I guess has at least some chances to be considered seriously).--Ymblanter (talk) 07:42, 9 April 2021 (UTC)[reply]
In addition to better notability guidelines, it would be helpful to have a policy that actually requires editors to demonstrate notability at the time of article creation. Many of Lugnuts' Cricketer stubs were created under the assumption that there must be significant coverage out there somewhere for anyone who has played in a certain number of matches at a certain level, and several editors are !voting Keep at AfD based on that premise even when the only source found is a database entry. –dlthewave☎ 15:18, 10 April 2021 (UTC)[reply]
Even WP:GEOLAND carries this implicit assumption (this is why it uses the language "typically presumed to be notable" rather than "are notable"). Even for legally-recognised populated places, we are only presuming they can make a WP:GNG pass if someone does the research deep enough. Maybe this behaviour was OK when simply doing this based on Sports-Reference.com for e.g., pole-vaulters (I don't think it is, but the consensus hasn't historically been against it), but as soon as you try to do GEO articles the same way you end up with something like the Iranian "village" case because geography is much more complex than sports statistics. The amount of grief we've had over the assumption that X in Persian/Azeri/whatever is the same as "village".... FOARP (talk) 18:50, 10 April 2021 (UTC)[reply]
Well, let us not overdo things. I have created for example this article today, and it is currently sourced to two databases (well, to one statistical document and one government dadabase-like site). I will return to it later (which may well be over several years) to bring it to this stage. However, I do not think any sane person can argue that it has notability issues, or even that it would be more beneficial to have it as am element of a list. My argument is that at some stage of the development (which needs to be formalized, but something like the article about a locality only contains the name, the native name, administrative division the locality is in, population, and coordinates), it is more advantageous to have it as an element of a list and not as a standalone article. Such article should be redirected to the list.--Ymblanter (talk) 19:17, 10 April 2021 (UTC)[reply]
"Presumed notable" under notability guidelines does not mean that this necessarily needs to show the type of sources that meet SIGCOV, only that the article can be shown to meet criteria that is likely to lead to more SIGCOV for notability. Most notability guidelines are merit based (like winning a Nobel prize) and this approach makes sense, but the issue are cases in GEOLAND and NSPORT where simply proving something/someone existed at a certain level is a presumption of notability (in the case of NSPORT, having played a professional level game is the presumption that the person had to have a prior career to get to a professional level that can be documented). I'd also note that any approach like this would have to be aligned with CSD which has purposely rejected any "notability" factors and uses a far lower bar to allow articles to be kept. --Masem (t) 14:42, 11 April 2021 (UTC)[reply]
I would support such a policy, especially if it applied to sports as well. How hard is it to find one SIGCOV source? If you don't have access to refs but expect them to exist, it seems much more reasonable to put the subject in relevant lists and make a post in the relevant wikiprojects asking if anyone else does have access. JoelleJay (talk) 20:28, 10 April 2021 (UTC)[reply]
Do you consider a locality as a place falling under WP:GEOLAND? Part of the lack of clarity here comes from the definition of WP:GEOLAND, I think. SportingFlyerT·C 15:10, 11 April 2021 (UTC)[reply]
Yes, localities fall under GEOLAND, but there are a lot of other things which fall there, and which can not be treated the same way.--Ymblanter (talk) 15:17, 11 April 2021 (UTC)[reply]
My biggest gripe with geographic (and sport) stubs is not there existence but its that they clutter random and will discourage any reader/editor from pressing the button more than a few times. Quality articles have little chance of being discovered when they are drowned out in all the noise. So I would support any attempt to reign in stubs and replace them with descriptive lists.
For localities, Stub policy should be modified to explicitly prohibit creation of an article when the only information is available is database entries. A minimum of a history, geography, or other informative section should be required. Slywriter (talk) 16:19, 11 April 2021 (UTC)[reply]
I second what you've said above. Störm(talk) 21:46, 11 April 2021 (UTC)[reply]
@Slywriter: I'm not sure about this. I've found our locality stubs on US locations are pretty good, say Lake George Township, Hubbard County, Minnesota (selected at random). Sure, it's not great, but it's better than nothing. I'm pretty sure everything in said article, other than the name history (which isn't really significant), came from databases. Would your proposal be against that type of article? Elli (talk | contribs) 22:25, 11 April 2021 (UTC)[reply]
Elli, it's better than Meryemköy,_Çıldır but all the reader has learned is the US census data and outdated census data at that. So unless someone bothers to update that article next year, it will be two censuses behind current times with little hope of anyone every updating. A list of townships in Hubbard or Minnesota with links to us census, wikidata or other data points would serve readers better long term as a single page can be updated to point to the most current data and preserve historical data. Slywriter (talk) 23:26, 11 April 2021 (UTC)[reply]
I'll third the Random button comment. It serves no purpose at this point unless you want to discover dozens of stubs of football players and plant cultivars. JoelleJay (talk) 03:25, 12 April 2021 (UTC)[reply]
Not limited to stubs, not limited to locations; every new article creation should cite at least one reliable, indepth source. Articles lacking this should be tagged for improvement, and then (after a week or so) either moved to draftspace or redirected to a list (if a relevant list is available). Fram (talk) 07:56, 12 April 2021 (UTC)[reply]
The random function could be easily configured or parameterised to include or exclude specific types of content, depending on the user's requirements. For example, I most often see "random article" in the Wikipedia iPhone app, which I browse daily. This seems to be already filtered so that only articles with images are shown.
Trying the app's randomizer, I soon find Dolany (Kladno District) – a Czech village. This is a stub but notice that it has has an image and infobox and so looks fine. Notice also that it has no citations – just an {{authority control}} entry. It was created from the corresponding article in the Czech wikipedia. Notice that the topic also exists in many other language Wikipedias and so is generally accepted as valid.
If editors want to flesh this stub out then that's what they should do. Deletion would be a retrograde step and therefore disruptive. Creating yet more rules would be contrary to policy per WP:CREEP.
Yes an article that has a history section in Czech, has image galleries on commons and other points that show someone took effort in at least one language, and didn't just drop a line from a database
The mission also calls for wikipedia to last a 100 years, tens of thousands of one line articles that require updating to be relevant are of no help to future editors and readers.(Nor are database dumps of single game sports professionals nor genus/species articles that could be handled at the genus level because nothing is known about any of those species. And there is little call to delete the data, it's about changing how it is organized so there are less articles and more relevant lists/charts to capture these one liners. Slywriter (talk) 20:00, 12 April 2021 (UTC)[reply]
Nganzun, created in 2008, has two additional stub articles hierarchially above it before you get to an en-wiki article with any relevant information at Mandalay_Region. The Burmese wikipedia is marginally better though even there Nganzun and Nganzun Township could easily be one article, but better yet both could make Myingyan District an actual relevant article and editors have only one article to update going forward. Instead, 3 articles will languish untouched for decades. Slywriter (talk) 20:34, 12 April 2021 (UTC)[reply]
Burma and Bangladesh got hammered with loads of "village" stubs created by-bot/bot-like-editing by Dr. Blofeld (now Encyclopædius) back in 2008 or so. Almost none of them have been touched since. The articles were created from GEOnet data but - very importantly - what GEOnet calls a "populated place" can be literally anything that people might live/work in and many of the places it describes as "populated" may never have been populated (it's not like they send investigators out to check or do any work to validate the data they present). Nganzun doesn't even have that.
"Spray and pray" stub creation really is just a bane. FOARP (talk) 07:28, 13 April 2021 (UTC)[reply]
Creating articles that are simply statistical data presented in prose-format is simply bad editing - everything Rambot added could have been (and probably was) a single line in a table and would have been more concise and more easily comparable to other places presented that way. I think we can and should do better than that. I will, however, say that using a bot to do this is still better than the cut/paste stuff that Carlos, Lugnuts, and Dr. Blofeld were doing, since human error is reduced. FOARP (talk) 08:18, 13 April 2021 (UTC)[reply]
I have mixed feelings about geostubs, but oppose any new policy restricting their creation. There are a few good things about geostubs, even ones that languish un-edited for long periods of time. A few I can think of off the top of my head: 1) When we have an article, it allows readers to easily navigate to corresponding articles in other languages that may be better. 2) They provide infrastructure for new editors who may not be equipped to start an article from scratch with appropriate navbox/coords/etc. but who may be able to productively contribute to an already existing article. 3) For a similar reason, redirects to existing table-type articles probably discourage the creation of new geographic articles (someone who sees a table may think, but where could i add information about the history of this place?). And to the extent you say, well let's not use redirects, then, only the search function, then you have a problem where multiple places have the same name, which is a very frequent occurrence. And that makes things difficult for readers. Calliopejen1 (talk) 19:14, 20 April 2021 (UTC)[reply]
Oppose any kind of mandatory merging/listing rule. There are definitely circumstances where that is appropriate, but just because something is short doesn't mean it isn't better as a standalone page than a line of an endless table or list. Redirects to sections or rows in tables are very easy to break and imagine trying to deal with that on a mobile device. postdlf (talk) 19:44, 20 April 2021 (UTC)[reply]
Why doesn't Wikipedia require editors to be 13 or older?
Most websites with user interaction require the users to be 13 or older. I think that having a minimum age would somewhat reduce the amount of vandalism on the website. How come Wikipedia doesn't have a minimum age? Félix An (talk) 14:39, 11 April 2021 (UTC)[reply]
I suppose you could ask people to state that they are 13 or older, such statements might not be true tho.Selfstudier (talk) 14:42, 11 April 2021 (UTC)[reply]
This is impossible to enforce. One can add such a clause to the terms of use, but vandals do nt care about terms of use anyway.--Ymblanter (talk) 14:43, 11 April 2021 (UTC)[reply]
"Most websites ..."[citation needed] Most vandals don't log in anyway. And readers can use accounts for other things than editing. PrimeHunter (talk) 14:56, 11 April 2021 (UTC)[reply]
Websites do that because the Children's Online Privacy Protection Act limits what personal data can be collected from those under 13. Wikipedia is not in the habit of collecting information, so it doesn't have that particular age concern. --Nat Gertler (talk) 15:02, 11 April 2021 (UTC)[reply]
Not only does WP not actively collect the kind of user information that such laws and regulations are concerned about, we actually advise young Wikipedians to not reveal their age or other private information. Roger (Dodger67) (talk) 16:06, 11 April 2021 (UTC)[reply]
Nobody should be pre-judged to be a vandal simply because of their age. And most vandalism by under 13s would not be very subtle, so would be easily spotted and reverted. It's the subtle, more hidden, vandalism that we need to worry about most, and most of that comes from older editors. If we are to ban people from editing because they might be a vandal we will have to ban everyone (even me, aged 63) from editing. Phil Bridger (talk) 15:50, 11 April 2021 (UTC)[reply]
As noted above, we don't really have a mechanism for enforcing an age verification requirement for WP editors on the scale suggested by the OP. We do have the WP:CIR guideline which in practice does weed out most very young editors. Personally I believe it would make sense to have a minimal age requirement for the admins, if only for legal reasons. Nsk92 (talk) 16:14, 11 April 2021 (UTC)[reply]
@Nsk92: there is such a requirement for Checkusers, Oversighters, and ArbCom members. Elli (talk | contribs) 21:04, 11 April 2021 (UTC)[reply]
@Félix An: why should it? A minimum age wouldn't reduce vandalism in the slightest, from what I can tell (I'm sure wanna-be 12-year-old vandals would just lie). Elli (talk | contribs) 21:04, 11 April 2021 (UTC)[reply]
The reason many websites have a requirement for the minimum age (13) is because of COPPA, which does not apply to Wikipedia as we do not collect, use, or disclose a user's age. Izno (talk) 23:02, 11 April 2021 (UTC)[reply]
For what it's worth (and this is peripheral), I believe that in the early days of Wikipedia there were administrators that were even younger than 13 and I can think of an incumbent who was 13 when they passed RfA. Questions of age of course come up in RfAs, with many voters unwilling to vote for minors. There's also the case of on the Internet, nobody knows you're a dog. Sdrqaz (talk) 17:10, 11 April 2021 (UTC)[reply]
Ah, that's an interesting bit of history, Graham (with a bit of commentary regarding Malleus sprinkled in). Are you aware of any successful RfAs for minors in the "modern" era? I'm reminded of this 2015 RfA, which I had stumbled on a week or so ago, where about half of the opposes were about age (and the candidate was older than many of the more extreme examples too). Sdrqaz (talk) 12:41, 12 April 2021 (UTC)[reply]
@Sdrqaz: Nope, I don't know of any. Graham87 13:40, 12 April 2021 (UTC)[reply]
I can't think of a recent succesful RFA by someone believed to be a minor, it would not surprise me if our youngest current admin is older than a teenager. There are two things that have made the community less open to adolescents in the last decade or so, the expectation to use inline citation, and a mobile platform that makes Wikipedia apig to edit on smartphones or tablets. This doesn't just give us a serious ethnicity skew, but we underrepseent the smartphone generation. ϢereSpielChequers 08:34, 13 April 2021 (UTC)[reply]
@WereSpielChequers: The smartphone generation of dedicated editors doesn't exist. While exceptions exist, smartphones are used by consumers of media and beyond photos and video not so much by creators. Wikipedia is a pig to edit on smartphones or tablets because those devices lack a physical keyboard. Nobody writes a book on a smartphone. They may fix a typo here and there, add a category or even a reference, but are much less likely to add a whole section. — Alexis Jazz (talk or ping me) 16:23, 13 April 2021 (UTC)[reply]
@Alexis Jazz: Writing on mobile isn't so bad: I've found that glide typing speeds it up and when you're used to typing on mobile, touch-typing is actually possible. The point about consumers of media seems about right, though. Sdrqaz (talk) 16:31, 13 April 2021 (UTC)[reply]
@Sdrqaz: I suppose you could get used to anything, but even on a netbook keyboard I would probably still beat you on both speed and accuracy. The problem isn't just the keyboard either: the screen on a tablet or large phone would be almost adequate, and for the consumption of media it essentially is, but when you start typing the keyboard takes up a large portion if not all of that screen. It may not be impossible to write text on a mobile device if you are trained in that, but anyone who really wants to write more than a short social media comment or fix a typo on WP is likely to ditch their mobile device for something with a physical keyboard. So to circle back, Wikipedia doesn't underrepresent the smartphone generation, smartphone users underrepresent Wikipedia. Which just makes sense. Fiat Pandas are fine everyday cars but underrepresented in stock car racing and that's unlikely to surprise anyone. — Alexis Jazz (talk or ping me) 22:37, 14 April 2021 (UTC)[reply]
I have a Fiat Panda, and I have a smartphone. I'd rather edit Wikipedia with the Panda than with Wikipedia's mobile interface. DuncanHill (talk) 23:11, 14 April 2021 (UTC)[reply]
WereSpielChequers, that's interesting. I was thinking about it more in the sense of shifting RfA standards rather than a lack of representation. Personally, as a frequent "pure" mobile editor (using the mobile website, not the desktop site on a mobile à la Cullen), the interface is adequate (faint praise perhaps). You can't use Twinkle or RefToolbar without the Cullen method and it's difficult to have two windows open at once for better writing, but it's not as terrible as others say (the app on the other hand, is a different story). Inline citations can be done by having Template:Cite web open in another tab and copying the skeleton over or typing out the parameters manually once you've remembered it.I would've thought that all things being equal (if we disregard the changing standards at RfA), the admin corps would have younger inductees than a decade ago because younger editors wouldn't have to wait their turn at the family computer and could just edit any time, any place.Chequers, were the successful candidacies of minors because voters didn't care about their age or didn't know? Or maybe those who knew didn't publicise it so the rest of the voters didn't know? Sdrqaz (talk) 16:27, 13 April 2021 (UTC)[reply]
I have looked back on two RFAs from ladies who I'm pretty sure were young when they passed their RFA. One in 2010 was a close call in numbers, in hindsight my own oppose there was over harsh and I've since only opposed for faulty deletion tagging where I've found multiple mistakes. One of the opposes in that one was explicitly because she was a schoolkid, but no subsequent opposes mentioned that or the maturity word, and quite a few opposes were of the "you're almost there come back in a few months" type, which I doubt were ageist. In 2007 I found one where there was a neutral vote "I cannot bring myself to support someone so young" but the RFA passed 90 to 1. Which fits my memory that the community didn't used to see it as a problem to have very young admins. I can remember a couple of narrowly unsuccessful ones in 2009, one of which had several editors cite "maturity concerns", but in both cases there were recent mistakes. So I'd say the community used to knowingly appoint teenage admins. I have vague memories of a more recent RFA where expectation had become more common that admins should be legally adult. ϢereSpielChequers 20:50, 13 April 2021 (UTC)[reply]
Interesting stuff, WereSpielChequers, thank you. I think I am aware of which 2007 RfA you're referring to; she unusually had a reconfirmation shortly after. Looking at a 13-year-old candidate in another, they sailed through with 98% support without anyone bringing up age, so I'm not sure if anyone else was aware of their age at the time. Maybe the one you're thinking about that was more recent was this 2015 one? It seems around half of the opposes were based on age. Sdrqaz (talk) 21:53, 13 April 2021 (UTC)[reply]
Almost certainly it was, at 15 he was older than at least one of the uncontentious ones from a few years earlier and most of the age opposes were on the principle of his age - there was also a huge amount of kickback in the support column from people who rejected the ageism in the oppose column. I'm pretty sure something changed insde or outside the community in the intervening years to shift Eric Corbett's view from an outlier to a large enough minority to probably derail an RFA. The only thing I can think of that might account for the shift is the Catholic sex abuse scandal and the role of admins in keeping certain things off the pedia and having access to deleted edits. I will leave it to some future researcher to work out whether a group of editors changed their views on young candidates or if this was the RFA electorate changing. Or indeed that by 2015 the community no longer had many teenagers or at least teenage admins. But clearly things did change, and I doubt they have changed back. I think the RFA crowd has long been capable of spotting very young candidates. ϢereSpielChequers 07:25, 14 April 2021 (UTC)[reply]
I recently came across a BLP article that was being actively vandalized by an IP who was repeatedly re-adding an obscene pornographic image to the article to the infobox instead of the photo of the subject. As I was reverting the IP, I saw that the IP got blocked, and then I received a nasty e-mail through my Wikipedia e-mail with a threat of violence. Shortly after I saw that the blocking admin revoked the IP's talk page and e-mail access (I assume the admin received a similar message). I am pretty sure that the responding admin in that case was an adult, but in general I think we should not be putting minors (e.g. 15-year-olds who happen to be admins) in the position of having to address these kinds of situations. Nsk92 (talk) 13:22, 18 April 2021 (UTC)[reply]
A minimum age wouldn't really reduce vandalism because of the ability to edit anonymously. If it required users to click a button stating that they are 13 or older, the anyone could just click the button, regardless of whether or not they are 13. Also, the problem with this is that laws are different in different places. For example, one place might have a law stating the minimum age to have a forum account is 13 while another place might state is 18. Wikipedia is accessible to people from all over the world. So if we just set it to 13, it would cause problems for users who edit from places where the minimum age is below 13.
@Nsk92: That's an interesting argument – quite a lot of the opposition to teen admins is based on perceived immaturity/impaired judgement rather than as a child protection measure. Regarding just email, you could disable the ability of brand-new editors to email you, but of course hostility is also on-wiki. Sdrqaz (talk) 22:50, 18 April 2021 (UTC)[reply]
I think I remember one editor who made good edits to dinosaur articles was less than 13 when they started, so I'm not sure why we need to exclude them on that basis. FunkMonk (talk) 14:00, 12 April 2021 (UTC)[reply]
So, you admit to having made your first edit pre-conception. Please may I borrow your time machine? --Redrose64 🌹 (talk) 10:57, 13 April 2021 (UTC)[reply]
Excluding those adolescents who obey rules such as don't edt until you are 13 won't lose us any vandals. It might lose us some goodfaith editors, and it might even attract some vandalism from adolescents who want to show that they can hit the edit button even though they shouldn't. So I don't see any benefit from this proposal, and there is a small disbenefit. ϢereSpielChequers 08:40, 13 April 2021 (UTC)[reply]
Agree . If this were feasible to enforce, it'd be worth discussing. It's not, so it isn't. {{u|Sdkb}}talk 18:21, 13 April 2021 (UTC)[reply]
In the US, COPPA applies to all personal data, even if voluntarily posted (contact info on a userpage for instance), if the operator is aware that the user is under 13. Nonprofits, however, are exempt. We follow best practices by oversighting such personal info when we come across it. –dlthewave☎ 20:23, 13 April 2021 (UTC)[reply]
Yes. Also, apropos of young admins, I can think of an arbitrator way back when who was 14, or possibly 15. A good arb, too. Bishonen | tålk 12:24, 23 April 2021 (UTC). Trimmed, BEANS reasons. Primefac (talk) 12:56, 23 April 2021 (UTC)[reply]
In Europe, wouldn't Article 8 of the GDPR apply? Personal data is processed (IPs, email addresses). But I guess the WMF has figured this out with their lawyers. ProcrastinatingReader (talk) 12:37, 18 April 2021 (UTC)[reply]
Undisclosed alternate accounts
For purposes of this discussion, "undisclosed" can be taken to mean "not publicly declared" regardless of whether the account has been disclosed to ArbCom or to a CU, or was discovered without voluntary disclosure. This discussion is aimed at "privacy alts", secondary accounts created for editing certain topic areas the user would prefer not to edit from their primary account.
Background
Since the early days of the English Wikipedia, there has been a tradition or custom of some users having either known or undisclosed alternate accounts. This has held over to some extent into the modern era of the project and is enshrined in policy at WP:VALIDALT. Publicly disclosed alternate accounts are fully free to edit in any way with few restrictions; however, WP:PROJSOCK states that undisclosed accounts may not edit the Wikipedia namespace. English Wikipedia is something of an outlier in this regard: many other WMF projects regard undisclosed alternate accounts as illegitimate sock puppets. Therefore, behavior that is technically acceptable at EN.WP can have serious consequences if practiced on many other WMF wikis. Existing policy makes it clear that private disclosure to ArbCom or individual functionaries does not allow for policy violations, but this is often misunderstood by users and can lead to frustration both on the side of users and of CheckUsers.
Issues
A blanket ban on undisclosed alternative accounts editing project space results in a situation where content created by an alt could be under discussion, for example via WP:AFD, or the user's behavior may be under discussion at forums such as WP:ANI and by the letter of current policy, the user cannot participate in those discussions at all.
Only the Arbitration Committee has access to the list of known undisclosed alternative accounts. This information is considered private and generally cannot be shared, even with checkusers. This means a user could have disclosed their alt account to the committee, only to be blocked for socking, and the connection between the accounts publicly revealed, in the course of a legitimate sockpuppet investigation.
There is not actually a hard obligation to disclose alternative accounts at all, to anyone. It is therefore likely that the accounts known to the arbitration committee or individual checkusers are mostly those who would not abuse them anyway, and represent only a small portion of the total number of such accounts.
There is no reasonable way to police all the edits of all known alternative accounts to ensure they are within policy.
Proposed remedies
Not anyone else's problem Change language of policy to actively discourage using privacy alts and to make it clear that if the connection is discovered it is not the responsibility of the community, the functionaries or the Arbitration Committee to conceal it. If the connection is made clear by the privacy alt's behavior, that is the fault of the account operator.
Clarify WP:PROJSOCK: Carve out narrow exemptions to the project space ban for deletion discussions related to content created or edited by the alt account, or discussions of the alt accounts' own behavior. Broader discussions on site policy, other users behavior, etc, are still strictly off limits.
No longer allowed at all: The use of privacy alts is to be considered deprecated and removed from policy. Any user operating more than one account without publicly linking them for any reason will be subject to the sockpuppetry policy. This would not apply to legitimate clean start accounts where one account was abandoned before the new account began editing. (this option is mutually exclusive with the other proposed options)
Discussion of proposed remedies
I've opened this discussion because some recent events have revealed a number of issues, identified above, with the policy on private alternative accounts. The first remedy in particular I feel pretty strongly about. Privacy alts are at-your-own-risk. If you screw it up and are detected, whoever you disclosed to can verify that you disclosed an alt to them, but that doesn't obligate that user to then cover up the entire affair. Generally, private alt accounts are just a bad idea, and we should probably be more stringent in discouraging them, and also making it clear that disclosing is not a free pass to otherwise violate the socking policy. On the second remedy, it's just not fair that we allow these accounts for privacy reasons, but by the letter of policy they cannot contribute to any project-space discussion, even if it is about their own behavior or content they created. The third remedy, I threw in there in case it happens that the community just wants to end this practice altogether, as many other projects have. I've not proposed specific wording, this is more about looking for consensus on the ideas, the wordsmiths can get in there and create the appropriate wording if such a consensus is reached. Beeblebrox (talk) 22:15, 15 April 2021 (UTC)[reply]
Beeblebrox, Thanks for starting this discussion. I suspect it will attract enough attention that maybe you want to break it out into its own subpage? -- RoySmith(talk) 22:23, 15 April 2021 (UTC)[reply]
One thing I'd like to see added to option 2 is permitting undisclosed alts to ask questions at appropriate venues (Teahouse, Help Desk, that sort of thing), since the letter of the law says those are projectspace but those aren't exactly policymaking venues. People also ask legitimate questions at the village pumps, but I'm not sure whether to include those in this exception since those are more "internal project policy discussion" venues. GeneralNotability (talk) 22:17, 15 April 2021 (UTC)[reply]
Question: I understand the reasons for public alt accounts (such as having an alt for public computers or at work), but what are the reasons (in the past, at least) for allowing undisclosed/private alt accounts? Schazjmd(talk) 22:21, 15 April 2021 (UTC)[reply]
I would like to know this too. I don't have an issue with undisclosed alt accounts that would out someone who isn't paid but if you don't want to potentially connect yourself to your employer, a simple solution is to not edit about them. No one is forcing you to and conversely, no one is forcing you to edit Wikipedia at all. TAXIDICAE💰 22:27, 15 April 2021 (UTC)[reply]
See the comment directly below for one example. Often it's a matter of not wishing to "out"some specfic aspect of their life, either something mundane as mentioned below, or perhaps editing controversial topics on religion or sexual practices. Beeblebrox (talk) 22:32, 15 April 2021 (UTC)[reply]
@Schazjmd: that's a good question. The common old-school example for why someone would have a "secret" alt is to edit embarrassing subjects, e.g. certain sexuality topics. Another possibility is to edit a topic, which editing with the main account may compromise the user's privacy. Another possibility could be an existing Wikipedia editor having assigned coursework that involves editing Wikipedia, and would not want that associated with the main account, either from either side so to say (on-wiki in terms of an association with a given university, or having university colleagues know the existence of the main account). In some cases there are real-world implications in that Wikipedia editors may experience trouble with local authorities as a result of certain edits. At the end of the day we are a project that permits pseudonymous editors. Short of running certain mass checkusers—something that is a non-starter as far as the privacy policy goes—we ought to accept that there is not much one can do about someone using two accounts to edit separate topics. Of course, there are obvious deceptive uses of multiple accounts; think of vote-stacking an AfD or cases where a banned user uses multiple accounts to evade the ban to continue the same disruption that led to the ban. That said, it ought to be considered whether the simple fact of using an alternate account is somehow a problem. Maxim(talk) 23:34, 15 April 2021 (UTC)[reply]
I hope the third suggestion isn't going to be taken seriously. I have a some photos I've been meaning to add to a few articles when I get around to it. These photos could be traced back to my real-world identity. Should I really have to choose between adding the photos, and outing myself? Because I see no other way to add the photos than create a "privacy alt". Suffusion of Yellow (talk) 22:24, 15 April 2021 (UTC)[reply]
I assumed someone would propose it during the course of the conversation, so I just put it out there. Beeblebrox (talk) 22:32, 15 April 2021 (UTC)[reply]
Suffusion of Yellow, regardless of the above changes, using a separate account only to upload pictures shouldn't put you at any risk. Blocking someone for using multiple accounts requires behavioural evidence (with or without technical evidence), so the chance of someone connecting those two accounts is practically zero. (Yes, mistakes happen, and checkusers occasionally run checks they shouldn't, but that's also why oversight exists.) – bradv🍁 23:27, 15 April 2021 (UTC)[reply]
It doesn't matter whether you would be caught for uploading the images. It matters that it's against the rules. I've been in similar cases to Suffusion of Yellow and agree that the third suggestion is ludicrous. If there is a common use case of people evading a rule with no harm done, no way of detection and in a way that nobody could possibly object to then it is a bad rule. Though in my case it would actually stop me uploading pictures altogether, because I would follow the rule even if it's pointless and unenforceable (too high consequences for too low a reward). (And though Commons isn't under our scope, this soft redirect and the fact I have used or would use an en.wiki account to add the uploaded images to articles means that this is our jurisdiction.) — Bilorv (talk) 12:17, 16 April 2021 (UTC)[reply]
I would really only support 2 as worded, and could support 1 if language about "actively discouraging" is removed. I've never used an alternate account, but I respect that others may find it necessary. I agree that no one is ever under any obligation to keep knowledge of someone else's secondary account secret, HOWEVER, I also can understand legitimate reasons to use a secondary account. We should still discourage good hand/bad hand accounts, or similar purposes, such as participating in policy discussions while concealing prior activity on Wikipedia, but I do agree that exceptions need to be allowed for when the alternate account has itself an interest in the discussion, such as AFDs for articles where the account is a contributor. However, Wikipedia should neither encourage nor discourage the use of private alts with the only caveat that actual violations of community trust are likely to have consequences. --Jayron32 22:35, 15 April 2021 (UTC)[reply]
(This thread moved from its own section originally entitled A difficult example): Let's assume I'm a member of International Flat Earth Research Society, and I've made many posts edits from my personal account (with a non-PII account name) espousing this viewpoint, including vigorous participation in AfDs and other WP-namespace pages. In my day job, I'm employed by NASA where my job responsibilities include computing trajectories for space missions. I haven't told my employer of my flat earth beliefs because that knowledge would impact my career advancement. Assume for the moment that despite my private views, I'm good at my job. One day, my boss comes to me and says, "We need a WP:Wikipedian in Residence to curate articles about NASA, and you're it. Your job responsibilities will include being active in discussions about what articles to keep or delete". The "No longer allowed at all" option would put me in a bind. There's no way I can perform my job without either breaking our socking policy or outing myself to my employer. If you don't like my NASA example, I'm sure you can think of similar situations. — Preceding unsigned comment added by RoySmith (talk • contribs) 22:41, 15 April 2021 (UTC)[reply]
Aside from the absolute absurdity of this example, your career advancement isn't Wikipedia's problem, nor should it ever be. You can turn down a WIR or come clean - transparency is key here. You don't have to dox yourself by adding your full name or even first name. Disclosure doesn't require identifying yourself. WIR is another matter and not really relevant to this discussion. TAXIDICAE💰 22:47, 15 April 2021 (UTC)[reply]
Praxidicae, Why is the example absurd? We have many examples of people who edit as a requirement of their employment. A department in a University wanting every faculty member to have a wikipedia page and assigning that job to some low-level person in the department office. We've seen that scenario multiple times. -- RoySmith(talk) 22:56, 15 April 2021 (UTC)[reply]
And that person is welcome to decline that request from their employer if it would violate the sites terms of use for the same reason an employer demanding an employee break a law or policy should be declined. No one forces you to edit as a volunteer or a paid editor and our policy is already clear enough on that. TAXIDICAE💰 23:25, 15 April 2021 (UTC)[reply]
RoySmith, in this case you could just stop editing from your previous account. Using serial accounts does not constitute sockpuppetry, unless you are subject to a block or ban. – bradv🍁 23:15, 15 April 2021 (UTC)[reply]
But what if they are subject to block or other restriction. Continuing the NASA example, our theoretical editor (let's called them Tarquin) is presumably a generally good contributor and net positive to the encyclopaedia but perhaps they are topic banned from editing articles about the phantom time hypothesis or they have a mutual interaction ban with another user? If Tarquin just stayed away from those topics/editors we probably wouldn't be any the wiser, but it would be a breach of policy and obviously the other party to the interaction ban would not know to stay away from the new account. Thryduulf (talk) 01:28, 16 April 2021 (UTC)[reply]
If someone is subject to a ban they shouldn't be creating a new account or accepting a paid editing position – especially not without being fully transparent with both their employer and the editing community. That's currently prohibited by both our sockpuppetry policy and our paid editing policy, and none of the proposed changes above would alter that. – bradv🍁 02:07, 16 April 2021 (UTC)[reply]
@Thryduulf: I think you could have picked a betterexample for a username. :-) That user's very familiar to me for his early work in mathematics and classical music articles. I don't think I ever spoke to Tarquin personally but his name is very familiar to me in page histories and on old talk pages. I hope he'd be as amused by this as I am; I've mentioned it on his talk page. Graham87 08:46, 16 April 2021 (UTC)[reply]
In a paid WiR role, you are already mandated to disclose your alternative accounts under current policy Wikipedia:Paid-contribution disclosure#How to disclose: "paid editors must provide links to the user page(s) of their Wikipedia account(s) on each website on which they advertise, solicit or obtain paid editing services, as well as in direct communications with each client and potential client (such as through email). If the paid editor has used or controlled more than one Wikipedia account, each account must be disclosed." This was added in a recent RfC. – Finnusertop (talk ⋅ contribs) 23:17, 15 April 2021 (UTC)[reply]
Whether and to what extent that applies to Wikipedians in residence is not at all clear. It is also completely and utterly unenforceable because we can (and should) never know the contents of all private communication, as was pointed out repeatedly when it was proposed. I'm also dubious that stipulating the content of communication between employer and (potential) client is something that it is even legal for a third party to place restrictions on. Thryduulf (talk) 01:01, 16 April 2021 (UTC)[reply]
I explained my concerns with WP:PROJSOCK elsewhere. I can only see what I can read from the history, so perhaps someone who was actually there knows the context better and can point out any errors, but its current enforcement doesn't make sense to me. Most illegitimate uses are obvious why they're disallowed; you can't use multiple accounts to pretend to be multiple people in a way that bolsters your position, avoids scrutiny, or deceives editors. But PROJSOCK isn't intuitive in the same way. It's cited to an ArbCom case from 2007 where the evidence was an editor abusing multiple accounts to participate in policy discussions whilst avoiding scrutiny. The community appears to have narrowly worded it to this (and similar variants) for years after the case, clarifying that Alternate accounts should not edit policies, guidelines, or their talk pages; comment in Arbitration proceedings; or vote in requests for adminship, deletion debates, or elections. That all makes sense, and directly follows from the case evidence too. Then in 2014 someone boldly edited the page to the vaguer "quote[] from the underlying Arbcom decision" which says Undisclosed alternative accounts are not to be used in discussions internal to the project. As a reader, discussions internal to the project is ambiguous whether it means a namespace ban or (indeed, as the original interpretation appears to have been) just consensus discussions, and a Wikipedia namespace ban doesn't logically follow from the evidence in that case. Asking questions in venues (including WP:VPT, which whilst is a "village pump", it's used for asking questions not consensus discussions on making policy) is totally fine, for example. That 2014 edit, at least as interpreted now, appears to have been a material change. Was there a discussion leading up to that? Why is the WP namespace more of a problem than any other NS? ProcrastinatingReader (talk) 22:44, 15 April 2021 (UTC)[reply]
(based on your old sandbox I've presumed option 1 includes CUs disclosing connections) Presumably users can be subject to discretionary checks for various reasons, and the CU policy is rather vague on what is grounds for a check. So, reading that option now, a discretionary check could result in a privacy account popping out (possibly already disclosed to ArbCom which the CU wasn't aware about, but even if not we don't treat ignorance of policy as deliberate attempts to violate policy), so the CU goes ahead and links the two accounts publicly. So basically you'd have CUs outing editors, with solid technical evidence to dispel any doubt too. Which just isn't fair on its face. ProcrastinatingReader (talk) 22:57, 15 April 2021 (UTC)[reply]
My tenure on the Arbitration Committee, and as a checkuser, made me aware of plenty of situations where the use of an alternative account was the only legitimate way to continue participating on the project. I also saw any number of situations where legitimate use strayed into illegitimate. This was often by accident, but if someone sees that slip, the cat is not getting back in the bag. The conflict between alternative accounts and Wikipedia's commitment to transparency is unresolvable. I'll defer to the current committee on whether they think the present system is sustainable. Personally, I wouldn't want to be entrusted with that information, and if I were seeking to avoid scrutiny and still edit Wikipedia (a difficult task), I would be loath to disclose that information to anyone. Mackensen(talk) 23:01, 15 April 2021 (UTC)[reply]
Mackensen, I've just noticed that you were part of the Committee that passed the principle that led to PROJSOCK (Wikipedia:Requests for arbitration/Privatemusings § Sockpuppetry). What was the reasoning behind it? The first two sentences are intuitive, but I don't understand that final restriction. Pinging those members of the Committee.Sdrqaz (talk) 21:57, 16 April 2021 (UTC)[reply]
Sdrqaz wow, what a fucked up thing {{bcc}} is. How in the living hell is a recipient supposed to know where on the page they've been bcc'd? Otherwise, my opinion about sockpuppetry (I hate that term) is the same it was back then: "Should be generally forbidden. Wikipedia is not a role-playing game." But I wasn't going to win that argument, which is why I've divorced myself from all involvement in Wikipedia policy; I'm a sore loser.--jpgordon𝄢𝄆 𝄐𝄇 00:56, 17 April 2021 (UTC)[reply]
Sorry about that, jpgordon. I only use it when I feel there are too many people being pinged. Thanks for sharing your opinion on sockpuppetry. Sdrqaz (talk) 17:12, 17 April 2021 (UTC)[reply]
Sdrqaz, I don't think we thought we were saying anything new. See for example my comments at Wikipedia:Requests for arbitration/Privatemusings/Workshop#Alternate accounts: The use of an alternate account to stir up policy debates while the main account does something different has never been acceptable on Wikipedia. Sockpuppetry was understood to mean the abuse of multiple accounts; using multiple accounts non-abusively was frowned on but not banned. Maintaining a burner to stir things up on policy pages evaded accountability. Mackensen(talk) 23:22, 16 April 2021 (UTC)[reply]
I was pinged into this discussion. The contentious issue seems to be the natural justice of excluding undisclosed private accounts from the Wikipedia: namespace. My reaction here is "too bad". I would keep the principle, and just note that there may be mitigating circumstances for such editing. On the whole we want to know that users edit in good faith from single accounts in internal discussions, and I find said "restriction" natural at the level of ArbCom principles. Charles Matthews (talk) 07:12, 17 April 2021 (UTC)[reply]
Thanks, Mackensen and Charles. Mackensen, wouldn't such abuse fall under the "avoiding scrutiny" part of policy? I don't think PROJSOCKing should be encouraged (and the maintenance of accounts in the Privatemusings case arguably falls under that avoidance), but a blanket ban doesn't sit well with me. Sdrqaz (talk) 17:12, 17 April 2021 (UTC)[reply]
I would prefer that PROJSOCK be modified. There are cases where a privacy alt is useful. Just because we are not censored, does not mean the world is the same. They can be particularly useful in maintaining sexual health articles. A recent example is the RfD's for Tiny penis. It's reasonable to not want that at the top of your contribution history, and as long as the editor is not being deceptive or behaving in a way that will get them sus'd out, we should allow privacy alts in discussions of that nature and not actively discourage their use. — Wug·a·po·des 23:24, 15 April 2021 (UTC)[reply]
I generally back proposal 2. There are reasons for private accounts. While editors obviously can't be obliged to "cover it up", that does not mean that we have to pick an all or nothing approach. For example, a sockpuppet investigation could have the details revdelled if it was agreed no breach had occurred, but required major disclosure to demonstrate it. We wouldn't be any worse off, other than a few minutes of admin clerk time. Some minor amendments to the nature of proposal 2 to include helpdesks and so on in the exemption also seems reasonable. I had originally wondered "why not just switch back to the main account to ask", but realised that certain questions would require enough specificity to accidentally twin the accounts. One additional change I'd propose would be formally authorise ARBCOM to share details on private alts with CUsNosebagbear (talk) 23:52, 15 April 2021 (UTC)[reply]
If never the two accounts shall meet, why should we care? Absent seeking significant bits, is it really an issue if an editor manages to successfully maintain two alternate wiki personalities for years on end? The risks should be disclosed up front (option 1) and from there on, it should be on the editor to ensure the two personalities are never in the same venue. Once they catch the eye of a CU AND violate policy, then public revelation may be a consequence (though pointing to things like WP:BLP, we have expressed an aversion to exposure that could lead to real-world harm of subjects, though guess editors do not get the same courtesy). In short, it seems like we shouldn't be playing a game of gotcha until/unless pseudo-anonymity is not a core policy of en-wiki. Slywriter (talk) 00:07, 16 April 2021 (UTC)[reply]
A modified option 2 (with the warnings from option 1) is really the only practical option here, but instead of minor amendments it should be rewritten wholesale to focus exclusively on detailing what activities and behaviours are prohibited. For example we want editors to be able to highlight problems and potential problems with articles/project pages/technical issues, we want them to be able to respond to queries about their editing, we want them to be able to ask questions aimed at improving their editing, etc. We don't want them to misrepresent themselves as more than one person, we don't want them to !vote multiple times in a discussion, we don't want them evading sanctions, etc. All of these things are equally desirable or not desirable regardless of what namespace they happen to occur in. Asking for help on an article talk page is no different to asking for help at a Wikiproject page or the teahouse, discussing the reliability of a source on an article talk page is no different to discussing the reliability of a source at WP:RSN. Discussing changes to a template used on user pages is unquestionably a "discussion internal to the project" but I see no possible justification for excluding privacy alts from such a discussion, doubly so if they are excluded if the discussion happens in the Wikipedia namespace but not if it happens in the template talk namespace. If there are certain discussions such users need to be excluded from (and I'm having difficulty thinking of any) then we need to detail what those discussions are and importantly why they excluded (people are more likely to abide by rules they understand the purpose of that rules they don't). Thryduulf (talk) 01:17, 16 April 2021 (UTC)[reply]
I was writing something up, then Thryduulf put it in a far more elegant manner. I have no objection to private secondary accounts editing project space and would scrap PROJSOCK entirely. The standard provisions under WP:BADSOCK would apply, such as voting twice in the same AfD (though that would defeat the point of a "private" secondary account), voting twice in the same discussion, editing the same articles etc. Sdrqaz (talk) 01:24, 16 April 2021 (UTC)[reply]
Sdrqaz, I'm trying to think of any truly problematic behaviour that is prohibited under PROJSOCK but isn't covered by one of the other provisions, and I can't think of any. Scrapping that line entirely may, in fact, be the most straightforward solution. – bradv🍁 02:09, 16 April 2021 (UTC)[reply]
Thanks, Bradv. I'm open to changing my mind if someone puts forth a good argument, but I'm pleasantly surprised by how commenters so far are viewing it – I had thought mine would be a minority opinion due to a desire for transparency. Sdrqaz (talk) 17:56, 16 April 2021 (UTC)[reply]
Scrapping WP:PROJSOCK sounds good, given that all of the areas where editing project space creates problems appear to be dealt with by other restrictions. Tamwin (talk) 07:02, 16 April 2021 (UTC)[reply]
I agree that WP:PROJSOCK should be scrapped. As written, it doesn't make much sense because it may not be clear which account is the alternate and which is the primary. And it's not clear what "discussions internal to the project" means or why this matters. Andrew🐉(talk) 08:56, 16 April 2021 (UTC)[reply]
Scrap WP:PROJSOCK. The whole thing has contradicted Wikipedia:Clean start outright for years, even though the latter is policy (rather than essay). The only things we need to stop alternate accounts doing is evading scrutiny, bypassing editing restrictions and creating a false illusion of support for an action (and anything else uncontroversial I'm forgetting off the top of my head). Our rules here are ludicrous. Let's say someone edits as a child and gives away a bit too much personal information (not enough to dox, just enough for them to be concerned that combined with the topic of their edits or time zone or something else, it's enough to not wish to be public). Let's say that someone copies and pastes the wrong text without noticing, it's personal information and by the time it can be oversighted they're scared someone has seen and saved it. Or someone drunkenly writes something with stupidly much information. All three of these people have the choice between losing all right to privacy or never editing Wikipedia properly again (just mainspace edits is not "properly"). People here are underestimating how much information editors can unintentionally give away in behavioural evidence such as subject knowledge contributions, timestamps of edits, edits about localised topics etc., and how much some people value privacy. If an experienced editor wanted a new account just to stop the behavioural evidence piling high enough that they could be targeted then that's a plenty good enough reason. If someone starts an SPI based on a valid alt then you need to contact them by email or contact a CU/SPI clerk by email and explain the situation. The SPI should then be dropped, with the closure written to create as little suspicion as possible. Tough situation with no ideal solution but it's better than nothing. If you think your alt is now unusable because of the connection drawn, even though the SPI was thrown out, then start a new valid alt. — Bilorv (talk) 12:17, 16 April 2021 (UTC)[reply]
Bilorv, creating a new account, as long as the old one was not under some sort of sanction or block, is not and has never been sockpuppetry and does not violate PROJSOCK. It's only sockpuppetry (and that includes PROJSOCK) if you operate multiple accounts simultaneously. GeneralNotability (talk) 19:46, 16 April 2021 (UTC)[reply]
@GeneralNotability: says who? WP:SOCK says "The general rule is one editor, one account", "sockpuppetry, or socking, refers to the misuse of multiple Wikipedia accounts", "Editors must not use alternative accounts to mislead, deceive, disrupt, or undermine consensus" etc. No mention of whether you're operating them simultaneously. PROJSOCK says, in full, "Undisclosed alternative accounts are not to be used in discussions internal to the project", correct? The page doesn't define "alternative" but I've always taken it to mean "second or subsequent account created" (with complications in the case of IP editing). If that's not the case and I've not overlooked a definition, then it needs properly defining. It also seems to me that a counterexample to your comment is that WP:BADSOCK explicitly lists "Misusing a clean start", a term specifically referring to a new account operating never in conjunction with an old account, as an instance of sanctionable sockpuppetry. (Though this bullet point is almost the exact opposite of CLEANSTART, as the main use of a clean start is when you think you've been messing up and you want a chance to leave that baggage behind i.e. avoid some types of scrutiny. Another one to remove entirely.) I think we need a lot of discussions about how to rectify the many contradictions within SOCK and itself, and SOCK and CLEANSTART, and removing PROJSOCK is one of the things I would like to happen. — Bilorv (talk) 20:42, 16 April 2021 (UTC)[reply]
Bilorv, further down the page, under WP:SOCKLEGIT: Clean start under a new name: A clean start is when a user stops using an old account in order to start afresh with a new account, usually due to past mistakes or to avoid harassment. A clean start is permitted only if there are no active bans, blocks, or sanctions in place against the old account. (some further details follow that quote, but that's the gist). Also, If you are unable to access your account because you have lost the password or because someone has obtained or guessed your password, you may create a new account with a clean password. SPIs are routinely declined because the reported accounts operated sequentially. I concede that both of those say you're supposed to mark the old account as retired or (for lost-password cases) publicly declare the connection between accounts. With lost-password scenarios, however, odds are that the editor in question didn't actually read the sockpuppetry rules when they got locked out and created a new account, so that is fairly loosely enforced. GeneralNotability (talk) 21:11, 16 April 2021 (UTC)[reply]
@GeneralNotability: I'm struggling to see which of this text supports the claim creating a new account, as long as the old one was not under some sort of sanction or block, is not and has never been sockpuppetry, or which of it refutes any of the statements I made. — Bilorv (talk) 21:23, 16 April 2021 (UTC)[reply]
Bilorv, apologies, it's actually the context of those sentences (the fact that they're under WP:SOCKLEGIT, which is the section "Legitimate uses") which supports the claim. The heading of that section, in part, says Alternative accounts have legitimate uses. For example, editors who contribute using their real name may wish to use a pseudonym for contributions with which they do not want their real name to be associated (...) These accounts are not considered sockpuppets. and then goes on to list examples of legitimate alternative accounts, two of which I quoted in my previous post. I do, however, quibble with the terminology of "alternative accounts" since that (to me) implies the use of more than one account at the same time. GeneralNotability (talk) 21:35, 16 April 2021 (UTC)[reply]
@GeneralNotability: thanks, I think I understand better where you're coming from now, though I can't agree that the policy as written supports your claim. On the other hand, I think I agree that it should be written in a way that makes the claim unambiguously true. There are lots of problems here—"Inappropriate uses of alternative accounts" is including things which maybe don't fit the letter of this definition of "sockpuppet", but it's labelled WP:BADSOCK and everyone uses this as a list of sockpuppet behaviour. This definition of "These accounts are not consider sockpuppets" follows the section, rather than preceding it, and still leaves a lot of terminology specification to be desired. This is the sort of thing I'm referring to about SOCK contradicting itself—I suppose the base issue here is that I've been here 7 years and read the page dozens of times and I don't feel I understand clearly where the boundaries are. In general I don't like legalese and bureaucracy, but I do think we're doing a huge disservice to anyone navigating alternate accounts (or IP and logged-in editing) in good faith because they need to be able to say: here is an ironclad justification for my actions and if I ever have to defend them, here is unambiguous policy as written at the time I made these decisions. Or they need to know: actually, I can't do this, and here's the unambiguous reason why. — Bilorv (talk) 21:56, 16 April 2021 (UTC)[reply]
The more this discussion goes on and the closer I look at all the policies the more I see what a complete mess they are. Wikipedia:Sockpuppetry could do with a complete top-to-bottom rewrite to increase clarity, remove contradictions, and present everything in a logical order. For example several of the bullets under inappropriate uses are different examples of appearing as multiple people, there should just be a single prohibition on doing that with an non-exhaustive list of examples. Thryduulf (talk) 21:44, 16 April 2021 (UTC)[reply]
Absolutely, this is part of the point I'm trying to make (though I think I'm muddling it partly because I don't even understand what the rules are and aren't, so I struggle to suggest concretely what new version to change to). — Bilorv (talk) 21:56, 16 April 2021 (UTC)[reply]
@GeneralNotability: Question: Say you got a 14 year old doing some silly stuff and gets themselves indeffed. 4 years later they decide to give Wikipedia another try. Obviously it's not ideal to be continuing an account where one was adding obscenities to articles or something. So... they're expected to get an unblock on their main account, and then mark it as retired and then create a new one? If they've lost the password to the original, they're expected to reset it. If they've lost the email, then...? ProcrastinatingReader (talk) 09:24, 17 April 2021 (UTC)[reply]
Just to clarify the point a bit: I strongly oppose all three of the proposed remedies and feel they are a step backwards from the already inadequate status quo, though (1) is the least objectionable. — Bilorv (talk) 20:42, 16 April 2021 (UTC)[reply]
Scrap WP:PROJSOCK. I can't think of any behavior we want to disallow which isn't already covered by one of the other bullet points in WP:ILLEGIT. -- RoySmith(talk) 14:39, 16 April 2021 (UTC)[reply]
Scrap PROJSOCK per the others. Otherwise oppose all three options. Levivichharass/hound 15:44, 16 April 2021 (UTC)[reply]
Keep PROJSOCK, but can clarify; 1 and 3 are preferred I largely agree with Guerillero on this (also courtesy ping to Risker for some history on the topic.) I am fine with clarification on PROJSOCK that people can validly use it to comment on discussions directly relevant to them, but that isn't a reason to throw our the baby with the bathwater.There are several reasons behind PROJSOCK, but one of the main ones is that it provides a clear line for individuals rather than the rather ambiguous avoidance of scrutiny line, which is open to interpretation. As an example of where these would be issues:
People commenting on AE or ANI cases related to individuals they have a known negative relationship with. This prevents the closer from weighting arguments (grudges are fair to consider), and has the effect of potentially preventing sanctions on a main account (i.e. IBAN.) Even if only one account comments, this is an issue.
Potential harassment concerns following users around in project space that they don't like from disputes elsewhere. Even if there is not any double voting, this is still an illegitimate use of multiple accounts. It is significantly harder to deal with, however, if there is not a clear prohibition.
Concealing behaviour on internal discussions that might not be sanctionable but would have a negative impact on someone's position within the community -- if you're an archinclusionist or archdeletionist with positions way outside of the community norm and use a "privacy alt" to comment on AfDs this is an abuse of multiple accounts. If you request permissions at NPR and it is clear that you do not have an understanding of the notability policy that is in line with the community's it will be denied. If you run for RfA and you have positions on any number of topics that show a clear disconnect with community consensus, you will not pass RfA. All of these are forms of evasion of scrutiny that erode community trust, and are abuses of multiple accounts, but without PROJSOCK would be much more difficult to deal with.
We are an online community and part of that is about trust. If you don't know that the person who you are talking to is not commenting in a completely absurd and abusive manner 10 minutes later, or at least have reasonable assurances that they aren't, trust will go down hill. Many other Wikimedia projects do not allow secondary accounts at all. Updating our policy to allow people to essentially have as many personalities as they want in project space, and have ways to Wikilawyer out of it as the policy would be unclear is a clear negative, and would set us up with Commons to be one of the projects most open to abuse. TonyBallioni (talk) 01:32, 17 April 2021 (UTC)[reply]
Hmm... On #2, surely hounding is hounding anywhere (why is it any better to be following an editor around on article talk or template talk pages?). On #3, surely we shouldn't make policy that affects many editors for the sake of the dozen per year that want to run RfA (who can be asked to disclose individually?). Also, general note, aren't 1/3 not mutually exclusive with 2? Seems like Beeble has pointed out multiple issues, and even if PROJSOCK is adjusted (in whatever direction) the 'issues' about CUs not knowing declared alt accounts, or the infeasibility of policing edits (whether in WP: or any other namespace) remains. ProcrastinatingReader (talk) 10:15, 17 April 2021 (UTC)[reply]
TonyBallioni, The problem is, this is conflating "internal discussions that affect project policy" with "Wikipedia namespace". Given that we do allow privacy socks, surely you're not arguing that WP:Teahouse should be off-limits? Is asking for help on Help talk:Footnotes OK, but not on Wikipedia talk:Citing sources?
If a privacy sock is dragged to WP:AN, can they defend themselves there? Or if one of their articles is nominated at WP:AfD, can they participate in that discussion? Would it be OK to protest a WP:PROD, because that happens in article Talk space, but once you've done that and somebody takes the next step and brings it to AfD, you're stuck?
And what about WP:DYK, WP:GA, WP:FA? Are those fair game for privacy socks? DYK reviews take place mostly in Template space, GA in article Talk space, and FA in Wikipedia space. Does that mean that DYK and GA are OK, but FA is not?
What about participating in wikiprojects? They're in Wikipedia space. Would our hapless NASA employee from my earlier example be barred from participating in WP:Wikiproject Flat Earth? Maybe that's off-limits but Portal:Flat Earth is fine?
Your goal is to ensure that privacy socks don't get to speak with multiple voices at discussions that drive project policy. That's a laudable goal, but outlawing the subset of pages that happen to fall into the Wikipedia namespace does not advance that goal. By the time you're done carving out all these exemptions, the bright line you seek will have gotten rather blurry. -- RoySmith(talk) 12:47, 17 April 2021 (UTC)[reply]
Your goal is to ensure that privacy socks don't get to speak with multiple voices at discussions that drive project policy. No. That is not my goal, and my entire response above was saying it doesn't matter if people only contribute once to each discussion if they are doing so in a way that is designed to avoid scrutiny and deceive the community. My goal is to prevent evasion of scrutiny by people using multiple accounts, because evasion of scrutiny destroys trust on a collaborative project, which is one of the driving principles of our policy on the abuse of multiple accounts.The reason why Wikipedia space in particular matters is because the only reason to use a second account in the Wikipedia namespace outside of limited discussions about content (RSN, AfD, and FA mainly) is to avoid scrutiny. It's to separate personalities, and not cause you to associate actions from one with the other. Unless your dealing with sexually deviant materials or other similar controversial topics, there really isn't a valid reason to want to have privacy on your project space discussions other than evasion of scrutinyWhich leads us to the final point: clear lines addressed with common sense are easier to enforce than ambiguous policy. No one is currently being blocked for commenting on the Tea House or in DYK or the like with a second account. CUs and SPI clerks have brains and are able to determine intent. If you remove a clear prohibition, that becomes much harder to figure out, and appeals become more difficult. Ambiguity on what constitutes "Avoidance of scrutiny" isn't helpful, and by keeping one line that clearly defines it for everyone, you help people know what is and isn't allowed and you help with enforcement. We're dealing with hypotheticals about the negatives, there are some heavy handed blocks, but they're pretty rare for this violation. The positives of this line when it comes to enforcement, however, are pretty huge. TonyBallioni (talk) 17:18, 17 April 2021 (UTC)[reply]
"by keeping one line that clearly defines it for everyone" Except the current single line doesn't clearly define it for everyone (otherwise we wouldn't be having this discussion). In addition to RSN, FA, AfD there are the village pumps (this one arguably excluded), the help desk, WikiProject pages, XfDs (especially related to pages they've contributed to with the alt account), RFU, RFHM, ITNC, TALKPP and similar projects, AN(I) when their behaviour is being discussed or they are the victim of others' bad behaviour, CCI, EFR, EFFP, EAR, Arbitration space for cases relevant to the pages they edit with the alt, RFA/RFB for someone they've interacted with in topics they edit using their alt, and likely many more I've not heard of. Yet the current wording does not do anything to stop someone developing multiple account personalities in discussions that happen to occur in places other than the Wikipedia and Wikipedia talk namespaces. By saying "CUs and SPI clerks have brains and are able to determine intent." you seem to be agreeing with me that what matters is the intent of the person, so surely the rules should be written to state that what matters is the intent not the venue? "The positives of this line when it comes to enforcement, however, are pretty huge." I've not seen a single good enforcement of this rule that was not also covered by other existing provisions so I completely disagree with you that "The positives of this line when it comes to enforcement, however, are pretty huge."Thryduulf (talk) 18:19, 17 April 2021 (UTC)[reply]
Keep PROJSOCK, leaning option 1 – essentially per Tony. Abolishing PROJSOCK would require us to replace it with a huge wall of text explaining what exactly constitutes evasion of scrutiny in projectspace. Yes, there's a reasonable argument to be made for split contribution histories in articlespace in some cases. But independently using two accounts to participate in behind-the-scenes community processes inherently makes it impossible for me to evaluate someone's conduct as an editor in context, and that is poison for community discourse. If carveouts and clarifications are needed, that's fine and we can discuss those, but deprecation of PROJSOCK would either lead to ballooning policy or socking galore. As for my take on option 1: The current system of is suboptimal because it presents us with complicated OUTING considerations – I'm not opposed to people using alts to edit controversial topics (in articlespace) per se, but using them in a way that's policy-compliant and disconnected from their main account should be the responsibility of the operator. --Blablubbs|talk 09:39, 17 April 2021 (UTC)[reply]
@Blablubbs and TonyBallioni: Why is projectspace special? Why is evading scrutiny on a page in the Wikipedia namespace different to evading scrutiny anywhere else? Why is, e.g. Wikipedia:Help desk a "behind-the-scenes community process" but e.g. Help talk:Citation Style 1 not? Why would we need a "huge wall of text explaining what exactly constitutes evasion of scrutiny"? Surely it is better to just prohibit "evading scrutiny" and list some examples so that we don't have to deal with wikilawyering? Thryduulf (talk) 11:08, 17 April 2021 (UTC)[reply]
Thryduulf, the Help Desk is one of the places I would consider carveout-worthy. What is special are places like AfD, AN(/I), AE or RFAR. The issue with relying only on the evasion of scrutiny clause is that it will lead to Wikilawyering either way. It inevitably provokes situations where people say "but it wasn't one of the listed examples" and we have to have drawn-out unblock discussions and AN threads about what is and isn't evasion of scrutiny. I'd argue that most scenarios where someone uses a privacy alt in community discussions are inherently scrutiny evasion; a blanket ban on PROJsocking with specific, narrow exceptions is more feasible. Blablubbs|talk 11:18, 17 April 2021 (UTC)[reply]
Even if we say something like PROJSOCK is required, "consensus discussions and conduct dispute resolution" seems to encompass all of those examples, and others. The average projectspace page is just not problematic, from WikiProject talk pages to bot/editfilter requests. Even the text I cite is questionable, as asking whether a source is reliable at RSN could be seen as a "consensus discussion" but is just not problematic. ProcrastinatingReader (talk) 11:25, 17 April 2021 (UTC)[reply]
Also, what if a privacy alt is being harassed? They can't post to ANI, so what's their recourse? Should they contact an admin privately? (if so, how do you communicate this to them? using the ANI banner that evidence shows few actually read?) ProcrastinatingReader (talk) 11:34, 17 April 2021 (UTC)[reply]
@Blablubbs: So a privacy alt is not allowed to contribute to a discussion at XfD about a page they are a significant contributor to? What benefit to the project does that bring? As long as they only contribute using one of their accounts and don't otherwise give the impression of being multiple people, I just cannot see how their actions are harmful? As for "but it wasn't one of the listed examples" it's much much harder to wikilawyer around a list of examples that is explicitly not a complete list than it is a list that purports to be complete. Thryduulf (talk) 11:54, 17 April 2021 (UTC)[reply]
I'll reply with two quotes from Tony's comment that I'm in full agreement with. As for noticeboards and AfD discussions:
I am fine with clarification on PROJSOCK that people can validly use it to comment on discussions directly relevant to them, but that isn't a reason to throw our the baby with the bathwater. Whether we want to keep the wording as "projectspace", or tweak it to "consensus discussions and conduct dispute resolution" is another matter.
As for what harm it brings to just blanket-allow participation in such discussions:
...if you're an archinclusionist or archdeletionist with positions way outside of the community norm and use a "privacy alt" to comment on AfDs this is an abuse of multiple accounts.
If we see such an obvious alternative account used to vote in AfDs now, current policy gives us grounds for an investigation; a deprecation of PROJSOCK would severely complicate that, but such behaviour is highly problematic and a serious breach of community trust. Blablubbs|talk 12:11, 17 April 2021 (UTC)[reply]
Firstly, why is using multiple accounts to express extreme views more problematic than using a single account to do so if there is no attempt to manipulate the discussion or appear as multiple people? Secondly, why is using multiple accounts to communicate such positions problematic in the Wikipedia namespace but not in any other namespace? Thirdly, If we agree that using an alternative account in a given manner is problematic then surely policy should explicitly prohibit using multiple accounts in that manner rather than as part of a very broad and very vague prohibition that requires numerous carveouts and exceptions to avoid catching things we don't want to prohibit and requires people to guess what behaviour we don't want them to engage in? Thryduulf (talk) 12:43, 17 April 2021 (UTC)[reply]
Anyway, even if we do nothing but remove "Undisclosed alternative accounts are not to be used in discussions internal to the project." the behaviour you are talking about would still be covered by "it is a violation of this policy to create alternative accounts to confuse or deceive editors who may have a legitimate interest in reviewing your contributions." Thryduulf (talk) 12:47, 17 April 2021 (UTC)[reply]
To answer your question as to why it's problematic for someone to use different accounts to segregate views on internal matters: our system is built on trusting other contributors, and part of that trust is built on knowing their past history of views. As an example, I know you and I agree significantly on most things related to the harassment policy and outing, but have very different views on speedy deletion. While I'll engage with you on the latter topic, I'm also not going to spend a significant amount of my time trying to persuade you around to my point of view because at some point based on past discussions, I know we're just going to have to agree to disagree. On the flip side, in discussions around harassment and privacy, I'm much more likely to rethink my position and see if I considered everything if I see you or someone else who I know I share similar thoughts to arguing one way.This is what comes with being a community: you take all of the actions and positions of people, and they do impact how you read what they're saying and influence your thoughts. That's not a bad thing, that's human nature and it is a natural and important part of communities, both online and otherwise. The concern isn't an account that exists solely to segregate views on policy discussions, it's two accounts that never overlap and are fully developed accounts with their own personalities contributing to community discussions in a way that if uncovered would cause a loss of trust in the community. Having some policy around that clearly prohibiting it is a good thing, as in my experience it's easier to deal with clear lines with common sense than it is to deal with ambiguous lines in a similar manner. TonyBallioni (talk) 17:18, 17 April 2021 (UTC)[reply]
All three original options seem reasonable to me, per the proposal. Removing WP:PROJSOCK from the sockpuppetry policy entirely, however, is an idea that came up during the discussion and that isn't agreeable to me. Imagine someone who operates two accounts, one for mainspace and one for projectspace. Both are strictly separated: The mainspace account never edits the Wikipedia namespace, the projectspace account never edits articles. The result is an account that does not violate any policies while undermining our trust in community discussions. One of the main aspects of internal Wikipedia discussions is that they're held by users who also contribute to the encyclopedia in ways that can be easily looked up. Allowing project-only sockpuppets to loudly participate in internal discussions without ever having made any visible contributions to the encyclopedia would be a mistake: Policies affecting all articles are created in internal discussions, so we'd suddenly be open to policy changes by people who have no idea what their proposed changes mean to editors. Policy must be written, and consensus must be found, by people who verifiably contribute to the encyclopedia. Project socks prevent this verification. ~ ToBeFree (talk) 10:59, 17 April 2021 (UTC)[reply]
An account that edits only in projectspace is a very, very uncommon situation and PROJOCK both prohibits far, far more than that and doesn't actually prevent an account that doesn't contribute to the encyclopaedia from contributing (loudly or otherwise) in internal discussions held on e.g. template (talk) pages, help (talk) pages, article talk pages, category (talk) pages, etc. I'd also argue that an account that has contributes to the development of back-end tools and similar has verifiably contributed to the encyclopaedia. Thryduulf (talk) 11:14, 17 April 2021 (UTC)[reply]
"The reason why Wikipedia space in particular matters is because the only reason to use a second account in the Wikipedia namespace outside of limited discussions about content (RSN, AfD, and FA mainly) is to avoid scrutiny." I disagree with this. I would create a second account under my real identity if I could, and use my real-name account for noncontroversial editing and all noncontroversial project space discussions, while using my anonymous Levivich account to edit controversial topics (like war, politics and religion) and related project space discussions. If I did, it wouldn't evade scrutiny, it would increase it. Right now I could have a privacy alt that edits, say, sex topics (User:Sexivich?), and I can use this Levivich account to edit project space RFCs about sex issues and no one would know Sexivich's edits in those areas were mine. That avoids scrutiny. If instead I could use the Sexivich account for sex-related project space discussions, that would be more transparent, not less. If we're going to allow privacy alts (and we do, as we should), we should allow those alts to edit all namespaces. Levivichharass/hound 18:45, 17 April 2021 (UTC)[reply]
Strongly agreed on the first remedy. We should discourage privacy alts not because they're illegitimate, but because they don't work very well. Like Beeblebrox, my experience with this on ArbCom was a bunch of cases of people setting up a privacy alt for good reasons, accidentally outing themselves and/or getting themselves CU-blocked because they misunderstood our byzantine sock policy, then asking us to unring the bell. Probably there's a bias there in that we only heard about the cases that went wrong but, with this and other policies (oversight, vanishing, clean starts), we need to be more up front with the fact that the only reliable way to maintain your privacy on Wikipedia is to never reveal private information in the first place.
I always thought PROJSOCK was an arbitrary rule, but I don't know the history behind it, so I'm on the fence about that. – Joe (talk) 19:05, 17 April 2021 (UTC)[reply]
Scrap PROJSOCK, remedy #2 second choice Projectsock is really an outdated and overly broad guideline that should be eliminated, but if that doesn't have consensus I would support clarifying it to make its reach more narrow.Jackattack1597 (talk) 00:59, 18 April 2021 (UTC)[reply]
Strongly Discourage non-publicly-declared parallel-editing accounts, and simplify the rules for simple cases before getting bogged down in the complicated LEGITSOCK rules.
WP:SOCK is confusing for a simple newish Wikipedian to get simple answers. There is some very complicated stuff in it that is interspersed with simple stuff, and I think the simple stuff should be stated clearly and upfront, and with the complicated stuff below, under warnings.
The simple stuff is:
WP:SOCKING is NOT:
The use of multiple accounts that are publicly declared (declared on the main userpage, and all such accounts connected). Examples for this include secure and non secure computers. Segregation of edits of different types. Maintenance of multiple watchlists. Templates for this include {{User alternative account name}}, and I think they belong at the top of the main userpage.
Stuff gets complicated when talking about multiple editing accounts that are not publicly declared. Mainly, the reason for these seems to be "privacy". There are good reasons to not publicly disclose two editing accounts. You may have a good reason to edit publicly, in front of family, work, or for educational course purposes, and not want to reveal your main anonymous account. However, the section allowing for this should clearly and strongly state that doing this is NOT RECOMMENDED, and if done, done only briefly and for very narrowly defined purposes. One little mistake, and the connection may be spotted, and may then be forever public. Relative newcomers to Wikipedia should be actively discouraged from running undeclared editing accounts in parallel. This complicated stuff needs to be written, and is written, but it should be separated from the simple for the sake of simple comprehension of a simple reading of policy for simple questions.
The rules for non-publicly-declared parallel-editing accounts need to be clear and hard. There is currently a rule that you have these, only the main account may edit project space. This is very important for accountability. I think some words are needed to clarify what is a "main account".
Should an undeclared account every be allowed to participate in AfD discussions on their own content? We had discussions on this at WT:SOCK in March 2010, and in the end I found User:SlimVirgin, 10:03, 19 March 2010 specifically, convincing that legitsocks should not be allowed at AfD or dispute resolution. I also think that it is a simple and necessary extension to this that IPs must not be allowed to contribute to AfD, or to project space discussions in general.
Answering User:RoySmith's questions of 12:47, 17 April 2021 (UTC). For LEGITSOCKS, that are the not the main account, These should be specific-purpose, preferably short-term accounts. WP:Teahouse should be off-limits. Asking for help on Help talk:Footnotes maybe, but not on Wikipedia talk:Citing sources? No, simple hard rules are needed for this dangerous practice. The main account can ask questions about citing sources. I don't see why the non-main LEGITSOCK should be asking at Help talk:Footnotes.[reply] If a privacy sock is dragged to WP:AN, they cannot defend themselves. If a privacy sock is dragged to WP:AN, and the thread is entertained, something is wrong, and the person is not qualified to run a privacy sock. An account trying to be quiet and do a specific thing should be quiet and well mannered. If one of their articles is nominated at WP:AfD, can they participate in that discussion? No. The community has to be trusted to be running a fair AfD. Would it be OK to protest a WP:PROD, because that happens in article Talk space, OK. But once you've done that and somebody takes the next step and brings it to AfD, you're stuck? That's right. Trust the community at AfD. And what about WP:DYK, WP:GA, WP:FA? These are high end editing, competitive and somewhat drama associated. Reputation and accountability are important here. It is no place for a sockpuppet. No to WikiProjects. No to AfC reviewing. No to Portals. Pretty much, LEGITSOCKS should stick to mainspace, and to answer questions directed to them in talk space and user_talk. --SmokeyJoe (talk) 11:21, 18 April 2021 (UTC)[reply]
I strongly support the right to have privacy alts. Accordingly, they should be allowed to contribute in the project namespace, insofar as it's practical to write policy allowing this, subject to concerns such as the ones raised by TonyBallioni. They should certainly be allowed to defend their articles from deletion, and other such directly relevant activities. Benjamin (talk) 08:45, 18 April 2021 (UTC)[reply]
Scrap PROJSOCK and scrap disclosures - PROJSOCK misinterprets the Arbcom case that led to its addition to the policy. The issue there was not that the user was using undisclosed alternate accounts in project space (in and of itself) but that they were using them in ways that were already forbidden by WP:SOCK (apparently WP:GHBH and WP:STRAWSOCK). It's not Arbcom's place to invent policy and they should not have done so here. If someone uses different accounts to contribute to different discussions (not the same discussions) in otherwise legitimate ways, what does it matter? PROJSOCK is a "gotcha" policy that punishes users for no benefit to the project; we should just remove the bullet. As for disclosures, we should probably stop: it's irresponsible and probably unethical to suggest that disclosing a private alt to Arbcom somehow imparts a guarantee of privacy, which is absolutely not the case. It's also clear that everyday editors don't understand that each WMF site is a separate project with separate governance, that our coordination between projects is deliberately very limited, and that what might be allowed here might not be allowed on other WMF projects. What we should do is more strongly advise editors considering a privacy alt of the dangers: if they do use their alt in forbidden ways then we will publicly connect their main just as we do for all sockpuppet accounts, and although we discourage outing, Wikipedia is in the real world and we really have no control over other editors trying to "unmask" a privacy account, though I say we should do more to discourage editors who make a habit of malicious witchhunts. If a user is going to try to use a privacy alt, they need to understand the risks, and that they are responsible for maintaining their privacy, not Wikipedia. I am, however, very strongly against creating a policy that private alts are forbidden. Ivanvector (Talk/Edits) 13:30, 18 April 2021 (UTC)[reply]
Question: I've been editing since 2006, but usually I create a new account every few months because I don't think scrutiny is fair. That is, if someone doesn't like what I write about sexuality topics, I don't want them going through my environmental topic editing to dig dirt on me. Is my behavior outside established norms? If I give myself a WP:CLEANSTART every three months, and abandon all my earlier accounts, is that bad? 50.242.124.27 (talk) 16:04, 18 April 2021 (UTC)[reply]
I think it's fine. I'm sort of the opposite of you: I've only ever edited under one account. But I've given serious consideration to doing it your way (repeated clean starting), or just saying the heck with having a registered account and editing only under a dynamic IP. The irony of IP editing, especially from a large dynamic range like a mobile provider, is that it entirely avoids all the "scrutiny" that others talk about. Dynamic IPs can edit (almost) everything and there is zero way to even see their contribs history (since the ranges are shared). And like 90%+ of the encyclopedia is written by IPs this way... no scrutiny for most editors and yet the website doesn't fall apart. That's why I think talk of scrutiny and community is misplaced: really the transparency and control we think we have over registered accounts is a joke: we only have that for those who bother to register an account and use it, and use it within policy, which is a tiny minority of all editors. Transparency and scrutiny of this type are an illusion. Levivichharass/hound 17:44, 18 April 2021 (UTC)[reply]
None of this is aimed at clean start accounts. Having two accounts at once is different than abandoning an account and starting a new one. If the IP has really been doing that for as long as they say, they are doing it exceptionally well and I for one have no problem with that. Beeblebrox (talk) 21:20, 18 April 2021 (UTC)[reply]
There's an interesting point above. Posit this situation:
RoySmith decided to do it the other way around: Edit as real-world identity User:RoySmith, easily identified with boating being a well-known name in the boating world, on boating subjects; and in order to hide the shame from xyr boating colleagues of also knowing about K-Pop and species of beetle, editing everything else except for boating as User:BigBubblyBoatingBob.
Is this even the problem to be addressed? People mention AFD, but the sorts of sockpuppetry that we largely get at AFD are pretty much always of the kind that are illegitimate anyway. It certainly does not seem to be anything like what the Privatemusings case was, either.
I think the solution is to encourage sockpuppetry. There are a few common uses of sockpuppetry that are so heinous that the entire concept is banned: socking to evade a ban/block/sanction (block evasion), socking to create the illusion of consensus (vote-stacking), and socking to evade scrutiny (WP:GHBH). There's also the well-established norm that no person can have more than one account with admin permissions. Beyond that, I think we need to re-consider why socking is a problem. User:力 (power~enwiki, π, ν) 00:16, 20 April 2021 (UTC)[reply]
I don't support any option as I feel that some editors may be embarrassed for users to know that they edit in a specific category and if they declared that they used an alt in those categories it might further increase the embarassment. I feel like instead there should be a template that says "This is a privacy alt of a user who would wish to remain anonymous, who uses this alt to edit in these categories:", that way the alt would still technically be declared but it saves the editor the embarrassment of having to specifically declare that they own the alt who edits in categories they would wish to not be known as an active editor in. Blaze The Wolf | Proud Furry and Wikipedia Editor (talk) 19:59, 20 April 2021 (UTC)[reply]
Just to clarify for myself: I do not support getting rid of PROJSOCK entirely. I think it needs to be changed, but I do think it serves a purpose. Privacy alt sre intended to be used for editing content, if you want to talk about policy, you should use your main account. Beeblebrox (talk) 20:04, 21 April 2021 (UTC)[reply]
To borrow Benjamin's phrase, I strongly support the right to have privacy alts. To those people saying they need to judge a person's history and character to have a working community: a privacy alt is effectively a separate person (or persona). Their contributions, discussions, and interpersonal relationships can stand on their own. I understand there's a fear that you might hold Dr Jekyll in high esteem whilst there’s a Mr Hyde stalking around. Wouldn't that be a rare occurrence? Much more common would be the case of Rob the boating expert and Bob who edits in other areas. If both accounts behave in a respectful and constructive manner, and they're not teaming up to mislead, then they should both have a voice in all parts of the project that relate to their respective topic interests. Pelagic ( messages ) – (11:14 Sun 25, AEDT) 00:14, 25 April 2021 (UTC)[reply]
Beeblebrox, it's a bit of bullshit that there is no option to "leave things as they are". We aren't under any obligation to parrot other wikis, after all. I haven't read all the discussion (and shouldn't need to in order to opine here), but a discussion for change that doesn't allow the option to leave the status quo is null and void, imho, as you can't gauge the most basic question "is there an appetite for ANY change?". It's not like you to make such a glaring omission like that. Dennis Brown - 2¢ 18:03, 25 April 2021 (UTC)[reply]
I don't quite see it that way. I'm proposing remedies to perceived problems. If the community feels that either there is no problem or these aren't the remedies that will solve them, they will be rejected and the status quo retained. Happens all the time. Beeblebrox (talk) 18:54, 25 April 2021 (UTC)[reply]
Automatic Exemption from Hard IP Block for established logged-in users
I don't understand the rationale behind parts of the current Hard IP Block policy. Obviously it is important to prevent vandalism from unregistered or new accounts, however once an editor is relatively well established I don't see how this has any significant effect. Many people, myself included, frequently use a VPN service for perfectly legitimate reasons, in my case my ISP fails to connect to many servers elsewhere on the web. When I come across small errors on wiki, it is impractical to disconnect and reconnect just to fix it, so I often simply don't do it.
From my understanding, the reasoning behind such a policy is to prevent anonymous vandalism by ensuring that all edits are attributable. Provided a well established user is logged in then any edits they make remain attributable, regardless of the IP address they originate from. If such a user were to engage in vandalism, they would be blocked; they would then be unable to edit from the blocked IP, removing the problem.
I do not understand why automatic exemption should not be granted to such users; as they are still accountable for their edits there is no reason why this would have any meaningful impact on vandalism. I think that once a user has shown that they can be trusted to edit protected pages, their motives for using a blocked IP can be assumed to be benign.
Extended confirmed users should absolutely be trusted with this; the risk of someone creating an account (which cannot be done from the blocked IP), making 500 edits and waiting 30 days just to abuse an anonymous IP address is non-existent, given the user can still easily be blocked. I think autoconfirmed users are up for debate, however I would again point to the fact that accounts cannot be created from blocked IPs, providing an element of accountability.
While VPNs and other forms of anonymous proxies clearly pose a risk of vandalism, having a blanket ban fails to recognise that there are perfectly legitimate reasons for an editor to use these. Exempting established editors from these bans will not have any impact on vandalism or accountability, while removing barriers to them fixing issues they see on wikipedia from such IP addresses. If an editor is trusted with high-level permissions, why can they not be trusted to edit from a blocked IP?
Given administrators automatically receive such an exemption, it cannot be that difficult to add this permission to other user groups. Therefore, I propose that extended-confirmed users are granted this permission, and ask that we debate whether this exemption should be extended to auto-confirmed users. John wiki: If you have a problem, don't mess with my puppy... 12:17, 17 April 2021 (UTC) — Preceding unsigned comment added by John wiki (talk • contribs) 12:01, 17 April 2021 (UTC)[reply]
There is already a mechanism for non-admins to work around hard IP blocks: Wikipedia:IP block exemption, which is open to anyone who demonstrates a need and can be trusted not to abuse the right. Since the vast majority of users don't need it, automatically giving this to a whole user group would serve no purpose, except to significantly undermine our ability to detect misuse of multiple of accounts (which is the main reason we hard block proxies, not ordinary vandalism). – Joe (talk) 18:39, 17 April 2021 (UTC)[reply]
@Joe Roe: How would it undermine the ability to detect socks? Also, how would a user be able to abuse the right? The main thing I'd be worried about are compromised accounts, but inactive accounts could maybe be excluded somehow. When you say that "the vast majority of users don't need it" I'm not entirely sure. Am I the only one who gets bombarded with VPN sponsorships on YouTube? They must be selling subscriptions if they can afford that. Some mobile internet ranges probably also get blocked every now and then. The vast majority of users is likely unaware of the possibility to get IP block exemption. In order to say anything sensible, we'd need to know how often extended-confirmed users are stopped from editing by an IP block. — Alexis Jazz (talk or ping me) 18:57, 17 April 2021 (UTC)[reply]
Open proxies are hardblocked => Registered users can't use open proxies => Registered users have to use their own Internet connection to edit Wikipedia => Checkuser can detect all accounts on the Internet connection. (Ideal scenario)
Allowing users to use proxies means allowing them to hide their IP address from checkusers. ~ ToBeFree (talk) 20:10, 17 April 2021 (UTC)[reply]
Checkusers can see 3 months back, so this would require some serious planning. On the one hand there is the theoretical risk of increased vandalism because of that, on the other hand there are potential missed contributions from legitimate users who happen to use a VPN. Since the former is theoretical and we don't have stats on the latter, there is no way for us to come to an informed decision. — Alexis Jazz (talk or ping me) 21:07, 17 April 2021 (UTC)[reply]
Before I peeked behind the CU curtain, I would also have been sceptical that someone would spend months getting an account extended confirmed just so they could switch to a proxy to evade a block. Unfortunately, there are plenty of people with that much time on their hands, and the disruption they cause also often goes far beyond vandalism.
As for awareness, yes, the majority of users probably don't know that IPBE exists. But the message you see if you're affected by a proxy block points you to it, so hopefully the percentage is much higher for those who actually need it. – Joe (talk) 07:29, 19 April 2021 (UTC)[reply]
"Extended confirmed users should absolutely be trusted with this": No, as it would take away the scrutiny and requirement for justification that WP:IPBE provides. Extended-confirmed sockpuppeteers, even admin sockpuppeteers, exist. A prominent case was Edgar181. This case was prominent because it was a rare occurrence and the trust implied in sysop permissions is even higher than the trust required for IPBE. ~ ToBeFree (talk) 20:17, 17 April 2021 (UTC)[reply]
If you think that sockpuppeteers would not go to the trouble of creating multiple extended-confirmed socks to disrupt with, you haven't met some of our most dedicated sockmasters. Black Kite (talk) 20:23, 17 April 2021 (UTC)[reply]
I'm not sure how best to preserve the ability to detect socks, but I feel strongly that any situation that makes it as hard as it currently is to edit from, say, China is unacceptable. Benjamin (talk) 08:53, 18 April 2021 (UTC)[reply]
I strongly oppose this proposal, because I believe it's founded on a flawed premise, namely that the risk of someone creating an account (which cannot be done from the blocked IP), making 500 edits and waiting 30 days just to abuse an anonymous IP address is non-existent. Simple vandalism, logged-out or otherwise, is only part of the issue here; extended-confirmed is not hard to game, and I could list dozens of socks who had EC (or other, manually granted permissions). The blanket IPBE grant that is proposed here would make it extremely easy to sock. The CU team is willing to grant IPBE for users who have to circumvent the Great Firewall or similar government censorship mechanisms and does so regularly, after review – and that needs to stay this way if we want to keep CUs in a position to deal with skilled sockmasters through technical evidence {{webhostblock}} and {{colocationwebhost}} already point users to WP:IPBE, but if additional mechanisms for pointing users towards WP:IPECPROXY are needed, that can of course be done. Blablubbs|talk 13:58, 20 April 2021 (UTC)[reply]
Heck no IPBE can be granted at request. It should not be given out if not necessary. The potential for abuse is quite high. Gaming ECP isn't that hard. Our socks are dedicated to the art of abuse. AdmiralEek (talk) 23:22, 20 April 2021 (UTC)[reply]
Make autopatrol an optional right for administrators
I propose to make the autopatrolled user right optional for administrators in the same way as edit filter is. ( Administrators can assign it to themselves, but it isn't part of the standard toolset.) Jackattack1597 (talk) 00:56, 18 April 2021 (UTC)[reply]
Any particular reason? – bradv🍁 03:48, 18 April 2021 (UTC)[reply]
(edit conflict) @Jackattack1597: Indeed: before proposing a change to an established practice, you should first demonstrate that there are problems with that practice, and then show that such issues that exist are best fixed by applying your proposed change. Secondly, this should really be at WP:VPR, not VPP. --Redrose64 🌹 (talk) 09:04, 18 April 2021 (UTC)[reply]
Oppose - I'm pretty sure I know what this is about, and this is the wrong solution - there isn't a good reason to unbundle just this one userright, and I don't see a discussion about unbundling similar rights which would be for the same reason. I'm also against unbundling tools from admins only to let admins assign them to themselves; if we're going to unbundle, then admins should ask at WP:PERM just like everyone else and be evaluated according to the community's criteria. Edit filter manager and interface admin are different things: you can do real damage to the project with those, that's primarily why they're not part of the standard admin toolset. Ivanvector (Talk/Edits) 11:29, 18 April 2021 (UTC)[reply]
Believe me, I want to unbundle more rights, but based on Village pump ideas feedback, a proposal to unbundle multiple similar rights wouldn't have gone anywhere, and may have even gotten WP:SNOWed, and I went with this instead because it would be a step in the right direction, and there's a recent example of when it would have been helpful. Mass creating non-notable articles does real damage to the project too, in my opinion; it consumes countless hours of cleanup time from productive editors that could better be spent elsewhere.Jackattack1597 (talk) 14:07, 18 April 2021 (UTC)[reply]
Oppose. The proposal is an overreaction to a single isolated incident that is an extreme outlier. On the whole we don't have evidence of a significant number of admins creating a lot of substandard articles that escape community's attention. Rather than taking away user rights from the admins we should be creating new userrights, that are a part of the full admin toolkit, and making them available to regular users. That's how I'd like to see unbundling proceed. Nsk92 (talk) 11:54, 18 April 2021 (UTC)[reply]
Support, I'd like to be able to have my new articles scrutinized like everyone else's. —Kusma (𐍄·𐌺) 12:09, 18 April 2021 (UTC)[reply]
Administrators can unreview pages they create; an opt-in bot could be written to cover admins who want this by default or are subjected to it by restriction. –xenotalk 13:41, 18 April 2021 (UTC)[reply]
In the past I've deliberately submitted articles I create to WP:AFC for that reason. AFC is a stronger review process anyway. Ivanvector (Talk/Edits) 13:44, 18 April 2021 (UTC)[reply]
There are many workarounds. I sometimes use {{stub}} on my stubs, as this will summon a stub sorter who often also notices other things I have overlooked. {{uncat}} is a similarly useful incantation. —Kusma (𐍄·𐌺) 18:00, 18 April 2021 (UTC)[reply]
Oppose If an admin is unable to create pages in compliance with the most basic of site policy, then they shouldn't be an admin. If they want NPP review of a particular page for some reason, they can manually unpatrol it. ProcrastinatingReader (talk) 12:14, 18 April 2021 (UTC)[reply]
Oppose We are here to build an encyclopaedia, not to talk to each other and play with policies and guidelines (including wikilawyering). If a user can't write a decent article, they should not be an admin here in the first place. Content issues are very important and one who violates core content policies should not have the opportunity to climb up the ladder. 4nn1l2 (talk) 12:30, 18 April 2021 (UTC)[reply]
Oppose The proposer hasn’t made a case for this. --Malcolmxl5 (talk) 12:39, 18 April 2021 (UTC)[reply]
We recently had a situation where a long-term admin was discovered to have made thousands of non-notable articles over the years, and it had been brought to the communities attention previously, but nothing happened until this year because he was an admin and the autopatrolled right is part of that toolset. His actions have resulted in a large cleanup effort spanning multiple wikiprojects and taking up countless manhours of cleanup time, and if autopatrolled had been debundled from the start it could have been removed when the issue was brought to the communities attention in 2014 https://en.wikipedia.org/wiki/Wikipedia:Administrators%27_noticeboard/IncidentArchive830#Carlossuarez46_mass-creating_articles, instead of enabling him to create thousands of articles between then and now of questionable notability. Jackattack1597 (talk) 14:26, 18 April 2021 (UTC)[reply]
Support The real question here is simple, are admins expected to create content or are they expected to administrate? Autopatrolled exists purely for the benefit of the WP:NPP project, and non-admins can already receive this permission so this is already unbundled from adminship, but admins automatically receive this permision when they become admins, so the only current way to un-autopatrol an admin is to desysop them. Admins who don't create articles up to the standards of NPP should have the autopatrolled perm removed instead of having the NPP project request a full desysop because none of the other admin tools (block, delete, protect etc) are used help the NPP project in ways that non-admins can (NPP non-admins have RFPP, CSD, AIV etc when they need admin attention already). Also, it should be plainly obvious that any admin who tries to re-autopatrol themselves against the wishes of the community would be quickly desysopped. Iffy★Chat -- 13:00, 18 April 2021 (UTC)[reply]
I would support a proposal to unbundle every userright that can be requested by non-admin editors from the admin toolkit, for the reasons Iffy presents, but that is not this proposal, and doing them piecemeal would be worse than not doing anything. Ivanvector (Talk/Edits) 13:46, 18 April 2021 (UTC)[reply]
See also my comment below, but I've found that the NPP project mostly only cares about ns:0 pages; not actually all new pages (which are affected by patrolling). — xaosfluxTalk 15:50, 18 April 2021 (UTC)[reply]
Xaosflux, for those who aren't as familiar with NPP, could you explain to what ns:0 refers? Sdrqaz (talk) 20:29, 18 April 2021 (UTC)[reply]
@Sdrqaz: sorry for the jargon! "ns" refers to the different namespaces, "articles" are in an unlabeled namespace, "(main)" which is namespace number "0". This discussion for example is in the Project namespace, which we have labeled "Wikipedia:", which is namespace number 4. I've found that most participants in "new page patrol" only focus on "new articles" not really "new pages"; focusing on articles is very important as it is the most reader-facing component, but it is not all-encompassing of new pages. Hope that helps! — xaosfluxTalk 21:20, 18 April 2021 (UTC)[reply]
Got it, thanks! Learn something new every day. Sdrqaz (talk) 22:45, 18 April 2021 (UTC)[reply]
@Xaosflux: The NPP project mostly only cares about ns:0 pages because Special:NewPagesFeed, by default, only lists pages in mainspace; users need to set the filters on that listing to see another namespace - which presently only seems to offer the User: namespace as an alternative. I'm pretty sure that at one time all namespaces were selectable, as they are at Special:NewPages. --Redrose64 🌹 (talk) 23:06, 18 April 2021 (UTC)[reply]
@Redrose64: yea, that's why NPF isn't great for catching things like copyvio's in Draft:, bad new content templates, etc. We have an overlap of curation tools here on enwiki, especially between "patrolling" and "reviewing" of new pages. — xaosfluxTalk 23:23, 18 April 2021 (UTC)[reply]
Oppose – while I agree it's not administrator's main job to do content creation (they were appointed to administrate the project), it doesn't make any sense to me to remove autopatrol from them. First, "administrating an encyclopedia" pretty much means make it look like an encyclopedia (by using the mops here and there). In order to be able to make something look like an encyclopedia, you naturally need to know how an encyclopedia looks like – in another words, you must be able to create an article that would normally pass an AfD, AfC or NPP. I think that all administrators should either be able to write articles in a good enough form to pass the standard review process, or they shouldn't be an administrator at all. Note that I don't think administrators necessarily need to be able to write good/featured articles – but that's at another end of the quality scale we use --Martin Urbanec (talk) 14:41, 18 April 2021 (UTC)[reply]
Oppose while I certainly don't expect all admins to write brilliant prose and expertly built articles, I do expect that articles created by admins should survive speedy deletion (which according to WP:NPP is at its core...about deciding whether a new article will be...accept[ed], or initiating...deletion procedures). If admins are creating bad articles a topic ban against article creations could be levied. As far as non-content space creations, the bar to acceptance of these pages is even lower and admin are likely to create all sorts of meta pages that shouldn't need to bother recent changes patrollers. — xaosfluxTalk 15:48, 18 April 2021 (UTC)[reply]
Dug in to this a little bit more as well, pursuing Special:NewPages shows that at least right now most new pages aren't articles at all; are admins causing problems in creating all of these types of pages? — xaosfluxTalk 18:04, 18 April 2021 (UTC)[reply]
Support. I started out writing this comment in opposition. I got as far as "As Xaosflux said just above, some people specialize in writing good prose, some people specialize in mopping. But, to be sure, the ONLY reason this project exists is to generate good content for our readers to consume, and the ONLY reason admins exist is to support the creation of that content. If an admin can't meet even the absurdly low bar of WP:NPP, they have no business being an admin". But, as I studied the flowchart in detail, I changed my mind. Some of the boxes talk about things I would never expect an admin to do (pure vandalism, etc). But, then I thought about my experiences in the software engineering world. In the best shops, even the most experienced senior people don't get to commit code without a second set of eyes looking at it. Some of the checks are (paraphrasing) "Does the topic exist at another title?", "Is the article at the correct title?", "Does the article contain a copyvio?", "Can the article use more/better tags?". Any or all of these would benefit from a second set of eyes looking it over. If you're really writing good stuff, the review should take no time at all. I wouldn't worry about how much workload this will add to the NPP queue; there just aren't that many admins, and most of them aren't producing a ton of new mainspace content. -- RoySmith(talk) 16:55, 18 April 2021 (UTC)[reply]
@RoySmith: when you reference even the most experienced senior people don't get to commit code without a second set of eyes - isn't that also an argument for removing the 4,776 other editors flagged as autopatrol? — xaosfluxTalk 17:59, 18 April 2021 (UTC)[reply]
Xaosflux, Yes it is. That's not going to make me very popular, is it? -- RoySmith(talk) 18:09, 18 April 2021 (UTC)[reply]
@RoySmith: not sure - maybe it will make you someone that came up with a great idea; it does seem like the problem you are raising goes much beyond the sysops though. I'm not sure how this will be helpful outside of ns:0 though; perhaps making autopatrol not work in ns:0 would be better? — xaosfluxTalk 18:12, 18 April 2021 (UTC)[reply]
Xaosflux, To go back to my statement that the ONLY reason this project exists is to generate good content for our readers to consume, I'm really only talking about ns:0. I'm fine with people creating crappy pages in project space (which I mean in the more general sense of anything other than mainspace) because they don't directly affect what our readers see. To be honest, I'm fairly ignorant of the details of how page patrolling works; I assumed it only applied to mainspace. Is that not the case? -- RoySmith(talk) 18:22, 18 April 2021 (UTC)[reply]
@RoySmith:see Special:NewPages to see all the unpatrolled pages. And we do need to ensure that we're not doing things like hosting copyvio's or attack pages in all namespaces or we might not have a project to host articles at all... — xaosfluxTalk 18:28, 18 April 2021 (UTC)[reply]
@RoySmith: All new pages may be patrolled, but by default Special:NewPagesFeed and Special:NewPages only list pages in mainspace; users need to set the filters on those listings to see other namespaces. Many users (like yourself) will not be aware of the namespace selection feature. --Redrose64 🌹 (talk) 23:06, 18 April 2021 (UTC)[reply]
This chart is impressive but it mostly demonstrates how overly bureaucratic and complex Wikipedia has become. (If Wikipedia:New pages patrol/School exists what does that say about the expectations for a much more advanced right like the RfA?) I would hope we can trust our admins not to insert copyvio in their articles. The kind of checks like "Can the article use more/better tags?" are basically frivolous and encourage tag-bombing new articles. In general the type of the argument you make above is an argument to eliminate the "autopatrolled" userright altogether. In reality many new articles are currently overtagged. I expect that the only useful tag that many autopatrolled users probably neglect to add to their articles in significant numbers is the "stub" tag. But that's probably a problem for bots to handle somehow. Nsk92 (talk) 18:14, 18 April 2021 (UTC)[reply]
Oppose, solution looking for a problem. Stifle (talk) 16:21, 19 April 2021 (UTC)[reply]
Oppose Was going to say exactly what Stifle said. This is a solution in search of a problem. I know there was a case of the autopatrolled tool causing problems in one case dealing with one admin, but this is NOT a widespread problem, hard cases make bad law, etc. --Jayron32 16:25, 19 April 2021 (UTC)[reply]
Oppose If an admin abuses even one of their tools, they should be desysopped, period. If, say, they are abusing their page mover right, we desysop them and give them account creator, autopatrolled, event coordinator, extended confirmed, file mover... every non-admin user right except page mover. If they are abusing autopatrolled to make 300 non-notable substubs, we desysop them and give them every non-admin user right except autopatrolled. 🐔ChicdatBawk to me! 11:37, 20 April 2021 (UTC)[reply]
Oppose If we can't trust an admin to regularly make policy compliant pages, we probably can't trust them to be an admin. AdmiralEek (talk) 23:24, 20 April 2021 (UTC)[reply]
support getting rid of the autopatrolled bit entirely. All new pages can use a second set of eyes. CapitalSasha ~ talk 01:25, 21 April 2021 (UTC)[reply]
Oppose per Ivanvector and Nsk92. We have proven we can deal with the rare admins not in compliance or abusing the tool. This proposal is not really needed, and not the proposal I would support as it is currently written even if it were needed. Huggums537 (talk) 11:40, 21 April 2021 (UTC)[reply]
Oppose no good reason for this change. Elli (talk | contribs) 14:46, 21 April 2021 (UTC)[reply]
I would probably support, but more information is needed as well as a more complete proposal. Logs of pages created by autopatrolled users and administrators would be useful. Most administrators passed RFA many years ago when the policies and guidelines were different, and it's likely that not all have kept up to date with the changes. It isn't only administrators, there are editors who have been inactive since 2009 who could create a page now that wouldn't have to be patrolled. The reason to separate autopatrolled status is not "300 non-notable substubs"; it's the occasional inadequately sourced article. Peter James (talk) 18:20, 23 April 2021 (UTC)[reply]
@Peter James: for a snapshot take a look at NewPages - for the most part the new pages that are not highlighted in yellow are created by autopatrollers (include admins). — xaosfluxTalk 19:38, 23 April 2021 (UTC)[reply]
Also, it would be pretty simple to add "autopatrol" to the various other flags we remove for inactivity (generally for a year of no activity) - bring it up at Wikipedia talk:Autopatrolled and ping us at WT:PERM if it passes. — xaosfluxTalk 19:41, 23 April 2021 (UTC)[reply]
FWIW there are ~578 users that are in 'autoreviewer' that have not made an edit in over 5 years, 1214 that haven't in 1 year. — xaosfluxTalk 19:45, 23 April 2021 (UTC)[reply]
Comment: There is no proof the community can deal with the rare admins not in compliance or abusing the tool - the very issue is that autopatrol allows avoidance of scrutiny. I've seen literally dozens of instances where the right is abused, or at least barely respected by editors and admins. Before any sensible decision can be made rather than the subjective supports and opposes, it needs to be established just how much the WP:NPR workload is actually relieved by active holders of the autopatrolled right. IMO (lacking sources), since ACPERM was rolled out, I would hazard a pure guess that deprecating it altogether it would not add much burden to New Page Reviewing. Thus, research first, i.e. checking the quality of autopatrolled submissions over a sample period, and the number of autopatrolled new articles to be reviewed daily at NPP. Then start a RFC backed up by data and well founded rationale. Kudpung กุดผึ้ง (talk) 14:59, 26 April 2021 (UTC)[reply]
@Kudpung: Out of curiosity I've just ran a few Quarries for data. In the last 30 days, 25,810 pages have been created by autopatrolled users in the mainspace. List. Total articles created in the same period were 51,642, so that's 25,832 non-autopatrolled articles that went through NPP.
It would probably be quite easy to trial something without pulling the autopatrolled perm of any user (directly). If there were consensus to try disabling autopatrolled for, say, a month, a phab task could be made to temporarily remove the autopatrol permission from groups (Special:ListGroupRights). ProcrastinatingReader (talk) 16:05, 26 April 2021 (UTC)[reply]
@ProcrastinatingReader: while you only mentioned ns0, it looks like adjusting your query shows that over 74,000 other "new pages" were created by autopatrolled editors - I can't see any reason to force all those through the new page patrol process? — xaosfluxTalk 16:46, 26 April 2021 (UTC)[reply]
@Xaosflux: my rationale for limiting the query to mainspace was that (iirc) someone said most NPPs ignore non-mainspace creations. No opinion on whether scrapping autopatrolled is a good idea; NPP's organisation and functioning is beyond my expertise, but I figured providing some data (and a possible technical implementation for a temporary trial) might help those who want to think about the idea further. ProcrastinatingReader (talk) 16:53, 26 April 2021 (UTC)[reply]
NPP was designed specifically as a New Article review process. In the rebuild of the control panel we asked for 3 years ago, it was decided to include a drop down option to review Articles plus User Pages for the purpose of catching people using their user page as a fake article , spam or 'hosting for non Wiki purposes, and make the other options more granular and to include the AfC list. There is probably no pressing need for every kind of namespace to be reviewed except perhaps redirects from soft deletions that get quietly turned back into articles. It is not known if New Page Reviewers use these options very much. Kudpung กุดผึ้ง (talk) 17:26, 26 April 2021 (UTC)[reply]
Currently, GUILT is one of the principles listed in a final Arb Com decision in a 2006 case. It is currently subsumed under WP:BLPBALANCE which states Beware of claims that rely on guilt by association, and biased, malicious or overly promotional content. I'm of the mind that it should be integrated with BLP policy. A few quick examples of situations where it came into play:
JzG referred to it in this discussion...this is an attempt to smear Joe Biden through guilt-by-association based on innuendo, facts already known and admitted...
I referred to it in at a different BLP, stating: His fallout is the result of WP:GUILT because of the start-up company's questionable business practices, not his own...
I am proposing that WP:GUILT be added to WP:BLP as a subsection of Writing style. My proposal also includes moving the relative guilt statement in BLPBALANCE to the new subsection as follows:
Beware of claims that rely on guilt by association, and biased, malicious or overly promotional content. Guilt by association is never a sufficient reason to include negative information about third parties in a biography. At a minimum, there should be reliable sources showing a direct relationship between the conduct of the third parties and the conduct of the subject (i.e. a nexus), or that the subject knew or should have known about and could have prevented the conduct of the third parties.
Survey (WP:GUILT)
Approve - it is very much needed. Atsme💬📧 23:21, 18 April 2021 (UTC)[reply]
Oppose due to redundancy. I appreciate the sentiment, but, as you note, WP:BLP specifically says to "Beware of claims that rely on guilt by association" and that biographies should be "completely sourced, neutral, and on-topic." Thus, this principle is already "integrated with BLP policy." The proposed new text would add new verbiage and headers, but provide no new substantive guidance for editors beyond what is already in WP:BLP, WP:SYNTH, WP:V, etc. Thus, I oppose this as redundant and instruction creepNeutralitytalk 03:35, 19 April 2021 (UTC)[reply]
Oppose Not needed. It's already in there, the policy page doesn't benefit from the redundancy. --Jayron32 16:23, 19 April 2021 (UTC)[reply]
Oppose per Neutrality. Also, without commenting on the specific principle, an ArbCom case from all the way back in 2006 has pretty limited precedent-making power; Wikipedia was a radically different place then. {{u|Sdkb}}talk 04:05, 20 April 2021 (UTC)[reply]
In Talk:Hitler_family#Infobox_and_ethnicity_template an editor argued that there should be an exception made for this particular article since Austria-Hungary was at the time a multiethnic country and that stating one has Austro-Hungarian citizenship would not help a reader determine one's ethnic background. Is there a provision to make a custom field for ethnicity for particular articles? Do the editors support this?
The issue with ethnicity is that it is a nuanced concept that requires context and explanation to make sense in a biography. A field in an infobox does NOT provide the necessary context NOR does it allow nuance. The discussion in question is merely about deprecating the use of the ethnicity field in infoboxes; it does NOT prevent an explanation of ethnicity in the body of an article, which in many cases should be done. --Jayron32 15:29, 20 April 2021 (UTC)[reply]
What Jayron32 said. If necessary, a complex aspect like ethnicity can be discussed in the main body of the article, with proper context, but it should not be squeezed into the infobox. And there is nothing exceptional about the Austro-hungarian empire, lots of other countries were/are multiethnic. Nsk92 (talk) 16:08, 20 April 2021 (UTC)[reply]
I think we must remember WP:IAR. If you read the discussion where it was deprecated the issue was adding in articles where it was not really notable, not to rid it from articles where it was notable. Emir of Wikipedia (talk) 15:26, 25 April 2021 (UTC)[reply]
If so, we need clear guidance on where that line should be drawn. When in doubt, I would err on the side of NOT including the parameter. Blueboar (talk) 15:45, 25 April 2021 (UTC)[reply]
The idea of IAR is probably that you can't (and shouldn't try to) legislate everything in advance. Creating guidance for when to IAR would be defeating the point (and that guidance itself would be subject to IAR anyway). I think the rough consensus is not that there's XYZ situations where ethnicity is appropriate, but rather that it's pretty much always inappropriate. Such edge cases where one wants to use it should probably be discussed on the talk page in advance (the value should at minimum be verifiable, especially noteworthy for the subject, and worthy of inclusion in an infobox). If there's consensus to use it, in regards to the technical limitation of |ethnicity= no longer existing, I guess you could embed a pseudo-infobox with a label/value pair. See Template:Infobox#Embedding. ProcrastinatingReader (talk) 15:56, 25 April 2021 (UTC)[reply]
What is your opinion regarding the essay WP:SANTA?
The essay states several reasons that Wikipedia should make it clear that Santa Claus does not exist. I personally agree with it, but what do you think about it? Félix An (talk) 16:56, 25 April 2021 (UTC)[reply]
Félix An, parents should stop lying to their kids. We should replace "legendary character" with "fictional character". If we can't get consensus for that, maybe use the term "fabricated" or "mythological". If you're old enough to know what those words mean or old enough to use a dictionary, you have no business to be believing in Santa. — Alexis Jazz (talk or ping me) 17:07, 25 April 2021 (UTC)[reply]
I tried, but unfortunately, they were opposed to calling it "fictional character." In the interim, I tried to clarify that "legendary" meant "from folk tales" by wiki-linking it and the word "character" to clarify the meaning. Félix An (talk) 17:26, 25 April 2021 (UTC)[reply]
Well, legendary does justice to both being an imaginary character and losely based upon a real person. To tell the truth: real, hard-core Dutch Protestants hate Sinterklaas, Santa and Christmas, as popish propaganda. According to them a Christmas tree is Pagan at best and Satanic at worst. Tgeorgescu (talk) 17:31, 25 April 2021 (UTC)[reply]
For the record, I love Christmas, and I sing Christmas songs at Christmas and say "Merry Christmas" to people. I just don't like the fact that I was lied to for so many years. I even helped the owner of emailSanta.com get his article published in AfC, while modifying it so that it clarified that the website was merely a simulation as per Wikipedia:NPOV and Wikipedia:NOTCENSORED. Félix An (talk) 17:33, 25 April 2021 (UTC)[reply]
I had a professor who had a Catholic grandma and a Protestant grandma, and for them Christmas was an occasion for quarrel. As a compromise solution, he had an unadorned evergreen branch in his room. Tgeorgescu (talk) 17:37, 25 April 2021 (UTC)[reply]
I should have expected this, but a request for comment on the topic exists and resulted in "legendary character". Also in the RfC is the suggestion "In traditional festive legend, the character of Santa Claus is said to bring gifts" which would be accurate. I'd have to disagree with "imaginary" though, Donald Duck isn't imaginary either. I think "legendary" is pretty bad. Dragons and those who slay dragons are legendary. By the common definition, Santa isn't. — Alexis Jazz (talk or ping me) 17:37, 25 April 2021 (UTC)[reply]
What do you think is the best choice of words used to describe Santa? Félix An (talk) 17:41, 25 April 2021 (UTC)[reply]
Félix An, that's irrelevant. The question is what lead text could have consensus. I think next July a new RfC can be started. (a year after the last one) Start a discussion before that to collect viable alternatives. Present the alternatives in a clear fashion. Ask voters to include their second and/or third choice. Limit the new RfC to the description in the lead section, don't muddle the RfC with questions about the inclusion of parents or criticism. — Alexis Jazz (talk or ping me) 18:10, 25 April 2021 (UTC)[reply]
OK, that seems like a good idea. I hope you can suggest some good alternatives too. Thanks for the idea! Félix An (talk) 18:11, 25 April 2021 (UTC)[reply]
I think the essay is an appropriate endorsement of WP:NOTCENSORED. I'm okay with the current phrasing "legendary", since it's both fully factual and doesn't ruin the myth right in the first sentence/top of Google results. I'm assuming we elaborate in the body, but if a kid has the maturity to read through an adult-level historical account, they're probably ready to learn the truth. I've never been a fan of having a custom where society lies to children, but I think per WP:PLA we can make the slightest bit of deference to it by using "legendary" rather than "fictional". But that deference has to immediately end the moment it would interfere even the slightest bit with our ability to write a neutral encyclopedia. {{u|Sdkb}}talk 20:03, 26 April 2021 (UTC)[reply]
I think "legendary" is more accurate than "fictional". The word "fictional" implies origin in a work of fiction — a novel, a play, something like that. In what novel was Santa invented? "Folkloric" might be still better. --Trovatore (talk) 20:22, 26 April 2021 (UTC)[reply]
Since you ask, I think it's stupid and jejune, and pretty insulting to boot. "If you are going to edit on Wikipedia, you should form principles and you should stick to them", which I guess translates to "agree with me". Thanks for the lesson on principles. The essay? It's appropriate for a high-school level of discourse I suppose. It's does represent a remarkably dense cluster of statements that meet the Tiresome Trifecta: didactic, false, and annoying. Jesus fuck, what a killjoy. Remind me not to invite this person to my kid's birthday party ("We all die and rot in the ground and it all comes to nothing, and now you're a year closer to that, and your parents will go first and leave you all alone. What's that? I'm just telling him the truth.) Oops sorry to criticize your essay there, but to the quote a commenter above, parents should stop lying to their kids, so just applying the same principle here. Herostratus (talk) 00:16, 27 April 2021 (UTC)[reply]
--TheSandDoctor Talk 08:56, 28 March 2021 (UTC)
Administrator note I left this section open (separate from the close above) as I believe this discussion is badly needed. However it's not a discussion that requiers admin attention, and should probably be moved elsewhere. Ivanvector (Talk/Edits) 14:13, 11 April 2021 (UTC)
Agree . RaptorLake (talk) 21:14, 15 April 2021 (UTC)
