Wikipedia:Village pump (policy)

"WP:VPP" redirects here. For proposals, see Wikipedia:Village pump (proposals).

 Policy Technical Proposals Idea lab WMF Miscellaneous 

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

The policy section of the village pump is used to discuss already-proposed policies and guidelines and to discuss changes to existing policies and guidelines. Change discussions often start on other pages and then move or get mentioned here for more visibility and broader participation.

• If you want to propose something new that is not a policy or guideline, use Village pump (proposals). For drafting with a more focused group, you can also start on the talk page for a WikiProject, Manual of Style, or other relevant project page.
• If you have a question about how to apply an existing policy or guideline, try one of the many Wikipedia:Noticeboards.
• If you want to ask what the policy is on something, try the Help desk or the Teahouse.
• 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.
• If you want to propose a new or amended speedy deletion criterion, use Wikipedia talk:Criteria for speedy deletion.

Please see this FAQ page for a list of frequently rejected or ignored proposals. Discussions are automatically archived after remaining inactive for two weeks.

« Archives, 177, 178, 179, 180, 181, 182, 183, 184, 185, 186, 187, 188, 189, 190, 191, 192, 193, 194, 195, 196, 197

Administrator Recall

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.

This discussion forms part of a debate on adopting a community-based process for the involuntary removal of administrator rights, administrator recall. This topic was most recently addressed at the 2024 Requests for adminship review; more background information may be found in a section below. The question of this request for comments was whether the result reached during that discussion immediately assumes force of policy, or whether it requires further ratification.

Due to the unusual nature of an RfC to clarify the outcome of a previous RfC, participants at times addressed somewhat different matters in their comments, and some cast bolded support or oppose votes on slightly varying questions. In this closure, I shall focus on the key question as identified above, that is, whether we in principle now have a policy on administrator recall, or not.

On the English Wikipedia, there are no formal requirements for policy changes; that is, there is no specific process that must be followed. The relevant policy Wikipedia:Policies and guidelines § Content changes only specifies that "Major changes should also be publicized to the community in general; announcements may be appropriate." This, to me, means that this RfC is a valid way of figuring out where we want to set the threshold for this particular policy amendment; there is no unequivocal policy argument to either adopt the Phase II result as policy or not. The RfA review was also publicized through several standard channels used for important discussions, fulfilling that requirement.

Proceeding to the discussion at hand, it appears at first sight that the bold yes votes significantly outnumber the noes. However, as mentioned above, in this discussion, bold words can deceive. Furthermore, some editors commented on the contents of the Phase II result rather than on whether it carries the force of policy. I have deemed such arguments irrelevant to this discussion. While weighing this is not entirely quantifiable, and I will therefore not state exact numbers, I consider those in favour of the procedure already being adopted to have a clear numerical superiority.

Some of those who opposed pointed out certain discrepancies in the information provided in the RfC statement, in the Phase II closures, and at Wikipedia:Administrator recall. As of the time of closing, many of these concerns have been resolved, see for example the note at the end of this closing statement. Some things remain undecided; in particular, how the 30 day limit should apply when an administrator elects to re-request through administrator elections. While some editors stated that unresolved questions impede the adoption as policy, most thought that any outstanding issues may be resolved through normal editing. Some editors also opined that, while there may be consensus for the individual conclusions of the review, the policy page written on the basis of these will need to be the subject of a separate RfC to adopt or not. Again, I see a majority of editors being of the opinion that the conclusions may be accepted as policy now, with any further issues resolved by normal editing.

In summary, this RfC has resulted in consensus to adopt administrator recall, according to the Phase II result, as policy. Now, the following should happen.

1. It shall be ensured that Wikipedia:Administrator recall exactly documents the closures of Wikipedia:Requests for adminship/2024 review/Phase II/Administrator recall.
2. Wikipedia:Administrator recall shall be marked as a policy, and references to it inserted at Wikipedia:Administrators and other relevant pages.
3. Any further issues regarding the administrator recall policy will be resolved through normal editing.

Please note the following discrepancies between the present RfC statement and the result of the Phase II RfC. The consensus at Phase II was that reconfirmation via administrator elections shall be subject to a fixed 55% threshold. The 25 editors supporting a recall petition must be extended-confirmed users. The result of this discussion concerns the existing consensus as documented at Wikipedia:Requests for adminship/2024 review/Phase II/Administrator recall, not the summary in the RfC statement. -- Maddy from Celeste (WAVEDASH) 15:38, 26 October 2024 (UTC)

---

Is there consensus to have administrator recall based on the consensus reached during Wikipedia:Requests for adminship/2024 review? 03:11, 22 September 2024 (UTC)
The consensus reached there established recall with the following process:

Petition

• Cannot be launched until 12 months have passed since the user has successfully requested adminship or bureaucratship, re-requested adminship, or become an arbitrator.
• Open for up to 1 month.
• Notification is posted to Wikipedia:Administrators' noticeboard.
• 25 editors must support the petition to trigger the re-request for adminship process.
• The format allows for discussion and reasoning to be explained.
• To support a petition, you must meet the criteria to participate in a request for adminship. You must not support more than 5 open petitions. There is no limitation on how often someone can initiate a petition.
• If a petition for a given admin fails to gain the required support, another petition for that admin cannot be launched for six months.
• Support statements can be stricken based on the same criteria as for requests for adminship.

Re-request process

• A bureaucrat will start a re-request for adminship by default. The admin can request a delay of up to 30 days. If the re-request does not start by then, the admin can have their privileges removed at the discretion of the bureaucrats.
• The re-request can also take the form of participating in an admin election. (Not clear what the consensus is regarding the need for the election to fall within the 30-day window).
• For either a re-request or an election, the following thresholds apply:
  • below 50%: fail
  • 50–60%: Bureaucrats evaluate consensus
  • 60% and above: pass

Background

During phase 1 of WP:RFA2024 Joe Roe closed two proposals for recall with the following close (in part with emphasis in the original):

Considering § Proposal 16: Allow the community to initiate recall RfAs, § Proposal 16c: Community recall process based on dewiki, § Proposal 16d: Community recall process initiated by consensus (withdrawn), in parallel, there is a rough consensus that the community should be able to compel an administrator to make a re-request for adminship (RRFA) in order to retain their administrator rights. However, there is also a consensus that the process(es) for initiating an RRFA needs to be worked out in more detail before this is implemented. Phase II of this review should therefore consider specific proposals for RRFA initiation procedures and further consensus should be sought on which, if any, is to be adopted. The dewiki-inspired process suggested in Proposal 16c was well-supported and should be a starting point for these discussions.

When the second phase began the process was, after 3 days, structured in a way that took Proposal 16c and offered alternative options for certain criteria. This was done in good faith by Soni who had originally proposed 16c. Some editors objected to this structuring at the time and/or suggested that a 3rd RfC would be needed to confirm consensus; Joe Roe would later clarify well after the process was underway that the Phase 2 structure did not, in his opinion as closer, reflect the consensus of Phase 1. Others, including Voorts who closed most of Admin recall phase 2, suggest that there was adequate consensus to implement the process described above. Post-close discussion among editors has failed to achieve any kind of consensus (including whether there needs to be an RfC like this). As an editor uninvolved in the current discussions about Admin recall until now, it seemed to me that the clearest way to figure out if this recall process has consensus or not is to ask the community here rather than have this discussion in parallel with an attempt to recall someone. Barkeep49 (talk) 03:11, 22 September 2024 (UTC)

Survey (administrator recall)

• (involved) The question here is simple: did a two-phase discussion that reached consensus in both phases also achieve an overall consensus to implement? The answer is equally simple: yes, it did. The current strongest argument against this idea seems to be that Phase II's formatting didn't give enough leeway for someone to propose a recall system distinct from the dewiki process (while still using that as a starting point). But there was an open discussion, and I don't recall seeing a different idea gain any significant amount of traction. If we really need to go through an entirely new RfC to double-confirm a proposal we've already accepted in principle and fine-tuned, fine, let's do it, but it seems like a waste of community time to me. theleekycauldron (talk • she/her) 11:10, 22 September 2024 (UTC)

  The open discussion section was closed after three days though. – Joe (talk) 11:49, 24 September 2024 (UTC)

  Despite this, people added additional proposals, and additional options to existing proposals, and nobody complained about the open discussion section being closed, for months thereafter. Levivich (talk) 18:24, 24 September 2024 (UTC)

• (uninvolved) Yes consensus was reached. Naturally new tweaks/discussions will come along. Let's have specific RfCs on those. ~ 🦝 Shushugah (he/him • talk) 11:38, 22 September 2024 (UTC)
• Yes there is a consensus (uninvolved). A legitimate objection is that the process of managing the second RfC may have stymied other possible outcomes beyond a de wiki style process, and this may have been the case. However, RfCs with perceived flaws tend to generate lots of comments pointing this out (as we can already see below) and I'm just not seeing that that in the 2nd phase RfC. The 1st phase confirmed that the community wanted a recall process, the 2nd phase asked for proposals to be developed for implementation and there was a consensus found within that discussion for a specific variant. In the interest of not letting the perfect being the enemy of the good, I believe there is sufficient support for the admin policy to be updated based in this outcome, with further adjustments being made as required (or indeed removing it entirely should a subsequent consensus determine that it should). Scribolt (talk) 15:42, 22 September 2024 (UTC)
• Strangely-worded question. No, there isn't currently a consensus for this proposal; but yes, I think we should reach consensus for it at this RfC.—S Marshall T/C 16:45, 22 September 2024 (UTC)
• A key challenge in trying to reach agreement by consensus is that interest tends to wane as discussion moves from higher-level concepts to more fine details. One way to address this is to get consensus for a general initiative, obtain consensus for key aspects to incorporate, then work on implementation details. For this specific situation, I think the phase 2 discussion did a sufficient job at taking the support shown during phase 1 and working out agreement on the broad-stroke steps for a recall process. As always, because it's hard to get people to pay enough attention to reconcile specific wording, part of working out the implementation means finding a working procedure that is the central object illuminated from different directions by people's statements. I feel the phase 2 results reveals enough scaffolding to proceed with implementation. isaacl (talk) 17:00, 22 September 2024 (UTC)
• (involved) Yes. There is consensus per my comments in the post-close discussion, as well as per leeky and Scribolt above. Those editors raising objections to the idea of admin recall or the proposals that gained consensus, but who did not participate in the earlier RfCs, should have participated; phases I and II were both widely advertised (I remember them being posted at T:CENT, VPP, AN, AN/I, etc.). I worry that a third RfC will fatigue the community and disproportionately draw the most vocal opponents to the process, resulting in a small group of people overriding a consensus already twice-determined by the community. voorts (talk/contributions) 20:51, 22 September 2024 (UTC)
• (I closed some of the proposals) I don't know why we need an RfC to say "yes, this RfC was correct", but yes. Charlotte (Queen of Hearts • talk) 22:40, 22 September 2024 (UTC)
• I participated in both Phase I and Phase II. I believe the results of Phase II achieved consensus and should be implemented. I do not see how this contradicts the results of Phase I. As others have pointed out, an actual policy page is still being drafted and might have to go through yet another RfC. Having an RfC on the validity of each step seems like a waste of time. Toadspike [Talk] 07:34, 23 September 2024 (UTC)
• I think your question answers itself. "Was there consensus for the consensus"? The answer is obviously yes. Now, if you want to ask a different question, open a different RFC. --130.111.220.19 (talk) 18:14, 23 September 2024 (UTC)
• No, there isn't consensus for the recall process proposed at Wikipedia:Administrator recall. I'll reiterate a comment I made on the Phase II talk page: taking the mini-consensuses from that phase, then using them to cobble together a process, doesn't translate into a solid policy with broad community consensus. The fact that various aspects of the proposal, even now, are up in the air disproves the notion that "the consensus already exists". Those who are advocating for Wikipedia:Administrator recall need to finalise that page, then present it for a simple yes/no RfC, so that the consensus (or lack thereof) on the policy as a whole is beyond question. SuperMarioMan (Talk) 20:55, 23 September 2024 (UTC)
• No, there is no consensus for this, and I've explained why on the pages where the proposal is being developed. But I think it's unfair to ask this question now, because the editors who support the proposal are still working on it. I therefore think this RfC should be closed as premature. --Tryptofish (talk) 21:51, 23 September 2024 (UTC)
  • I had hoped that this RfC would be withdrawn, but it appears that it won't, so I feel the need to say why this RfC cannot establish consensus for the policy change.
    • First, Barkeep49 gets the facts wrong in the statement of this RfC. He says: Joe Roe would later clarify well after the process was underway that the Phase 2 structure did not, in his opinion as closer, reflect the consensus of Phase 1. In fact, he said more than that: I'm really sorry to say this, but reading it all through now, I think Wikipedia:Requests for adminship/2024 review/Phase II/Administrator recall has trainwrecked... I just cannot see how a genuine consensus can be said to come from a process like this... The only way I can see of salvaging this is to take whatever precise version of 16C got the most support and present it as a straight support/oppose RfC. [1]. Barkeep49 goes on to quote Voorts as having determined that phase 2 established consensus: Others, including Voorts who closed most of Admin recall phase 2, suggest that there was adequate consensus to implement the process described above. But in fact, Voorts drew a clear distinction between his close of individual sections, as an uninvolved closer, and his personal opinions about overall consensus, which were separate from the close: [2], [3].
    • And the bullet-list summary differs in some substantive ways from what appears to be the proposed policy. 25 editors must support the petition. Isn't it 25 extended confirmed editors? Who closes the petition? In fact, this is still being discussed: [4].
    • Since when are policy pages simply a bullet-list? Are we being asked to establish the bullet-list as a policy page, or are we being asked about Wikipedia:Administrator recall? The latter is beyond any question a work-in-progress. So if it needs to be changed as the editing process there continues, are we establishing consensus for the current version, or for some indeterminate version that will emerge in the future? And if the real purpose of this RfC is to establish consensus against, is that a fair process?
    • Phase 1 established consensus for some form of process. Phase 2 established consensus for some particular forms of the process, but did not establish whether those forms are actually to be implemented as policy, or whether those forms are the best version to be submitted as a policy proposal. This RfC muddles two different questions: whether the process so far has already established consensus, or whether the proposal summarized in bullet points should now be adopted as policy. And some editors here have been answering the first question, whereas others have been answering the second.
    • No one has answered the question of what is inadequate with the status quo, with ArbCom handling desysop requests.
    • The bullet-list proposal would be a disaster for Wikipedia if enacted here. It can't even be launched within the first year after the successful RfA? What happens if an admin does objectional things before then? More importantly, we are in a time when many members of the community are deeply concerned that we do not have enough new admins emerging from RfA, and that we are starting to see backlogs. Many members of the community regard RfA as being unattractive to well-qualified candidates, too stressful, not worth the aggravation. So if any random group of 25 users can force a recall, and just a few can start the petition process, how will that affect administrator morale? Will even more qualified RfA candidates decide against applying? Will current admins become too fearful of angering 25 disruptive editors, and hold back from dealing with contentious tasks, such as AE?
  • At least we should have a fully-developed proposal for the community to evaluate. Given that there are editors who are working on just that, it seems foolish to demand an up-or-down RfC now, before they have finished, on the theory that this would save them the trouble of working on something that will fail. Plenty of editors want the proposal to succeed, so they are not being imposed upon by giving them the time to finish. And the proposal here isn't ready for prime time. --Tryptofish (talk) 22:56, 25 September 2024 (UTC)
• Yes (uninvolved) - There is a super clear consensus to have an administrator recall. Still work to be done om the actual policy page. But to the question of this RFC, Is there consensus to have administrator recall based on the consensus reached during the last review? Yes clearly, otherwise the right next step would be to challenge that close. This is not the place to relitigate the RFC or how the policy page is being created. PackMecEng (talk) 13:13, 24 September 2024 (UTC)
• No IMO the question is unclear but I think interpreted as "was it decided that the deWiki version be adopted?". In shorthand, the main close was a general consensus that there should be a recall process, with the related verbiage in essence implicitly saying that it needed to be developed and then approved. The close on adopting the deWiki version was that there was insufficient participation (in this context) to consider it to be a decision either way. So the next step is to develop a proposal that can get wide support and get it approved. While keeping in mind that the first close says that it's already decided that "we want something like this" and so that question should not be revisited, and "There should not be any such recall process" is not a valid argument at this point. North8000 (talk) 13:54, 24 September 2024 (UTC)

  That next step is what Phase II was. Levivich (talk) 18:19, 24 September 2024 (UTC)

• Yes. If this discussion is "Should Wikipedia:Administrator recall be implemented?", my answer is yes. That is effectively what the list of points above effectively are. If this question is "Is there consensus already to implement Wikipedia:Administrator recall?" then my answer is also Yes. I think there was consensus via Phase II to do this. If people believe there isn't, then I strongly prefer resolving the first question right now instead of bunting this entire thing to a second RFC further down the line.
  I also personally would have preferred a week while editors already discussing the matter at Wikipedia talk:Administrator recall could resolve this. But the cat's out of the bag, and nobody seems to actually close this as premature. So I would prefer going through with this RFC instead of alternatives that draw this out for everyone. Soni (talk) 05:06, 25 September 2024 (UTC)
• Regarding Soni's first question, my answer is unreservedly Yes. Regarding Soni's second question, my answer is a Very Weak Yes. Also, this RfC is a premature mess. Tazerdadog (talk) 18:30, 25 September 2024 (UTC)
• Yes. ~ ToBeFree (talk) 22:02, 25 September 2024 (UTC)
• Yes. We do not need an RfC to answer the question "Did the previous discussion, with a consensus close, actually close with a consensus?" Just get it done. Details will, as usual, be refined as we go along. If the entire thing turns out, after post-implementation experience, to be a bad idea, then it can be undone later. PS: If there is doubt whether a close of an RfC or other discussion actually reached the consensus claimed by the closer, the place to hash that out is WP:AN (unless it's subject to a more specific review process like WP:MRV for move disputes, and WP:DRV for deletion ones).  — SMcCandlish ☏ ¢ 😼  13:08, 27 September 2024 (UTC)
• Involved yes there is consensus, yes this should be implemented, per those above and in particular leeky. HouseBlaster (talk • he/they) 18:12, 28 September 2024 (UTC)
• No. The partial trainwreck of the discussion that happened at the Phase II RfC meant that consensus for several critical aspects of the recall proposal did not gain sufficient consensus to enact such a significant change to a core policy (WP:ADMIN). And for my own part I failed to see a consensus on some matters at all, though I suppose reasonable minds can disagree on the matter. JavaHurricane 10:31, 29 September 2024 (UTC)
• Yes per S Marshall. The process should continue with the understanding that there is a consensus for recall on this basis though details remain to be finalized. Eluchil404 (talk) 21:45, 29 September 2024 (UTC)
  • I don't think the question here is whether there is consensus for some future version, in which the details will have been finalized. It's whether there is consensus for what it says at the top of this RfC. --Tryptofish (talk) 22:50, 29 September 2024 (UTC)
    • Right. And my position is that there is (or at least it should be established here) consensus for the form of recall described in the 14 bullet points listed above. Some people in this discussion have queried the precise interpretation of some of the points, so another round of workshopping precise language would not be amiss, but the proposal should continue to move forward on this basis without "going back to the drawing board" because of concerns about a previous RFC. Eluchil404 (talk) 23:43, 29 September 2024 (UTC)
• Yes, there is consensus to adopt an administrator recall process that includes the characteristics that achieved consensus in RFA2024 Phase II. To my eye, the proposal here successfully reflects that consensus. ModernDayTrilobite (talk • contribs) 14:41, 30 September 2024 (UTC)
• "25 editors" is much too vague. Could be 25 IPs? Only logged in editors with some experience should be allowed, and the simplest way is to require EC. Zero^talk 02:47, 3 October 2024 (UTC)

  Already done. The suffrage requirements for recall petitions are "same as RFA". That was one of the Phase 2 consensuses (consensi?). Phase 1 consensus set RFA suffrage to EC. Levivich (talk) 03:33, 3 October 2024 (UTC)

• Yes, confirm consensus. The weight of community involvement and the clear consensus close are sufficient to grant this process the effect of policy immediately. I will say this: I am absolutely shocked that the second phase of the discussion was not better advertised; given the long-anticipated nature of this process and the importance to community functions moving forward, it should have been better attended. And yet, the dozens of editors that did participate came to reasonable and clear consensus conclusions on various facets of the process. Beyond that, we are years deep into repeated derailing of the creation of this function, despite clear community support for some sort of process. There is absolutely no reason why further discussion to clarify, alter, or amend any provision of the process cannot take place after the process is codified in its namespace. But the time has come for the process to exist, and there is nothing egregiously problematic in what was decided upon in the foregoing discussion. With the caveat that, no matter what the community decided upon for the initial procedure, there are bound to be things we can only think to address and adjust after the first community RRfA discussions take place. SnowRise ^{let's rap} 10:33, 3 October 2024 (UTC)

  Regarding notifications about the second phase of discussion: a watchlist message was posted, the centralized discussion notice box was updated, and a link was posted to the Administrators' noticeboard (there was also a link present in the announcement of the closure of phase 1). A mass message was sent to what I believe is a list of participants in phase 1. isaacl (talk) 16:47, 3 October 2024 (UTC)

  Well, fair enough, if it was posted on CD, which is arguably the single best thing you can do to promote an issue. But I do think spaces like VP are a vastly more reasonable place for posting a notice intended to draw in general community input about the recall of admins, compared to AN, with it's limited traffic mostly constrained to admin activity (or at least as much constrained as any open space on the project). In fact, some may argue (though I'm certain it was lack of forethought rather than intent) that the only noticeboard to receive a notice of the discussion being the one noticeboard with the highest admin-to-non-admin activity ratio is maybe the least optimal way to advertise a discussion that would seek to create the community's first direct means for recalling admins. The CD link seems to have been the only notice well-calculated to reach an average community member: the mass mailer, the discussion link in the closure of phase I, and the watchlist notice, all of those were only ever going to reach those who participated in Phase I. Which is good, but again, probably a lot less than this discussion warranted. SnowRise ^{let's rap} 17:35, 4 October 2024 (UTC)

  Watchlist notices get pushed to everyone with an account, no? Also, CD is posted at the top of VPP. voorts (talk/contributions) 19:55, 4 October 2024 (UTC)

• Yes (involved), but I agree with everyone who is saying that this is pre-mature fanfanboy (block) 18:27, 3 October 2024 (UTC)
• Yes there appears to be community consensus to implement an Administrator Recall process as described. I think some of the concerns raised are genuine, especially the potential for abuse... But I doubt the community would look kindly on editors who chose to WP:GAME this new system. Horse Eye's Back (talk) 20:06, 4 October 2024 (UTC)
• Yes (involved). The existence of the pre-voting "open discussion" section, as well as the widespread "find a consensus" sentiment was enough for the consensus found to be valid. Mach61 14:10, 7 October 2024 (UTC)
• Yes (involved). From the get-go, the purpose of WP:RFA2024 was to reach consensus -- not to workshop a proposal for later ratification, but to workshop proposals and approve/deny them in the same RFA2024 process. In Phase I, Proposals 16 and 16c, the overall proposal for a community-based recall system (#16) reached consensus. On the numbers, 65 editors voted, and it was 43-22. On the proposal for a specific dewiki-like system (#16c), 34 editors voted, it was a 25-9 majority, but this was determined to not be consensus because of the (relatively) lower participation.

  We went on to Phase II, where specific proposals for details of the recall system were made. The purpose of Phase II was, clearly, to iron the details from Phase I #16c, not to draft a proposal for submission to the community, but to decide the details, in Phase II. This is evidenced by the many "find a consensus" votes in Phase II (the phrase appears 27 times on the page, in addition to which there are various variations on the theme), which were editors expressly saying they'd rather have a recall system in place with any of the proposed details, than have the proposal for recall fail due to disagreement about some of its details. It was clear that the participants wanted Phase II to end with a consensus for an actual system, not a proposal for a third round of RFC. 93 editors participated in Phase II [5], which is even more than in Phase I.

  Both Phase I and II were widely advertised, tagged with the RFC template, advertised on watchlists, and posted on WP:CENT -- they more than complied with WP:PGCHANGE. They had broad participation, and the fact that Phase II ended with a system very similar to dewiki only confirms the budding consensus from Phase I. The fact that the "open discussion" section of Phase II was closed after a few days does not undermine the consensus-forming process in my view; discussion continued, new proposals continued to be made, and some voted against the entire idea of recall. Nevertheless, consensus was formed on various proposals, leading to the system that is now well-documented at WP:RECALL.

  So, yes, this months-long process confirmed what we all already knew was global consensus (to have a community-decided involuntary recall system, and to have it be modeled on dewiki's successful system); this RFC will be the third time in a single year that this global consensus will be confirmed. When this RFC is closed as "yes," as I believe it will be, we should put the policy template on WP:RECALL and that should dispel any and all doubts as to whether WP:RECALL has consensus. 100+ editors in 3 rounds of voting is more than enough to establish global consensus. Levivich (talk) 17:47, 7 October 2024 (UTC)

• Yes and No. It appears that Wikipedia:Administrator recall is still being developed and that these dot points are the basis for that development. There is a consensus for a recall policy according to these dot points but as has been pointed out above these dot points are not a policy in and of themselves so cannot be adopted immediately. When there is consensus for a barebones policy (the dot points) it is then developed into an actual policy page before a final RfC to adopt it. That's the normal process and should be followed here. So, yes there is a consensus to have a recall process along the lines of the dot points and that is correctly being developed into a policy before final adoption so, no, there is not yet a consensus to turn the wordy version at Wikipedia:Administrator recall into policy. Callanecc (talk • contribs • logs) 01:49, 8 October 2024 (UTC)

  The current version is less than 500 words and it's been stable for one week. voorts (talk/contributions) 01:57, 8 October 2024 (UTC)

  Sounds like it's ready for an RfC for formal adoption as a policy then? I don't think it's appropriate to merge this RfC into that given that the proposal here is a series of dot points that is different to what's at Wikipedia:Administrator recall. For example, I wouldn't support 25 editors as listed in this proposal but would support 25 extended confirmed editors. Other questions have been raised above (for example what if there's a concurrent ArbCom case) and I would encourage editors who have raised those concerns here to take them to Wikipedia talk:Administrator recall for a further discussion and whether or not they should be incorporated into that proposal before it is put forward for adoption. Callanecc (talk • contribs • logs) 00:26, 9 October 2024 (UTC)

  25 extended-confirmed editors is already a requirement. A fourth RFC seems excessive. Levivich (talk) 01:45, 9 October 2024 (UTC)

  +1 Yet another reason why this should have been workshopped first: this proposal is missing a crucial part of the previous stage. Sincerely, Dilettante Sincerely, Dilettante 01:51, 9 October 2024 (UTC)

  While I have expressed agreement with this sentiment before, I am also a firm believer of not putting everyone through additional WP:BURO after this. So I'd rather User: Barkeep49 or someone else add a link to WP:Administrator recall to the topic above instead of trying to wrangle a 4th RFC. I'd phrased my !vote above to answer the question I think we should be asking anyway. Soni (talk) 06:30, 9 October 2024 (UTC)

  Agreed: Callanecc and Dilettante's points are accurate and well taken, but this really does come down to a more direct call on community will and BURO. I think the obvious emerging consensus here is that if a version of the policy language has already been rendered which includes all of the consensus elements agreed to for the process, without any glaring contraventions or other issues, then as soon as this discussion closes with a consensus in the affirmative, that version of the guideline becomes policy immediately. Repeating the process yet again for purely pro forma reasons is not necessary, appropriate, or a reasonable use of community time. Let's remember that any version validated can thereafter be reasonably expected to be subject to discussion and further tweaking, particularly in its first months.

  EDIT: Though I do think one reasonable thing that could be done thereafter would be to advertise every major disputed discussion on the guideline talk page at VPP for the next six months (and having a tendency to do so thereafter, really). It is, after all, a new process that has non-trivial consequence to our administrative operations, so continuing to have heavy community input in its initial evolution here can only be regarded as a good thing. SnowRise ^{let's rap} 03:18, 13 October 2024 (UTC)

  Adding on to the pile that says that we've already gone through so much bureaucracy at this point that any more after this would be really out of the norm. If there's consensus here, mark it as policy and work out fine details as they are brought up. If there's not consensus, let's find out right now, and not after more formal RFC cycles. Tazerdadog (talk) 18:12, 15 October 2024 (UTC)

• Yes on principle, but some points still need to be workshopped. How does 50–60%: Bureaucrats evaluate consensus work for an election? Is it split in the middle? This kind of details should've been made clear before putting the proposal up to a vote. (Edit: looking at the comments below, this appears to have already been discussed) Chaotic Enby (talk · contribs) 06:15, 9 October 2024 (UTC)

  Yeah it's 55%, which was added to WP:RECALL a few weeks ago (following that discussion below). Levivich (talk) 06:22, 9 October 2024 (UTC)

• Yes, a consensus was clearly reached. But I recomend another RfC after this just to make sure. SerialNumber54129 17:28, 24 October 2024 (UTC)

  @Serial Number 54129 This is that confirming RfC Mach61 18:58, 24 October 2024 (UTC)

General discussion (Administrator Recall)

• Close as the proposal is still being developed. A draft of a full proposal is being discussed at WP:Administrator recall that refines and adds clarification to the closes at WP:RFA2024. All editors are welcome to participate in the discussion. I do anticipate that this proposal will come back for community discussion. --Enos733 (talk) 03:35, 22 September 2024 (UTC)

  As noted when this was raised on my talk page, the work there appears procedural. There is no agreement even there about whether or not this is already policy or not. Having editors spend time developing something in detail when the core policy doesn't have consensus is a poor use of time in my opinion. If it does have consensus the details can be worked out and will be made to happen. We have seen that happen with Admin elections coming out of the RFA2024 process. Best, Barkeep49 (talk) 03:49, 22 September 2024 (UTC)

  I understand where you are coming from, but the detailed efforts identified a couple challenges with how to implement the close, and I wouldn't suggest that the policy described above is the exact proposal coming from those efforts (although it is in harmony with the closes in WP:RFA2024). While every policy could be further refined, I am of the belief that our community is best served by bringing forward a more complete proposal for community discussion. - Enos733 (talk) 04:28, 22 September 2024 (UTC)

  This should be closed. For most people, whether they support admin recall depends very much on the details of the proposed mechanism. For a sensible RfC, the mechanism has to be spelled out (as above) but must not change for 30 days. That does not match reality at the moment. Johnuniq (talk) 04:48, 22 September 2024 (UTC)

  @Johnuniq genuine question: what details do people need beyond which there is already RfC consensus for? Best, Barkeep49 (talk) 15:46, 22 September 2024 (UTC)

  Barkeep49, I oppose the proposal, but I think you should withdraw this RfC for now. What people still need (or at least should be entitled to) is to see a full proposal, a proposed policy page, not the bullet list summary you posted here, and to see a rationale for adopting the proposal, prepared by its supporters. And editors are working on those things now. --Tryptofish (talk) 21:59, 23 September 2024 (UTC)

• I long ago tuned this out as a TL;DR waste of my time. But curious, is there a consensus that the current Arbitration Committee-led "recall procedure" is not up to the task, and should be discontinued? Or, rather, is there a consensus that both procedures may be used. Can an admin be subject to both an Arbcom case *and* a "community recall procedure" at the same time? Is there a consensus for that? To be clear, I oppose the possibility of simultaneous, competing recall procedures. wbm1058 (talk) 09:53, 22 September 2024 (UTC)

  @Wbm1058 Nothing in this above would prevent someone from becoming a party to an arbcom case, or from arbcom issuing any remedy. How would you like a blocking condition to work? Perhaps a prohibition on community recall rrfa launching while the admin is a party to an arbcom case? — xaosflux ^Talk 10:42, 22 September 2024 (UTC)

  If stripping the Arbitration Committee of the power to desysop isn't part of the package, this whole "recall procedure" strikes me as highly problematic. Imagine an Admin suffering through a month-long Arbitration Commmittee proceeding, ending with an "admonishment" to the administrator, followed hours later by the opening of a "community recall procedure". – wbm1058 (talk) 10:52, 22 September 2024 (UTC)

• Bureaucrats evaluate consensus for 50-60% is invalid for the election option, that is strictly a vote - so needs a specific value. — xaosflux ^Talk 10:38, 22 September 2024 (UTC)

  There has been consensus for 60% threshold for Admin elections. The same has been summarised in Wikipedia:Administrator recall as well (which was intended as a summary of Phase II) but I don't see a link to it in the main proposal here Soni (talk) 10:54, 22 September 2024 (UTC)

  So perhaps the description above just needs to be clarified. — xaosflux ^Talk 14:41, 22 September 2024 (UTC)

  Should be consensus for 55%. Option C stated the midpoint of whatever passed in the other discussion. Option C won there, which was 50-60%, so the midpoint is 55% which is explicitly called out in the first discussion. Pinging @Voorts: in case I'm completely misreading something here. Tazerdadog (talk) 18:51, 22 September 2024 (UTC)

  55% is correct. voorts (talk/contributions) 20:31, 22 September 2024 (UTC)

  @Xaosflux, @Soni, and @Tazerdadog: I've fixed the close to state that it's 55% without 'crat discretion; I think I added that bit by accident because that's nowhere in that discussion. voorts (talk/contributions) 20:45, 22 September 2024 (UTC)

• Leaving aside everything else, this part is confusing: A bureaucrat will start a re-request for adminship by default. The admin can request a delay of up to 30 days. If the re-request does not start by then, the admin can have their privileges removed at the discretion of the bureaucrats. Is this implying that if the admin requests a delay then the admin is responsible for creating it? Why not have the 'crat create it after the delay, same as they would for no-delay? Anomie⚔ 14:39, 22 September 2024 (UTC)

  I don't like that part at all. I'd rather see the admin start their own RRFA within some short deadline (7 days - with possibly the option for asking for the 30 day extension) -- and if they don't start it anyone can ask at BN to process the desysop. Crats never have to edit, so requiring the crats to create a pageto move the process forward gives them a pocket veto. — xaosflux ^Talk 14:46, 22 September 2024 (UTC)

  I disagree with this RFC's summary of that part of the proposal. As I read it, an admin chooses whether to start an RFA (or stand for election), which must be done within 30 days, and if it's not done within 30 days, crats desysop with discretion ("discretion" such as taking into account whether the petition was entirely signed by obvious sock puppets or had the requisite number of qualified signatories, or to extend the period to 32 or 33 days instead of 30 due to the admin's RL schedule, things of that nature). Levivich (talk) 15:06, 22 September 2024 (UTC)

  Option E there is where it says the 'crat should open create the discussion. The other options had the admin being required to say "come attack me" within a certain period of time. The combination of E+A is where we got the confusion here, since E didn't explicitly say what should happen if a delay is requested. Anomie⚔ 15:11, 22 September 2024 (UTC)

  Yeah, I think the closer got it wrong by finding consensus for E. Only 6 people (out of 30+) voted for E. It's A, not E. Levivich (talk) 15:20, 22 September 2024 (UTC)

  OTOH, looks like only 9 of those 30+ voted after E was added. That part, at least, seems like it could use further discussion by people who care. Anomie⚔ 15:23, 22 September 2024 (UTC)

  I just asked the closer to reconsider it. Levivich (talk) 15:30, 22 September 2024 (UTC)

  This point is one of the pieces that has been ironed out at WP:Administrator recall. As I said above, and others have pointed out, this proposal is not completely ripe. - Enos733 (talk) 15:38, 22 September 2024 (UTC)

  Yeah I guess the current language at WP:RRFA handles it just fine. @Anomie and Xaosflux: take a look at WP:RRFA, I think that addresses your concerns on this point? Levivich (talk) 16:06, 22 September 2024 (UTC)

  🤷 Looks to me like they changed it from E+A to just A. That does resolve the confusion. Anomie⚔ 16:50, 22 September 2024 (UTC)

  I don't think it would ever happen, but in theory the crats could just wait 30 days and then decide to revoke privileges without any community input, which seems like a flaw, that part should be reworded to clarify who is responsible for starting the process in each situation. ASUKITE 17:08, 3 October 2024 (UTC)

• Close as premature. The page is a mess right now, as several people have posted above. It isn't anywhere near finalized so of course there will be holes and parts where it doesn't judge consensus. When I said "What we need is an RFC to decide whether or not we need another RFC", I didn't expect anyone to actually do it. Sincerely, Dilettante 15:48, 22 September 2024 (UTC)
• I'm a little confused as to what is being asked here: is this a request for approval of a process? Or are we judging whether consensus was previously formed for it? The latter does not seem to me a good question to ask, as it is sending us further into the weeds of a proposal that has already gotten out of hand with respect to creation and approval procedure. But that's how I read my colleagues' !votes above. Vanamonde93 (talk) 16:16, 22 September 2024 (UTC)
• Do we really need another bureaucratic mess that is another RfC? I think the last one had enough consensus. Ping me if there's anything in particular we're trying to work out and I'm not getting the point of this. I'm trying to take a step back from the more complicated aspects of the project right now but this is important. Clovermoss🍀 (talk) 16:20, 22 September 2024 (UTC)
• Close as a confusing, duplicative mess. The specific question in this RFC, as far as I can make out, is asking whether the previous discussion had consensus to implement something following discussion, or whether the outcome of that further discussion needs to be subject to an RFC. I don't think it's sensible to even ask that until that further discussion is complete and we can see the differences between it and the consensus outcome. However, above there appears to be discussion of things other than that question, and no clear agreement about what the consensus of the last RFC was (with the consensus as determined by the closer having changed at least once since the initial close) - other than more discussion of the details was needed (which seems to be happening in two places). I don't think it's possible for this discussion to be useful in any way so it should be closed before it creates even more confusion. Thryduulf (talk) 21:04, 22 September 2024 (UTC)

  @Thryduulf: I think there might be some confusion about what this discussion is for – it would definitely be silly if it was trying to ask people to assess the consensus of the post-close discussion on talk. This RfC asks the same question the post-close discussion has been focused on: did the Phase I and Phase II RfCs result in a consensus to implement? That, I think, is worth discussing. theleekycauldron (talk • she/her) 23:23, 22 September 2024 (UTC)

• The "25 editors" figure in the initial proposal was qualified as being extended confirmed. Definitely not supporting a process whereby any 25 editors, over the course of a full month, can start this process. — Rhododendrites ^talk \\ 13:13, 24 September 2024 (UTC)
• I don't think there's a consensus ... but whether there is or isn't, "There is no limitation on how often someone can initiate a petition." needs to be clarified. You can't support more than five open petitions, but then the next sentence says you can initiate a petition without limit. Those two statements need to be harmonized. --B (talk) 13:34, 24 September 2024 (UTC)

  I don't think "There is no limitation on how often someone can initiate a petition" is entirely accurate. There are limitations on how often someone can initiate a petition (there are cooling off periods, plus the 5-petitions-at-once limit), limitations that were decided in Phase II and are specified at WP:Administrator recall § Petition. Levivich (talk) 18:20, 24 September 2024 (UTC)

• Re:Close as premature comments, I said my piece above and on my talk page about why I thought (and think) it appropriate. I also don't think I hold any particular status other than being UNINVOLVED in this process. So if some other UNINVOLVED editor wants to close this as premature, I'm certainly not going to push back. Best, Barkeep49 (talk) 20:18, 25 September 2024 (UTC)
• For further background, see wp:Administrators_open_to_recall and the associated categories and pages. (including pages related to some actual recalls) When we came up with this back in the Jurassic Era, we intended it to be voluntary. It's interesting to see that there appears to be consensus that some kind of mandatory process be implemented. ++Lar: t/c 15:53, 9 October 2024 (UTC)

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

Looking for guideline, forgot where it is

I recall a while ago, I found and/or was pointed to a guideline that basically stated cosmetic changes to links or templates should not be done if there is no change in functionality or where the page links (such as replacing a link to an redirect with the link to the target page). Can anyone point me into the direction of that guideline? Steel1943 (talk) 19:26, 25 October 2024 (UTC)

Could it be WP:NOTBROKEN? (I also thought of WP:COSMETICBOT which is technically just part of the bot guidelines but my sense is in general people like human editors to at least be aware and minimize such edits.) Skynxnex (talk) 19:33, 25 October 2024 (UTC)

@Skynxnex: I'll look into it further, but that definitely gives me direction on what to look at. Thanks! Steel1943 (talk) 19:41, 25 October 2024 (UTC)

No such guideline exists. Gonnym (talk) 06:21, 27 October 2024 (UTC)

It's not a guideline, but it's common sense. WP:BOTDICT#cosmetic edit (see the bit about "edit warring on presentation"), WP:BOTDICT#editor-hostile wikitext, and the general concept of threshold of usefulness will have good general advice. Headbomb {t · c · p · b} 21:29, 1 November 2024 (UTC)

COSMETICBOT is a policy for bots, which includes tools that assist manual editing, and it identifies itself as a general guideline for other "bot-like" purely manual editing. So it might apply with different strength depending on how many such edits someone is doing, how they are doing them, and if/how-much disruption it's creating for other editors working on certain pages. DMacks (talk) 13:30, 27 October 2024 (UTC)

Is there any legal reason we can't have Fair Use images in sandbox articles under active dev?

I'm collaborating with another user on a sandbox draft, and I want to show my thoughts of what an article might look like. I was tempted to upload a fair use image to help facilitate the discussion, but of course, that's verboten here. A question just occurred to me; now I need to find the answer.

Is there any legal reason we can't use fair use images in collaborative drafts before the article goes in Article Space? Or is this some sort of self-imposed superstitious villager taboo we do to ourselves, unnecesarily, as a sacrifice to imagined gods of US copyright law in the hopes our rite will appease them? Is the project actually at ANY legal exposure if we allow fair use in collaborative drafts under active development? Feoffer (talk) 05:18, 27 October 2024 (UTC)

There's no legal reason we can't use fair use (outside of fair use allowances), the stipulation stems from the WMF's resolution on non-free content, which stresses the need to keep non-free use minimal. On that end, en.wiki has adapted the standard that the only allowable space for non-free content is within mainspace article content, as we have seen non-free used on user-page drafts without ever being converted to mainspace, which violates the need for minimal use.
If you are trying to prepare a draft that will use non-free, and want to make sure that the article looks decent with the images in place, its recommended this to be a last step just prior to moving from a draft to mainspace,so that the necessary non-free can be uploaded and queued for inclusion. Or you can use placeholder free images while the draft is in development. — Masem (t) 06:22, 27 October 2024 (UTC)

If the image is available elsewhere online then you can link to that on the talk page so that other editors know what image is being discussed and offer critique, etc. on it. If it doesn't exist elsewhere (e.g. it's something you've scanned) then it is far from impossible that your uploading it to a third party image host for the purposes of said discussion will be compatible with fair use (but do check the image host's terms of use). Thryduulf (talk) 11:53, 27 October 2024 (UTC)

We have File:Placeholder.svg (and also in other formats) that's often used in mock-ups and examples, such as Template:Infobox school athletics/doc#Example (as an example of an example:). DMacks (talk) 13:16, 27 October 2024 (UTC)

Digital storage time by law

Is there a legal time frame that WMF is forced to store IP addresses of users? It seems the WMF has given them out before and has said to an Indian court that they are going to again. If there is no legal reason then they should be purged after a certain time frame. This would make it difficult for checkusers and sockpuppet admin. We could easily store them in an area that only those groups would have access to. Then the WMF could say that the court would have to subpoena someone from those groups. Thoughts?Music Air BB (talk) 17:08, 27 October 2024 (UTC)

Foundation:Privacy policy#How Long Do We Keep Your Data? states Once we receive Personal Information from you, we keep it for the shortest possible time that is consistent with the maintenance, understanding, and improvement of the Wikimedia Sites, and our obligations under applicable law. In most instances, Personal Information is deleted, aggregated or de-identified after 90 days. and further links to Foundation:Legal:Data retention guidelines, which states that IP addresses will be kept for "at most 90 days" and then "deleted, aggregated or deintentified".

The Sharing section of the privacy policy details when, why and with whom your data may be shared by the Foundation. The "For legal reasons" subsection begins We will access, use, preserve, and/or disclose your Personal Information if we reasonably believe it necessary to satisfy a valid and legally enforceable warrant, subpoena, court order, law or regulation, or other judicial or administrative order. However, if we believe that a particular request for disclosure of a user's information is legally invalid or an abuse of the legal system and the affected user does not intend to oppose the disclosure themselves, we will try our best to fight it. Thryduulf (talk) 17:20, 27 October 2024 (UTC)

We should knock that 90 days down to 7 days but leave in a limited access area for 90. Only sockpuppet and checkusers would have access to it. What about email addresses? I thought no human had access to those? Music Air BB (talk) 17:31, 27 October 2024 (UTC)

The IP information (for accounts) is already limited access - only checkusers (with good reason), stewards (sometimes), some techies and some staff can access it. It gets automatically removed from the database after 90 days. That seems a reasonable timescale to me - it's mostly used to reduce abuse of the site, which can be chronic. As for email, if it's in a database and can be displayed to a human, then a human can access it. The people operating a database (in this case the WMF) can access pretty much anything that's in there, with enough effort. They surely have policies and checks in place to prevent willy-nilly access, but it can't really be stopped on a technical level. -- zzuuzz ^(talk) 18:39, 27 October 2024 (UTC)

The WMF's privacy policy is not something that the en.wp community has any control over. If you want to suggest changes to them you need to do so elsewhere. I don't know where that place is, but the people who watch meta:Wikimedia Forum are likely to. Thryduulf (talk) 18:42, 27 October 2024 (UTC)

There is a shedload of fora I could have posted to including Wikipedia:Village pump (WMF) where there seems to be some drama about the WMF take down of an article and doxing because of a court order in India. The article contents are still in a sub-section of a parent article so I don't know why the grand uproar. Just expand that section like a WP:COAT. I doubt many people have Wictionary:Village Pump (WMF) on a watchlist nor the main WMF ones. This page probably has the best input. Music Air BB (talk) 19:45, 27 October 2024 (UTC)

Perhaps somewhat ironically, the OP is the sock of a user who has already been subject to multiple blocks. The 90 day limited access was enough to confirm this without any doubt. Girth Summit _(blether) 16:48, 29 October 2024 (UTC)

I have trouble locating AfD deletion discussion

How do I find the discussion concerning deletion of Effie Awards? I attempted to search the tool in Articles for Deletion section, but it doesn't yield the relevant result.

Most relevant discussion I found is here. Marcos [Tupungato] (talk) 16:48, 28 October 2024 (UTC)

Effie Award was speedy-deleted under WP:CSD#A7 in September 2018 for not credibly asserting significance. --SarekOfVulcan (talk) 16:53, 28 October 2024 (UTC)

Yep, note that it was Effie Award that was the article - Effie Awards was a redirect to it, and was deleted under CSD#G8. The article was only sourced to the Effie website, which at the time didn't work either. Black Kite (talk) 16:59, 28 October 2024 (UTC)

Paying someone else to write your edits

I have encountered many kinds of COI editors, autobiographers and paid editors (disclosed and undisclosed) in my time but I've just stumbled upon something that I've never seen before; a page where the text strongly suggested the user had paid someone else to write text for them that they were then posting on Wikipedia. The telling part was that when copying the text they had left in part of the correspondence they'd been having, not unlike when users forget to remove the "Sure, here is a draft Wikipedia page" text from a chatbot.

The page has already been tagged for speedy deletion by @FifthFive because it was in any event autobiographical, promotional and NOTAWEBHOST, but out of mere academic curiosity: is there any area of policy that deals with this kind of thing? AntiDionysius (talk) 21:20, 29 October 2024 (UTC)

Copyright is the first thing that comes to mind. AIUI, unless it is a work for hire or you explicitly assign the copyright to me (or release it under a Wikipedia-compatible free license), you own the copyright and my posting it here would be a violation of your copyright. Other than that I don't think there is any need for policy here - if I wrote it and it would be deleted (NOTWEBHOST, spam, etc) then delete it for that reason, if it isn't a copyright violation and it wouldn't be deleted if it was self written then I don't see any benefit to deleting it. Thryduulf (talk) 22:06, 29 October 2024 (UTC)

Re copyright, really depends on jurisdiction, the communications between the parties and (as mentioned) an absence of any express licence, but if it was clear between the parties the text was going to be used for Wikipedia, it wouldn't be unreasonable to argue that an implied licence exists compliant with Wikipedia's requirements. Regards, Goldsztajn (talk) 23:45, 29 October 2024 (UTC)

In this particular case, it seemed like it was very clear that the writer was aware their work was for Wikipedia (not that this stopped them from writing promotionally, but anyway) but yeah I can see how those contextual questions would be important. AntiDionysius (talk) 00:26, 30 October 2024 (UTC)

For sure, yeah - it strikes me as likely to end up being promotional most of the time (why else would you pay someone if not to promote something?) but I'm not suggesting we need a policy to ban the practice as such. AntiDionysius (talk) 00:27, 30 October 2024 (UTC)

If it's promotional enough that deletion is better than rewriting, then it should be deleted for being promotional regardless of who wrote it. If it's not that promotional then it shouldn't be deleted, regardless of who wrote it. Thryduulf (talk) 01:35, 30 October 2024 (UTC)

Yes, sorry, that was what I was trying to express. AntiDionysius (talk) 10:28, 30 October 2024 (UTC)

In my limited dealings with COI's, a thought occurred to me that, in working with them, I risk subjecting myself to suspicion of being a COI editor myself (Wikilawyering intensifies). Cheers. DN (talk) 00:07, 30 October 2024 (UTC)

Date redirects to portals?

16 August 2006 points to the current events portal as a result of this discussion. However, date redirects will continue to come up at RfD, some some wider community discussion and input is helpful on whether or not the current events portal is an appropriate target for mainspace redirects. See also: this ongoing discussion for some context.

Related questions to consider: are portals "part of the encyclopedia"? Thanks, Cremastra (u — c) 00:55, 30 October 2024 (UTC)

• The second question is easy: Yes, portals are part of the encyclopaedia. As to the first question, portals are reader-facing content and so I see no reason why they wouldn't be appropriate targets for mainspace redirects, given that uncontroversially target mainspace redirects to reader-facing templates and categories when they are the best target. Whether the port is the best target for a given date will depend on the specific date but in general the portal should always be an option to consider. Thryduulf (talk) 01:32, 30 October 2024 (UTC)

  I agree with this. The portal is definitely not always the best option and it has its limitations, but, as I wrote at WP:RDATE it should be considered and assessed along with mainspace articles. Cremastra (u — c) 01:44, 30 October 2024 (UTC)

Pinging: Utopes, who I've discussed this with.

Notified: WT:RFD, WT:PORT, WT:CURRENTEVENTS, WT:WPRED. Cremastra (u — c) 01:43, 30 October 2024 (UTC)

If a namespace doesn't have the same standards as mainspace, then the reader shouldn't be redirected there while possibly not realizing they are now outside of mainspace. Yes, there is more content at Portal:Current events/August 2006 than at 2006#August, but the reader is now facing a decades-old page with no quality control, where links to Breitbart are misleadingly labeled as (AP). Chaotic Enby (talk · contribs) 00:50, 6 November 2024 (UTC)

Portal does have the same standards as mainspace. That a portal is not up to those standards is no different to an article being in bad shape - fix it. Thryduulf (talk) 00:54, 6 November 2024 (UTC)

• There's a lot of random junk in portalspace, but yes, it is part of the encyclopedia. Just like categories and templates, portals are reader-facing content. C F A 💬

Issues with antiquated guideline for WP:NBAND that essentially cause run of the mill non-notable items to be kept

Specifically, WP:NBAND #5 and #6, which read:

5.) Has released two or more albums on a major record label or on one of the more important indie labels (i.e., an independent label with a history of more than a few years, and with a roster of performers, many of whom are independently notable).

6.) Is an ensemble that contains two or more independently notable musicians, or is a musician who has been a reasonably prominent member of two or more independently notable ensembles. This should be adapted appropriately for musical genre; for example, having performed two lead roles at major opera houses. Note that this criterion needs to be interpreted with caution, as there have been instances where this criterion was cited in a circular manner to create a self-fulfilling notability loop (e.g., musicians who were "notable" only for having been in two bands, of which one or both were "notable" only because those musicians had been in them.)

These appear to have been put together by a very small number of editors over a decade ago and hasn't seen much change since then and I feel it's much more lenient than just about anything else. This SNG defines a "label" that has been around for over "a few years" that has a roster of performers as "important". So, any group of people who have released two albums through ANY verifiable label that has exited for more than a few year can end up being kept and this isn't exactly in line with GNG. I believe a discussion needs to be held in order to bring it to GNG expectations of now.

Graywalls (talk) 06:17, 30 October 2024 (UTC)

Especially given how broadly the various criteria have been "interpreted" in deletion discussions, the best way to go about it is just to deprecate the whole thing. Rely on the GNG for band notability, and if that results in a heap of articles on ephemeral outfits, garage bands and local acts vanishing, huzzah. Ravenswing 09:07, 30 October 2024 (UTC)

The SNG isn't workable in the age of digital distribution. It's very easy to create "an independent label with a history of more than a few years". If someone wants to suggest a way to reform the SNG, I am open to solutions. But deprecation is a simple alternative if we can't. The GNG is always a good standard because it guarantees we have quality sources to write an article. Shooterwalker (talk) 14:22, 30 October 2024 (UTC)

I was active in AfD discussions when NBAND was pretty new, and it was useful for dealing with a flood of articles about garage bands and such, but I think our standards in general have tightened up since then, and I agree it is time to review it. There is the possibility, however, that revising NBAND may require as much discussion as revising NSPORT did. Donald Albury 17:49, 30 October 2024 (UTC)

This sounds reasonable. I guess we need some concrete re-write suggestions to base an rfc on. Gråbergs Gråa Sång (talk) 18:17, 30 October 2024 (UTC)

It sounds like you're assuming that NBAND is meant to be a substitute for the Wikipedia:General notability guideline. That's true for some WP:Subject-specific notability guidelines but not for all of them.

I guess the underlying question is: Is there actual harm in having a permastub about a band that proves to be borderline in GNG terms? Consider this:

"Alice and Bob are a musical duo in the science fiction genre. They released their first album, Foo, in 2019 and their second, Bar, in 2020. Both albums were released by Record Label. They are primarily known for singing during a minor event."

I'm asking this because I think that the nature of sources has changed, particularly for pop culture, since NBAND and the GNG were written. We now have subjects that get "attention from the world at large", but which aren't the Right™ kind of sources and, while these Wrong™ sources definitely provide "attention", some of that attention might not provide biographical information (which means we're looking at a short article).

For example, instead of getting attention in the arts section of a daily newspaper, they're getting attention from Anthony Fantano on YouTube. He's an important music critic,[6] but I suspect that our knee-jerk reaction is "Pffft, just some YouTuber, totally unreliable". Consequently, we might rate a band that we theoretically intend to include ("attention from the world at large") as not meeting the GNG (because the whole field relies on the Wrong™ style of sources). WhatamIdoing (talk) 19:02, 30 October 2024 (UTC)

Keep in mind that like most other notability guidelines, it is a presumed assumption that a topic is notable if it meets these criteria. If you do an exhaustive Before and demonstrate there is no significant coverage beyond the sourcing to satisfy there criteria, the article should still be deleted. None of the SNGs are geared towards preventing this type of challenge. — Masem (t) 19:30, 30 October 2024 (UTC)

If we had to yield to presumptive notability about some random band because it released two albums with Backyard Trampoline Recordings established few years ago and had to do exhaustive search to disprove notability, we're getting setup for a situation where removal is 10x more challenging than article creation. So.. I see a great value in scrapping NBAND 5, and 6. Graywalls (talk) 00:47, 31 October 2024 (UTC)

Welcome to WP:SNGs. As Masem said, they're supposed to be a rough idea of gauging notability before exhaustively searching for sources. But pretty much all of them have ended up being used as means to keep articles about trivial or run-of-the-mill subjects. Thebiguglyalien (talk) 19:37, 30 October 2024 (UTC)

Graywalls listed two criteria but the main discussion seems to be about the 1st (#5). I agree with Graywalls on that. With the evolution of the industry, the label criteria is no longer a useful indicator as it once was and IMO #5 should be removed or modified. Sincerely, North8000 (talk) 19:13, 30 October 2024 (UTC)

I agree, both those criteria should be scrapped. JoelleJay (talk) 22:21, 30 October 2024 (UTC)

I've noticed that as well. I think #6 has some value still, while #5 is like saying an author who has published two or more books by a major publishing house is presumed notable. Way too low a bar without requiring some level of reception of those albums/books. (WP:NAUTHOR doesn't have that 2-book criteria, of course, just seems like parallel benchmarks.) Schazjmd (talk) 13:25, 31 October 2024 (UTC)

On the other hand, in this case, I suspect that an artist that "has released two or more albums on a major record label or on one of the more important indie labels" will in 99% of cases have enough coverage to clear the GNG bar. I'd like to see an example of one that doesn't. Black Kite (talk) 13:29, 31 October 2024 (UTC)

The definition of important as said in #5 is "history of more than a few years, and with a roster of performers, many of whom are independently notable". This would mean that a garage band is notable, because they've released two CD-R albums on Rotten Peach Recordings which has been around for 3 1/2 years, has a roster of performers and some of whom have a Wikipedia page on them. Often time "notable" is determined by the presence of a stand alone Wikipedia page. When you look at the page, many band member pages are hopelessly non-notable, but removal takes an AfD. So a simple deletion can become a time consuming multi-step AfD. Graywalls (talk) 19:18, 31 October 2024 (UTC)

Here's a current AfD I am participating in where NBAND#5 was invoked to justify a keep. Wikipedia:Articles_for_deletion/Sons_of_Azrael_(3rd_nomination) Graywalls (talk) 19:24, 31 October 2024 (UTC)

Not opining on that band's notability, but Metal Blade is a famous independent label that has existed for 42 years, has released material by very high-profile bands, and is distributed by Sony - it's not some one-person imprint operating out of their garage. Black Kite (talk) 11:28, 1 November 2024 (UTC)

• One suggestion I would add is to make these two criteria apply only to bands before a specific year, that year being where physical releases still dominated over digital sales. I don't know the exact year but I am thinking it's like around 2000 to 2010. There may still be older groups during the time of physical releases that don't yet have articles that would fall into one of these criteria. Masem (t) 20:02, 31 October 2024 (UTC)
• As someone who's had WP:DSMUSIC watchlisted for most of their editing history, and who tends towards deletion at that, I actually don't see much of a problem with these criterions. It certainly seems true that the majority of musicians who are signed to a label or a member of multiple bands with two other musicians who meet WP:GNG themselves meet GNG. I do think it is sometimes justified to accept less-than-GNG sourcing in articles where a SNG is met (see Wikipedia:Articles for deletion/John LeCompt for this as it applies to c6 specifically) and more importantly, NMUSIC contains language that allows deleting articles even where it is technically met (see Wikipedia:Articles for deletion/Rouzbeh Rafie for an extended argument about that. Mach61 23:29, 31 October 2024 (UTC)
• I've understood these criterion to be supplementing GNG, that is, that if a band or individual artist meets one or more of these criterion, they *likely* are notable. However, in the past when I was a younger and less experienced editor, I think I did understand these as being additions or alternatives to GNG. So I think that should be clarified. This has come up on the deletion discussion for Jayson Sherlock. He is a member or former member of several very notable bands, and for that reason I presumed that he would easily have independent coverage about him specifically. However, to my surprise, there's only one interview of him in a reliable source that would provide notability (there's some interviews on personal blogs or minor sites that wouldn't be RS except for him making statements about himself). But at least one editor has used the above criterion to argue that the article should be kept.--3family6 (Talk to me | See what I have done) 12:20, 1 November 2024 (UTC)

  Just as an aside, interviews do not contribute to GNG unless they include secondary independent SIGCOV (such as a substantial background introduction by the interviewer). JoelleJay (talk) 15:39, 1 November 2024 (UTC)

• Agreed. That's important to note. I was presuming such, and also why I wouldn't rely on a singular interview as the sole source for establish GNG.--3family6 (Talk to me | See what I have done) 16:30, 1 November 2024 (UTC)

That's how I see most SNGs (and the outliers ought to follow their lead). At the very least, we can clarify that NBAND is meant as an indicator for the GNG, and not a substitute. Shooterwalker (talk) 02:04, 2 November 2024 (UTC)

• As someone who thought the old NSPORTS was wildly overinclusive and needed cleanup... these NBAND guidelines don't seem that bad? If two plainly notable musicians were discovered to have done some obscure team-up in the 1970s, that does indeed seem to be a notable topic and useful to have linked somewhere, even if there isn't tons of info on this collaboration. It's worth mentioning because minor subtopics are often merged to the overarching topic (e.g. songs to the album), but there may not be a clear merge location for this if both parties were equal contributors, and a short separate article is an acceptable compromise. Similarly, the complaint about #5 seems to be about just how "indie" the hypothetical label is, but this seems like a solvable problem. If a band fails GNG, that implies that either their two albums really were from a very obscure indie outfit and thus also fail NBAND, or else that we have some sort of non-English sources issue where we may consider keeping on WP:CSB grounds (i.e. that sources probably do exist to pass GNG, but they're difficult to find, and we can trust they exist because this was a major and notable label releasing the band's work). About the only suggestion I can offer is that the comment in 6 about avoiding circular notability could probably be phrased in the sense of GNG, i.e. that the two notable musicians need to both meet GNG and then this will create a new, safe NBAND notability for their collaboration. SnowFire (talk) 17:36, 4 November 2024 (UTC)

RfC: Shorten the recall petition period?

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.

To anyone unfamiliar with this, admin recall is a new process that is exactly what it sounds like. Currently, there is a 30 day petition period: if 25 people sign it, the admin then needs to pass a new RfA within 30 days to keep the tools. Should we change the petition period?

• Option A: Keep the petition period the same (30 days)
• Option B: Change the petition period to 7 days
• Option C: Some other time period (like 14 or 15 days?) that's longer than a week but shorter than a month.

Clovermoss🍀 (talk) 19:20, 1 November 2024 (UTC)

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

Another RfC regarding the admin recall process

Cut the petitions to being just signatures, or not? It is here: Wikipedia talk:Administrator recall#RfC: Should we add text prescribing just signatures, no discussion? Herostratus (talk) 05:50, 3 November 2024 (UTC)

And Wikipedia:Administrator recall/Fastily this morning. BusterD (talk) 14:36, 4 November 2024 (UTC)

WP:PAID if owner of company

Drm310 and I have a polite disagreement on the interpretation of WP:PAID, and I may very well be mistaken. What is very clear is if an editor is an employee of a company, they are a paid editor. What's not clear is what happens if the editor is the owner of a company. Sure, there's a conflict of interest, but are they a paid editor? I'll quote Drm310, as he says it better than me. "They said that they were a company owner and not an employee. You said that makes them a paid editor. I always interpreted the policy as: if a person is receiving (or expecting) compensation as part of their job, then they're a paid editor. But if they have an ownership stake in the company/organization, then they fall outside the definition of employee. Are we now interpreting it so that owners are paid editors too, because they are drawing an income from their business?" My position is that an owner of a company counts as a paid editor by virtue of the ownership (they don't even need to be drawing an income). Is that position correct, or is it a step too far wrt WP:PAID? --Yamla (talk) 15:25, 4 November 2024 (UTC)

I would read it as you do, @Yamla:; they have a vested interest in the company being successful, which, in my book, ultimately means getting "something" out of it (which in most cases will mean an income of sorts). Reading it differently smacks slightly of (wiki-)lawyering. Lectonar (talk) 15:35, 4 November 2024 (UTC)

Hmm. Well, Lectonar, it has always seemed to me that the line "you stand to gain from your editing, so it's effectively paid, even if you aren't actually paid for the editing" is wikilawyering, so evidently that's a matter of point of view.

I have always taken it that paid editing does not include editing about one's own business, in line with what Drm310 says, but my experience is that many, perhaps most, administrators take it the way that Yamla and Lectonar do. In a way it doesn't make much difference, as in either case the conflict of interest issue applies, but there are ways in which it may make a difference. In my opinion the most important way it may make a difference is the purely practical consideration that most owners of businesses writing about their own businesses don't recognise "paid editing" as a description of what they are doing, so it is, in my opinion, more helpful to use other wording which they will be more likely to understand than insisting "yes it is paid editing". (There's already enough of a problem with: "No, I'm not paid to edit Wikipedia, it's just part of my job" ... "Yes, but if it's part of a job that you are paid for then it's paid work" ... "Yes, but..." without adding another layer of room for misunderstanding.) I therefore think it's more helpful to treat the expression "paid editing" as not applying to editing about one's own business.

Theoretically it isn't up to us to decide what the expression means, because it's part of the Wikimedia Foundation's terms of use, over which we have no jurisdiction. However, those terms of use refer to "each and any employer, client, intended beneficiary and affiliation" and as far as I can see there is no definition or clarification of the word "affiliation", so that doesn't really help. JBW (talk) 16:10, 4 November 2024 (UTC)

I think an owner is "intended beneficiary", ownership being a beneficial interest in what is owned, even if one can't parse "affiliation". Alanscottwalker (talk) 16:17, 4 November 2024 (UTC)

I'm of the opinion that PAID applies to owners, but the wording of WP:PAID is ambiguous enough that a reasonable person might very well disagree with that opinion, and I think that should be clarified on that page. An owner of a company can still be an employee of that company (e.g. if the company is set up as a C corporation they can be considered an employee for tax and insurance purposes). I don't think the applicability of the paid-contribution disclosure should change depending on how you structure your company if the role in the company is similarly situated. If you are compensated by working at a company as an owner or otherwise, that needs to be disclosed. Even situations where an owner does not receive direct financial payments or dividends from their ownership of the company (like with a smaller startup company) they would still need to disclose that under WP:PAID, as money is not the only form of compensation. Even in a sole proprietorship they are directly paid for their work at the company, the same as if they were an employee. Owning the company should not be a loophole precluding the need for disclosure. - Aoidh (talk) 16:48, 4 November 2024 (UTC)

@Aoidh: Has anyone suggested that it should preclude the need for disclosure? If they have, I haven't seen where tgey have done so. I assumed it was obvious that there is a need for disclosure of one's position because it is a conflict of interest. JBW (talk) 22:30, 4 November 2024 (UTC)

@JBW: I'm sure I've seen it come up but I can't recall where. Someone with a COI reading Wikipedia:Conflict of interest might reasonably assume that if they are not considered a paid editor, then they are not required to disclose anything. The difference between the PAID verbiage (required...requirement..you must disclose...you must not use administrative tools for any paid-editing activity) contrasts with the less strict wording of non-PAID COI (expected to disclose...should disclose...COI editing is strongly discouraged). The section Wikipedia:Plain and simple conflict of interest guide#Disclosure also makes this distinction. I'm not saying I don't think COIs should be disclosed, but someone with a COI who is going to split hairs about whether an owner of a company make one a paid editor would be likely to split hairs there as well. - Aoidh (talk) 23:51, 4 November 2024 (UTC)

• While an owner is technically not an employee, it would be absurd to suggest that PAID applies to employees but not owners. ~~ Jessintime (talk) 16:22, 4 November 2024 (UTC)

Jessintime I do not intend to tell you that your opinion on this as "absurd"; I prefer to just say that I respectfully disagree. You may like to consider which of those two approaches is more constructive. JBW (talk) 16:28, 4 November 2024 (UTC)

I did not mean to be disrespectful, but my use of the word "absurd" here was in reference to the doctrine of absurdity. ~~ Jessintime (talk) 16:34, 4 November 2024 (UTC)

Jessintime OK, thanks for clarifying that. However, having looked at the article that you have linked, I am wondering what the absurd result you think would ensue. What is it that an owner of a company would be allowed to do which an employee wouldn't? Certainly not editing without disclosure of conflict of interest. JBW (talk) 22:36, 4 November 2024 (UTC)

I think Buster's response below (Starlink's unpaid interns would count as paid editors, but not Elon) illustrates the problem. ~~ Jessintime (talk) 17:18, 5 November 2024 (UTC)

From the policy page: Interns are considered employees for this purpose. So unpaid interns count as paid editors when editing the Starlink Wikipedia article for their employer. But edits by Elon Musk would not count as paid editing. That sounds like an absurd result to me. Do I misunderstand the policy? BusterD (talk) 19:42, 4 November 2024 (UTC)

• Someone who has a few shares in a large company is one of its "owners" in law, but likely doesn't have a big enough financial stake in it to amount to a COI in Wikipedia terms. Someone who has most of the shares in a small company, on the other hand, has a COI.—S Marshall T/C 22:10, 4 November 2024 (UTC)

  If I may extend your example, if I were in the business of stocks or futures, I might actually have a stake (direct or otherwise) sufficient to put me in direct conflict, no matter which company is the subject. BusterD (talk) 23:00, 4 November 2024 (UTC)

• I have just seen a message on Yamla's talk page, where I think he makes a point that I have tried to make, but he has expressed it perhaps more clearly than I have. He said: "In the end, whichever way the consensus goes, I think the combination of WP:PAID and WP:COI means the end result (though not the communication) ends up the same." Many of the comments above appear to be based on the assumption that not interpreting "paid editing" as including owner-editing would mean letting owners edit without disclosure, but it wouldn't. JBW (talk) 22:50, 4 November 2024 (UTC)

  Thanks for copying my comment here, JBW. In my initial post, I meant "Sure, there's a conflict of interest" to cover this point, but failed to be clear. I do think the communication around paid editing is important, even if the end result (user has to declare a conflict) is the same. This is frequently a challenging concept to communicate to new editors. --Yamla (talk) 22:56, 4 November 2024 (UTC)

• I think there may be a more fundamental misunderstanding of WP:PAID here than you think. Paid editing is about people being paid to edit. Let's take What is very clear is if an editor is an employee of a company, they are a paid editor to the point of absurdity: a burger flipper at a 40,000-location chain fast-food restaurant who edits the article about the chain is in no way being paid to make that edit. Their job is to flip burgers, not to do corporate PR. They do have a COI (positive or negative) due to the employment relationship, but unless the CEO or PR department or whoever is telling employees that editing Wikipedia is now part of their job it's not WP:PAID.
  But like many other things around here, since WP:PAID has stricter requirements and penalties than WP:COI, people tend to try to stretch the definitions as far as they possibly can to use the stricter requirements and penalties to combat editing they don't like. I won't be surprised if people in that space take objection to my paragraph above on the basis that restricting WP:PAID to the clear definitions would hamper their efforts to combat the spammer scourge.
  As for the business owner, if the business is making paid edits on behalf of clients then the company as a whole, including the owner, is being WP:PAID to edit on behalf of the company's clients. And the required disclosure includes those clients, not just their general ownership of the paid-editing company. On the other hand, if the business is making widgets then I'd say the owner's editing is a very major COI but it's not specifically WP:PAID. Anomie⚔ 00:21, 5 November 2024 (UTC)

I disagree with that interpretation of WP:PAID. The policy says: "Users who are compensated for any publicity efforts related to the subject of their Wikipedia contributions are deemed to be paid editors, regardless of whether they were compensated specifically to edit Wikipedia." I think it's completely reasonable to hold the belief that "publicity" is almost always part of the job of a company owner and other senior officers e.g., C-suite occupants, governing board members. ElKevbo (talk) 02:43, 5 November 2024 (UTC)

Yes, and even more than that, the owner, officers and board members are fiduciaries of the company, and "compensated" and "incentivized" by ownership and/or other compensation (money, goods or services -- possession of the company is a good) to work in the company's best interest, whether in editing Wikipedia, or elsewhere. -- Alanscottwalker (talk) 12:52, 5 November 2024 (UTC)

Certainly the sole or majority owner of the company has an actual or risk of COI (depending on which definition of COI you use), But "Paid" implies more that that.....that somebody is paying them and telling them what to do. North8000 (talk) 02:53, 5 November 2024 (UTC)

IMO WP:PAID should be split into its main two interpretations: "instructed (even if implicit, e.g. hired for publicity in general) to edit Wikipedia for compensation" and "direct financial interest in a subject". JoelleJay (talk) 17:39, 5 November 2024 (UTC)

The issue here is WP:COI, not WP:PAID. When you're PAID to edit, the owner (or someone acting on behalf on the owner) tells you 'your job is to do this for me'. If you don't, you lose your job/don't get paid, so that's where your incentive comes from. WP:PAID exists, among other reasons, because there are firms trying to sell these services to companies/owners, and companies/owners paying people to edit on their behalf so they can go 'we hired professionals, if they're an issue blame them!'. It's a special type of COI-editting that's common enough to have a special policy for that special type of COI editing.

When the owner themselves are doing the editing, all the special concerns of PAID disappears, save for the remaining one: COI-editting. But that's covered by WP:COI. There is nothing special about the owner of Mary Sue, owner of Certified Reiki Thetan-Level 3 Shop editing an article on her business, than Rocker Boy Joe writing about his band Rocket Bobs, or Jensen Huang vandalizing AMD articles through an account named User:AMDTROLL4V3R. They don't lose their jobs, they still have their income, and they don't get in trouble if they fail to deliver. Headbomb {t · c · p · b} 17:50, 5 November 2024 (UTC)

If your job includes promoting a business and you come to Wikipedia to promote that business, that is PAID editing, owner or otherwise. That someone would be fired for refusing is not the criteria, an owner is highly incentivized to promote their business and can expect to be compensated for that effort through business growth and profit, and it is the compensation element that makes an editor a paid editor. - Aoidh (talk) 17:58, 5 November 2024 (UTC)

Which is just a regular WP:COI. There is no compensation exchanged, nor any power dynamic at play when/if they "fail to deliver". Headbomb {t · c · p · b} 18:11, 5 November 2024 (UTC)

There is no part of WP:PAID that suggests that a power dynamic or consequence for a failure to deliver is a determining factor, and owners are indeed compensated for their work. This is especially true when taking into account that compensation is not limited to remuneration. - Aoidh (talk) 19:27, 5 November 2024 (UTC)