As has been noted in the WP:AN#Nihonjoe and COI thread, it's not clear what the process is to remove a bureaucrat. In practice, it seems to be accepted that arbcom has the authority to decrat somebody, just like they have the authority to desysop somebody. By way of examples:

• In Special:Permalink/296240244#Nichalp (2009), arbcom voted to remove Nichalp's crat tools by motion (it's not clear to me if there was ever a formal case page for this).
• In Wikipedia:Arbitration/Requests/Case/Andrevan (2018), arbcom overwhelmingly voted to accept a case to remove crat tools. The decision itself was rendered moot by a resignation under a cloud.
• In the current case request, there's no outcome yet, but the 7/0/1 vote so far to accept the case makes it clear that arbcom considers removal of crat tools within their purview.

The problem is that the current WP:ARBPOL#Scope and responsibilities only talks about "requests ... for removal of administrative tools". I think it's uncontroversial that the intent was that this would include crat tools, and that's certainly been actual practice as demonstrated by the above three cases, but we should make it official. So, in accordance with WP:ARBPOL#Ratification and amendment ("Proposed amendments may be submitted for ratification ... having been requested by a petition signed by at least one hundred editors in good standing"). I hereby propose that WP:ARBPOL#Scope and responsibilities, item 3, be amended to read:

To handle requests (other than self-requests) for removal of administrator or bureaucrat tools;[note 2]

Note: this shouldn't have any bearing on the current case, but it should be clarified for the future. I'll publicize this on WT:AC; please feel free to list it elsewhere if there's other places it should be.

RoySmith (talk) 17:35, 2 March 2024 (UTC)[reply]

Signatories[edit]

1. As proposer RoySmith (talk) 17:35, 2 March 2024 (UTC)[reply]
2. Agreed, but perhaps "rights" is better than "tools". Usedtobecool ☎️ 17:49, 2 March 2024 (UTC)[reply]
3. Hopefully this is to all intents and purposes a codification, but it's good to have a belt and braces approach. There have been a couple of recent examples of the committee using—or almost using—this authority, noted by Roy, so whether they should have abrogated this right to themselves is moot: the community has clearly accepted that they already do. ——Serial 17:52, 2 March 2024 (UTC)[reply]
4. * Pppery * _{it has begun...} 18:19, 2 March 2024 (UTC)[reply]
5. I suppose it's a yes, but is this needed? Has anyone seriously questioned ARBCOM's right to so this? Phil Bridger (talk) 18:26, 2 March 2024 (UTC)[reply]
6. I'd prefer it just to say that Arbcom has jurisdiction to remove any advanced permission granted by the community, but failing that, this is also okay.—S Marshall T/C 19:52, 2 March 2024 (UTC)[reply]
7. I have no strong feelings over the current contreversey, and agree that ArbCom can already do this, but I still see this as worth supporting. Mach61 02:56, 3 March 2024 (UTC)[reply]
8. I don't agree that bureaucrat tools are administrative tools; there is no requirement to be an admin to become a bureaucrat, for instance, and I think one of the bureaucrats removed their own administrator rights for a while. So I wouldn't assume that bureaucrat functions are subsumed under administrator ones. Jo-Jo Eumerus (talk) 07:53, 3 March 2024 (UTC)[reply]
9. starship.paint (RUN) 14:17, 3 March 2024 (UTC)[reply]
10. I agree generally with the moot camp and Risker in the comments: "administrative" in ordinary English is no synonym for "administrator" -- so ARBPOL already covers this; WP:CRAT#Removal of permissions also covers it; and the committee's power to "bind" any user, covers it thrice over, but as a sitting Arb seems rather confused, touching off this petition, I'll go along, as a show of you really should not be confused about it, already (although yes, it should be permissions (all advanced permissions), if implemented by the committee). Alanscottwalker (talk) 14:27, 3 March 2024 (UTC)[reply]
11. One more for "all advanced permissions" per Alanscottwalker et al.--GRuban (talk) 17:34, 3 March 2024 (UTC)[reply]
12. There shouldn't be uncertainty at present, but it is best to rule out any remaining uncertainty. Robert McClenon (talk) 05:12, 4 March 2024 (UTC)[reply]
13. I agree with the spirit but would recommend a slight change to the verbiage. Perhaps we could replace administrative tools with en-wiki advanced permissions. This would also cover CU/OS permissions, even though Stewards actually activate/deactivate those bits. — Jkudlick ⚓ (talk) 18:33, 5 March 2024 (UTC)[reply]
14. Support rewording to en-wiki advanced permissions per Jkudlick. Pinguinn 🐧 10:09, 6 March 2024 (UTC)[reply]
15. Whilst I think the committee already has this power, there is no disbenefit in codifying it. Stifle (talk) 09:04, 8 March 2024 (UTC)[reply]

    The way this proposal is worded, there is disbenefit as explained below. Thryduulf (talk) 10:43, 8 March 2024 (UTC)[reply]

16. I will support as crat rights can only be removed by stewards on request from the Committee (in addition to self or emergency cases). Toadette ^{(Let's discuss together!)} 22:07, 17 March 2024 (UTC)[reply]
17. Support, but maybe just change it to “any (local) user right” or “any (local) editing privileges” to fully remove any ambiguity. Geardona (talk to me?) 17:58, 20 March 2024 (UTC)[reply]
18. Obviously. Support codifying for clarity to the casual reader. -Fastily 20:01, 24 March 2024 (UTC)[reply]
19. I think they already have this right. Clarifying it is always a good idea. SportingFlyer T·C 18:02, 2 April 2024 (UTC)[reply]

    If this proposal just clarified matters so de facto became de jure then there would be no reason to oppose (but also limited reason to support). However that is not what it does, as explained in both sections below. Thryduulf (talk) 18:15, 2 April 2024 (UTC)[reply]

20. Yes, of course! I also support other wordings proposed, including "all advanced permissions" and equivalents. Toadspike (talk) 10:03, 3 April 2024 (UTC)[reply]
21. Yes. They should have the rights to remove absolutely any permissions, including bureaucrat. Animal lover |666| 10:29, 10 April 2024 (UTC)[reply]

    They already do, but this proposal would remove some of those rights. Thryduulf (talk) 11:12, 10 April 2024 (UTC)[reply]

Moot point[edit]

1. Creating a new section as I don't support or oppose this because, as far as I'm concerned, ArbCom already have this authority; it's merely rarely used because bureaucrat numbers are vastly lower than the administrator count. If I or any other bureaucrat engaged in misconduct worthy of desysopping an admin, then I'd expect the committee to remove our bureaucrat permissions, too. Acalamari 18:36, 2 March 2024 (UTC)[reply]
2. "adminstrative tools" coverts cratship. Galobtter (talk) 22:26, 2 March 2024 (UTC)[reply]

   +1 This. "Administrative tools" refers to any advanced permissions typically only given to administrators like CheckUser, Oversight, and yes Bureaucrat. Awesome Aasim 23:16, 2 March 2024 (UTC)[reply]

3. "Administrative tools" includes filemover, rollbacker as well as any local advanced administrative tools that Arb decides should be removed, via a case or motion. Not just sysop, crat, OS and CU bits. I'm not getting how there could be confusion here. Dennis Brown - 2¢ 06:00, 3 March 2024 (UTC)[reply]

   Per everyone above me in this section and Risker in the section below. Thryduulf (talk) 10:24, 3 March 2024 (UTC) moved to oppose. Thryduulf (talk) 21:42, 4 March 2024 (UTC)[reply]

4. Administrative tools is not the same thing as administrator tools. Checkuser and oversight are not administrator tools, but they are administrative tools. The same is true of bureaucrat tools. Seraphimblade ^{Talk to me} 10:51, 6 March 2024 (UTC)[reply]
5. They already do. Chris Troutman (talk) 21:37, 14 March 2024 (UTC)[reply]
6. Queen of Hearts ^she/_they^talk/_stalk 20:40, 18 March 2024 (UTC)[reply]

Oppose (ARBPOL petition)[edit]

1. My opinion lines with Risker's below. I'd go further, though. "Administrative" clearly includes any advanced rights. Including additional categories makes the list seem like an enumerated list of userrights, which it should not be. There are other administrative user rights (BAG, EFM) that don't have a strong precedent for removal discussions by the community, although I see no reason why the community by consensus could not remove them. But in some unlikely future where the community thinks it cannot act in these cases (or any other future userrights), then I think that clearly falls under ArbCom. Otherwise we'd end up in a scenario where no body is able to remove the rights. So in summary: my view is that the provision caters for the removal of all administrative userrights which the community, by consensus, believes it cannot revoke. I think trying to enumerate specific technical userrights in the policy, rather than using a descriptive phrase like "administrative tools", is a mistake. I also think this proposal isn't useful, because it doesn't resolve any real controversy. There's no dispute that ArbCom can remove 'crat rights.
   Obviously, I know opposes don't mean anything in this petition, but the section header was created so here's my opinion. ProcrastinatingReader (talk) 21:21, 4 March 2024 (UTC)[reply]
2. Per my comments below and ProcrastinatingReader above. First this is not needed, as ArbCom already can remove 'crat tools - by precedent, by clear community consensus and also by policy as they are covered by "administrative tools", but that's not on it's own a reason to oppose. The reason to oppose is the change from "administrative" to "administrator", which reduces the scope of the committee's possible actions by removing their ability to remove rights that are not part of the admin toolkit, for example rollback and edit filter manager - these can (or might be) removed by the community but there is no reason why the committee shouldn't (also) be able to remove them (there is precedent for removing EFM). Thryduulf (talk) 21:42, 4 March 2024 (UTC)[reply]
3. There is no serious doubt that ArbCom already has this authority, so the amendment is not necessary, and therefore this is not a good use of the community's time. Newyorkbrad (talk) 02:08, 6 March 2024 (UTC)[reply]
4. Per my above comment. Dennis Brown - 2¢ 03:48, 6 March 2024 (UTC)[reply]
5. "Adminstrative" tools is a wider power grant than "administrator and bureaucrat"; for instance the committee would be (and has) within their power to prohibit someone from using rollback, or from using edit filter manager abilities, etc. No one is seriously questioning the ability of Arbcom to de-crat if they decide it necessary, after all, but with this passed the question of "could Arbcom order EFM removed" becomes an open question, and right now it is really not -- yes, they can. Courcelles (talk) 14:20, 6 March 2024 (UTC)[reply]
6. Per Thryduulf, this proposed amendment appears to reduce ArbCom's authority in an attempt to further codify a power it has already wielded. BluePenguin18 🐧 ( 💬 ) 06:30, 8 March 2024 (UTC)[reply]
7. "Administrative tools" is not equivalent to "sysop user group"; it covers any tools used for back room work on the project. ArbCom could (and should) yank pagemover if someone is found to be misusing it, things usually just don't get to that point because ArbCom's jurisdiction to remove pagemover overlaps with sysops'. More realistically, take Edit Filter Manager. This isn't granted automatically to sysops, you don't have to be a sysop to hold it, and removal generally requires a discussion. If an admin grants themselves EFM and is desysoped, would ArbCom let them keep EFM? Currently they could yank EFM along with sysop (both being "administrative tools"), but under the proposal ArbCom would be prohibited from removing EFM (being neither "adminitrator or bureacrat tools"). Obviously someone would IAR and revoke EFM, but why should we even create that situation in the first place when the current text already handles the situation effectively? The proposal significantly narrows the jurisdictional scope of the committee while weakening the Committee's ability to respond to diverse kinds of disruption. — Wug·a·po·des 21:16, 8 March 2024 (UTC)[reply]
8. Per Risker. Rlendog (talk) 17:42, 2 April 2024 (UTC)[reply]
9. Per Thryduulf; I support the ability of the ArbCom to remove bureaucrat tools, but this indeed seems to reduce ArbCom power rather than merely clarify it. –Gluonz ^{talk contribs} 19:43, 2 April 2024 (UTC)[reply]

Comments (ARBPOL petition)[edit]

• Nichalp's permissions were removed under Level II procedures due to a failure to respond to the Committee's concerns over socking and UPE, and in theory a case could have been requested but was not the account had also been inactive for some time. Andrevan isn't the only case where resignation ended a case; in the aftermath of the infamous VfD deletion mess, the case against Ed Poor was also dropped following his resignation of the 'crat bit even though he retained the sysop flag long enough ago that some might not consider it relevant. During the WMF/Fram mess it was also implicitly assumed the committee could review 'crat actions and potentially remove the flag, though that entire situation was such a gross outlier all interpretations should be cautious. The current policy also says that 'crats can request stewards remove the right as a result of a ruling by the committee, though that wording is recent [1]. Finally, the Committee unquestionably has the power to ban someone which would result in the flag being removed eventually simply through inactivity. 184.152.68.190 (talk) 19:18, 2 March 2024 (UTC)[reply]
• A few notes. First, the correct term is "permissions", not "rights" or "tools". Second, if it is going to be amended, it should be "remove any advanced permission" rather than focusing just on 'crat tools. Third, there are several other aspects of the policy that could use updating, and doing it piecemeal is a really, really poor use of community time.
  Finally, on Wikipedia, policy is descriptive, not prescriptive. It is the expectation that the things mentioned in the policy will be done, but it does not restrict other things from being done as well. There's no reason to think that removing the bureaucrat tool is outside of the scope of Arbcom; the policy actually says "administrative tools", not "administrator tools", so the interpretation has always been "tools that are administrative in nature". The very name of the permission "bureaucrat" points directly to an administrative nature to the tools. Propose closing this, as there's no real doubt that Arbcom can remove 'crat tools. Risker (talk) 20:24, 2 March 2024 (UTC)[reply]
  • Should they be managing Stewards or Researchers, though? Surely it should be any advanced permission granted by the en.wiki community.—S Marshall T/C 21:50, 2 March 2024 (UTC)[reply]
    • I would think it is implied that the enwiki ArbCom only has jurisdiction over enwiki matters. Giraffer (talk) 22:04, 2 March 2024 (UTC)[reply]
  • +1 to everything you said. Wikipedia:Arbitration/Policy#Jurisdiction covers the permissions outside of enwiki/granted by the WMF. Galobtter (talk) 21:56, 2 March 2024 (UTC)[reply]
  • I agree with Risker on all points. I don't think there's any question that reviewing bureaucrat permissions are within Arbcom's scope. This goes all the way back to the first Ed Poor case in 2005: Wikipedia:Requests for arbitration/Ed Poor. True, Ed resigned before it came to that, but there was no sense at the time that Arbcom couldn't have done it. Mackensen (talk) 00:58, 3 March 2024 (UTC)[reply]
  • You've made the points that I would have. I'd only add as counterpoint that people do microparse policy sometimes. In addition, one current arbitrator has stated this to be "a grey area policywise", so maybe policy should do a better job of describing things if said description doesn't match the historical reality. ☺ Uncle G (talk) 02:24, 3 March 2024 (UTC)[reply]
• I have removed the "oppose" section, as it is meaningless at this stage. Per Wikipedia:Arbitration/Policy#Ratification and amendment, the petition needs one hundred signatures to move to ratification vote, regardless of how many people oppose the change. HouseBlaster (talk · he/him) 22:19, 2 March 2024 (UTC)[reply]

  I renamed support to "signatories". Galobtter (talk) 22:26, 2 March 2024 (UTC)[reply]

• Several people in the signatories section are supporting substantively different wordings to that proposed - I don't think we can assume that everyone supporting changing "removal of administrative tools" to "removal of administrator or bureaucrat tools" necessarily supports a change to "all advanced permissions" (or similar) unless over 100 editors explicitly support that in their vote ("tools" vs "rights" is probably not significant enough to have an impact). WP:ARBPOL#Ratification and amendment suggests that would require either a new petition by the community before ratification or a different (possibly competing) proposed amendment supported by a majority of the Committee. Thryduulf (talk) 15:49, 3 March 2024 (UTC)[reply]
• Thinking a bit more, I would probably oppose this as worded now because changing "administrative tools" to "administrator tools" runs the risk of ARBCOM not being able to remove any tools not part of (or unbundled from) the admin toolkit - for example rollback and edit filter manager (the latter was done in Wikipedia:Arbitration/Requests/Case/Kww and The Rambling Man). Thryduulf (talk) 15:49, 3 March 2024 (UTC)[reply]
• I'll add a couple of comments based on the responses above. The biggest objection here seems to be that "it's obvious that arbcom can do that". As Alanscottwalker pointed out, we've got a sitting arb who's not sure about that, but that's not actually what got me going on this. In the WP:AN thread I cited above, it came up several times that there wasn't a process to remove an arb a bureaucrat. Nobody jumped up (that I'm aware of) and said, "Of course there is, that's arbcom's job", let alone a link to a policy statement that says it is. So I don't think it's as obvious as people seem to think. On the topic of additional modifications such as changing "tools" to (for example) "rights", I don't disagree that those would be improvements. But I deliberately proposed the smallest possible change, in the hopes that it would be non-controversial. In retrospect, it was silly of me to think "non controversial" could apply to anything on enwiki :-) RoySmith (talk) 15:58, 3 March 2024 (UTC)[reply]

  ...it came up several times that there wasn't a process to remove an arb. And yet, Wikipedia talk:Arbitration Committee/Noticeboard/Archive 51#Suspension of Beeblebrox. There are precedents, if not a policy. Donald Albury 16:47, 3 March 2024 (UTC)[reply]

  @Donald Albury: Ugh, I wrote "arb" but meant to write "bureaucrat". My apologies for the confusion. RoySmith (talk) 16:58, 3 March 2024 (UTC)[reply]

  All that is required to remove a bureaucrat is a request at m:Steward requests/Permissions#Removal of access that includes a link to a discussion demonstrating community consensus, a brief explanation of the reason, and summary of the results of the discussion. Thryduulf (talk) 17:10, 3 March 2024 (UTC)[reply]

  @Thryduulf I pinged a local friendly steward to ask about this. The gist of their response was that a steward would need to see not just a link to the discussion but also a link to the local policy that says that's how it works on enwiki. RoySmith (talk) 02:52, 4 March 2024 (UTC)[reply]

  There is a policy: WP:ARBPOL#Conduct of arbitrators Any arbitrator who repeatedly or grossly fails to meet the expectations outlined above may be suspended or removed by Committee resolution supported by two-thirds of all arbitrators. Thryduulf (talk) 16:59, 3 March 2024 (UTC)[reply]

• Seems to me we can fix this with much less, ahem, bureaucracy by amending WP:Bureaucrats to say that any bureaucrat that loses sysop permissions for any reason should lose bureaucrat as well. —Cryptic 17:36, 3 March 2024 (UTC)[reply]

  It is theoretically possible for a non-admin to be elected as a crat. It's also possible for a 'crat to resign adminship but not 'cratship . A amendment would need to deal with those scenarios, but that's hardly a blocker. Thryduulf (talk) 18:19, 3 March 2024 (UTC)[reply]

  Yeah for me I think it's entirely possible to imagine a scenario where a crat loses their trust as a crat - it requires more trust than admin for a reason - but not so much trust so as to require loss of adminship. The most likely scenario for this would be some kind of poor judgement with the crat tools. Best, Barkeep49 (talk) 04:02, 4 March 2024 (UTC)[reply]

• I think the point that "administrative tools" includes bureaucrats is a valid one. Perhaps, then, it might be helpful to instead just explicitly determine (via consensus) that bureaucrats are included in that definition, rather than amending the text. Frostly (talk) 19:07, 4 March 2024 (UTC)[reply]
• Added to WP:CENT. I'm not familiar with past practice concerning amendments so if this goes against best/common practice, feel free to revert. Also a bit clunky, so please reword if possible. Sincerely, Novo Tape^{My Talk Page} 17:59, 5 March 2024 (UTC)[reply]
• Based on the above discussion (and the point that other groups like checkusers are also potentially subject to this power), I feel like perhaps something like "advanced user rights, including administrative tools" might be a bit clearer than either the existing or proposed language. -- Visviva (talk) 19:35, 5 March 2024 (UTC)[reply]
• It seems to me like most of the opposes could be handled with a simple edit to To handle requests (other than self-requests) for removal of administrative or bureaucrat tools. SportingFlyer T·C 18:05, 2 April 2024 (UTC)[reply]

  Possibly, but as explained above, that would not be what those supporting have expressed support for, so it would need a new proposal. If making a new proposal, then, per Risker, "advanced permissions" is the optimal terminology. Thryduulf (talk) 18:11, 2 April 2024 (UTC)[reply]

Proposed principle about this[edit]

As part of the current Conflict of interest management case ArbCom has proposed (and is currently passing) a remedy which affirms that ArbCom already has this ability. Editors interested in weighing on this may do so on the proposed decision's talk page. Barkeep49 (talk) 18:33, 4 April 2024 (UTC)[reply]

Should ARBPOL be amended to add appealability and submission of questions to U4C? _signed, SpringProof ^talk 04:31, 23 March 2024 (UTC)[reply]

I am hereby petitioning the following two changes to the Arbitration Policy:

A: The following sentence shall be added to WP:ARBPOL#Appeal of decisions:

Questions strictly concerning the Universal Code of Conduct may be severed and appealed to the Universal Code of Conduct Coordinating Committee, which shall decide to hear it or not.

B: The following sentences shall be added to WP:ARBPOL#Policy and precedent:

Prior to publishing a decision, the Committee may refer questions of policy solely regarding the Universal Code of Conduct to the Universal Code of Conduct Coordinating Committee, which shall be required to answer, unanimously or by majority, in a reasonable timeframe.

I am petitioning these amendments in preparation for the upcoming U4C elections, which will establish the U4C. Part of their charter includes the option for projects to submit appeals concerning the UCoC, so I thought that might be helpful to add to ARBPOL.

These amendments are severable and may be adopted by themselves, so I have separated them into A and B.

_signed, SpringProof ^talk 04:31, 23 March 2024 (UTC)[reply]

_{Disclosure: I am currently a candidate for the U4C.}

Signatories for A[edit]

1. Petitioner, _signed, SpringProof ^talk 04:31, 23 March 2024 (UTC)[reply]

Signatories for B[edit]

1. Petitioner, _signed, SpringProof ^talk 04:31, 23 March 2024 (UTC)[reply]
2. Agree Slacker13 (talk) 13:04, 27 March 2024 (UTC)[reply]

General comments (ARBPOL U4C petition)[edit]

These proposals misunderstand what the U4C was created to do, and I hope they'll be withdrawn. The charter is very clear that the U4C doesn't generally have jurisdiction "when a NDA-signed, high-level decision-making body exists", and on en-wiki that's ArbCom. ArbCom should be interpreting the UCOC on its own (if necessary, which it rarely is), and the UCOC couldn't even hear appeals from those decisions if it wanted to except in extraordinary cases of "systemic failure". Anything else would be at odds with both the charter and this project's independence. Extraordinary Writ (talk) 05:52, 23 March 2024 (UTC)[reply]

@Extraordinary Writ: I understand that the U4C doesn't already constitutionally have jurisdiction over appeals. If there already was, this petitioned amendment would be moot (see above). I think the UCoC involves more disputes than it's chalked up to be. For example, the only open case right now is centered around a UCoC issue (What constitutes paid editing?). Love your name, by the way. :) _signed, SpringProof ^talk 07:38, 23 March 2024 (UTC)[reply]

Expanding the U4C's jurisdiction is even more problematic, I think. Even if it could be done without amending the U4C charter (which I doubt), giving the U4C additional authority over ArbCom would be a serious blow to this project's self-governance, and I think it's very unlikely that you'll find 100 editors who'll support doing so. (Paid editing is a Terms of Use issue, not a UCOC issue, by the way.) Extraordinary Writ (talk) 21:03, 23 March 2024 (UTC)[reply]

@Extraordinary Writ: You're right, I apologize. Nevertheless, the case also includes an issue of alleged doxing, which is further part of the UCoC. _signed, SpringProof ^talk 05:08, 24 March 2024 (UTC)[reply]

• This proposal misses the entire point of the UCOC, which is to provide a method of dispute resolution on projects that don't already have methods; in particular, smaller and newer projects. I fully expect to see medium- to large-sized projects without an arbitration committee creating one so that they don't have to deal with the U4C. Keep in mind that the UCoC itself is largely adapted from English Wikipedia policies and their corollaries on other large projects. This seems like massive overreach. Risker (talk) 23:11, 24 March 2024 (UTC)[reply]

  That's what I would like the UCoC to be. However, UCoC is more ambitious about its scope. Its main page claims that it may not be circumvented, eroded, or ignored by ... local policies of any Wikimedia project. It dictates that all who participate in Wikimedia projects and spaces will: [list of demands] and that it applies equally to all Wikimedians without any exceptions. Of course, any attempt to enact such arrogance may see significant numbers of us advise the WMF where to stick its encyclopedia, but those who wrote that text don't seem to be here to play second fiddle to ArbCom. Certes (talk) 23:47, 24 March 2024 (UTC)[reply]

Oppose this per others above: this is just more WMF stuff encroaching on enWP's jurisdiction. 🌺 Cremastra (talk) 22:48, 26 March 2024 (UTC)[reply]

I also oppose. UCoC may claim precedence over ArbCom, the laws of physics and all major deities, but U4C doesn't and shouldn't. Let us continue to answer to locally elected representatives rather than our new global overlords who have parachuted in uninvited. Certes (talk) 23:09, 26 March 2024 (UTC)[reply]

• This isn't useful. For (A) if something is within the scope of UCOC review it doesn't require a local policy to make it as such. For (B) local polices can't make global bodies act. — xaosflux ^Talk 14:21, 27 March 2024 (UTC)[reply]

  It seems to be suggesting that ArbCom defer to the U4C, which I suppose ArbCom could do if it wished, but it certainly isn't obliged to and I'd rather it didn't. Certes (talk) 14:30, 27 March 2024 (UTC)[reply]

  If I've understood correctly, then (A) would allow users to appeal some arbcom decisions to the U4C, whether to do so would not be a decision arbcom could make. If so then this is pointless as the UCOC and U4C determine whether the latter can hear appeals of ArbCom decisions, not local policy. It also attempts to mandate the U4C making a decision on whether to hear a specific appeal or not - legalistically it can't do that, but in practice the only other option is to ignore the request which I would sincerely hope they wouldn't do.

  (B) is really in two parts. The first part allows (but doesn't require) ArbCom to refer UCOC policy questions to the U4C if they want to. I don't have a problem with this in principle, but whether answering such questions is a function of the U4C is a matter for the UCOC and U4C to decide not en.wp policy, and I also don't think it is something that needs a policy amendment to allow given that ARBPOL doesn't restrict who the committee can consult. The second part attempts to require the U4C to answer arbcom's questions and to answer them in a "reasonable timeframe". English Wikipedia policy has no more ability to do this than it has to require the US Congress to answer arbcom's questions.

  Together that makes this whole thing a mixture of pointless and moot. Thryduulf (talk) 14:54, 27 March 2024 (UTC)[reply]

• It's credibly claimed above that in practice, our ArbCom disapplies the UCOC to en.wiki. If so, then we should make a clear declaration of this in a prominent place.—S Marshall T/C 16:00, 27 March 2024 (UTC)[reply]

  @S Marshall what doesn't apply to English Wikipedia is the Universal Code of Conduct Coordinating Committee (U4C). The community has never been given a chance to ratify the Universal Code of Conduct (UCoC) itself. This has always struck me as a mistake, though the WMF Board does seem to have the power to make it policy anyway. Either way, the UCoC is a set of minimums and it is my firm judgement that enwiki policies often go far above those minimums and in no place are our policies less than the UCoC. Barkeep49 (talk) 21:57, 27 March 2024 (UTC)[reply]

  On the basis of your last sentence, I modify my previous position to: "On en.wiki, our governance and policies make the UCOC nugatory." If that's right, it's rather important, and I do think we should say so.—S Marshall T/C 22:09, 27 March 2024 (UTC)[reply]

• This isn't useful. ArbCom is ArbCom. U4C has no supervisory jurisdiction over ArbCom. Stifle (talk) 10:08, 2 April 2024 (UTC)[reply]

I wish to seek to change the wikipedia policy WP:SOURCE. Currently this states "Any material lacking an inline citation to a reliable source that directly supports the material may be removed and should not be restored without an inline citation to a reliable source." in the section Responsibility for providing citations. I propose amending this with the additional sentence "Sources may be contained in a linked article."

RATIONAL FOR THE PROPOSED CHANGE

I believe that requiring sources on every page brings a number of problems: 1) it is onerous and inefficient and discourages linking relevant articles to pages, especially for new editors: 2) the relevant article may include more sources, mentions of the article might only include one, so anyone looking for useful information might not see it; 3) in a rapidly moving field sources may be updated in an article but that might be missed on linked pages. In any case it is easy for anyone to click on the link to see the article with all relevant sources. Hewer7 (talk) 13:50, 23 March 2024 (UTC)[reply]

I disagree with this suggestion. If the same information is sourced in a different article, it's much less onerous for the editor to copy the source to the new article than to expect readers to go to other articles to verify the information. And we can't rely on other articles being properly sourced because, too often, they're not. Schazjmd (talk) 14:00, 23 March 2024 (UTC)[reply]

Wikipedia:Wikipedia is not a reliable source. It has been long established that we cannot cite other Wikipedia pages to support content in a Wikipedia article. It may be fruitful to review sources cited in other articles, but Wikipedia:Verifiability#Burden states, The burden to demonstrate verifiability lies with the editor who adds or restores material, and it is satisfied by providing an inline citation to a reliable source that directly supports the contribution. That means that an editor who is using a citation to a source found in another article must have verified that the source does indeed support the content being added. You cannot change just the one policy point you targeting, other points in other policies and guidelines would all have to be changed. Donald Albury 14:10, 23 March 2024 (UTC)[reply]

I am not proposing that wikipedia be used as a source. My proposal is that sources may be contained in a linked article. Hewer7 (talk) 14:42, 23 March 2024 (UTC)[reply]

When you rely on another linked article to have the cited sources to support content, you are indeed using that other article as a source for that content. Donald Albury 18:03, 23 March 2024 (UTC)[reply]

An example of why we don't use WP articles as sources (or rely on sources cited in other articles without verifying their suitability): An article I'm drafting (User:Donald Albury/Trail Ridge) refers to the geological Hawthorn Formation. I found that our article on the Hawthorn Formation was a stub, saying it is a stratigraphic unit in South Carolina. On the other hand, our article on the Hawthorn Group said it was a stratigraphic unit in north Florida. In fact, the Hawthorn Group, formerly called the Hawthorn Formation, is a stratigraphic unit stretching from southeastern South Carolina through coastal Georgia and down the Florida Peninsula. I had to find new sources and cite them to correct that mess. You can only decide that a Wikipedia article is correct if you check out the cited sources, and search for and check out other sources (in case the cited sources are incomplete), and if you do that, you should just go ahead and cite those sources in the article you are working on. Donald Albury 18:28, 23 March 2024 (UTC)[reply]

There is a very simple reason why we require citations to be repeated in every article where information appears… articles can change. The “linked” article may currently contain a citation that supports the information at the article you are working on… but there is no guarantee that this will be the case in the future. The other article might, at some point in the future, be completely rewritten - and in the process the citation that supports what is in your article might be removed. You have to repeat the citation in your article to ensure that the information will always be supported, no matter what may happen at the other one. Blueboar (talk) 14:44, 23 March 2024 (UTC)[reply]

In addition to that (not that that isn't enough, mind you), there's the fact that while most of us most of the time experience Wikipedia online, it's not the only way it can be used. A printed copy of an article that contains proper referencing has those references listed at the bottom of the article. If we switch to relying on the mere fact that there are references on some other page, those references may not accessible to the person using the printed version. -- Nat Gertler (talk) 15:55, 23 March 2024 (UTC)[reply]

I would oppose this change in policy. Besides the other issues mentioned above, this would make it much more onerous and error-prone for a reader to verify content. Suppose there is a sentence containing links to 5 other Wikipedia articles, with no citation. If the reader wants to verify this statement, they would need to click on each of those 5 links, scrutinize the linked article to try to find a similar statement and see if there is a source there. If they can't find such a source after spending 10 minutes or whatever in this process, they still don't know if they have just overlooked the source or if the original statement was simply unsourced. Having the source for a statement at the point where the statement is made is essential.

The OP says that the current process is onerous for editors. That's fine; if there is a part of the process that is onerous, it should be onerous for editors, not for readers. CodeTalker (talk) 20:39, 23 March 2024 (UTC)[reply]

+1 Regards, Goldsztajn (talk) 21:24, 23 March 2024 (UTC)[reply]

• No, absolutely not. This would invite all sorts of problems. The most obvious one is that it would become easier for a source's meaning to drift via a game-of-telephone; a slight mistake or paraphrase on one article that isn't a problem there could become something drastically divergent from the source on another article that relies on the first one's citation. And worse, it makes it harder to verify - what source in the linked page, exactly, and on what page, do I look at if I'm not sure it's summarized correctly on the second page? Finally, on top of all this, what if the relevant section is edited or removed and the source replaced or removed itself? Someone making that edit may not even know the page that relied on that source existed, so it would quietly become unsourced with nobody realizing that it had happened. We already have a problem with "source drift", especially in uncited lead sections, where text starts out reasonably summarizing the source and yet repeated edits for WP:TONE or perceived NPOV issues or the like, each one a reasonable rewording of the phrasing immediately prior to them, collectively cause the text to drift further and further away from what the source actually says. This would make the problem far worse. --Aquillion (talk) 03:55, 25 March 2024 (UTC)[reply]

  +1 I strongly oppose this idea, but Aquillion said it far better than I could. 🌺 Cremastra (talk) 20:58, 26 March 2024 (UTC)[reply]

This would go against verification, Wikipedia is never a reliable source for verification and there is nothing to say that the details on the other page are reliable or will even stay in the article. -- LCU ActivelyDisinterested «@» °∆t° 21:18, 25 March 2024 (UTC)[reply]

• Oppose. Sources should be on the page they relate to, so that verifiability can be met. Stifle (talk) 10:09, 2 April 2024 (UTC)[reply]

I frequently patrol RecentChanges, and a pet peeve of mine is users creating standalone talk pages, which I feel personally responsible for G8'ing. Is there any reason not to prevent them from creating abandoned pages? 🇺🇲JayCubby✡ please edit my user page! Talk 15:45, 28 March 2024 (UTC)[reply]

@JayCubby we don't have a technical mechanism to enforce this, and creating a "policy" forbidding it would just be ignored by these editors that would have no idea that there was a policy, and that they were expected to follow it. — xaosflux ^Talk 13:16, 29 March 2024 (UTC)[reply]

Dear @User:Shannon1 before reverting my edits please discuss here. These maps are preferred because they are zoomable and rich of metadata. If you disagree please discuss. Hooman Mallahzadeh (talk) 15:19, 29 March 2024 (UTC)[reply]

@Hooman Mallahzadeh: Hi, can you link me to the Wikipedia documentation or discussion that indicates the OSM maps are "preferred"? The watershed maps are valuable to river articles because they show key information like drainage basin extent, tributaries and topography. I wouldn't be opposed to including both in the infobox, but there appears to be no way currently to display two maps. Shannon [ Talk ] 15:22, 29 March 2024 (UTC)[reply]

I should note that in French Wikipedia it is used correctly for Seine, In Japanese used for Arakawa River (Kantō). This is correct use of maps in the year 2024. Hooman Mallahzadeh (talk) 15:24, 29 March 2024 (UTC)[reply]

@Shannon1 Policies doesn't say anything. But I can discuss and defend about their preference. Just compare these images:

Traditional map	New Maps

Which of these maps is more clear? The new or the old? Hooman Mallahzadeh (talk) 15:38, 29 March 2024 (UTC)[reply]

I really think that we should create a policy for the preference of OpenStreetMaps over traditional ones. Hooman Mallahzadeh (talk) 15:40, 29 March 2024 (UTC)[reply]

I think they serve different purposes, and it would be ideal to have both in the infobox - but there appears to be no way to do this at the moment. The OSM map would be a fantastic replacement for pushpin locator maps like on Walla Walla River. However, it deletes a ton of important information that is displayed in the older watershed map. Can we hold off on any kind of mass replacement until this can be resolved? Shannon [ Talk ] 15:43, 29 March 2024 (UTC)[reply]

1. OpenStreetMaps presents the least but most important metadata at each level of zoom.
2. The ability of zooming is only provided by OpenStreetMaps
3. If any change occurs for the river, for example the path changes, this is rapidly applied for OpenStreetMaps
4. language of metadata changes automatically for each Wikipedia
5. and many others. Just let me some time to write them.
6. font-size of text of metadata is automatically adjusted

Hooman Mallahzadeh (talk) 15:44, 29 March 2024 (UTC)[reply]

You should have tried to get agreement for that policy before attempting to impose your preference across a large number of river articles. Kanguole 16:09, 29 March 2024 (UTC)[reply]

@Kanguole Ok, we are here for agreement about that. Hooman Mallahzadeh (talk) 16:14, 29 March 2024 (UTC)[reply]

@Hooman Mallahzadeh: Please revert the map changes you have made, since they have been challenged and there is so far no agreement for them. Kanguole 21:04, 29 March 2024 (UTC)[reply]

If it's an article about a river, the traditional map is more informative. 🌺 Cremastra (talk) 21:01, 29 March 2024 (UTC)[reply]

@Shannon1 See, we can have both maps by using "Hidden version of maps in infoboxes"

{{hidden begin|title=OpenStreetMap|ta1=center}}{{Infobox mapframe |wikidata=yes |zoom=6 |frame-height=300 | stroke-width=2 |coord={{WikidataCoord|display=i}}|point = none|stroke-color=#0000FF |id=Q1471 }}{{hidden end}}

that is rendered as:

OpenStreetMap

which yields: (here we hide topological and show OpenStreetMap, but the reverse can be applied)

Seine
The Seine in Paris
Topographical map
Native name	la Seine (French)
Location
Country	France
Physical characteristics
Source
• location	Source-Seine
Mouth	English Channel (French: la Manche)
• location	Le Havre/Honfleur
• coordinates	49°26′02″N 0°12′24″E / 49.43389°N 0.20667°E / 49.43389; 0.20667
• elevation	0 m (0 ft)
Length	777 km (483 mi)
Basin size	79,000 km2 (31,000 sq mi)
Discharge
• location	Le Havre
• average	560 m3/s (20,000 cu ft/s)
Basin features
River system	Seine basin
Tributaries
• left	Yonne, Loing, Eure, Risle
• right	Ource, Aube, Marne, Oise, Epte

We can have both maps, one is hidden by default, and the other is shown by default. But I really think that we should show OpenStreetMap and hide others. But in many rare cases that the revert is true, we show topographic map and hide OpenStreetMap. Hooman Mallahzadeh (talk) 15:54, 29 March 2024 (UTC)[reply]

We want an edit for Template:Infobox river and use parameters hidddenMap1 and probably hiddenMap2 for implementing this idea. Hooman Mallahzadeh (talk) 16:07, 29 March 2024 (UTC)[reply]

I opened a thread on Template talk:Infobox river regarding this. Also pinging @Remsense: who has been separately reverting my edits. Shannon [ Talk ] 16:09, 29 March 2024 (UTC)[reply]

I'm merely concerned specifically with the articles I've reverted, I have no opinion on the issue at-large. Remsense诉 16:16, 29 March 2024 (UTC)[reply]

@Remsense: I've been on Wikipedia 15+ years and river articles have always used these watershed maps. I'm aware that policies can change but there has been no such discussion at WP:RIVERS or elsewhere. In my view, the watershed map on Yangtze for example is far more informative than the OSM map, which is essentially a better locator map. The Yangtze basin is immense, with dozens of major tributaries, and in this case the OSM map also leaves out the Jinsha that continues for more than 2000 km upstream of Sichuan. (Not because I made the watershed map, necessarily – I just noticed the reversions because of my watchlist.) Shannon [ Talk ] 16:25, 29 March 2024 (UTC)[reply]

I'll revert on these pages for now, thank you for the elaboration. Remsense诉 16:35, 29 March 2024 (UTC)[reply]

If you really want consistent guidelines (after working out technical issues), put them on WikiProject Geography. A global policy would just be MOS:BLOAT. SamuelRiv (talk) 16:39, 29 March 2024 (UTC)[reply]

@SamuelRiv I made a discussion for that here. Thanks, Hooman Mallahzadeh (talk) 16:51, 29 March 2024 (UTC)[reply]

@Shannon1:For my final word, I really cann't read the metadata of this map, because text on it is too small:

unless opening it. So its metadata is useless at the first glance, unlike OpenStreetMap.

• Not sure where to put this comment, because this section is broken with huge amounts of whitespace making it almost unreadable. I just want to mention that i have reverted three or four river map changes by Hooman Mallahzadeh, the summary of the diff indicated that the rather ugly and not as useful Open Street Map was preferable; my summary is "By whom is it "preferred"? Don't think there's a policy on this; until any discussion is finished the better map shouldn't be removed." I see now that a discussion (not a vote at all) has been started here. I'd like to suggest that Hooman Mallahsadeh reverts all the changes they have made of this type until this discussion comes to some conclusion. Happy days, ~ Lindsay^Hello 20:26, 29 March 2024 (UTC)[reply]

Proposal 1: Render both; prefer OSM; hide others[edit]

Ok, please vote for this scenario.

"Both topographic and OpenStreetMaps will be rendered in Infobox, but it is preferred to show OpenStreetMap and hide others by using "Template:Hidden begin" and "Hidden end".

For "vote", I asssume you mean "discuss"? 🌺 Cremastra (talk) 21:04, 29 March 2024 (UTC)[reply]

Agree with proposal 1 re OSM[edit]

1. Agree Hooman Mallahzadeh (talk) 16:23, 29 March 2024 (UTC)[reply]

Disagree with proposal 1 re OSM[edit]

1.  Disagree The OS map (in the way it is implemented here; don't know if layers in OS can be switched off for this kind of view) shows too much information that is not relevant for river articles (like roads, for example), and not enough information about what these articles are about - rivers. Plus, the watershed maps are just prettier IMO. Zoeperkoe (talk) 18:08, 29 March 2024 (UTC)[reply]
2.  Disagree Some maps are better for some things. For example in river or lake articles, the watershed maps are more helpful, but for city maps OSM is probably better. 🌺 Cremastra (talk) 21:03, 29 March 2024 (UTC)[reply]

   @Cremastra@Zoeperkoe Why OSM is preferred? Because it is more abstract, and for solving our problems, it is preferred to move from reality into concept. Please read the article Concept. In fact, we want to solve our problems by concepts that only includes main data and lacks redundant data. So certainly OSM maps are appropriately more abstract and finer concept.

   For example, in this image:

   

   The abstracted version of tree is preferred for many applications (question answering) like addressing and others over Cypress tree.

   So. in river Infoboxes, I even propose to use wider lines to remove elaboration of rivers and make a simpler map for its Infobox at the first glance. Hooman Mallahzadeh (talk) 05:22, 30 March 2024 (UTC)[reply]

   As someone who also likes the OSM maps in general cases: "read the Concept article" is not a very compelling argument.

   My argument would be that they are more flexible and more immediately maintainable by editors. We can theoretically better control the level of abstraction or detail we need for a given article. I don't mind cracking open the text editor to edit an SVG, but not everyone wants to do that. I've seen enough infobox crimes to know that dogmatism either for maximum abstraction or concretion is counterproductive. Remsense诉 05:28, 30 March 2024 (UTC)[reply]

3.  Disagree For users with Javascript disabled (either by choice or by force), OSM maps are useless. No movement, no zoom, and nothing drawn on top of the base tiles. Also no ability to swap between tiles. Please ensure that whatever choice you make fails safely without scripts. 216.80.78.194 (talk) 11:10, 31 March 2024 (UTC)[reply]

   When I disable JS in my browser, the maps above still render with the lines indicating the rivers' courses. They do miss the ability to click to see a larger interactive version, but they're not useless. Anomie⚔ 13:22, 31 March 2024 (UTC)[reply]

4. OSM map is much less informative for the topic of rivers. CMD (talk) 06:17, 7 April 2024 (UTC)[reply]

   @Chipmunkdavis Being less informative is an advantage. The purpose of an Infobox is providing some general information, not detailed information. In an Infobox, only the most important and most readable data should be shown. Other maps can contain details, not the Infobox map. Hooman Mallahzadeh (talk) 06:52, 7 April 2024 (UTC)[reply]

   While I think this position is preferable to the other extreme which is far more common in infobox disputes, I think it's a perspective being wielded too dogmatically here. While it's fun when I say things like "being less informative is an advantage" and there's a real sense where that's true, it also misses the point here that no one size fits all when it comes to presenting key information, and a watershed is important information one would like to know at a glance. It's being mischaracterized in my opinion as a detail, what others are arguing is that it is not so. Remsense诉 07:05, 7 April 2024 (UTC)[reply]

   @Chipmunkdavis@Remsense Yes. But the most abstract data version is in the first zoom, if you want more abstract version do "zoom out" and if you need more detailed version, do "zoom in",

   But at the first glance, if is not enough informative, then for example for "watershed", we can use "point locators" on the map. Or for areas we can use area locators. They are added very fast by using new items of Template:Maplink. The same as Shinano_River. Hooman Mallahzadeh (talk) 07:20, 7 April 2024 (UTC)[reply]

   I agree it's a potential solution. But we should judge the solution on a case by case basis, rather than making a swap across an entire class of articles now. Remsense诉 07:22, 7 April 2024 (UTC)[reply]

   An in this particular case, the watershed and to an extent tributaries is important and immediately visually readable. CMD (talk) 12:29, 7 April 2024 (UTC)[reply]

5. Disagree. I have just been reading a river article i happened to come across (River Wyre) which has made me feel so strongly that i have had to return here and protest these OSM maps, though i had planned not to. The map in that particular article, as well as other river articles i have looked at recently, is not sufficient: It gives no idea of the area drained by the river, there are unexplained dotted and faint grey lines all over it which apparently give no information, and (in this particular case) it is huge compared to the other images in the article. I am rather worried by Hooman Mallahzadeh's statement above, [b]eing less informative is an advantage, which i strongly disagree with; we should be giving our readers an abundance of information and allowing them, if they so desire, to choose what they wish to take away. Happy days, ~ Lindsay^Hello 07:42, 7 April 2024 (UTC)[reply]

   In the context of an infobox it is understandable what they mean. However, the point here is I think it's perfectly reasonable to display a river's watershed in the infobox. Remsense诉 07:54, 7 April 2024 (UTC)[reply]

   @Remsense See French Wikipedia at this page https://fr.wikipedia.org/wiki/Seine . It displays both start and end with pointer and then in the continuum of Infobox, it discusses start and end of the river. I think this convention of French Wikipedia describes rivers (and also Seine river) fantastic. Hooman Mallahzadeh (talk) 09:02, 7 April 2024 (UTC)[reply]

   Remsense, i agree that the infobox should contain the watershed ~ the thing is, if it doesn't, the information (presumably in the form of a map) would need to be elsewhere in the article. The infobox is indeed the logical place to look. Happy days, ~ Lindsay^Hello 13:19, 7 April 2024 (UTC)[reply]

   @LindsayH Please do not be surprised about my statement! Just see the Occam's razor article, ending line of the first paragraph:

   "The simplest explanation is usually the best one."

   And this sentence:

   In philosophy, Occam's razor (also spelled Ockham's razor or Ocham's razor; Latin: novacula Occami) is the problem-solving principle that recommends searching for explanations constructed with the smallest possible set of elements.

   And this sentence:

   Entities must not be multiplied beyond necessity.

   I don't know what is your major, but this principle is applied to all theories in science. Hooman Mallahzadeh (talk) 08:07, 7 April 2024 (UTC)[reply]

   Hooman Mallahzadeh, i think you're possibly misunderstanding Ockham's razor: It says nothing about withholding information to make things simpler, what it means is that given a certain number of observations or facts the simplest explanation which covers them all is to be preferred. So i am still concerned (maybe even more so now) about your desire to give our readers less information. Happy days, ~ Lindsay^Hello 13:19, 7 April 2024 (UTC)[reply]

   @LindsayH «Least information» but «most important information», in addition, it should be readable at the first glance, topological maps are usually unreadable at the first glance. Hooman Mallahzadeh (talk) 13:24, 7 April 2024 (UTC)[reply]

   My point is that this aphorism has exhausted its usefulness, and that this should be decided case by case, not as a class. Remsense诉 14:28, 7 April 2024 (UTC)[reply]

Neutral[edit]

1. I support the inclusion of both, but there is no need to hide one or the other. See the current documentation of Template:Infobox river. The OSM implementation would be a good replacement for the dot locator map, but it does not at all adequately replace a topographical map showing basin-level details. I am aware of the limits of image maps particularly regarding language, but 1) this is the English Wikipedia and this primarily concerns pages in English; 2) replacing existing .jpg and .png maps with SVG maps would enable maps to be easily edited for translation; and 3) if a map isn't available in a certain language, then just using the OSM version is fine. Shannon [ Talk ] 19:00, 29 March 2024 (UTC)[reply]

• Please see WP:NOTVOTE. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:26, 29 March 2024 (UTC)[reply]

• Yeah, that isn't how policy decisions are made. AndyTheGrump (talk) 21:32, 29 March 2024 (UTC)[reply]

Proposal 2: Include both (OSM and topographic maps) when appropriate[edit]

This seems like it best approaches existing consensus:

When appropriate, both a topographic map and OpenStreetMaps should be included in infoboxes.

Remsense诉 01:07, 30 March 2024 (UTC)[reply]

@Remsense Just see how beautiful Japanese Wikipedia introduced the river Shinano_River by this code:

{{Maplink2|zoom=8|frame=yes|plain=no|frame-align=right|frame-width=400|frame-height=600|frame-latitude=36.93|frame-longitude=138.48
|type=line|stroke-color=#0000ff|stroke-width=3|id=Q734455|title=信濃川
|type2=line|stroke-color2=#4444ff|stroke-width2=2|id2=Q11655711|title2=関屋分水
|type3=line|stroke-color3=#4444ff|stroke-width3=2|id3=Q11362788|title3=中ノ口川
|type4=line|stroke-color4=#4444ff|stroke-width4=2|id4=Q11372110|title4=五十嵐川
|type5=line|stroke-color5=#4444ff|stroke-width5=2|id5=Q11561641|title5=渋海川
|type6=line|stroke-color6=#4444ff|stroke-width6=2|id6=Q11437096|title6=大河津分水
|type7=line|stroke-color7=#4444ff|stroke-width7=2|id7=Q3304165|title7=魚野川
|type8=line|stroke-color8=#4444ff|stroke-width8=2|id8=Q11587633|title8=破間川
|type9=line|stroke-color9=#4444ff|stroke-width9=2|id9=Q11561259|title9=清津川
|type10=line|stroke-color10=#4444ff|stroke-width10=2|id10=Q11366441|title10=中津川
|type11=line|stroke-color11=#4444ff|stroke-width11=2|id11=Q11674896|title11=鳥居川
|type12=line|stroke-color12=#4444ff|stroke-width12=2|id12=Q11530256|title12=松川
|type13=line|stroke-color13=#4444ff|stroke-width13=2|id13=Q11571106|title13=犀川
|type14=line|stroke-color14=#4444ff|stroke-width14=2|id14=Q11626952|title14=裾花川
|type15=line|stroke-color15=#4444ff|stroke-width15=2|id15=Q11671931|title15=高瀬川
|type16=line|stroke-color16=#4444ff|stroke-width16=2|id16=Q11444998|title16=奈良井川
|type17=line|stroke-color17=#4444ff|stroke-width17=2|id17=Q11563522|title17=湯川
|type18=line|stroke-color18=#4444ff|stroke-width18=2|id18=Q59404662|title18=依田川
|type19=line|stroke-color19=#4444ff|stroke-width19=2|id19=Q59490451|title19=西川
|type20=line|stroke-color20=#4444ff|stroke-width20=2|id20=Q59537584|title20=黒又川
}}

This includes all sub-rivers. I think this type of maps should be a good sample for all other Wikipedia to introduce rivers. Hooman Mallahzadeh (talk) 13:18, 30 March 2024 (UTC)[reply]

I personally quite like this, yes. I'm sure if there's some argument against this, we will be hearing it—I like when other editors hone my aesthetic senses. Remsense诉 13:21, 30 March 2024 (UTC)[reply]

It looks very useful. I also stumbled across the Syr Darya page which manages to use both types of map in the infobox using the |extra= field. I would say that's a good, clean way to approach it going forward. Again, I think both types of maps are useful in different ways, and I see no reason to take an absolutist stance and say one or the other should be favored in all cases.

To add, I was kind of rubbed the wrong way at the start of this debate by OP's attitude that new and high tech is always better regardless of the context or usage (not to mention inventing an imaginary consensus which totally threw me for a loop), and as others have commented, this isn't how policy decisions on Wikipedia are made. Finally, as someone passionate about river topics, the auto generated maps just don't tell the full "story". It's nuance and individual approach versus cold standardization. Yes, there are a lot of poorly drawn and inaccurate user-made maps out there (including many of my older maps) which could do well with being replaced, but then there are beautiful ones like Rhine, which provide a value much harder to replace.Shannon [ Talk ] 16:53, 30 March 2024 (UTC)[reply]

@Shannon1 Even in the article of Rhine and in the selected map of Infobox, the font is too small and we can't read anything. So aside from choosing OSM or not, between existing maps, the second map i.e., File:Rhein-Karte2.png is more appropriate for Infobox map of this article. I think we should make a policy for selecting between maps, the one that is more abstract, i.e. we apply this policy:

The simplest and most abstract map is the preferred one for Infobox of articles

Hooman Mallahzadeh (talk) 17:56, 30 March 2024 (UTC)[reply]

I have already made my point, so I'll excuse myself from further argument on this thread. As I've stated, I support applying both maps where possible as I believe that provides the best value for the reader. I don't particularly mind if the OSM or topographic map is placed first or second in the infobox. However, I cannot agree with the assessment that "the simplest and most abstract map is preferred" in the context of rivers, which are complex systems that are much more than a simple blue line. Unless a broader consensus can be reached, I maintain to oppose any removal of useful content that have been considered standard on river articles for years. Shannon [ Talk ] 19:56, 30 March 2024 (UTC)[reply]

I've (hopefully) resolved a mild conflict on a page I was editing by adding additional sources to with Hell Gate links but this raises a larger question for me - how does worker-owned local journalism fit into the reliable source media sphere? Hell Gate has no physical presence, but neither does Gothamist, or The City. The main difference is that Hell Gate is a worker cooperative so it has a bit more of a "voice" than Gothamist, which has a top-down structure, does.

I have no idea if other cities have their own version of this, but I feel like this model may become more common as traditional journalism collapses in on itself.Computer-ergonomics (he/him; talk; please ping me in replies ) 19:52, 29 March 2024 (UTC)[reply]

@Computer-ergonomics you should ask this question at the reliable sources noticeboard, where you'll get a faster response Mach61 23:54, 29 March 2024 (UTC)[reply]

Ah thanks for the link! I had lost it and need to bookmark it. But there was no rush on the response, I just think it' a good conversation to have.Computer-ergonomics (he/him; talk; please ping me in replies ) 03:24, 30 March 2024 (UTC)[reply]

I say use it with a bit of caution. It's still a new-ish organization and has a small newsroom. But this New York Times article has a favorable coverage of it, describing it as a "blog-style news site". It also employs professional journalists. Extremely local journalism carries WP:DUE concerns. Ca ^{talk to me!} 01:42, 30 March 2024 (UTC)[reply]

Yeah, in this case it was for coverage of Palestine protests in NYC which were also covered in Curbed, the NYT, the City, Hyperallergic, etc etc etc.Computer-ergonomics (he/him; talk; please ping me in replies ) 03:26, 30 March 2024 (UTC)[reply]

This is better for WP:RSN (feel free to copy my response over if you move it). In terms of operations, The City is a good analogy, but not Gothamist, which is published by WNYC. In terms of content, there are several similarities between Hell Gate and Gothamist, though. No idea how it's doing financially with its atypical business model, but Hell Gate is surprisingly well known for how new it is. It's had several good scoops/stories/hot takes that have made the rounds and I've not seen any issues with its factual content. The authors' voices come through in the writing more than the big papers, and that can result in a bit of a blend of opinion and news, but the opinion part seems pretty easily distinguished. It's somewhere between a traditional news website and a group blog where all of the authors are experienced journalists and experts in the area of the blog (NYC politics, etc.). The upshot is I'd think it would be usable in general for the facts it presents, for its opinion with attribution, and if a claim is especially contentious, defer to sources with more established editorial processes. Also, great taste in images. — Rhododendrites ^talk \\ 02:37, 1 April 2024 (UTC)[reply]

 You are invited to join the discussion at Wikipedia talk:Biographies of living persons § c-Aaron Liu-20240401154800-TheSpacebook-20240331201000. Aaron Liu (talk) 19:07, 1 April 2024 (UTC)[reply]

I'm wondering why the term "original research" is used, as in "no original research allowed on Wikipedia." There's nothing wrong with research—we all seek out, discover, consult, read, and cite various types of sources. We all conduct research. The problem is when editors analyze, interpret, or draw conclusions from the research they've done. The problem is "original thought" (a phrase I've seen used as well), not original research. I'm a new editor, so maybe I'm missing something with the terminology, but in my several months editing Wikipedia, it sure feels like I do "original research" all the time. I just have to be careful not to bring an agenda, opinion, or personal bias when I present the findings of that research by writing or editing an article on Wikipedia. Perhaps someone can clarify this for me, but even after that clarification, I feel the terminology is very confusing for new editors and I'm wondering whether the phrase "original research" should be used at all.

The policy about original research states: "original research means material—such as facts, allegations, and ideas—for which no reliable, published source exists." That doesn't sound accurate to me. That's not original research, that's fabrication. It's not research at all, original or otherwise. Wafflewombat (talk) 16:46, 2 April 2024 (UTC)[reply]

Cal Ripken Jr. has a streak of over 2000 consecutive games in MLB, and we have several reliable sources to outline this fact, so List of Major League Baseball consecutive games played streaks is supported well with sources for this record. We also have a list for Career stolen base leaders similarly well sourced. "Career stolen base leaders for players who played past 40 years old" could be a notable item to be included in a players article should a source exist, but as there's no reliable source I can point to for information to build an article, that would be more than likely be considered original research, and that's maybe the clearest I can break it down for an example. YellowStahh (talk) 17:31, 2 April 2024 (UTC)[reply]

If you feel OR is conceptually convoluted, wait till you get to SYNTH... :) </facetiousness> Think of outcomes rather than process - what the prohibition on original reasearch is primarily concerned with is the end product. Is it conceptually something new or is it something *directly* attributable to reliable sources? Regards, Goldsztajn (talk) 22:03, 2 April 2024 (UTC)[reply]

WP:OR certainly applies to substantive article content. But it's interesting in that I see a lot of original research done in pursuit of rigorous sourcing for articles. And I think most would agree that's a good thing that's made WP more reliable than most -- editors here sometimes go through extensive effort to separate substance from chaff, or suss out fabrication and myth that's been uncritically repeated in what might be superficially be considered reliable secondary sources. (For sources in history articles especially this seems to be an exceptionally important, and exceptionally difficult, task.)

This is why, when on Talk Page discussions about sourcing, I'm tempted to wp:trout those who accuse editors of violating OR by examining such issues in citations. That's not what the policy says or intends. To answer as to the term itself, no two-word term will adequately summarize a policy, since every policy here has subtleties and exceptions, so I think it's fine enough shorthand. It gets the important point across, especially for newer editors. SamuelRiv (talk) 22:59, 2 April 2024 (UTC)[reply]

Thanks for the replies, all of you. YellowStahh and Goldsztajn helped to clarify the term. I had pretty much come to the same conclusion that Goldsztajn presented on my own, but it took me awhile. I think more appropriate guidelines would be no original thought, no original arguments, no original conclusions. I can see why it's handy to have a two-word term to summarize all this, but honestly I would have preferred a longer version, because I feel the term "original research" is misleading, and honestly I keep having to remind myself what it means. SamuelRiv, you may feel that the term "gets the important point across, especially for newer editors," but what I've been trying to say is that I heartily disagree. For me, it has been misleading, confusing, and frustrating. Only when somebody used the phrase "no original thought" in a talk page discussion did I begin to understand what the OR policy was actually about. Wafflewombat (talk) 03:04, 3 April 2024 (UTC)[reply]

"we all seek out, discover, consult, read, and cite various types of sources" - That's not the kind of "research" the OR policy is talking about (well, except for original-research-via-synthesis, discussed by YellowStahh above). It's talking more about, like, observation of raw material / primary sources, the kind of thing that should be published in a journal article / book / blog post / etc. Citing a secondary source that example.com has the most toxic comment section on the Internet isn't OR. Examining example.com 's comment section yourself and coming to the conclusion it is the most toxic comment section on the Internet is OR - you should publish a pithy blog post about that, not add it to Wikipedia as a fact. Or for an even more direct example - say you're traveling the wilds of Alberta and take a picture of the Canadian T-Rex, long thought to be extinct. You need to go get that published in an academic journal first; you can't just come directly onto Wikipedia and say "According to my discovery, the T-Rex is not extinct." (As the example shows, this is really a defense mechanism against cranks - rather than argue with them over whether that was REALLY a T-Rex or not, we're just directing them to get it published in a reliable source first, which won't happen 99% of the time.) SnowFire (talk) 17:15, 4 April 2024 (UTC)[reply]

Thanks, this is helpful. Wafflewombat (talk) 20:19, 4 April 2024 (UTC)[reply]

I would further the above example of a T-Rex to a discussion recently I saw here, where the subject source may be notable but in the interview this user was looking to reference it turned out to be Original research and was an interview the user conducted himself looking to publish it to Wikipedia. Had this of been a Sun newspaper interview or a well known Book podcast it would've been fine to reference. YellowStahh (talk) 16:21, 5 April 2024 (UTC)[reply]

Think of it through the lens of primary, secondary, and tertiary sources. A secondary source reviews primary sources and does original research, then writes conclusions. Wikipedia is a tertiary source, we summarize the secondary sources, or directly use tertiary sources that review all sources on a subject, and we avoid primary sources. Cuñado ☼ - Talk 20:38, 4 April 2024 (UTC)[reply]

Well said, thank you. Wafflewombat (talk) 21:12, 4 April 2024 (UTC)[reply]

Posting this announcement / discussion thread also here for visibility, as this is in a way a global policy matter. The other thread can be found here.

Hello! I am writing to you to let you know that the full draft of the Movement Charter has been published on Meta for your review.

Why should you care?

The Movement Charter is important as it will be an essential document for the implementation of the Wikimedia 2030 strategy recommendations. Participating in the Charter discussions means that you ensure that your voice is heard and your interests are represented in shaping the future of the Wikimedia Movement. As the English Wikipedia community is the largest of the Wikimedia movement, it is essential to have the perspectives from your community presented in the global conversations. I hope many of you will find time to provide feedback, share your thoughts and perspectives!

Community Engagement – April 2nd to April 30th

The Movement Charter Drafting Committee (MCDC) cordially invites everyone in the Wikimedia movement to share feedback on the full draft of the Movement Charter.

Let your voice be heard by sharing your feedback in any language on the Movement Charter Talk page, attend the community session today, on April 4th at 15.00-17.00 UTC, or email movementcharter@wikimedia.org. I will also be monitoring conversations on this talk page, to bring back the summaries to the ongoing global conversations.

You can learn more about the Movement Charter, Global Council, and Hubs by watching the videos that the Movement Charter Drafting Committee has prepared. Read the Committee's latest updates for more information about the most recent activities from the Drafting Committee.

Thank you again for your time and kind attention! I look forward to your input and feedback. Have a wonderful month of April! --KVaidla (WMF) (talk) 13:10, 4 April 2024 (UTC)[reply]

WP:CONLEVEL: "Consensus among a limited group of editors, at one place and time, cannot override community consensus on a wider scale."

Does this mean that local consensus cannot deviate from a guideline? Or, does said "community consensus on a wider scale" require a community consensus separate from the guideline, such as RfC? ―Mandruss ☎ 01:41, 6 April 2024 (UTC)[reply]

I suspect it wouldn't be hard to find two guidelines that would be impossible to comply with at the same time. PAGs offer many competing principles. That's why we have local consensus. And we are allowed to consider factors not covered by guidelines, as I understand it, since guidelines can't be expected to cover every possible situation. ―Mandruss ☎ 02:45, 6 April 2024 (UTC)[reply]

It's difficult to give a general answer, because while it is true that a consensus reached amongst a broader audience is presumed to be more representative of the community's viewpoint than the result of a discussion with a smaller number of editors, consensus can change. Additionally, specific circumstances can lead to different tradeoffs being made between competing guidance. If your question is with respect to the discussion at Wikipedia talk:Citing sources regarding including links to archived versions of sources, then I personally feel the most collaborative approach is to seek to change the broader guideline to consider cases where articles have a large number of citations. isaacl (talk) 03:14, 6 April 2024 (UTC)[reply]

I'd oppose that per CREEP, among other things. Local consensus is perfectly capable of handling exception situations. Anyway, I seek to clarify CONLEVEL vis-a-vis guidelines, which is a worthwhile clarification in my view. ―Mandruss ☎ 03:21, 6 April 2024 (UTC)[reply]

Generally, if a broad audience discusses a specific situation and a conclusion is reached, then a subset of that broader audience should respect that consensus. The result of that discussion can get captured on a guidance page. If the subset wants to put forth an argument that the captured result doesn't truly represent consensus, or that consensus has changed, then the editors in question can start a new discussion with the broader audience. isaacl (talk) 03:31, 6 April 2024 (UTC)[reply]

A very substantial part (most?) of our body of guidelines has been formed by unopposed BOLD edits on pages that relatively few editors have the time to follow on a regular basis. That does not constitute affirmative discussion by a broad audience. So it would be a mistake to assume discussion by a broad audience until proven otherwise (it would be prohibitively difficult to prove that a discussion doesn't exist). It makes more sense to assume the opposite until proven otherwise. In the specific case you mentioned, regarding including links to archived versions of sources, I've yet to see any community consensus—with or without discussion, let alone discussion by a broad audience—that things must be done that way. The guideline itself doesn't say that. ―Mandruss ☎ 04:01, 6 April 2024 (UTC)[reply]

Sure, like I said, specific circumstances affect what will be the best collaborative approach in a given case. However as per your request, I discussed the general approach: work with all interested parties to figure out the consensus view. isaacl (talk) 06:07, 6 April 2024 (UTC)[reply]

No problem with that, provided said work is done at the article's talk page where it belongs, and with respect for any local consensus reached there (with the option of bringing in outside voices by posting notices in other talk spaces). I've been suggesting that since at least 1 April,[2] and for some reason the other editor has refused to start said discussion. Starting it is the responsibility of the editor who seeks to change the existing consensus (I'm aware of only one), not those who support it. And we still lack clarification of CONLEVEL, which would inform said discussion. ―Mandruss ☎ 07:00, 6 April 2024 (UTC)[reply]

I have given my viewpoint on how broader levels of consensus supersede local discussions, and how if there is a dispute on whether or not a broad level of consensus has been achieved, then further discussion is necessary. Within English Wikipedia's decision-making traditions, as mentioned by other commenters, inviting a broader set of interested parties (including the local participants) is the key aspect, regardless of venue. isaacl (talk) 17:08, 6 April 2024 (UTC)[reply]

In the case of the specific dispute that sparked this discussion, there is no change to the guidelines required to accommodate the current situation, although it could be done. The relevant guideline language is "When permanent links aren't available, consider making an archived copy of the cited document when writing the article". Editors at the article's talk page have indeed considered it. And even making archived copies wouldn't conflict with what they decided to do, which was to not add them to the article itself. Nikkimaria (talk) 22:27, 6 April 2024 (UTC)[reply]

• Note - This discussion stems from Talk:Donald_Trump#Discussion_pointer and Local Consensus #25 there, and it's conflict with WP:CITE. The most relevant discussion is at Wikipedia_talk:Citing_sources#Talk:Donald_Trump_and_using_WP:LOCALCON_to_disallow_citation_archives. Soni (talk) 05:55, 6 April 2024 (UTC)[reply]

Such an absolute phrase is just idiotic, for lack of a better term. Of course everyone knows that what works for the community on a wide scale might not be the best choice every time. I think that, based on what ArbCom actually says, yes, local consensus cannot deviate from a guideline, but in practice that's stupid and dumb and editors need to use their brains. If a discussion or an RfC is able to show that slavish devoition to the tenet of some random PAG isn't a reasonable path, well, I would consider that an example of, per CONLEVEL, [convincing] the broader community that such action is right, which is enough to override any policy or guideline. Cessaune [talk] 08:03, 6 April 2024 (UTC)[reply]

If ArbCom meant the principle to apply to guidelines lacking separate community consensus, nobody has shown me that yet despite my request for that. The passage attributed to ArbCom in the WT:CITE discussion is Where there is a global consensus to edit in a certain way, it should be respected and cannot be overruled by a local consensus, and that seems both cherry-picked and ambiguous to me. ―Mandruss ☎ 08:19, 6 April 2024 (UTC)[reply]

Maybe the assumption is that all guidelines/policies were agreed upon by consensus, and such a consensus qualifies as a 'global' one regardless of whether or not the consensus actually had enough participation to be called a 'community' consensus? I don't know. Cessaune [talk] 08:26, 6 April 2024 (UTC)[reply]

I don't know either, but that would mean that all guidelines are bright-line "You must do this, per ArbCom." I find it very hard to believe that ArbCom would say that, hence my skepticism. We might as well convert all guidelines to policies. Not that all policies are 100% absolutes, either. ―Mandruss ☎ 08:42, 6 April 2024 (UTC)[reply]

It's perhaps worth reminding folks that this page is not for settling local content disputes, but for discussing larger, more important site-wide issues such as the meaning of CONLEVEL. That was my intent here, and it's why I avoided talking about the local dispute until it was mentioned by Isaacl. That local dispute is but one of the many potential future beneficiaries of this discussion. ―Mandruss ☎ 09:48, 6 April 2024 (UTC)[reply]

Yes, but if CONLEVELS applies, then there is no local content dispute to settle as a single page cannot decide to deviate from community norms agreed upon in a wider forum (policy or guideline). Also consider WP:NOTANARCHY. The MoS is a guideline, should individual pages get to decide to ignore style choices made by the wider community at the MoS with a local consensus?

To how strict are guidelines enforced, I’d say about equal to policies. The difference isn’t whether or not a local consensus or a WikiProject can overrule a PAG, more that a policy change generally requires significantly more discussion (an RFC, or trips through VPP/VPR; sometimes combinations of all three) than a guideline change (which can be made as simply as a talk page discussion or even a BOLD change that goes unchallenged and has defacfo acceptance via WP:SILENTCONSENSUS). —Locke Cole • t • c 10:09, 6 April 2024 (UTC)[reply]

if CONLEVELS applies, then there is no local content dispute to settle as a single page cannot decide to deviate from community norms agreed upon in a wider forum (policy or guideline). Key word: IF. Until I came here, I was willing for that IF to be answered in a local discussion, with the belief that ordinary editors can be trusted to read and interpret policies, to fairly consider opposing arguments (and there was always the possibility of an outside closer, who would be allowed to override the majority if they deemed that the minority had a stronger policy position). Now I'm willing for it to be answered here instead. If it doesn't get answered here, I fall back to local discussion. One place it should NOT be answered: WT:CITE. ―Mandruss ☎ 10:17, 6 April 2024 (UTC)[reply]

Key word: IF. Well to save you the trouble of waiting, ArbCom certainly thinks it applies. If a PAG has more strength than a WikiProject consensus (the example used by ArbCom) then surely a PAG cannot be overruled by a simple talk page consensus at a single random article. That way lies anarchy. —Locke Cole • t • c 10:44, 6 April 2024 (UTC)[reply]

ArbCom certainly thinks it applies - As I've previously said, here and at WT:CITE: Show me. That doesn't mean repeating that one ambiguous sentence you've quoted so far, and then applying your personal interpretation to it. It means linking to something where ArbCom explicitly said that CONLEVEL applies to guidelines lacking separate community consensus. Or, for that matter, even something they said that clearly implies that's what they meant. ―Mandruss ☎ 10:52, 6 April 2024 (UTC)[reply]

Words mean things. -fin —Locke Cole • t • c 11:01, 6 April 2024 (UTC)[reply]

-fin - If only! ―Mandruss ☎ 11:03, 6 April 2024 (UTC)[reply]

(edit conflict) Speaking generally, the purpose of guidelines is to provide general guidance that is expected to be interpreted with common sense and to which occasional exceptions may apply. A local consensus can determine that an exception should apply to a specific circumstance being discussed, but it needs to be understood that this is an exception that doesn't change the general guideline and it needs to be articulated why an exception is required for this case. If the feeling is that the guideline is wrong more generally than in occasional specific circumstance then broad community consensus to change the guideline is the correct way forwards - c.f. WP:IARUNCOMMON. Thryduulf (talk) 11:10, 6 April 2024 (UTC)[reply]

Agreed, but I see only one way to decide whether an exception is required (which is itself ambiguous). To wit: local consensus with the possibility of outside closure. ―Mandruss ☎ 11:30, 6 April 2024 (UTC)[reply]

I agree with Thryduulf completely. There has to be room for local consensus, since guidelines by definition have some exceptions. If those arguing for an exception can't articulate a way in which the situation is exceptional, then the outside closer should find in favor of the guideline's proponents. We commonly see arguments for an exception that are obviously just disagreement with the guideline, and experienced closers often notice and act accordingly. Firefangledfeathers (talk / contribs) 16:38, 6 April 2024 (UTC)[reply]

One thing to keep in mind… the location where a consensus was reached matters less than the number of participants who reached it. A consensus reached on an article’s talk page with lots of participants should be given more weight than a consensus reached on a guideline’s talk page that only involved two or three participants. Blueboar (talk) 12:01, 6 April 2024 (UTC)[reply]

Changes to article A (beyond non-binding blue-sky talk) are discussed at Talk:A. Do you disagree? ―Mandruss ☎ 12:15, 6 April 2024 (UTC)[reply]

Usually… but not always. Ultimately, it doesn’t matter where changes are discussed, as long as those who care about article A are notified, clearly pointed to the discussion and can participate. Blueboar (talk) 12:43, 6 April 2024 (UTC)[reply]

Bad idea imo. Years later, when editors want to review the discussion that formed a consensus, how are they expected to know to look for it in the archive of a guideline talk page? Is it not difficult enough to hunt it down in the article's archive? That's the general case. In the specific case at Talk:Donald Trump, it's not quite so bad. Its current consensus list could link to off-page discussions, although that would break the eight-year precedent. ―Mandruss ☎ 12:58, 6 April 2024 (UTC)[reply]

That’s what links are for. If there is a discussion on a policy/guideline page that relates to a specific article… we should post a notice at the article’s talk page linking to that discussion. Similarly, if there is a discussion at the article level that might impact a policy/guideline (say carving out an exception), we should post a notice at the policy/guideline talk page linking to that discussion.

Again, the important point to CONLEVEL is that a broad level of community involvement outweighs a limited level of community involvement. It’s not really about the specific location where that discussion takes place. Blueboar (talk) 13:50, 6 April 2024 (UTC)[reply]

You haven't said whether you think any given guideline should be assumed to have that broad level of community involvement, merely by virtue of its existence. As I've said, plenty of guideline content did not arise from discussion, let alone broad discussion. If not, CONLEVEL does not apply to guidelines lacking separate community consensus. That's the point of this discussion. ―Mandruss ☎ 13:59, 6 April 2024 (UTC)[reply]

The way to decide if it does have consensus or not is discussion, if no-one has ever objected to something it isn't possible to decide if it does or not. Editors could have never objected to it because they are in complete agreement, or because they never noticed that something had been changed. -- LCU ActivelyDisinterested «@» °∆t° 14:13, 6 April 2024 (UTC)[reply]

Ok, then that answers my question. CONLEVEL cannot be asserted for a guideline without that discussion, and presumably among more than a handful of editors who happen to show up at a guideline talk page and care to jump in. And we've established that the subject article must be notified at the start of the discussion, not two months later following a massive wall of discussion. ―Mandruss ☎ 14:28, 6 April 2024 (UTC)[reply]

It can be asserted, it can also be objected too. There isn't a simple answer to your question.
Absolutely more notification is always a good idea, and when taking a discussion to a more general location leaving a courtesy notification that you have done so is a good idea. -- LCU ActivelyDisinterested «@» °∆t° 15:00, 6 April 2024 (UTC)[reply]

Correct - we have very few musts… but many shoulds. When it comes to consensus, Wikilawyering over venues and notifications is rarely productive. Blueboar (talk) 15:12, 6 April 2024 (UTC)[reply]

In my view, notification is important enough to be one of the few musts. There is no should about notifying the subject of an ANI complaint, for example; you do it, or you get dinged for not doing it and are expected to do it in the future. And I mildly resent having that W-word directed at me, if that was your intent. ―Mandruss ☎ 00:15, 7 April 2024 (UTC)[reply]

Can be asserted, and has been asserted. When MEDRS was adopted as a guideline (through what was, at the time, a quite extensive and well-notified process; the WP:PROPOSAL process was based on what we did for MEDRS and MEDMOS), an editor claimed that the well-advertised RFC on its talk page was just a local consensus, and therefore the page couldn't be a guideline unless we changed it to say what he wanted (he wanted to cite more primary sources). But "you can claim it" isn't the same as "other editors will accept your complaint as legitimate". WhatamIdoing (talk) 04:17, 7 April 2024 (UTC)[reply]

Completely agree. Anyone can object and raise the question of whether any particular piece of guidance is correct, whether anyone will agree with them is an entirely different matter. It's similar to the misuse of IAR. Just because a particular editor believes ignoring a certain policy or guideline will improve the encyclopedia, doesn't mean that other editors will agree.
Convincing other you are right through discussion may still be required. -- LCU ActivelyDisinterested «@» °∆t° 12:39, 7 April 2024 (UTC)[reply]

Enough people closely watch policy/guidance pages that we can safely assume they have broad consensus… especially because almost every policy/guideline begins with a statement that exceptions will exist. I assume that also has broad consensus.

The real question comes when an exception is proposed: does that exception have broad enough consensus to be accepted? If only two or three editors think so, then no… if lots and lots do, then yes. Blueboar (talk) 14:39, 6 April 2024 (UTC)[reply]

I disagree with your logic, Blueboar. Any discussion at an article's talk page, no matter the number of participants, will be seen only by users who watch that page. I think it would be very rare for such a discussion to have been seen by more users than a discussion held at a noticeboard, village pump, policy, or guidance page. Any discussion that seeks to deviate from established policy or guidance in more than a trivial way needs to be advertised to the community at large. Donald Albury 15:31, 6 April 2024 (UTC)[reply]

I think the point is whether (and how well) it's been advertised. If it's held at a talk page, but has been widely advertised (noticeboards, village pump, projects, etc) then just because it's held at a talk page doesn't discount it. -- LCU ActivelyDisinterested «@» °∆t° 15:55, 6 April 2024 (UTC)[reply]

Meh… as a rule of thumb, yes… but a lot depends on the specific article and the specific guideline we are talking about. There are articles that have hundreds of watchers, and obscure guideline pages with only a handful of watchers.

That said, I would agree that advertising these discussions at related pages, noticeboards, village pumps etc is beneficial, as it will bring in a broader slice of the community. When seeking a consensus to make an exception to “the rules”… more is better. Blueboar (talk) 16:08, 6 April 2024 (UTC)[reply]

The assertion that Any discussion at an article's talk page, no matter the number of participants, will be seen only by users who watch that page is not true (due to Wikipedia:Requests for comment and links posted at village pumps, noticeboards, and Wikiprojects) and secondly not always material (because there are pages with more than a hundred current/active/watching-using editors watching them). WhatamIdoing (talk) 01:23, 7 April 2024 (UTC)[reply]

A consensus reached on an article’s talk page with lots of participants should be given more weight than a consensus reached on a guideline’s talk page that only involved two or three participants. I'd be careful going just off the numbers here. For example, Donald Trump (edit | talk | history | protect | delete | links | watch | logs | views) has more page watchers than Wikipedia:Citing sources (edit | talk | history | links | watch | logs), however, the people watching Donald Trump are likely more concerned with the article subject (either directly, or broadly as a businessman/politician/etc) than people watching the project page (which is more concerned with presenting a consistent experience for readers in both appearance, verifiability, and so on). And that's where we get into the details here: people concerned about the persistence of our sources in the form of citations aren't going to go to each individual article to wait for a discussion by editors there to try and circumvent a guideline created by the wider community. The onus, as explained by ArbCom, is for those people wanting to circumvent a wider PAG consensus is to go and hold that discussion with editors of the PAG. Mandruss only quoted the first sentence of WP:CONLEVELS, but the whole paragraph spells this out more clearly:

Consensus among a limited group of editors, at one place and time, cannot override community consensus on a wider scale. For instance, unless they can convince the broader community that such action is right, participants in a WikiProject cannot decide that some generally accepted policy or guideline does not apply to articles within its scope. WikiProject advice pages, how-to and information pages, template documentation pages, and essays have not gone through the policy and guideline proposal process and may or may not represent a broad community consensus.

Generally speaking, a WikiProject would be expected to have a wider view of the community than a single article talk page. Just because an article is popular with the people editing it, doesn't somehow make a decision reached there any more valid than one reached by fewer editors concerned with a broader topic applied globally at a PAG. —Locke Cole • t • c 18:01, 6 April 2024 (UTC)[reply]

So, are you suggesting that every local consensus that circumvents a PAG should be brought to the wider community? Just asking for clarification. Thanks! Cessaune [talk] 19:32, 6 April 2024 (UTC)[reply]

If it’s something that already has a wider community consensus, yes, of course. WP:NOTANARCHY. We’re not a democracy either but that isn’t an open invitation to ignore wider discussions/consensus and pretend they’re irrelevant (or in this explicit example, never even consider the guidance at WP:CITE). —Locke Cole • t • c 20:42, 6 April 2024 (UTC)[reply]

Alright. So, would you be willing to state that, in your opinion, for a group of people to invoke WP:IAR, they must first secure the approval of the wider community? Cessaune [talk] 23:26, 6 April 2024 (UTC)[reply]

WP:IAR works if doing so improves the encyclopedia. If the invocation of IAR does not receive at least an lmplicit consensus that has done so (i.e., if other users object), then we fall pack on P&G and seeking consensus. What we are discussing is the proper venue for discussing overturning or ignoring a P or G. Donald Albury 00:07, 7 April 2024 (UTC)[reply]

If a group of users acting in good-faith come to a consensus against a PAG for whatever reason, they have effectively invoked IAR, right? Many, dare I say every consensus is, at least according to the editors involved, a representation of the differing ideals and opinions of editors, consolidated into a single, reasonable opinion that represents 1) the aforementioned opinions of editors and 2) the best interests of the article; it satisfies the improving or maintaining clause IMO. I can't think of a consensus, in real life or in theory, that doesn't/wouldn't satisfy that clause. IAR is fundamentally relevant to this discussion.

IMO the question at play here is: does the invocation of IAR require the approval (consensus) of more than just an article talkpage worth of editors? Once that question is answered, picking venues is simply a matter of applying the IAR answer. Cessaune [talk] 02:02, 7 April 2024 (UTC)[reply]

WP:IAR is irrelevant in this specific instance for at least two reasons: It was not invoked in the discussions held at Talk:Donald Trump. And because WP:CITE/WP:DEADREF were not even considered, you cannot WP:IAR a rule you never even considered during the discussions. —Locke Cole • t • c 03:55, 7 April 2024 (UTC)[reply]

I think it's pretty clear that we have moved on to a much broader topic, as evidenced by the OP's question posted at the beginning of this thread. Unless I'm missing something. Cessaune [talk] 04:03, 7 April 2024 (UTC)[reply]

Possibly, but context is important and WP:IAR should only be used sparingly. If we're using IAR all the time, then there's something wrong with the broader WP:PAGs we have. —Locke Cole • t • c 20:26, 7 April 2024 (UTC)[reply]

Well, maybe there is. And IAR is a policy. It should be used carefully, not sparingly. Cessaune [talk] 20:58, 9 April 2024 (UTC)[reply]

No this is a mistake. A group of editors invoking IAR is fine, but that doesn't mean it can't be questioned. If a larger consensus goes against them then they are no longer invoking IAR but just "I don't like it". IAR is for improving the encyclopedia, if the consensus of a larger group is that you are not improving the encyclopedia than IAR doesn't count. -- LCU ActivelyDisinterested «@» °∆t° 15:48, 7 April 2024 (UTC)[reply]

Yes, of course it can be questioned. That's how consensus works. But I'm asking whether such a local consensus doesn't count unless brought to the larger group. Cessaune [talk] 19:55, 7 April 2024 (UTC)[reply]

I would say it counts until it is questioned and brought to a larger group. Blueboar (talk) 20:10, 7 April 2024 (UTC)[reply]

Yes, exactly. Cessaune [talk] 22:02, 7 April 2024 (UTC)[reply]

Consensus among small groups of editors is outweighed by consensus of a larger group of editors, which could in turn be outweighed by a consensus of an even larger group of editors.
In general discussions should happen in places relevent to the issue, but they don't have to. If a discussion happens at a slightly odd location, but is widely advertised and well attended it shouldn't be discounted jusy because of it's location.
If there is disagreement about what should happen, then as with everything else the solution is discussion.
To the specific question, local consensus shouldn't deviate from guidance / policy that has general community support. Does it have general community support, or was it silently add and no-one noticed? Is the policy / guidance correct, or does it need to be updated? Yep you guessed it the solution is discussion. -- LCU ActivelyDisinterested «@» °∆t° 14:08, 6 April 2024 (UTC)[reply]

I agree, and you've reminded me that the "small group of editors" concept was at one time connected to WP:Consensus can change. Specifically, if a couple of editors make a decision on a talk page, that's fine (we do that all day long!), but if/when the "larger community" shows up to re-discuss it, then we may (or may not!) find that the second/larger group's decision is different from the first/smaller group's decision. WhatamIdoing (talk) 04:21, 7 April 2024 (UTC)[reply]

Basically, should a content-dispute concerning the Donald Trump page, be handled at that article's talkpage, thus getting local consensus? or at the appropriate Village Pump page, thus getting a broader consensus. GoodDay (talk) 16:43, 6 April 2024 (UTC)[reply]

Doesn’t matter… choose one and advertise the discussion at the other with a link. The venue (ie page) where a discussion takes place isn’t what makes a consensus “local” vs “broad”. That is determined by how many editors are involved in the discussion. Blueboar (talk) 17:10, 6 April 2024 (UTC)[reply]

See my reply above about why numbers shouldn't be a factor, but if numbers are to be the deciding factor, yes, such discussions need to be advertised to those interested in the topic (in this case, citations having archive links banned). —Locke Cole • t • c 18:06, 6 April 2024 (UTC)[reply]

CONLEVEL and guidelines: Going meta[edit]

According to this discussion to date, Locke Cole and I have both been wrong on multiple important points. I won't attempt to enumerate them: (1) I'm not keeping score, and (2) they should be clearly apparent to any objective eye.

My main takeaway, which actually just confirms what I already knew: It's a sad reflection on the state of en-wiki PAGs that two very experienced editors can differ to such a degree (and can both be wrong!). This is the biggest barrier to entry in my view; en-wiki seems designed to drive new editors mad, and it was driving this editor mad until I semi-retired out of a need for self-preservation.

I don't expect this to change in our lifetimes, if in en-wiki's lifetime. It would take a cataclysmic, Armageddon-ish intervention by WMF, against massive opposition and with experienced editors quitting in droves. Once one has somewhat mastered the labyrinth (or believes they have), they are strongly invested in it and will do whatever they can to protect it. They like the position of seniority it provides. This is not casting wide aspersions, it's just acknowledging human nature, which is highly flawed at this early date. ―Mandruss ☎ 02:33, 7 April 2024 (UTC)[reply]

I agree that our ruleset empowers some of us at the expense of others of us. Those of us who have the practical power are not motivated to fix that, because we believe it would remove some of our power.

For example, consider the many discussions about WP:ONUS vs WP:QUO/WP:NOCON (e.g, the recent Wikipedia:Requests for comment/When there is no consensus either way). We agree that ONUS says I can delete cited material that doesn't have consensus to keep it, and we agree that NOCON says that we usually keep longstanding cited material unless there is a conensus to remove it. So if there's no consensus, and I want to remove it, I can say "Sorry, no consensus means ONUS applies and it gets removed", but if there's no consensus and I want to keep it, I can say "Sorry, no consensus means NOCON applies and it gets kept".

Either way, I can get my way, and only someone equally familiar with the rules will know that the opposite rule exists – and there are very few such people in the world. WhatamIdoing (talk) 04:37, 7 April 2024 (UTC)[reply]

Since you asked (woops, you didn't), here's what a solution would look like. This is just pointless blue sky, which is my forte (it tickles my neurons). It's about as worthwhile as debating whether we're living in a simulation, but many strange people are doing that.

Massive overhaul of PAGs, with more emphasis on simplicity and streamlining, eliminating many of the thousands of little complexities ("improvements") that the encyclopedia doesn't really need to do a good job of serving its readers. Also eliminating contradictions in PAGs wherever possible. Basically a large-scale "reverse CREEP" movement, with an imaginary big banner reading Perfect is the Enemy of Good., maybe with an imaginary pipe to KISS principle.

This would be beyond the capacity of the usual self-selected discussion/consensus (Village Pump) model, as we would be bogged down in interminable debates about minutiae for fifty years (nay, we would abandon it long before then, when we noticed that we were only ten percent done after five years).

What it would take would be a committee of perhaps eight very senior editors who (1) understood the goal, (2) were completely on board with the goal, (3) had sufficient room in their lives to work on the project, and (4) had WMF-mandated carte blanche. They would have, say, two dozen less-experienced editors "working for them", who would be tasked with the actual edits to the PAGs. Maybe it could be organized as a WikiProject. Unhappy editors would take Xanax, figuratively speaking (or literally speaking), or take early retirement. If well-planned and well-organized, and if the queen bees and worker bees spent half their time on it, I think it could be completed within five years. Hell, I'd volunteer as a worker bee, finding new purpose in my wikilife.

Of course, all editors would have learn the new PAGs, although the main points of major content policies like V, NPOV, and BLP would remain essentially the same. In effect, NPOV would become "NPOV Lite", etc.

Following paragraph inserted after replies. I don't care to underscore the whole thing per REDACT. Sue me.
Would it be disruptive? You bet. All change is disruptive to some degree, in proportion to its magnitude, and this change would have plenty of magnitude. The proper question is not whether a change would be disruptive, or how disruptive it would be, but whether the benefits are worth the disruption. In my experience, we tend to focus on the downside of a proposed change instead of fairly weighing it against its upside. This is a result of a natural, usually unconscious resistance to change.

It would be a departure from how WP has always done things, putting so much power in the hands of so few. It would also be the only way to achieve the goal. It's not like there is no precedent for such a departure; see ArbCom.

But, as I said, this could never happen if it required community consensus. ―Mandruss ☎ 09:33, 7 April 2024 (UTC)[reply]

I don't believe it's necessary that we all agree, or that it would be a good thing if we did. If that was the case the policies and guidelines would never have changed since they were first written. Disagreement leads to confirmation or change, either way will likely be an improvement.
I very much doubt that policies rewritten by dozen editors would lead to less arguments. Even the idea of a WMF mandate to rewrite the policies would cause disagreement on a very large scale. -- LCU ActivelyDisinterested «@» °∆t° 13:02, 7 April 2024 (UTC)[reply]

Of course. There is no shortage of reasons not to do this. I've always believed in short-term pain in return for long-term gain, I can't help it. In my view, the trauma would pay big dividends in the long term. Less arguments - editors should be arguing about content, not PAGs. We're arguing about PAGs because PAGs are far too complex and confusing, and unnecessarily so. We're wasting far too much time that could be spent considering content questions, and the encyclopedia is suffering as a result. I think PAGs could be made simple enough that potential new editors are not staying away in droves, and that PAGs could be pretty well mastered in 2–3 years of editing at an average rate.

It feels weird trying to sell something that I know would never fly, simply because WMF would never provide the mandate. We're just havin' fun here, right? ―Mandruss ☎ 13:27, 7 April 2024 (UTC)[reply]

One thing I have noticed over my many years as a Wikipedian is that the community has shifted how it interacts with our P&G pages. We used to be more focused on “the spirit of the law” (exploring the intent behind a particular rule, and asking whether that intent applies in a given situation). Now, we focus more on “the letter of the law” (noting what a particular rule says, and asking how to apply it in a given situation). It would be nice if we could again focus more “spirit” and less on “letter”. Blueboar (talk) 14:54, 7 April 2024 (UTC)[reply]

It's a consequence of trying to use consensus-based decision making. Consensus only works when there is a strong alignment in the goals of everyone involved. This very quickly becomes impossible as a group grows in size. As Clay Shirky wrote in "A Group is its Own Worst Enemy", this leads to the group trying to codify its rules in greater detail, and eventually they get too complex, and the group chooses a new way to make decisions. The community is too large for everyone to have the same spirit. For it to be guided more by spirit, it either would have to get a lot smaller, or enact more hierarchy in its governance to provide this guidance. isaacl (talk) 15:18, 7 April 2024 (UTC)[reply]

Erm, consensus, doesn't work?? What we all doin here, ma man? It might not work from time to time, there might be some zig and zag but it kinda works eventually or we would never have any articles in contentious areas. Selfstudier (talk) 15:33, 7 April 2024 (UTC)[reply]

Most discussions involve a small number of people. As long as they remain in strong alignment of goals, they can reach an agreement. It doesn't scale up well as the group of people in the discussion gets larger. Guidelines and policies are supposed to reflect the community viewpoint and so require broad support. But I've had a hard time finding policies that weren't largely written by a small number of people long ago, before the codification of the life cycle of policies and guidelines. Contentious areas continue to remain contentious, with the community relying mainly on editor behaviour becoming sufficiently disruptive that they are restricted from editing within the area in question. The same disputes are re-argued with the same points, and major change to guidance is stalemated. isaacl (talk) 16:03, 7 April 2024 (UTC)[reply]

Elections work, they are scaled up consensus, same again, perhaps the result is "wrong" but it can be fixed next time around. And if change is stalemated, maybe that is the consensus. Selfstudier (talk) 16:14, 7 April 2024 (UTC)[reply]

Elections are voting, which isn't the same. If Wikipedia guidelines were established by voting, then the stalemate would be broken. Within the context of this discussion thread, voters in a dispute would be free to vote on the basis of the spirit of guidance. With English Wikipedia's decision-making traditions, though, the evaluation of consensus is filtered through considering if expressed opinions are inline with guidance. This leads to arguments on the letter of guidance. isaacl (talk) 16:29, 7 April 2024 (UTC)[reply]

This leads to arguments on the letter of guidance. I agree with this but I don't think it is a bad thing, there is scope to argue every side of an issue and I don't think that should be restricted at all. An election is only a up/down vote after all the arguing that goes on beforehand, so the effect is not that different. Selfstudier (talk) 16:48, 7 April 2024 (UTC)[reply]

Sure; the point was in response to Blueboar as to why English Wikipedia's current decision-making traditions lead to more focus on the letter of guidance versus the spirit. Regarding elections, they're considerably different than the current consensus-determining discussions, because people can just drop in and vote without discussion (such as what happens with the arbitration committee elections), and there's no evaluator of consensus filtering the expressed viewpoints. isaacl (talk) 17:07, 7 April 2024 (UTC)[reply]

I agree that the PAGs (and MOS) could use simpler language, but I doubt rewriting them will have that effect. It will instead mean that in any area of disagreement or ambiguity a specific side is chosen, and so to more arguments. -- LCU ActivelyDisinterested «@» °∆t° 15:54, 7 April 2024 (UTC)[reply]

Perhaps, there's too many rules. This will increase the chances of overlapping & contravening. GoodDay (talk) 16:37, 7 April 2024 (UTC)[reply]

How we got here[edit]

I've had a couple of discussions during the last year about LOCALCON, and I usually find that nobody agrees what it means, except that it's always the other editor who's wrong: This section is always invoked by someone who feels they "lost" a discussion, in an attempt to prove that the apparent agreement does not "legally" count and they still win anyway, and those editors will re-define "local" to mean anything that means they "win" (This is insight is not originally mine.)

I wrote part of LOCALCON, so I can speak to the meaning that I intended, but the idea goes way back to when I was a new editor. Perhaps these notes will help:

A few milestones[edit]

What the policy originally said (January 2007)

Consensus decisions in a specific case cannot override existing project-wide policy.

First major revision (July 2007) This form didn't last long, but the discussions had other influences later

Consensus on Wikipedia always means, within the framework of communal consensus, as documented by established policies and practice. Consensus never means "whatever a limited group of editors might agree upon", where this contradicts policy and practice. [...]

Even strong opinions and strong support expressed in specific polls, almost never change the need to abide by communally-agreed policies, guidelines and practices. Consensus on a small scale is not expected to override consensus on a wider scale very quickly (such as content-related policies/guidelines).

Example: 4 editors who strongly agree on some viewpoint end up dominating discussion on the article's talk page. Even if they all agree, and are all sure they are right, and all sure other editors are wrong, they cannot override the requirement of policy to represent the opposing views neutrally and fairly, because the community has indicated a very high level of consensus that this is non-negotiable.

Addition of WikiProjects as the primary example (August 2007)

Consensus decisions in specific cases are not expected to override consensus on a wider scale very quickly - for instance, a local debate on a Wikiproject does not override the larger consensus behind a policy or guideline. The project cannot decide that for "their" articles, said policy does not apply.

The (basically) re-arranging I did in 2009

"Consensus" between a small number of editors can never override the community consensus that is presented in Wikipedia's policies and guidelines; instead, consensus is the main tool for enforcing these standards. The focus of every dispute should be determining how best to comply with the relevant policies and guidelines. Editors have reached consensus when they agree that they have appropriately applied Wikipedia's policies and guidelines, not when they personally like the outcome. (The "small number of editors" language had been used previously, both to endorse small groups of editors making decisions about how to implement various policies in specific articles and also to prohibit them from declaring "their" articles exempt from the usual policies.)

What the relevant part currently says

Consensus among a limited group of editors, at one place and time, cannot override community consensus on a wider scale. For instance, unless they can convince the broader community that such action is right, participants in a WikiProject cannot decide that some generally accepted policy or guideline does not apply to articles within its scope.

A few notes[edit]

The problem that section is supposed to solve

Imagine that we could poll the entire community, and we found 100% agreement about a general principle (e.g., "all material must be verifiable"). It is not feasible to do that for every little decision. For example, we can all agree that all material must be verifiable, but disagree over whether or not a given source actually verifies a specific bit of material in the article. A decision that "X" cited source adequately verifies "Y" material in the article – even if some editors disagree – is not the problem that LOCALCON is trying to solve. The problem we're trying to solve is a handful of editors claiming that material about their favorite subject is actually exempt(!) from the core content policies (or, more commonly, from various aspects of the MOS) just because they all agreed to exempt their subject area from those pesky requirements. The problem is not people having discussions about how to best apply the policies and guidelines to specific subjects. It's even okay if those discussions are small and unadvertised. The problem we need to solve is people thinking that they can "agree" to put (e.g.,) non-neutral content into an article because they don't think the NPOV policy should be applied to all articles (e.g., because it's too mean to tell people that babies get fatal diseases, or because they want to use the article for some geopolitical protest, or because putting the LD₅₀ facts in an infobox for a chemical might result in someone dying, or because accurately describing a side effect might result in someone refusing medical treatment, or whatever Wikipedia:Righting Great Wrongs goal concerns them).

Some of the key discussions leading to the current state

• Wikipedia talk:Consensus/Archive 3#Local or global consensus in 2007 (first significant discussion after adding the first version). The question about such a concept as "local consensus" is Can the editors of an article agree that the article ignore particular guidelines? See also What if...the only comments...are the gist of "I don't the agree with the guideline" and not anything about why it doesn't fit in a particular scenario?
• Wikipedia talk:Consensus/Archive 3#Added section: Consensus on Wikipedia in 2007 (first significant discussion on how to word it) This identifies a goal of comparing localized consensus (article debate) with communal consensus (policy), specifically that a discussion on an article talk page isn't good enough to declare that "your" article is exempt from a policy.
• Wikipedia talk:Consensus/Archive 3#What I think "Consensus vs. supermajority" should say in 2007 (first time WikiProjects are named in this context) Related comment in another section: It may not be the best wording, but the point is important. An individual wikiproject, or group of editors working on an article, cannot meaningfully choose to override important policies or guidelines just because they want to, because their "small consensus" is assumedly overridden by the "Wikiwide consensus" in support of the policy/guideline.
• Wikipedia talk:Consensus/Archive 8#"Purpose of Consensus" about a short-lived attempt in 2009 to remove my version, with comments like A small group, at no time, can summarily override established consensus/policy on a case-by-case basis because they want to. The wording may not be perfect, but the idea is basically "true". No minority can self-appoint their decision over a wider group on Wikipedia.
• Wikipedia talk:Consensus/RfC in 2010, in which WikiProjects are told they can't defy the MOS and accessibility guidelines to make colorful tables in "their" articles
• Wikipedia talk:WikiProject Composers/Infoboxes RfC in 2010, in which a particular WikiProject is told that they can't prohibit infoboxes in "their" articles (and WP:ADVICEPAGE is determined to have the support of the community)
• Wikipedia talk:Consensus/Archive 16#CONLIMITED may need expansion in 2013, with the comment "Local consensus" is not necessarily problematic. It's only problematic when it conflicts with community consensus...Local consensus is how most decisions are made. Includes discussion about whether, instead of "local consensus" vs "community consensus", we should be clearer (e.g., perhaps saying something like "a decision made by a small group of editors in an unadvertised discussion" vs "written policies and guidelines" or "widespread practices among experienced editors")
• Wikipedia talk:Consensus/Archive 19#some issues regarding WP:CONLEVEL from 2015 – the problem of guidelines becoming out of date. The One True™ Policy (according to WP:NOT and WP:PG is what the community actually does in practice. Sometimes our written policies and guidelines are out of date (e.g., the content policies technically permit editors to create articles that do not include any sources at all, but in practice the Wikipedia:New pages patrol rejects nearly all uncited articles. Ergo, our real policy, in practice, is that you've got to cite something, even though our written policies don't say that for non-BLP subjects – yet. If a couple of editors decide to require citations in a given article, their decision may be better aligned with the community's current practice than the written policies and guidelines.).
• Wikipedia talk:Consensus/Archive 20#Request for Comment - add subsection to WP:Local consensus about consensus levels in 2017, to add some definitions (implicit consensus [i.e., nobody reverted you] vs "Local consensus, among a small number of contributors regarding one or several pages" vs "broader community consensus", which linked to Wikipedia:Consensus#By soliciting outside opinions). Rejected as unnecessarily WP:CREEPY.
• Wikipedia talk:Consensus/Archive 23#CONLEVEL as any level that agrees with me 2023 attempt to get a definition (so we can stop editors from claiming that well-attended, CENT-listed RFCs don't count because any discussion that doesn't agree with me is just "local".

I have been meaning to assemble the history of this section, with an eye towards reducing the number of contradictory things said about it, for some time. I hope this is a little helpful to at least one editor. WhatamIdoing (talk) 04:11, 7 April 2024 (UTC)[reply]

Thanks for compiling all of that. I am always interested in seeing how policy points have evolved over time - in both language and interpretation. Blueboar (talk) 11:59, 7 April 2024 (UTC)[reply]

Also appreciate the historical perspective, thank you. —Locke Cole • t • c 20:56, 7 April 2024 (UTC)[reply]

1. WP:USEENGLISH says If there is no established English-language treatment for a name, translate it if this can be done without loss of accuracy and with greater understanding for the English-speaking reader.
2. WP:DONTUSEENGLISH says It can happen that an otherwise notable topic has not yet received much attention in the English-speaking world, so that there are too few sources in English to constitute an established usage. Very low Google counts can but need not be indicative of this. If this happens, follow the conventions of the language in which this entity is most often talked about (German for German politicians, Turkish for Turkish rivers, Portuguese for Brazilian municipalities etc.).

The status quo would be that we should follow WP:USEENGLISH, per WP:POLCON which tells us: If policy and/or guideline pages directly conflict, one or more pages need to be revised to resolve the conflict so all the conflicting pages accurately reflect the community's actual practices and best advice. As a temporary measure during that resolution process, if a guideline appears to conflict with a policy, editors may assume the policy takes precedence.

However, this conflict has been noted at the RM at Talk:Political Party for Basic Income#Requested move 28 March 2024, and it would be useful to resolve it.

@Tristan Surtel, 162 etc., Necrothesp, ModernDayTrilobite, and Andrewa: Notify editors who have participated in that discussion. BilledMammal (talk) 04:55, 7 April 2024 (UTC)[reply]

The first sentence you quoted appears in Wikipedia:Article titles § Foreign names and Anglicization and not the page to which you linked. The section also contains the second sentence you quoted, with a "See also" link to the second page you linked, Wikipedia:Naming conventions (use English) § No established usage in English-language sources, so all of it is nominally policy. Looking at a slightly broader excerpt, the page states: If there are too few reliable English-language sources to constitute an established usage, follow the conventions of the language appropriate to the subject (German for German politicians, Portuguese for Brazilian towns, and so on). For lesser known geographical objects or structures with few reliable English sources, follow the translation convention, if any, used for well known objects or structures of the same type e.g. because Rheintal and Moseltal are translated Rhine Valley and Moselle Valley, it makes sense to translate lesser known valley names in the same way. For ideas on how to deal with situations where there are several competing foreign terms, see "Multiple local names" and "Use modern names" in the geographical naming guideline. Such discussions can benefit from outside opinions so as to avoid a struggle over which language to follow. . . . In deciding whether and how to translate a foreign name into English, follow English-language usage. If there is no established English-language treatment for a name, translate it if this can be done without loss of accuracy and with greater understanding for the English-speaking reader.

Thus the overall context is to use established usage in English-language sources, and if there is none, follow the translation convention appropriate for the subject and language. If there is no established convention, then the name can be translated if it can be done without loss of accuracy and provides greater understanding for English readers. isaacl (talk) 05:23, 7 April 2024 (UTC)[reply]

Rereading the relevant quotes and policies, I find myself agreeing with isaacl's interpretation. I think the confusion stems from the phrasing of follow the conventions of the language in which this entity is most often talked about - some editors (including me, earlier) have parsed this passage as saying "use the language in which this entity is most often talked about", but on closer review I believe isaacl is correct that the passage intends to convey "follow the precedents for translating the names of other entities that with this language." To put it another way, WP:DONTUSEENGLISH doesn't necessarily tell us not to use English: it tells us to follow the lead of other analogous subjects that do have established usage in Anglophone sources, which may or may not be in English depending on the specific case.

To clarify this seeming mismatch in the policy language, I think the text currently at WP:DONTUSEENGLISH should be expanded with more detail on what "follow[ing] the conventions" entails. Copying over the Rheintal/Moseltal example from WP:UE, and contrasting it against an example such as the Brazilian-towns case, would probably be the best way to make the situation clear; this would show that using the native name may or may not be preferable, depending on general practice within the class of articles. (This approach would also be in conformance with the existing policy at WP:CONSISTENT.) ModernDayTrilobite (talk • contribs) 14:11, 10 April 2024 (UTC)[reply]

Currently, the status quo for events listed on the main page is to use the present tense, even if the event in question has definitively ended. I didn't really notice this was an issue until yesterday when I noticed that the main page said that the Solar eclipse of April 8, 2024 is visible through parts of North America. Knowing that it was not currently visible and double checking that the article referred to the event in the past tense, I changed this to was visible. [3] I did not realize that this is against the current consensus at WP:ITNBLURB which says that these events must always be described in the present tense. If one is interested in further background, I encourage them to read this discussion here (scroll down to errors).

I think that this status quo is misleading to readers because it cases like this, we are deliberately giving inaccurate and outdated information. I believe this is a disservice to our readers. The eclipse is not visible anymore, yet we must insist that it is indeed visible. I think that we should also be consistent... If the article for a blurb is using the past tense, we should use the past tense on the main page. Therefore, I propose that events listed on ITN that have definitively ended should be described in the past tense if it would otherwise mislead readers into thinking an event is ongoing. Clovermoss🍀 (talk) 11:33, 10 April 2024 (UTC), edited 17:00, 10 April 2024 (UTC)[reply]

Note: Notification of this discussion was left at Wikipedia talk:In the news.—Bagumba (talk) 12:00, 10 April 2024 (UTC)[reply]

I propose that events listed on ITN that have definitively ended should be described in the past tense: But any blurb can be written in the past tense, e.g., a country was invaded, an election was won, a state of emergency was declared, etc. So if we did go to past tense, I don't understand why there is a distinction with needing to have "definitively ended".—Bagumba (talk) 12:07, 10 April 2024 (UTC)[reply]

I made the distinction because I felt our current approach was the most jarring in situations where we're literally misleading the reader. I don't really have any strong preferences either way on other situations and felt like it'd be for the best to make sure my RfC was clear and not vague. I'm not trying to change every blurb at ITN right now, hence the "definitive end date" emphasis. If someone wants more broader changes to verb tense at the main page, I'd say that warrants its own separate discussion. Clovermoss🍀 (talk) 12:16, 10 April 2024 (UTC)[reply]

Note The blurb currently reads A total solar eclipse appears across parts of North America[4]—Bagumba (talk) 12:33, 10 April 2024 (UTC)[reply]

I was about to suggest a rewording along these lines… so that the blurb is accurate while maintaining present tense. Blueboar (talk) 12:45, 10 April 2024 (UTC)[reply]

It's better than flat out saying visible, but this phrasing still implies that it is visible? Present tense when an event has ended implies that an event is still ongoing. Clovermoss🍀 (talk) 16:22, 10 April 2024 (UTC)[reply]

Support per nom, see no reason to oppose. Aaron Liu (talk) 13:19, 10 April 2024 (UTC)[reply]

Per below, there isn'ta clear way forward for this one. On one hand, "Liechtenstein wins the FIFA World Cup" should definitely remain that way, but this also causes situations like these. Maybe something like unless this wording directly encourages a misleading interpretation that the event is still ongoing., using an earthquake in present tense and this event in past tense as examples. Or maybe we should just IAR such cases. Aaron Liu (talk) 16:30, 10 April 2024 (UTC)[reply]

I don't think IAR is going to work as long as we don't have an explicit exemption because it'd be causing someone to explicitly go against consensus for their own ends. I switched the wording to "was visible" out of ignorance in regards to current standards, not because I was deliberately ignoring them. I think there might have been much more ado made about my actions if I had done this with a justification of IAR. I don't have issues with your proposed wording, because again, my biggest issue with all of this is intentionally misleading readers. Clovermoss🍀 (talk) 16:39, 10 April 2024 (UTC)[reply]

@Aaron Liu: I've changed the proposal to have "if it would otherwise mislead readers into thinking an event is ongoing". Does that address your concerns? Clovermoss🍀 (talk) 17:03, 10 April 2024 (UTC)[reply]

Support, though I find isaacl's alternative of including a time frame intriguing. Aaron Liu (talk) 17:11, 10 April 2024 (UTC)[reply]

Comment for a lot of blurbs, the present tense is fine, as it continues to be true. e.g. elections, "X is elected leader of Y" is correct and better than past tense, and same with sports matches that end up on ITN. A blanket change to past tense is disingenuous therefore, although swapping to past tense for events that happened (and aren't ongoing) seems somewhat reasonable. Joseph2302 (talk) 13:55, 10 April 2024 (UTC)[reply]

Isn't "Is elected" past tense? Though I agree that for situations where we can use the active voice, "Z legislature elects X as leader of Y" sounds better. Aaron Liu (talk) 14:05, 10 April 2024 (UTC)[reply]

"Is elected" is present tense, specifically present perfect. "Elects" is also present tense, simple present. Levivich (talk) 18:14, 10 April 2024 (UTC)[reply]

I think for time-bound events such as the eclipse, including a time frame would be the best approach to avoid confusion. Additionally, I think using past tense is fine. isaacl (talk) 17:09, 10 April 2024 (UTC)[reply]

I am in favor of past tense for everything. "Won the election," or "landslide killed 200" or "eclipse appeared" all read as fine to me. Newspapers using present tense makes sense because they publish every day (or more often). It doesn't make sense for ITN where items stay posted for days or weeks. Levivich (talk) 18:10, 10 April 2024 (UTC)[reply]

Something about ITN mostly using present tense just feels... righter. Regardless of staying posted for weeks, they are all quite recent compared to most other stuff we have on the main page. Also see historical present. Aaron Liu (talk) 20:30, 10 April 2024 (UTC)[reply]

• Decide case-by-case: we can safely IAR in most cases. Cremastra (talk) 19:43, 10 April 2024 (UTC)[reply]
• No special rules for the main page: use the same tense we would in articles. We are an encyclopedia not a newspaper. (t · c) buidhe 20:37, 10 April 2024 (UTC)[reply]
• Object The present tense serves us well. It is the standard tense for headlines, certainly within the UK and I believe US too (though some MoS in the US is very different to the UK). I can't see anything in the proposal beyond change for the sake of change. doktorb _words^deeds 22:00, 10 April 2024 (UTC)[reply]

  Again, it is confusing to say that the solar eclipse is in the sky. Aaron Liu (talk) 22:05, 10 April 2024 (UTC)[reply]

  It would be confusing to switch from "is....was....did....has" in a single box on a typical ITN week. doktorb _words^deeds 22:28, 10 April 2024 (UTC)[reply]

Editors are sometimes paid to improve articles for their employer, or to remove false information from their competitor's articles. This is fine as long as these are following policy. A frustrating case is when a paid editor submits edit requests to fix false information about their competitors, but has no inclination to fix this exact same information in the articles for their employer. When asked to do so, they replied that they likely wouldn't ask they weren't compensated to do that. I am not linking the user here because they didn't do anything wrong according to our current policies. In order for Wikipedia to be free from promotion, paid editors should not turn a blind eye to information they have admitted is false if it benefits their employer to do so.

I think this suggestion is definitely in line with Wikipedia's mission, but enforcement might be difficult. I'm not suggesting that paid editors need to make their employer's articles perfect before they can change anything else; instead, I'm suggesting that when paid editors are arguing for specific claims to be removed from some articles, they should do due diligence to make sure that articles for their employer don't have those exact same claims. Mokadoshi (talk) 17:37, 10 April 2024 (UTC)[reply]

PAID (or COI in general) effects both the company/subject that they are associated with, but also potential competitors. We can't exactly suggest that any editor make changes (or, edit requests in this case) about any article. Lee Vilenski ^{(talk • contribs)} 18:08, 10 April 2024 (UTC)[reply]

It sounds like the unidentified editor is a paid editor. If so, they are required to make the necessary disclosure. Once they have done so, they aren't really deceiving other editors when they make (or don't make) edit requests. Other editors are free to evaluate the edit requests in that context, and to approve/deny the requests based on what the correct editing decision is, regardless of who made the request. And if their pattern of requesting causes other editors to scrutinize their own company's page, those other editors are free to edit the company page for NPOV, regardless of whether the paid editor does it. --Tryptofish (talk) 22:12, 10 April 2024 (UTC)[reply]

No policy or guideline can compel anyone to edit. If an uninvolved editor wrote a Wikipedia biography claiming that I'd won ten Olympic golds and a Nobel Prize, you couldn't make me fix it, though I hope that someone else would soon do so. Certes (talk) 22:58, 10 April 2024 (UTC)[reply]

It's more like if you were paid to correct articles with false claims to Olympic medals, and you've submitted requests to do so (which asks the community of their time to review them), but you're not interested in fixing any false claims that benefit you to ignore. It sucks when people only care about neutrality on Wikipedia when it personally benefits them, but maybe you're right that it's not a behavior that policy can or should change. Mokadoshi (talk) 23:41, 10 April 2024 (UTC)[reply]

In my experience with dealing with paid editing when reviewing articles, in unblock requests or at AN/I and WP:COIN, the vast majority of actual paid editors who engage in unconstructive, biased editing on Wikipedia do so without disclosing that they are paid editors, and are sanctioned on the basis that they didn't disclose their paid status properly. COI editors who comply by the letter of the relevant policies and guidelines are a non-problem. _signed, Rosguill ^talk 23:52, 10 April 2024 (UTC)[reply]

You're right. I should be grateful that they are going through the proper channels instead of performing undisclosed paid editing. If making the policy more onerous makes even just one paid editor decide to not go through the proper channels, that would be a step in the wrong direction. Mokadoshi (talk) 00:21, 11 April 2024 (UTC)[reply]

You can only even ask a PAID editor to fix errors in their employer's articles if you've already identified said errors... in which case, it's easier for you to fix them than to require the other editor to make an editing request which then may be fulfilled only with struggle. That, and the general belief that fixing problems is good and adding unneeded hoops to jump over in order to do so is bad, lead me to reject your suggestion. -- Nat Gertler (talk) 23:27, 10 April 2024 (UTC)[reply]

The present norms we have toward paid editors (ultimately falling back on our content policies as most important but usually with nigh-explicit contempt, as they fundamentally aren't here for the same reasons we are, while keeping in mind they may not want to be here either) is exactly the level of active time we should spend on them. Any more time other editors who want to build an encyclopedia have to spend conversing with or monitoring paid editors is certainly time better spent elsewhere. Remsense诉 00:03, 11 April 2024 (UTC)[reply]