For a listing of ongoing discussions, see the dashboard.
view
edit
history
watch
archive
talk
purge
RfC: Converting all current and future community discretionary sanctions to (community designated) contentious topics procedureedit
Latest comment: 2 days ago61 comments24 people in discussion
Should all community discretionary sanctions (DS) be updated to use the new contentious topics procedure? Awesome Aasim Refreshed 01:18, 8 March 2024 (UTC) 05:55, 7 February 2024 (UTC)Reply
Background
edit
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)edit
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.) Awesome Aasim 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. Awesome Aasim 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. The contentious topics procedure incorporates all of the improvements from the 2021-22 review of the discretionary sanctions procedure. Compared to the discretionary sanctions procedure, the contentious topics procedure is much easier to understand and follow. For example, many editors currently need to be reminded of topic areas under community sanctions every 12 months to be eligible for certain remedies, which led to complaints in the 2021-22 review. Switching from discretionary sanctions to contentious topics would eliminate this requirement: "Editors no longer need to be alerted every 12 months, as they are presumed to remain aware after their first alert." — Newslingertalk 04:45, 9 March 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? Awesome Aasim 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". Awesome Aasim 05:08, 30 March 2024 (UTC)Reply
When the shift was made to Contentious Topics, the option was made explicitly for the community to use AE if it wished. Barkeep49 (talk) 22:45, 16 April 2024 (UTC)Reply
My problem with relying on AE for them is that decisions there are ultimately made only by administrators and rely heavily on ArbCom decisions in turn. ArbCom is the last stop for things that the community has failed to handle, and administrators are the second-to-last stop; but for thing like DS/CTOP designations, which can have a sweeping practical impact on editing across a large section of the wiki, the initial decision-making ought to be made by the community as a whole. --Aquillion (talk) 17:45, 17 April 2024 (UTC)Reply
Oppose Ivan (talk) 20:58, 21 March 2024 (UTC)Reply
Support - I don't have anything to add beyond what Galobtter said - perfectly expressed. —Ganesha811 (talk) 01:18, 22 March 2024 (UTC)Reply
Oppose as written but open to most of the content of the proposal, per Barkeep49. signed, Rosguilltalk 17:49, 29 March 2024 (UTC)Reply
Oppose for the exact reasons given by Rosguill. Dennis Brown - 2¢ 23:50, 29 March 2024 (UTC)Reply
Oppose Wikipedia:Community discretionary sanctions isn't even active, so why would it be merged? — xaosfluxTalk 17:30, 1 April 2024 (UTC)Reply
The proposal is for community-authorized discretionary sanctions to be modified to follow the contentious topics procedure. isaacl (talk) 17:39, 1 April 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
Support as a starting point, although there are a lot of details to hash out and we should probably approach a community CTOP policy page bit-by-bit rather than trying to create it in one go via an RFC. (I am not sure ANI is the best place for this for reasons I'll get to in a moment, it's just better than what we have.) It's important that there be a way to create or modify CTOPs that the entire community can weigh in on and form consensus around; they can drastically affect editing in an entire swath of the wiki. ArbCom's remit is only to resolve problems that the community has failed to solve, and neither they nor administrators are supposed to be creating or modifying policy by fiat, so given how widespread and central CTOPs have become, it makes no sense for the only way to modify CTOPs to be decision-making processes that go only through administrators or arbcom. In fact I would go a step further (though I think doing this cleanly would require cooperation with ArbCom and agreement on their end to modify existing CTOPs in this regard) and say that a clear, unambiguous community consensus on a particular CTOP ought to be able to move it from ArbCom to community control, since it is an indication that the community can now handle it. CTOPs have grown drastically from their initial origins and affect enough of the wiki (in a way that effectively amounts to an intricate set of policies affecting much of our editing) that it no longer makes sense to leave ArbCom as the final decision-maker regarding them, at least in situations where the community can reach clear and unambiguous agreements. I do agree with some comments above that a noticeboard rather than AN / ANI would be a better place to do things related to CTOPs, though - the whole issue is that CTOPs have grown to the point where they are effectively policy, which means that outside of emergencies or situations where the community has failed to handle one, the first line of control over them should be with the community as a whole, not with administrators or ArbCom. --Aquillion (talk) 17:45, 17 April 2024 (UTC)Reply
Discussion (community contentious topics)
edit
Cooperation of ArbComedit
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. Awesome Aasim 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. Awesome Aasim 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. Awesome Aasim 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
I mentioned this in a big reply below already, but I feel one possible solution to this is to allow the community to take control of ArbCom community sanctions once they're stable (through a clear consensus of editors somewhere), transferring them to community CTOPs. This allows ArbCom to act swiftly and impose CTOPs in situations where the community would inevitably be slow-to-act, and simplifies community decision making because they can just take solutions ArbCom has created and tweak them slightly if necessary; but it avoids the situation we have now where ArbCom functionally takes control of moderation over entire topic areas indefinitely, which IMHO is something we want to avoid. --Aquillion (talk) 18:05, 17 April 2024 (UTC)Reply
I do agree that it's worth considering ways to transfer more control over the CTOP process to the community; it affects so much of the wiki now, and is so forceful, that it has effectively turned into policy-by-fiat, which ArbCom wasn't supposed to do. But I'm not sure its feasible to simply transfer the entire thing to the community at once. What I would suggest (and suggested above) is the following. First, create a community CTOP page that is totally separate from ArbCom's (aside from maybe mentioning it for historical reasons), and encourage ArbCom to use that as the basis for its CTOPs, in the same way most of the other things ArbCom does relies on community-created policy. Second, establish that a clear and unambiguous consensus among a sizable number of uninvolved editors can transfer an ArbCom CTOP to community control and place it under the community CTOP rules. (This would probably require that ArbCom agree to modify existing CTOPs to add a line about how the community can take control of it in that manner.) The principle here is that ArbCom is only supposed to be handling things that the community can't; declaring that governance of an entire topic area is a problem that the community has failed to handle, indefinitely, seems like it's too much - it's a lot bigger than ArbCom handling just one person's ban! But it is true that sometimes things break down and require ArbCom intervention on a large scale or we wouldn't have CTOPs in the first place. Creating an "escape hatch" for once things settle down that allows things to transfer back to community control would leave ArbCom with the tools it needs for emergency situations that the community has failed to handle, while allowing for a way to smoothly return to community control once ArbCom's solutions have settled things and a consensus has built around that (avoiding the situation we have now where entire topic areas are under ArbCom control indefinitely.) --Aquillion (talk) 17:57, 17 April 2024 (UTC)Reply
That seems to match my suggestion: make the process a community-defined one, and work with the arbitration committee to define its process as an add-on to the community-defined process. Transferring all of the arbitration committee-designated contentious topics at once to community-designated ones isn't being proposed, and I agree it wouldn't be a desirable approach. isaacl (talk) 18:05, 17 April 2024 (UTC)Reply
(edit conflict) @Aquillion: Regarding transferring things from ArbCom control to community control. There defacto already is a procedure for this - a request for amendment to the relevant case/motion that authorised the CTOP designation. The request would need to unambiguously state that the intent was to transfer all or part of the topic from ArbCom control to community control to avoid it being confused for a request to remove the designation entirely but other than that wouldn't need to be anything special, although if I were an arbitrator reviewing such a request I'd want to see three things:
Community consensus that such a transfer was desirable
Community consensus that the community does feel able to handle enforcement of it (and no evidence that it can't)
Evidence that CTOP is still required (because it it isn't then it would be preferable to just remove the designation)
Yes, this does mean that it would be ArbCom giving control to the community rather than the community taking control from ArbCom, but we elect arbitrators to listen to the community desires and not act unreasonably in matters like this. I also see it as a protection against a vocal minority that doesn't have the consensus it claims to. Thryduulf (talk) 18:16, 17 April 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. Awesome Aasim 21:21, 10 February 2024 (UTC)Reply
Request revision to initial question
edit
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
Isaacl Done. Awesome Aasim 20:07, 7 February 2024 (UTC)Reply
Tag Refreshed
edit
I refreshed the RfC tag because there is not enough input to gauge consensus. Could this be because this is uncontroversial or what? Awesome Aasim 19:58, 8 March 2024 (UTC)Reply
Could well be :) Selfstudier (talk) 10:27, 9 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. Awesome Aasim 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
edit
Latest comment: 6 days ago161 comments45 people in discussion
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
Well said. — Frostly (talk) 06:28, 5 April 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 per Schazjmd. 🌺 Cremastra (talk) 15:57, 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
For reference, the script seems to be User:Ahecht/Scripts/TemplateSearch. jlwoodwa (talk) 04:53, 18 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
Comment: Unless I'm missing something, the TP: prefix was proposed in 2015, in a discussion which was closed as no consensus - Wikipedia:Village pump (proposals)/Archive 127#Prefix suggestion: TP: for Template:. All the best. —a smart kitten[meow] 19:00, 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
@Phil Bridger tl is ISO639 for tagalog. — xaosfluxTalk 22:20, 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
Oppose. Unnecessary, and just as with T=Talk, TP=Talk Page. wjematherplease leave a message... 08:01, 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 [1] 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
@Mandruss: I highly recommend User:Ahecht/Scripts/TemplateSearch. jlwoodwa (talk) 04:05, 10 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
edit
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
This section is not for opposition to the general concept; see my reply to Anomie's Oppose, below. ―Mandruss☎ 00:53, 10 April 2024 (UTC)Reply
Notifications. ―Mandruss☎ 23:25, 9 April 2024 (UTC)Reply
Notification of all participants to date, regardless of the nature of participation; you commented, you get notified. @Aaron Liu, Ahecht, Alexcalamaro, Anomie, ARandomName123, A smart kitten, Bilorv, Buidhe, CactiStaccingCrane, Chipmunkdavis, Cocobb8, Cremastra, Draken Bowser, Fastily, Frostly, Goldsztajn, GreenC, Isaacl, Izno, Jlwoodwa, JML1148, Johnuniq, Mach61, Michael Bednarek, Mir Novov, Musiconeologist, Nickps, Phil Bridger, Pppery, Redrose64, Schazjmd, Slacker13, Usedtobecool, Wjemather, Xaosflux, and ZandDev: ―Mandruss☎ 23:13, 9 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
Only if they exist, like tl:, but not for tpl:, tmp:, tem:. -- Michael Bednarek (talk) 13:06, 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:
T: New York Times Style Magazine, T: The New York Times Style Magazine → T (magazine)
– Joe (talk) 13:30, 11 April 2024 (UTC)Reply
Of those, Template:A is salted so could be recreated as a redirect to Tribes: Ascend, Template:DS is a pointer to a defunct template so could probably be hijacked as a redirect to Thief: Deadly Shadows, Template:SCC is an unused redirect to Template:Supreme Court of Canada sidebar that could easily be retargeted to Terminator: The Sarah Connor Chronicles, and Template:MP, Template:TSCC, Template:SCC Episodes, Template:New York Times Style Magazine, and Template:Kort are all red. Still opposed to t: since it would cause avoidable confusion, but less strongly so than before. * Pppery * it has begun... 01:36, 12 April 2024 (UTC)Reply
There's a few more than those, in particular T:APRM→Turbo: A Power Rangers Movie; T:OTD→WP:Selected anniversaries; and T:DYKT, T:TDYK, T:TDYKA, and T:tdyk pointing at Template talk: titles. —Cryptic 12:02, 12 April 2024 (UTC)Reply
Note that Template:OTD points to Wikipedia:Selected anniversaries/Date. Aaron Liu (talk) 12:47, 12 April 2024 (UTC)Reply
And Template:DYKT points to a different place than T:DYKT and both are in use. The others are fine: Template:ARPM, Template:TDYK, Template:TDYKA, and Template:tdyk are all red. Template:OTD vs. T:OTD difference seems to be a historical accident not a deliberate difference. * Pppery * it has begun... 17:05, 12 April 2024 (UTC)Reply
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
tm: Cremastra (talk) 23:18, 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
Done. Protip: Use c:commons:Convenient Discussions. It formats bullet-point replies correctly. Aaron Liu (talk) 01:13, 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
Tem. Still saves a whole plate. Hyperbolick (talk) 04:49, 10 April 2024 (UTC)Reply
Note "tem" is the ISO 639 code for Temne. Anomie⚔ 11:29, 10 April 2024 (UTC)Reply
It's so obscure!! Hyperbolick (talk) 09:30, 11 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
tpl:Slacker13 (talk) 14:12, 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
First choice Tm, second choice T: — PerfectSoundWhatever (t; c) 03:11, 13 April 2024 (UTC)Reply
Browser config
edit
I do not know about the rest, but on chrome, using the search engine shortcut feature worked perfectly.
Go to chrome://settings/searchEngines
Click "Add" that's next to "Site search"
Fill out: Name = [Anything], Shortcut = [I picked "tt"] , URL with %s in place of query = https://en.wikipedia.org/wiki/Template:%s
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
You can also use User:Ahecht/Scripts/TemplateSearch to automatically replace TP: and {{ in the Wikipedia search box with Template:. --Ahecht (TALK PAGE) 16:31, 11 April 2024 (UTC)Reply
Deprecating new unsourced articles
edit
Latest comment: 3 days ago169 comments74 people in discussion
REJECTED
After a full month of discussion, it seems fairly clear that this proposal does not have consensus for implementation. Just Step Sideways from this world ..... today 17:40, 16 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.
After the events at Wikipedia:Requests for comment/Deletion of uncited articles and Wikipedia:WikiProject Unreferenced articles/Backlog drives/February 2024, I think there is broad community consensus to not take any policy action against old unsourced articles. However, there should be a process in order to take action against new unsourced articles, because currently there are still new articles that does not have sources attached to it (see the 2023/2024 category at Category:Articles without sources).
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
And if we think further in the future, such a process can also be used to tackle Category:Articles with unsourced statements as well. This would be a glorious sight to behold. CactiStaccingCrane (talk) 06:55, 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".
- CactiStaccingCrane (talk) 07:07, 17 March 2024 (UTC)Reply
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
Number 3 is pretty easy, though. Wikipedia:Third-party sources has been around for years, and we're pretty good at identifying them. WhatamIdoing (talk) 20:43, 24 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:
CactiStaccingCrane (talk) 08:13, 17 March 2024 (UTC)Reply
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
I agree with this. CactiStaccingCrane (talk) 11:27, 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
Schazjmd, created March 24 or in the category March 24? — Usedtobecool ☎️ 15:48, 17 March 2024 (UTC)Reply
@Usedtobecool, from Category:Articles lacking sources from March 2024. (The article has since had one of its external URLs changed to a ref to remove it from the category.) Schazjmd(talk) 15:59, 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. SportingFlyer T·C 15:27, 17 March 2024 (UTC)Reply
This is for recent articles, not old articles. CactiStaccingCrane (talk) 17:28, 18 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
That should be obvious and needs amending now. CactiStaccingCrane (talk) 13:59, 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 Hearts she/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. Seraphimblade Talk 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
Joe, a third-party source is defined in Wikipedia:Third-party sources, and is not about tertiary sources. WP:TERTIARY does not use "third-party" to describe tertiary sources. See also Wikipedia:Secondary does not mean secondhand. WhatamIdoing (talk) 20:46, 24 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
Oppose - here are, at time of writing, the latest uncited articles created today which under this proposal would be prodded: Lake Rabon (South Carolina), Last Train To Fortune, Khereshwar Temple, Teluk Bahang River, 2024 Salzburg local elections, Henry VI's Conquest of Sicily. I'm not seeing those articles as any more problematic than other similar unsourced articles. I think it is better that we make a judgement about which articles we delete rather than simply sweep away everything that meets a broad criteria. SilkTork (talk) 15:00, 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
That's a good point. CactiStaccingCrane (talk) 17:21, 22 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
That is a good argument to get rid of WP:BEFORE too. The Bannertalk 17:09, 21 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
Oppose WP:AFDISNOTCLEANUP, and neither is PROD. InfiniteNexus (talk) 06:32, 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:
.mw-parser-output .templatequote{overflow:hidden;margin:1em 0;padding:0 32px}.mw-parser-output .templatequote .templatequotecite{line-height:1.5em;text-align:left;padding-left:1.6em;margin-top:0}"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
Support OrdinaryGiraffe (talk) 01:00, 24 March 2024 (UTC)Reply
Why? Thryduulf (talk) 01:06, 24 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
@Broc "pages" no (e.g. I don't think Bear (disambiguation) should qualify). Traditional articles, maybe. — xaosfluxTalk 09:31, 10 April 2024 (UTC)Reply
Oppose: If this is going to be a new policy, then it must apply to all articles. Old articles cannot be grandfathered in.--2601:345:0:52A0:E165:4C72:14FB:3B9A (talk) 23:53, 11 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
Comment This proposal also fails to take into account pages that don't require sources, such as lists of lists - see for example Lists of members of the National Assembly (South Korea) converted from a redirect today. Thryduulf (talk) 23:35, 14 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.
Template substitution counter
edit
Latest comment: 8 days ago19 comments9 people in discussion
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
Why not using "What links here"? CactiStaccingCrane (talk) 12:19, 8 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?[2] 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
edit
Latest comment: 3 days ago5 comments4 people in discussion
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.
WikipediaTalk pageTemplateDraftUserUser talk pageModuleMyTest Wikipedia
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
The tabs were added in this edit to Template:Sandbox header by Awesome Aasim. – Joe (talk) 06:41, 12 April 2024 (UTC)Reply
I guess that is what WP:BRD is for.
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}}. Awesome Aasim 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.... Awesome Aasim 06:53, 12 April 2024 (UTC)Reply
Tangentially related, but I've made a request at Template talk:Page tabs#Tab background color to change the default tab colors so it meets the MOS:CONTRAST accessibility guidelines. hinnk (talk) 13:57, 16 April 2024 (UTC)Reply
Suicide hotlines
edit
Latest comment: 8 hours ago37 comments13 people in discussion
For the proposal see User:TheSpacebook/lifeline
Firstly, is this the correct place to put this? Also, I can’t find this proposal on Perennial proposals. I have concerns about the Suicide methods article. I believe it to be a clear violation of WP:NOTHOWTO. Failing that, the article is just a WP:BADIDEA. The consensus is currently for the page to stay, so for now, possibly the suicide crisis line for the reader could be displayed at the top of the page subtly embedded into the article.
But for now, I’ve spun this up in 15 minutes and sourced the numbers from List of suicide crisis lines. This might have to be expanded, as some lines have opening and closing times, so it can be expanded to display just the emergency telephone number when the number is closed. It relies on one thing though, IP address lookup service ‘ipapi’. There are probably better in-house Wikipedia databases that can do this, for better reliability. But essentially it curls the IP address and returns the ISO 3166-1 alpha-2.
The script is ultra-simplistic as I don't know what the specific technicalities of Wikipedia are, so it's a basic HTML script. If a more advanced tool would be better, point me towards the Wikipedia dev docs for the technical specifications. Also, I can build other tools for Wikipedia by piggybacking off the pre-existing ones.
I imagine that some people who have attempted suicide will probably have the Suicide methods article in their internet history. It should work with HTML, so the quickest solution is to insert the script only on the Suicide methods page. Sort of like an WP:IAR. It will also need to be styled so it looks better on the page.
All the phone numbers should be checked for accuracy, but the raw basic script for HTML can be found here: User:TheSpacebook/Suicide crisis line script. And the full HTML page, if it needs testing, can be found here: User:TheSpacebook/Suicide crisis line script HTML page. Just copy and paste it into a text editor, save it with the extension ".html", and then open it in a web browser.EDIT: I’ve reworked my proposal to be more subtle, it can be found here User:TheSpacebook/lifeline. TheSpacebook (talk) 23:15, 17 April 2024 (UTC)Reply
Technical issues aside, this feels a lot like WP:RIGHTGREATWRONGS to me. * Pppery * it has begun... 23:29, 17 April 2024 (UTC)Reply
For background, see Wikipedia:Village pump (proposals)/Archive 161 § Proposal to add suicidal disclaimer at Suicide and Wikipedia:Village pump (proposals)/Archive 192 § Suicides. isaacl (talk) 23:46, 17 April 2024 (UTC)Reply
Thank you for supplying me with those. However, my proposal is completely different. I’m not arguing for the article to be censored, nor the article to have a disclaimer (or "trigger warning"). I’m proposing that the relevant suicide crisis line to be in the article. This already happens on a different article, Suicide prevention, but it only displays the USA number. Possibly another example of the Western, specifically American, WP:BIAS on Wikipedia? Plus, the numbers already exist on List of suicide crisis lines, I think it would be a good idea to put the specific phone number in the appropriate place. TheSpacebook (talk) 00:45, 18 April 2024 (UTC)Reply
Both discussion threads discussed putting a link to a hotline in articles, targeted to the reader's geographical area. isaacl (talk) 01:57, 18 April 2024 (UTC)Reply
Both of those discussions began to get sidetracked to disclaimers or censorship, and were concluded based on those two. I hope this discussion focuses only on the suicide crisis number. Also the Suicide prevention article has a number, and I said in my other comment how this could be American WP:BIAS on Wikipedia. Something like that, but it changes for the country makes reasonable sense to me. TheSpacebook (talk) 10:51, 18 April 2024 (UTC)Reply
The point of providing background is so the relevant discussion points can be reviewed and taken into consideration, to facilitate moving forward from the previous discussions. Both discussions cover relevant issues. isaacl (talk) 16:17, 18 April 2024 (UTC)Reply
Both of them are arguing for WP:DISCLAIMERS. I have since modified my proposal, to make it clear that I’m not proposing a disclaimer. The text already reads that to prevent suicide they should call a crisis number, so it seems more precise to have the exact number. TheSpacebook (talk) 16:29, 18 April 2024 (UTC)Reply
For instance, the second discussion has a post from a WMF staff member on the database it maintains, and how it would be willing to provide support for any community initiative. I feel this is useful background for your proposal. isaacl (talk) 16:37, 18 April 2024 (UTC)Reply
Thank you again for sending me that, it was an interesting discussion. But it sways into WP:DISCLAIMERS which is not what I’m proposing. The script I made is a basic example, as I don’t have access to any of the backend Wikipedia/WMF tools. Linking it to a backend database that WMF maintains would be better. If the number changes, it only needs to be edited once to reflect immediately. TheSpacebook (talk) 17:03, 18 April 2024 (UTC)Reply
Using an external service is a huge "no" from a privacy perspective. If we were to do this, we'd take up the WMF's offer to to it in-house from Wikipedia:Village pump (proposals)/Archive 192#Suicides. But what has changed since that discussion didn't result in acceptance? Anomie⚔ 01:19, 18 April 2024 (UTC)Reply
All the script needs run is the ISO 2-letter country code. This can easily be supplied in-house at Wikipedia/WMF. I just used an external to show a working example of the script, as I don’t have access to any of the Wikipedia backend tools that can be used instead. In my initial post, I said there are probably better in-house Wikipedia databases that can do this. I’m not suggesting an external service is actually used. TheSpacebook (talk) 01:26, 18 April 2024 (UTC)Reply
The user's assumed country is available using Geo.country in javascript. the wub "?!" 08:55, 18 April 2024 (UTC)Reply
Perfect. What format does that return? Would it be Geo.country_code, as the 2 letter ISO country code, or something else? Now I can take away the fetch part:
const response = await
fetch('ipapi.co/country_code');
const country = await response.text();
and have then replace this part:
const country = await fetchCountry();
with the following:
const country = Geo.country
Anyone is welcome to make amendments to User:TheSpacebook/Suicide crisis line script to make it better. Still need to check the format it returns the country in, however. Is that still not an external package/library? If not, the script now fully works in-house with Wikipedia/WMF, using no external services. TheSpacebook (talk) 11:01, 18 April 2024 (UTC)Reply
I realise that this proposal is slightly different, but the comments that I made at Wikipedia:Village pump (proposals)/Archive 161 § Proposal to add suicidal disclaimer at Suicide and Wikipedia:Village pump (proposals)/Archive 192 § Suicides still stand. Phil Bridger (talk) 11:30, 18 April 2024 (UTC)Reply
I quite plainly believe it is not within Wikipedia's mandate to have this sort of thing on an article. Buddy Gripple (talk) 12:48, 18 April 2024 (UTC)Reply
Suicide prevention already does this, but it only displays the USA/Canada number, which I believe shows Western WP:BIAS. So I could maybe amend my proposal to have that page display the relevant suicide crisis number. TheSpacebook (talk) 13:01, 18 April 2024 (UTC)Reply
No, you should rescind the proposal entirely. This is not something we should be doing AT ALL. Any current examples of such need to be removed. --User:Khajidha (talk) (contributions) 13:08, 18 April 2024 (UTC)Reply
Also, you are wrong about the suicide prevention only showing the US/Canada number. The numbers for the Samaritans (UK) and the Netherlands's crisis line (113) are also present in the images. These images (and the one for the US/Canada number) are present as examples of prevention campaigns, not directory listings. There is, however, an imbalance in that article between US material and other countries. --User:Khajidha (talk) (contributions) 13:22, 18 April 2024 (UTC)Reply
Are you referring to these images in the article? I hardly think they count as anything for this discussion, but the Dutch number is in the caption. Also, is List of suicide crisis lines not a directory listing? But I’m glad we agree that there is an imbalance. Perhaps to redress this, the relevant line is displayed, and not the USA/Canada one for everyone. I don’t see the relevance for it to be on the article for non-USA/Canada readers.
TheSpacebook (talk) 13:28, 18 April 2024 (UTC)Reply
Yes, those images. They show prevention methods in use, just as the image at the top of the article shows a poster used in the US. This is not displaying the US/Canadian line for everyone. Yes, the list of suicide crisis lines is a directory. I also think it should be deleted. --User:Khajidha (talk) (contributions) 14:25, 18 April 2024 (UTC)Reply
I’m confused by This is not displaying the US/Canadian line for everyone, it literally is displaying the number for everyone, no? If List of suicide crisis lines was put up for AfD (which I’d oppose for it even being considered to be deleted), my theory is that it would be 'keeped', as per WP:IAR or some similar exceptional policy. TheSpacebook (talk) 14:29, 18 April 2024 (UTC)Reply
As I said before, this image is present as an example of a prevention campaign not as a "here is the number to call" listing. It's a subtle distinction and I have no objection to removing that image. --User:Khajidha (talk) (contributions) 14:59, 18 April 2024 (UTC)Reply
Can I just clarify, I’m not proposing a banner to be placed on the page, I’m proposing something more subtle. For example, the third paragraph in Suicide methods could easily be reworded to include the script which displays the number, without looking so blatant: (emphasis added) Some suicides may be preventable by removing the means. Making common suicide methods less accessible leads to an overall reduction in the number of suicides. Some method-specific ways to do this include restricting access to pesticides, firearms, and known-used drugs. Other important measures… and calling a crisis hotline. TheSpacebook (talk) 14:23, 18 April 2024 (UTC)Reply
It's not obvious to me that such a banner wouldn't have some unintended consequences. I know search engines and newspaper articles about suicide use them, but all kinds of stuff gets done for herd reasons. How do we know that a big obvious warning box would not itself prompt someone to move from a state of passive information consumption to a state of actively contemplating a personal action? The prompt could trigger the thought that "Someone thinks I might actually do it", which is one hop from "I might actually do it". Barnards.tar.gz (talk) 14:36, 18 April 2024 (UTC)Reply
I’m not proposing a banner. Just something more subtle. A banner would open a Pandora’s box and snowball into other content warnings, erring too close to WP:CENSORED. TheSpacebook (talk) 14:41, 18 April 2024 (UTC)Reply
So at the very least, this seems to require running a default gadget to change the content of an article in a manner that would be hard to editorially control. That doesn't seem like a good use of technical resources to me, without even getting in to the problems related to invalidating caches or editor issues of having this be interface-admin protection content. — xaosfluxTalk 17:42, 18 April 2024 (UTC)Reply
Noted. The aim of this is to subtly include the text in the article. But, I’ll add a 'default text' parameter to display if there isn’t a number available, that can be unique to each use of the script. TheSpacebook (talk) 17:47, 18 April 2024 (UTC)Reply
I hadn't thought through the techical aspects of this before. The proposal seems to be to present different content to different people. As far as I am aware that is something we stopped doing, for very good reason, about fifteen years ago when we gave up turning linked dates around. Do we really propose to start doing that again? Phil Bridger (talk) 20:01, 18 April 2024 (UTC)Reply
I’ve completely reworked my proposal, it's vastly different from displaying dates and content warning disclaimers. It can be found at User:TheSpacebook/lifeline. I can’t find anything the exact same as what I’m proposing. Whilst they use geolocation, all previous suggestions seem to be some sort of banner/warning. TheSpacebook (talk) 20:06, 18 April 2024 (UTC)Reply
But you seem to be suggesting displaying different content to different people based on their location. Phil Bridger (talk) 20:27, 18 April 2024 (UTC)Reply
Correct. But there isn’t a specific rule against doing it for this tool/template as per WP:5P5. TheSpacebook (talk) 20:42, 18 April 2024 (UTC)Reply
There isn't a specific rule against me sticking my left index finger in my ear and singing "The Star-Spangled Banner" while drinking a glass of champagne, but that doesn't make it a good idea. Phil Bridger (talk) 20:58, 18 April 2024 (UTC)Reply
If in the UK, s/Star-Spangled Banner/God Save the King/ [1] 1. except in Wales or Scotland, or for those in Northern Ireland from one community. And republicans, anarchists, and those who switch Javascript off. Those using TOR, VPN, or who have activated add blockers. Sirfurboy🏄 (talk) 06:59, 19 April 2024 (UTC)Reply
It would simply be far better than a script as to have one page, likely in WP space for the purpose, to give the read a list of numbers to contact if they feel suicidal and need help. Not dynamic , but absolutely clear what number they should use by country list. A separate mainspace page that identifies these numbers is also fine, but there's likely a different format and purpose there, to inform, not to urge getting assistance.Whether to include it on topics that directly deal with suicide, that's a separate issue. I think our disclaimers warn about medical advice and this would seem to fall within it. — Masem (t) 12:17, 19 April 2024 (UTC)Reply
Previous discussions have come out against this type of proposal, because it would be almost impossible to maintain an accurate and up to date list of phone numbers for every country, or to identify with 100% accuracy where the reader was located. This is an idea that is well meaning but is unlikely to work well in real life situations.--♦IanMacM♦(talk to me) 15:02, 19 April 2024 (UTC)Reply
I understand all the concerns. Just thought I’d offer up a solution which met in the middle when this issue is raised, and be subtle to avoid a disclaimer. WMF said that they already maintain this database in the previous discussion and have more advanced tools to geolocate users: https://en.m.wikipedia.org/wiki/Wikipedia:Village_pump_(proposals)/Archive_192#Suicides. My proposal is in good faith, the subtle template seems like something WMF could do a lot better with their advanced tools etc. TheSpacebook (talk) 16:51, 19 April 2024 (UTC)Reply
Tagging blocked socks
edit
Latest comment: 6 hours ago13 comments8 people in discussion
I have recently noticed that @Liz has reverted my edits on blocked sockpuppet User:JayCubby for adding the {{Sockmaster}} tag on the userpage. The template page itself states that it is reserved for administrator and checkusers only, however I believe that it should be open to use for everyone in good faith who attempt to save others' time by putting this template on a blocked sock's user page to help improve the encyclopedia. I propose that the rules on that template be changed to accomodate this requirement. 2003LN6 15:53, 18 April 2024 (UTC)Reply
Also pinging @Primefac as original blocker. 2003LN6 15:57, 18 April 2024 (UTC)Reply
How exactly do you mean, "help improve the encyclopedia"? -- zzuuzz (talk) 16:35, 18 April 2024 (UTC)Reply
@Zzuuzz:It would save time for editors wanting to know exactly why the user was blocked and when. This way, they would not need to go into their contribs and find out themselves. 2003LN6 18:55, 18 April 2024 (UTC)Reply
So why propose this for just sock blocks if the intention is to save time on finding why a user was blocked? Not that I want it called out on the user page for everybody, but I'm just saying, why stop there if that's the goal? Hey man im josh (talk) 21:33, 18 April 2024 (UTC)Reply
There's probably an appropriate amount of information on the talk page for that purpose. The global lock reasons also raise significant questions. These tags can sometimes be useful to help locate the correct SPI/LTA page for finding, reporting and actioning repeat customers where it's not entirely obvious (carefully balanced with WP:DENY), but for someone who just made a mistake it's overkill with little utility. Not only might it oversimplify a complex situation, it may even overcomplicate a simple situation. Whatever the case, I don't really see how the tags would really help with anything here. -- zzuuzz (talk) 23:29, 18 April 2024 (UTC)Reply
Template documentation isn't policy and while non-admins/non-clerks are informally discouraged from tagging socks, in practice most will look the other way if the tagging is reasonable. But there are various situations where we will choose not to tag in the interests of WP:DENY, discretion, or not oversimplifying a complex situation. I would not have tagged this account and I would suggest you find a more interesting thing to do on Wikipedia than applying tags to user pages. Spicy (talk) 16:54, 18 April 2024 (UTC)Reply
(edit conflict) Agreed; there are more productive things for editors to do than go around tagging blocked users' pages. Primefac (talk) 16:58, 18 April 2024 (UTC)Reply
@Spicy: Thank you for your explanation. Why would it be discouraged from tagging this user particularly? You have explained that it is generally fine if the tagging is reasonable and I believe that my use of the tag was reasonable. 2003LN6 18:54, 18 April 2024 (UTC)Reply
Making a fuss about blocked users is not helpful. People who deal with socks are quite capable of tagging where they believe there is a benefit. There might be many reasons a particular page is not tagged and discussing details is a waste of time and the opposite of WP:DENY. One example of why a sock might not be tagged is that we just want them to find another hobby and avoid righting-great-wrongs at Wikipedia. Johnuniq (talk) 23:30, 18 April 2024 (UTC)Reply
Non-admin tagging of socks presents a few problems. 1: It doesn't improve the experience for the reader in any way whatsoever, so there is no pressing need for a tag to be applied immediately, if at all. 2: Mistakes are often made, which raises WP:CIVILity issues, and causes drama that admin often have to deal with. 3:Admins are accountable to the community, non-admin/IPs are not, so the labeling of someone as a chronic policy violator should be limited to admin only, the majority of the time. There are several reasons why admin choose to NOT tag some socks, including WP:DENY, which can be based on non-public information that non-admins don't have access to. Dennis Brown - 2¢ 23:49, 18 April 2024 (UTC)Reply
@2003 LN6: I'd just like to point out, since maybe you missed it, that you tagging accounts as socks (in this case before they were even blocked) had already caused confusion for the administrator who blocked them in this ANI thread(it caused one of the socks to not be blocked): Wikipedia:Administrators'_noticeboard/IncidentArchive1153#Sockpuppet? The admin, @Drmies, had also asked you to leave the tagging of socks to admins or SPI clerks, as well: Special:Diff/1218557430. – 143.208.238.41 (talk) 06:11, 19 April 2024 (UTC)Reply
Thank you for all of your comments. I appreciate the feedback and will conform to these guidelines in the future. 2003LN6 19:06, 19 April 2024 (UTC)Reply
