This is the Village pump (all) page which lists all topics for easy viewing. Go to the village pump to view a list of the Village Pump divisions, or click the edit link above the section you'd like to comment in. To view a list of all recent revisions to this page, click the history link above and follow the on-screen directions.
Discussions older than 7 days (date of last made comment) are moved to a sub page of each section (called (section name)/Archive).
Policy
Petition to amend ARBPOL making it clear they have jurisdiction over crats
The purpose of this discussion was to determine whether to amend the arbitration policy such that it expressly states the already widely accepted view that the Arbitration Committee has the authority to remove bureaucrat permissions as part of its responsibility under Wikipedia:Arbitration/Policy § Scope and responsibilities #3 to handle requests (other than self-requests) for removal of administrative tools. In order to advance to the ratification phase of ARBPOL's formal amendment procedure, this petition requires signatures from "at least one hundred editors in good standing". Because 100 signatures have not been received in a reasonable amount of time, I am going to go ahead and close this petition out as unsuccessful. To be clear, there is a clear consensus within this discussion that the Arbitration Committee does in fact already have the authority to remove bureaucrat permissions. In fact, some editors expressed concern that the proposed amendment would inadvertently reduce ArbCom's existing authority rather than expand it by specifying only "administrator and bureaucrat" as opposed to "administrative tools". Mz7 (talk) 18:09, 13 April 2024 (UTC)[reply]
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
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.
Agreed, but perhaps "rights" is better than "tools". Usedtobecool☎️ 17:49, 2 March 2024 (UTC)[reply]
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]
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]
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 MarshallT/C 19:52, 2 March 2024 (UTC)[reply]
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]
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]
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]
One more for "all advanced permissions" per Alanscottwalker et al.--GRuban (talk) 17:34, 3 March 2024 (UTC)[reply]
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]
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]
Support rewording to en-wiki advanced permissions per Jkudlick. Pinguinn🐧 10:09, 6 March 2024 (UTC)[reply]
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]
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]
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]
Obviously. Support codifying for clarity to the casual reader. -Fastily 20:01, 24 March 2024 (UTC)[reply]
I think they already have this right. Clarifying it is always a good idea. SportingFlyerT·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]
Yes, of course! I also support other wordings proposed, including "all advanced permissions" and equivalents. Toadspike (talk) 10:03, 3 April 2024 (UTC)[reply]
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
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]
+1 This. "Administrative tools" refers to any advanced permissions typically only given to administrators like CheckUser, Oversight, and yes Bureaucrat. AwesomeAasim 23:16, 2 March 2024 (UTC)[reply]
"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]
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. SeraphimbladeTalk to me 10:51, 6 March 2024 (UTC)[reply]
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]
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]
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]
"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]
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]
"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]
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. –Gluonztalkcontribs 19:43, 2 April 2024 (UTC)[reply]
Comments (ARBPOL petition)
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 MarshallT/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]
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]
@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 arbitratorsAny 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 TapeMy 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. SportingFlyerT·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
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]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
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.
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.
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, SpringProoftalk 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, SpringProoftalk 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. — xaosfluxTalk 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 MarshallT/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 MarshallT/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]
Sources: clarify that they may be on a linked page
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]
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]
Oppose. I understand where you are coming from, but the information architecture of wikipedia isn't formed to make this a robust option. The longer-term solution, which has been discussed from time to time, would be to create a centralized "citation library" where, for instance, a book referenced by many articles has a central citation which is called from each of the articles using that citation. The only way this would work in practice would be to have a bot-based transfer of citations to the library with in-page replacement. This is a wish and not a reality today. --User:Ceyockey (talk to me) 00:36, 11 April 2024 (UTC)[reply]
Re: image won't be removed or edited I fell it should
This discussion is not attempting to discuss already proposed policies and guidelines or to discuss changes to existing policies and guidelines. The original requester appears to have been confused about how to deal with content concerns on a page, which are not decided by admins and certainly do not require a policy change. The appropriate venue to discuss improving an article is the associated talk page. While Wikipedia continues to not be censored, editors are always welcome to select illustrations and images that best improve articles. The offensive materials guideline already provides guidance on this topic, and editors have already adjusted the article images that spurned this discussion. — xaosfluxTalk 10:18, 8 April 2024 (UTC)[reply]
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
I was looking up my condition and found this page. When i went down to types to me it had a very horrid picture which should of been edited to hide areas
Now i tried to report it but admins said it cant be censored as its a using the WPP policy
Now i said it fell it should be censored due to it type of picture but they said to go here and discuss it under policy i fell the picture should be censored in areas
To clarify, you want to change Wikipedia's longstanding policy that we don't censor images? Oppose, per all the reasons already listed there. 🌺 Cremastra (talk) 23:56, 26 March 2024 (UTC)[reply]
Only images like the one under that article. It should in my view have a black circle in intermate areas thats all 2A02:6B66:5430:0:A199:5B1C:6E44:34BE (talk) 00:00, 27 March 2024 (UTC)[reply]
Sorry, I haven't looked at the article yet. What's the problem with the images? 🌺 Cremastra (talk) 00:01, 27 March 2024 (UTC)[reply]
In fairness to the IP, although Wikipedia is not censored, per WP:GRATUITOUSthis does not mean that Wikipedia should include material simply because it is offensive and Offensive material should be used only if its omission would cause the article to be less informative, relevant, or accurate, and no equally suitable alternative is available. This isn't to weigh one way or another in this particular case so much as to say we can rightly weigh this more carefully than immediately rejecting any call for sensitivity about an image. Hydrangeans (she/her) (talk | edits) 00:12, 27 March 2024 (UTC)[reply]
Here's an obligatory proper non-mobile wikilink to the Phakomatosis article. Graham87 (talk) 10:18, 27 March 2024 (UTC)[reply]
There are two images that show naked children, but both are in the context of medical diagnosis and are sourced to reputable medical sources (like the Mayo Clinic). Sadly there are times where medically informative images need to go that direction due to the nature of the medical issue (this article appearing to be about conditions occurring in youth). Is it possible there are equivalent images that don't show as much? Maybe - the Mayo clinic's image is the worst offender here and it is because the larger image doesn't seem to identify any features of the symptoms with the one larger image. It would be helpful for editors to see if there are better images that avoid the issue of showing full nudity here, but removal just because they do show naked children in medical context is not really appropriate. Masem (t) 12:16, 27 March 2024 (UTC)[reply]
IMO an IP with no useful contributions complaining about an objectively educational if unideal image being “horrid” because it has a nude child in a reasonable context, something we have Countless images of, is not a good reason to even consider removing something. Dronebogus (talk) 20:38, 29 March 2024 (UTC)[reply]
"an IP with no useful contributions": that's probably a reader, rather than editor, which means you should treat them with courtesy, not rudeness. We edit for them, not just for other editors.Has anyone asked the creator or the graphics lab if there is something that can be created that won't be considered child pornography in some jurisdictions? - SchroCat (talk) 07:04, 30 March 2024 (UTC)[reply]
It’s not child pornography if it’s from the Italian Journal of Pediatrics. Nevertheless I found a censored alternative. I will add that to the page instead. Dronebogus (talk) 14:33, 30 March 2024 (UTC)[reply]
In some jurisdictions (to repeat what I said), even this would be considered child porn: it shows a naked child. We can all see which well-meaning journal it is from, but in some countries the image is still outside the law. If there’s an alternative, so much the better. - SchroCat (talk) 16:40, 30 March 2024 (UTC)[reply]
In some jurisdictions porn is considered porn, and in some countries that’s outside the law, but we still use porn to illustrate porn where appropriate. Wikipedia only cares about what’s realistically considered illegal in the US. Dronebogus (talk) 17:35, 30 March 2024 (UTC)[reply]
FFS, you could start an argument in an empty room: we’re talking about a medical condition that affects both adults and children, not a ‘using porn to illustrate porn’. - SchroCat (talk) 20:52, 30 March 2024 (UTC)[reply]
No, you started talking about how the image might be illegal in some countries, I pointed out that other images on Wikipedia are illegal in some countries. Dronebogus (talk) 21:52, 30 March 2024 (UTC)[reply]
I find it amusing the way some editors in this thread dismiss the OP's concerns (or the OP themself) as if they are completely unfounded, whereas in the AI images thread earlier this month some rather similar concerns of legality and morality were argued from rather extreme positions. (Rightly, wp:notcensored was not the correct argument there, nor is it here; wp:gratuitous, linked by Hydrangeans, was the correct response here and contains the relevant guideline links and statements.) Of course with AI images the legal concerns are hypothetical and civil, whereas for the image in this thread, in other contexts or trivially modified, the legal concern is real and criminal in many jurisdictions. SamuelRiv (talk) 15:36, 30 March 2024 (UTC)[reply]
While SamuelRiv spoke of the legal concern, I don't think that's the only consideration we should have. Our policy on gratuitous imagery isn't grounded in worries about the law but in considerations for what is ethical. Images containing offensive material that is extraneous, unnecessary, irrelevant, or gratuitous are not preferred over non-offensive ones in the name of opposing censorship, and Wikipedia is not censored, but Wikipedia also does not favor offensive images over non-offensive images. If it's possible to have an image that illustrates the symptoms without showing full nudity, that would be preferred because we prefer images that don't have unnecessary offensive material over images. We might additionally consider whether we know if the subject was able to give fully informed consent to the photograph, especially since the subject was a child rather than an adult. I agree with Masem that the Mayo Clinic's image is the cause of most concern because the main image of the fully nude child does seem gratuitous, as the symptoms visible in the closer shots aren't particularly discernible in the full body image, meaning its inclusion doesn't advance the educational purpose of the article. Hydrangeans (she/her | talk | edits) 19:12, 30 March 2024 (UTC)[reply]
I don’t disagree, but if you’re going to argue about legality then I’m going to point out that argument’s well-established baselessness. Dronebogus (talk) 21:50, 30 March 2024 (UTC)[reply]
There's "Wikipedia isn't censored," and then there's "Surprise! Here's an unexpected picture of a child's vulva". We could edit that image to make it SFW without compromising the encyclopaedic content at all.—S MarshallT/C 21:32, 30 March 2024 (UTC)[reply]
Thanks, that was the appropriate and proportional response. Let's close this before any blood gets spilt.—S MarshallT/C 22:01, 30 March 2024 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Preference of using OpenStreetMaps
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]
OpenStreetMaps presents the least but most important metadata at each level of zoom.
The ability of zooming is only provided by OpenStreetMaps
If any change occurs for the river, for example the path changes, this is rapidly applied for OpenStreetMaps
language of metadata changes automatically for each Wikipedia
and many others. Just let me some time to write them.
font-size of text of metadata is automatically adjusted
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]
@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"
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]
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]
@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, ~ LindsayHello 20:26, 29 March 2024 (UTC)[reply]
Proposal 1: Render both; prefer OSM; hide others
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".
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]
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]
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]
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]
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, ~ LindsayHello 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, ~ LindsayHello 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, ~ LindsayHello 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]
Occam's razor has to do with problem-solving. If we apply to everything, then we get rid of everything as being too complicated. Cremastra (talk) 01:34, 11 April 2024 (UTC)[reply]
It's always puzzling to me when people bring up Occam's razor as if it lends any credence to a particular philosophical argument, where it universally translates to "the right answer is probably the one that seems right to me". Remsense诉 01:38, 11 April 2024 (UTC)[reply]
Neutral
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]
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
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]
Original research
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]
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]
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]
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:
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]
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
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
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:
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.
"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
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 LD50 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: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.).
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]
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.
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.
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]
When discussion has ended, remove this tag and it will be removed from the list. If this page is on additional lists, they will be noted below.
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]
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]
Appear means to start to be seen or to be present.[5] It doesn't say that it continues to be seen. Perhaps the previous blurb's problem was that it resorted to using is, incorrectly implying a continuing state, not that a present-tense alternative was not possble(??)—Bagumba (talk) 06:34, 11 April 2024 (UTC)[reply]
To be present is to continue to be seen (by those looking, at least). I think you're misreading that as to start to be seen or present. That second to be matters here (and so it appears bold). InedibleHulk (talk) 22:30, 11 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]
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. doktorbwordsdeeds 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. doktorbwordsdeeds 22:28, 10 April 2024 (UTC)[reply]
A typical ITN week does not have many blurbs that really need the past tense like the solar eclipse. Aaron Liu (talk) 02:37, 11 April 2024 (UTC)[reply]
We should use the correct tense. Someone does not "wins" an election or sports match, they won it. The eclipse, after it ended, was visible over North America, but "is" visible is factually inaccurate at that point (and before it starts to happen, we should say it will be visible). A political leader does not "makes" a statement, they made it. On the other hand, it may be accurate to say that a conflict is going on, or rescue efforts after a disaster are underway. So, we should use the natural, normal tense that accurately reflects the actual reality, as it would be used in the article. SeraphimbladeTalk to me 06:02, 11 April 2024 (UTC)[reply]
Object I don't think I agree with the premise that ITN blurbs are phrased in the present in the first place. It's in the historical present tense. "A 7.4-magnitude earthquake strikes near Hualien City, Taiwan" doesn't give the impression that the ground is still shaking. Nor does "A solar eclipse appears across parts of North America" read as "a solar eclipse is happening right now." Likewise, "Nobel Prize–winning theoretical physicist Peter Higgs (pictured) dies at the age of 94." doesn't need to be changed to "died at the age of 94", we know it's in the past, we're not under any illusions that he's still in the process of dying. It's phrased in such a way that doesn't really imply either past or present and just kind of makes sense either way. If an event is still happening, the blurb makes sense. And if the event is over, the blurb still makes sense. I think that's intentional. Vanilla Wizard 💙 07:33, 11 April 2024 (UTC)[reply]
Keep present tense as general recommendation per above. Discuss individual cases when this is too jarring. —Kusma (talk) 07:43, 11 April 2024 (UTC)[reply]
As an encyclopedia rather than a news agency, I would think past tense fits our vibe more. Archives of our frontpage would remain clearly accurate indefinitely. We are not reporting news, we are featuring a newly updated/written encyclopedic article on currently relevant events. ~Maplestrip/Mable (chat) 08:22, 11 April 2024 (UTC)[reply]
Keep present tense. There is a difference between "X is happening" (which necessarily means right now, at this moment) and "X happens" (which os somewhat more vague). We should always use the second form, regardless of precise moment. As stated above, we even have statements like "an earthquake hits..." or "So and so dies", both of which are clearly over by the tine it gets posted. Animal lover|666| 19:12, 11 April 2024 (UTC)[reply]
Object from a wp:creep standpoint To my knowledge there is no rule regarding this and it's just a practice. This would change it to having a rule. North8000 (talk) 19:25, 11 April 2024 (UTC)[reply]
How? The present tense rule was always written down there and this proposal does not make ITN a guideline. Aaron Liu (talk) 19:42, 11 April 2024 (UTC)[reply]
No, it should not – it's unencyclopaedic and ungrammatical. The Simple Present is used to describe habitual or continuous actions or states (the Sun sets in the West; he is a boot-and-shoe repairman; I'm Burlington Bertie, I rise at ten-thirty; Timothy Leary's dead etc). Events in the past are described using the Present Past when when no time is specified (the lunch-box has landed; London has fallen; mine eyes have seen the glory ...). When a time in the past is specified, the Simple Past is invariably used: in fourteen hundred and ninety-two, Columbus sailed the ocean blue, in fourteen hundred and ninety-three, he sailed right back over the sea; today, I learned; well I woke up this morning and I looked round for my shoes. This is not rocket science. Ours is not a news outlet with a profit target to meet, we have no reason to have 'headlines', which are simply bits of news given some kind of extra urgency by being in the wrong tense. "Wayne Shorter dies!" immediately begs the question "really? how often?" So "A total eclipse of the Sun has occurred; it was visible in [somewhere I wasn't] from [time] to [time]". It gives the information, it's written in English, where's the problem? (NB there are two distinct present tenses in English, the Simple Present and the Present Continuous; the latter is used for things that are actually happening in this moment or about to happen in the future (I'm going down to Louisiana to get me a mojo hand; I’m walking down the highway, with my suitcase ...). Justlettersandnumbers (talk) 20:22, 11 April 2024 (UTC)[reply]
@Justlettersandnumbers: Reading your comment makes it sound like it supports of my proposal instead of opposing it? I don't understand the "no, it should not" unless there's something I'm not getting. Clovermoss🍀(talk) 21:10, 11 April 2024 (UTC)[reply]
@Clovermoss The title of your section begins with "Should the main page continue to use the present tense". Aaron Liu (talk) 22:49, 11 April 2024 (UTC)[reply]
And then the actual RfC itself is my proposal to change that for situations where this would be misleading readers. I'm not sure it's necessarily the best idea to be messing around with section names at this point but I'm open to suggestions that would help make this less confusing for people. Clovermoss🍀(talk) 22:53, 11 April 2024 (UTC)[reply]
Eh, never mind. I decided to be bold and make it consistent with how CENT describes this discussion. Hopefully that helps things. Clovermoss🍀(talk) 23:15, 11 April 2024 (UTC)[reply]
Support Given that WP:ITNBLURB currently has the guideline that "blurbs should describe events in complete sentences in the present tense," it does not seem like instruction creep to modify an existing rule. isaacl recommends including a time-frame, but I find this impractical for events that occur over multiple time zones. While this eclipse's article reports the event's span over the overall planet in UTC, this level of detail is too cumbersome for a main page blurb. Clovermoss' proposal limits itself to cases where the present tense would be confusing, which is preferable to an individual discussion for each perceived exception to the current guideline. BluePenguin18 🐧 ( 💬 ) 20:50, 11 April 2024 (UTC)[reply]
Yes, the practice should continue - this is a perfectly normal idiomatic feature of English. Headlines are written in the present tense, just like 'in which...' in the chapter sub-headings of old novels, the summaries of TV episodes in magazines and on streaming services, and lots of other places where a reported past action is summarised. GenevieveDEon (talk) 21:33, 11 April 2024 (UTC)[reply]
How about, "is seen over North America" -- passive with present tense and past participle, anyone? :) Alanscottwalker (talk) 21:49, 11 April 2024 (UTC)[reply]
That's a better solution than ending the practice of using the historical present tense. Though I think that suggestion is more likely to be implemented at WP:ERRORS than through a Village Pump policy proposal. (I'm also not entirely sure why this whole discussion isn't just at the ITN talk page since it doesn't affect any other part of the main page, but it's no big deal) Vanilla Wizard 💙 20:10, 12 April 2024 (UTC)[reply]
ERRORS is not the appropriate venue, given that the discussion that was there was removed. As for why it's here specifically, I figured anything regarding the main page was important, that a discussion here would invite more participants, and avoid the possibile issue of a local consensus. Clovermoss🍀(talk) 20:16, 12 April 2024 (UTC)[reply]
I originally thought this suggestion was sarcastic, given the smiley face. If it is serious, I dislike it because "is seen" is extremely passive voice. Assuming there is a problem (which I don't think there is), the solution is not passive voice. CaptainEekEdits Ho Cap'n!⚓ 20:22, 12 April 2024 (UTC)[reply]
I don't think passive voices are that bad; while I agree that the active voice is usually preferred, do you really think that "North Americans see a total solar eclipse" is better? Aaron Liu (talk) 21:32, 12 April 2024 (UTC)[reply]
No. I think that the current iteration "A total solar eclipse appears across parts of North America" is perfect. CaptainEekEdits Ho Cap'n!⚓ 21:37, 12 April 2024 (UTC)[reply]
I was illustrating why the passive voice doesn't deserve to be demonized. Aaron Liu (talk) 21:42, 12 April 2024 (UTC)[reply]
In fairness, that discussion was removed specifically because ITN uses present tense and the discussion was proposing to change that, and ERRORS isn't the place for proposals to change how we do things. Alanscottwalker's suggestion also uses the present tense, so ERRORS would be a fine venue if they really wanted to see that change made. After all, that discussion at ERRORS is what resulted in the language being changed from "is visible" to "appears". I personally think appears is totally fine (I agree with CaptainEek that there is no problem), but if someone prefers "is seen", that's the place to do it. Vanilla Wizard 💙 20:33, 12 April 2024 (UTC)[reply]
That discussion only happened because I changed "is visible" to "was visible", prompting an errors report. I'd prefer "appeared" over "appears" since that implies that it is still indeed visible per the above discussion. It's better than "is visible", though. Clovermoss🍀(talk) 01:07, 13 April 2024 (UTC)[reply]
Keep present tense as ITN is supposed to summarize and collect news headlines and the present tense is standard in headlines. Pinguinn🐧 00:05, 12 April 2024 (UTC)[reply]
Keep using historical present I think a lot of supporters here are confusing the historical present (often used in news headlines) for the simple present. I would agree that the eclipse would have made sense to be an exception to that general rule, as was the focus in the original proposal here, but I wouldn't change the general rule. Anomie⚔ 12:04, 12 April 2024 (UTC)[reply]
Currently, in this proposal, I see a codified exception for when using the present tense would be confusing that would only apply in cases like the solar eclipse. Aaron Liu (talk) 12:43, 12 April 2024 (UTC)[reply]
Keep historical present tense Headlines are most compelling and appropriate in the historical present tense. The NYTimes provides that "Headlines are written in the historical present tense. That means they written are in present tense but describe events that just happened."Out of curiosity, I perused the AP Stylebook (56th edition, 2022-2024), which surprisingly had almost nothing to say on tenses, though its section on headlines is generally instructive.
"Headlines are key to any story. A vivid, accurate and fair headline can entice people to dig in for more. A bland, vague or otherwise faulty headline can push readers away. Often, a headline and photo are all that many readers see of a story. Their entire knowledge of the piece may based on those elements. Headlines must stand on their own in conveying the story fairly, and they must include key context. They should tempt readers to want to read more, without misleading or overpromising."
How to best have a vivid headline? Present tense and active voice! One of Wikipedia's most frequent writing errors is using past tense and passive voice out of a misplaced assumption that it is more encyclopedic. But past and passive are weak. Present and active are better, and are what I have been taught in a wide multitude of writing courses and professional spaces. To add to the NYTimes, AP, and personal experience, I consulted my copy of Bryan Garner's Redbook (4th ed.), which while meant as a legal style guide, is useful in other areas. Regarding tense, in heading 11.32, it provides that "generally use the present tense." I then turned to the internet, which backed up the use of present tense in headlines: Grammar expert suggests present tense "Engaging headlines should be in sentence case and present tense." Kansas University on headlines: "Present tense, please: Use present tense for immediate past information, past tense for past perfect, and future tense for coming events."Using the historical present is best practice for headlines. That's not to say that there can't be exceptions, but they should be rare. As for the eclipse, it properly remains in the historical present. As a further consideration: if we are updating ITN tenses in real time, we are adding considerable work for ourselves, and we push ourselves truly into WP:NOTNEWS territory. CaptainEekEdits Ho Cap'n!⚓ 18:35, 12 April 2024 (UTC)[reply]
I don't think we're adding considerable work for ourselves. It takes a second or two in the rare situations that require it, anything else regarding the main page has much more work involved. We already update the articles in question, just not the blurb, which is a bit of a jarring inconsistency in itself. I don't understand the argument that the tense we should be using should be comparable to newspaper headlines because we're NOTNEWS? Could you elaborate a bit on your thinking there? Clovermoss🍀(talk) 19:43, 12 April 2024 (UTC)[reply]
For the last part: they're mistaken that this proposal would require tenses to be updated to the past tense when any event ends, which is way too much effort to stay current which kinda does fall into NOTNEWS. (Note that this proposal would only require past tense if the historical present causes confusion) Aaron Liu (talk) 19:50, 12 April 2024 (UTC)[reply]
We are NOTNEWS. But as my comment above alludes to, ITN is a de facto news stream. Each entry in ITN is effectively a headline. Why try to reinvent the headline wheel? I'm afraid I have to disagree with Aaron's clarification, because Clover did change the tense after the event ended. It would have been incorrect to say "was" when the blurb first posted...because the eclipse was presently happening at that time. I'll add further that "otherwise mislead readers into thinking an event is ongoing" is an unhelpful standard. I don't buy that the average reader is going to be confused by a historical present headline. We read headlines all the time, and the average reader understands the historical present, even if they couldn't define it. CaptainEekEdits Ho Cap'n!⚓ 20:18, 12 April 2024 (UTC)[reply]
I have to disagree with you there. I think that when the main page stated that the eclipse "is visible", that was confusing to the average reader. It confused me, prompting me to check that the eclipse wasn't somehow ongoing. We were giving inaccurate information intentionally and I honestly don't see why we do this for the main page. Because it's interesting? Because newspapers do it before an event happens? Once the eclipse ended, newspapers referred to the event in the past tense as well. My decision to change it to "was visible" took one second (so not a considerable time investment, although everything that ensued certainly has been). Clovermoss🍀(talk) 20:32, 12 April 2024 (UTC)[reply]
Ah, that's my bad, the "is visible" language is also problematic for its passivity. I like the "appears" solution, and thought that was the original wording. But I think it would be improper to say "appeared." I'm not so sure I buy that newspapers were uniformly using past tense; again, the best practice for newspapers is to use the historical present. The time issue is ancillary to the best practice issue, I agree that the real time sink is the discussions that will surely result from implementing this rule. CaptainEekEdits Ho Cap'n!⚓ 20:42, 12 April 2024 (UTC)[reply]
I could show some examples if you'd like, since you don't seem to buy that newspapers were using the past tense after the eclipse appeared.
"A total eclipse of a lifetime appeared for hundreds of thousands of visitors and residents in the Hamilton-Niagara region" – Canadian Broadcasting Corporation[6]
"During the event on April 8, 2024, one of these arcs was easily visible from where I stood, agape beneath our eclipsed, blackened star, in Burlington, VT." – Mashable[8]
"The great American eclipse appeared Monday, bringing the nation to a standstill as photographers captured stunning shots of the rare celestial event." – CNET[9]
"The total solar eclipse that swept across Mexico, the United States and Canada has completed its journey over continental North America." – CNN[10]
I think that "appears" is better than saying "is visible" like the previous phrasing was before my intermediate change of "was visible" but it still runs into the issue of implying the eclipse is appearing somewhere. I agree with what InedibleHulk said above To be present is to continue to be seen (by those looking, at least). I think you're misreading that as to start to be seen or present. That second to be matters here (and so it appears bold).Clovermoss🍀(talk) 21:14, 12 April 2024 (UTC)[reply]
The operative issue is that these are headlines from after the event. But the blurb got posted during the event. CaptainEekEdits Ho Cap'n!⚓ 21:19, 12 April 2024 (UTC)[reply]
And the blurb stays days or weeks on the main page, where using the past tense would be more accurate than using present tense the entire time. I also think that having a clear exemption clause would prevent time sink discussions like this one, not cause them. It'd prevent us from needing to have a discussion every time something like this happens. Clovermoss🍀(talk) 21:25, 12 April 2024 (UTC)[reply]
I think that this discussion would prevent some time sink over reluctance to IAR. And again, only a small number of events would need their tense changed. Aaron Liu (talk) 21:34, 12 April 2024 (UTC)[reply]
Drop present tense and use the tense we'd use anywhere else on Wikipedia. Wikipedia is not a newspaper, even on the Main Page, and there's no reason we should obscure the timing of events for stylistic reasons. Loki (talk) 21:18, 12 April 2024 (UTC)[reply]
The tense we'd use anywhere else is, by default, present? WP:TENSE provides that By default, write articles in the present tense. CaptainEekEdits Ho Cap'n!⚓ 21:22, 12 April 2024 (UTC)[reply]
MOS:TENSE says By default, write articles in the present tense, including those covering works of fiction (see Wikipedia:Writing better articles § Tense in fiction) and products or works that have been discontinued. Generally, use past tense only for past events, and for subjects that are dead or no longer meaningfully exist. We use past tense for past events like we do at the actual article linked in the ITN blurb: Solar eclipse of April 8, 2024. It's just the main page where we make the stylistic choice to not do that. Clovermoss🍀(talk) 21:31, 12 April 2024 (UTC)[reply]
The present tense makes the main page read like a news ticker, which we are often at pains to explain it is not (e.g. WP:NOTNP). I would favour the past tense for all events that are not ongoing. If we cannot agree on that, I support the proposal to use the past if there might be a misunderstanding (partly in the hope that familiarity will lead to the past tense being used more and more in the future!). JMCHutchinson (talk) 11:06, 13 April 2024 (UTC)[reply]
Should PAID editors fix inaccuracies in their employer's articles before attempting to fix their competitor's?
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, Rosguilltalk 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]
No. If an editor is improving the encyclopaedia they should be encouraged to continue doing so, regardless of how, why or which part of the encyclopaedia they are improving. Intonationally preventing other editors improving the encyclopaedia is disruptive editing and persistently doing so could (and imo should) lead to blocks. If you have identified problems in a different article then either fix them, or explicitly note them (tags, talk page and/or wikiproject) with enough detail that other editors know what the problem is, where it is, and why it's a problem. Thryduulf (talk) 01:32, 11 April 2024 (UTC)[reply]
Wouldn't this disincentivise the paid editors in question from reporting the errors in their competitors' articles in the first place? – Teratix₵ 06:23, 11 April 2024 (UTC)[reply]
This thread illustrates only one of the many reasons we should ban paid editing.--ChetvornoTALK 07:48, 12 April 2024 (UTC)[reply]
Examples of paid editors improving the encyclopaedia illustrate why we should ban paid editing? There are lots of silly things written about paid editing, but that is one of the silliest. Thryduulf (talk) 10:10, 12 April 2024 (UTC)[reply]
No We can't ever compel editors to write about something they don't want to. CaptainEekEdits Ho Cap'n!⚓ 19:01, 12 April 2024 (UTC)[reply]
No. At first glance this seems like a good idea, but, as well as what has been said above about compelling editors to do something, I can see more than one WP:BEANS concern. Phil Bridger (talk) 19:24, 12 April 2024 (UTC)[reply]
I'm in general in favor of it, though it'll probably need some eyes going over it before going to guideline status, especially on cautions about using primary sources. Obviously a little more relaxed than WP:MEDRS, but not carte blanche use or outright encouraging primary sources either.
I have some guidance on my user page in the sourcing section that might be helpful there. In short, primary journal articles have their own mini-literature reviews in the intro and to some degree discussion/conclusions. When you are in a field that doesn't have many literature reviews, etc. those parts of sources can be very useful (e.g., entomology topics for me) for things like basic life cycle or species information. It's a good idea to avoid using a primary article for sourcing content on the findings of the study itself since it's not independent coverage though. That's not meant to be strict bright lines if it becomes guideline, but give guidance on how primary sources are best used if they are being used. If someone wants to use/tweak language from my page for updates, they'd be welcome to. KoA (talk) 16:20, 11 April 2024 (UTC)[reply]
I think we could say that in that circumstance, such as a paper is both a secondary source (in its discussion of other literature) and a primary source (in its results). I agree that the section on primary sources could be fleshed out, but I don't think it should be a blocker to giving it guideline status now (guidelines are never complete). – Joe (talk) 06:21, 12 April 2024 (UTC)[reply]
My thoughts exactly too in that it's an improvement that can be made independent of guideline or not. It would be a simple addition like you put, but it would also preempt concerns that sourcing would somehow be severely limited, which it functionally would not be.
If anything, much of what I mentioned here or at my userpage already addresses what has been brought up in a few opposes below. KoA (talk) 17:19, 12 April 2024 (UTC)[reply]
Oppose. Maybe it's stable because we are free to ignore it. Maybe any useful advice in it is just what's already in other PAGs. Maybe we already have enough guidelines. WP:MEDRS was a bad idea too but at least had the excuse that dispensing bad health advice could cause legal problems; outdated cosmological theory has a somewhat smaller effect. Peter Gulutzan (talk) 17:51, 11 April 2024 (UTC)[reply]
Support. This is necessary due to the huge and growing problem of the flood of unreliable research. As an engineer I edit scientific WP articles, and I waste an enormous amount of time dealing with noobs who come across some unsupported claim in a paper or sensationalist "science" website and are determined to put it in WP. And more time on pseudoscience advocates who dig up obscure papers that support their delusions. And more time on researchers trying to promote their careers by inserting cites to their own research papers in WP. In science today primary sources (research papers) are worthless, due to p-hacking the vast majority in even top journals are never confirmed. This needs to be reflected in our guidelines. --ChetvornoTALK 20:51, 11 April 2024 (UTC)[reply]
Support but... So unlike wp:ver & wp:rs (which require certain trappings and not actual reliability) we're going to require actual reliability for science articles? Requiring actual reliability puts it in conflict with wp:Ver and wp:RS. :-) North8000 (talk) 21:06, 11 April 2024 (UTC)[reply]
It's not my understanding that guidelines create "requirements", just offer best practices supported by consensus (WP:GUIDES). – Joe (talk) 06:09, 12 April 2024 (UTC)[reply]
Support. Many longtime editors do not realize or refuse to acknowledge that primary sources should only ever comprise a small fraction of sourcing for an article. We also regularly have editors insisting various basic biology topics "aren't governed by MEDRS" because they don't have an immediate clinical relevance, and therefore the findings of primary research papers are acceptable. Having an actual guideline to point to that is more explicit on this would be helpful. JoelleJay (talk) 00:57, 12 April 2024 (UTC)[reply]
This is also what I've found WP:SCIRS most useful for over the years. WP:PSTS is established policy, but it's not immediately obvious how to apply it to scientific topics without the extra guidance in WP:MEDRS or WP:SCIRS. We end up with sections that are just runs of "A 2017 study found, ..." then "A 2020 study found, ..." with no information on if any of those findings have achieved scientific consensus, because people see a journal article and assume that because it's reliable you can use it without qualification. WP:SCIRS clarifies which types of journal article are primary and which are secondary, and therefore how we should be using each type. – Joe (talk) 06:16, 12 April 2024 (UTC)[reply]
Oppose Contra Joe Roe above, I think that Wikipedia:Identifying reliable sources (science) isn't an useful guidance on how to use primary vs secondary. In natural sciences, you tend to have articles that include a summary or review of existing science, followed by a paper's own conclusion - which by its very nature cannot say whether its findings have been widely accepted or not. That is, the same source is both primary and secondary, depending on which information you take from it. The essay isn't aware of this point. The problem with popular press isn't secondary/primary, either; rather that it tends to exaggerate and oversimplify i.e a reliability issue. Jo-Jo Eumerus (talk) 06:57, 12 April 2024 (UTC)[reply]
We could just add that point? – Joe (talk) 07:06, 12 April 2024 (UTC)[reply]
That would be a root-and-branch rewrite, as the idea of them being two separate kinds of sources is woven in its entire structure. In general, I think that WP:PSTS is a problem as it takes a concept mostly from history and tries to extrapolate it to other kinds of sources which often don't neatly map on it. Jo-Jo Eumerus (talk) 07:15, 12 April 2024 (UTC)[reply]
If a primary source has a "summary or review of existing science", that existing science will be available in secondary sources, which are what we should use.--ChetvornoTALK 07:36, 12 April 2024 (UTC)[reply]
I don't see anything in WP:SCIRS or WP:PSTS that precludes a source being primary in some parts and secondary in others?WP:PSTS explicitly acknowledges that a source can be both primary and secondary at the same time: A source may be considered primary for one statement but secondary for a different one. Even a given source can contain both primary and secondary source material for one particular statement.. KoA observed the same thing above. It's a good point, and worth noting, but I think it can be easily achieved with an extra paragraph in WP:SCIRS#Basic advice, no rewrite needed. – Joe (talk) 08:26, 12 April 2024 (UTC)[reply]
Only in well-covered fields. In less well covered ones like remote volcanoes, you often have one research paper that summarizes the existing knowledge before introducing its own point. But this guideline would apply to every field, not just the well-covered ones. ^It's not enough for the guideline to acknowledge the existence of "hybrid" sources; that's still assuming that most aren't hybrids and will mislead people into trying to incorrectly categorize sources. It's an undue weight issue, except with a guidance page rather than an article. Jo-Jo Eumerus (talk) 10:07, 12 April 2024 (UTC)[reply]
I don't think I'm fully understanding you. A volcanology paper that summarizes the existing knowledge before introducing its own point is both a secondary source (in the first part) and a primary source (in the second part). How is this different from other fields? – Joe (talk) 10:20, 12 April 2024 (UTC)[reply]
Sorry, that was addressing Chetvorno. Jo-Jo Eumerus (talk) 10:45, 12 April 2024 (UTC)[reply]
I think the vast majority of people citing primary sources are citing them for their research findings, not their background sections. In the rare cases where they are citing the latter, if the material is contested on SCIRS/PSTS grounds then the editor can just point to where we say otherwise-primary sources can contain secondary info and say that's what they're citing. JoelleJay (talk) 16:18, 12 April 2024 (UTC)[reply]
The trouble with the 'secondary' material in primary sources, is that the authors almost invariably spin it to align with their (primary) research conclusions. It should generally be avoided in favour of dedicated secondary sourcing. Bon courage (talk) 03:23, 16 April 2024 (UTC)[reply]
I'm a bit short on time until next week, but I'd be willing to draft something based on my userpage (though a bit more flexible/advisory) if someone else doesn't get to it. KoA (talk) 17:29, 12 April 2024 (UTC)[reply]
Oppose. <rant>The essay is an example of the primary vs secondary fetish that pollutes much of our policy. Actually there are very few things disallowed for primary sources that are not also disallowed for secondary sources. The rule should be "use the most reliable source you can find and refrain from original research". Instead, endless argument over whether something is primary or secondary replaces rather than informs discussion of actual reliability. So we get editors arguing that a newspaper report of a peer-reviewed journal article is better than the journal article itself, favoring the least reliable source for no good reason. Secondary reports of research are useful, for example they may contain interviews with experts other than the authors, but they are not more reliable than the original on what the research results were. Review articles are great, but rarely available. It is also not true that the existence of secondary reports helps to protect us from false/fake results; actually is the opposite because newspapers and magazines are more likely to report exceptional claims than ordinary claims.</rant> Zerotalk 10:28, 12 April 2024 (UTC)[reply]
Well, it seems this is a common bugbear. Personally I've found the primary vs. secondary distinction very useful in doing exactly that, avoiding original research, but clearly others' mileage vary. Although it should be pointed out that, apart from discussing primary and secondary sources, WP:SCIRS strongly discourages using media coverage of scientific results (Wikipedia:Identifying_reliable_sources_(science)#Popular_press), so someone arguing that a newspaper report of a peer-reviewed journal article is better than the journal article itself would not find support in this essay.
In any case, isn't the objection you and Jo-Jo Eumerus are articulating really against WP:PSTS, not WP:SCIRS? Not recognising a guideline because it fails to deviate from a policy would be... odd. – Joe (talk) 10:52, 12 April 2024 (UTC)[reply]
If the policy is questionable, making a guideline that emphasizes the problematic aspects in a field where the problematic aspects are particularly problematic is making a problem worse. FWIW, while newspapers aren't my issue with SCIRS, I've certainly seen people claiming that news reports on a finding are secondary and thus to be preferred. Jo-Jo Eumerus (talk) 11:14, 12 April 2024 (UTC)[reply]
And they cite SCIRS for that? It says the opposite. – Joe (talk) 12:21, 12 April 2024 (UTC)[reply]
Joe, you are correct that my main beef is not with SCIRS. I haven't paid much attention to it, though I'd have to if it became a guideline. Mainly I severely dislike PSTS, which is full of nonsense, and I don't want more like it. Almost every word in the "primary source" section of PSTS is also the case for secondary sources. For example, "Do not analyze, evaluate, interpret, or synthesize material found in a primary source yourself" — since when are we allowed to do any of those things to a secondary source? And the only good thing about rule #3 is that it is largely ignored (unless "any educated person" knows mathematics, organic chemistry and Japanese). I could go on....I've been arguing this case for about 20 years so I don't expect to get anywhere. Zerotalk 14:32, 12 April 2024 (UTC)[reply]
Zero0000 re: "...newspapers and magazines are more likely to report exceptional claims than ordinary claims". That is a different problem: what constitutes a reliable secondary source for a given field. SCIRS says: "Although popular-press news articles and press releases may tout the latest experiments, they often exaggerate or speak of 'revolutionary' results" So for scientific topics general newspapers and newsmagazines should not be considered reliable sources on a par with scientific journal reviews. WP:PSTS does not mention this issue; another reason SCIRS should be a guideline. --ChetvornoTALK 23:32, 14 April 2024 (UTC)[reply]
Oppose. Upgrading the "Identifying Reliable Sources (Science)" (SCIRS) to guideline status risks imposing unnecessary rigidity on topics that straddle the science and non-science boundary, and I believe that WP:MEDRS needs to be downgraded to an essay due to its frequent misapplication to part-biomedical topics, sometimes even in bad faith. As an essay, SCIRS provides useful advice without enforcing a strict approach that may not be suitable for all topics. By making it a guideline, we risk encouraging an overly simplistic distinction between primary and secondary sources, which may not always reflect the complexities and nuances of scientific inquiry, especially in interdisciplinary fields, or in burgeoning areas of research where established secondary sources may not yet exist. Furthermore, this rigidity could be abused, potentially serving as a gatekeeping tool rather than as a guide, particularly in contentious areas that intersect science with social or political dimensions, as seen with MEDRS in various topics. Maintaining the current flexibility that allows for context-sensitive application of source reliability is essential to ensure that Wikipedia continues to be a diverse and adaptable repository of knowledge. FailedMusician (talk) 23:42, 12 April 2024 (UTC)[reply]
We already have flexibility in assessing secondary vs primary coverage within a source, per PSTS. Can you link some examples of MEDRS being misapplied? And if a topic has no secondary coverage at all, whether in review articles/books or in background sections of primary research papers, it certainly should not have its own article and likely isn't BALASP anywhere else either. JoelleJay (talk) 00:48, 13 April 2024 (UTC)[reply]
I believe you are aware of cases where MEDRS has been misapplied. There are instances where primary sources, extensively covered in mainstream media, are challenged by misconstrued higher-quality sources, often to remove contentious content or editors. Introducing a new policy for scientific sources could further stratify our community, complicating contributions and inhibiting constructive dialogue. FailedMusician (talk) 10:14, 13 April 2024 (UTC)[reply]
Where are these cases and why would you think I was aware of them? We haven't edited any of the same mainspace or talk pages or the same topics of any wikipedia- or user-space pages, so I don't know how you would get that impression. The only time I've seen editors claiming primary biomed sources need to be pushed into articles is in support of fringe views like the lab leak conspiracies. JoelleJay (talk) 01:58, 15 April 2024 (UTC)[reply]
Scientific topics often cross multiple disciplines or emerge in fields where extensive secondary sources are scarce. Elevating SCIRS from an essay to a formal guideline could inadvertently restrict the integration of innovative or complex scientific information, making source verification a restrictive rather than supportive process, like in the example you cite. FailedMusician (talk) 23:34, 15 April 2024 (UTC)[reply]
Other disciplines also need secondary sources to comply with NPOV and OR, so I don't see how SCIRS would affect such content negatively. Can you link some examples of disciplines where secondary sources are scarce but which still have DUE content? The example I cite is evidence in support of SCIRS as it would discourage use of unvalidated, potentially fringe research findings outside of medicine. JoelleJay (talk) 00:47, 16 April 2024 (UTC)[reply]
Oppose. Large parts of SCIRS are copy-pasted from (an old version of) WP:MEDRS, but with some words changed. There may be a place for a SCIRS but it would need to be more specific and content-appropriate than this. Bon courage (talk) 03:08, 16 April 2024 (UTC)[reply]
Could support if retitled. I find SCIRS is very useful. In my experience, when articles or sections are rewritten to use mostly SCIRS sources, they get considerably better. I've thought of proposing that this be retitled to "Identifying 'high-quality reliable sources (science)" and then made a guideline. With its current title, I have two concerns. One is the large grey area around what “science” is, which would need to be clarified. Another is the exclusion of factual encyclopedic content that is too new or too obscure to have been covered in secondary sources. Here’s a simple example from Orca: “A 2024 study supported the elevation of Eastern North American resident and transient orcas as distinct species, O. ater and O. rectipinnus respectively.[1]”
I’m very concerned that a guideline would be used to revert any and all additions of content that “fails SCIRS” which is highly discouraging to newbies and would result in the rejection of a lot of good information along with bad.
The value of SCIRS sources is that they indicate the level of acceptance that claims have in the science community. This is useful for assessing controversial claims and for filtering out noise in fields where there are a lot of early-stage technologies clamoring for attention. Secondary sources are invaluable for ensuring NPOV in broad and/or controversial areas. However, I have never bought into the idea that secondary sources are essential for ensuring NOR in the sciences. A primary source in history is by definition written by a non-historian and requires a researcher to interpret it. A primary source in science is usually written by a scientist and summarizing it is not original research. Clayoquot (talk | contribs) 04:24, 16 April 2024 (UTC)[reply]
Yeah, but deciding a piece of primary research is worthy of encyclopedic content (i.e. is 'accepted knowledge') is OR. Primary research is really an interchange among researchers, and much of it is faulty/wrong/fraudulent. Wikipedia editors are in no position to pick and chose what's good and what's not. Bon courage (talk) 04:29, 16 April 2024 (UTC)[reply]
Clayoquot makes an important point about the uncertainty over what is the "science" as that can be exploited by advocates of certain issues to misrepresent emerging or part scientific topics as being on the fringe. This can impact the reliability and representation of such topics on Wikipedia, potentially either overstating or undervaluing their scientific validity. Therefore, clear guidelines are crucial to prevent the misuse of these definitions. FailedMusician (talk) 07:36, 16 April 2024 (UTC)[reply]
WP:FRINGE doesn't just apply to "science", however it is defined. In the humanities the secondary/primary considerations are completely different in any case (you don't get a systematic review of who wrote the works of Shakespeare!). Bon courage (talk) 07:43, 16 April 2024 (UTC)[reply]
How scientific aspects of topics are defined is important, especially in the face of editors engaging in strong advocacy on issues, and worse. That's why we need to exercise caution here. FailedMusician (talk) 09:56, 16 April 2024 (UTC)[reply]
Oppose: Like @Clayoquot, I am an active contributor to WikiProject Climate change, and I can say with confidence that certain scientific subjects, such as, in fact, climate change, are so fast-moving that an application of this policy would cripple most of our articles on this topic. Even the primary peer-reviewed papers are, by necessity, several years behind the real-world processes due to the time it takes to first analyze the climate data, and then to get the paper through peer review. To give an example I have had to deal with recently - a research paper (i.e. a primary source) on trends in oceanic carbon storage published in August 2023 was only able to cover trends up to 2014! Yet, if SCIRS were to become a guideline, we would need to exclude it and rely on even older data!
As @Bon courage points out, much of SCIRS stems off MEDRS. Primary research in climate science is in a very different position to primary medical research. It's one thing to p-hack an observational study among a few dozen patients. It's quite another when you have to reserve months of computing time from room-scale supercomputers (lead image here shows what a typical climate model looks like nowadays, for reference) - often multiple ones in different research institutions across the world - in order to be in a position to even test your hypothesis in the first place. Likewise when your primary research involves field work like sending robotic submarines underneath glaciers.
It is actually a lot easier to write a review in climate science if you don't mind about the journal which would accept it - and the current guideline text has very little to say about differences between journals, even ones as obvious as those between Nature and Science vs. MDPI and Frontiers. As best as I can tell, this notorious piece from MDPI would be accepted for inclusion due to being a secondary source, while a paper in Naturelike this one would be rejected, if going off SCIRS as currently written. Even if this were amended, a lot of primary climate research is unlikely to make it into reviews for reasons that have nothing to do with reliability. I.e. it's not really realistic to expect that scientific reviews, or even the ~4000-page IPCC reports (published in 7-year intervals) would include every good paper about climate impact on every species that could be studied, or about every geographic locale. For lesser-known species/areas in particular, it would often be primary research or nothing.
Finally, I can only assume that if this guideline were to be applied consistently, then graphics taken from primary sources would be affected as well, wouldn't they? That would be a disaster for so many of our articles, which would stand to lose dozens of illustrations. This is because only a handful of reliable climate journals use the licensing compatible with Wikipedia terms, and those overwhelmingly publish primary research. Secondary scientific reviews tend to either lack suitable illustrations in the first place, or to have incompatible licensing (i.e. the graphics in the IPCC reports). The precious exceptions are nowhere near enough.
Is it just me or does this template tend to get abused quite a lot? Not sure what the best way to bring up the issue is Trade (talk) 16:33, 12 April 2024 (UTC)[reply]
@Trade, how is it being abused? Could you link to some examples where you think it's been used improperly? Schazjmd(talk) 16:48, 12 April 2024 (UTC)[reply]
Abused as in used when it's very obvious what changes the IP wants made to an article and yet it's still being treated as if the request is somehow unintelligible.
I don't have examples at hand since i only edit here sporadically. Still i'm interested to hear if other editors consider it an issue Trade (talk) 21:59, 12 April 2024 (UTC)[reply]
That would be specifically {{ESp|xy}}Cremastra (talk) 20:51, 13 April 2024 (UTC)[reply]
Trade, your issue seems not to be with the template itself, but with the fact that responders to edit requests are not usually familiar with the article topics themselves, but should know how to read sources to determine whether a request is valid. This is the ideal, but is not always true in practice because this is the encyclopedia that anyone can edit, including you. I can't really say any more without an example - Wikipedia works best when people talk about real cases rather than abstact principles. Phil Bridger (talk) 21:12, 13 April 2024 (UTC)[reply]
Can we make AfD notification smart enough to notify the editor who turned an existing redirect into an article, rather than notifying the editor who merely created the redirect?
As a redirect-happy editor, I get these all the time. I make a redirect somewhere because the subject is mentioned, but not independently notable. Some other editor comes along and turns the redirect into an article. A third editor nominated the article for deletion, and who get's the notification? The editor who turned the redirect into an article? No, it's me. How hard is it to make the obvious fix to this? BD2412T 23:16, 7 April 2024 (UTC)[reply]
@BD2412 can you be more specific about this "notification" you are referring to? echo doesn't have a trigger that fires when someone discusses deleting a page. — xaosfluxTalk 23:51, 7 April 2024 (UTC)[reply]
I believe that'd be part of WP:Twinkle. Not entirely sure who maintains the scripts/how to fix this though Soni (talk) 00:13, 8 April 2024 (UTC)[reply]
@BD2412 thanks. Mediawiki doesn't do this in core, and there are many many ways someone could be notified similar to that. In your specific case you seem to be referring to this edit, and that the editor made (possibly unknowingly) a bad edit - correct? That edit claims that it was made with the help of the PageTriage extension, so you may want to report a bug about it. — xaosfluxTalk 00:13, 8 April 2024 (UTC)[reply]
@Xaosflux: (do I need to ping you, by the way? Are you watching the discussion already?) The editor didn't make a mistake; the notice is sent automatically from the editor's account when the editor uses certain tools to nominate an article for deletion. BD2412T 00:29, 8 April 2024 (UTC)[reply]
(yes please use ping I don't use "subscribe" echo notifications) As I noted above, based on the edit tag this user appeared to use an extension to help them make this edit; if this isn't the desired behavior for that extension it can be reported to the extension maintainers using the link I provided above. (Had this been a different tool, such as Twinkle, there would be a different set of volunteers to look in to it). — xaosfluxTalk 00:48, 8 April 2024 (UTC)[reply]
@Xaosflux: Not 100% sure, but it looks like it. That has been unactioned for a long damned time, though. BD2412T 01:05, 8 April 2024 (UTC)[reply]
That happens a lot. And when it is something in software, it needs to be addressed by a limited number of developers for that software (there are currently over 200 open tasks for that extension alone). This is not something that we can fix here on the English Wikipedia. — xaosfluxTalk 01:28, 8 April 2024 (UTC)[reply]
I have long had a similar annoyance, which I have mostly ignored. As an AFC reviewer, I sometimes move a sandbox draft that has been submitted for review into draft space. This creates a redirect from the sandbox to the draft, and I appear to be the originator of the draft. Either six months later, or much later, I get a notice that "my" draft has been deleted as G13, an expired draft. I think that this is the same issue, in which the creation of a redirect confuses Twinkle. Is this the same issue as User:BD2412 is reporting? Robert McClenon (talk) 15:10, 8 April 2024 (UTC)[reply]
Yes, User:Xaosflux, that is what I was describing. If a page that I moved from a sandbox to draft space is ignored for six months, I then get a G13 notice that it was deleted. Yes, I don't consider myself to have been the draft creator, but I do get the notice. No, I do not create the draft by copy-paste. I dislike copy-pastes as much as the admins who have to do history-merge to correct for them. Yes, there is a persistent minor problem with who Twinkle thinks is the author. Robert McClenon (talk) 16:15, 9 April 2024 (UTC)[reply]
Yes, I see that this was first reported five years ago. There is a persistent minor problem that has been around for so long that the bug has the status of a naturalized citizen. Robert McClenon (talk) 16:20, 9 April 2024 (UTC)[reply]
@Robert McClenon thank you, from your notes above this specific error is only coming from Twinkle, correct? Twinkle issues can generally be addressed on-wiki, it just takes someone to write patch for the script. — xaosfluxTalk 17:08, 9 April 2024 (UTC)[reply]
I don't believe that any notification is technically required, the obvious fix would be to get rid of notifications... But I don't think thats what you mean. Horse Eye's Back (talk) 15:59, 9 April 2024 (UTC)[reply]
Actually, if I am the one who turns a redirect into an article, I would want to be notified if that article is nominated for deletion. BD2412T 16:23, 9 April 2024 (UTC)[reply]
The watchlist seem to fill that role for most, personally I almost always hit the little star when making a redirect or unredirecting. Horse Eye's Back (talk) 17:00, 9 April 2024 (UTC)[reply]
Some editors don't use watchlists, and would still like to be notified that their work is being tagged for deletion. Templates on user talk pages are the "gold standard" for notices to editors, and so are required for noticeboards, where pinging is not a substitute. Some editors may not care about these notifications, but other editors either want them or should receive them, so that editors who do not care for them can ignore them. Editors who receive misdirected notifications, as are being discussed here, sometimes ridicule them. Robert McClenon (talk) 04:34, 10 April 2024 (UTC)[reply]
Thank you for mansplaining Templates to me... Including the completely irrelevant information about templates related to noticeboards when we're discussing AfD notification. Next time resist the urge. Horse Eye's Back (talk) 16:17, 12 April 2024 (UTC)[reply]
If you go to ?action=info for any page, you will see a table with various statistics, including two lines about how many people are watching the page, e.g.:
I am finding that the ratio shown here is not at all unusual for older articles, but the first line gets more attention from editors. They think "hundreds of editors are watching this page", when they should be thinking "almost nobody is watching this page". Is there a way we could remove/hide the irrelevant number from this info page? Or should we just change MediaWiki:Pageinfo-watchers to something like "Total number of watchlists (includes inactive editors)"? WhatamIdoing (talk) 04:53, 10 April 2024 (UTC)[reply]
I’m one of those who ‘think "hundreds of editors are watching this page", when they should be thinking "almost nobody is watching this page"’ ... I think we should have that “second line” added to these pages (or replaced the “first line”):
I bet someone here could write a .css script that would blank that out, or rename it to something like "This is the wrong line – ignore it". I checked a bunch of Special:Random pages, and most of them showed no data, due to there being too few people watching the pages. WhatamIdoing (talk) 21:11, 11 April 2024 (UTC)[reply]
For hiding that row on the page information page on Wikipedia, try #mw-pageinfo-watchers { display: none; } in one of the .css files. –Novem Linguae (talk) 22:43, 11 April 2024 (UTC)[reply]
Thanks, @Novem Linguae. That seems to have worked for me. That suggests that iff we ever decided that we wanted to do that globally, it could be done in (e.g.,) global.css. I'm going to try this out for a while. I suspect that I'll like it. WhatamIdoing (talk) 22:32, 12 April 2024 (UTC)[reply]
If it's on <30 watchlists, no number is given for either item (the second item is simply suppressed).
If it's on ≥30 watchlists, an exact number is given for both items.
If the second number is zero, it says "There may or may not be a watching user visiting recent edits" instead of a second number. WhatamIdoing (talk) 23:53, 10 April 2024 (UTC)[reply]
Is there a way we could remove/hide the irrelevant number from this info page? I would not support removing this. Presenting both numbers, and letting the user decide which they want or need, seems like an acceptable status quo here. The less than 30 thing for non admins is for security reasons. Admins can see both numbers at all times. The linked phab ticket mentions changing the second message to mention 30 days explicitly. I could get behind a change like that. –Novem Linguae (talk) 02:05, 11 April 2024 (UTC)[reply]
Under what circumstances do you think it would it be useful for to you to know that the watchlists associated with 1,991 mostly inactive (and sometimes actually dead) include the defunct Wikipedia:WikiProject Contents?
The number of active editors presently watching that page is a single-digit number. I can understand why that number would be useful to know, but not why the first has practical value. WhatamIdoing (talk) 02:56, 11 April 2024 (UTC)[reply]
As far as I can tell, pages can be watched actively, without the user being considered active there - such as through email or syndication. — xaosfluxTalk 08:45, 11 April 2024 (UTC)[reply]
Or by looking at the watchlist but not visiting the links. Nardog (talk) 09:43, 11 April 2024 (UTC)[reply]
I suspect that the scenario Nardog describes is far more common than the one Xaosflux describes. WhatamIdoing (talk) 18:32, 11 April 2024 (UTC)[reply]
That was an argument against hiding the total number of watchers. I was echoing Xaosflux. Nardog (talk) 05:58, 13 April 2024 (UTC)[reply]
I've never spent much time reading about the internal mechanism, but I believe that it works like this:
If you have some pages on your watchlist, and then get permanently locked out of your account, you are "a watcher" for all of those pages forever, even though you can't actually watch anything from that account.
If you have some pages on your watchlist, go to Special:Watchlist, close the tab without clicking on any link or visiting an article at all, and then get permanently locked out of your account, you are counted as "an active watcher" for all the pages on your entire watchlist for the next 30 days (including pages that did not have any changes made, so they weren't listed at Special:Watchlist on the day that you visited that page).
This means that there are 9 active editors with this page on their watchlist, of which an unknown number – but it is quite possibly zero – actually looked at the page in question during the last month.
So Xaosflux says, yes, there may only 9 editors who have that page on their watchlists and actually went to Special:Watchlist at any point during the last 30 days, but maybe a few more people also get e-mail messages about changes to articles on their watchlist, so the "9" might be a slight undercount.
The scenario you describe – visiting the watchlist but not checking every page – is certainly common. The "9" is probably an overcount, if the goal is to know whether anyone actually checked the specific page. WhatamIdoing (talk) 02:54, 15 April 2024 (UTC)[reply]
WhatamIdoing, I don't believe merely viewing the watchlist makes you an active watcher. — Qwerfjkltalk 07:45, 15 April 2024 (UTC)[reply]
You're correct. The count uses the same "first unseen timestamp" data used for highlighting of unseen edits on the history page. If a revision older than the configured age would be highlighted, the user is not counted as having visited recent edits. Viewing the watchlist or history page doesn't reset that, while visiting the page itself will and viewing old revisions or diffs may. Anomie⚔ 11:41, 15 April 2024 (UTC)[reply]
Thanks. I have corrected the errors I introduced last week to Help:Watchlist ("Number of page watchers: 3,644; Number of page watchers who visited recent edits: 29; Number of editors who noticed my error: 0").
The "visited recent edits" should probably be changed to "visited the page recently". I think most editors will interpret this as "checked a diff" (i.e., the edit) instead of "clicked on the article" (e.g., displayed the page via Special:Random). WhatamIdoing (talk) 16:42, 15 April 2024 (UTC)[reply]
Does hovering over the diff with WP:POPUPS count as "visiting" the edit? I rarely click on anything unless the popups diff is unclear, or I want to investigate the history. Suffusion of Yellow (talk) 16:47, 15 April 2024 (UTC)[reply]
That doesn't reset the "first unseen timestamp" (a fact that I've found particularly convenient). WhatamIdoing (talk) 17:43, 15 April 2024 (UTC)[reply]
Personally, I would interpret "visited the page recently" to mean "visited the current version of the page recently". I think the natural assumption is that "page" without a qualifier refers to the current version. isaacl (talk) 16:59, 15 April 2024 (UTC)[reply]
Would you feel the same about "visited the page during the last 30 days"? WhatamIdoing (talk) 17:44, 15 April 2024 (UTC)[reply]
Anchor
I am having trouble putting an anchor at a specific row in List of cover versions of Led Zeppelin songs. In particular, I want an anchor on the song "That's the Way". I tried
| rowspan="4" | {{Anchor|"That's the Way"}} "[[That's the Way (Led Zeppelin song)|That's the Way]]"
but loading the page with the anchor in the URL didn't seem to take me there. I looked at the documentation at Help:Tables and locations § Section link or map link to a row anchor which told me to try
|- id="That's the Way"
but I'm getting the same issue (also, I'm not certain how to encode quotation marks if I go the id on the row route). I'm sure I'm missing something obvious here. Kimen8 (talk) 16:31, 10 April 2024 (UTC)[reply]
This is what I figured. Something with my browser, even caching, who knows. I tried incognito and it didn't work. Good to know the current version works.
Do you know how to escape quotes using the row id anchor? Or should I just use the anchor template in that situation?
You were doing fine putting an anchor. The misunderstanding was in referring to the anchor. Uwappa (talk) 04:49, 11 April 2024 (UTC)[reply]
Table of Contents can't display some statistics symbols
(I'm posting it here since this place gets more traffic than Wikiversity). We have a statistical page in Wikiversity which includes statistical symbols in the headings. While there's no issue with those symbols shown in the body of the page, the Table of Contents is bugged whenever these symbols are used. Does anyone have the solution to this problem? OhanaUnitedTalk page 21:16, 10 April 2024 (UTC)[reply]
This is likely to be T295091, an unresolved bug from November 2021. – Jonesey95 (talk) 21:24, 10 April 2024 (UTC)[reply]
@OhanaUnited: The first problem heading is ==== Haphazard weights with estimated ratio-mean (<math>\hat{\bar{Y}}</math>) - Kish's design effect ==== which contains <math>...</math> markup. The problem that you observe is why our MOS:HEADINGS says For technical reasons, section headings should ... Not contain <math> markup. --Redrose64 🌹 (talk) 22:33, 10 April 2024 (UTC)[reply]
Why doesn't this code work?
I have a script at User:TheTechie/tut.js. The function getText is supposed to return something, but it returns undefined. Even alerting the returned wikitext returns something, but returning it or assigning it to a variable and using it in arcTostill returns undefined.
Browser: Chrome 122.0.6261.137 (either stable or LTS)
Can someone help me here? Thanks --- thetechie@wikimedia: ~/talk/$ 01:34, 11 April 2024 (UTC)[reply]
First off, are you calling getPage from somewhere? I don't see a call to it in the code currently.
Second, have you tried step debugging it in Chrome Dev tools? Press f12, ctrl shift f to search for getpage, place some breakpoints inside by clicking on the line number, then run the code. Hover over variables and hit f10 to see what the code is doing. –Novem Linguae (talk) 02:14, 11 April 2024 (UTC)[reply]
@Novem Linguae Sorry, I meant that getText stores value in a variable called wikitext, which when used in arcTo, is equal to undefined. When the wikitext got in getText is alerted, it returns something, but when the wikitext is assigned to a variable and used in arcTo it is undefined. As for the dev tools thing, I'm currently kinda busy and can't use devtools right now, I will when I get the chance. Sorry for the confusion. thetechie@wikimedia: ~/talk/$ 15:36, 11 April 2024 (UTC)[reply]
I installed your script just now and took a closer look. The getText codepath never runs because nothing calls it. Are you saying you need getText to run so you can set the wikitext variable to something other than undefined? If so you need to put getText( title ); somewhere. –Novem Linguae (talk) 16:07, 11 April 2024 (UTC)[reply]
@Novem Linguae I fixed the call issues, but it still returns undefined. (Hint: To run the offending function, click the TUT in the menu and select "Arc" and enter a page name). Thanks --- thetechie@wikimedia: ~/talk/$ 17:13, 11 April 2024 (UTC)[reply]
Unrelated tip: it's hard for other developers to read your code if you abbreviate. I'd suggest expanding TUT, arc, arch, arcTo, sm, etc. to use their full names. –Novem Linguae (talk) 22:52, 11 April 2024 (UTC)[reply]
getText doesn't have a return statement, so it won't return anything. If you want to make it return Promise<string>, it needs return statements on line 16 and line 31. See promise chaining. – SD0001 (talk) 16:20, 11 April 2024 (UTC)[reply]
@SD0001 and Novem Linguae: update: if I run the function the second time, it gets the variable and it isn't undefined. I'll be looking into this, just wanted to update you both though. thetechie@wikimedia: ~/talk/$ 17:25, 11 April 2024 (UTC)[reply]
Also I appear to have done something on accident which causes the portlet to not appear, even though the function to add a portlet is called. Any help is appreciated. thetechie@wikimedia: ~/talk/$ 21:54, 11 April 2024 (UTC)[reply]
Thanks, but although I see it I don't see a way to get it to change what I see. Doug Wellertalk 10:06, 11 April 2024 (UTC)[reply]
Click the "Time zone" field and select Europe/London. PrimeHunter (talk) 11:39, 11 April 2024 (UTC)[reply]
Which "clock" are you referring to?
Uwappa and PrimeHunter above are talking about the display of times in the watchlist, page history, and other special pages.
If you're talking about the UTCLiveClock gadget ("(S) Add a clock to the personal toolbar that displays the current time in UTC and provides a link to purge the current page (documentation)"), docs at the top of mw:MediaWiki:Gadget-UTCLiveClock.js specify what to add to your common.js or skin.js to change the timezone.
If you're talking about the timestamps shown on comments in discussion pages like this one, there's a CommentsInLocalTime gadget ("(U) Change UTC-based times and dates, such as those used in signatures, to be relative to local time (documentation)") to adjust the display, but I believe you'll have to live with UTC in the editor like the rest of us around the world do.
Is there a way to show all edits by edit summary? Via a web interface. For example, show all edits that contain the string "WP:URLREQ#herbaria4.herb.berkeley.edu" such as Special:Diff/1165643139/1218392247. -- GreenC 13:26, 11 April 2024 (UTC)[reply]
GreenC, you mean other than a SQL query? If it's just for one user you can use this tool. — Qwerfjkltalk 15:04, 11 April 2024 (UTC)[reply]
@GreenC: That tool is in the box at the bottom of your contribs page, fifth from the left as "Edit summary search". --Redrose64 🌹 (talk) 17:00, 11 April 2024 (UTC)[reply]
I should have known about this a long time ago. -- GreenC 17:41, 11 April 2024 (UTC)[reply]
Contributions link dropdown
Resolved
Is there a .css or .js way to disable the dropdown ? - FlightTime (open channel) 14:09, 11 April 2024 (UTC)[reply]
Hi there, I started having this issue today that's making it nearly impossible to edit.
When I click "review your changes" after editing a page, "template parameters changed" appears for EVERY template on the page, even if I have not changed any of them. Here is a screenshot I took (uploaded to Imgur). I tried disabling all my user scripts, and I am still having the issue.
I am using Firefox version 124.0.2, on desktop, and my browser is up to date.
I would really really appreciate any help with this. Thank you so much for any help. HeyElliott (talk) 19:13, 11 April 2024 (UTC)[reply]
Also, it's not an issue with any of my extensions, as I'm still having the issue without extensions. HeyElliott (talk) 19:21, 11 April 2024 (UTC)[reply]
Same thing happens to me. At first I thought I messed up somehow. (I'm using Chrome, so it's not the browser). Nikolaj1905 (talk) 11:07, 12 April 2024 (UTC)[reply]
Hey all, I've left the results of the investigation in the phab task, but this is a one-off disruption because of changes in contents of data-mw attributes of template content wrappers in Parsoid HTML. When cached HTML (generated by older production code) is compared with new HTML (generated by new production code that went out this week), you will see these noisy diffs reported by the visual diff code which compares HTML (not wikitext). But, you shouldn't run into this in subsequent edits. Sorry about the disruption. SSastry (WMF) (talk) 13:43, 12 April 2024 (UTC)[reply]
@SSastry (WMF): Thanks for the explanation. I thought page diffs are based on Wikitext. Can you explain why in this case it is comparing the output HTML instead of the Wikitext? RudolfRed (talk) 19:54, 12 April 2024 (UTC)[reply]
There are two kinds of diffs. One is the wikitext diffs - the kind that is most commonly used. Visual diffs need to compare the rendered output and hence it compares HTML. SSastry (WMF) (talk) 09:26, 15 April 2024 (UTC)[reply]
Thanks so much for your quick fix on this and the reply, I really really appreciate the work y'all do on this site! I've still been having this issue a few times today but I assume that's just because of the cached stuff, and it'll fix itself? (Sorry, I don't know much about caches and HTML and such.)
Thank you again, and I hope you have a great day! HeyElliott (talk) 19:57, 12 April 2024 (UTC)[reply]
Sorry to reply again, but I'm still getting the error often. Do I need to clear my cache or something? Again, sorry, I'm not super knowledgeable on this stuff. Thank you! HeyElliott (talk) 03:20, 13 April 2024 (UTC)[reply]
You don't need to do anything on your end. If the page is edited across the deployment date, that first edit will have this problem in visual diffs. You could forcibly clear the cache of the page via the purge query parameter if you wish and then look at the visual diff again - that should fix the problem in most cases. SSastry (WMF) (talk) 09:29, 15 April 2024 (UTC)[reply]
Missing Article for improvement
This week's Article for improvement seems to have gone missing. There was one last week, and there's one scheduled for next week, but there's none for this week:
citoid (VisualEditor automatic citation generator service) is not working for some refs that used to work. including NY Times. see phab:T362379. Jeremyb (talk) 18:02, 12 April 2024 (UTC)[reply]
Using the search function at the top of the page for a case with a redirect to an anchor brings the reader to the top of the redirected article, not to the anchor, which is not convenient for the reader. Is this behaviour intended? This seems to be a significant down-side of redirect to anchors for me.
The following example is for illustration (the question is not about this specific example): There is a redirect for Facial expression recognition. The search function will show Affective computing as a result. Clicking on it leads to the beginning of this article, which itself does not contain "Facial expression recognition", because the anchor leads to "Facial affect detection". Kallichore (talk) 19:08, 12 April 2024 (UTC)[reply]
I opened phab:T362442 on this. Feel free to voice support there, good chance some search dev is going to say this is a feature not a bug. — xaosfluxTalk 20:55, 12 April 2024 (UTC)[reply]
Issue with Search Feature on Wikimedia
I conducted a search for "Solar eclipse of 2024 April 8" on Wikimedia.
Expecting a concise and accurate description of the page, I was disappointed by the search results.
Upon clicking, I found metadata in Hungarian, which is unusual, as the page is new and not previously associated with Hungarian. Additionally, no image is displayed.
Metadata: Solar eclipse of 2024 April 8
<nowiki>eclipse solar del 8 de abril de 2024; 2024. április 8-i napfogyatkozás; 2024ko apirilaren 8ko eguzki eklipsea; eclipse solar del 8 d'abril de 2024; Sonnenfinsternis...
Could the search feature generate metadata that accurately describes the page's content and include an image from the page? AceSeeker (talk) 23:53, 12 April 2024 (UTC)[reply]
When you search for that string on the English Wikipedia, you get reasonable results, as far as I can see. It looks like you did this search on Wikimedia Commons, which is different from the English Wikipedia, and which editors here are not responsible for. It appears that the Commons page that is the first result uses a template called {Wikidata Infobox}. The page description that you are seeing appears to be the names of the corresponding page as listed on Wikidata at d:Q2620078. I don't know why that template on Commons pulls in that data, but you could ask about it at commons:Template talk:Wikidata Infobox. – Jonesey95 (talk) 00:07, 13 April 2024 (UTC)[reply]
Thank you for prompt response and clarifying that the issue may be related to the template {Wikidata Infobox} on Wikimedia Commons. I'll follow up on the commons:Template talk:Wikidata Infobox page to address this matter. Appreciate your assistance! AceSeeker (talk) 00:25, 13 April 2024 (UTC)[reply]
I opened a phabricator issue about this but then I realised I should have discussed it here first.
So, when using the edit button for the lead section on mobile (I'm on mobile web, I have no idea if the app is different), no section link is included in the edit summary. On the other hand, on desktop when the "Add an [edit] link for the lead section of a page" gadget is used, a section link is correctly added. In my opinion, mobile should be updated to match desktop's behavior. Nickps (talk) 14:09, 13 April 2024 (UTC)[reply]
Not sure if this is the right place, newbie editor.
So I was trying to reset the password for my old account, Lovecodeabc, so I requested password resets. However the resetting of passwords did not work, and it seems that if I send a password reset on Special:PasswordReset for my email, it works, but not for my username. Additionally, the temporary password emailed for the Lovecodeabc account does not work. I just want to have the Lovecodeabc username back. Any suggestions? Lovecodeabc(tm) (talk) 14:12, 13 April 2024 (UTC)[reply]
The only way to reset a password is by email, and only if you had previously registered and confirmed your email to an account before you forgot the password. Special:PasswordReset always requires both a username and a password, and will only send a reset if both of them match. You can also only do one reset per day in most cases. The first username you mentioned does not appear to have an email registered, unless you specifically reconfigured it to be for reset only and not for wikimail. — xaosfluxTalk 14:54, 13 April 2024 (UTC)[reply]
Special:PasswordReset only requires one of username and email address. That's why it says "Fill in one of the fields to receive a temporary password via email". User:Lovecodeabc has not specified a valid email address.[12] The message is different if you have a valid address but have chosen to disallow mails from others. @Lovecodeabc(tm): I guess you entered the email address for Lovecodeabc(tm) and the mail says so, not Lovecodeabc. PrimeHunter (talk) 16:30, 13 April 2024 (UTC)[reply]
Oops, forgot that Send password reset emails only when both email address and username are provided. is off by default! So yes, it will send you reset links for ALL the accounts you have under an email address - but again if the email address was never confirmed to the account it won't. — xaosfluxTalk 16:54, 13 April 2024 (UTC)[reply]
Well, I got a password reset email for Lovecodeabc: The emailLovecodeabc(tm) (talk) 20:26, 13 April 2024 (UTC)[reply]
@Lovecodeabc(tm): I did a test. "This user has not specified a valid email address." at https://en.wikipedia.org/wiki/Special:EmailUser?wpTarget=Lovecodeabc can both mean the account never saved an email address and never confirmed it (see Help:Email confirmation). A temporary password can be sent to an unconfirmed email address. I don't know why the password didn't work for you. It's also odd that your screenshot says "lovecodeabc" with lowercase "l" (unless it's an uppercase "L" in a weird font). The first character of usernames is automatically capitalized. If you wrote it as "lovecodeabc" when the account was created then I don't know whether the lowercase "l" is stored somewhere and can still be retrieved in some situations. Anyway, the account only has 19 edits and can just be abandoned. Special:Contributions/Lovecodeabc only shows unimportant userspace edits and Special:CentralAuth/Lovecodeabc shows no edits at other wikis. If you really want the username then you could try Wikipedia:Changing username/Usurpations. It's usually only for accounts with no edits but rare exceptions are made. First check several times in different browsers that a temporary password doesn't work. PrimeHunter (talk) 23:41, 13 April 2024 (UTC)[reply]
@Suffusion of Yellow: My account is Lovecodeabc, not Iovecodeabc. Sorry for the confusion!
@PrimeHunter: I'll look into Wikipedia:Changing username/Usurpations. I've checked Mozilla Firefox on Ubuntu 22.04 and Safari on iPadOS. Are there any issues with those two browsers? I haven't used Google Chrome to try it yet. (also, isn't Google Chrome based on Chromium/WebKit, same as Safari)?
@Lovecodeabc(tm): Is it possible you also created the account User:Iovecodeabc with your email address and wrote Iovecodeabc at Special:PasswordReset but tried to log in as Lovecodeabc with the temporary password in the mail? That would certainly explain why it didn't work. PrimeHunter (talk) 01:33, 14 April 2024 (UTC)[reply]
Oh yeah, it never occured to me to check the user page of Iovecodeabc! Lovecodeabc(tm) (talk) 01:39, 14 April 2024 (UTC)[reply]
@Lovecodeabc(tm): Everything technical appears resolved now. Lovecodeabc hasn't stored an email address (or has an unknown and unconfirmed address) so it doesn't work to write Lovecodeabc at Special:PasswordReset. Iovecodeabc has stored an email address so it works to either write Iovecodeabc or the email address, but it only sends a password for Iovecodeabc. https://en.wikipedia.org/wiki/Special:EmailUser?wpTarget=Iovecodeabc indicates the email address is not currently confirmed but that can be done as described at Help:Email confirmation. Zzyzx11 wrote there [13] that you need a confirmed email address to reset your password but an unconfirmed stored address is apparently enough for that. Confirmation is required for other email features. PrimeHunter (talk) 02:27, 14 April 2024 (UTC)[reply]
Changing "input element" to "anchor element" and then making anchor elements unselectable
Hi, after the title of articles, and after final rendering, an expression appears as
"translate links from en to fa". Bug scenario is that when we want to select the title, if we suddenly extend the selected region, for example for Wikipedia article, the texts of "Toggle the table of contents" and "en" and "fa" would be in our clipboard. So after pasting the clipboard, the total clipboard text would be:
Toggle the table of contents
Wikipedia
en
fa
To solve this problem, we should apply these styles:
.vector-page-titlebar-toc.translator-equ-wrapper{-webkit-user-select:none;/* Safari */-ms-user-select:none;/* IE 10 and IE 11 */user-select:none;/* Standard syntax */}
But the element type for "en" and "fa" is "input" and we can not make "input elements" unselectable, so please convert "input element" to "anchor element" for "en" and "fa" and then apply the above styles. Thanks, Hooman Mallahzadeh (talk) 16:46, 13 April 2024 (UTC)[reply]
I guess this is related to a userscript, not part of the standard user interface. Without that script installed I don't see quite what you're talking about. I suggest asking at fa:MediaWiki talk:Tofawiki.js or consulting Ebrahim. --Jeremyb (talk) 02:46, 14 April 2024 (UTC)[reply]
Hooman Mallahzadeh: This was proposed here User talk:Ebrahim/ArticleTranslator.js#user-select but was making breakage in some other browser so I applied another solution which supposed to not have the issue which apparently isn't imperfect in your case though I couldn't reproduce your issue. Guess the best way forward is to add your username to a blacklist for the tool so you can develop your own version and after that if your version covers all the use cases on all the different browsers we can merge the versions. Does that sound good? Just please keep your changes to minimum possible for the ease merging back the versions. Thanks −ebrahimtalk 06:27, 14 April 2024 (UTC)[reply]
Ok, I can reproduce this, it only happens on double clicks (and not in triple clicks?), and only happens in Chrome and not in Safari and Firefox. Changing those input elements to editable anchor elements isn't that easy, in fact it initially was like that before this edit and some users weren't able to edit them when needed and having that with user-select: none makes users not able to select the text inside to modify the actual language code. −ebrahimtalk 06:56, 14 April 2024 (UTC)[reply]
@Ebrahim No the problem is not resolved! To correct that, at this page and at the lines 340 and 341, you should convert input element to anchor element like this:
@Jeremyb-phone The problem for the "Toggle the table of contents" persists for all users, this code makes that unselectable.
.vector-page-titlebar-toc{-webkit-user-select:none;/* Safari */-ms-user-select:none;/* IE 10 and IE 11 */user-select:none;/* Standard syntax */}
Would you please do something to apply this style? Thanks, Hooman Mallahzadeh (talk) 08:47, 14 April 2024 (UTC)[reply]
Regarding the user script (not toggle part), unfortunately that solution will disturb the tool on other browsers and things like this can happen on double/triple clicks on Safari (at least it once it used to be). I'm testing with all three browsers (Chrome, Firefox and Safari) but suggestions that have given to me were fixing one browser issue making the other major browsers worse so maybe I can add you to the blocklist of the tool so you copy the script and use your version, then if your solution could work on other browsers on my testing I can apply it to the main script also. −ebrahimtalk 09:23, 14 April 2024 (UTC)[reply]
@Ebrahim Such problems (inconsistencies between browsers) arise from bad design of codes. Maybe you should refactor this Javascript code. Implementing codes layer by layer such that one layer be completely independent of other layers would probably solve this bug and other similar bugs. Hooman Mallahzadeh (talk) 09:49, 14 April 2024 (UTC)[reply]
Hello guys, it's been a few hours and I can't edit any page on Wikipedia not even my userspace. Prior to this, for about 30 mins I had an issue checking the page history revisions of a particular page. While checking the page history, it seemed to glitch with an error saying "Unable to stash Parsoid HTML." I couldn't compare the revisions of other editors. Normally I'd ignore such issues thinking something related to "Wiki Sever" is going on, but now it's getting me worried. Rejoy2003(talk) 14:11, 14 April 2024 (UTC)[reply]
Actually, now it's broken for me on iPhone. GoutComplex (talk) 14:36, 14 April 2024 (UTC)[reply]
I see page history perfectly, but it's just editing that won't work for me on PC. It works fine on phones. GoutComplex (talk) 14:33, 14 April 2024 (UTC)[reply]
Well I'm on phone, I can't edit nor check history properly apparently due to "glitching." Rejoy2003(talk) 14:36, 14 April 2024 (UTC)[reply]
I'm also getting ""Unable to stash Parsoid HTML" on Chrome on Windows 11. Same thing on Firefox on Windows 11. Looks like Microsoft Edge on Windows 11 works properly.
On Android 14, I get a different error, "Error, can't load the editor". ReferenceMan (talk) 14:37, 14 April 2024 (UTC)[reply]
After 1 successful edit, Microsoft Edge now gives the same error, "Unable to stash Parsoid HTML."
Same issue, Firefox on Windows 10. Mrchikkin (talk) 14:42, 14 April 2024 (UTC)[reply]
Okay I can edit now, but still there's still minor glitch or bug (along with the Parsoid HTML pop-up) while checking some history of some pages. I tried to login into my account through Opera browser, the good thing is I can edit back. Probably something's up with Google chrome or Firefox. Rejoy2003(talk) 14:45, 14 April 2024 (UTC)[reply]
Same here, the visual editing is not opeing on my phone, and opening sometimes on Desktop. Grabup (talk) 15:17, 14 April 2024 (UTC)[reply]
I'm also getting the same error message saying, "Unable to stash Parsoid HTML". But what's weird is I tried using the Legacy renderer instead of the Parsoid; But it still says: "Unable to stash Parsoid HTML". I don't understand how come a problem with the new Parsoid renderer, could be effecting the Legacy renderer also. 𝓥𝓮𝓼𝓽𝓻𝓲𝓪𝓷24𝓑𝓲𝓸 (ᴛᴀʟᴋ) 15:20, 14 April 2024 (UTC)[reply]
Whatever the problem was, it seems like its fixed now. Both visual and wikitext editors are now working in both renderers. 𝓥𝓮𝓼𝓽𝓻𝓲𝓪𝓷24𝓑𝓲𝓸 (ᴛᴀʟᴋ) 15:24, 14 April 2024 (UTC)[reply]
Still not working on mobile. Grabup (talk) 15:26, 14 April 2024 (UTC)[reply]
Same here not working for me too (Android 13 user). Rejoy2003(talk) 15:35, 14 April 2024 (UTC)[reply]
I think (though I'm not totally sure) that if you have an account/membership you can still access the pages. — Qwerfjkltalk 07:44, 15 April 2024 (UTC)[reply]
I believe that File:2024 Total Solar Eclipse (NHQ202404080102).jpg taken by NASA photographer is superior to the image now in the infobox of the article. In particular, it shows the Solar prominences much more clearly. However, I cannot figure out how to replace the image in this particular infobox. By the way, the photo was taken in Dallas, not in Indianapolis where the current image was taken. Any assistance would be appreciated. Thanks. Cullen328 (talk) 00:11, 15 April 2024 (UTC)[reply]
Zaathras and Suffusion of Yellow, thank you very much. I have been editing for 15 years and have never edited a module, and would have no idea how to do so. Cullen328 (talk) 00:38, 15 April 2024 (UTC)[reply]
I have no idea why it has to be so complicated. LOL. Complexity is the enemy that looks like a friend. -- GreenC 18:05, 15 April 2024 (UTC)[reply]
@Cullen328 I'm oppose this change because the image you're proposing has noticeable noise around the corona. In addition, there is already an image of the solar eclipse in Dallas, Texas in the gallery. √2(talk) 06:03, 15 April 2024 (UTC)[reply]
sounds like the technical question is resolved and now it's an editorial issue. take it to the article's talk page? Jeremyb (talk) 06:51, 15 April 2024 (UTC)[reply]
However, Indiana was the most viewed state for the eclipse and now this Wikipedia page is making it look like it wasn't.
Although the photo from Dallas shows the finer details, the photo from Indianapolis shows us a greater aesthetic and the fact that Indianapolis was the hotspot for viewing the eclipse based on weather throughout the day and a bloom in tourism.
And it was the first total solar eclipse for Indianapolis since September 14, 1205.
And if it weren't for the weather forecast ahead of the event, Texas would've had more visitors than it did as many went to Indiana for the best spots. Eric Nelson27 (talk) 23:00, 15 April 2024 (UTC)[reply]
Tables next to each other
Is there a way to put two tables next to each other instead of having one underneath the other? Flaming Hot Mess of Confusion (talk) 00:59, 15 April 2024 (UTC)[reply]
I discovered recently that floating tables is disabled in mobile using !important in the CSS. So those two tables are arranged vertically in mobile view, despite being so narrow. I discovered this when trying to make a template more responsive. — Jts1882 | talk 12:50, 15 April 2024 (UTC)[reply]
Hmm, weird. Yes, tables arranged vertically even if plenty of horizontal space available.
Hi, you might be aware that pagelinks table is being normalized (phab:T299947). I want to give enough time before dropping the columns. So here is the notice that the data has been fully populated in all Wikis except Turkish Wikipedia and Chinese Wikipedia (and these two wikis will finish in roughly a week). This means if you have tools or database reports in English Wikipedia that relies on pl_namespace or pl_title, you need to switch them to use pl_target_id ASAP. The rough estimate is that the old columns will be gone in a couple of weeks.
I was asked to make an explicit note here (one and two). Let me know if you have any question in the ticket. Thank you and my apologies for inconvenience. You can read more why we need to do this in phab:T222224. Best ASarabadani (WMF) (talk) 12:18, 15 April 2024 (UTC)[reply]
Thank you for the notification. Like the earlier templatelinks change, this will break to many on- and off-wiki tools (some of which may be unmaintained), and it's difficult to assess the likely scope of the damage. Here is a list of affected {{database report}}s, but there are plenty of other ways to use the table such as Quarry. Pinging R'n'B, who will probably be one of many with work to do. Certes (talk) 12:30, 15 April 2024 (UTC)[reply]
Thanks. I'm aware. Hope to update scripts before the end of this week. --R'n'B (call me Russ) 20:58, 15 April 2024 (UTC)[reply]
@ASarabadani (WMF): Would it be possible to add a view to the database which simulates the old pagelinks table by joining the new pagelinks table to linktarget? Then, updating our software would be as simple as replacing the word pagelinks by the name of the new view throughout. We would need to check that the performance hit of using the view is not significantly worse than what we will suffer anyway by adding the linktarget table explicitly. Certes (talk) 20:07, 15 April 2024 (UTC)[reply]
I got a notification recently that there were recently multiple failed attempts to access my account, so I looked into enabling some kind of MFA. Allowing this for most/all users seems sensible since it would help prevent account compromises, and mult-factor auth is pretty common these days.
@Catleeball: Notifications of the kind you mention merely mean that somebody went to Special:UserLogin, entered your username, then had at least one try at guessing your password, and failed. This sort of thing happens to most of us from time to time, and is rarely worth worrying about - unless you habitually log in somewhere public, where somebody might be watching over your shoulder to see what you type. The way that I deal with it is to (i) always log out when finished editing, this kills all login cookies (regardless of which device they are stored on); (ii) change password from time to time, always doing so when in a private location; (iii) always use a strong password; (iv) don't use the same password on any other website (but note that because of WP:SUL, your password at French Wikipedia, Commons, Meta, Wiktionary etc. will always be the same as your English Wikipedia password). --Redrose64 🌹 (talk) 22:51, 15 April 2024 (UTC)[reply]
2FA is allowed for all users, just follow the instructions at meta:SRGP. It may seem like a pointless song-and-dance, but the idea is that saying "I have read the instructions" to a human has a greater effect than clicking an "I have read the instructions" button on a form. You'll be more likely to take the importance of backups seriously, and less likely to waste people's time after you lock yourself out of your account. I don't if that actually works in practice. Suffusion of Yellow (talk) 23:17, 15 April 2024 (UTC)[reply]
Did you mean to link the page for stewardship requests when you put meta:SRG there?
I saw that the oathauth testers group was allowed to sign up at Special:OATH, but I wasn't finding where in the documentation it said how to self-enroll for that group. Catleeball (talk) 23:28, 15 April 2024 (UTC)[reply]
I fixed the link; that should be Meta:SRGP#Requests for 2 Factor Auth tester permissions. However, so long as you have a strong password that you do not use on any other site, you should be fine. You don't have any advanced permissions, so anyone attacking your account is going to move on to the next one after a few tries. The only exception is if there is a "catleeball" (or similar) account out there on some other site, with the same (or similar) password. If that site has been compromised, then it might only take a few tries to get in to your account. Suffusion of Yellow (talk) 23:48, 15 April 2024 (UTC)[reply]
Tech News: 2024-16
Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.
Problems
Between 2 April and 8 April, on wikis using Flagged Revisions, the "Reverted" tag was not applied to undone edits. In addition, page moves, protections and imports were not autoreviewed. This problem is now fixed. [14][15]
Changes later this week
The new version of MediaWiki will be on test wikis and MediaWiki.org from 16 April. It will be on non-Wikipedia wikis and some Wikipedias from 17 April. It will be on all wikis from 18 April (calendar). [16][17]
Default category sort keys will now affect categories added by templates placed in footnotes. Previously footnotes used the page title as the default sort key even if a different default sort key was specified (category-specific sort keys already worked). [18]
A new variable page_last_edit_age will be added to abuse filters. It tells how many seconds ago the last edit to a page was made. [19]
Future changes
Volunteer developers are kindly asked to update the code of their tools and features to handle temporary accounts. Learn more.
Four database fields will be removed from database replicas (including Quarry). This affects only the abuse_filter and abuse_filter_history tables. Some queries might need to be updated. [20]
Why does the talk page visual editor not have a "cite" button?
Am i missing something, or is it impossible to automatically cite urls from the talk page visual editor? Yes, you can use the source editor, but is there a specfic reason why this is? Is there any way to get a more featured editor on the talk page visual editor? MarkiPoli (talk) 12:14, 16 April 2024 (UTC)[reply]
Not sure if it's intentional, but the keyboard shortcut Ctrl+Shift+K (Cmd+Shift+K on macOS) still works for this. the wub"?!" 13:17, 16 April 2024 (UTC)[reply]
RfC: Converting all current and future community discretionary sanctions to (community designated) contentious topics procedure
Should all community discretionary sanctions (DS) be updated to use the new contentious topics procedure? AwesomeAasim Refreshed 01:18, 8 March 2024 (UTC) 05:55, 7 February 2024 (UTC)[reply]
Background
In late 2022/early 2023, the discretionary sanctions procedure was overhauled by ArbCom and converted to "contentious topics". With now two different processes for two different kinds of sanctions there is now a lot of fragmentation and inconsistency in how contentious topics should be handled, with even conflicting wording. The main goal of this RfC is to unify the procedure used for all areas where general sanctions are in effect with the one designated by ArbCom, going forward.
As proposed at this time, there will be the some similarities and differences between community and arbitration contentious topics, including:
The imposition of the standard set of restrictions by consensus of administrators in a community designated topic would be at WP:ANI rather than WP:AE.
Reconsideration of contentious topic restrictions would be done at WP:AN instead of at WP:AE or WP:ARCA.
Awareness of a community contentious topic would include but not be limited to being mentioned in the discussion closing summary regarding that contentious topic, which is the closest there is to a "final decision".
And of course, ArbCom would be able to convert community contentious topics to those designated by the committee, after which all the ArbCom venues would have to be used from that point forward, though existing restrictions would remain appealable to WP:AN until renewed at ArbCom.
Survey (community contentious topics)
Support as proposer. It needs to be clear, especially for new editors, what contentious topics are and what the expectations are for editing topics designated as contentious by either ArbCom or the community. A unified procedure will ensure consistency rather than fragmentation and will make editing the list of contentious topics and their restrictions much easier. (I did do a little bit of work in the Module:Sanctions/sandbox adding in support for ArbCom contentious topics, as it would make it so much easier to use the related sanction templates. I also did work in user space to help envision what a unified contentious topics page might look like.) AwesomeAasim 05:55, 7 February 2024 (UTC)[reply]
Strong Oppose The current iteration of WP:CTOP is far too tied in to the Arbitration Committee. The available sanctions and procedures are under the jurisdiction of WP:AC/PR can be modified by the Committee by motion at any time, which in this scenario would be binding on decisions made by the community without community consensus. Additionally, many of the General Sanctions areas have a set of restrictions that either exceed what CTOP would allow, or have a more limited subset of them. The community currently has the flexibility to customize sanctions based on the needs of the individual topic area (similar to how Arbcom can impose their own restrictions either alone or on top of the CTOP designation), rather than relying on a "one size fits all" solution. Regarding the possibility of Arbcom choosing to convert community-based CTOP to Arbitration Enforcement, the Committee already has the power to supercede and convert General Sanctions. They've done so before, in cases including WP:ARBCC and WP:ARBTPM. This proposal as written would reduce the community's autonomy and flexibility for the sake of consistency, and I don't see that as a net positive.I would, however, support the community adopting a "standard/default" DS language that could be used when customization isn't needed, and reviewing all the existing GS areas to see if they should be abolished or modernized. Updating our own process, templates, info pages etc to completely separate from the Arbcom version would also accomplish this proposal's goal of reducing confusion and would be better than the current system of sometimes linking to CTOP, sometimes linking DS which redirects to CTOP (when they really mean the older version of DS), sometimes a completely different thing with no consistency. Template:Gs/alert is one example of this, where it links to WP:CTOP even when the actual restrictions are unrelated to that designation. Revamping our own procedures would be a better way to reduce fragmentation and confusion than glomming onto what Arbcom chooses to do. The WordsmithTalk to me 18:32, 7 February 2024 (UTC)[reply]
I am not exactly seeing how this is a dealbreaker. The CT procedure applies only to designated contentious topics; community consensus or arbitration remedies can always add additional sanctions regardless of WP:CTOP like in WP:ARBPIA. AwesomeAasim 22:13, 7 February 2024 (UTC)[reply]
Support The phrase "discretionary sanctions" is not clear and so the phrase "contentious topics" was introduced as an improvement. We should have clear and consistent language for contentious matters so that discussions and actions are comprehensible. Andrew🐉(talk) 08:57, 10 February 2024 (UTC)[reply]
Support. The "sanctions regimes" are too complex as it is, and we need to use consistent terminology to reduce that complexity when possible. — SMcCandlish☏¢ 😼 13:03, 21 February 2024 (UTC)[reply]
Support making the rules clear and consistent to all users. A big part of the problems I've had with DS is that I couldn't tell what was expected of me. No comment on whether this new way of doing things is better or worse than the old one, but it sounds like this isn't that conversation. I 100% support clear and proactive explanations of what Wikipedia does and does not want from its editors. Darkfrog24 (talk) 16:10, 9 March 2024 (UTC)[reply]
Support making the rules clear and consistent for all editors. Let'srun (talk) 19:33, 10 March 2024 (UTC)[reply]
Support standardization — as is, the current discrepancy is an unintended relic, not a feature. Community-imposed vs Arbcom-imposed sanctions is a clerical, technical distinction, and I cannot think of any good reason not to streamline the two into the same concept, for the sake of simplicity and understanding. ~Swarm~{sting} 02:39, 12 March 2024 (UTC)[reply]
Support Contentious topics is confusing enough by itself. Two similar but not identical rules is too much. I support any efforts to standardize our sanction systems. Galobtter (talk) 02:53, 12 March 2024 (UTC)[reply]
Support in the abstract – it might require some case-by-casing, but I think in general, having one set of rules for everyone is much cleaner and easier to understand for those trying to follow the road. theleekycauldron (talk • she/her) 00:00, 17 March 2024 (UTC)[reply]
Oppose (despite abstract support) as ANI has generally been the wrong forum for General Sanctions work. In my mind it should be a pump or AN and ANI should be out of the whole system. I also think it's a missed opportunity to not allow community GS to be heard at AE. There is already the community option for AN but this proposal would have created the option of using AE which is the forum many think about anyway. Outside of these details I'm supportive of the effort (given the fact that amongthe few who have expressed an opinion there seems to be overall support). Barkeep49 (talk) 14:55, 21 March 2024 (UTC)[reply]
Would you support having community contentious topics use the ArbCom noticeboards instead? AwesomeAasim 17:35, 29 March 2024 (UTC)[reply]
That seems like it would be confusing using Arbitration Enforcement, since some sanctions would be relevant to Arbcom and some wouldn't. There's a workable idea in here somewhere, and I think unifying all the sanctions noticeboards into one venue is it. There used to be Wikipedia:Community sanction noticeboard where appeals were heard, before it was retired in 2007 and merged into AN. Having something like a Wikipedia:Sanctions noticeboard that merges General Sanctions enforcement/appeal, requests for new General Sanctions areas that are now at the Village Pump, Arbitration Enforcement/CTOP, and topic ban enforcement into one unified board. The structure of requests there should probably mirror the current AE pretty closely, since that format seems to work better than the free-for-all unstructured discussion at other boards. The WordsmithTalk to me 18:28, 29 March 2024 (UTC)[reply]
If I recall correctly ArbCom has authorized the use of AE for community general sanctions using DS/CT. Is that still the case or was I wrong the whole time? But that is what I refer to "using ArbCom noticeboards". AwesomeAasim 05:08, 30 March 2024 (UTC)[reply]
Thanks, so just a really misleading title. Reaffirm oppose though, we should not abandon a community process further in to arbcom. — xaosfluxTalk 17:46, 1 April 2024 (UTC)[reply]
My apologies for being overly concise in my previous comment: the proposal isn't to abandon community-authorized discretionary sanctions, but to align its procedures with the contentious topics procedures. It would remain under community control, with the changes to procedure that were introduced as part of contentious topics (such as a standard set of restrictions, sanctions no longer being limited to a year, only one template-based notification required for the first notification about contentious topics). isaacl (talk) 17:57, 1 April 2024 (UTC)[reply]
This is still a very confusing proposal, as it is not very clear about what exactly it wants changed. For example, I can't see why something that has nothing to do with arbcom remedies would need to be recorded at Wikipedia:Arbitration enforcement log (per the WP:CTOP requirements that this proposal appears to to merge in). — xaosfluxTalk 10:31, 2 April 2024 (UTC)[reply]
Further development of the details do still need to be worked out. Community-authorized discretionary sanctions was defined by pointing to the arbitration committee discretionary sanction pages and saying, like that, but with a few differences. When those pages were renamed, that left a hole. In my view, ideally the community would define its preferred base procedure, and then the arbitration committee could point to it and say like that, but with a few differences. Those differences could include locations of logs and appeals (this proposal does explicitly specify a different location for appeals). I appreciate the viewpoint of those who would prefer to have a separation based on the group responsible for the designation of a contentious topic. But maybe that purpose can be served another way, such as a lookup table with appropriate links to the specifics for each variant. From the perspective of users encountering the concept of discretionary sanctions/contentious topics for the first time, I feel it's confusing to be using both the older version and the newer version of the process simultaneously. isaacl (talk) 15:39, 2 April 2024 (UTC)[reply]
Which is why I'm leaning that this is a bad proposal. It should have been work-shopped more first. Make X like Y, but not really like Y is messy. — xaosfluxTalk 14:09, 3 April 2024 (UTC)[reply]
Support it will be easier to understand the community-imposed restrictions and could allow the same templates to be used to make the process more unified. Dreamy Jazztalk to me | my contributions 18:03, 1 April 2024 (UTC)[reply]
Conditional support "Discretionary Sanctions" needs to be deprecated – the phrase is archaic, bureaucratic, and meaningless. However, the noticeboard should not be ANI (per Barkeep), since that place is a mess, whereas sanctions enforcement should be more clear-cut than the usual ANI fare. Toadspike (talk) 09:48, 3 April 2024 (UTC)[reply]
Support unifying community discretionary sanctions under the contentious topics procedure as it promises to significantly simplify Wikipedia's administrative framework, especially for new users. Adopting one coherent, streamlined process will mitigate the confusion and frustration associated with understanding the diverse existing sanctions systems. FailedMusician (talk) 21:48, 12 April 2024 (UTC)[reply]
Discussion (community contentious topics)
Cooperation of ArbCom
I wonder if adding in stuff to the WP:CTOP page and similar would require the petition and referendum process. If so, then I guess the merging of templates would have to hold off until a former petition and request for amendment actually passes. It is possible ArbCom will green light the merge if this RfC passes, but I do not know. AwesomeAasim 05:55, 7 February 2024 (UTC)[reply]
I feel the community should work with the arbitration committee to assume responsibility for the contentious topic process, with a pointer to an arbitration-committee specific page where it can customize the process as it feels necessary. This would bring the process under community control, while still allowing the arbitration committee to adapt it to its needs. (There is no change to arbitration policy and so no need to amend it.) isaacl (talk) 19:07, 7 February 2024 (UTC)[reply]
Wouldn't that just be the status quo (or perhaps the old GS/DS) status quo? I think Arbcom is more agile than the community in drafting this kimd language given that passing a motion is easier than an RfC and motions can be adjusted mid vote which is nearly impossible to do with an RfC. Truthfully I think the right place to start is with the standardized language for community GS and perhaps to be more intentional about whether it wants its restrictions to be eligible to be heard at AE, though as The Wordsmith points out there are really good reasons for the community to decide not to do that. Barkeep49 (talk) 04:30, 9 February 2024 (UTC)[reply]
The process for authorizing discretionary sanctions was documented by the committee, and then later the community started authorizing discretionary sanctions, with its process pointing to the Arbitration Committee pages and saying, "like that". This resulted in the community's process being coupled to decisions made by the arbitration committee. I'm suggesting the reverse: have the community assume responsibility for the contentious topics process, and then the arbitration committee can point to it and say, "like that, but with our specific customizations". I agree the community can decide on its own on what contentious topic process it wants to create. I think it would be good, though, to check with the committee that it is amenable to adopting the community process as a base, and layering any desired differences on top. isaacl (talk) 04:52, 9 February 2024 (UTC)[reply]
That also sounds like a good idea: community authorizes the remedies that are appropriate, ArbCom implements them. If ArbCom were to deviate then they would just need to ask the community whether it is an appropriate deviation or not. AwesomeAasim 17:28, 9 February 2024 (UTC)[reply]
The committee doesn't have to be constrained by the community as it is already authorized through the arbitration policy to enact remedies of its devising for matters within its scope. It would be simpler for editors to understand, though, if the arbitration committee version of the process was just a set of differences upon a common process. Differences could include things like additional administrator actions that could be performed, or a specific venue for appeals. isaacl (talk) 18:03, 9 February 2024 (UTC)[reply]
I think you know what I mean :)
WP:ARBECR is already used a lot by both the community and by ArbCom, like in WP:RUSUKR and WP:CT/A-I. What I am saying is if ArbCom feels that a specific sanction that there has never been any precedent for is necessary, they should propose it to the community, where there then can be consensus on the exact wording. Placement, enforcement, and appeals are all going to differ though depending on whether the restriction is placed by the community or ArbCom. AwesomeAasim 18:43, 9 February 2024 (UTC)[reply]
The community can provide feedback on proposed decisions. I disagree that the committee needs to obtain community consensus on new types of remedies. The arbitration committee is empowered to impose a restriction that community consensus has been unable to reach through prior dispute resolution. If you are referring specifically to the standard set of restrictions that can be imposed for designated contentious topics, I still disagree that community consensus should be mandatory. Typically the committee will provide an opportunity for feedback and the last review of discretionary sanctions illustrates that it strives to lighten the load of enforcing administrators. isaacl (talk) 19:17, 9 February 2024 (UTC)[reply]
Regarding the extended-confirmed restriction, it was initially devised by the committee on its own. After taking some time to evaluate its effectiveness, the community chose to adopt it as an available restriction. isaacl (talk) 19:25, 9 February 2024 (UTC)[reply]
I agree with isaacl that ARBPOL and CONEXEMPT explicitly mean that the committee does not have to, with-in its scope, get community consensus. However, ECR is a example of why I think the committee is better placed at the moment to be a leader when it comes to contentious topics. The committee having to deal with the absolute hardest conflicts means there is going to be more of an incentive to try something new and ~15 people are going to have an easier time getting to yes than what is required to get community consensus for that newness. It's also revealing to me that ArbCom gets more requests for us to assume community imposed sanctions (examples: COVID, Horn of Africa as two that the committee did assume and Russia-Ukraine War as one that committee has twice been asked to assume and haven't). I would really love it if the community could, as it does in so many other ways, demonstrate broader capabilities when it comes to general sanctions than it has in the past. And to that end getting consensus for some standard wording would be a great place to start. Barkeep49 (talk) 19:48, 9 February 2024 (UTC)[reply]
I agree that the arbitration committee is better positioned to try new approaches (consensus doesn't scale up well, so getting consensus amongst 15 people is definitely easier). In a similar vein as you expressed, I feel it would be ideal for the community to agree on a base contentious topics process, which the committee could extend in new ways that the community could later choose to incorporate back into the base process. isaacl (talk) 19:57, 9 February 2024 (UTC)[reply]
In WP:DS2022, one of the changes made was to allow the community to make use of AE. I think we should do so. HouseBlaster (talk · he/him) 03:42, 9 February 2024 (UTC)[reply]
I definitely think we should split contentious topics from WP:AELOG. A separate contentious topics log would make restrictions much easier to follow - and, if the restriction is rescinded or converted from community to ArbCom or the other way around - it can be logged as well. AwesomeAasim 21:21, 10 February 2024 (UTC)[reply]
Request revision to initial question
The statement all community general sanctions (DS) in the initial question is misleading. "General sanctions" is not synonymous with community authorization for discretionary sanctions. I think the intent should be clarified that the proposal only affects discretionary sanctions authorized by the community, and not all general sanctions. isaacl (talk) 19:03, 7 February 2024 (UTC)[reply]
I refreshed the RfC tag because there is not enough input to gauge consensus. Could this be because this is uncontroversial or what? AwesomeAasim 19:58, 8 March 2024 (UTC)[reply]
I think it's because many editors simply don't know what's going on. I didn't know this discussion was taking place. I'm still not sure what the change in policy is, only that, if it has been changed, the system should be clear about it. Are we dissolving Discretionary Sanctions? Is AE not going to be a thing any more? Is it merging with ANI? Darkfrog24 (talk) 22:37, 17 March 2024 (UTC)[reply]
@Darkfrog24 The question is really just about making community sanctions use the new contentious topics procedure. AwesomeAasim 23:45, 17 March 2024 (UTC)[reply]
Okay. What is the new CT procedure? Do you know how it's different? I just read through one of the links that Newslinger provided above, and I'm having trouble picking out differences. Darkfrog24 (talk) 00:35, 18 March 2024 (UTC)[reply]
For full details, see Wikipedia:Contentious topics. It's basically a renamed version of discretionary sanctions, with changes made based on community feedback received during the 2021–22 review of discretionary sanctions. Some highlights: there is a standard set of restrictions that a single administrator can impose on their own discretion. Restrictions outside of these can be imposed by a consensus discussion at the arbitration enforcement noticeboard. Sanctions are no longer limited to one year, but after a year, sanctions that were imposed by a single adminstrator no longer have to be discussed at the arbitration enforcement noticeboard to be modified. Users no longer have to be made aware of each specific topic area. They only have to be notified once using a specific template about the contentious topic system. Striking out inaccurate description. isaacl (talk) 01:56, 18 March 2024 (UTC)[reply]
Users no longer have to be made aware of each specific topic area. They only have to be notified once using a specific template about the contentious topic system. That would contradict the CTOP regime. Even among the Arbcom sanctions, editors still have to be notified about topic areas individually. The WordsmithTalk to me 19:54, 18 March 2024 (UTC)[reply]
My apologies; I misspoke. A specific template only has to be used for the first notification about the contentious topic system in general. Subsequently, any form of notification can be used to inform a given user about specific contentious topics. Previously, a specific template had to be used for each affected topic area. isaacl (talk) 21:22, 18 March 2024 (UTC)[reply]
Again, not all community sanctions, but community-authorized discretionary sanctions. isaacl (talk) 01:36, 18 March 2024 (UTC)[reply]
Create an alias for the Template namespace
I am proposing that tp: be added as an alias to the Template: namespace per this discussion.
Note: Though previous aliases were already listed on perennial proposals, it proposed t:, which would have conflicted with some article titles, or be confused with the Talk: namespace. Tp:, on the other hand, wouldn't, and would make it way quicker to look up a template in the search bar.
Edit (during rfc): tp: was not fully supported due to it being confused with "Talk Page", however other options were proposed, like hard coding {{ being replaced by Template: in the search bar, or other aliases like tmp:.Cocobb8 (💬 talk • ✏️ contribs) 15:19, 16 March 2024 (UTC)[reply]
Oppose "Template" is not a long word, and nobody abbreviates it as "tp" these days. This seems pointless. * Pppery *it has begun... 15:27, 16 March 2024 (UTC)[reply]
I just thought it'd make it consistent with wp: for Wikipedia:, which is 10 characters, while Template: is 9 characters. Cocobb8 (💬 talk • ✏️ contribs) 15:29, 16 March 2024 (UTC)[reply]
Nobody abbreviates it as "tp" these days. Even if that is true it is not a reason for us not to do so. Wikipedia is big enough to be making fashions rather than following them. Phil Bridger (talk) 21:16, 16 March 2024 (UTC)[reply]
Support I'd find it useful. It's less effort to type "tp:infobox person" in the search box than "template:infobox person" (which is how I usually navigate to wp: and template: pages). Schazjmd(talk) 15:52, 16 March 2024 (UTC)[reply]
Support I'd absolutely love this. I've often wondered if there was some technical problem that was preventing us doing this. Usedtobecool☎️ 16:00, 16 March 2024 (UTC)[reply]
Support: Pretty nice QOL change. Per Schazjmd. ARandomName123 (talk)Ping me! 16:35, 16 March 2024 (UTC)[reply]
I don't think it's a good idea to create an alias (and implicitly creating more English Wikipedia jargon) just to improve the search function. We should instead improve the search capability directly. isaacl (talk) 17:41, 16 March 2024 (UTC)[reply]
Yeah, but you don't want a casual reader to be confused as to why they ended up on a template page Cocobb8 (💬 talk • ✏️ contribs) 17:42, 16 March 2024 (UTC)[reply]
It would be a lot easier for the casual user to stumble upon a namespace alias, which could happen anywhere they enter an URL that might trigger a browser to launch, than for them to deliberately select the search box and type there. Furthermore, if this isn't intended to be used by a broad audience, then a more targeted solution would be better. Users wanting this functionality can make use of the script to which you were pointed in the previous thread, or they can configure their OS to provide an appropriate macro expansion to shorten the number of keystrokes they use. isaacl (talk) 18:08, 16 March 2024 (UTC)[reply]
"tp" seems very easily misconstrued as "Talk Page" at a glance. CMD (talk) 18:12, 16 March 2024 (UTC)[reply]
Good point. Sdkbtalk 18:22, 16 March 2024 (UTC)[reply]
Support I've been wanting this. It really is irksome to type out "Template:" I since learned today there are scripts, and of course {{tld}} for talk pages, but it would be much cleaner and simpler to have a standard abbrev. and this is technically easy to implement. TP: or T: it doesn't matter they both are fine. I prefer T: -- GreenC 18:56, 16 March 2024 (UTC)[reply]
Oppose For the reasons in WP:PEREN#Create shortcut namespace aliases for various namespaces. In particular, the Template namespace is generally not linked often enough that saving the typing of 6 characters is likely to be at all worthwhile and there's nothing available to use for the corresponding talk pages. Anomie⚔ 20:00, 16 March 2024 (UTC)[reply]
there's nothing available to use for the corresponding talk pages See Nirvana fallacy. — Frostly (talk) 06:29, 5 April 2024 (UTC)[reply]
The template for linking a template is called {{tl}}. Shouldn't we have some consistency between this and the short-cut? Or is "tl" already used? Phil Bridger (talk) 21:16, 16 March 2024 (UTC)[reply]
{{tl}} is short for {{template link}}, so the el doesn't have anything to do with templates qua templates. jlwoodwa (talk) 04:31, 18 March 2024 (UTC)[reply]
Support – While there are helpful template shortcuts, like {{t}} and its siblings, that can be used in discussions, and a script that can be used in the on-wiki searchbox to convert {{ to Template:, a namespace shortcut (tp:) would help in edit summaries and customised browser search boxes. -- Michael Bednarek (talk) 23:55, 16 March 2024 (UTC)[reply]
Oppose Adding layers of obfuscation is not helpful. If I want to refer to {{convert}}, writing Template:Convert is easy and helpful to someone reading my comment. Writing Tp:Convert is unnecessary jargon that saves under a second of typing at the cost of head-scratching for readers. tp would be "talk page" for many. Johnuniq (talk) 01:00, 17 March 2024 (UTC)[reply]
Oppose As someone who has next to no involvement with template editing, I immediately think of 'talk page' when I see 'tp'. It would confuse many people who edit outside of the technical areas of Wikipedia. (Summoned by bot) JML1148(talk | contribs) 06:57, 17 March 2024 (UTC)[reply]
Rename the template mainspace from "Template:" to "Plantilla:" and use "Pl:" as a shortcut CactiStaccingCrane (talk) 18:02, 18 March 2024 (UTC)[reply]
That would be quite a big change, but I'm not against it lol Cocobb8 (💬 talk • ✏️ contribs) 19:50, 18 March 2024 (UTC)[reply]
But this is in español ROTFL -- ZandDev 13:45, 20 March 2024 (UTC)[reply]
Yeah there's no way we'll get consensus on that one Cocobb8 (💬 talk • ✏️ contribs) 13:46, 20 March 2024 (UTC)[reply]
Yea, no. Also even on eswiki that uses that namespace name this couldn't happen as Pl is ISO639 for Polish. — xaosfluxTalk 09:40, 21 March 2024 (UTC)[reply]
Soft Oppose I'd support hard-coding {{→Template: into the search box's autocomplete natively rather than using my script as a hack, but I agree that the widespread use of links like TP:Example are an unnecessary layer of obfuscation/jargon. With the WP prefix, at least the shortcut links are mostly self explanatory, but it wouldn't be obvious to a newcomer what, for example, tp:birds is, or why it's not an article. --Ahecht (TALK PAGE) 18:17, 18 March 2024 (UTC)[reply]
@Ahecht Yes, hard-coding that directly could be a great alternative. I just think that we need to find a solution for this, and maybe tp: wasn't the best as others have pointed out. I'll continue gathering some ideas and then conduct a sub-RfC to see what option would be best, as long as the consensus doesn't seem to be oppose. Cocobb8 (💬 talk • ✏️ contribs) 19:52, 18 March 2024 (UTC)[reply]
neutral i could go either way. I like the hard coding option of having 'template' be dropdown option in the menu. Slacker13 (talk) 01:29, 20 March 2024 (UTC)[reply]
Support – I don't think that adding the t: will add an another level of obfuscation. The current method of making interwiki link is already obscure and complicated, specially for newbies, instead a simple alias to the template namespace will be easy and handy in researches. -- ZandDev 13:57, 20 March 2024 (UTC)[reply]
Note that I suggested tp: though, not t: as it was rejected previously: does that work for you? Cocobb8 (💬 talk • ✏️ contribs) 13:58, 20 March 2024 (UTC)[reply]
@Cocobb8: I'm in favor to the proposal of create an alias for the template namespace, but I believe that I, when I would see one of these link, would not associate tp: directly with templates, but with talk pages. -- ZandDev 16:04, 26 March 2024 (UTC)[reply]
Oppose I do work with templates but I feel that this is not an intuitive shortcut and could easily be confused with "talk page". (t · c) buidhe 04:57, 21 March 2024 (UTC)[reply]
Support , I had typed TP: prefix in the past thinking that I would get the template page without success. This would be useful in different scenarios (just like the WP: prefix). And its use is optional, so if someone doesn't like it, they can go with the full Template: as ever. Alexcalamaro (talk) 05:32, 21 March 2024 (UTC)[reply]
Neutral Agree with the principle, would prefer access to a shortened version; but also agree that the proposal is too close to talk page. Regards, --Goldsztajn (talk) 22:08, 21 March 2024 (UTC)[reply]
I think supporting {{ in the search bar would be sufficient to support the use case of issue. But beside that, I agree with oppose comments above. Izno (talk) 02:48, 22 March 2024 (UTC)[reply]
Oppose per above. Not intuitive and I'm not convinced this solves a genuine problem -Fastily 21:26, 24 March 2024 (UTC)[reply]
Strong support because I have typed "Twmplate" in the search bar too many goddamn times. Mach61 21:03, 26 March 2024 (UTC)[reply]
Support: I have to do everything on mobile, and am looking up templates all the time. This would make that a significantly less laborious and typo-prone experience. But I'd be happy with some other 2- or 3-letter shortcut if TP: is a problem. No more than 3 letters, though. Also I keep typing TP:, TMP: or TPL: without thinking, expecting them to work. But I only want it for search purposes. I'd be opposed to its use as jargon for referring to templates. — Preceding unsigned comment added by Musiconeologist (talk • contribs) 01:34, 28 March 2024 (UTC)[reply]
To help you out immediately, you can use the text expansion feature or apps on your phone to expand an abbreviated string to a longer one. isaacl (talk) 01:43, 28 March 2024 (UTC)[reply]
Well yes, this is rather basic and I've already got a vast number of shortcuts set up. The one I'd naturally use for templates translates tem into {{|}}. There are two points, though: (i) it's counterintuitive and annoying that the whole word is needed, in contrast to wp: etc.; and (ii) beyond three characters, it stops really being a shortcut because it's only a bit shorter. Part of the annoyance is in having to remember that there isn't a 2-letter prefix to use. Musiconeologist (talk) 00:43, 10 April 2024 (UTC)[reply]
Alias {{ (if technically possible): no ambiguity and concise. Typing {{Rfc should take you to Template:Rfc and so should {{Rfc}}. I'm neutral on aliasing TP as the ambiguity may be balanced out by utility. I like T better despite previous community rejection. — Bilorv (talk) 22:37, 29 March 2024 (UTC)[reply]
It is technically possible for {{ to be implemented, and there already is code for it if you want to try it out. Cocobb8 (💬 talk • ✏️ contribs) 22:41, 29 March 2024 (UTC)[reply]
Support any shortcut except just T. Aaron Liu (talk) 02:00, 30 March 2024 (UTC)[reply]
Support saves me a few characters/seconds when accessing templates through the search bar, might even make up for the seconds wasted to write this comment. Tl, tmp or tpl works for me if people object to tp. Draken Bowser (talk) 21:24, 3 April 2024 (UTC)[reply]
Support, this is an excellent idea. I type "Template:" in the search box a lot and it seems many other users do as well, so it makes sense to add a prefix. Preferably it wouldn't be "TP" if a good amount of people have issues with that; I don't care about what ends up being chosen as it remains relatively short (2 or 3 letters). ― novov(tc) 02:59, 6 April 2024 (UTC)[reply]
Support. Aliasing {{ is less preferable to me because a shortcut would also allow shortening template links in edit summaries, where {{tl}} is unavailable. The particular shortcut used doesn't matter to me, just that I won't have to type "Template:" every time. Nickps (talk) 12:46, 8 April 2024 (UTC)[reply]
Think about the possibility of [[{{example}}]] Aaron Liu (talk) 15:11, 8 April 2024 (UTC)[reply]
No. Why should we introduce a way to link to pages that only works in edit summaries and nowhere else? (Note that using it elsewhere will transclude example instead.) TMP:example on the other hand, will work in Search, in talk pages and in edit summaries and the fact that it's a unified syntax makes it easier for non power users to learn. I'm not opposed to introducing {{ for Search (alongside a regular shortcut) as long as we take measures to make sure that people don't end up on the wrong page. That is, if e.g. {{foo}} exists we should add a {{technical reasons}} hatnote to Template:foo/doc. Nickps (talk) 16:21, 8 April 2024 (UTC)[reply]
@Nickps It's already impossible to start a title with a bracket, see [21]Mach61 12:25, 9 April 2024 (UTC)[reply]
I'm aware. That doesn't mean there aren't topics whose WP:COMMONNAMEs start with {{. Nickps (talk) 12:57, 9 April 2024 (UTC)[reply]
Support. I've been at this for ten years and still hate calling up a template doc because it requires so damn much typing. The more typing, the more opportunity for typos that have to be corrected (and I'm good at typos). No objection to something other than TP, such as TM, although no doubt someone would say that could be confused with something else. The longer it gets (e.g. TMP), the less benefit. Something like this doesn't need to be descriptive, just easy to remember. ―Mandruss☎ 05:02, 9 April 2024 (UTC)[reply]
Doc pages don't require much more typing - and if four characters is too many, there is always the "view" link top right of the green doc box that is displayed on the main template page. --Redrose64 🌹 (talk) 13:18, 9 April 2024 (UTC)[reply]
I'm talking about calling up template doc when I don't have a link to click, such as {{infobox person}} (I'm looking to read the doc, not edit it, so the transclusion on the "main template page" is all I need). So I'm typing into the search box, and typing nine characters before I even get to the template name. I would dislike three characters (tm:) one-third (3⁄9) as much. My question is: Why NOT do this? Where's the significant downside? ―Mandruss☎ 19:27, 9 April 2024 (UTC)[reply]
I think Redrose thought that you meant actually manually going to the /doc subpage. Aaron Liu (talk) 20:23, 9 April 2024 (UTC)[reply]
Yeah, I know. Hence my attempt at clarification. ―Mandruss☎ 20:31, 9 April 2024 (UTC)[reply]
Thanks. I prefer solutions that benefit everybody, not just those who are aware of a script and choose to use it. I'm not here just for myself. ―Mandruss☎ 04:08, 10 April 2024 (UTC)[reply]
Support. Don't get why this hasn't been done already. We have wp: because typing "wikipedia:consensus" is tedious. And I can't spell template—I misspell it tempalte all the time—so an alias would be very nice. Anything four characters or shorter would be fine by me; I especially like the {{ idea. And to those who think that creating an alias will cause confusion—really? Is wp:sectionlink any more confusing than tm:sectionlink or something similar? You'll be lost for all of two seconds, if that. Cessaune[talk] 03:44, 11 April 2024 (UTC)[reply]
omg I thought I had something really wrong with my fingers for always spelling tempalte Aaron Liu (talk) 11:35, 11 April 2024 (UTC)[reply]
Strong Support Been meaning to propose this for a while! Any concerns about confusion can be fixed by an experienced editor spending one minute noticing the new system. — PerfectSoundWhatever (t; c) 02:26, 12 April 2024 (UTC)[reply]
Template namespace alias: Second survey
It seems to me we might have wide enough support for this to pass as a general concept. But I think a closer would be unable to decide on the specific alias to use, so we'd be looking at another RfC to decide that (ugh). Therefore a separate survey is in order. Eliminating tp:, I see at least tentative support for t:, tl:, tm:, tmp:, and tpl: (am I missing any?). I don't think this needs ranked voting—the specific choice isn't that critical—so it would be great if editors could just specify their one favorite. ―Mandruss☎ 22:31, 9 April 2024 (UTC) Redacted 05:55, 14 April 2024 (UTC)[reply]
tm:t: ―Mandruss☎ 22:31, 9 April 2024 (UTC) Redacted 04:50, 12 April 2024 (UTC)[reply]
t: and tm: are no good because they deprive mainspace articles like t:kort of the title they deserve. tl is already in use to refer to the Tagalog Wikipedia. Fine with the others. * Pppery *it has begun... 22:37, 9 April 2024 (UTC) (edited * Pppery *it has begun... 03:05, 10 April 2024 (UTC))[reply]
I struck tl:, it is not valid as it is an ISO language code. — xaosfluxTalk 23:35, 9 April 2024 (UTC)[reply]
I find the "title they deserve" argument uncompelling in the greater scheme. Those wacky norsk and a few others might have to take one for the team. By eliminating t and tm, you're effectively forcing a three-character alias (unless we want to back up and introduce something like te at this late date, which would probably meet with its own opposition anyway). Just for fun, how about an example of a tm-"killer"? ―Mandruss☎ 03:25, 10 April 2024 (UTC)[reply]
Anomie provided one below. And te is already used for the Telugu Wikipedia. * Pppery *it has begun... 03:28, 10 April 2024 (UTC)[reply]
Told ya. Hell, while you might be able to produce a better example, I wonder if t:kort would survive AFD. ―Mandruss☎ 03:38, 10 April 2024 (UTC)[reply]
T:kort seems to be the only one for t:, other than some redirects which would work just as well from template namespace. But I think it would survive AfD - why would it be any less notable than anything else in Category:Fare collection systems, keeping in mind WP:Systemic bias and that sources are probably in Norwegian? Since I don't see a compelling reason for this proposal at all you aren't going to be able to convince me to cause a clear harm in the name of a dubious benefit. * Pppery *it has begun... 03:48, 10 April 2024 (UTC)[reply]
Fair enough. Just don't want anybody getting the impression that t and tm are now off the table like tl. The fact that they aren't stricken in the intro should be enough, but ya never know... ―Mandruss☎ 03:53, 10 April 2024 (UTC)[reply]
On t:kort specifically, which appears to be the only article that starts with T:, I don't think it actually should have that title per MOS:TM. The use of a colon isn't standard Norwegian orthography and the majority of third-party sources appear to call it "T-kort". – Joe (talk) 10:55, 11 April 2024 (UTC)[reply]
And I see you've done that move. Well damn, now I'm tempted to change my vote from tm to t. But then I'd have to re-ping everybody; not sure it's worth it. ―Mandruss☎ 11:26, 11 April 2024 (UTC)[reply]
There are still some links to the redirect at T:kort and quite a few others. OTOH, I don't understand the objections based ISO language codes. -- Michael Bednarek (talk) 12:07, 11 April 2024 (UTC)[reply]
It's established convention that links prefixed with a language code go to that language's edition. Aaron Liu (talk) 12:38, 11 April 2024 (UTC)[reply]
If a Wikipedia is created for a language, the ISO 639 code will be used in its URL and for its wikilinks (like how de: or es: link to German or Spanish Wikipedias, or how they can link back to us with en:). A namespace alias would conflict with that, preventing linking to that Wikipedia, so such aliases are often preemptively avoided. Anomie⚔ 13:14, 11 April 2024 (UTC)[reply]
Most of those other redirects are cross-mainspace redirects to templates, i.e. using "T:" as a pseudo-namespace. Obviously they wouldn't be affected by this proposal. The exceptions I can see are:
I'd be fine with any of the choices.Schazjmd(talk) 23:18, 9 April 2024 (UTC)[reply]
@Schazjmd: Yeah, this is the kind of "vote" that doesn't get us any closer to consensus. You might as well have saved yourself the trouble. Maybe you could just close your eyes and pick one? ―Mandruss☎ 23:54, 9 April 2024 (UTC)[reply]
T is fine just as we use "h" for help space all over.Moxy🍁 23:36, 9 April 2024 (UTC)[reply]
tm: prefer this than single letter "t" which still retains a "talk" ambiguity. Regards, --Goldsztajn (talk) 23:54, 9 April 2024 (UTC)[reply]
tm: because T: is already used, it's shorter than tpl:, and tmp: is misleading/confusing. -- Michael Bednarek (talk) 00:30, 10 April 2024 (UTC)[reply]
Oppose Since you pinged me, I still oppose the whole idea. I note that "t" could be confused with "talk", as was already noted, "tpl" is the ISO 639 code for Tlacoapa, and "tmp" is a deprecated (but apparently not unassigned) ISO 639 code for Tai Mène. Also of note are articles T:kort and TM:103 Hustlerz Ambition that would be affected by certain of the proposals here (plus a few other redirects starting with "T:", such as T: New York Times Style Magazine). Anomie⚔ 00:40, 10 April 2024 (UTC)[reply]
I pinged you because pinging everybody was a whole lot easier than trying to decide who should be pinged for this section. I might decide wrong and piss somebody off. This section is not for opposition to the general concept; that's the other one. If the general concept doesn't pass, this section will prove a waste of time, but it's still worthwhile. ―Mandruss☎ 00:43, 10 April 2024 (UTC)[reply]
tm or t8 are fine. The "8" might seem radical, but it's actually a typical method for shortening long words, such as l18n or k8s - eight being a familiar number for this purpose. No matter the choice, there will likely be edge case overlaps. That shouldn't stop it though. There are likely edge cases for WP, File, and whatever else. -- GreenC 01:00, 10 April 2024 (UTC)[reply]
8 is just outside the normal typing zone on a normal keyboard and requires extra clicks to get to on a phone keyboard. I oppose it. Aaron Liu (talk) 01:01, 10 April 2024 (UTC)[reply]
8 is just outside the normal typing zone on a normal keyboard - I don't know, but really? -- GreenC 01:03, 10 April 2024 (UTC)[reply]
I also support tm. Ideally I'd support tp: the most, which also has no usages, and establishing this convention would prevent confusion, but it seems this has been struck down already. Aaron Liu (talk) 01:00, 10 April 2024 (UTC)[reply]
Also support t: per novov. Aaron Liu (talk) 11:45, 12 April 2024 (UTC)[reply]
tm or tp for me. tl would also be OK, and would match the existing {{tl}} template. Musiconeologist (talk) 01:07, 10 April 2024 (UTC)[reply]
Sorry, that seems to have ended up in the wrong place. If anyone feels like moving it properly into the list of replies, please do. I'm hampered by the size of the page. Musiconeologist (talk) 01:10, 10 April 2024 (UTC)[reply]
Thanks. We ended up both moving it at the same time! I got an edit conflict, then discovered it was now in the right place anyway. I now know to add a new bullet point, not a new reply via the reply link. Musiconeologist (talk) 01:38, 10 April 2024 (UTC)[reply]
tl is off the table; that's why there's a line through it. See this edit. tp was eliminated because of strong opposition to something that looks like "talk page". It helps to read before posting. We'll assume you like tm, then. ―Mandruss☎ 01:18, 10 April 2024 (UTC)[reply]
(and as said above tl is off the table because it already refers to the tagalog wikipedia) Aaron Liu (talk) 01:32, 10 April 2024 (UTC)[reply]
I did, then I read considerably more (the whole discussion). It's late at night, I was battling to navigate the page in a tiny window, and I didn't remember that specific detail among all the others. Anyway, tp is my first choice. Musiconeologist (talk) 01:33, 10 April 2024 (UTC)[reply]
Anarchist. ;) ―Mandruss☎ 01:37, 10 April 2024 (UTC)[reply]
Yes, tm is fine. And my irritability suggests I need sleep, (I find the opposition to tp surprising though. I expect the alias to be a contraction of one word.) Musiconeologist (talk) 01:43, 10 April 2024 (UTC)[reply]
tm is a contraction of template. It just uses the first and second consonants instead of the first and third. ―Mandruss☎ 01:46, 10 April 2024 (UTC)[reply]
Exactly. Same as tp. I wasn't saying any different. I just meant that I'm surprised people would intuitively interpret tp as talk page rather than template when using acronyms would obviously be a different model. But they do, and that's fine. Musiconeologist (talk) 02:01, 10 April 2024 (UTC)[reply]
I see. Sorry for the misunderstanding. Get some sleep. ―Mandruss☎ 02:08, 10 April 2024 (UTC)[reply]
TM: , as my prefered TP: has been discarded per above. Alexcalamaro (talk) 01:36, 10 April 2024 (UTC)[reply]
Not to the two million people that speak Temne. – Joe (talk) 11:06, 11 April 2024 (UTC)[reply]
@Joe Roe: Aside that being .00025% of the world, what number of Temne speakers would even know that that’s its abbreviation? Hyperbolick (talk) 02:58, 12 April 2024 (UTC)[reply]
I don't know, I don't speak Temne. But if/when we have a Temne Wikipedia, it'll be how we link to it. – Joe (talk) 06:07, 12 April 2024 (UTC)[reply]
Oppose t, not sold on the concept as a whole but the others don't seem to hold the potential confusion the initial proposal did. CMD (talk) 08:46, 10 April 2024 (UTC)[reply]
{{ is my first choice and t is my second choice (and I don't understand why I have to say it twice). — Bilorv (talk) 09:18, 10 April 2024 (UTC)[reply]
Because to achieve something from this proposal it is necessary to converge to a few and ideally to a single prefix. -- ZandDev 11:25, 10 April 2024 (UTC)[reply]
I'm not sure if a non-alphanumeric namespace alias is possible, but if it is, I suspect {{: would pose a problem for many existing tools and scripts that parse wikitext, including syntax highlighting tools. isaacl (talk) 17:29, 10 April 2024 (UTC)[reply]
Note that the {{ option does not include a : and would require additional programming. Aaron Liu (talk) 17:34, 10 April 2024 (UTC)[reply]
My apologies for being overly concise. I included the : to emphasize that the proposal is for a namespace alias, and not to suggest that there would be a colon in the namespace alias. Yes, the point of my comment was that not only might there be a need for changes to MediaWiki software, but to many existing tools and scripts, including syntax highlighting tools. isaacl (talk) 17:45, 10 April 2024 (UTC)[reply]
The {{ option is not supposed to be a namespace alias that would still require the colon. It's proposed to be what seems to be a searchbar alias plus maybe an edit summary alias. Aaron Liu (talk) 02:38, 11 April 2024 (UTC)[reply]
Yes, it's not necessary to explain proposals that I'm already aware of (as per my previous comments). If someone isn't proposing a namespace alias, then they shouldn't list it as their preferred option in this section. isaacl (talk) 04:51, 11 April 2024 (UTC)[reply]
It also wouldn't really help on mobile, at least with SwiftKey, since accessing the braces entails either a long keypress for each one or switching to symbol layout. Either way it's probably easier to type the whole word than use the alias. Musiconeologist (talk) 17:41, 10 April 2024 (UTC)[reply]
Oppose anything and everything that conflicts with an article, including "T:" and "TM:", I also oppose "tp" as it is more likely to refer to "talk page" than "TemPlate". Neutral on other suggestions. Thryduulf (talk) 11:04, 10 April 2024 (UTC)[reply]
Immediately comprehensible, easy to remember Musiconeologist (talk) 16:14, 11 April 2024 (UTC)[reply]
tm: for it does not conflict with talk pages in any way, and is the most logical one to me. Would also be fine with tmp: and tpl:. Cocobb8 (💬 talk • ✏️ contribs) 14:21, 10 April 2024 (UTC)[reply]
First choices: t, tp, tm Second choice: Aliasing {{ Last choices: Anything with a number or 3+ letters Honestly, I would suggest whoever closes this just narrowes down the 2-3 most viable options, selects one randomly, and comes up with a post-hoc justification. This isn't worth spending a lot of time on Mach61 17:22, 10 April 2024 (UTC)[reply]
tm is also a language code. Aaron Liu (talk) 17:34, 10 April 2024 (UTC)[reply]
I see no problems, tm: isn't a valid interlanguage link. Mach61 17:45, 10 April 2024 (UTC)[reply]
Not sure what I was talking about. Aaron Liu (talk) 02:39, 11 April 2024 (UTC)[reply]
I guess that could work, but to me it looks like tm: is the one gathering the most support so far. Cocobb8 (💬 talk • ✏️ contribs) 20:52, 10 April 2024 (UTC)[reply]
T: is the straightforward and shortest prefix: it does its job better. The main problem is that it could be confused with talk, but I noticed that all here said that 'tp' seems to refer to 'talk page', so why not use it for talk pages? People will adapt to the chosen solution and have to remember it. Also tm is not direct (but for me acceptable). ZandDev 18:09, 10 April 2024 (UTC)[reply]
It's too much work to have everyone adapt to a new thing. Aaron Liu (talk) 02:40, 11 April 2024 (UTC)[reply]
Off-topic about namespace aliases for other things. ―Mandruss☎ 05:13, 11 April 2024 (UTC)[reply]
I noticed that all here said that 'tp' seems to refer to 'talk page', so why not use it for talk pages? You're proposing a tp: alias for talk:? Aren't you a bit off topic? Besides, it would save only two characters, not 5–7: a truly negligible improvement. Besides, there are at least two kinds of talk pages, article and user. That's if you exclude other talk spaces, such as this one. If any additional aliases might make sense, they would be atp: for talk: and utp: for user talk:—the words "talk page" can be ambiguous in some contexts, so I try to use those acronyms wherever such ambiguity might exist. Apologies for extending the off-topic; sometimes I can't help myself! ―Mandruss☎ 05:06, 11 April 2024 (UTC)[reply]
I agree with you, it isn't worth it to add tp: as an alias to talk:, the latter being already pretty short. However, for whatever ends up being chosen for template:, might it work to add an extra t in that alias for the template talk: namespace? Say, if tm: is the one chose, then tmt: could alias template talk:. Also, a shorter alias for user talk: would be ut:. Cocobb8 (💬 talk • ✏️ contribs) 12:54, 11 April 2024 (UTC)[reply]
Note "tmt" is the ISO 639 code for Tasmate. Anomie⚔ 13:14, 11 April 2024 (UTC)[reply]
Comment: people realize that t: is the existing psudeo-namespace for templates, as seen at T:CN and T:DYK? That doesn't mean you HAVE to support it, but it makes the arguments that it would be "confusing" stange, as it is already in use. Mach61 12:48, 11 April 2024 (UTC)[reply]
There's also T:MP, and there's no evidence that people not already in the know aren't confused by those. Plus it could turn out to be more confusing once people can use it for every template rather than only the handful of pseudo-namespace redirects that have been allowed. Anomie⚔ 13:14, 11 April 2024 (UTC)[reply]
Comment. Let me see if I understand this. If the colon were removed from the title at TM:103 Hustlerz Ambition (a vanishingly insignificant cost to the project, although some Jeezy fans would disagree), that would create a redirect with the colon that wouldn't work because of a tm: namespace alias? Then we should consider manually changing all existing links to that article (104 entries in that list, although I don't know how many would have to change) and deleting the unusable redirect. Then all we'd have to worry about is the possibility that some obscure Tamboori Wikipedia (e.g.), Tamboori being spoken by 112 people on a remote island in the South Pacific, will be created in the future and somebody at en-wiki will want to link to it. ―Mandruss☎ 14:23, 11 April 2024 (UTC)[reply]
@Mandruss actually, we could just create a template page and redirect that (see Help:A Day in the Life for an analogous case). The issue is when there is already an existing template with the same name as a mainspace page after the prefix. Mach61 14:27, 11 April 2024 (UTC)[reply]
Hmmm. Well there's something to be said for knowing I don't understand something, since I'll talk less. I don't know how much of an obstacle we're talking about. I do believe that we should be prepared to make some sacrifice to make this work. ―Mandruss☎ 14:45, 11 April 2024 (UTC)[reply]
Yeah, it's super easy to create an alias template, provided that the alias doesn't conflict with article titles/redirects already. Which is the main issue. Cessaune[talk] 15:55, 11 April 2024 (UTC)[reply]
Tm or Tl Both are close to the colon-key, which is always practical. Draken Bowser (talk) 15:51, 11 April 2024 (UTC)[reply]
@Draken Bowser:tl is off the table, hence the strikethrough in the intro to this section. See previous discussion in this section. ―Mandruss☎ 16:14, 11 April 2024 (UTC)[reply]
After further consideration, I would probably go for t: or tmp:/tpl:. Any collision with article space can be solved by redirects, similar to Portal:No Escape, given the number of offenders is relatively small. TM: is a non-starter in my opinion since many keyboards auto-correct it to a U+2122™TRADE MARK SIGN, and the point of a shortcut is to avoid difficulty. ― novov(tc) 02:33, 12 April 2024 (UTC)[reply]
Very valid point. However, I've not seen that happen inside search boxes or on Wikipedia as far as I can remember, which are basically the only scenarios in which anyone would be typing template: anyway. Cessaune[talk] 04:15, 12 April 2024 (UTC)[reply]
Unfortunately it does happen for me; afaik it's a default text replacement on macOS. I'd disable it, but I find the ability legitimately useful in other circumstances. ― novov(tc) 07:58, 12 April 2024 (UTC)[reply]
That's it. After that, just type out your shortcut, followed by title, separated by a space/tab, on the address bar and hit enter. Everyone can pick whatever shortcut they like, for all namespaces and even page prefixes of their choice. You can add one for https://en.wikipedia.org/wiki/Wikipedia:Requests_for_adminship/%s to go to RFAs by just typing out usernames, for example. Best, Usedtobecool☎️ 05:47, 9 April 2024 (UTC)[reply]
That's good for an alternative in the meantime! But tp: would make it easier regardless of the platform people use to contribute. Cocobb8 (💬 talk • ✏️ contribs) 11:20, 9 April 2024 (UTC)[reply]
I propose that articles that are created after 1st April 2024 and does not have any inline sources to be eligible for WP:PROD. Such a PROD can only be revoked after an addition of one inline, reliable, third-party source. That source does not need to completely establish the topic's notability (because that will be decided in AfD); its only job is to verify that this topic is not a hoax. CactiStaccingCrane (talk) 06:48, 17 March 2024 (UTC)[reply]
If this proposal is accepted by the community, it would greatly streamline our efforts to cleanup uncited articles and prevent the growth of the cancerous Category:Articles without sources backlog. In the future, this "imaginary" deadline could be gradually push backwards to tackle older and older articles, until the backlog is fully cleared. CactiStaccingCrane (talk) 06:53, 17 March 2024 (UTC)[reply]
Support As I have already said, independent reliable sources are needed to established notability, so such sources should be made explicit by citing them in any new article. As Levivich says, an article with no sources is a blog. Hell, when I was blogging a few years ago, I always included a list of sources at the bottom of a post, so that readers could read more about the subject, if they wanted to. Not providing sources when an article is created is just being rude to other editors who are somehow expected to do the work sourcing the article that the creator could not be bothered with. Donald Albury 20:26, 21 March 2024 (UTC)[reply]
I envision that there will be three things that needs to be done before this proposal can be enforced:
Make a new template similar to {{Proposed deletion}} for this proposal
Communicate to new editors that articles on Wikipedia must have reliable sources cited, and it is strongly encouraged that they find reliable sources before writing the article
A way to tackle editor disputes about what constitutes "third-party" and "reliable".
Number two is extremely difficult. Anyone who knows English could be a new editor. There are many hundreds of millions of them. Phil Bridger (talk) 10:49, 17 March 2024 (UTC)[reply]
We should also find ways to retain new editors if this proposal is enforced, because that would set an even higher barrier for entry for new editors to Wikipedia. This is the reason I why invited WP:Wikiproject Editor Retention to this topic. CactiStaccingCrane (talk) 07:12, 17 March 2024 (UTC)[reply]
As in discouraging. It would be bad if we start to vandalize new articles in order to depreciate them though :) CactiStaccingCrane (talk) 07:19, 17 March 2024 (UTC)[reply]
New editors are already forced to go through WP:AfC, which is not going to approve an unsourced article. --Ahecht (TALK PAGE) 13:39, 17 March 2024 (UTC)[reply]
If you think the new editor article-writing experience is so demoralizing, maybe we should just not let new editors create articles in the first place? 2603:8001:4542:28FB:E9B3:2893:5C25:E68F (talk) 07:28, 17 March 2024 (UTC) (Send talk messages here)[reply]
No. We already have the WP:Article wizard to aid completely new editors to create a new article. I think that the wizard should be shown more prominently in "Wikipedia does not have an article with this exact name" notification box, as well as making {{AfC submission/draft}} and {{AfC submission/declined}} easier to understand for new editors. But we need new editors and we MUST NOT make Wikipedia harder for newcomers to contribute. CactiStaccingCrane (talk) 07:33, 17 March 2024 (UTC)[reply]
The fundamental problem for newcomers is that editing Wikipedia is not convenient. It takes a substantial effort to do so. So, one way to make this easier is to improve on the article wizard and ask people to find a few sources before citing them. I imagine that the new article wizard would ask you for URLs/book titles (and pages), and once you create a draft it would show you how to expand these fragments of info into fully-fledged "wikipedia-compliant" citations. CactiStaccingCrane (talk) 08:04, 17 March 2024 (UTC)[reply]
Sorry for the horrendous MS Paint drawing, but this is what I envision it to be like this:
All of the objections raised to the two similar proposals in the last few months still apply. I really can't be bothered to repeat them again. We're supposed to be building an encyclopedia here. Clearing a backlog is only incidental to this. Phil Bridger (talk) 08:52, 17 March 2024 (UTC)[reply]
I like this idea in theory, but will only support it once tools and wording changes for newcomers are instated. The risk of this detracting newcomers is high enough that I think the community should have a consensus that the new wording/templates etc. alleviate harm, and they should be ready to go before any changes are made. ― novov(tc) 09:52, 17 March 2024 (UTC)[reply]
Support per all the arguments I've made before. WP:BURDEN, basically. 🌺 Cremastra (talk) 12:47, 17 March 2024 (UTC)[reply]
Rather than a PROD, we should really just move new unsourced articles to draft. Lee Vilenski(talk • contribs) 12:56, 17 March 2024 (UTC)[reply]
This again? While consensus can change, it seems unlikely that consensus will have changed in the month since Wikipedia:Requests for comment/Deletion of uncited articles was rejected. Let's not make this another topic area where people keep pushing essentially the same proposal with slightly different wording until, through tendentiousness and exhaustion, they manage to get something in (and then ratchet and repeat). Anomie⚔ 13:38, 17 March 2024 (UTC)[reply]
Support Moving to Draft with a x day prod-like notice. I'm impressed by the relentless work done by a small number of overwhelmed volunteers trying to address this problem, and I support their efforts. I disagreed with the former proposal, but this one is acceptable, grandfather the existing article and raise the quality bar for new articles by a very small degree. We already do this with AfC, where quality standards are much higher, it is nothing we don't already do. -- GreenC 14:42, 17 March 2024 (UTC)[reply]
Query: Can someone speak to how the newer entries in Category:Articles lacking sources are ending up there? Don't all new articles these days have to go through WP:NPP, which ought not to let them pass if they are unsourced? Sdkbtalk 14:44, 17 March 2024 (UTC)[reply]
Did you find many such new articles? New page reviewers can mark unsourced articles reviewed if the topic is notable but I doubt that happens very often. Someone would have to sort those articles by creation/expansion-from-redirect date to find out. — Usedtobecool☎️ 15:09, 17 March 2024 (UTC)[reply]
First one I checked from March 2024 was created by an autopatrolled editor, so even NPP wouldn't see it necessarily. Schazjmd(talk) 15:23, 17 March 2024 (UTC)[reply]
The categories track the tagging date. And iirc some automated tools update tag dates when making unrelated edits. So, it's likely the new categories are just populating with old articles. Autopatrolled editors wouldn't remain autopatrolled if they created unsourced articles nowadays. I actually think autopatrolled has a higher bar than necessary but admins are very risk-averse. — Usedtobecool☎️ 16:12, 17 March 2024 (UTC)[reply]
@Usedtobecool, you're right, it wasn't created in March 2024, I should have looked more closely. Schazjmd(talk) 16:22, 17 March 2024 (UTC)[reply]
In general, I expect almost all the articles in those categories are old articles. Notability would have to be completely obvious and there would need to be no BLP element in the article for a reviewer to pass an unsourced article in 2024, if someone were to start Ancient history of Botswana that more or less concurs with relevant content in existing articles, for example. — Usedtobecool☎️ 16:31, 17 March 2024 (UTC)[reply]
I draftify all new unsourced articles I see, but sometimes the creator tendentiously undraftifies it, and per WP:DRAFTIFY, I'm not allowed to redraftify it, so I just tag it. 🌺 Cremastra (talk) 19:03, 17 March 2024 (UTC)[reply]
What are they supposed to do about them? We don't delete articles just because they lack references and NPPers don't have a special 'article go away' button otherwise. Unless an unreferenced has other, more immediate problems I think most experienced reviewers would tag it with {{unreferenced}} and move on. Others might choose to bat it back and forth to draftspace a few times first, but the end result is the same. – Joe (talk) 08:00, 19 March 2024 (UTC)[reply]
Oppose per the most recent discussion and disallow any new discussions on this for a few months. I've already seen several notable topics without sources or with only one source being moved to draftspace and then deleted after six months. A PROD would make this even worse. SportingFlyerT·C 15:27, 17 March 2024 (UTC)[reply]
Oppose Unsourced articles are bad but etching explicit grandfather clauses into Wikipedia's rules is worse. * Pppery *it has begun... 15:39, 17 March 2024 (UTC)[reply]
Yeah, I don't like the idea of grandfathering, especially given the potential to reinforce systemic bias, given that Wikipedia's content is becoming more diverse over time. Sdkbtalk 16:34, 17 March 2024 (UTC)[reply]
That's why there is a moving deadline to the left to clear out the backlog. Stage one of this proposal is to prevent further growth of the backlog, stage two of this proposal is to start tackling the remaining articles from newest to oldest. CactiStaccingCrane (talk) 17:30, 18 March 2024 (UTC)[reply]
Oppose, draftifying does the trick already. There do not seem to be many (any?) totally unsourced articles that make it through NPP, so I am not sure there are any articles that this proposal applies to (the category mentioned by the nominator contains mostly old articles that have been recently tagged as unsourced). —Kusma (talk) 16:32, 17 March 2024 (UTC)[reply]
The NPP process does not allow unsourced articles to be draftified. It maybe happens often, but it's not part of the policy. An NPP reviewer is required to look for sources, and if they find sufficient ones to support notability, they are supposed to tag the page as {{unreferenced}} and mark it as reviewed, not to draftify it. I would support allowing NPP reviewers to directly draftify unsourced pages, but this is not the case at the moment. Broc (talk) 12:45, 5 April 2024 (UTC)[reply]
Oppose. From above, it appears that newly created unsourced articles are already sufficiently handled by our existing rules and processes. Sdkbtalk 16:35, 17 March 2024 (UTC)[reply]
Mild oppose. Three concerns: First, the proposal and discussion seem to be conflating unsourced articles with articles lacking inline citations. Requiring all articles to have inline citations regardless of whether any content has been or is likely to be challenged is out of step with WP:V and quite a jump from settled practice. Second, is is not clear what it means for the affected articles to be "eligible" for PROD. WP:PROD#Deletion provides the following criteria for PROD eligibility: the page is not a redirect, never previously proposed for deletion, never undeleted, and never subject to a deletion discussion. So as long as the proposer reasonably believes that the deletion will be uncontroversial there doesn't appear to be any particular procedural barrier to prodding these articles now. Third, it would be helpful to see evidence that there is a problem that needs solving. A PetScan query for articles created since January 1, 2024 in Category:All articles lacking sources gives 8 results, including one article with listed references (so tagged incorrectly but still subject to this proposal) and one that is currently up for speedy deletion. The remaining six definitely have some issues, but I'm not sure we need this level of policy change to fix what seems to be a couple-of-articles-per-month problem. (OTOH, the counterargument could well be made that this just shows that the proposal is the best kind of wiki-rule: one that simply codifies existing practice to prevent future confusion. But if that's the argument it would likewise be helpful to have some quantitative details showing how this proposal maps onto existing practice.) -- Visviva (talk) 17:03, 17 March 2024 (UTC)[reply]
For what it’s worth, on March 1 and 2 I attempted to patrol the category in question and see if it was possible for one person to keep it down to zero. It sort of is but you run into articles that are unlikely to get deleted but next to impossible to source, and then things get out of hand if you miss a day. It’s a tough project. I just want to note that this is a burden on editors to fix, and a lot of times adding a inline source to a plainly bad article doesn’t do a lot. ForksForks (talk) 02:08, 18 March 2024 (UTC)[reply]
This is exactly what I meant. This PROD would essentially be a formal enactment of our "unspoken rule", which is that new articles on Wikipedia must have sources. A lot of people here don't get it. CactiStaccingCrane (talk) 11:52, 18 March 2024 (UTC)[reply]
Have you considered that it might be "unspoken" because it's not actually a rule? – Joe (talk) 08:01, 19 March 2024 (UTC)[reply]
Comment – Let's suggest something new. Before PRODDING, one should check for sources. If it turns out that the unsourced article has no reliable sources to verify, then just PROD it; otherwise, it should be draftified as an easy and less bitey than prodding. Toadette(Let's discuss together!) 21:57, 17 March 2024 (UTC)[reply]
Oppose. This proposal is not compatible with WP:NEXIST or WP:ATD. The topic of an unsourced article is often notable. The content of unsourced articles is often accurate and verifiable. An article is not "unsourced" merely because lacks of inline citations. Deletion of an article for lack of inline citations would result in the deletion of articles on topics whose existence and notability is not only verifiable, but is actually verified with sources actually cited in the article. The proposal is a solution in search of a problem, as there is no problem with unreferenced new articles that could possibly make it expedient to create a new sticky PROD similar to the BLP PROD. We are not being swamped with unreferenced new articles, and it is very easy, and takes very little time, to do a WP:BEFORE search. I propose that there should no further proposals for the creation of an "unreferenced PROD" for the next five years. I do not believe that there is any chance of consensus for the creation of a new PROD in the near future, and the community does not have time to !vote on what is essentially the same proposal again and again and again in quick succession. It is not particularly easy to check the large number of noticeboards for perennial proposals, either. James500 (talk) 23:22, 17 March 2024 (UTC)[reply]
Yet we often say in WP:BURDEN that "the burden to demonstrate verifiability lies with the editor who adds or restores material." I do agree that retroactively apply this proposal to very old articles is a very dumb idea, but I do think that we need to explicitly communicate with new editors that new articles require at least 1 cited source. We can help them to find the sources, but ultimately the burden is on them to find it. CactiStaccingCrane (talk) 17:25, 18 March 2024 (UTC)[reply]
This conflates notability with content; we can establish notability in the absence of sourcing in an aricle, verification of content requires sourcing. Regards, Goldsztajn (talk) 10:55, 20 March 2024 (UTC)[reply]
Establishment of notability (in the Wikipedia sense) requires the existance of reliable, independent sources, so if we know what those sources are, why not cite them in the article? In other words, if no reliable, independent sources are cited in the article, where is the proof that the subject is notable? Donald Albury 13:36, 20 March 2024 (UTC)[reply]
This. The cognitive dissonance in these kind of arguments are deafening. CactiStaccingCrane (talk) 13:37, 20 March 2024 (UTC)[reply]
The cognitive dissonance is the instance that WP:V says "verified with an inline reliable source from the first revision of the article" not "verifiable". If you want to change that, you need to explicitly propose amending WP:V. If you want to change "credible claim of significance" to "credible claim of significance supported by an inline citation to a reliable source" then you need to explicitly propose amending that page. Thryduulf (talk) 13:56, 20 March 2024 (UTC)[reply]
Based on the number of comments in opposition here, I don't think it's obvious at all. However, if it is obvious then you will have no problem gaining consensus for the amendments. Just don't claim the consensus exists until you can provide a citation proving it does actually exist. Thryduulf (talk) 14:07, 20 March 2024 (UTC)[reply]
I agree with DonaldAlbury above: the point of having one source, no matter if it's not reliable, or trivial, is to ensure that the WP:CCS is true. Cocobb8 (💬 talk • ✏️ contribs) 13:38, 20 March 2024 (UTC)[reply]
Strong oppose I agree completely with James500. What matters is whether articles can be sourced, not whether any sources are currently listed in the article. We should be making it easier for editors (new and old) to contribute notable articles to the encyclopaedia, not putting even more barriers in their way. Thryduulf (talk) 12:11, 18 March 2024 (UTC)[reply]
Support We need to build this idea that finding and including sources is step #1 of creating an article. And the burden shouldn't fall on overloaded volunteers to "prove a negative" when people don't bother with sources. But are there enough of these to be setting this up? I've done thousands of NPP's and don't think that I've ever seen one with zero sources and just a few with zero in-line sources. The widespread / pervasive volunteer-crushing problem is zero GNG sources. North8000 (talk) 17:41, 18 March 2024 (UTC)[reply]
I mean, nobody's forcing you to look for sources. – Joe (talk) 08:38, 19 March 2024 (UTC)[reply]
The greater fool theory, that someone else will do it, is not accurate: see the backlog. See the stats that show how few experienced regular editors. If we can't support our maintainers who are in the trenches doing this work, then you are right, they should not do it. -- GreenC 15:52, 22 March 2024 (UTC)[reply]
Support I think the is an extension of WP:CIR. Beside it is very frustrating to see in AfDs the comments "there are sources available" and "normal editing can solve this" after which absolutely nothing happens. Not even by the editors that state that there are sources available (when you know that, why do you not add them???). The Bannertalk 17:48, 18 March 2024 (UTC)[reply]
Strong support. I opposed the previous proposal to remove all unsourced articles, but this encyclopedia has existed for 23 years, and the standards have dramatically increased since then. Back then, this might've been acceptable, but it is no longer, hasn't been for quite a while, and this just codifies that. This is also in line with WP:BURDEN; we shouldn't have to prove a lack of notability to throw these articles out. Queen of Heartsshe/theytalk/stalk 20:25, 18 March 2024 (UTC)[reply]
Strong support. Wikipedia is a tertiary source, let's not forget that, and its purpose is to benefit readers by presenting information on all branches of knowledge. As others have said, having at least one source will at least verify the topic is not a hoax, and will ensure that the mentioned knowledge is not fake. These unsourced articles should at the very least be moved to a draft, in my opinion. Cocobb8 (💬 talk • ✏️ contribs) 20:38, 18 March 2024 (UTC)[reply]
Support. I don't love grandfather clauses either, but I think this is the least bad of the available solutions (the most bad being "Do nothing; just keep accumulating unsourced material indefinitely".) At some point, we have to turn the water off to the gushing pipe, and then we can focus on cleaning up the remaining mess. We really need to get across the idea of a "reverse BEFORE": Before you create or substantially add to an article, have in hand the reference material that verifies what you will write, and cite it. "Write first, hope someone sources it later, in practice let it sit unreferenced or CN tagged for the next ten years" should be an approach that is deprecated and ultimately not permitted (at least not in mainspace; if people want to do things backward in a draft or userspace, that's up to them.) An alternative might be to draftify unsourced new articles, and forbid returning them to mainspace until at least one source is added, but when you're already dealing with a flood, first turn the tap off. SeraphimbladeTalk to me 21:04, 18 March 2024 (UTC)[reply]
Oppose mostly because a grandfather clause is generally a bad idea at best: why does this only become a problem on April 1, 2024? As other have pointed out, unsourced articles rarely make it through NPP and AfC, and even if we let PROD be used for this, it can still be contested and forced to go through AFD where WP:NEXIST makes it likely to be kept regardless of the number of citations in the article. The main practical effect I see is the grandfather clause, and it only makes sense if the goal of slowly removing the protection is bought into. The problem is that consensus from about a month ago doesn't show an appetite to apply this rule to articles that already exist, and without a mechanism to move the grandfather date automatically we'll have to keep having discussions to move it around which wastes time and risks running around consensus by tiring people out with constant discussions. I don't see this going well in practice. — Wug·a·po·des 21:05, 18 March 2024 (UTC)[reply]
This is why I suggested that "In the future, this "imaginary" deadline could be gradually push backwards to tackle older and older articles, until the backlog is fully cleared." CactiStaccingCrane (talk) 02:43, 19 March 2024 (UTC)[reply]
There have been multiple recent consensuses that explicitly opposed to using prod or speedy deletion to clear the backlog, so this is clearly something the community does not want and continuing to propose it is getting tendentious. Thryduulf (talk) 02:49, 19 March 2024 (UTC)[reply]
Oppose. Is there something preventing us moving such articles to draft space that necessitates creating a new hammer? Also, requiring inline citations is a step too far and seems contrary to policy. I hope this isn't really what was intended and the proposal is just badly worded. wjematherplease leave a message... 22:24, 18 March 2024 (UTC)[reply]
Inline citations are essential for verifying information in an article. As stated in Wikipedia:Verifiability: "All quotations, and any material whose verifiability has been challenged or is likely to be challenged, must include an inline citation to a reliable source that directly supports the material." CactiStaccingCrane (talk) 02:45, 19 March 2024 (UTC)[reply]
So, contrary to policy, you are actually seeking to bypass the challenge part (for the contentious material) and jump straight to deletion (of the entire article)? wjematherplease leave a message... 08:18, 19 March 2024 (UTC)[reply]
The crucial part of that is has been challenged or is likely to be challenged, and nowhere does it say that deletion of the article is the appropriate course of action for verifiable but not verified material. Thryduulf (talk) 02:51, 19 March 2024 (UTC)[reply]
In practice, this is needed because it is very difficult to verify which statements belong to which source (with an exception of very short stubs). I would say that all sentences in such an article are likely to be challenged because they establish that "this topic exists in real life" and "this topic has X, Y, Z attributes that is true". CactiStaccingCrane (talk) 02:57, 19 March 2024 (UTC)[reply]
That's not what the policy says though, and there has been consensus against treating all unsourced statements as likely to be challenged because the person doing the challenging must assess whether the claim is a "sky is blue" type claim (and thus doesn't need a source), plausibly true (in which case they should attempt to find a source, and add it if found or tag it if not) or completely implausible (in which case they should remove it from the article). Thryduulf (talk) 03:08, 19 March 2024 (UTC)[reply]
Also, many new articles are "very short stubs". WhatamIdoing (talk) 20:47, 24 March 2024 (UTC)[reply]
Oppose. It is necessary that articles be based on sources, but not that the sources be cited in-line. Other, less WP:BITEy methods are better ways to address this issue than quickly deleting new articles. Such as a more leisurely deletion process or drafification. Eluchil404 (talk) 00:22, 19 March 2024 (UTC)[reply]
Comment. My reading of the previous discussions was that there is a consensus against (or at least a marked lack of consensus for) automatic deletion of unreferenced articles, old or new. Those previous proposals were weakened by a lack of clarity in scope and terminology, and it seems that this proposal is too:
What do you consider an unsourced article? An unreferenced article? An article consisting of one or more uncited claims? Or one that is not based on sources, cited or not? Those are not synonyms, and anyone who has got stuck into trying to write or salvage articles will know that there is a big difference between an article that lacks citations and an article that lacks sources.
What is an inline source? Do you expect people to copy the whole text into the article, or do you mean inline citation? In which case, how do you square this new requirement with WP:MINREF, WP:GENREF, WP:LISTVERIFY, and WP:LEADCITE?
What is a "third-party source"? Elsewhere, that phrase can mean either independent (WP:GNG) or tertiary (WP:PSTS). In both cases, this would contradict current policy: independent sources are only required to demonstrate notability, and need not be present in the article; tertiary sources are described by WP:NOR as less desirable than secondary ones.
What does it mean to be eligible for PROD? All articles are eligible for PROD, if the deletion is expected to be uncontroversial. Does this remove the 'uncontroversial' requirement? Does that mean that this new type of PROD can be used multiple times? Or after an AfD?
If the only purpose of the required source is to verify that this topic is not a hoax, what information actually needs to be in it? Or should it verify some of the article content? If so, how much? If not, where are you supposed to put the citation, if it doesn't actually relate to any actual article text? What about articles that are obviously not hoaxes (i.e. most of them)?
This would be a massive change to our inclusion standards. It needs to be properly thought through. – Joe (talk) 07:49, 19 March 2024 (UTC)[reply]
Joe Roe, I think all of these concerns are very valid and thus this proposal is not complete. Should I move this to the idea lab? CactiStaccingCrane (talk) 09:59, 19 March 2024 (UTC)[reply]
Maybe not this specific discussion, which is already quite long. If you want to develop this idea further, I'd suggest going back to basics and asking what encyclopaedic purpose a mandatory citation for each new article would serve (i.e. beyond just removing it from Category:Articles lacking sources). – Joe (talk) 11:29, 19 March 2024 (UTC)[reply]
I wish that the opposers would detail more about what this proposal is missing rather than just regurgitating talking points. CactiStaccingCrane (talk) 17:15, 22 March 2024 (UTC)[reply]
I'm saying that the potential for confusion is there, not that I'm personally confused. – Joe (talk) 10:05, 10 April 2024 (UTC)[reply]
Oppose There is already a process that works (draftification through NPP), there is no need to complicate that. Curbon7 (talk) 09:27, 19 March 2024 (UTC)[reply]
SilkTork, all of them are either PRODDed or have one citation. Problem solved. Lake Rabon (South Carolina) is the only article here that currently does not have one inline citation and that should change now. CactiStaccingCrane (talk) 17:17, 22 March 2024 (UTC)[reply]
So our current system works, no? None of the articles have been prodded, but those which were problematic have been moved to Draft space as appropriate. Some of those may be moved back into main space after they have been worked on. Better to go to Draft than to be deleted. SilkTork (talk) 17:42, 22 March 2024 (UTC)[reply]
Oppose. First of all, as one of the patrollers, the flowchart of NPP clearly state that unsourced articles have to be draftified, not PROD-ed. PROD only applies to BLP articles that are unsourced, not other articles. If this is implemented, the procedure of NPP will have to be changed as well which requires further discussion before it can be implemented. We have to also consider WP:ATD where alternatives before deletion have to be considered before moving on to the deletion. This proposal also didn't consider WP:NEXIST - where the notability is based on the availability of sources, not the current state of the article where it may or may not be sourced. Finally, I think there is no need for this. Sending them to draft is enough for them to fix the article, or if they didn't want to fix it, it will be deleted anyway. ✠ SunDawn ✠(contact) 16:57, 19 March 2024 (UTC)[reply]
Support. The first edit to any new page should contain at least one source. One source is the minimum we should require for any page in mainspace. One source is the minimum we should require from anyone creating a new page in mainspace. One source is the minimum required to show that an edit or an article meets WP:V, WP:NPOV, and WP:NOR, our core content policies. One source is not too much to ask. And for this reason, there is little reason to save an unsourced draft. Without a source, a Wikipedia article is meaningless. Levivich (talk) 17:12, 19 March 2024 (UTC)[reply]
Isn't the reason to draftify an article exactly so that it can be brought up to mainspace standards before living in mainspace? Zerotalk 05:12, 20 March 2024 (UTC)[reply]
A draft with no sources is useless, it doesn't help anyone start an article, because you need at least one source in order to summarize sources. Also, while a petty concern, the editor who started an unsourced draft shouldn't get article creation credit. The first step of writing an article is to gather sources; people who write stuff off the top of their head are just blogging, not writing a Wikipedia article. Levivich (talk) 15:37, 21 March 2024 (UTC)[reply]
Just because sources are not explicitly listed does not mean they weren't used when writing the page. Thryduulf (talk) 15:43, 21 March 2024 (UTC)[reply]
It doesn't matter if they were used or not, if the sources are not listed in the draft, the draft is not helpful to anyone else. Levivich (talk) 15:57, 21 March 2024 (UTC)[reply]
Firstly that is irrelevant, secondly it's not true. If someone has written an article about a topic but not included sources then another editor can find sources to verify the claims in the article without needing to know the claims (or even the topic) exist. There is no guarantee of course that such claims will present a comprehensive and neutral view of the topic, but that's true regardless of whether all, none or some of the claims are sourced. Thryduulf (talk) 16:01, 21 March 2024 (UTC)[reply]
Irrelevant? You're the one who brought it up. I agree, it doesn't matter if sources were used or not used in the creation of an article, what's relevant is whether sources are listed in the article or not. If the sources aren't listed in the article, when second editor comes along in order to improve the unsourced article, the second editor has to start by looking at sources and coming up with a summary of those sources. Then the second editor can look at the unsourced draft and yeah, maybe the unsourced draft will magically be a perfect summary of the sources. This is, obviously, highly unlikely. At the very most, in this highly unlikely scenario, the unsourced article would have saved the second editor a bit of typing. But that time saved typing is cancelled out by the time spent reading the unsourced draft and comparing it to the source material to see if it matches. That's a waste of time. I would never read an unsourced draft -- it doesn't matter what the heck is written there if there is no source listed. I would just gather the sources and write my own summary, completely ignoring the unsourced draft. It's useless to an actual article writer.
And why do some editors spend so much energy defending unsourced articles? FFS, this is Wikipedia, it's coming up on almost 25 years now. The first step in writing an article is to gather not one source, or two, but three high-quality, GNG-compliant sources. If you don't have that, you don't have a notable topic, you aren't verifying what you're writing, you're just blogging, not writing a summary of secondary sources. Writing off the top of one's head about a topic is not the same thing as summarizing sources. And if somebody's off-the-top-of-their-head blog happens to line up with an NPOV summary of high-quality RS, that's just like a freak coincidence, man. That is not what we should be striving for, or even tolerating, on Wikipedia. "But what if the bloggers happens to be right?" is an lol argument.
If an editor happened to use sources in drafting the unsourced article and just forgot to put them in there, that's easily fixed. When the article is prodded, tagged for CSD, or AFD'd, the editor can add the sources. Heck, even after it's deleted, the editor can get it REFUNDed and add the sources.
Much more likely, the unsourced article is unsourced because the author didn't summarize sources, they wrote off the top of their head. This is not worth saving, nor is it worth defending.
Wikipedia articles are summaries of secondary sources. That's what they are, and if they don't summarize secondary sources, then they're not Wikipedia articles, even if they're hosted at wikipedia.org. The starting point for every article and every editor is sources. Anyone who starts anywhere else is doing it wrong.
Someday, more Wikipedia editors will come to realize this, and eventually Wikipedia will actually as a matter of policy require sources for all statements in mainspace. It's rather an indictment of Wikipedia that this was not the first policy, and that it's still not policy almost 25 years later. Levivich (talk) 16:23, 21 March 2024 (UTC)[reply]
I wasn't the one to bring this up, you brought it up in response to Zero. I'm not saying that it's not better to have sources in a draft (obviously it is), so most of your arguments are refuting something I'm not claiming. My only point here was that an unsourced draft can be helpful.
You are entitled to your opinion about how other people's workflows for writing articles is "wrong", but unless and until there is a consensus to modify WP:V, WP:N, WP:AGF and other core policies you don't get to impose your opinion on the encyclopaedia. Thryduulf (talk) 17:40, 21 March 2024 (UTC)[reply]
What in the world am I doing that would be considered "imposing my opinion on the encyclopedia"? Comments like this is why I get frustrated discussing things with you. Nobody here is imposing anything on anyone, and this IS an RFC about modifying policy. This IS the right place to express the views I've expressed. Levivich (talk) 17:46, 21 March 2024 (UTC)[reply]
BTW IMO it doesn't have to be an inline source; a general reference would be fine. Levivich (talk) 00:07, 11 April 2024 (UTC)[reply]
Oppose, because this creates a new type of deletion, which makes new page patrol and deletion workflows more complex. I believe that all new deletion proposals should work within our existing types of deletion. I think it would make more sense to expand the scope of BLPPROD, than to add a brand new NOSOURCESPROD that is in addition to the almost obsolete PROD (since folks always just unprod these and they end up at AFD) and BLPPROD. I will also note that many new page patrollers automatically draftify or BLPPROD articles without sources. –Novem Linguae (talk) 21:12, 19 March 2024 (UTC)[reply]
almost obsolete PROD (since folks always just unprod these and they end up at AFD). Try looking at the evidence rather than repeating silly tropes. Phil Bridger (talk) 22:30, 19 March 2024 (UTC)[reply]
Hi @Phil Bridger. I don't think we've interacted before. It's nice to meet you. User:DumbBOT/ProdSummary appears to be a list of current prods. Got any reports that list the outcomes of prods, such as deprod vs delete? My point is that many prods are de-prodded, which then requires the patroller to follow up with an AFD. This is my anecdotal experience with using prod during NPP. Thanks. –Novem Linguae (talk) 23:10, 19 March 2024 (UTC)[reply]
Nice to meet you too. That link points to many articles where the PROD tag has been there for nearly a week and nobody has removed it, making your claim that that always happens false. Phil Bridger (talk) 14:35, 20 March 2024 (UTC)[reply]
Oppose if a new article is sent for deletion solely because there are currently no sources, that's a bad rationale for deletion and a failure of WP:BEFORE. Headbomb {t · c · p · b} 01:55, 20 March 2024 (UTC)[reply]
@Headbomb (or anyone else who's interested), do you feel the same way about the Wikipedia:Proposed deletion of biographies of living people policy? I think this proposal overreaches in requiring an Wikipedia:Inline citation to a reliable, third-party source, but I don't see why, in principle, a completely uncited new article about a BLP should be subject to deletion after a week's notice but an equally uncited new article about, say, a sports team or a business shouldn't be allowed to follow the same process. WhatamIdoing (talk) 20:35, 24 March 2024 (UTC)[reply]
Oppose. Articles on notable topics which would be worth having but don't yet meet mainspace standards (lack of sourcing is only one possible reason) should be draftified. That is a step towards eventually having a good article, while deletion is a step away; I think it is obvious which is better for the encyclopedia. Zerotalk 05:16, 20 March 2024 (UTC)[reply]
PROD would force that article to be improved or to be moved to draftspace. And frankly, why is it so difficult to cite one source in an article about a notable topic? I don't get the opposers' reasoning here. If there is no source in an article, how could we know that this article is not a total fabrication? CactiStaccingCrane (talk) 17:08, 22 March 2024 (UTC)[reply]
I am especially opposed to requiring "inline" sources. If there are sources but they aren't inline, that's a case for cleanup, not deletion. Deleting (rather than draftifying) an article only for that reason would be highly counterproductive. New editors often do not know our standards for how to present sources in articles and we should help them learn rather than telling them to fuck off. Zerotalk 02:31, 11 April 2024 (UTC)[reply]
Oppose as above, contradicts WP:NEXIST; unclear that this necessarily resolves a problem - as the February unreferenced backlog drive showed, even experienced Wikipedians were making mistakes and incorrectly sourcing articles. Regards, --Goldsztajn (talk) 11:00, 20 March 2024 (UTC)[reply]
Oppose per other guidelines and many other opposers, that sources existing and existing notability is enough to not use an enhanced PROD process. I am not a very big fan of draft space (I think working in articles space where there's many eyes is often better if it seems notable. And user space or off wiki is better at the stage where notability is unclear or if someone wants to draft an article solo.). However, I could see supporting a properly crafted proposal that articles less than 90 days old and entirely unsourced when draftified with care (so maybe a very weak form of WP:BEFORE is done) cannot be moved back to article space without adding at least one source that has a credible claim of at minimum verifying the article. Skynxnex (talk) 15:08, 20 March 2024 (UTC)[reply]
MILD SUPPORT I think that any articles without citations should either provide a source or be deleted.But there should be a ~month long period to provide sources before deletion occurs. Redacted II (talk) 17:51, 20 March 2024 (UTC)[reply]
Support I know this is not going to succeed, but ultimately only this approach is consistent with the widespread (and beneficial) practice of improving verifiability by removing unsourced content from articles—which can only be restored if there is a reliable source. (t · c) buidhe 05:00, 21 March 2024 (UTC)[reply]
I think it's premature to predict the outcome. A straight vote count is running a bit under 40:60 against the proposal, but a number of objections (including my own) are to specific details (e.g., specifically requiring an inline citation instead of a general citation) rather than to the overall principle. WhatamIdoing (talk) 20:42, 24 March 2024 (UTC)[reply]
Oppose; not sure there is much more to be said about why this would not be a great idea. I think this would go against the spirit of the project, and that it would be a very costly move in return for not much improvement. jp×g🗯️ 05:01, 21 March 2024 (UTC)[reply]
This is not a "very costly move" as you have said, as multiple editors has pointed out that this is not that much different to how modern Wikipedia processes new unsourced articles. We just don't allow them to come to the mainspace. CactiStaccingCrane (talk) 17:05, 22 March 2024 (UTC)[reply]
Draftification is done at the discretion of editors and new page patrollers, who like most Wikipedia editors are generally expected to have coherent reason for things that they do. Making it a binding policy would remove this discretion. Either way, it is not good: if it's meant to substantively change the way that article creation works on Wikipedia, it is for the worse, and if it isn't meant to substantively change anything, that is a great reason to avoid making giant disruptions in the public-facing process of a thing that has worked fine for the last 23 years. jp×g🗯️ 07:37, 23 March 2024 (UTC)[reply]
Support. I also see this as unlikely to succeed, but I'd prefer to see the project move into this direction. I think it would be an improvement to require that article creators include at least one source, and I do not see current procedure as sufficient to deal with the unsourced article problem. I can understand the objections based on grandfathering, but I would prefer the harms of temporary inequity over the harms of doing nothing. Firefangledfeathers (talk / contribs) 15:43, 21 March 2024 (UTC)[reply]
Support. I don't think the citation needs to be inline, but geez y'all, it's 2024, citations are expected in everyday culture now, anyone dumping an unsourced article into mainspace (without followup edits) nowadays is willfully ignoring our requirements and clearly has no plans to join the community. We don't need to protect these precious new editors, and we don't need to retain unsupported information that would be deleted if it was in any other format than a standalone page. JoelleJay (talk) 16:15, 21 March 2024 (UTC)[reply]
Support per Levivich. Ajpolino (talk) 19:36, 21 March 2024 (UTC)[reply]
Oppose. To be sure, a new, truly unsourced article is very likely to be hit by NPP for draftification, prod, or AFD (perhaps even when it really shouldn't). It's good practice to include at least some references. However, some editors take a narrow view of sourcing and consider implicit sources as "unsourced" when it really isn't (i.e. a newbie editor simply writing out "According to Joe Bloggs, blah blah blah..."). Secondly, the main case where valid "unsourced" articles exist are generally the frontiers that are good to create articles on for WP:CSB grounds. These are often translations of other language's wikipedia articles where there very well may be sources, but not ones easily consulted in English. Now, yes, other language Wikipedia editions have weaker notability requirements than enwiki, and yes, some of these are just authentically unsourced in the other language too. But this case is large enough that there will still be cases of plainly notable people who don't have articles yet, and deleting the articles out of misguided "consistency" doesn't make sense. Better to keep the article simple and non-controversial and wait on someone familiar with the foreign language sources, instead. Keeping this situation a valid option for creating an article means opposing the proposal. SnowFire (talk) 20:58, 21 March 2024 (UTC)[reply]
Do I feel comfortable to say that we tolerate unsourced articles because someday, somebody will magically put a citation into it? No. Without work from the WP:WikiProject Unreferenced articles, Category:Articles lacking sources backlog would now have >150k articles and will keep growing from here. Plus, by de facto standard, we already strongly recommended that new articles should have an inline citation. Why is it so difficult to codify that into policy? If you translate an article from a foreign language to English, then it is very trivial for them to copy the citations to the English version of the article or find one source that verify that this topic/subject actually exist. It's not that difficult. If you want new editors to understand the new PROD criteria, why not being more clear in the Article Wizard that Wikipedia articles need to have sources? And if my proposal sounds BITEy, then that's because the whole PROD/AfD process itself is BITEy. Please, if that's the reason why you opposed my proposal, please suggest changes to PROD and AfD instead. This is not my fault.
You might ask, why do I demand an inline citation in my proposal? This is because an inline citation helps me to verify a specific statement in the article. If that reference is placed below, a reader would have no idea what is the specific statement that we are referring to. Just to mention this, most new editors nowadays don't start out editing in wikicode, they start out with VisualEditor. When they fire up VisualEditor for the first time there is an explicit instruction dialog hovering below the citation button that instructs you how to make an inline citation. It's really not that hard to do for a beginner. Even if VisualEditor somehow cannot process your URL, you can always type that citation in plain text.
And why do I ask that citation must come from reliable source? Because we don't want people to write an article about a notable topic with absolutely shitty sources, like Twitter posts, gossip websites, forums, etc. If the whole article is talking about the Ancient history of Botswana and every citation in that article refers to a self-published Blogger page, then that article is just as useless as it is uncited, because we cannot verify whether that article is spewing out myths or not. Many editors here objected my proposal due to WP:NEXIST, but why is it so hard to ask people just cite one of those excellent sources to the first sentence, to verify that this topic actually exists in real life?
I'm just gonna sum up my proposal as follows. Missing content on Wikipedia is terrible. Having incorrect content masquerading as facts on Wikipedia is much, much worse. CactiStaccingCrane (talk) 17:00, 22 March 2024 (UTC)[reply]
Oppose. I would think that if one was going to go through the expense of yet another RFC on the same theme (the third within six months?), it would have at least been better thought out. As Joe Roe and others have highlighted, clearly it is not. Anyway, we should not introduce this new process, subtly different from existing ones yet also similar and overlapping in purpose. I hesitate to expand our assortment of procedural mechanisms for deletion or quasi-deletion, which is already confusing to editors. Adumbrativus (talk) 04:21, 22 March 2024 (UTC)[reply]
It is cleanup, in that a PROD indicates that "this article that does not have inline citations does not belong to Wikipedia". And it is not wrong to do so, because it corresponds to our current best practices. CactiStaccingCrane (talk) 11:05, 22 March 2024 (UTC)[reply]
Support There is no excuse for creating an unsourced article in 2024. Unsourced articles cannot be repaired by adding sources; they must be rewritten because without the sources we cannot tell if they are COPYVIO. Hawkeye7(discuss) 08:20, 22 March 2024 (UTC)[reply]
Support. The bar needs to be raised. Stifle (talk) 11:42, 22 March 2024 (UTC)[reply]
No, this particular bar should not be raised. The proposal is about new unsourced articles and suggests to delete them instead of draftifying as we currently do. This would make our problem of WP:BITEing newbies worse and give less feedback on how to write an acceptable article, without any change to the amount of unsourced content in mainspace. The backlog of unsourced articles is completely unconnected to the new articles that this proposal is about. —Kusma (talk) 14:10, 22 March 2024 (UTC)[reply]
How/when would that happen? Due to the backlog due to a handful of active NPP'ers being asked to do too much of the million editors' work and otherwise being too difficult and painful, it won't even get looked at at NPP until after the draftifying time limit runs out. Not that I think that there are very many completely unsourced new articles. The pervasive problem is lack of GNG sources for articles that need those. North8000 (talk) 14:23, 22 March 2024 (UTC)[reply]
Oppose - the suggestion has already been turned down, apparently twice - no justification for bringing it up again so soon. For the rest, as per James500 and Joe. Ingratis (talk) 16:23, 22 March 2024 (UTC)[reply]
The last proposal said that we should PROD all articles right now that does not have a source. That's absolute lunacy. What I'm suggesting here is what the community has effectively done to new articles since 2020. CactiStaccingCrane (talk) 17:01, 22 March 2024 (UTC)[reply]
My bad - I should have implied "substantially similar", not "identical". On which, I'll just quote a brief comment from up above:
"All of the objections raised to the two similar proposals in the last few months still apply. I really can't be bothered to repeat them again. We're supposed to be building an encyclopedia here. Clearing a backlog is only incidental to this. Phil Bridger (talk) 08:52, 17 March 2024 (UTC)"
I could add to that but it would be pretty much what James500 and Joe have already said better. Ingratis (talk) 06:37, 23 March 2024 (UTC)[reply]
Oppose I'm confused about what @CactiStaccingCrane: is proposing here. The header claims the proposal is (1) "deprecating new unsourced articles". But then he says (2) I propose that articles that [...] [do] not have any inline sources can be PRODed. Unsourced articles aren't the same as articles lacking inline citations. He then specifies (3) "Such a PROD can only be revoked after an addition of one inline, reliable, third-party source" – apparently raising the bar even higher, since articles lacking inline, reliable, third-party citations aren't the same as articles merely lacking inline citations. There must be clarity on what exactly is proposed to be changed. – Teratix₵ 16:24, 22 March 2024 (UTC)[reply]
Oppose Seems to be covered well by existing (albeit broken) processes. Sungodtemple (talk • contribs) 01:01, 23 March 2024 (UTC)[reply]
Oppose There are ways other than deletion that can be employed to clear the backlog. I would support a draftification process for unsourced articles to get potentially problematic content out of mainspace, but simply deleting discourages new editors from learning how to write articles and ultimately staying on the site. funplussmart (talk) 02:51, 23 March 2024 (UTC)[reply]
Comment- MediaWiki Edit Check project - (has anyone else mentioned this? sorry if so) this looks as though it is about to deal with most of the issues raised here, to the liking of some if not of others. Ingratis (talk) 12:07, 23 March 2024 (UTC)[reply]
For the proposer's reason. (Sorry about where I put the comment, I was clicking the wrong reply button.) OrdinaryGiraffe (talk) 01:11, 24 March 2024 (UTC)[reply]
Oppose (quite strongly), because it this would prevent all translation of articles from wikipedias that accept general referencing (which, incidentally, still technically includes our own). (1) Yes, the translator ideally will get the original source, track down the information, and convert general referencing into inline referencing. But often it's impossible to track down all the sources, and we have to assume at least some good faith that the original author did use the sources they provide. A translation is still a starting-point for later editors to convert the general references to inline, and to find new references. Wikipedia articles aren't expected to be complete at first appearance. (2) We promise our readers that everything in Wikipedia can be traced back to a source. We don't promise how much leg-work it will require. Even an inline reference can require work, if it's just a book with no page number. Or a book that's really hard to track down. Sometimes an article here is quite short, and has a couple of general references that themselves are either quite short, or have a clear section obviously on the subject (e.g. references to Grove in biographies of musicians), and general referencing is straightforward and reasonably helpful to the reader. We are also not obliged to pander to hypothetically incredibly lazy readers who want to be told that the information is in the third word on the fourteenth line on page 37. There are circumstances when general referencing isn't evil, and we should trust AfC and the new page patrol to use their discretion to accept such articles even if not inline-referenced. Elemimele (talk) 21:16, 25 March 2024 (UTC)[reply]
(1): Is it that difficult to ask for one source? Our built-in translation tool also translate the references for you, so I don't see why this is so hard to do.
(2) and (3): That's true. I think I have to reconsider this proposal for this reason. CactiStaccingCrane (talk) 02:17, 26 March 2024 (UTC)[reply]
@CactiStaccingCrane, while you're thinking about translation, take a look at the German-language Wikipedia. Check out articles like w:de:Sandstein (=sandstone). There are general references, but I didn't see a single inline citation.
Even among their TFAs, which AFAICT do have inline citations, they may be sparse. Several this month (including Herrenhof (Mußbach) and Schwachhauser Heerstraße, which we don't have articles about) had less than 10 inline citations.
I wouldn't personally want to emulate this approach, but it is something to think about as a potential source of complications. WhatamIdoing (talk) 04:42, 26 March 2024 (UTC)[reply]
Yes, that's precisely what I meant. I don't condone the German Wikipedia's approach; it would be better if they used more inline citations, but unfortunately they often don't, and yet nevertheless they have useful, well-written articles on subjects we don't cover, and the articles are sourced, just not the way we do it. Elemimele (talk) 06:50, 26 March 2024 (UTC)[reply]
Oppose from a new page patroller, using PROD for this is WP:BITEy and the wrong process, the current remedy of WP:DRAFTIFY gives the often new editors more time to rectify sourcing issues and gives them more venues to get help. ~ A412talk! 02:52, 26 March 2024 (UTC)[reply]
@A412, PROD is the prescribed process for completely unsourced BLPs (which seems to be the majority of articles that NPP deals with). Do you feel that BLPPROD is also BITEy? Do you use draftification to get around the BLPPROD rules? WhatamIdoing (talk) 04:45, 26 March 2024 (UTC)[reply]
No, because WP:BLP, as policy, is more applicable than the WP:BITE guideline. This doesn't mean we should expand the pattern we use to deal with unsourced BLPs (which exists for a specific reason) to the more general case. ~ A412talk! 04:55, 26 March 2024 (UTC)[reply]
Oppose. An issue for someone who's new to Wikipedia, still learning wikitext etc. is that adding a citation in the correct format isn't entirely straightforward. Even using the provided templates, you have to know which detail belongs in which field. It's another technical thing to be learnt. It's quite possible that the reason someone hasn't added any citations yet is that they don't feel confident adding them. "How do I make the references appear in the right place?", "What does name mean on the form?", "How do I know if I'm choosing the right template?", "What is a template anyway?" People don't automatically know this stuff, and they're already having to read up on how everything else works. I think a friendly offer of help with inserting them would be more useful. "Find a reference you need to add, and I'll show you what to put in the popup form." Musiconeologist (talk) 02:07, 28 March 2024 (UTC)[reply]
Oppose As seen by the recent backlog drive, many unsourced articles have sourcing available and it just takes an editor to spend 10 mins to find them. The problem is that this rule would be deleting potentially encyclopedic subjects written by editors that lack the expertise to add sources. Also, not all pages require sources. For example, most lists lacking sources do little harm to Wikipedia. What about disambiguation pages, obviously those shouldn't have sources. At what point does a list page become a disambiguation page, and vice versa? And pages with valid general references should never be deleted. — PerfectSoundWhatever (t; c) 16:51, 28 March 2024 (UTC)[reply]
As also seen by the recent backlog drive, it's really easy to add a poor source to a shoddily started article and call it a day. It's much easier and better in the long haul if we expect the editor writing the article to establish it based on sources, rather than pretending it's equally worthwhile to write articles backwards. Remsense诉 17:06, 28 March 2024 (UTC)[reply]
Strong support – per above, there's no reason to allow additional articles written entirely backwards—the majority of outcomes are either unsourced articles, or backfilled articles that will likely need to be largely rewritten anyway because the original author wasn't actually working from any sources. Better to do the rewriting first before the article actually goes live. Remsense诉 17:09, 28 March 2024 (UTC)[reply]
Draftifying is the solution This is basically de facto practice anyway. An article without sources is going to get draftified pronto. Then, either the author will clean it up, or it gets deleted in six months. I don't know that we need a dedicated kind of PROD, I think regular PROD could work if it isn't suitable for draftifying. But I do agree with the sentiment that we are no longer in the wild west days of Wikipedia. Sourcing exists, can be found, and should be found before a totally unsourced article gets thrown out there. CaptainEekEdits Ho Cap'n!⚓ 19:24, 28 March 2024 (UTC)[reply]
Support in theory, Oppose as written. I agree that new articles with no sources should not exist. However, there must be safeguards. 1. Draftifying is better than PROD. It preserves good text, even if unsourced. 2. The PRODing editor and the deleting/draftifying editor must look for sources. We cannot have editors mass–PROD and mass–delete articles without WP:BEFORE simply because of this rule. This rule, or any like it, must explicitly require WP:BEFORE. If those conditions are met, I will support the change. Toadspike (talk) 11:04, 30 March 2024 (UTC)[reply]
Support the encyclopedia should be built from V up. Draken Bowser (talk) 21:03, 3 April 2024 (UTC)[reply]
Support draftification rule new articles that are completely unsourced or are built on unreliable sources should be draftified as part of the NPP process, even if the NPP reviewer finds that sources exist. The article can then be improved and published to mainspace once sources are added to it (same bar we put on AfC articles). I do not support deletion of content simply because it's unsourced. Broc (talk) 12:52, 5 April 2024 (UTC)[reply]
Comment I wanted to correct one erroneous item which is that draftifying articles is typically an available option. Due to the backlog at NPP they are all generally past the time limit for doing that. North8000 (talk) 15:16, 5 April 2024 (UTC)[reply]
Do we need to increase the time limit that articles can sit in draftspace … so NPP can work through their perennial backlogs? Blueboar (talk) 16:31, 7 April 2024 (UTC)[reply]
The time limit North8000 is talking about is that articles already than 90 days shouldn't be moved to draft. That was agreed here, but I noted at the time that the specific figure of 90 days was just a starting point that can and should be revisited. – Joe (talk) 11:05, 8 April 2024 (UTC)[reply]
Support moving to Draft with a PROD-like tag. Honestly, if the article author can't be bothered to source the article, it can't be that important. We are no longer barn-building here. Virtually every subject of any objkective imortance, and a good many of no objective importance whatsoever, are already here. Guy (help! - typo?) 16:16, 7 April 2024 (UTC)[reply]
Comment @CactiStaccingCrane why is there a need for an inline source? It's not a strict requirement for articles in general, nor is necessary to establish notability, and it only creates an additional burden on the editor. I see many "oppose" here because of this requirement, and I was hoping you could explain the rationale behind it. Broc (talk) 10:30, 8 April 2024 (UTC)[reply]
Because this is de facto required for all new articles on Wikipedia. Inline source helps the person who actually use the reference section have an easier time verifying facts in the article. CactiStaccingCrane (talk) 12:18, 8 April 2024 (UTC)[reply]
My understanding is that they are only required for GA/FA, as well as for contentious material and direct quotes (per WP:IC and WP:MINREF). Broc (talk) 14:28, 8 April 2024 (UTC)[reply]
Comment I wasn't aware of the RfC on unsourced articles, but the consensus at that RfC is incredibly disappointing. Simply put, we should not have unsourced articles. We are supposed to be an encyclopaedia, and having unsourced articles makes us little more than a social media site or a free webhost. Just recently, two long term unsourced articles were discovered to be hoaxes: Wikipedia:Articles for deletion/St. Berks and Wikipedia:Articles for deletion/Miami-Petersburg Department of Water and Sewers. How many long term unsourced articles are hoaxes? How much misinformation is there sitting around on the project, potentially fooling readers? I think the draftify process works relatively well for new articles, the problem is long-term unsourced articles and unfortunately the community has shown an unwillingness to take it seriously. AusLondonder (talk) 22:28, 9 April 2024 (UTC)[reply]
@AusLondonder: I am quite sure that nobody things we should have unsourced articles. Opposition centres around how to balance our goal of creating a verifiable encyclopaedia against our equally-important goals of being an encyclopaedia that anyone can edit that fixes problems instead of removing them. I don't think it's fair to conclude that, if others see that balance differently from you, they're not "taking it seriously". – Joe (talk) 10:01, 10 April 2024 (UTC)[reply]
We currently have many thousands of unsourced articles, the backlog is enormous. Having unsourced articles is a credibility problem for a start. With no sources, how can we verify we're not spreading hoaxes to our readers? AusLondonder (talk) 12:18, 10 April 2024 (UTC)[reply]
The issue is that when you speedily delete an article rather than sourcing it, tagging it, prodding it, moving it to draftspace, etc. you don't give any opportunity for the editor to improve it by adding sources, you reduce the opportunity to educate them about the desired standards for Wikipedia articles and you make it far more likely they won't develop into a productive editor who improves the encyclopaedia. Short term, arguable improvements should never come at the expense of long term definite improvements. Especially as this proposal would speedy delete articles that have sources which just happen not to be inline. Thryduulf (talk) 13:17, 10 April 2024 (UTC)[reply]
Oppose creating PROD PLUS. If someone makes a new stub and drops in a ==References== section, I'm not too worried that the references aren't "inline" and require some syntax formatting to not have it summarily deleted. — xaosfluxTalk 23:49, 9 April 2024 (UTC)[reply]
@Xaosflux what about completely unsourced pages instead? Broc (talk) 06:11, 10 April 2024 (UTC)[reply]
Oppose per Pppery and Sdkb's criticisms of a grandfather clause. These articles with the unreferenced tag are avoiding draftification in the NPP process by satisfying the relevant notability criteria, so it stands to reason that reliable sources can be found for other editors to create inline citations, even if it will be a herculean task for all 95K articles that currently have the tag. BluePenguin18 🐧 ( 💬 ) 08:14, 12 April 2024 (UTC)[reply]
Oppose: This proposal risks discouraging new contributors by setting overly stringent barriers to entry. Instead of penalising new, unsourced articles, we should guide and educate new editors on the importance of sourcing. Let's not make participation in Wikipedia more daunting than it already is. FailedMusician (talk) 12:50, 13 April 2024 (UTC)[reply]
Proposal: Add a link to the WP:Contents page either on the Main Page itself or on the mobile sidebar
I found that it is very hard to get to the WP:Contents page in mobile view. Instead, I would have to search for in the search bar and go into desktop view to access it. I am proposing that we include this page somewhere on the main page. No opinion on where to put it on the main page, but my first thought would be to put it the other areas of Wikipedia section. Please comment with your thoughts below. Interstellarity (talk) 00:21, 23 March 2024 (UTC)[reply]
I would support a swap from the portals link to the contents link. Interstellarity (talk) 01:10, 23 March 2024 (UTC)[reply]
The portals link was added to that box as a small concession after we decided to remove the more prominent portal links at the top of the Main Page. I'm not saying that's a reason to keep it, but just historical context you should know.
I think there's a larger underlying problem here of it being difficult to access sidebar links in mobile generally. Some links are justifiably not present there, as they relate to tasks better done on a desktop, but the contents page seems useful to everyone. I'd like to see an effort to push the developers to refine the links there. Sdkbtalk 14:42, 29 March 2024 (UTC)[reply]
I don't use either Contents/Portals or Contents regularly, but it seems that they are fairly equivalent, and the Portals look much nicer and have more links. I don't see the point of replacing the Portals with Contents alone – @Interstellarity, could you please explain why you find Contents more useful than Portals? Toadspike (talk) 10:51, 30 March 2024 (UTC)[reply]
@Toadspike: Sure thing. The contents page is the main gateway for browsing Wikipedia. While most people search for a specific article, it would be helpful for people like me that like to browse Wikipedia. On mobile, the contents page is not easily accessible compared to desktop so I think in this way, we can make it more accessible in mobile. The contents page has a lot of ways to browse Wikipedia by category. Whether people like overview articles by category like looking for some wars going on in the history section or looking at vital, good, and featured articles, it's a great way to be able to browse what Wikipedia has to offer. I hope you consider my reasoning and that you understand where I'm coming from. Interstellarity (talk) 12:57, 30 March 2024 (UTC)[reply]
I understand these goals, but I think WP:Contents/Portals does basically the same thing, and seems to work on mobile as well. Toadspike (talk) 14:23, 30 March 2024 (UTC)[reply]
WP:Contents is the second link in the sidebar. If that doesn't appear on mobile, that is a problem with the mobile view not the Main Page. We shouldn't add redundant links for desktop users just for the convenience of mobile users, especially for such an obscure and little-used page (the page views tool shows it is the least used link in that part of the sidebar). Incidentally, the correct place to suggest changes to the Main Page is T:MP, not here. Modest Geniustalk 11:15, 3 April 2024 (UTC)[reply]
To your last sentence—not necessarily. The last major mainpage redesign (Removal of portal links from Main Page) was proposed and passed here. In any case, I suspect this page is much more watched. Aza24 (talk) 04:22, 10 April 2024 (UTC)[reply]
Bring back the Book Creation Tool.
The Book Creation Tool was an amazing, fantastic, super useful tool.
It is an obligation to bring it back.
Cheers. MikeYahooCom (talk) 05:48, 1 April 2024 (UTC)[reply]
@MikeYahooCom Do you have a link to what it would look like/an old documentation, so we have more detail on what it'd be about? Cheers Cocobb8 (💬 talk • ✏️ contribs) 13:29, 1 April 2024 (UTC)[reply]
@MikeYahooCom, to be more specific, go to Help:Books and click on the link in this section. You can enable the tool and it will appear at the top of pages you are reading. StarryGrandma (talk) 22:19, 1 April 2024 (UTC)[reply]
Thanks for the reply and the advice. But it used to be that you could aggregate topics/chapters and download all of them in PDF in the format of a PDF book, just by clicking download. It would download it and create the index, with page numbers and chapters. All of it in one unified PDF document.
It really was a great tool for creating, in seconds, a PDF book of topics you liked including an index, page numbers and all.
Really never understood why it was eliminated. MikeYahooCom (talk) 01:48, 2 April 2024 (UTC)[reply]
Unfortunately (that relatively little used) feature was provided by a 3rd party and that 3rd party wasn't able to keep that integration up with the changes of Mediawiki and Wikimedia for 8 years, after which it broke and there is no easy way to restore or rebuild that without significant investment. (i'm not blaming the 3rd party, I'm pretty sure it wasn't exactly sustainable on their end either, they haven't even updated their website since). —TheDJ (talk • contribs) 09:00, 10 April 2024 (UTC)[reply]
Template substitution counter
There is currently no way to track template substitutions without adding code to templates that adds tracking marks to the template's output, and some bot watching for these marks. Aside from all that overhead, these marks may make use of this mechanism impossible in some cases.
Tracking substitutions should be a comparatively simple modification to MediaWiki. When a template gets substitued, just increment the appropriate per-template counter, which could be accessed through a magic word. If you want to get fancy, you can add a list of the substitutions performed for this edit to its page history entry.
Having such a counter would be useful when a template is up for discussion, and to help gage when protection is appropriate.
So, why not make a feature request? Paradoctor (talk) 03:02, 6 April 2024 (UTC)[reply]
Support - I can see the use of this when templates are rarely transcluded, but nearly always used by substitution. Cocobb8 (💬 talk • ✏️ contribs) 13:29, 6 April 2024 (UTC)[reply]
What would happen when a template is substituted in one edit, and that edit is subsequently reverted? --Redrose64 🌹 (talk) 13:37, 6 April 2024 (UTC)[reply]
Why should that be an issue? Paradoctor (talk) 13:41, 6 April 2024 (UTC)[reply]
Presumably nothing, if the intent is to understand how often a template is substituted (and thus how "important" a template is, and thus whether it should be protected/watched). That the resulting text was subsequently reverted doesn't change that the substitution happened.
It seems like a slightly useful feature to me.
The only thing I would question is whether we have any evidence of an actual problem that needs solving. I suspect most of the commonly substituted templates are well known, like {{afd}}, and are already recognised as high risk. Barnards.tar.gz (talk) 12:42, 8 April 2024 (UTC)[reply]
We have evidence that we don't know. That is the point here. Paradoctor (talk) 14:54, 8 April 2024 (UTC)[reply]
What I mean is that if the important templates were being vandalised, we would probably have noticed that. Barnards.tar.gz (talk) 18:56, 8 April 2024 (UTC)[reply]
Why make editors do guesswork when a machine will do the same far more accurately, for free? Paradoctor (talk) 02:55, 9 April 2024 (UTC)[reply]
I get it, that’s why I said it was slightly useful. It would be a good feature. Just a low priority one unless there’s a material problem that it would fix. Barnards.tar.gz (talk) 07:40, 9 April 2024 (UTC)[reply]
I think what is being said here is that when the template is substituted, it isn't being linked or contacted in any way (because its content is being posted). Lee Vilenski(talk • contribs) 12:31, 8 April 2024 (UTC)[reply]
@Paradoctor: This isn't something that we would be implementing directly here on the English Wikipedia. It would require extending the database to maintain a new page value (or more likely a new linked table) - keeping in mind almost any page can be "transcluded". So if you want every parser call to {{subst:X}} to increment a counter referenced to page X, you will indeed need to open a feature request upstream for that. Feel free to do so, there are lots of ideas opened that way. — xaosfluxTalk 14:39, 9 April 2024 (UTC)[reply]
why not make a feature request?[22] Sometimes I wonder why I bother to say anything at all. Paradoctor (talk) 15:56, 9 April 2024 (UTC)[reply]
And? You are asking for reasons why you shouldn't go make a feature request? We didn't come up with any, so go right ahead. While this page's guidelines do ask for Software changes which have consensus should be filed at Phabricator. to be discussed here, what I called out is that this type of software change isn't the type that will require community consensus. It would have no impact on readers, and no direct impact on editors. — xaosfluxTalk 23:53, 9 April 2024 (UTC)[reply]
What's the mechanism by which page saves get run through edit filters? Presumably there is something being carried out there which is capable of evaluating whether a thing's been done or not -- I don't know, maybe it's impossible to detect if template text is being expanded or not, but it seems kind of simple to me. At the very least it shoudl be possible to detect if {{subst: is being added, right? jp×g🗯️ 18:40, 11 April 2024 (UTC)[reply]
Well, no bigbrain comments on how this fits into the mw db schema or anything, but one issue with this does jump out to me, which is that this seems like it would fail to reflect if the template were removed later. Like, if there is some template that's getting substed 80 times a day in 2024, then we decide it's inefficient and stop using it completely in 2025, wouldn't a {{TOTALSUBSTCOUNT}} in 2026 be kind of misleading? jp×g🗯️ 18:40, 11 April 2024 (UTC)[reply]
You just gave me an idea. Let me get back to you tomorrow. Paradoctor (talk) 19:46, 11 April 2024 (UTC)[reply]
Is this something we really need to track? Personally, I hate our over-reliance on templates, and would be happy to deprecate all of them. Blueboar (talk) 18:54, 11 April 2024 (UTC)[reply]
You mean, no templates at all? 🤯 Paradoctor (talk) 19:47, 11 April 2024 (UTC)[reply]
Wikipedia Sandbox
Not sure what happened here Wikipedia:Sandbox? May have been a talk about redoing layout adding tabs? Would have brought this up on its talk but iit is also a sandbox (where to talk about sandbox?).
To thw point..... Not only does it look very bad, but its an accessibility nightmare.
Tabs look horrible...2 tabs are using the strike parameter for those using the strike out usernames gadget...word "sandbox" is reapted over and over making tabs huge for no reason.
Main problem is the accessibility of the sandbox message that is a wall of text that is not clear as to what to click.start. Tabs cause whole page to have vertical scroll bar for some. Why so many sandboxes and some with odd space in naming i.e Wikipedia talk Sandbox? Why link Module:Sandbox that is template editor level protected? Looks messy and a bit overwhelming for new editors Moxy🍁 06:00, 12 April 2024 (UTC)[reply]
I self reverted for now and we can discuss which tabs, if at all, are worth keeping. The perspective for a new user is that there should be a way to jump between the different sandboxes. If you want the tabs to read something else, well... {{sandbox heading/Tabs}}. AwesomeAasim 06:48, 12 April 2024 (UTC)[reply]
2 tabs are using the strike parameter for those using the strike out usernames gadget probably because User:Sandbox and User_talk:Sandbox are both user pages of a blocked demonstration account. It shouldn't be like that; maybe it should only be struck out, etc. in contributions and history pages and not on content pages. Hmm.... AwesomeAasim 06:53, 12 April 2024 (UTC)[reply]
New users are given zero guidance and then get yelled at when the break the rules they didn't know about. Therefore, I propose that, after sign up, we make a page (perhaps something like H:INTRO?) that we then direct new signups to
Two questions I have:
Will new users simply click away without learning anything?
How much will this help?
As it stands, the current onboarding procedure is basically nothing: just set them out there and yell at them when they mess up. Something needs to change and I hope my proposal will generate some discussion on how to make the onboarding process better. NW1223<Howl at me•My hunts> 01:37, 7 March 2024 (UTC)[reply]
Aaron highlighted the Growth team features. To summarize them, new users get Special:Homepage as their base-camp (you might have to activate it in your preferences). There, they have access to selected help links and,
Some wikis also post a message at talk pages. From what I observe*, a successful welcome message requires the following:
it is a real message, not a block of links
it is clearly signed by a real human
it includes a clear indication "contact me if you have any question"
they are posted before the user make an edit (so that they can ask a question to the user who welcomed them**).
Messages consisting of blocks of links are not successful (a known issue), in particular when the message look like a banner or something else than a discussion. Signatures have to be clear, as the way we format our messages on wikis is not something the rest of the works is used to.
* Of course, what I observe is not a proof of anything, but I observe a lot of newcomers/experienced users at a lot of wikis since a long time. :)
** This is how Mentorship works: you get a name to contact at Special:Homepage (but unfortunately, at your wiki, not everyone gets one as we don't have enough mentors).
Since so many recent changes have the "newcomer task" tag, I think it's enabled by default for newcomers. Aaron Liu (talk) 15:28, 7 March 2024 (UTC)[reply]
It is default for all new accounts, correct.
But Mentorship is only available to 50% of new users for the reasons I explained, and a key feature to discover editing, Add a link, is still missing at your wiki.
or we could just not yell at them... It is my personal opinion that a lot of our users have themselves forgotten they are on wiki that anyone can edit. —TheDJ (talk • contribs) 21:48, 7 March 2024 (UTC)[reply]
I wish our policies had TL:DR versions of them too because some of them are very lengthy and I have no doubt that that's put some people off from editing here. ♠JCW555(talk)♠ 22:16, 7 March 2024 (UTC)[reply]
Although experienced editors do make mistakes from time to time, in my experience, the vast majority of new editors who get "yelled at" are spammers, self promoters, POV pushers, axe grinders, conspiracy theorists and others whose manifest goals are not in alignment with improving this great encyclopedia. As I see things every day on the firing line, any editor who comes here with a genuine intent to neutrally improve this encyclopedia is almost always welcomed with open arms. So, when an editor puts forward vague assertions of "yelled at", I expect diffs and specific cases. Who in particular got "yelled at", and why? Cullen328 (talk) 09:49, 9 March 2024 (UTC)[reply]
When I see an edit that degrades the encyclopedia, I revert it, and usually use Twinkle to leave a message on the user's page, with or without an additional comment. I think that kind of response is what some are calling "shouting". I will not leave unreverted an edit that damages the encyclopedia, no matter how well intentioned. I think the lowest levels of the Twinkle warnings are benign enough. I use the stronger versions of Twinkle warnings when a user repeats the same kind of edits after being warned. I block users who repeatedly over a short period of time make obviously problematic edits after being warned. It may be that new users don't see messages on their talk pages, but that is not a reason to allow them to continue to make edits that degrade the encyclopedia. Donald Albury 14:13, 9 March 2024 (UTC)[reply]
@Cullen328, how would you describe to an external observer how English Wikipedia welcomes good faith users with open arms? I'm asking it as finding how bad faith users are treated is easy (Donald gave a good example above), but examples of how one deals with good faith users is more difficult to find.
Actually, what I observed over the years is that vandalism or damageable edits get a warning message, while good faith edits are just left as they are, with no message, because they fit what is expected.
Yea, that makes sense, especially because then newcomers could fix the typod on articles, like (off-topic warning) how I fixed an typo on the article for WFSU-TV. The thanks option is actually pretty cool. mer764KCTV5 / Cospaw (He/Him | Talk • Contributions) 16:37, 13 April 2024 (UTC)[reply]
Trizek (WMF), we have places like the Teahouse and the Help Desk where new editors can get assistance, and they are easy to find given the amount of traffic they get. I have over 10,000 edits to the Teahouse and over 1,200 to the Help Desk, so I have considerable experience helping and encouraging new editors. Many new editors come to my talk page asking for advice. and I have 5,600 edits there. I agree that bad edits and those that make them get more attention in general than good editors making uncontroversial typo fixes, converting bare URLs into bibliographic references, and reverting vandalism. If I notice particularly good work from a new editor, I will definitely thank them. I think that a brief, personalized compliment is better than 100 "welcome templates". The analogy that comes to mind is that few people give detailed thanks to people doing routine work. Few people go into a McDonald's and lavishly compliment the people sweeping the floors, taking the orders and packaging up the french fries. We just treat them politely, with a "thanks" to the order taker being about the extent of it. Cullen328 (talk) 20:09, 10 March 2024 (UTC)[reply]
Trizek (WMF), I don't know if the WMF collects any statistics, but I wouldn't be surprised if the English Wikipedia gets more than its fair share of bad faith users, making experienced editors more cynical. At least if I were a spammer, self promoter, POV pusher, axe grinder, conspiracy theorist or any other bad faith user I'm sure I would prefer to target the largest Wikipedia that has the largest readership. Phil Bridger (talk) 20:35, 10 March 2024 (UTC)[reply]
@Cullen328, thank you for the details. I think volunteer-me have the same profile as yours, but at my wiki. I don't really count places mike the Help desk or the Teahouse as proofs of being welcomed, as these are places you have to discover (or at least find the link to them). Thanks are apparently only for "particularly good" edits as you said. Messages are often perceived as costly to create. What would you (any of you) do to show a user that they edit is going in the right direction, at low cost?
@Phil Bridger, I'd say the bigger the wiki, the more likely it is to attract people. But as I read it quite often, I kind of think there is a perception of a mass of bad faith users that damage things, while only a few users do it right. I'm not sure this is true: maybe there is a perception bias, as badly behaving users are way more visible than users who do things the right way, don't you think?
I'm assuming that, in this context, you're using "getting yelled at" not to mean overt incivility (which is against policy), but rather more subtle snubbing, e.g. ignoring messages or responding curtly. I honestly think that this encyclopedia could improve if this just didn't happen at all, regardless of the person. spintheer (talk) 03:43, 27 March 2024 (UTC)[reply]
Trizek (WMF), there used to be a bot called HostBot that would send welcoming Teahouse invitations to new accounts in good standing that had made 10 edits within a few days. Sadly, the bot operator, User:Jtmorgan, is far less active in recent years, and the bot no longer operates. Maybe you can look into that.
If you take a look at the Home Page, you will see that the first prominent word is "Welcome". The prominent phrase "anyone can edit" links to Help:Introduction to Wikipedia. There is a prominent link to Help:Contents on the Home Page, which links to many other help pages. Further down are links to the Community Portal, the Village Pump, the Teahouse, the Help Desk, the Reference Desks, and so on. In other words, the page that new editors first see shouts "Welcome! How can we help you?" I know about banner blindness but I doubt if it would make much difference if we displayed "WELCOME" in bold, bright orange all caps, flashing and flickering. It wouldn't help and it would make us look ridiculous.
Most new accounts do not ever edit. Of those that do, most of those make only a handful of edits and then lose interest. Of those that continue editing, a significant percentage have motivations incompatible with the goals of the project as I described above. Of those who really want to improve the encyclopedia, many are here to create or improve one or two articles about topics of great interest to that person, and then they stop editing. Student editors are here to get a good grade, and only a tiny percentage continue after the course is over. People go to edit-a-thons to satisfy their curiosity, meet cool people and get some free food. Only a tiny percentage keep editing.
I have been wondering for nearly 15 years what the positive psychosocial factors are that separate all those types of people who contribute little or no encyclopedic content from the "rare beasts" who make improving this encyclopedia in countless ways an avocation for many years. I cannot answer that question with confidence although I have my pet theories. I hope that the WMF could make that research happen but I do not know.
As an adminstrator, I believe that blocking bad actors like harassers, vandals, spammers and the like is essential, because showing such people the door makes the editing environment more hospitable. And so I am not ashamed to have blocked nearly 10,000 accounts. I think my work in that area makes Wikipedia a more welcoming place. I think I have said enough so I will stop now. Cullen328 (talk) 02:49, 15 March 2024 (UTC)[reply]
There's been some research on the psychological profile of Wikipedians. I am not sure you would consider the factors to be "positive", but if memory serves, we are above average for neuroticism and below average for agreeableness. In plain English: we start editing because there's a typo, we would rather be right and have an argument than go along with something that's wrong. We also don't like change. This all aligns with my experience. How about you? WhatamIdoing (talk) 01:53, 19 March 2024 (UTC)[reply]
I like change and demand a link to such a study immediately >:( Aaron Liu (talk) 02:05, 19 March 2024 (UTC)[reply]
@Cullen328, thank you for your detailed answer. You describe what I would call "passive welcoming": various signs, at various places that convey the idea of welcoming others. At the opposite, "active welcoming" goes more on the way of telling users personally that you can mentor them, thank users for their edits, etc. This is something you do, and I believe it is super important.
It tights to positive reinforcement: someone getting a positive stimulus on their edits are more likely to continue participating. If that positive discourse comes from a human, it has way more chances to be received and appreciated, compared to one coming from an information message on static page.
Following what @WhatamIdoing said or what @Dustfreeworld illustrated above, we, communities, are apparently very good at saying when something gets wrong. Worse, we are very good at qualifying one edit as not good even if just a part of it is not good. Reverting seems to be sometimes easier than fixing up an edit. And I'm not talking of vandals and trolls there: my focus is on users who genuinely came to fix something and saw "be bold" written at various places.
This topic started with the question of onboarding new users, but it is also on how to keep them editing. As we are in the ideas lab, I'm looking for your ideas: what would you (any of you) do to show a user that they edit is going in the right direction, at low cost? What do you miss to encourage users in an easy way?
@Trizek (WMF), thanks for the ping :-) I’m not sure if I can give much useful comment about your questions, because I’m facing issues very similar to those described in the “How do we ... “ discussion myself as well… ...
My problem is, there’s a user who really doesn’t like me. It seems that my edits are being watched. When they think there’s an “opportunity”, they will suddenly “jump out”, sometimes just within minutes after my edit, nominate the article I edited for AFD, or have half of an article deleted, or criticise me on talk page and have the thread I opened being closed, or, directly yelling at me that “You’re sprouting ... “, etc. All within a short time / same day, like heart attacks. You can’t feel the stress/threats just from viewing the page history unless you’ve experienced them (and that can only be felt from those notifications popping up). And when I tried to restore the removed content, I faced 3RR and 2 warnings, all within minutes; followed immediately by very unpleasant “discussion”/criticism on the project’s talk page.
When I look up the warning templates pages [23][24], I can’t find the warning template that they used. There is no such (level 4) warning template which says “restoring good-faith content is disruptive” (not to mention those are sourced long-standing content not added by me). It seems that they have “tailor-made”/created their own version of warning message for me.
If I were a new user, I would have been threatened and left already. Definitely, with no doubt. I’m quite sure that they have done similar tricks (3RR + level 3/4 warnings) to other good-faith editors as well. (This differs greatly from most other editors do, like providing a detailed edit summary, just remove one or two sentences/sources at a time unless they are doing a rewrite, tagging it first, try fixing the problem first, discuss civilly on talk page first, and only remove outright contentious bad content like those involving BLPs, etc.)
But I can understand why other users may not notice that or can’t see the problem because one can’t feel the tension just from viewing the page history, or, they might not understand how bad I felt when I saw large amount of valuable content that had been there over a decade was deleted mainly because of me. I came here to improve articles and to add content, not making them vanish. That completely goes opposite with the reasons that I’m here. What they did do affect my editing. I’ve left WP for a few days because of that, but it seems no use. Some of the above happened after I came back. I’ve asked for advice on another editor’s talk page, it seems that I was misunderstood. I was mainly asking for suggestions on the likely animus / uncivil behaviour, not on article’s content. I regret having asked that.. yes, my fault.. it was misunderstood.. and it seems that I’ve put someone in a difficult situation, which is not what I intended ... (As a side note, if we’re talking about content, removing a large amount of content at a time of course is not good. No one knows everything about every subject, and everyone makes mistakes. Removal like that will just increase the risk of mistaken removal, even when done in good-faith, without leaving the chance for correction).
I won’t deny that perhaps some of my edits/comments had irritated that user .. but I don’t think what they did is the way to go. Perhaps they just want to prove that “See? The article has problems that you didn’t notice and I’m correcting them now.”? I hope that can come to an end.. but that kind of behaviour has been lasting for quite some time already, and I’m not that optimistic ….. I choose to speak up here, anyway. What also troubled me is their fluctuating attitude/behaviour. Sometimes they seem to be very civil (mostly to others, but once or twice to me also). But when they are unhappy / don’t like you, it’s just totally different. I’ve been told to “find way” to like them, but it’s just too difficult.. I have tried not to escalate during the discussions (if you are familiar with my edits you’ll know how assertive I can be) but I wonder if that helped. I hope I’ve made it clearer now on why I said “I’ve tried my best already”. It’s not about “discovering the value of others”. Nothing like that. You can’t really like someone if they treat you (and others?) like that, no matter whatever value they have ...
Back to the “How do we welcome new medical editors?” thread at WP:MED talk page.. well, I think that user (one different from the above) has taken some of the advice in that discussion and probably has become more civil (as seen from their comments at least) now. And they have never been uncivil to me, which I really appreciate; despite the fact that I’ve pointed out several times what they shouldn’t have done. I believe that’s an editor with good intention. For that I’ve even given them a barnstar. So, perhaps I should go on and start a new discussion called “How do we work with our newly-joined colleagues?” Do we work with them by ... 3RR … warnings ... following … ?” I don’t think I have the energy (or should spend the time) for that though .. after all, it’s just Wikipedia ..
(N.B. I’m talking to myself and reply is welcome but not absolutely needed.. I’m not providing any diff, because I really don’t want to piss people off… if you know you know, anyway ..) --Dustfreeworld (talk) 18:35, 21 March 2024 (UTC)[reply]
WP:Wikihounding is against policy. You might want to consult someone to see if it fits. Aaron Liu (talk) 18:47, 21 March 2024 (UTC)[reply]
Thank you for sharing this, @Dustfreeworld. I'm really sorry for your bad experience. First and foremost, as Aaron Lui said, you need to report the behavior you describe.
On your message, I agree regarding the attitude. Welcoming users and providing suggestions to their edits is a positive and active way to have more editors joining. Trizek_(WMF) (talk) 17:47, 26 March 2024 (UTC)[reply]
@Trizek (WMF) The biggest blocker with any active welcoming and mentorship plan is that... They all fail thanks to no longevity plans and too much effort required.
I have never seen WP:Welcome Committee in action (but it's hard to, because the idea is decentralised anyway), WP:Teahouse has longevity (because it's low frills for everyone), but Wikipedia:Adopt-a-user pretty much has dried up (It's a lot of effort per mentor), WP:Co-op never really got off the ground (too much effort for everyone), WP:Snuggle is disbanded now (don't think many users used it but I might be wrong), WP:TWA is... I am not even sure if it's alive or not, it's not very easy to see the impact of it there, Growth Team's Mentorship space is currently indecipherable for any veteran editor (I don't even have an enwiki page to link for it), Hostbot is unfortunately inactive (not sure why), WP:Twinkle welcoming templates are still active.
Of all of these, I'd recommend reviving Hostbot and encouraging more Twinkle Templates for your active welcoming purposes. One is a bot, the other is a simple 2-clicks per user who's already installed Twinkle. Essentially the simpler and lower effort your solution is for everyone, the more impact it'll have overall (because it's much more likely to be used 3 years later instead of 3 months).
I could go in more depth, but essentially I'd like to see WMF dedicate more resources to simple easy to maintain ideas that solve one problem each, instead of overarching mega-goals that fail soon after the "patronship" dries out. Soni (talk) 06:42, 1 April 2024 (UTC)[reply]
There was research that showed people liked TWA but it did not improve editor retention. Not sure what your suggestion about Twinkle is; isn't Twinkle-welcome already working? Aaron Liu (talk) 14:45, 1 April 2024 (UTC)[reply]
Yeah I was pointing out Twinkle-welcome as one of the few "active welcoming" things that do already work; so if I were WMF, I'd focus some resources towards "Can we encourage this more". Right now it's mostly used by veterans who already know what Twinkle is/how to use Twinkle/are used to welcoming via Twinkle often enough. I don't have any specific plans already, but I assume anything that boosts any of those three will increase active welcoming. My point of highlighting Twinkle was "Improve something that works" vs "Make a new project that first crosses the longevity barrier".
I do think there's better avenues to explore, roughly in 'more automated and less heavy on maintenance' things. I'd like Hostbot revived, if only because it'll give us a lot of data on impactful retention. Soni (talk) 18:34, 1 April 2024 (UTC)[reply]
Some kind of encouragement to use Twinkle Welcome messages more might indeed help. After using Twinkle for many years, I only recently realized that I should be using the welcome messages more often when dealing with problem edits from (apparently) new editors. I think part of my problem was that I did not realize that besides the purely welcoming messages I often saw on user talk pages, there are also welcome messages that deal with a subset of problem edits that I can use instead of a pure warning message in many cases. Donald Albury 13:09, 2 April 2024 (UTC)[reply]
Most initiatives to help newcomers in a direct way (not through passive messaging) are time consuming, that's true. In my opinion (which is just an opinion), it is also the price of quality welcoming, to create a new generation of wikipedians. At the moment, the lack of time creates a gap on who will join: only users with "survival" skills will succeed, while less assured people will give up.
What I call "Passive messaging" are user talk page messages, often pre-formatted for a given purpose, often with wiki-jargon, looking like being distributed by a machine and very often with no way to contact the sender. Donald just gave good context about them.
Also, I don't know if Twinkle offer ressources to encourage users of they've done good (or partially good) edits.
@Soni, if I set aside using Twinkle, what are the solutions to welcome and sustain a new generation of editors? Trizek_(WMF) (talk) 16:47, 2 April 2024 (UTC)[reply]
user talk page messages, often pre-formatted for a given purpose, often with wiki-jargon, looking like being distributed by a machine and very often with no way to contact the sender. I actually disagree. I get the main point you're making, but in practice, I find Template:Welcome cookie to be strictly better than literally everything (including Special:Homepage). There are a lot of worse templates, agreed, but tweaking to adjust the templates to better serve your purpose (A simple message saying "You can contact me at [my talk page]")
Also, I don't know if Twinkle offer ressources to encourage users of they've done good (or partially good) edits. That's why I mentioned Snuggle from earlier. If you specifically want "Let us encourage editors who made good editors recently" you may be better off partially or completely reusing codebase that should already exist from before. The project had an interface like WP:Huggle and pointed out newer editors with "good" edits that I could then send welcome messages to. It just was a separate interface that editors had to get used to using, so ended up not actually being used much (IIRC).
if I set aside using Twinkle, what are the solutions to welcome and sustain a new generation of editors? Like I tried to mention earlier, I think this problem is best solved by breaking down each subproblem separately. I think reviving Hostbot could be good for "Identify lots of promising editors, send them to pipeline of "editors training others". I think Growth homepage is good for "Every new editor sees this" but it needs severe updates to allow experienced editors to interact or help (Teahouse and a bunch of onwiki resources are still not added, there's no enWiki landing page or talk page, there's no WP project page with simple "Here's example screenshots of how the growth page looks", all of those will allow veterans to point out specific things that can be improved). I think there is room for space to grow "Mentor and retain editors who are promising (100+ good edits)", probably an evolution of WP:Adopt in some way. (I don't offhand know what that could be, other than "You could probably ask WP:WER and WP:EotW folks". Those have done excellent work in retaining promising veterans from burnout, simply by encouragement. So I can totally see something similar working for newcomers).
In essence, I'm recommending "Iterate and improve on every subproblem" as a way. "Will veterans use and maintain this space 2 years later" can be very hit-or-miss, but my best guess for increasing those odds involve asking a few Wikiprojects, then improving the projects they are most excited by/most likely to use. Soni (talk) 17:56, 2 April 2024 (UTC)[reply]
Interesting thoughts, thank you. They will feed into my work on mentoring and how to help communities in this area.
Regarding pre-formatted messages, my definition may not apply to some messages, but the majority of them are actually not that good across wikis. Even the Welcome cookie one could be improved for the benefit of new users. It is a problem in itself. :)
Anyway, to be continued, probably somewhere else. Trizek_(WMF) (talk) 19:01, 3 April 2024 (UTC)[reply]
My favorite welcome template is {{w-graphical}}, which neatly categorizes the links. Aaron Liu (talk) 19:06, 3 April 2024 (UTC)[reply]
Oh I completely agree that things could always be improved, I just think the improved templates are really "solid" and cover a lot of useful ground consistently (even if a bit impersonal). I also like automation because I treat this process as a scaling problem.
We probably have thousands of new editors monthly who make a useful edit, a few hundred who stick around for 10 edits, and probably dozens who I'd call "promising" (>20% odds of editing 1 year later, say). Each group requires a different approach to maximise our "odds", simply because otherwise you'd spend a lot of time personalising messages that might never be ever seen.
The more we can accurately go "Okay we have 20 new editors with 50 unreverted edits made over the last month", the more we can focus vet effort on personally interacting/encouraging/mentoring those. And the "They made 2 edits that weren't flagged as vandalism" folks can be handled by automated/semi-automated systems to get them to "Okay this is what talk pages are, also ask questions on this link" levels Soni (talk) 19:50, 3 April 2024 (UTC)[reply]
@Trizek (WMF) Also if you'll solicit future community input, I recommend WP:Helpdesk, Wikipedia:IRC/wikipedia-en-help regulars as well. Both locations deal with large volumes of newcomers constantly, so the vets there would know exactly the things that would smoothen their mentoring curve. Soni (talk) 19:54, 3 April 2024 (UTC)[reply]
You know that we don't have a common definition of a "useful edit"? The one used is based on reverts: a non-reverted edit after 3 days. We have data about this.
Regarding automated system providing guidance, they could work, but human-to-human interactions are way better to improve retention. We are working on the Wikimedia Foundation's annual plan, and it has a question regarding how we can distinguish ourselves from other platforms. I think the human factor is important there. It doesn't mean that we should not use any form of semi/automated ways of helping users (like we plan to do with Edit check), but we can make a difference on how we encourage new users with a more human -centered approach. Again, it is still a question with no proper answer. Yet!
Oh I completely understand, I'm just making sure to emphasise making it sustainable for human volunteers. The last time I checked the Growth dashboard (6 months ago?) my realisation was that most of the human effort on veterans' end was fairly wasted. You do not want to burn out all your experienced editors trying to reply to everything when it's way more important for the "promising newcomers" (People who have already shown they understand Wikipedia basics AND are sticking around for more than 1-2 days) to get that interaction. I do not believe the latter is happening at all (or enough) right now, so I feel former (Spreading out volunteer attention to everyone) is not helpful enough.
You know that we don't have a common definition of a "useful edit"? I don't know if this is the biggest problem to solve, but I'm fairly confident I've seen something like this before. Snuggle, Huggle, mw:ORES all have some way of judging the quality of edits. I know I've seen this in my Watchlist as well. This is a perfect usecase for this or similar tooling: Decent accuracy but sorts through everything. Soni (talk) 14:33, 4 April 2024 (UTC)[reply]
I've often written about the inefficiencies of Wikipedia's discussion processes, and combined with the realities of most volunteer recruiting, where the vast majority of people stopping by aren't going to commit to staying around, agree that recruiting is costly. (There's a commonly used solution for that, but it's not one that I feel the English Wikipedia community is ready to accept: have paid staff do the welcoming and hand-holding.) That being said, I think that's just something that has to be paid to feed the pipeline for maintaining English Wikipedia at its current scale. While I also agree that having tools to help identify promising newcomers would be helpful to target them for retention, I additionally feel we need to work on ways to get more editors to the point where their promise can be evaluated. As others and I have previously suggested, perhaps there should be recruiting initiatives targeting groups whose interests align well with the idea of volunteering to write encyclopedia articles. This can be on a one-on-one personal level (current editors reaching out to people they know who would be interested) and on a higher level, such as trying to get history buffs involved. isaacl (talk) 15:34, 4 April 2024 (UTC)[reply]
@Soni, well the sustainability of any program that involve humans to help new users feeling welcomed and capable of editing is precisely the challenge.
My realisation was that most of the human effort on veterans' end was fairly wasted -- could you elaborate on this?
Regarding the quality of edits, there are two different cases: ORES can give a prediction of the intent or the level of damage. It is a possibility to guess if the edit is useful, but it is not qualifying as such for sure. Some obvious cases are immediately identified, but the grey area between vandalism and constructive edits is left to humans' appreciation. If we had a proper definition of a useful edit, the prediction models (ORES or its replacement) would work differently.
Regarding assigning a mentor to active users who already shown apetite for Wikipedia by a few edits could be a mistake. Being a mentor myself at my wiki, I often get questions from users who aren't sure if they can change something on a page. Their very first edit is a question to me. If i put aside SPAs, the majority of them are now active users (even if not regularly).
@Isaacl, if you have any link to your writings at hand, I'm curious to read about welcoming new users.
The Growth team worked on a tool to identify promising users, so that their mentor can encourage them. We tested it at a few wikis, but it is not ready at all for a larger release. We also have plans to assign mentors to newcomers who match their interests, but it is not on Growth's scope for now. Trizek_(WMF) (talk) 14:13, 5 April 2024 (UTC)[reply]
I think it's a good idea to try to match mentors to new editors based on common interests, as well as directing new editors towards active groups of editors with matching interests. Unfortunately, many WikiProjects no longer have high levels of engagement on their talk pages, which makes it harder.
could you elaborate on this? We've actually discussed exactly this last year. I noticed that the Growth dashboard was casting too wide a net, so I got 10 mentees who had never made an edit (and never would again). I don't believes any changes were made from there. And the dashboard continues to not be clear on what "level of editors" you'll get questions from. Veterans are a 'non-renewable resource' so I always prefer them fully knowing what they're signing up for and/or being tapped after there's already a "filter" applied on their potential mentees.
Their very first edit is a question to me I guess we disagree. I would like those editors to also get some assistance, but I personally believe it's way more important to first build a sustainable structure at the "higher levels of the pyramid". That is currently missing, so in my opinion, you are giving good human support to a few thousand editors who edit once, but have nothing for few dozens/hundreds who are already super likely to stick around.
I would rather Growth team's efforts be on building the "newbie to experienced editor" mentorship pipeline for all levels of newcomers, than focus all new initiatives trying to redo fancy new ideas but only for the newest editors. The reason I suggested ORES is because it probably isn't perfect but it's definitely "good" as a starting point. The scale at which enWiki operates, I'll rather have an existing tool that's 70% accurate in iding newcomers, than a tool that comes a few months later. I'd rather WMF spent more resources improving current tooling and reviving good projects with promise, than continue churning out newer plans every few months. Soni (talk) 18:14, 5 April 2024 (UTC)[reply]
Workshopping a trial admin process
In WP:Requests for adminship/2024 review/Phase I, I proposed trial adminship but it appeared that the proposal was not quite ready. I want to figure how can we have a trial admin process that is most likely to hold well with the community. There definitely should be a method for there to be trial admins when consensus is unclear or to dispel any doubts about current user conduct. Or maybe trial adminship should be the only result of an RfA. I do not know. AwesomeAasim 18:16, 12 March 2024 (UTC)[reply]
The framework that I think has the best chance would be a kind of limited adminship. I would make a permission, requestable at WP:Perm and grantable/removable by a single admin as appropriate. The permission is designed to counteract vandalism and be used by a new change patroller. The permissions would be:
Block any account that is not autoconfirmed for a short time (37 hours?)
Semi-protect any page for a short time (probably same time frame as blocking)
Delete any recently-created page.
This gives these permission holders the full block/protect/delete triad to avoid the law of the instrument. It also gives them enough ability to break up most common/simple cases without letting them get into a lot of situations where they generate controversy.
The permission would NOT have viewdeleted. This is awkward because they could delete a page and not have any way to revisit it, but it is a WMF requirement for any process that didn't go through a full RfA or similar.
The way the actual restrictions on the perms are enforced could be technical or social. If they have the technical ability to make any block, but there's a brightline policy against it and a bot that reports any discrepancy to AN, I think that's still fine.
I know this isn't exactly what you had in mind from trial adminship (giving the full tools and a period of time to use them before some kind of reconfirmation), but I think it's the best way to practically solve some of these issues. Tazerdadog (talk) 18:40, 12 March 2024 (UTC)[reply]
That feels like a pretty good idea, as making it a perm removes the need for a double RfA, and it can still show experience and trust in light of a future RfA. Chaotıċ Enby (talk · contribs) 19:31, 12 March 2024 (UTC)[reply]
On many Fandom wikis, there is this right called "content moderator". This right gives users the ability to edit fully protected pages (but not interface pages), delete/restore pages, rollback, and protect pages. We can have something similar particularly for those extremely familiar with the deletion policy. AwesomeAasim 03:43, 15 March 2024 (UTC)[reply]
That is indeed a problem, but I don't think it is that big of a problem when other administrators are able to immediately intervene when there is an incident of disruption going on. AwesomeAasim 16:42, 15 March 2024 (UTC)[reply]
That's not the issue. It's not about "they can't block and will have to wait for other admins", it's "they can't block and thus will likely protect instead of blocking, which is often not ideal". Chaotıċ Enby (talk · contribs) 16:44, 15 March 2024 (UTC)[reply]
I am thinking any trial admin process needs to allow users to demonstrate that they know how to act appropriately with the admin tools. Conduct as a non-admin is not necessarily an indicator as to whether they will behave that same way with the admin tools. In fact, people are more likely to be careful when given the tools just because they know the community can easily take the tools away. AwesomeAasim 20:11, 21 March 2024 (UTC)[reply]
I can think of lots of ways to do this. The trail admin might be paired with a full admin who would supervise the, trial admin. More high powered use of the tools might be reported to a notice board, Blocks might be limited to 24 hours to give a full admin time review, assuming a longer block is appropriate. The whole trial admin concept itself might be done a trial, say one year with a pause after to evaluate how it went.--agr (talk) 21:29, 21 March 2024 (UTC)[reply]
What do you have in mind when you say "supervise"? isaacl (talk) 02:02, 22 March 2024 (UTC)[reply]
I like the idea in general. The details would need work. There's nothing that precludes working on this even if it outside the main current review. North8000 (talk) 20:23, 21 March 2024 (UTC)[reply]
Well, re "delete/restore pages"... restoring pages (which perforce would require the right to read them first) is probably the most sensitive right on the project. Sure, for the overwhelming majority of deleted pages, there's nothing sensitive there. But, other pages might contain egregious libel, doxxing of persons, state secrets, instructions for making infernal devices, and so forth, and we really want them to be gone and to stay gone. One single person could cause a deal of mischief by reading these articles and giving them to a third party. (Yes, admins can do this, and some have, but I think we want to keep this ability as tightly controlled as possible.) As for deleting pages, are not enough pages being deleted? Could be quite the opposite. Herostratus (talk) 02:17, 26 March 2024 (UTC)[reply]
But, other pages might contain egregious libel, doxxing of persons, state secrets, instructions for making infernal devices, and so forth, and we really want them to be gone and to stay gone. That is what WP:SUPPRESS is for. AwesomeAasim 19:34, 2 April 2024 (UTC)[reply]
I don't think arbitrarily increasing the workload of a 45-person team that is already swamped with other stuff is a good idea. Aaron Liu (talk) 20:41, 2 April 2024 (UTC)[reply]
Okay, trying a different way to frame the problem:
There is a decently strong consensus that deletion, protection, and blocking are a core trio of permissions which should be packaged together.
The viewdeleted permission is incredibly sensitive for the reasons Herostratus listed above. Restoring a deleted page is also dependent on viewing it. Being able to delete a page but not undelete or review it is incredibly awkward for both admin accountability and mechanical reasons.
Trusting any user enough to give them the viewdeleted permission, along with all the other buttons, without having seen them use protection, blocking, or deletions before is a tall ask and is one of the reasons RFA is struggling.
I'm going to try to attack this from a different angle. Would it be possible from a technical perspective to create an adminbot that would email you the contents of a deleted page if and only if you were the person who most recently deleted it, and you had an appropriate userright, and/or undelete that page for you under the same conditions.
If we can do that, I think unbundling block/unblock, protect/unprotect, and delete/undo own deletion would be viable. Tazerdadog (talk) 19:51, 4 April 2024 (UTC)[reply]
It would require some code but it is not impossible to do. It already is possible to disallow editing of other user pages with a pre-edit hook or something similar (though it is not used on Wikipedia), to throw up the "permission error" message. I don't understand why stuff like copyright violations and etc. are not suppressed more regularly; if a page is G10'd or G12'd it almost definitely qualifies for suppression. Attack pages are defamatory in nature, and copyright violations have legal ramifications. Suppression isn't reversible; it can be reversed as easily as it is done. AwesomeAasim 03:21, 7 April 2024 (UTC)[reply]
ITN reform
I am opening this discussion to invite suggestions and proposals to reform WP:ITN in anticipation of an RfC. Such reforms are long overdue: ITN has effectively shut itself off from the rest of the site as a walled garden and have developed their own system of rules that conflict with sitewide expectations, creating multiple problems:
The inclusion criteria are entirely subjective and based on the personal whims and opinions of participants. Editors at ITN routinely use original research to determine "significance", applying their own analysis of each situation. Weight in reliable sources is not a major factor in whether ITN considers something to be "significant".
ITN flouts community norms around consensus. Discussions are typically closed as head counts, without weighing arguments in regard to the application of policy. "I like it" votes are given equal weight in discussions. The discussions are also closed before consensus has time to develop: no other part of the project would dream of letting a discussion without a clear consensus be closed in under a week, but ITN's nature requires that they be closed in a few days at most. Many discussions are closed after just a few !votes one way or the other.
ITN requires a fast turnaround, sometimes as short as a few hours. In addition to contradicting WP:DEADLINE, this creates rushed work and prevents in depth review. Nominal quality checks are done to make sure citations are present, but the window is short and most participants only evaluate "significance". This results in articles that are not only not ready for the main page, but ones that are unstable as they are oftentimes recently created, subject to early reporting errors, and undergoing significant changes.
Since arguments about personal beliefs and opinions are built into ITN's processes, it is inherently less civil than other parts of the project. Over the years, drama at ITN has rivaled most CTOPs, to the point that applying general sanctions to ITN itself has been discussed in the past.
The arbitrary selection of news stories (with a major systemic bias toward elections, sports, and mass-casualty events) misrepresents the overall state of what's actually in the news. Pushing this bias onto our readers does them a disservice.
These problems are intractable with ITN in its current form. I am asking for suggestions on how it can be reformed, or if that fails and there is consensus to abolish it entirely, how it can be replaced.
Examples of reforms:
Remove the significance requirement entirely and include any article that is the subject of a recent news event.
Require that a story receive significant coverage in a certain number of countries or a certain number of newspapers of record
Promote articles based on trending topics (with oversight to prevent gaming the system)
Examples of replacements:
Use the space to display several short blurbs for good articles each day, like smaller versions of WP:Today's Featured Article
Use the space to provide links on how to edit and to help users find where to start in order to recruit more editors
Move the "Other areas of Wikipedia" section of the main page into the space for easier navigation
These are ideas that have been suggested in the past. This is not an exhaustive list of examples, nor do I personally consider all of them viable. I'm requesting input from the Village Pump so we can develop additional suggestions and get a general idea of what the community thinks about them. Thebiguglyalien (talk) 18:48, 30 March 2024 (UTC)[reply]
Two issues with points raised:
On the fourth point related to arguments: the only time general sanctions have been applied is when the topic itself falls into areas where general sanctions have already been applied (like AP2, etc.) There have not been any sanctions applies for topics outside these areas. So that's just how general sanctions should be applied, and not an ITN issue.
On the fifth point, WP is not a newspaper and we absolutely should not share topics to match what is big in the news. Not every news story that gets a short term burst of coverage deserves a WP article (per NOTNEWS, WP:N and NEVENT) and ITN reflects that.
Remember that the main page as a whole is meant to showcase articles that represent some of the best of WP. Replacing it with a list of top stories in newspapers or with popular topics won't work at all, because not all those topics meet the main page requirement. — Masem (t) 19:17, 30 March 2024 (UTC)[reply]
I would also offer a suggestion that the ITN box include a permalink to the Wikinews sister project, which may be more attractive to those potential editors who get confused or put off in their first reverts that we are WP:NOTNEWS. SamuelRiv (talk) 15:09, 5 April 2024 (UTC)[reply]
I wonder if there's even a consensus that ITN needs to be changed, before we even start talking about the specifics of how to reform it. But I do not see any indication on the above thread that such a consensus exists. If there is, please feel free to share the diff, otherwise I feel like this will just go around in circles again as such discussions always do. Duly signed,⛵ WaltClipper-(talk) 13:13, 8 April 2024 (UTC)[reply]
About to open RfC but need last minute feedback
Wikipedia:Requests for comment/Enforcing ECR for article creators is intended to address the problem of WP:ARBECR where only extended confirmed users are allowed to edit in a specific topic area. I am posting here to get last minute feedback on the format of the RfC before I open it formally. Any suggestions for changes to the format or what? AwesomeAasim 02:36, 1 April 2024 (UTC)[reply]
Would speedy dratification be a valid option? Aaron Liu (talk) 03:14, 1 April 2024 (UTC)[reply]
@Aaron Liu If you think it should be an option please feel free to boldly add it. AwesomeAasim 17:31, 1 April 2024 (UTC)[reply]
Really not sure how to word it.
Option D: Addition of a draftification criteria for articles with enough merit to Wikipedia:Drafts#During new page review, with another specified option taken if it does not have enough merit.
Hi. I've been reviewing redirect and category requests for some time now and I have an idea: Disambiguation requests.
Currently, requesting the creation of a disambiguation page is not easy for new and IP editors, as it can only be requested with the same process as normal articles. Therefore, I would like to discuss the possibility of a new AFC page, AFC/D, which will be used for the requests of disambiguation pages.
The format of such requests can be something like this:
The request can then be reviewed by experienced editors with help from user scripts such as the afcrc-helper, which will make the process much easier and quicker.
Something I've been thinking about for a while is how Wikipedia could provide better attribution for the contributors of its articles. After all, attribution is a key part of our license, but the authorship of an article is very much hidden away out of sight. In order to see the authorship of an article, one first needs to go to the "View history" tab, then click on the "Page statistics" external link, which redirects to an entirely different website, and even then you need to scroll down in the page before seeing authorship details. It also appears to only be visible in the web browser version, while it seems completely absent from the mobile app version. This presents a pretty unintuitive set of hoops for readers to jump through in order to discover (and attribute) the authorship of various articles. Even as a regular contributor, I didn't know this tool existed until a year or so ago.
This means that, to the lay reader or content re-user, all of our articles might as well be written by a monolithic "Wikipedia", or maybe a vague gesture at "Wikipedia contributors". Contrast this with other prominent encyclopedias like Britannica, which display the primary contributors to an article quite prominently beneath the article title and list secondary contributors in an easy-to-find section in the article history.
I was thinking that, either in the main page or at the top of the "View history" tab, it may be worth including such a list of contributors. It could be as simple as listing the primary author (with the most percentage/characters contributed), followed by any secondary contributors (with >10% contributed), followed by an "et al", which could itself link to further information about the article's authorship.
I think this would be a very important fulfilment of our own license's terms of attribution, both for in-wiki use and for anybody that might be reading or thinking about reusing the article's content. It would be a step away from the monolithic conception of "Wikipedia contributors". It could also provide a greater sense of impact for the articles' authors themselves, who would be able to easily see the fruits of their labour on screen. Of course, I understand this may come with its own drawbacks. I know some editors prefer the anonymity, while others may be worried that this could encourage low-effort edits in order to farm credit. But I personally think that the potential benefits of such a credit feature would outweigh the potential costs.
Having looked through the village pump archives, I'm confident this isn't a perennial proposal. I only managed to find one discussion of such a feature, which was opened by @Doc James almost a decade ago, but it didn't seem to gather a clear consensus and I'm not sure if anything ended up resulting from it. If anyone has any comments on this embryonic proposal, I would be happy to hear from you. --Grnrchst (talk) 14:27, 2 April 2024 (UTC)[reply]
@Grnrchst as an example, could you produce what you would expect the output of such to look like for this page? — xaosfluxTalk 14:32, 2 April 2024 (UTC)[reply]
It's an odd example, because this is a discussion page, but it would currently be something like "Written by WhatamIdoing, Xaosflux, et al." --Grnrchst (talk) 14:43, 2 April 2024 (UTC)[reply]
So you'd be fine ignoring the thousands of other authors on such a byline? — xaosfluxTalk 14:58, 2 April 2024 (UTC)[reply]
I don't think it's feasible nor particularly useful to include every single contributor in a byline, but I don't think they should be entirely ignored either, that's why I've included the "et al." (could also say "and others", or something). The reason I set the byline inclusion at >10% is because that's the rule of thumb used by the good articles project to determine major contributions. I think named inclusion in the byline should be limited to such major contributors, but linking to total authorship in the "et al." would also be useful for showing the full scope of contributions. --Grnrchst (talk) 15:05, 2 April 2024 (UTC)[reply]
I don't think there is going to be any good way to programmatically determine those values. In your example above, what calculation did you use to determine that WhatamIdoing and I were >10% contributors for example? This is primarily why the cite this page tool example just says "Wikipedia contributors". (see more below) — xaosfluxTalk 15:17, 2 April 2024 (UTC)[reply]
I was using the "Top editors" section in the Xtools page I linked to in the "et al." As this is a discussion page, rather than a mainspace page, Xtools doesn't show an "Authorship" section in this case (hence why I didn't think it was a good example). Whereas in the one for Morgan Bulkely, there is an authorship section that shows Wehwalt at 79% of authorship, Real4jyy at 6.2% of authorship, etc. The authorship tool on Xtools is apparently powered by WikiWho, which we may be able to use for generating such a byline. --Grnrchst (talk) 15:25, 2 April 2024 (UTC)[reply]
As for the "Cite this page" tool, I think this is an example of how just vaguely citing "Wikipedia contributors" is unhelpful and even redundant. Of course it's authored by Wikipedia contributors, it's a Wikipedia article! --Grnrchst (talk) 15:51, 2 April 2024 (UTC)[reply]
I was thinking this "Written by [...]" could go next to the bit where it says "From Wikipedia, the free encyclopedia". --Grnrchst (talk) 14:51, 2 April 2024 (UTC)[reply]
In the mobile view, we do advertise the "last" author (e.g. see the bottom of this page) - that could possible be ported to desktop. — xaosfluxTalk 15:00, 2 April 2024 (UTC)[reply]
I think the "latest contribution" is a good measure of recent activity, what I'm aiming at with this proposal is trying to demonstrate a broader scope of total activity. --Grnrchst (talk) 15:07, 2 April 2024 (UTC)[reply]
Note, a feature request that may address this idea is open at phab:T120738. — xaosfluxTalk 15:18, 2 April 2024 (UTC)[reply]
I think you'd want to use the WhoColor API (which is what mw:Who Wrote That? uses). The other methods tend to overemphasize people who don't actually write any words. For example, if the article has 50 edits total at the time of calculation, and five of them are me blanking the whole article, or changing the whitespace on a template, then I've made 10% of the edits, but I haven't written a single word on the page.
@Grnrchst, the last time I remember seeing a discussion about highlighting the names of contributors, a jerk who normally edited under his real name created an account with a vulgar username and made one edit, just for the purpose of asking whether we really wanted to have vulgarities displayed in the mainspace. WhatamIdoing (talk) 16:41, 2 April 2024 (UTC)[reply]
I was having the same thoughts. It should be based on who contributed to what the article as currently displayed. It would be wrong for instance to list the top contributor as someone who hasn't edited the article since it was completely rewritten. It might also encourage more competitive editors to try and find ways to boost there standings, without having to do any actually helpful work. -- LCU ActivelyDisinterested«@» °∆t° 15:54, 3 April 2024 (UTC)[reply]
For the reasons mentioned above, I'm not a big fan of crediting whoever ran the link archiver most often as being the "author" of the page. Nor am I fan of being assigned as the author of a page, even if I am indeed the #1 author. The mw:Who Wrote That? extension is excellent and should be promoted, because it allows seeing authorship of words and sentences currently live, which is an excellent (though not infallible) way of tracking down who has added nonsense to an otherwise decent page (caveat lector: sometimes someone who copyedits nonsense will be shown rather than the original nonsense-adder). One thing that may not be widely known is that you can run Who Wrote That? on old versions of pages, making it an arguably more efficient tool than WikiBlame.-- SashiRolls 🌿 · 🍥 18:37, 8 April 2024 (UTC)[reply]
Although XTools is influenced by use of link archiver tools, the underlying WikiWho service provides token-by-token attribution of who added what. This can be used to determine authorship without considering anything between ref tags, as well as other markup that's seen to unfairly influence authorship stats. I have implemented this in SDZeroBot 6 task which makes the bot somewhat smarter about whom to notify about AfDs. – SD0001 (talk) 21:15, 8 April 2024 (UTC)[reply]
I am concerned that this would encourage WP:OWNERSHIP of articles. The entire point of the Wikipedia model is that articles are “authored” by the community, not by individuals. Blueboar (talk) 20:48, 2 April 2024 (UTC)[reply]
This is a completely fair and valid concern. --Grnrchst (talk) 21:54, 2 April 2024 (UTC)[reply]
I don't see the need for this. I do get a certain pleasure from seeing how much of the content in an article I have contributed (which I can see at Page Statistics), but I am well aware that no one else really cares, and the future of such content is out of my hands. I am not editing Wikipedia to build my curriculim vitae. Donald Albury 21:41, 2 April 2024 (UTC)[reply]
Personally I strongly dislike the idea of articles where I have primary authorship saying "written by Levivich, et al." or anything like that. That is very much not the kind of attention I want. Also, xtools authorship is not really reliable. For example, I am listed as the #2 author of Alexandria Ocasio-Cortez[25] but that's only because I once ran the archive bot on that page [26], I am not actually anywhere near a top author of the actual prose on that article. Levivich (talk) 17:15, 3 April 2024 (UTC)[reply]
If you have a divisive article and then add a note that User X was its most prolific contributor, readers will immediately assume User X holds those divisive views. And all the better if User X is an IP and offended readers can immediately find their location. (Which is already possible, of course, but why place it front and center?)
I agree with the concerns voiced by Levivich and others. And even if the authorship statistics were 100% accurate I still don't like the idea of omitting certain users; as sappy as it sounds I think every contribution matters. Potentially, we could do something like Based on the contributions of 328 users but even then I think a more appropriate place for this kind of thing would be the footer alongside the last edited date. ― novov(tc) 08:21, 4 April 2024 (UTC)[reply]
I can totally see the issues with this: we'll never have a 100% reliable measure of authorship, you can't include everyone, and we'll probably see a slight uptick in WP:OWNERSHIP and authorship gaming. But overall, I think it would be a nice way to acknowledge our volunteer editors and to communicate to readers "look, this was written by real people – you can join us". And twenty years into the project, with declining editor numbers, increasing restrictions and expectations of those editors that persevere, and donations to "Wikipedia" siphoned off by an organisation that has increasingly little to do with it, I think we really do need to start prioritising looking after our volunteer base over other concerns. Relying on the ideal of the selfless, perfectly-self motivated contributor, happy to work in complete anonymity, was fine in the early days of the project when the internet was the playground of affluent nerds with utopian ideals; those days are long gone. – Joe (talk) 08:56, 4 April 2024 (UTC)[reply]
I can see how algorithmically a shortened authorship list would be generated automatically, fine-tuned for a relatively accurate representation. And while anything like that could be gamed by users, that's why we have lots of human eyes to review abuse. I can also see how such a list would be useful to researchers and those making citations. However, were such an authorship list to be implemented, I'd suggest it be hidden out of the way a bit, at least certainly from the front page of the article, and perhaps even completely hidden from UI except as metadata.
I'll give some contrasting examples: Scholarpedia places its curator-authors (respected subject-matter experts) prominently at the top of its articles: non-random example is BCM Theory (SP). By contrast, Internet Encyclopedia of Philosophy has its authors' names and affiliation mentioned simply at the bottom, under "Author information" following the bibliography; while Stanford Encyclopedia of Philosophy has its author even more nondescript, being in a footer at the bottom under a copyright notice, and not implied to be an actual "author" until you click on the "Author and citation info" link on the sidebar. (Again, respected subject-matter experts; random ex.: Gender in Chinese Philosophy (IEP), Plato on utopia (SEP).) Wolfram MathWorld also has authorship given relatively subtly at the bottom of the page -- if it's contributed by someone other than the editor, the contribution note precedes the bibliography; otherwise authorship is indicated only in citation information (ex. Chen-Gackstatter Surfaces (MW)).
Given all this, I don't know what example editors here would want to find themselves compared to, especially since an algorithm listing authors would not distinguish one editor writing 95% of an article immediately preceding GA, from one editor writing 55% of the prose in a B-class, for which others had to find new citations (unless we'd want it to do so, but this would epitomize wp:ownership). SamuelRiv (talk) 15:37, 5 April 2024 (UTC)[reply]
It’s really hard to measure the significance of contributions to an article. It’s not just a count of who added the most words, or even of who added the most words that survive into the current version. How should we weigh a user who adds some high word count nonsense to an article, against a user who painstakingly sifts through the garbage, deletes most of it, and copyedits down any remaining kernel of valid content? Or the user who contributes great source analysis to a talk page discussion on a matter which results in a single word changing? Perhaps the article on Antoine de Saint-Exupéry is finished not when there is nothing left to add, but when there is nothing left to take away? Barnards.tar.gz (talk) 18:05, 5 April 2024 (UTC)[reply]
This is an excellent point. We don't have any accurate automated way to assess contribution levels, and xtools authorship isn't it (neither is bytes added or edit count). Levivich (talk) 18:56, 5 April 2024 (UTC)[reply]
Just because an algorithm isn't currently implemented, does not mean an algorithm doesn't exist. As a rough starting point: authorship+curation can be measured by taking the diffs made by an editor to bring text in line with the current stable state, weighted by time. (For the simplest measure, you can just use edit longevity with hysteresis.) Now, absent some new API properties, this is an expensive calculation to maintain for every article, but it's perfectly technically doable. (Another, more sophisticated method is analogous to a co-authorship network.) Of course this has been done before: Arazy et al 2010; Lanio & Tasso 2011 (citing Biuk-Aghai 2006). SamuelRiv (talk) 19:28, 5 April 2024 (UTC)[reply]
No algorithm will be perfect though, and the exact value of things other than clear-cut addition/removal is to some extent subjective. ― novov(tc) 01:57, 7 April 2024 (UTC)[reply]
Fundamentally, I think this is a nice idea and seems like it would be easy to implement since we already track editor contribution metrics, so it would just be a matter of making this visible on the page itself somewhere, maybe in the footer (though, yes, XTools is imperfect and an alternate system would probably be better). That said, I would hope there might be some opt-out system for those of us who don't want any sort of public credit, which includes me. (I never let anyone IRL know what WP articles I've worked on because the layperson assumes that the current status of any given WP article I "created" represents my writing. And, in many cases, I want nothing to do with how an article I "created" has evolved.) Chetsford (talk) 02:07, 7 April 2024 (UTC)[reply]
Much as with the hall of fame suggestion (people really seem to be concerned with credit and recognition, lately), this could go so very badly. Any algorithm that we set up is going to be full of holes. It is simply impossible to represent, with any sort of non-LLM algorithm, the extent to which an edit impacts an article's development and structure for a multitude of reasons. The first reason is the fact that anyone can edit Wikipedia, and edits are happening on a constant, minute-by-minute, second-by-second basis. An article could look one way today and then look totally different the following day, if it gets a massive rewrite. How would one recognize contributions in that scenario? If Editor X wrote the previous version of the article before its replacement, do they lose attribution now that it's been rewritten? Or do they receive attribution for something that no longer resembles their work?
The second reason, for Wikipedia articles, especially larger ones, the whole is greater than the sum of its parts. One can do a massive amount of copy-editing in a large edit, mainly to make stylistic or grammatical corrections, and as a result it would have very little impact on the article's growth but they would be considered an outsized contributor. On the other hand, the addition of a few vital facts or details could contribute heavily to the article's development, ensuring that it's meeting WP:GNG or perhaps even putting it on the road to becoming a WP:GA.
The third reason is that someone will always disagree with the algorithm that determines who is an author. Attitudes on Wikipedia among editors regarding WP:OWNERSHIP are already very fierce. This would exacerbate it to a fever pitch. Or it would simply not be taken seriously, if enough people take umbrage with it. This metric would be divisive at worst, and superfluous at best. If one wanted to track the metrics of the article, the "Statistics" are available for this very reason. They do not attempt to ask the question "who wrote this article?" They simply provide the data. In fact, it's a good rule of thumb - Anytime you ask any sort of question regarding creative or scholarly human impact, the question should always be answered by a human and not by a machine. Duly signed,⛵ WaltClipper-(talk) 13:20, 15 April 2024 (UTC)[reply]
Redirect deletion
Just floating this idea.. MediaWiki now includes a specific permission for deleting redirects with only one revision. The delete-redirect user right could be granted to page movers to allow them to delete pages that had been moved to draftspace by a non-PM and subsequently tagged with CSD R2. I see these pages pop up in the new pages feed from time to time, where the article had been draftified but sometimes the R2 tag lingers for quite awhile. To be clear, this permission only allows deletion of redirects that have only one revision (namely those created as a result of a page move). We could also probably set up an edit filter to further restrict usage of this feature to only permit deletion of the page if the person attempting the deletion is the original author, or if the R2 tag is on the page (I know there was at least an experimental/joke edit filter at one time to prevent deletion of the main page, so the functionality is there). Thoughts? Taking Out The Trash (talk) 01:10, 3 April 2024 (UTC)[reply]
Makes sense. If we trust page movers to move articles without leaving a redirect, we can trust them to help other users do the same. On the other hand, CAT:R2 very rarely has more than a couple of pages in it, so I don't think there's a pressing need for more hands there right now. – Joe (talk) 07:15, 3 April 2024 (UTC)[reply]
This proposal seems useful and reasonable. If R is a one-revision redirect to article A, a page mover could already delete R badly by moving A to R then back to A without leaving a redirect. (Don't try this at home.) Let's give them the tool to delete R well instead of badly. Any redirects we really need to keep should be protected anyway. Certes (talk) 09:09, 3 April 2024 (UTC)[reply]
The challenge this idea creates is setting up a "You can do X, but you can't undo yourself" situation. That isn't necessarily a showstopper, but something to consider. — xaosfluxTalk 14:11, 3 April 2024 (UTC)[reply]
I had thought delete-redirect still only helped during page moves and was currently granted to page movers: Wikipedia:Page mover#delete-redirect. (I've also looked through Wikipedia:Page mover/delete-redirect.) I think expanding it to just delete single revision redirects is maybe unwarranted; maybe with additional limitations as mentioned but I'm not sure the expansion of the right would be added to MediaWiki if it depends on local edit filters? Skynxnex (talk) 14:19, 3 April 2024 (UTC)[reply]
To be clear the permission delete-redirect is already assigned to "page-movers" (in fact that is the only group it is assigned to). — xaosfluxTalk 14:25, 3 April 2024 (UTC)[reply]
Also, as @Skynxnex mentioned above, it only actually applies during a move (a page move can't use Special:Delete directly with this access). — xaosfluxTalk 14:30, 3 April 2024 (UTC)[reply]
(To make sure nothing recently changed, I just validated that workflow with my test accounts as well). — xaosfluxTalk 14:31, 3 April 2024 (UTC)[reply]
Thanks for the clarification. It sounds as if some of what was asked for already exists, and the rest is not possible, so there's nothing to do here. Certes (talk) 14:40, 3 April 2024 (UTC)[reply]
Well, what I was interested in was granting access to Special:Delete only for single revision redirects to page movers, so that they can delete anything tagged for R2. I thought that the delete-redirect permission would allow this, but I could be wrong. Taking Out The Trash (talk) 17:18, 3 April 2024 (UTC)[reply]
It doesn't (verified), this permission was built (phab:T239277) to only be used during moves. — xaosfluxTalk 18:53, 3 April 2024 (UTC)[reply]
Expunged criminal offences
The state of Virginia, where most Wikipedia servers are, permits the expungement of certain less serious criminal records. This is common across the US. Most democratic countries have similar arrangements, for example the UK and Australia allow for many offences to become 'spent'. In the US, it is usually a misdemeanour to report expunged convictions without good reason (acceptable reasons are laid out in the relevant legislation); in the US and other countries like the UK it is a tort (a civil harm, and so actionable in civil court) to report without good reason. Should Wikipedia policy permit the removal of expunged convictions from articles? Charlie Campbell 28 (talk) 06:48, 5 April 2024 (UTC)[reply]
As a general rule our content should be guided by reliable sources rather than the location of the WMF's servers. How do they usually treat expungement? – Joe (talk) 08:03, 5 April 2024 (UTC)[reply]
Thanks, Joe. My question was inspired by coming across an ex-offender's article where all his expunged criminal convictions are listed in detail. So I guess we allow it at present? Charlie Campbell 28 (talk) 11:42, 5 April 2024 (UTC)[reply]
This is interesting, @SamuelRiv, and thank you. I read a good roundup of the US situation which suggested that the media might take this forward in their own way according to local editorial policy. This seems to be a good example. It's why I wondered if Wikipedia might consider doing the same. https://thecrimereport.org/2021/09/10/expungement/Charlie Campbell 28 (talk) 22:40, 5 April 2024 (UTC)[reply]
I'm not sure about other jurisdictions, but here in England records of crimes that attract sentences of more than a couple of years' imprisonment are never spent. Less serious crimes should not be covered at Wikipedia anyway (per WP:BLP). If the location of the servers leaves us open to court action we should consult our legal team. Phil Bridger (talk) 08:20, 5 April 2024 (UTC)[reply]
Thanks, @Phil Bridger. I can't see a reference at WP:BLP which says that spent (less serious in your formulation above) offences should not be covered. Are you sure? Charlie Campbell 28 (talk) 12:18, 5 April 2024 (UTC)[reply]
I also don't think this is quite right. We shouldn't be including trivial events in any article, on due weight grounds, but minor crimes can still receive significant coverage (see, for example, the Paris Hilton article). Barnards.tar.gz (talk) 13:07, 8 April 2024 (UTC)[reply]
On legality, if WMF has any concerns about the possibility of liability for hosting such information, it can take an office action to say so. I'd suggest that you would be hard-pressed to find any example of a speaker like an encyclopedia, newspaper, or blog (rather than a consumer reporting agency, government official, or person in possession of a restricted government record) being held liable in the United States (or in a foreign judgment enforced in the United States consistent with the SPEECH Act) for continuing to report true information about a past criminal proceeding that was published in the news before it was expunged. See United States defamation law (a major theme/adage of which is that truth is an absolute defense to defamation) and Gertz v. Robert Welch, Inc. (requiring at least culpable falsity for defamation on a matter of public concern), to say nothing of Section 230. SilverLocust💬 09:21, 5 April 2024 (UTC)[reply]
Thanks, @SilverLocust. I looked up the law in some states and in Europe. In US states like Virginia and Michegan, reporting an expunged conviction without justification is a misdemeanour, but you are right to say that it is far harder to secure a successful defamation action on that basis in the US than in Europe. There is a good brief here https://www.rcfp.org/disclosure-expunged-records-does-not-invade-privacy/. The media organisations discussed there won their case because they could show good reason. In the UK, it is simply a breach of tort law to report any spent offence without good reason. In mainland EU, the rules are even tougher. One question which might arise, then, is whether Wikipedia should observe the law in other jurisdictions (like UK and EU) or just US? Charlie Campbell 28 (talk) 12:00, 5 April 2024 (UTC)[reply]
If the crime was minor, and the only material available to verify it are things like court records, WP:BLPCRIME already says it shouldn't be in the article. Of course if there was substantial coverage about it in independent sources, then it might merit inclusion. As to the claim In the US, it is usually a misdemeanour to report expunged convictions without good reason—[citation needed] on that one; I would very much have expected to see a First Amendment challenge to that, and I would expect it to win. Laws muzzling the general public from disseminating truthful information almost never pass constitutional muster. UK law may say that, but well, we're not in the UK (though that may be a concern for individual editors who are, but it's on them to comply with law in their jurisdiction, and that doesn't affect anyone else). SeraphimbladeTalk to me 11:48, 5 April 2024 (UTC)[reply]
Thanks @Seraphimblade. Replies here don't appear to permit in-line citations so I was reluctant to simply cut and paste as that seemed to be against the purpose of the functionality. I'm not a lawyer and so I'm reluctant to cite the law (one of my own reference points was Virginia law) but was rather giving what I feel is an accurate pen-picture. I completely agree that it would be very hard, if possible at all, so win a defamation case in the US. It would, by the looks of it, be straightforward in Europe. The fact remains, however, that the legislation has a purpose, however difficult or feasible it might be to enforce. I think Wikipedia should have a clear policy on it. Charlie Campbell 28 (talk) 12:12, 5 April 2024 (UTC)[reply]
There is no problem using in-line citations. Just add {{Reflist-talk}} after your post to keep the full citation associated with your post. Donald Albury 13:01, 5 April 2024 (UTC)[reply]
Reporting of criminal records in the media is an interesting read from the perspective of UK law, particularly this bit: Once a conviction is online, and so in the public domain, the media can quote it in their outlets since they are not ‘revealing’ anything new, just stating a known fact. Nobody’s data is being invaded if past news sources are quoted and privacy rights are not being compromised. This seems to be true even in the case of ‘spent’ convictions. If the conviction is on record, it is likely that in certain situations the media are able to justify the ability to publish these details even though it is spent. This does seem to be speculative on their part rather than constituting legal advice.
Since Wikipedia is based on sources, perhaps Wikipedia should follow the sources, meaning that if action has been taken to "unpublish" a source on privacy grounds, then we could consider removing any material that relies on that source. We would weigh such unpublishment as evidence of a privacy interest. Conversely, while the source remains online, we would not take any action. Barnards.tar.gz (talk) 13:58, 8 April 2024 (UTC)[reply]
I have read all the very useful posts here and follow through wherever I can. I should say that my original thoughts were about Wikipedia policy rather than liability. My takeaway so far is as follows: US and EU law does allow for expunged convictions but it is highly unlikely that any case for defamation would succeed in the US. A similar type of case in the EU might be successful against the individual editor if resident there, however that editor would need to be identified and Wikipedia would be unlikely to yield to requests for such disclosure from outside the US. It does not seem that liability is a pressing question which could drive any kind of policy change.
However, a policy change can be driven by things other than legal liability. It also seems true, though, that US wikipedia editors in particular (but perhaps many elsewhere) would likely defend the stronger US freedom of expression over an emphasis in the EU towards a right to be forgotten. This all seems to rule out any policy of the automatic removal of expunged criminal records, regardless of jurisdiction.
It seems possible (likely?) that most editors recognise the sensitivity around different democracies' differing public policy and prefer to avoid conveying the impression that the US-based nature of Wikipedia is used to ride roughshod over every other part of the world. Might other, already extant, policies have relevance upon the way expunged convictions are reported in Wikipedia articles (e.g. proportion as per WP:NPOV?). Or is any kind of revision required? I come back to the example which prompted my post here, where an article largely comprises a list of an individual's spent convictions. Charlie Campbell 28 (talk) 13:18, 5 April 2024 (UTC)[reply]
That policy is WP:WEIGHT. Also, in the specific case that prompted this query, the subject of the article is a high-profile individual, a former British MP. In other cases, WP:BLP1E could apply and we could choose to not cover the person at all. Also because in this specific case the subject is a former MP, it seems extraordinarily unlikely that any attempts to suppress discussion of his criminal history would be successful in court. VQuakr (talk) 00:18, 6 April 2024 (UTC)[reply]
MPs are NPOL, no? I don't think minor criminal history would, in general, be sufficiently covered to be DUE in any BLP articles, though obviously specific cases may vary. Alpha3031 (t • c) 07:04, 6 April 2024 (UTC)[reply]
Thanks, @Alpha3031. I've looked that up. I think my example was a bad one. The problem with that article is not that it mentions offences (I don't think very well known people can expect the same treatment as much less known people) but that it's so imbalanced. I think this one in England is probably a better example. The guy has a Wikipedia page because he was known in the 90s. I don't see why his DUIs should be mentioned so long after he ceased to be famous. Charlie Campbell 28 (talk) 13:44, 6 April 2024 (UTC)[reply]
Agree that misdemeanor offenses years after a BLP person's window of notability (proposed WP term?) are entirely wp:undue. I'd also suggest that in the case of backbench MPs, briefly famous actors, temporary celebs, that wp:oneevent notability guidelines apply, namely: Editors are advised to be aware of issues of weight and to avoid the creation of unnecessary pseudo-biographies, especially of living people. This should probably be cross-quoted in the BLP P&G. I think it gives suitable grounds to remove the misdemeanors in the John Alford article you link. (The felony and tangential trial in the first two paragraphs are probably justifiable, both by the weight of events, and that they are interlinked with other independently notable events/people.) SamuelRiv (talk) 18:20, 6 April 2024 (UTC)[reply]
Thanks, @VQuakr. Yes. I now think the problem with that article, particularly the main body, is that there's so much NOT there. It looks like all the guy ever did was get convicted of stuff. I have a better example of the thing I'm talking about here, though. My Dad reminded me of this guy he knows a bit. He was in a TV soap for a year or two in the 90s and got caught taking drugs. He lost his job and hasn't worked in the media since. He was once well enough known to have a Wikipedia article, but now he's 50 and just a regular guy. He finds it hard to get even casual jobs. He got a DUI years ago and it's on his Wikipedia page. That doesn't seem at all right to me. Charlie Campbell 28 (talk) 13:38, 6 April 2024 (UTC)[reply]
Wikipedia Hall of Fame?
What are your thoughts? Is it going to work? Comment down below. WolverineXI(talk to me) 17:28, 8 April 2024 (UTC)[reply]
I'll bite. What do I get? Like, a room with a comfy chair? The one caution I would have about this is that there are some editors whose positive contributions to the encyclopedia would unquestionably earn them a spot, but who are presently indef-banned for other reasons. BD2412T 17:37, 8 April 2024 (UTC)[reply]
"The one caution I would have about this is that there are some editors whose positive contributions to the encyclopedia would unquestionably earn them a spot, but who are presently indef-banned for other reasons." That's a good point. Though, IMO, I don't think HOF should be behavior-exclusionary and should be open to anyone who has made an enduring impact on WP, regardless of how they made the impact. For instance, I say induct Jordan French (maybe not in the inaugural cohort, but eventually). Chetsford (talk) 18:47, 8 April 2024 (UTC)[reply]
French certainly made an impact but then so did many LTA vandals. If this idea is adopted, it seems appropriate to limit membership to those who have shown altruism rather than encouraging those who make Wikipedia worse for personal gain. Certes (talk) 08:24, 9 April 2024 (UTC)[reply]
Yeah, that's a good point, Certes. I think this was intended more as an exaggeration for emphasis that we not be rules-bound for a HOF, but probably not a good example to underscore that! Anyway, I agree with your suggestion. Chetsford (talk) 15:26, 9 April 2024 (UTC)[reply]
Similar to Internet Hall of Fame, to be serious, there would need to be a reliable advisory board. They can help surface little known but important people from the early founder days. It could be a popular vote nomination process, like the Nobel, but picking the winners would need a small august body, known for deep institutional knowledge and experience. After a few rounds/years of winners, those winners then become members of the advisory board. Overall this is probably something that should be organized by WMF. Or you can just do it, but it will be another "This one is special. This one is also special" award. -- GreenC 18:32, 8 April 2024 (UTC)[reply]
I like it. While we may have a superfluidity of awards, these cost essentially nothing to produce so I'm not sure I ever understand the resistance. All recognition systems are voluntary and those who don't approve can opt-out. Moreover, a HoF -- if managed through some approximation of the way GreenC describes -- would be different from existing accolades which are either interpersonal recognition (editor to editor) or metric-based recognition (e.g. Four Award, etc.). Chetsford (talk) 18:41, 8 April 2024 (UTC)[reply]
Of course they "cost nothing to produce", that's not the problem, the problem is that they give one more excuse to divide Wikipedians between "the ones who have power" (i.e. the unblockables) and the plebs like us. Chaotıċ Enby (talk · contribs) 13:36, 10 April 2024 (UTC)[reply]
It might be a good idea. 3.14 (talk) 19:07, 8 April 2024 (UTC)[reply]
The key questions for any initiative is what is the objective, and how helpful is the initiative in achieving this objective? For recognition programs, it's important to also consider how the selection process will work, and whether or not it will create more difficulties than benefits gained. Recognition programs are tricky because the flip side of selecting some is that many others are not selected, and that can result in conflict. isaacl (talk) 02:36, 9 April 2024 (UTC)[reply]
That's how recognition programs work, but I don't think they'll necessarily cause any conflict. WolverineXI(talk to me) 04:09, 9 April 2024 (UTC)[reply]
"it's important to also consider how the selection process will work" After the inaugural cohort is selected, maybe it should become self-perpetuating with all prior inductees selecting each subsequent cohort. (Though you'd still need some system to choose the inaugural cohort.) This would mitigate politicization and degradation as inducted members would have a vested interest in maintaining its reputational coherence. Chetsford (talk) 05:37, 9 April 2024 (UTC)[reply]
That would be difficult if they are dead or so long retired from WP they don't give a toss about the place anymore/are out of touch about who is still active and "deserves" a shout. - SchroCat (talk) 07:44, 10 April 2024 (UTC)[reply]
"would be difficult if they are dead" I imagine it would. Chetsford (talk) 08:48, 10 April 2024 (UTC)[reply]
I would object to exclusion of the deceased. There are some amazing editors who left us too soon, but with great work done first. BD2412T 02:37, 11 April 2024 (UTC)[reply]
We don't mean a blanket exclusion, just that we will ensure that batches of cohorts keep on coming; this line of discussion was about a proposal to have each cohort select the next. Aaron Liu (talk) 02:59, 11 April 2024 (UTC)[reply]
I don't think we'll select a cohort that are all dead or inactive, for the reasons you've mentioned. Aaron Liu (talk) 11:34, 10 April 2024 (UTC)[reply]
I think it best if you don't have any intake at all: voting for one's friends make this an inbred and insular process. As I've said before (as has Chaotic Enby), this is a bad idea - divisive and with the potential for conflict when the "wrong" people are elected and the "right" people over looked. - SchroCat (talk) 12:02, 10 April 2024 (UTC)[reply]
The English Wikipedia Hall of Fame idea sounds peachy keen, as Babe Ruth would say before tying his hands behind his back and hitting a home run with his neck (Ruth is, all kidding aside, the most underrated ballplayer in baseball history). The initial "class" obviously would include J and L, the pioneering heroes of our story, and I can think of several others who would be obvious. That first class probably shouldn't be large, maybe 7 or 8 inductees. Then the rules get tricky, but doable. In a perfect world we'd lock J and L in a room until they get to a place where they can come up with a plan of how to handle this that everyone says "Of course that's how it should be done". But, bottom line, I think an EWHoF is a good idea all around (without WMF involvement). Randy Kryn (talk) 03:22, 10 April 2024 (UTC)[reply]
A second rate popularity contest with ill-defined criteria? What could possibly go wrong. Terrible and divisive idea. You think someone's great - give 'em a barnstar, or, even better, leave them a thank you note, but to 'promote' people who will undoubtedly be divisive to others? That way grief and conflict lies. And this ignores the fact that "hall of fame" is not a worldwide concept that people everywhere readily grasp or buy into.- SchroCat (talk) 07:44, 10 April 2024 (UTC)[reply]
Schro, the procedure is akin to the Wikimedian of the Year, except that it exclusively concentrates on the English Wikipedia. There's a purpose for these initiatives, and I firmly disagree that this is a "bad idea." WolverineXI(talk to me) 13:25, 10 April 2024 (UTC)[reply]
You are, of course, entitled to disagree. For what it's worth, I think the Wikimedian of the Year is a fairly crap award too, being a process with no criteria and something else that divides, rather than unites. Most people are happy to do the work for the sake of the work, not to seek vacuously external praise or validation just because they've caught the eye of someone powerful or happen to be pushing a zeitgeist line of thinking. - SchroCat (talk) 14:44, 10 April 2024 (UTC)[reply]
As you haven't yet stated the purpose behind your suggestion, nor proposed a process, there isn't enough info to understand the potential benefits and costs. There's an understandable view that costs quickly outweigh benefits as any process involves more people, adding up to more total effort expended. isaacl (talk) 16:53, 10 April 2024 (UTC)[reply]
More awards? At this rate, all our time will be spent giving ourselves pats on the back and giving each other shiny things. While I don't agree with the more extreme anti-award views (take wiktionary for example; wikt:Template:User barnstar has been nominated for deletion twice, and been described as cheesy and gaudy. I don't think we need all that Wikipedia's tinsel to encourage people.), we shouldn't go overboard with this. Cremastra (talk) 22:07, 10 April 2024 (UTC)[reply]
It's okay if you choose not to participate in the process. WolverineXI(talk to me) 04:55, 11 April 2024 (UTC)[reply]
How would one choose not to participate? I would not participate, but saying so would make it look as if I thought I stood a chance of being elected, which I do not. I imagine that most of those who would choose not to participate think the same way. Phil Bridger (talk) 20:07, 11 April 2024 (UTC)[reply]
I don't much like anything on Wikipedia which encourages elitism, political campaigns, cliques, inequality, etc. I can imagine that many wiki-politicians would waste a lot of time campaigning to be elected to a HOF and that the results would be divisive. "How come so-and-so got elected, and I didn't?" Smallchief (talk) 21:44, 12 April 2024 (UTC)[reply]
I think this sort of thing is better left to other sites. Maybe the people who hang out at Wikipediocracy would create a Wikipedia Hall of Fame? Or would it become a Wikipedia Hall of Infamy? Phil Bridger (talk) 08:09, 13 April 2024 (UTC)[reply]
I especially don't like the idea of putting infamous characters in a HOF. Follow baseball standards. Pete Rose and Shoeless Joe Jackson are not in the baseball HOF because of scandal, despite being qualified. No bad actors, no matter how famous, in a HOF. Smallchief (talk) 09:04, 13 April 2024 (UTC)[reply]
Indeed. Baseball is a sport where defeating others on the field is encouraged. Wikipedia is a cooperative endeavour where it's frowned on. Certes (talk) 09:48, 14 April 2024 (UTC)[reply]
Yes, this program is designed for honoring purposes rather than competition. I hope that's clear to all. WolverineXI(talk to me) 04:41, 16 April 2024 (UTC)[reply]
In that case, it seems the honor should not be of the Wikipedian itself, but of the work that they accomplished in a given area. That's why the Barnstars exist, of course. Just as WP:NPA encourages us to comment on the content and not on the creator, so too should we be aware to not place individual people on a pedestal.
Frankly I find it disappointing that, in bringing forth the idea, the OP has not brought forth any comprehensive or detailed arguments in support of this idea and in response to the above critique. We are simply discussing a nebulous concept of recognition, which I think Wikipedia already addresses, and which if people really needed to see more of, they could use other websites or mediums for this purpose. Duly signed,⛵ WaltClipper-(talk) 12:29, 16 April 2024 (UTC)[reply]
Several editors on the Wikimedia Discord server have come together to organize a new contest focusing on improving content from parts of the world that don't get enough attention. We aim to make this a three-month event running from July through September. Ixtal and Sawyer-mcdonell have volunteered as coordinators, and they're looking for a third! The organizers are also seeking feedback from the wider community, particularly from editors with experience running wiki-events. Please leave comments, questions, and suggestions below, or sign up here. Thanks! —TechnoSquirrel69 (sigh) 05:27, 9 April 2024 (UTC)[reply]
Timestamp on video references
If a web reference leads to a more than hour-long video, but the citation in question involves a 10-second clip, I believe that could be made more accessible to a reader. I see this being something like an optional field on the web citation, but I’m really not very sure. Aaronlearns (talk) 01:47, 11 April 2024 (UTC)[reply]
Conversations with the Trustees - next call this Thursday 21st!
Hi all. I just wanted to give you a heads-up, in case you didn’t already know, that there are regular ‘Conversation with the Trustees’ events that you are welcome to attend and ask questions to the Wikimedia Foundation Board of Trustees (who oversee and guide the Foundation). I’m hosting the next one, taking place this Thursday 21st March at 19h UTC and, speaking as a long-time enwiki editor, it would be really nice to see people from here attending and engaging in the discussions. Please see m:Wikimedia Foundation Community Affairs Committee/2024-03-21 Conversation with Trustees for details! Thanks. Mike Peel (talk) 21:51, 18 March 2024 (UTC)[reply]
This is good to know about, Mike; thanks for sharing! Sdkbtalk 18:31, 19 March 2024 (UTC)[reply]
Proposal: WMF should hire a full-time developer to do basic maintenance on MediaWiki
I've been disappointed with the state of disrepair of MediaWiki for years, but yesterday I've become aware of an issue that finally drove me to complain: there was a basic SVG rendering bug that has been fixed upstream 4 years ago, but it still torments Wikipedia readers because WMF can't be bothered to install the fixed version T97233. WMF also refuses to switch to a less buggy SVG rendering library T40010 or to let the browsers do the rendering themselves T5593. Other users there expressed skepticism that SVGs would ever work here and we should revert to PNGs instead, as such issues have existed for more than a decade without being addressed.
This lack of basic maintenance is not limited to SVGs. There is also the well-known issue that graphs are "temporarily" disabled, which was triggered by MediaWiki using the Vega 2 library for 6 years after its end-of-life, until this time bomb exploded in their face. It looks like the current "solution" is just disable graphs forever T334940.
Another issue is that MediaWiki still runs on Debian Buster, the Debian stable from two releases ago. Fun fact, it will be end-of-lifed in three months, so we'll have one of the biggest websites in the world running on unsupported software. And these are only the problems I have personally encountered. Other editors tell of many more that I won't list here.
One might think that this situation is due to a lack of funds, but this is not the case. WMF has so much money that it doesn't know what to do with it: Signpost May 2023, Signpost August 2023. That's why I'm launching this proposal to tell it: hire a full-time developer to do at least basic maintenance. It's unconscionable to donate millions of dollars to other charities while your own website is falling apart.
It would be in fact perfectly natural natural for such a wealthy foundation administering such a large website to fix bugs themselves, or even take over development of the libraries it depends upon. I'm not demanding that much. Only to keep the software stack remotely up to date. Right now it's downright archaeological. Our billions of readers are suffering through issues that the rest of the world has long solved. Tercer (talk) 15:56, 23 March 2024 (UTC)[reply]
As I understand it, the WMF has hundreds of staff and these include developers. Github has 558 names of such. So, my impression is that there's no lack of staff or other resources. Presumably it's more matter of organisation and fit. I'm guessing that there's a lot of legacy code and technical debt and maybe this is too brittle and rotten to maintain easily. The graph debacle indicates that senior management ought to be getting a grip on this before a more catastrophic gap opens up. Andrew🐉(talk) 17:58, 23 March 2024 (UTC)[reply]
Obviously WMF has some developers. Certainly not hundreds, let alone 558. In any case none of them is dedicated to maintenance, otherwise Wikipedia's servers wouldn't be in a worse state than my grandmother's PC. I assume they are working on sexy new features such as the visual editor, the reply function, or the dark mode. Maintenance is boring, and doesn't look impressive in your CV. Nobody wants to do it. That's why I'm proposing a full-time maintainer.
Your alternative theory that they have enough resources but still can't do maintenance can be summarized as rank incompetence, and that's too cynical for my taste. It's also not actionable. What could one propose? "Proposal: WMF should get its shit together"? Tercer (talk) 19:09, 23 March 2024 (UTC)[reply]
The WMF does appear to have hundreds of developers and engineers. For example, see Developers/Maintainers which has a specific column documenting maintenance responsibilities. Some of these are the responsibility of entire teams such as Wikimedia Site Reliability Engineering which has a headcount of about 45. There are still clearly gaps in this structure, as shown by the year-long outage of graphs, for example. But the idea that there's nobody currently responsible for maintenance in a general sense seems too simplistic. The problem seems more that there's a complex structure in which it's easy for issues to fall down cracks or for people to pass the buck. Andrew🐉(talk) 21:21, 23 March 2024 (UTC)[reply]
I took a look at the gigantic list in Developers/Maintainers; the first two names there are volunteers, not staff, so we can easily discount that as indicating that WMF has hundreds of devs. All the ones I clicked in Wikimedia Site Reliability Engineering, however, are actually staff, so we can take 45 as a lower bound for the number of devs. Fair enough, some of them are responsible for maintenance, but it's clearly not enough. The WMF can easily afford to hire another, and it should urgently do so. Tercer (talk) 23:07, 23 March 2024 (UTC)[reply]
I find these threads tiresome. By background, I'm a real software engineer for real money in real life. I do some software development on enwiki-related projects as a volunteer. The pay sucks (but it's no worse than I get paid for editing) but at least I get to pick and choose what I work on, when I want to work on it, and how I want to architect it.
I've found my interactions with the WMF development staff similar to my interactions with any dev group I've ever worked with. Some are good, some not so good. There's a few who are absolute joys to work with. There's a few who are grumps. But then again, you could cross out "WMF developer" and write in (with crayon if you like) "enwiki editor" and you would still have a true statement.
The basic architecture is 25-ish years old. There's a lot of legacy crud. The fact that the core system is written in PHP just boggles my mind. Recruiting must be a challenge. How do you attract top-shelf talent when what you're offering is an opportunity to work on a legacy code base written in PHP and salaries which I can only assume are not competitive with what the Googles and Facebooks and Apples of the tech world are offering. And yes, you are right, doing maintenance work is not what people want to do. If you told somebody, "Your job is to ONLY work on maintaining the old stuff and you'll never get a chance to work on anything that's new and shiny and exciting", I can't imagine you'd get many applications. RoySmith(talk) 23:54, 23 March 2024 (UTC)[reply]
And the slow code review process discourages the volunteers who are affected by longstanding bugs from working on fixing them. And of course a company with a known-bad workplace culture. I think there are people, myself included, who would be willing to work on only fixing bugs rather than building new things in principle, but probably a lot of those people (again including myself) have internally vilified the WMF for exactly this reason so would consider it to morally repugnant to work for them. * Pppery *it has begun... 00:32, 24 March 2024 (UTC)[reply]
I am one of those people. The experience described in that link is totally unacceptable and would lead to prosecution in many jurisdictions. I am ashamed to be associated with its perpetrators. Certes (talk) 01:41, 24 March 2024 (UTC)[reply]
That's why WMF has to pay them. You'll never get boring infrastructure work done by volunteers. And no, I don't believe you'd have any difficulty finding applicants if you offer a decent salary. Even for working with PHP (it's no COBOL, everybody knows PHP). WMF can afford to pay even a top salary from a tiny fraction of the money it has been setting on fire. Tercer (talk) 10:26, 24 March 2024 (UTC)[reply]
Yes, that sounds much more likely to succeed than giving the interesting work to the paid staff and hoping some mug will volunteer to do the grind for free. One option is make dedicated maintenance a role rather than a person, and to allocate it to a different member of staff each month. (Other time periods are available.) That way no one has to do it for long enough to drive them to resignation, and it's a chance to cycle the skill set with e.g. graph maintenance being done when a graph expert is on duty. Certes (talk) 11:44, 24 March 2024 (UTC)[reply]
Small bug fixes can be spread out amongst developers. But truly addressing significant technical debt means cleaning up the software framework to be more sustainable. That's not something that can be done effectively by rotating the work. isaacl (talk) 20:49, 25 March 2024 (UTC)[reply]
To add a bit to what Roy Smith described about software development: there are failures in managing it throughout the industry, particularly dealing with legacy code bases and a existing user population that generally wants all of their interactions to remain exactly the same. When the software has an associated revenue stream, there's a profit incentive to drive deadlines to be met, but when there isn't, the motivation is to get something that works implemented, as cheaply as possible. That tends to accumulate technical debt that has to be resolved later. One more developer isn't going to have much effect on these problems, which need significant resources working in concert to address. Better project management and setting of priorities is needed, to adequately plan how to transform the code base to a more sustainable state. Note there's a good possibility that would result in a decision to shed functionality currently in use that's too costly or insecure to keep in place, with a plan to re-implement some parts deemed necessary. isaacl (talk) 01:57, 24 March 2024 (UTC)[reply]
That's mitigated slightly by the lack of one negative force: MediaWiki has no need to make change for change's sake, just to make Product 2024 look sufficiently different from Product 2021 that users will feel obliged to upgrade. Certes (talk) 11:48, 24 March 2024 (UTC)[reply]
I'm a software engineer myself. More specifically I'm an SRE, so I'm typically responsible for the types of tasks you're talking about (server upgrades, etc). Let me give you my perspective:
For most software engineers, the work they do at their job is completely outside of their control. They do what makes their boss happy, and in turn, they do what makes their boss happy, and so on. Thankless work like regular maintenance is often dropped without the proper incentives. For some people, those incentives are the salary to work long hours, but since many American jobs in big tech pay 2x to 5x the salary WMF pays for the same role, That isn't it. Those incentives have to come from the top. An example of what that might look like is a "backlog drive" that employees are required to participate in. But that's pretty rare, because leadership is typically being evaluated on metrics like increasing revenue or visitors to the site, and technical debt doesn't push those metrics. So, asking WMF to hire more people doesn't address the problem. Those new employees, if hired, would just fall into the established system that caused the technical debt to exist in the first place. So the conversation you need to be having is: "How do we convince WMF to invest in technical debt?" I don't know the answer to that question. But focusing on hiring more people doesn't solve anything. Mokadoshi (talk) 03:31, 25 March 2024 (UTC)[reply]
That's why the proposal is to hire a dev specifically to work on maintenance. Tercer (talk) 06:51, 25 March 2024 (UTC)[reply]
The problem is bigger than just one person working on small bug fixes. The framework needs to be cleaned up to be more sustainable. The third-party software dependencies need to be reconciled across different extensions. This needs co-ordination across multiple development areas, and a lot of automated testing. It needs support from management to push through, rather than to just spend enough to keep the parts working. isaacl (talk) 20:49, 25 March 2024 (UTC)[reply]
Been there, done that. Assigning all mainteinance work to a single engineer (or a small group of them) is a really bad idea in practice. It just obfuscates the need to have better mainteinance practices across the whole engineering organization. It isolates "mainteinance folk" from the new developments that they'll eventually move to mainteinance. It leads burns out, and then to a new "mainteinance guy" coming who starts from scratch and cannot tap into institutional knowledge about mainteinance. It is just unsustainable practice. MarioGom (talk) 10:19, 6 April 2024 (UTC)[reply]
Yes, investing in technical debt is exactly what's needed, but one reason (or excuse) for not doing that is lack of people. If I gag the cynic in me shouting that any new staff would just be diverted to exciting but unnecessary new chrome, an increase in resource should make it easier to get through the required drudgery. Certes (talk) 09:14, 25 March 2024 (UTC)[reply]
The key point is why hasn't the WMF already hired that one more developer, or ten, or fifty? Because it places a higher priority on spending those funds and management resources in other areas. For the development environment to truly improve, the WMF needs to change how it sets its priorities. Echoing what Mokadoshi said, that's the problem that needs to be worked on. isaacl (talk) 20:58, 25 March 2024 (UTC)[reply]
Do you have a source that the Wikipedia web servers run on Debian Buster? I thought they ran on Kubernetes? Mokadoshi (talk) 19:03, 25 March 2024 (UTC)[reply]
A message just came around on the cloud-announce mailing list saying that all the VPS hosts running Buster need to be upgraded in the next few months. I don't have any insight into what they're running on the production web servers, but I assume if they're migrating the VPS fleet, they're doing the same for production. RoySmith(talk) 19:14, 25 March 2024 (UTC)[reply]
Thanks for that link, I'm not in that mailing list so I didn't know. I don't know how WMF runs prod so it very well may be that they are running Buster. But it's important to note that the announcement is for Cloud-VPS which is VPS hosting for the community. It would be common practice to not upgrade Cloud-VPS until the last possible minute so as to minimize disruption for the community. AWS for example does not forcibly upgrade your OS until the last possible day. Mokadoshi (talk) 19:51, 25 March 2024 (UTC)[reply]
I wouldn't spend too much time and effort focusing on the Debian Buster thing. That doesn't affect end users in any way that I can see, and it is not end of life'd yet. Let's trust WMF software engineers and SREs to handle those details, and focus on things that directly affect end users. –Novem Linguae (talk) 21:05, 25 March 2024 (UTC)[reply]
Where it adds to the technical debt that has to be managed is the work to figure out the third-party software stack required by the extensions used for a given Wikimedia site. I agree that it's not a level of detail that editors should be worried about figuring out, but getting the code base improved so that it's easier to work out is important for long-term sustainability of the software. isaacl (talk) 21:24, 25 March 2024 (UTC)[reply]
It's in the discussion of the SVG bug I linked, where they say they will only install the bugfix when it comes with Bullseye, and link to the task for upgrading from Buster to Bullseye. Tercer (talk) 23:33, 25 March 2024 (UTC)[reply]
I really don't want to speak for the WMF, but I kind of understand their logic here. One way to manage a fleet of machines is to stick with LTS releases and survive on whatever gets packaged into that. It's certainly possible to built custom installs, but once you start doing that, you're off the LTS train and have to take on a lot more responsibility and overhead. I've lived in both worlds. If you haven't, it's difficult to fully understand just how attractive sticking to the LTS can be. RoySmith(talk) 00:10, 26 March 2024 (UTC)[reply]
I suspect WMF SRE would be fine with a newer version of the package, provided that there was a compelling reason (more than just small bug fixes) and a different person/team took full responsibility for what that entailed. Like if WMF multimedia team (staffed in this hypothetical future differently) basically said that this is a critical issue, we need the new version, and we are willing to take responsibility for all that entailed, it would probably happen. But that is not the situation happening here. Bawolff (talk) 15:28, 30 March 2024 (UTC)[reply]
This certainly does illustrate the odd relationship that the community has with WMF. In a commercial software shop, there would be meetings between engineering and product managements. The product folks would say, "If this bug isn't fixed, it's going to cost us $X next quarter in lost revenue as customers jump ship". The engineering folks would say, "The only way we can fix this is if we go off the LTS train and that's going to cost us $Y in additional engineering costs, plus some indeterminate $Z in technical risk exposure". The two sides would argue and come to some decision, but at least both points of view would be heard and weighed.
But that relationship doesn't exist here. The customer base is the volunteer community. It's difficult to put a price tag on their labor, and even if you could, they don't have a seat at the table when it comes to making these decisions. Yeah, there's meta:Community Tech and meta:Community Wishlist Survey, but that's not quite the same thing as having the VP of sales in your face about fixing whatever bug is pissing off his biggest customer and threatening his bonus this quarter :-) RoySmith(talk) 17:48, 30 March 2024 (UTC)[reply]
I think there is also a problem here in that the community lacks sufficient knowledge into how WMF does things to make effective criticism, and without effective criticism its impossible to hold WMF to account. Take this thread. The proposal is for WMF to hire a single developer to work on maintenance of MediaWiki despite the fact that there is already a lot more than one developer currently working on MediaWiki maintenance and none of the issues mentioned actually are MW maintenance issues. As a proposal it is pretty non-sensical - it is hard to even tell if these are issues the community cares a lot about or just an issue that a few people care about. The community might lack a seat at the table, which is a problem, but the community is also pretty bad at expressing what is important to it in a way you can actually do something with. Bawolff (talk) 18:17, 30 March 2024 (UTC)[reply]
You're missing the forest for the trees. I could have phrased the proposal instead as "invest more resources in maintenance" without changing anything else, and your criticism wouldn't apply. Moreover, you're missing the point about "jumping off the LTS train". There is no need to update this package in isolation. If MW had been updated to Bookworm last year, or even Bullseye three years ago, they would have gotten for free the SVG bugfix. No matter which way you look at it, maintenance is lacking. Tercer (talk) 19:16, 30 March 2024 (UTC)[reply]
Sure, but would it have been worth it? I also have a long list of things i would like to see fixed. The issue is everyone has a different list. I don't think there is any reason to think that hiring 10 more, or even 100 more devs would neccesarily fix the specific issues you are concerned about. Not all problems can be fixed by just hiring more people. (P.s. my criticism of, well technically this isn't a mediawiki issue, isn't neccesarily directed at you - there is no reason you should know where the boundries between different components lie. I think it is more emblematic of the meta problem where the community lacks the ability to really tell what WMF is doing and hence lacks the ability to really judge it which undermines the community's ability to be taken seriously when lobbying for changes) Bawolff (talk) 21:21, 30 March 2024 (UTC)[reply]
Actually, we do have good visibility into what they're doing. The big picture of how they handle OS upgrades is on on Wikitech. And if you're willing to invest some effort looking around on phab, you can find all the details. For example, T355020 talks about upgrading the hosts that Thumbor runs on. RoySmith(talk) 22:06, 30 March 2024 (UTC)[reply]
That's funny, it turns out SRE is violating their own policy by hanging on to Buster for so long. Well, I'm glad they agree with me. Tercer (talk) 22:16, 30 March 2024 (UTC)[reply]
Yes, it would. Updating Debian is a no-brainer. Very likely it would take care of a large fraction of your list automatically. And it's something you have to do anyway, so there's no benefit from running archaeological versions. Keep in mind that we're talking about Debian stable here, so even the newest version is already old and battle-tested. Tercer (talk) 22:09, 30 March 2024 (UTC)[reply]
From what I am aware of, there is a decent number of employed devs as well as volunteers, so if anything, this is a coordination problem (economical and social) more than anything else. I do have to agree on the point that despite the number of people, some important things don't seem to get done - some of it is primarily because dealing with legacy code is hard, and because hiring quality is hard (this is not to imply at all that current devs are bad) but more exactly that hiring the best devs to work on legacy code is particularly challenging (atleast without paying through the nose). The best way to resolve this is to use the donation war chest and work harder on technical evangelism + hiring on quality over quantity. --qedk (t愛c) 22:54, 25 March 2024 (UTC)[reply]
Perhaps WMF can fund the volunteer developers to do basic maintenance, just like the Rapid Fund and the Wikimedia Technology Fund (which is unfortunately permanently on hold)? Thanks. SCP-2000 14:53, 27 March 2024 (UTC)[reply]
Hi all - I'm Mark Bergsma, VP of Site Reliability Engineering & Security at WMF. Thanks for this discussion and the points already raised. I'd like to help clarify a few things: at WMF we do indeed have a few hundred developers/engineers - spread over many teams in the Product & Technology department, which is roughly half of the organization. "Maintenance" is not exclusively done by a few dedicated staff, but is the shared responsibility of most of those teams and staff, for the components they're responsible for. They actually spend a large amount of their time on that, and for some teams it's the vast majority of their work. We do consider that a priority and explicitly make time & space for it (we call it "essential work"), and we aim to carefully balance it with strategic work (like bringing new functionality to users/contributors), as well as needed investments into our platform and infrastructure (e.g. our multi-year project to migrate all our services to modern Kubernetes platforms for easier development/testing/maintenance/developer workflows). Since last year, we've also made MediaWiki and related platform work an explicit priority (WE3), including the establishment of some much needed MediaWiki-focused teams again, and have an explicit annual goal to increase the number of staff and volunteer developers working on MediaWiki, WE3.2), and the new formation of our MediaWiki platform strategy. This will continue going forward (WE5 and WE6 of our draft next-year plan).Nonetheless, it's true that we have a big challenge sustaining the large and ever growing footprint of services, features and code we've developed and deployed over the now long history of our projects, at the large scale we're operating at. Compared to that footprint, and considering the very wide range of technologies involved, old and new, different code bases and needed knowledge and skill sets, a few hundred staff to sustain and develop that is not all that much. It involves difficult choices and tradeoffs everywhere - prioritizing between many tasks and projects, all of which seem important. It's something we care about, have done quite a bit of process improvement work on over the past 1.5 year, and have a lot more left to do on. We're planning several related initiatives (e.g. WE5.1, all KRs of PES*) as part of our next annual plan to further improve this. We're also going to communicate more about this sort of work, which has been less publicly visible before.But, for something more concrete right now: I've also looked into the situation of the specific issue with SVGs that you raised. That's indeed a problem with an old librsvg library version that is used by Thumbor, our thumbnailing service, which was extensively worked on last year to migrate it to our Kubernetes platform - also for easier/quicker maintenance like discussed here. Further work (including the Thumbor container OS image upgrade and some required Thumbor development for that) then unfortunately got delayed, as the development team then responsible for it needed to be disbanded and reorganized at the time - also to allow us to form the aforementioned MediaWiki focused teams. But, I'm now happy to report that the plan is for the work on the Thumbor upgrade to Debian Bullseye to start soon, in the next few weeks, which when finished should finally address this frustrating issue as well. (And yes, we do normally upgrade before OS releases go out-of-support :)
Thanks for taking the time for such a detailed answer (it seems that Andrew Davidson had a much better grasp of the situation, and I stand corrected). I'm glad to hear that you are aware of the issues, care about them, and there are plans for improvement. In particular, I'm glad that there is a MediaWiki team again and that WE5.1 is an explicit goal. If the state of MediaWiki in fact improves (at least in the issues I'm aware of) I'll resume donating.
It's clear that the answer to my specific proposal is (a quite diplomatic) "no", but I don't mind. I care about the results, and I'm not going to pretend to know better than you how to achieve them. Tercer (talk) 18:44, 27 March 2024 (UTC)[reply]
Regarding the broken Graph extension, I have written an overview in the new Signpost that hopefully sheds some light on the situation for those who haven't followed it closely over the past year: Wikipedia:Wikipedia Signpost/2024-03-29/Technology report.
Speaking personally and generally (i.e. not necessarily about the Graph situation in particular), I think people should keep their minds open to the possibility that several things can be true at once: 1) WMF does a lot more maintenance (and other technical) work than some community members give it credit for, 2) many technical issues are trickier to solve that it might appear without detailed knowledge about the situation, but also 3) WMF often has serious problems with assigning resources proportional to impact and 4) there can also sometimes be situations where engineers overcomplicate a problem and let the perfect become the enemy of the good, or lack the expertise to find the most efficient solution. Regards, HaeB (talk) 02:49, 30 March 2024 (UTC)[reply]
Thank you @HaeB for your even-handed review of the Graph extension situation, and articulating some real challenges that we all face, contributors and WMF staff. Something that I remind myself daily is that most people are trying very hard to get decisions they think will have a lasting impact right, and it's true that sometimes that can lead to letting 'perfect become the enemy of good.'
I wanted to share a little of my perspective on the maintenance challenge: I've joked that this is my third 20+ year old codebase. Over those years, security, uptime and performance expectations have changed dramatically along with the Internet. We all expect software to be more safe, available and faster than ever before. Wikipedias have the privilege of serving a large user base of readers and editors, who are diverse in their geography, expectations and needs (to name just a few ways!). And often, those who work on the software are trying to keep as much functionality as possible as we modify things, so that as little as possible breaks even as the world changes around us. An imperfect analogy to what's happened might be retrofitting a series of buildings and changing their core purpose from some industry to housing. It's possible to change the purpose of a building without changing any of the internal structure, but over time, that becomes increasingly hard to live with. And now you have tenants, so you can't just send everyone away for a year to upgrade it all!
We have multiple significant maintenance projects underway. One place to hear about a part of this work is in the monthly MediaWiki Insights reports, which describe MediaWiki project progress and plans. Each language wiki and sister project wiki is a separate deployment that also supports a distinct set of extensions, some of which were created and deployed many years ago, under pretty different circumstances than we face today. Following the insights reports may help those interested learn more about what it takes to untangle years of uncoordinated decision making for our most critical software, and what it will require for us to establish a platform that is supportable on a free and open internet by dedicated staff and volunteers, and still enable an open and distributed model for all contributions.
Having volunteers who understand our challenges and then help us think through how to get things right together is super helpful. Thanks again and please keep sharing your thoughts. SDeckelmann-WMF (talk) 19:42, 1 April 2024 (UTC)[reply]
Preannouncement of upcoming Movement Charter conversations
I am Kaarel, support staff of the Movement Charter Drafting Committee, working with the Wikimedia Foundation.
I am writing here to let you know in advance that the full draft of the Movement Charter will be published on April 2nd, 2024. This will kick off the community engagement period from April 2nd to April 22nd. Perspectives from the English Wikipedia community would be very valuable for the conversations.
For context, the Movement Charter is a proposed document to define roles and responsibilities for all the members and entities of the Wikimedia Movement, including to lay out a new Global Council for movement governance.
Everyone in the Wikimedia Movement is invited to share feedback on the full version of the Charter draft – this is the last chance to propose improvements before the Charter draft is updated for the ratification vote in June 2024.
Since the last feedback round the drafts have gone through notable changes. I hope many of you will still find it worthwhile to review the drafts and share your perspectives to inform the final version of the text that will be ratified.
On behalf of the Movement Charter Drafting Committee, --KVaidla (WMF) (talk) 07:38, 26 March 2024 (UTC)[reply]
Please remember, when attempting to tie-in and enforce any specific rulings or wording of the document, that this project is Wikipedia (specifically English Wikipedia) and not Wikimedia or an entity called "Wikimedia movement", and its editors are called Wikipedians and not Wikimedians (although some Wikipedians may also want to self-identify as Wikimedians). Thanks. Randy Kryn (talk) 12:27, 27 March 2024 (UTC)[reply]
Thank you for this feedback! I would like to understand better the point you are making. The Wikimedia Movement Charter is a high level document defining the future roles and responsibilities of those comprising it. As defined here, on English Wikipedia, "The Wikimedia movement is the global community of contributors to the Wikimedia projects, including Wikipedia." The article further elaborates that "the Wikimedia community includes a number of communities devoted to single wikis", followed by a list, including Wikipedia communities.
In my perspective, this means that following the definitions also in respective article on English Wikipedia, as curated by English Wikipedia community, Wikipedians are part of particular Wikipedia community, who in turn are part of the global Wikimedia community. It does not seem reasonable in a Charter-like high level document to mention all the projects separately, so the term Wikimedia is used. At the same time, I do hear your point about the choice of the term might feel "alienating" (my interpretation, please correct or specify, if not correct) for the contributors of particular projects. What is your positive proposal for terminology considering this?
Thank you for your very kind attention given to the matter! --KVaidla (WMF) (talk) 15:46, 28 March 2024 (UTC)[reply]
Hello KVaidla (WMF). The point is quite simple. Wikipedians are people who have edited Wikipedia, the flagship project that WMF was organized to fund and protect. Wikipedians can individually choose to identify as Wikipedians, Wikimedians, or both (irregardless of the language you quote above, remember that Wikipedia cannot be used as a source) and are different groups of people when they identify or identifying them. WMF's funding is primarily based on donations that people think they are donating to Wikipedia when, in fact, Wikipedians have very little to do with deciding where and how much such funding is allotted. Wikipedians, a dictionary term, even used to have an annual award named for them. Wikimedian of the Yearl was named 'Wikipedian of the Year' from 2011 to 2016, when an obvious opportunity not taken arose to create the second award while keeping the first intact.Since Wikipedians are a stand-alone grouping, they may choose to belong or not belong to what you call the 'Wikimedia movement'. But any rulings or direction which dictates WMF (or "Wikimedia movement") policy onto them, without regard to the separation of the two, should not stand as doctrine or overriding policy but simply as suggestion. Funding of Wikipedia projects, conventions (our Wikimedia conventions, both worldwide and local such as the North American convention, should rival other major corporate and professional conventions in terms of facilities, banquets, sponsorship, etc., with a much greater extension of WMF funding, upwards of 500 scholarships to each, etc. as a major opportunity to celebrate the volunteers), and new ideas should be taken for granted in WMF's yearly budget, with WMF asking "Thank you, what more can we do?". In any case, the elephant in the room is that Wikipedia is the popularly known entity which "brings in" the donations for the movement and WMF operations, and instead of erasing the term 'Wikipedian' (as was done with the annual award) that separation, as well as the partnership and much fuller funding, should be further recognized and encouraged. Thanks for your reply above, and for your work supporting the projects. Randy Kryn (talk) 15:37, 30 March 2024 (UTC)[reply]
I am proud to be a Wikipedia editor. I don't really know or care about this "Wikimedia movement" which some marketing genius seems to have plucked out of thin air recently. I associate the term "movement" with promoting some cause or other, whereas I try hard to do the opposite by editing neutrally. If membership of this "Wikimedia movement" is optional, then I opt out. If it's a mandatory condition of remaining a Wikipedia editor, just let me know, and I'll move on and leave you to write your own encyclopedia. Certes (talk) 22:31, 1 April 2024 (UTC)[reply]
The “membership” like it pleases you to frame it is optional but certain policies are not. For camper, you may not personally attack other users or perform undisclosed paid editing. Ymblanter (talk) 11:40, 2 April 2024 (UTC)[reply]
I haven't done either of those and don't intend to, but I consider myself answerable to the community and not the WMF. I'll continue to behave in a way I feel is reasonable, the WMF (unfortunately) can decide which of us it allows to edit, and I trust the community to react appropriately to any poor or unexplained decisions as we have occasionally had to do in the past. Certes (talk) 11:59, 2 April 2024 (UTC)[reply]
Thank you, Randy Kryn, for taking the time to elaborate your point more. clearly. I believe I understand the perspective better and it has sparked further conversation, which can be helpful.
As to separation between Wikipedia communities and Wikimedia movement, I believe that project autonomy and agency of project contributors in policy-making continue to be important aspects of how we function. At the same time, there are already global policies, like the Terms of Use in place, that basically legally enable the functionality of all the projects. The Wikimedia Movement Charter drafting work is based on a hypothesis that there are matters that can be defined universally, so we do not need to revisit these matters project by project. Also it is about having the rights and responsibilities of different stakeholders set in writing for clarity. It would be interesting to hear your further thoughts and insights in relation to what has been suggested in the Movement Charter draft (which is now been published). Thank you again for your time and sharing of your perspective! --KVaidla (WMF) (talk) 12:58, 4 April 2024 (UTC)[reply]
Thanks KVaidla (WMF). I think my statement above presents my personal concerns, mainly about full funding of Wikipedia/Wikimedia volunteer projects and the worldwide and regional conferences (where 257 scholarships are given, for example, expanding that to 700, or 800, and assuring that the conferences rival the best corporate or non-profit conferences in keeping with Wikipedia's reputation and, importantly, to thank some of the volunteers who provide both the work product and the incentive for donors) could easily become a key priority of WMF funding. I've been saying that the world's billionaires will, at some point donate up to a billion dollars to Wikipedia and Wikimedia associated projects (Wikipedia's perceived yearly worth per the EMO - the Elon Musk Offer). For both then and now it would be nice to assure that the volunteers fully participate, including widescale funding-decision participation, in everything that dedicated knowledge-sharers can think up and accomplish. Randy Kryn (talk) 14:46, 5 April 2024 (UTC)[reply]
The movement
The phrase "Wikimedia movement" is not a recent invention, though it has received more attention in the past couple years. We individual Wikians of course are free to call ourselves proudly as we will but I think the failure a few years ago to rename the outlying and ancillary sites to "Wikipedia [something]" was unfortunate as it would have helped in public recognition. It would help in recruiting; almost all my students have been attracted to our teaching sessions in hopes of writing a new article when really, it would usually be easier for them to learn how to add a new picture. For my own editing, for a decade or more I have been putting about as much effort into Wikimedia Commons and Wikidata as into English Wikipedia. Those sites do a few things but mainly they supply pictures and data (geographical coordinates are one of my specialties) to the hundreds of Wikipedias including English. Even without a common name, I figure there ought to be a common policy structure and general set of guidelines for us all, so the WMF staff don't have to decide so many things for us. Naturally there will be an interest in adding matters that are mainly the concern of only the encyclopedias or of only few of the various other autonomous member sites, who each ought to handle such things by their already established methods. There will be disagreements on such questions, but I'm confident our usual methods of drawing a consensus will prevail. Jim.henderson (talk) 00:16, 4 April 2024 (UTC)[reply]
In short: I'm curious whether you're saying you believe that a difference of one letter (in some cases) constitutes a real detriment to the development of Wikipedia's sister sites? "Wiki" is already very widely associated with Wikipedia by the public, does "Wikipedia Data" being a thing people hear about and are surprised it exists seem much more unlikely than with "Wikidata"?
I really disagree that even in effect Commons's main function is to act as Wikipedia's image repository. Its use is ubiquitous.
I figure there ought to be a common policy structure and general set of guidelines for us all, so the WMF staff don't have to decide so many things for us.
I don't really think this structure makes sense. WMF doesn't really make that many choices for us—or at least, I feel part of the process for just about every choice I would like input on. I'm not sure what exactly you would like centralized, the current model seems to work. Do you have specific areas of policy or administration in mind?
I think it's important to remember that there isn't a "we", strictly speaking. Not all of us are here to be part of a movement or whatever, or even editing for the same reasons; some just want to fxi a tyop that bugged them, others to add information about their favourite volcano. Jo-Jo Eumerus (talk) 07:18, 4 April 2024 (UTC)[reply]
I have a great respect for sister projects. I refer to Wiktionary regularly, and I use Commons unconsciously most times I read a Wikipedia article with images, though I've contributed very little to either. I use Wikidata occasionally, and was briefly an enthusiastic contributor; I would use it much more if it had an intuitive user interface. None of this makes me part of a "Wikimedia movement", which I see largely as a political stance shared by some but not all editors. Certes (talk) 09:08, 4 April 2024 (UTC)[reply]
The fact that you think the other projects are nothing more than ancillary sites that should be rebranded as under the Wikipedia umbrella is a very, very bad sign. Cremastra (talk) 22:04, 5 April 2024 (UTC)[reply]
I completely understand that Wikipedia editors have a very Wikipedia-centric view of the broader Wikimedia community. It would be nice if everyone had the interest to learn more about the other projects, and how they are used, but I understand that it's not a priority for most Wikipedians, regardless of which language Wikipedia they choose to edit. But I'll just throw in a few tidbits:
For many mainstream media sources that use images, Wikimedia Commons is often a go-to resource. There isn't a day that I don't find a Wikimedia Commons credit on the series of mainstream media sources I look at.
Wikidata is used widely as a data aggregator by many other not-for-profit resources.
Some language editions of Wikisource are the largest repositories of open-source historic documents and literature in those languages
Some language editions of Wiktionary are having a major impact in preserving dying languages
The 339 Wikipedias, with their collective 62+ million articles, are indeed the major drivers of the Wikimedia family of projects; the largest Wikipedias, especially the English one, have deservedly gained a reputation for accuracy and neutrality in providing the entire world with information. That doesn't mean that the "sister projects" don't make a valuable contribution to the sum of all human knowledge. I will never fault anyone for choosing to focus on one specific Wikimedia project, or even one small aspect of a specific project. We're all better for those contributions. Risker (talk) 08:39, 4 April 2024 (UTC)[reply]
Fearful of being caught beating a dead horse, I'll speak once more and hope to be disciplined enough to hold my peace. Yes, one little letter can indeed make a difference. Besides the local Wikimedia Chapter I am a member of local clubs concentrating on bicycling and astronomy. I'm always nattering to them about how we make Wikipedia and sometimes they actually listen. A couple times, though they did not surrender to my efforts to get them to edit an article or two, they decided that a money contribution would be a good thing. "Eh? The form said 'Wikimedia Foundation'. Is that the same thing, or did someone else sneak in with some kind of Internet scam?" These people had me to make the explanation, unlike most outsiders.
A common brand can't help us thousands of insiders to understand what we're doing; like other big busy communities we are too complex to be understood with just a few simple labels. However, that's not what brands are for. Brand names are to promote instant understanding among the mass of outsiders, in this case their understanding that this is a big complex of websites with a common theme. We have different detailed policies to handle our specialties, but we are all about Wikipedia's original aim of promoting universal knowledge by organizing it for accessibility.
I have uploaded thousands of pictures to Wikimedia Commons, and I know of a dozen that are used in news publications, books, and other works. Probably hundreds more are so used; we don't require to be given notice. The usual credit, when given, is "From Wikipedia" or "From Wikimedia Commons" or "by Jim.henderson via Wikimedia Commons". I figure, out of the small minority of their readers who actually wonder where the pictures came from, "From Wikipedia" is the only one that isn't mysterious. Yes, knowledge professionals, most often, know what they are doing but they hope their product will be read by many more people than are composing it; same as we do. They don't expect their readers to learn what it takes to be a knowledge professional.
Wikidata is indeed used by many knowledge professionals. I am most familiar with the work of librarians since I work with them often, and have a lunch appointment tomorrow with a relative who's in that line of work. They are familiar with the different workings of OCLC, Worldcat, LoC and various local or specialized catalogs, and many of them also use Wikidata to help find their way through and among the others. Haha, a couple years ago I looked at the Wikidata item about me, and it showed my LoC Authority Control Number. What, has my good work come to such high prominence? No, that was another Jim Henderson, so I corrected it. Wikidata is full of dirty data like that, some of it imported from massive outside databases a century old or more. Not a big problem since WD serves people in the database business who are aware. I have also worked with art museum archivists and have no idea whether their old catalogs have as many errors as the databases for community gardens in Brooklyn or defunct restaurants in The Bronx. Hmm, perhaps I have wandered but anyway yes, the question of what brand name Wikidata ought to use is a lot less important than for Wikiprojects that serve a wider direct audience.
Oh-oh, it seems this paragraph on WD has revealed that I've already gone overboard. So, I'll drop my stick and carefully back away from the dead horse. Jim.henderson (talk) 01:13, 5 April 2024 (UTC)[reply]
The full Movement Charter draft awaits your review on Meta
Hello again! I am following up on the pre-announcement from the previous week 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!
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:07, 4 April 2024 (UTC)[reply]
Unified enwiki response to the charter
In votes like these a significant issue is that interested editors do not have the time or wherewithal to properly assess the issues or candidates presented and so abstain from the vote. I propose that we attempt to address this, by having more engaged editors consider the proposal carefully and, in consultation with the community though an RfC, issue a recommendation either to support or oppose the change. Specifically, I propose a three-stage process:
A pre-RfC discussion where we will write a neutral summary of the proposal.
An RfC where we will:
!Vote to approve the summary and its dissemination
!Vote whether we should encourage eligable enwiki editors to vote for or against the change
Assuming the summary is approved, a mass message to all eligable enwiki editors providing it. Further, assuming there is a consensus either for or against the change, a recommendation to the editors that they vote in line with that consensus.
Stage one should probably begin soon, in time for a RfC in May; first, however, I wanted a brief discussion of the general idea. BilledMammal (talk) 02:41, 7 April 2024 (UTC)[reply]
Thanks for your comment, BilledMammal. This isn't a bad idea, but it is worth noting that the draft charter will be revised in early May following this current feedback round. Although the MCDC (of which I am a a member) does not anticipate making really large changes, I think it would be reasonable to assume that the final version is going to have at least some differences from the current draft. Would it make sense to create a feedback page on this project as a place where interested enwiki editors could flesh out their opinions before the final revision is made? I'd hate to see people investing a lot of time reviewing a draft and proposing a project-wide opinion in an RFC-type format, based on a document that we know will change. There is something to be said for having a local page for comments and suggestions for improvement (and please yes, if someone thinks X is a bad idea, propose an alternative) as long as there's a link to it on the Meta page so that the MCDC will be well-informed of the discussion on this project. (For that matter, it may be a good idea for other projects, and I'm pretty sure some of them are thinking about this too.) Risker (talk) 03:17, 7 April 2024 (UTC)[reply]
That's a good point, but we also need to consider that it will take time for the RfC to run. I think we should start drafting the summary based on the current document, and then make any updates that are necessary to align it with the May changes and start the RfC a few days after it is released.
I would also agree that creating a local page where editors can make comments and suggestions for improvements would be useful, although I would suggest just using this page as it isn't as busy as the other village pumps and thus an extensive discussion of the proposed charter won't disrupt other discussions. BilledMammal (talk) 04:59, 7 April 2024 (UTC)[reply]
I think mass messaging every eligible voter WP:ACE style might be too many people. Perhaps a watchlist notice, or pinging rfc participants, would be a good compromise. –Novem Linguae (talk) 16:30, 7 April 2024 (UTC)[reply]
I don't think that the vote to ratify this charter is less important than the vote to elect the Arbitration Committee. BilledMammal (talk) 16:32, 7 April 2024 (UTC)[reply]
Thank you for this initiative, BilledMammal, to approach the Movement Charter conversations in a constructive way! For reference, the timeline for the steps can be found here on meta and you are right, the time is of essence. It has been already pointed out on the meta discussion page that the review of the Charter would benefit from additional contextual materials for informed decision-making. As a supporting staff member to the MCDC I will see what I can do, yet it might take some time. If there are priority areas for further context in the English Wikipedia community, please let me know, so I can focus my work around that and hopefully have respective content available earlier. Also let us know, if we can support the discussions around the Charter in other ways. Looking forward to hearing the perspectives and seeing good participation from en.wp community! --KVaidla (WMF) (talk) 12:47, 9 April 2024 (UTC)[reply]
Miscellaneous
Spoken Wikipedia and COI
Hypothetical question: if I got, say, Tom Clancy to do a WP:SPOKEN Wikipedia version of the article on Clear and Present Danger, Jack Ryan (character), or the Tom Clancy article for that matter, would that constitute a COI? He wouldn't be modifying the text or inserting commentary -- just reading the article. Would anyone see an issue with that? (For the record, no I do not personally know the ghost of Tom Clancy). — Rhododendritestalk \\ 03:26, 1 April 2024 (UTC)[reply]
The only scenario in which I could see a serious issue is if there is disagreement about which version of a given Wikipedia article should become the spoken Wikipedia version. I could imagine some disputes when one part of the article is narrated quickly, as if it get past it as fast as possible, when another isn't. But beyond these two specific situations I wouldn't think that there would be COI issues. Jo-Jo Eumerus (talk) 07:48, 1 April 2024 (UTC)[reply]
This is kind of an interesting question. It's not clear to me what status these spoken article have. Are they part of the encyclopedia? If so, then I would expect them to comply with all the enwiki rules about COI and such. bit my hunch is that's not the case.
On the other hand, under our CC-BY-SA-4.0 license, anybody is totally free to create a derivative work (i.e. a spoken article recording) and upload it to commons or wherever they wanted. They would have to comply with all the CC-BY-SA requirements, but enwiki policies like WP:COI aren't included in that, so they would be free to edit out whatever parts they don't like. RoySmith(talk) 00:18, 2 April 2024 (UTC)[reply]
I was pondering this recently also. I thought it may be redemptive to adapt certain quality articles into distinct, possibly shorter, possibly less strictly encyclopedic podcasts, basically. I still think it's worthwhile to explore the ways Spoken Wikipedia can be value added for readers or listeners in 2024, when most people who need one to read have access to a screen reader that can be dialed to their specifications. Remsense诉 17:58, 7 April 2024 (UTC)[reply]
We'd want Commons uploaders to declare COI -- and align to other WP P&G like V and RS -- should their content be included in WP articles. This is rarely the case. For images, this is something we can and should enforce, but for something like spoken articles, it may not be practical to be too picky about what gets offered for lack of volume. Having that initial spoken upload is kinda what gets the ball rolling for others to improve on it if it's insufficient. (And COI editors are sometimes among the few actually motivated to do that kind of thing.) Once there's a few to choose from, it may then be more appropriate to audit the editor on something like COI.
That said, on Commons I usually get quick responses by just messaging uploaders when I've had questions on things like verifiability, sourcing, etc., especially if they're active on a WP as well. So if you suspect an editor or uploader of undeclared COI, the first step is just to politely ask them. SamuelRiv (talk) 00:39, 2 April 2024 (UTC)[reply]
To clarify my original question, while I have some interest in getting unique voices (think comedians, voice actors, etc.) to record articles about which they'd have a COI, I'd be the one soliciting/vetting/uploading/adding it to the article. How nice would it be to have e.g. Tom Kenny do a spoken version of Spongebob Squarepants, or Jerry Seinfeld to read the article on Seinfeld? Last year a couple people who work for a foundation asked me for ideas to push attention towards Wikipedia's coverage of a certain topic rather than to some TikTok influencer. I suggested using the celebrity cache they had to read articles on the topic. So -- and these aren't the real examples -- something like George Clooney reading the animal welfare article. No COI involved. Now, obviously if they wanted to add anything beyond the content of the article it would have to be edited and uploaded as a separate file, but that could be a fun side project (have Seinfeld criticize how we write about the show, for example). Anyway, none of this is actually happening at the moment. Trying to think about other potential pitfalls before I consider whether to spend time on it. I see there's a good piece in the most recent WP:SIGNPOST from MPinchuk_(WMF). Wonder what they think about this sort of "personality-driven knowledge". — Rhododendritestalk \\ 12:16, 3 April 2024 (UTC)[reply]
Oh, this is a neat idea! I'm also curious what the community sentiment would be about the appropriateness of this kind of content on English Wikipedia. Note that the Basque Wikipedia community is exploring the "personality-driven knowledge" space through a tangentially related project called Ikusgela, in which they get well-known Basque personalities to narrate educational video explainers based on Wikipedia content and add these videos to Commons and articles on Basque Wikipedia, e.g. the video at the top of this article: Inflazio. Maryana Pinchuk (WMF) (talk) 21:00, 3 April 2024 (UTC)[reply]
Hello @MPinchuk (WMF)! I have been pinged about this conversation and I would like to precise that these videos are not done by "personalities" but hired actors. Is to say, the idea is to "build" a youtuber, not to use famous people to narrate those. Also, the video script is created, and is not a narration of the exact content of the article itself.
What @Rhododendrites is proposin is very interesting, and it is more related to this other projects: WikiProject Idazlezainak, where librarians recorded writers reading the lead section of their article and also an excerpt of one of their works (they chose youth literature). You can see all the audios here: c:Category:Audio_files_uploaded_in_Idazlezainak.
The other related project I see is this one made by Catalan Wikipedians, recording voice actors and some of the characters they had dubbed. All the files are here. And you can hear to ca:Son Goku or Vito Corleone's catalan voiceⓘ.
I think that those projects are more related to the proposal. Theklan (talk) 18:21, 4 April 2024 (UTC)[reply]
This is interesting, but I'd think that Spoken Wikipedia is more likely to be shut down than reorganized or updated with new projects. It was rendered obsolete years ago when text-to-speech technology caught up. Thebiguglyalien (talk) 02:58, 7 April 2024 (UTC)[reply]
I NEED a discussion of this most excellent video: Video on YouTube. Please link me to one :-) Cheers Video "I Made a Graph of Wikipedia... This Is What I Found" by adumb if it for some reason disappears. Cross posted from Talk:The Signpost#Graph of Wikipedia.CapnZapp (talk) 20:48, 1 April 2024 (UTC)[reply]
Why don't we make this the discussion? :P Thanks for sharing this video, I found it very interesting. Here's some of my notes.
Off the top, it was very cool to see the ways different communities are segmented on Wikipedia, and especially seeing how they interact with each other. I guess I can't be surprised that "United States" is the most linked article, although it is good that we now have a visual representation of US-centric bias on the platform. We desperately need more users to write about different areas of the world, and the map of linked countries is very good at showing just how under-represented the global south is in our catalogue.
The section on orphaned articles, with the demonstration of how much the graph changes when they are accounted for, I think demonstrates the importance of us de-orphaning articles wherever we can (WikiProject Orphanage is doing very important work, consider helping out!). I also loved the six degrees of separation segment, it's so interesting how articles all follow the same pattern in terms of degrees of separation and completely plateau in terms of new links soon after the 6th degree. The follow-up on Orphaned groups is something I think gets missed a lot when we discuss orphaned articles, we often don't look further into how these kinds of article cul-de-sacs can get created as well, even by articles that aren't themselves orphans. Orphaned groups are something we should probably look into. --Grnrchst (talk) 11:07, 7 April 2024 (UTC)[reply]
Upcoming numerological apocalypse
This seems like the default to ask this question, though I hope some of the people I'm trying to reach actually check this page:
Oh, I just know it's coming down the pipe at some point. I genuinely am wondering how IP editors feel about it. Remsense诉 18:29, 5 April 2024 (UTC)[reply]
Bizarrely, that link now redirects (in the HTTP 301 sense) to the WMF's advocacy page. I didn't know MediaWiki could redirect URLs which appear to be wiki pages externally, and it's slightly worrying that it can. Certes (talk) 09:06, 7 April 2024 (UTC)[reply]
You are correct, my bad! I swear I checked it before I sent. Thank you. Remsense诉 14:38, 7 April 2024 (UTC)[reply]
I very strongly support that (the temporary accounts), but then I'm not an IP editor. It seems wonderful for privacy, which if I only edited as an IP I would be concerned about. Cremastra (talk) 19:42, 5 April 2024 (UTC)[reply]
I edit as an IP from time to time and I think an increased layer of privacy is only great. Especially since those seeking to find use for such public-facing IP information are generally doing so for bad faith purposes. (The administrative purposes of site maintenance is done with non-public user IP logs.)
I'd suggest for future consideration, for editor recruitment and retention studies, making available additional features for anonymous editors, inspired by that used in other social media. Some message boards allow limited customization of signatures for anonymous posters, for example, such as flair colors and flag icons; one can hypothesize (and test quantitatively) that giving anonymous editors some extra means to express individuality might encourage eventual creation and retention of accounts. SamuelRiv (talk) 04:41, 7 April 2024 (UTC)[reply]
Anyone seeking to find your IP information may be acting in bad faith, but most investigations concern the minority of IPs which are used to vandalise Wikipedia. Tracking them down so they can be educated or blocked is very much a good-faith activity in the interests of Wikipedia and its readers. As for customisation, the problem is identifying when two visits are by the same person. In many schools and businesses and some homes, multiple editors share a connection or even a device. Wikipedia can only customise appropriately for each person if they log in. We really don't want one editor displaying another's signature because the server can't tell them apart. Certes (talk) 08:29, 7 April 2024 (UTC)[reply]
This seems to be missing something. Identical IPs have identical temporary masks, so abuse can still be tracked by casual editors. The point is that the IP address itself, with all the security concerns attached, is only visible to those with elevated privileges. As for my suggestion of signatured customization, I only made suggestions of what is termed in other forums "flair" or "flags" -- i.e. supplements -- not changing the actual displayed IP mask/username. SamuelRiv (talk) 20:46, 8 April 2024 (UTC)[reply]
There are some relevant comments in a VPM archive. Details of IP masking are still hazy but it may rely on cookies, allowing a vandal to get a new identity by clearing them or browsing privately (e.g. Chrome's incognito mode). It will also be difficult to work out whether two IPs are in a similar range, or to check neighbouring IPs for vandalism. (Hopping within an IPv6/64 is so trivial it often happens accidentally.) Certes (talk) 21:30, 8 April 2024 (UTC)[reply]
I don't have much of an opinion on it yet, to be honest. It'll certainly be nice if it gives me the ability to receive pings, and it may possibly give me a stable talk page across IP addresses on this range - even a separate talk page from that of other users on the range - which would be neat. But if there turn out to be a lot of downsides for English Wikipedia as a whole, the final result may be the entire loss of IP editing here, masked or not, which I would regret. It'll be interesting to see what happens when it's actually turned on. 57.140.16.57 (talk) 15:10, 8 April 2024 (UTC)[reply]
It's a leap into the dark. We have no idea whether we will still be able to fight unregistered vandals effectively or will have to reject the millions of useful IP contributions. I fear that we may soon no longer have an encyclopedia anyone can edit, but I hope to be proven wrong. Certes (talk) 16:25, 8 April 2024 (UTC)[reply]
Does anyone know how long the temporary accounts last and if they last more than 4 days can a temp account become autoconfirmed? I didn't see anything about this in the linked pages but it is a lot to go through. The closest I could find is a comment that there is awareness of the impact on anti-vandal efforts but that is quite vague. RudolfRed (talk) 22:30, 7 April 2024 (UTC)[reply]
One document states that temporary accounts will last a year, but I see nothing about them becoming autoconfirmed and think it very unlikely that it will happen. Certes (talk) 16:27, 8 April 2024 (UTC)[reply]
Adding notice about image copyright
The footer of our pages says:
Text is available under the Creative Commons Attribution-ShareAlike License 4.0; additional terms may apply. By using this site...
I think it would be sensible to change it to something like (additions emboldened for clarity):
Text is available under the Creative Commons Attribution-ShareAlike License 4.0; additional terms may apply. Images may be subject to copyright or require attribution if reused; see individual image pages for details. By using this site...
My reasoning is that images may be open-licensed or fair-use, and in neither case do we display any notice of this to readers on the page.
Is this in our gift, or is it a WMF issue? Where should a request be raised? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:14, 6 April 2024 (UTC)[reply]
The text comes from MediaWiki:Wikimedia-copyright, which is already locally customized. While some of the local customizations make sense, I have no idea why e.g. Special:Diff/546973720 wasn't also done in mw:Extension:WikimediaMessages. To me this seems like another one that should probably be done there first rather than only being done locally. Anomie⚔ 15:05, 6 April 2024 (UTC)[reply]
@Anomie: I mentioned you in that discussion, but my attempt to "ping" you failed (the interface is not one I'm familiar with). Please take a look. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:55, 10 April 2024 (UTC)[reply]
April 8, 1974
Why no mention on home page of 50th anniversary of Henry Aaron hitting 715th home run to break Babe Ruth’s MLB record? Fairly significant; maybe more than formation of Progress Party in Norway? Pliny37 (talk) 07:32, 8 April 2024 (UTC)[reply]
@Pliny37: You can start a discussion at Talk:April_8. There was a previous suggestion to add it, but that was a few years ago. RudolfRed (talk) 19:11, 8 April 2024 (UTC)[reply]
Wikimedia Foundation draft annual plan available for review
Hi everyone,
The Wikimedia Foundation’s draft annual plan for the 2024-2025 fiscal year is now available. This plan is shaped by many factors. These include external technological, regulatory, and social trends in the world about how people look for information and rely on the Wikimedia projects. Our planning was also built around small group discussions on wiki, via mailing lists and over 130 conversations with individuals in person and in scheduled calls. These discussions consistently highlighted the need to remain focused on upgrading our technical infrastructure and supporting volunteer needs for tool maintenance and metrics.
Our answer to these trends and needs is in this draft annual plan. You will see that it prioritises maintenance and upgrades for our technical infrastructure, such as MediaWiki core, data centre operations, and site reliability engineering services. There are also key results around a number of issues discussed here over the past year, such as ways to help volunteers connect to others who share their interests, building newcomer edit workflows that reduce the burden on experienced editors, building a new community wishlist that better connects movement ideas to Foundation activities, and improving tools for editors with extended rights.
The annual plan talk page is open for questions and feedback now through the end of May, after which we’ll summarise all of the responses across talk pages and community calls and publish a final version of the plan that considers this feedback. Thanks in advance for sharing your thoughts! KStineRowe (WMF) (talk) 21:59, 12 April 2024 (UTC)[reply]
Will the Met Office logo ever have its copyright expire?
The Met Office logo is currently protected by Crown copyright in the United Kingdom, but may not be copyrightable in the United States because it does not meet original standards. The version currently uploaded locally on English Wikipedia is the 2009 version. There may be differences in color matching between this version and the 1987 version. Therefore, the copyright protection period of logos uploaded in different periods will also be recalculated. -Fumikas Sagisavas (talk) 04:09, 14 April 2024 (UTC)[reply]
Agree Hooman Mallahzadeh (talk) 16:23, 29 March 2024 (UTC)
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)
I think we should have that “second line” added to these pages (or replaced the “first line”):
Resolved
You are invited to join the discussion at mw:topic:Y2o9jrgkmckm2hv4. Aaron Liu (talk) 17:18, 11 April 2024 (UTC)
The new version of MediaWiki will be on test wikis and MediaWiki.org from 16 April. It will be on non-Wikipedia wikis and some Wikipedias from 17 April. It will be on all wikis from 18 April (calendar). [16][17]
Four database fields will be removed from database replicas (including Quarry). This affects only the 
.jpg){kind=link}
