*'''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. <span style="white-space: nowrap;">— [[User:Wugapodes|Wug·]][[User talk:Wugapodes|a·po·des]]</span> 21:05, 18 March 2024 (UTC)
*'''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. <span style="white-space: nowrap;">— [[User:Wugapodes|Wug·]][[User talk:Wugapodes|a·po·des]]</span> 21:05, 18 March 2024 (UTC)
*'''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. <sub>[[User:Wjemather|<span style="color:#0D5218">wjemather</span>]]</sub><sup>[[User talk:Wjemather|<span style="color:#520D0D">please leave a message...</span>]]</sup> 22:24, 18 March 2024 (UTC)
*'''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. <sub>[[User:Wjemather|<span style="color:#0D5218">wjemather</span>]]</sub><sup>[[User talk:Wjemather|<span style="color:#520D0D">please leave a message...</span>]]</sup> 22:24, 18 March 2024 (UTC)
*'''Oppose'''. It is necessary that articles be based on sources, but not that the sources be cited in-line. Other, less [[WP:BITE]]y methods are better ways to address this issue than quickly deleting new articles. Such as a more leisurely deletion process or drafification. [[User:Eluchil404|Eluchil404]] ([[User talk:Eluchil404|talk]]) 00:22, 19 March 2024 (UTC)
== Make Todays Featured List appear exactly every 3 days instead of 3-4 days ==
== Make Todays Featured List appear exactly every 3 days instead of 3-4 days ==
When discussion has ended, remove this tag and it will be removed from the lists. If this page is on additional lists, they will be noted below.
Should all community discretionary sanctions (DS) be updated to use the new contentious topics procedure? AwesomeAasim Refreshed 01:18, 8 March 2024 (UTC) 05:55, 7 February 2024 (UTC)[reply]
Background
In late 2022/early 2023, the discretionary sanctions procedure was overhauled by ArbCom and converted to "contentious topics". With now two different processes for two different kinds of sanctions there is now a lot of fragmentation and inconsistency in how contentious topics should be handled, with even conflicting wording. The main goal of this RfC is to unify the procedure used for all areas where general sanctions are in effect with the one designated by ArbCom, going forward.
As proposed at this time, there will be the some similarities and differences between community and arbitration contentious topics, including:
The imposition of the standard set of restrictions by consensus of administrators in a community designated topic would be at WP:ANI rather than WP:AE.
Reconsideration of contentious topic restrictions would be done at WP:AN instead of at WP:AE or WP:ARCA.
Awareness of a community contentious topic would include but not be limited to being mentioned in the discussion closing summary regarding that contentious topic, which is the closest there is to a "final decision".
And of course, ArbCom would be able to convert community contentious topics to those designated by the committee, after which all the ArbCom venues would have to be used from that point forward, though existing restrictions would remain appealable to WP:AN until renewed at ArbCom.
Survey (community contentious topics)
Support as proposer. It needs to be clear, especially for new editors, what contentious topics are and what the expectations are for editing topics designated as contentious by either ArbCom or the community. A unified procedure will ensure consistency rather than fragmentation and will make editing the list of contentious topics and their restrictions much easier. (I did do a little bit of work in the Module:Sanctions/sandbox adding in support for ArbCom contentious topics, as it would make it so much easier to use the related sanction templates. I also did work in user space to help envision what a unified contentious topics page might look like.) AwesomeAasim 05:55, 7 February 2024 (UTC)[reply]
Strong Oppose The current iteration of WP:CTOP is far too tied in to the Arbitration Committee. The available sanctions and procedures are under the jurisdiction of WP:AC/PR can be modified by the Committee by motion at any time, which in this scenario would be binding on decisions made by the community without community consensus. Additionally, many of the General Sanctions areas have a set of restrictions that either exceed what CTOP would allow, or have a more limited subset of them. The community currently has the flexibility to customize sanctions based on the needs of the individual topic area (similar to how Arbcom can impose their own restrictions either alone or on top of the CTOP designation), rather than relying on a "one size fits all" solution. Regarding the possibility of Arbcom choosing to convert community-based CTOP to Arbitration Enforcement, the Committee already has the power to supercede and convert General Sanctions. They've done so before, in cases including WP:ARBCC and WP:ARBTPM. This proposal as written would reduce the community's autonomy and flexibility for the sake of consistency, and I don't see that as a net positive.I would, however, support the community adopting a "standard/default" DS language that could be used when customization isn't needed, and reviewing all the existing GS areas to see if they should be abolished or modernized. Updating our own process, templates, info pages etc to completely separate from the Arbcom version would also accomplish this proposal's goal of reducing confusion and would be better than the current system of sometimes linking to CTOP, sometimes linking DS which redirects to CTOP (when they really mean the older version of DS), sometimes a completely different thing with no consistency. Template:Gs/alert is one example of this, where it links to WP:CTOP even when the actual restrictions are unrelated to that designation. Revamping our own procedures would be a better way to reduce fragmentation and confusion than glomming onto what Arbcom chooses to do. The WordsmithTalk to me 18:32, 7 February 2024 (UTC)[reply]
I am not exactly seeing how this is a dealbreaker. The CT procedure applies only to designated contentious topics; community consensus or arbitration remedies can always add additional sanctions regardless of WP:CTOP like in WP:ARBPIA. AwesomeAasim 22:13, 7 February 2024 (UTC)[reply]
Support The phrase "discretionary sanctions" is not clear and so the phrase "contentious topics" was introduced as an improvement. We should have clear and consistent language for contentious matters so that discussions and actions are comprehensible. Andrew🐉(talk) 08:57, 10 February 2024 (UTC)[reply]
Support. The "sanctions regimes" are too complex as it is, and we need to use consistent terminology to reduce that complexity when possible. — SMcCandlish☏¢ 😼 13:03, 21 February 2024 (UTC)[reply]
Support making the rules clear and consistent to all users. A big part of the problems I've had with DS is that I couldn't tell what was expected of me. No comment on whether this new way of doing things is better or worse than the old one, but it sounds like this isn't that conversation. I 100% support clear and proactive explanations of what Wikipedia does and does not want from its editors. Darkfrog24 (talk) 16:10, 9 March 2024 (UTC)[reply]
Support making the rules clear and consistent for all editors. Let'srun (talk) 19:33, 10 March 2024 (UTC)[reply]
Support standardization — as is, the current discrepancy is an unintended relic, not a feature. Community-imposed vs Arbcom-imposed sanctions is a clerical, technical distinction, and I cannot think of any good reason not to streamline the two into the same concept, for the sake of simplicity and understanding. ~Swarm~{sting} 02:39, 12 March 2024 (UTC)[reply]
Support Contentious topics is confusing enough by itself. Two similar but not identical rules is too much. I support any efforts to standardize our sanction systems. Galobtter (talk) 02:53, 12 March 2024 (UTC)[reply]
Support in the abstract – it might require some case-by-casing, but I think in general, having one set of rules for everyone is much cleaner and easier to understand for those trying to follow the road. theleekycauldron (talk • she/her) 00:00, 17 March 2024 (UTC)[reply]
Discussion (community contentious topics)
Cooperation of ArbCom
I wonder if adding in stuff to the WP:CTOP page and similar would require the petition and referendum process. If so, then I guess the merging of templates would have to hold off until a former petition and request for amendment actually passes. It is possible ArbCom will green light the merge if this RfC passes, but I do not know. AwesomeAasim 05:55, 7 February 2024 (UTC)[reply]
I feel the community should work with the arbitration committee to assume responsibility for the contentious topic process, with a pointer to an arbitration-committee specific page where it can customize the process as it feels necessary. This would bring the process under community control, while still allowing the arbitration committee to adapt it to its needs. (There is no change to arbitration policy and so no need to amend it.) isaacl (talk) 19:07, 7 February 2024 (UTC)[reply]
Wouldn't that just be the status quo (or perhaps the old GS/DS) status quo? I think Arbcom is more agile than the community in drafting this kimd language given that passing a motion is easier than an RfC and motions can be adjusted mid vote which is nearly impossible to do with an RfC. Truthfully I think the right place to start is with the standardized language for community GS and perhaps to be more intentional about whether it wants its restrictions to be eligible to be heard at AE, though as The Wordsmith points out there are really good reasons for the community to decide not to do that. Barkeep49 (talk) 04:30, 9 February 2024 (UTC)[reply]
The process for authorizing discretionary sanctions was documented by the committee, and then later the community started authorizing discretionary sanctions, with its process pointing to the Arbitration Committee pages and saying, "like that". This resulted in the community's process being coupled to decisions made by the arbitration committee. I'm suggesting the reverse: have the community assume responsibility for the contentious topics process, and then the arbitration committee can point to it and say, "like that, but with our specific customizations". I agree the community can decide on its own on what contentious topic process it wants to create. I think it would be good, though, to check with the committee that it is amenable to adopting the community process as a base, and layering any desired differences on top. isaacl (talk) 04:52, 9 February 2024 (UTC)[reply]
That also sounds like a good idea: community authorizes the remedies that are appropriate, ArbCom implements them. If ArbCom were to deviate then they would just need to ask the community whether it is an appropriate deviation or not. AwesomeAasim 17:28, 9 February 2024 (UTC)[reply]
The committee doesn't have to be constrained by the community as it is already authorized through the arbitration policy to enact remedies of its devising for matters within its scope. It would be simpler for editors to understand, though, if the arbitration committee version of the process was just a set of differences upon a common process. Differences could include things like additional administrator actions that could be performed, or a specific venue for appeals. isaacl (talk) 18:03, 9 February 2024 (UTC)[reply]
I think you know what I mean :)
WP:ARBECR is already used a lot by both the community and by ArbCom, like in WP:RUSUKR and WP:CT/A-I. What I am saying is if ArbCom feels that a specific sanction that there has never been any precedent for is necessary, they should propose it to the community, where there then can be consensus on the exact wording. Placement, enforcement, and appeals are all going to differ though depending on whether the restriction is placed by the community or ArbCom. AwesomeAasim 18:43, 9 February 2024 (UTC)[reply]
The community can provide feedback on proposed decisions. I disagree that the committee needs to obtain community consensus on new types of remedies. The arbitration committee is empowered to impose a restriction that community consensus has been unable to reach through prior dispute resolution. If you are referring specifically to the standard set of restrictions that can be imposed for designated contentious topics, I still disagree that community consensus should be mandatory. Typically the committee will provide an opportunity for feedback and the last review of discretionary sanctions illustrates that it strives to lighten the load of enforcing administrators. isaacl (talk) 19:17, 9 February 2024 (UTC)[reply]
Regarding the extended-confirmed restriction, it was initially devised by the committee on its own. After taking some time to evaluate its effectiveness, the community chose to adopt it as an available restriction. isaacl (talk) 19:25, 9 February 2024 (UTC)[reply]
I agree with isaacl that ARBPOL and CONEXEMPT explicitly mean that the committee does not have to, with-in its scope, get community consensus. However, ECR is a example of why I think the committee is better placed at the moment to be a leader when it comes to contentious topics. The committee having to deal with the absolute hardest conflicts means there is going to be more of an incentive to try something new and ~15 people are going to have an easier time getting to yes than what is required to get community consensus for that newness. It's also revealing to me that ArbCom gets more requests for us to assume community imposed sanctions (examples: COVID, Horn of Africa as two that the committee did assume and Russia-Ukraine War as one that committee has twice been asked to assume and haven't). I would really love it if the community could, as it does in so many other ways, demonstrate broader capabilities when it comes to general sanctions than it has in the past. And to that end getting consensus for some standard wording would be a great place to start. Barkeep49 (talk) 19:48, 9 February 2024 (UTC)[reply]
I agree that the arbitration committee is better positioned to try new approaches (consensus doesn't scale up well, so getting consensus amongst 15 people is definitely easier). In a similar vein as you expressed, I feel it would be ideal for the community to agree on a base contentious topics process, which the committee could extend in new ways that the community could later choose to incorporate back into the base process. isaacl (talk) 19:57, 9 February 2024 (UTC)[reply]
In WP:DS2022, one of the changes made was to allow the community to make use of AE. I think we should do so. HouseBlaster (talk · he/him) 03:42, 9 February 2024 (UTC)[reply]
I definitely think we should split contentious topics from WP:AELOG. A separate contentious topics log would make restrictions much easier to follow - and, if the restriction is rescinded or converted from community to ArbCom or the other way around - it can be logged as well. AwesomeAasim 21:21, 10 February 2024 (UTC)[reply]
Request revision to initial question
The statement all community general sanctions (DS) in the initial question is misleading. "General sanctions" is not synonymous with community authorization for discretionary sanctions. I think the intent should be clarified that the proposal only affects discretionary sanctions authorized by the community, and not all general sanctions. isaacl (talk) 19:03, 7 February 2024 (UTC)[reply]
I refreshed the RfC tag because there is not enough input to gauge consensus. Could this be because this is uncontroversial or what? AwesomeAasim 19:58, 8 March 2024 (UTC)[reply]
I think it's because many editors simply don't know what's going on. I didn't know this discussion was taking place. I'm still not sure what the change in policy is, only that, if it has been changed, the system should be clear about it. Are we dissolving Discretionary Sanctions? Is AE not going to be a thing any more? Is it merging with ANI? Darkfrog24 (talk) 22:37, 17 March 2024 (UTC)[reply]
@Darkfrog24 The question is really just about making community sanctions use the new contentious topics procedure. AwesomeAasim 23:45, 17 March 2024 (UTC)[reply]
Okay. What is the new CT procedure? Do you know how it's different? I just read through one of the links that Newslinger provided above, and I'm having trouble picking out differences. Darkfrog24 (talk) 00:35, 18 March 2024 (UTC)[reply]
For full details, see Wikipedia:Contentious topics. It's basically a renamed version of discretionary sanctions, with changes made based on community feedback received during the 2021–22 review of discretionary sanctions. Some highlights: there is a standard set of restrictions that a single administrator can impose on their own discretion. Restrictions outside of these can be imposed by a consensus discussion at the arbitration enforcement noticeboard. Sanctions are no longer limited to one year, but after a year, sanctions that were imposed by a single adminstrator no longer have to be discussed at the arbitration enforcement noticeboard to be modified. Users no longer have to be made aware of each specific topic area. They only have to be notified once using a specific template about the contentious topic system. Striking out inaccurate description. isaacl (talk) 01:56, 18 March 2024 (UTC)[reply]
Users no longer have to be made aware of each specific topic area. They only have to be notified once using a specific template about the contentious topic system. That would contradict the CTOP regime. Even among the Arbcom sanctions, editors still have to be notified about topic areas individually. The WordsmithTalk to me 19:54, 18 March 2024 (UTC)[reply]
My apologies; I misspoke. A specific template only has to be used for the first notification about the contentious topic system in general. Subsequently, any form of notification can be used to inform a given user about specific contentious topics. Previously, a specific template had to be used for each affected topic area. isaacl (talk) 21:22, 18 March 2024 (UTC)[reply]
Again, not all community sanctions, but community-authorized discretionary sanctions. isaacl (talk) 01:36, 18 March 2024 (UTC)[reply]
Is it time for a new design for the main page?
Hi, Wikipedians,
I believe it's time to consider updating the design of the main page. I'm not certain when the current style was implemented, but it seems to date back to 2006 or even earlier. Nowadays, there are numerous modern and colorful box templates available that could give the page a more contemporary look. What are your thoughts on starting this initiative? After all, the main page represents our entire community. I understand that changing a familiar style can be challenging for many users, but it's part of the natural cycle of updates.
+1 It still looks good on Desktop and even on my phone, in Monobook and Minerva. Everything is in one column and the content is very readable.The WordsmithTalk to me 17:03, 14 February 2024 (UTC)[reply]
Wikipedians don't like change (see above), so it's not going to happen without a lot of work, but I do agree that it's time for a redesign. Since the last major attempts a decade ago, responsive design technology has advanced enormously, a new design system has been rolled out across Mediawiki, and we got a new default skin. All of this makes the main page look particularly dated and out of place in 2024. Ideally, we'd proceed by asking Wikimedia's design team to lend us their expertise and create something new – subject to community-agreed goals and constraints but not a crude yes/no vote on using it (which would inevitably fall afoul of the "change is bad" phenomenon). – Joe (talk) 07:36, 14 February 2024 (UTC)[reply]
Riad Salih You could probably get consensus for the general idea that the MP should be changed, but the consensus would break down over what specifically to change it to, as everyone has their own idea about that. As noted, this is a constantly made proposal. The best chance of success would probably be to propose incremental changes, one at a time- a wholesale redesign would never gain consensus. Even a small change would take much work to convince others to support and implement. 331dot (talk) 08:53, 14 February 2024 (UTC)[reply]
Change for the sake of change! People can contribute and don't wish for anything they don't change to not change. Aaron Liu (talk) 13:10, 10 March 2024 (UTC)[reply]
One idea that might get approval is moving to a single column. The current layout was well designed when pages used the whole screen, but there are very few words on each line now that we have two thin columns shoehorned into a narrow stripe down the middle of the screen with an acre of empty white space either side. Certes (talk) 10:17, 14 February 2024 (UTC)[reply]
The white space is probably from the skin you are using. It looks fine in legacy vector. Easier to change the skin to something that you like rather than change the main page for everyone RudolfRed (talk) 01:41, 15 February 2024 (UTC)[reply]
From a purely selfish viewpoint (which is allowed, as this is an aesthetic matter), I want the main page to remain unchanged. I use Vector 2010, and everything looks just fine to me. However, the vast majority of readers don't have the luxury of setting that preference, and are stuck with wide blank sidebars. Certes (talk) 09:51, 15 February 2024 (UTC)[reply]
I use the full width view of new Vector, but when checking it on the narrow width, it looks fine to me. A little narrow perhaps, but not nearly constrained enough IMO to obviate the advantages of a two-column view. ― novov(tc) 08:33, 15 February 2024 (UTC)[reply]
As Joe Roe said, Wikipedians are usually a little less open to change than a cube of iron. But do you have any specific ideas? 🌺 Cremastra (talk) 13:17, 14 February 2024 (UTC)[reply]
I kind of like the Spanish version, but Vector 2022 forces the text to wrap in a weird way because it's so narrow. The Turkish version is pretty similar to en.wiki's, and wouldn't be much of an improvement. I also looked at the Chinese MP (fine, but too white) the French one (I quite like it, actually), and and what I believe is the Slovakian one, which I also quite like. 🌺 Cremastra (talk) 12:58, 15 February 2024 (UTC)[reply]
@Cremastra Yes, I do agree with that, especially the Slovakian one. However, you know we still need ideas from other contributors, which can be challenging. Nevertheless, I will make an effort to advocate the idea of changing the main page design. Riad Salih (talk) 14:19, 16 February 2024 (UTC)[reply]
With all due respect, the gradients in the Slovakian one make it look very dated, like an early-2000s PowerPoint template. --Ahecht (TALK PAGE) 15:15, 19 February 2024 (UTC)[reply]
I agree that the Slovakian one is too dated. I don't see any problems with the Spanish version under vanilla V22. Maybe swap POTD with On this day for slightly longer line lengths for the latter, make Other projects full-width (and maybe unbox it), and of course adapt ITN to our format, but I don't think the Spanish version needs any more changes. Aaron Liu (talk) 16:25, 19 February 2024 (UTC)[reply]
I would concur that it's a good idea. IMO, some of the other Wikipedias have Main Pages that put enWP's one to shame. But as others have stated, good luck finding something that everyone can agree on. ― novov(tc) 08:38, 15 February 2024 (UTC)[reply]
Is there something particular you feel is a problem with the current design? – Teratix₵ 09:17, 15 February 2024 (UTC)[reply]
I think that it’s probably best to make changes one by one, so that consensus would be more likely. Like one change per discussion. 71.239.86.150 (talk) 16:01, 17 February 2024 (UTC)[reply]
Redesign it, but in a way that removes ITN and DYK. Both are massive investments for very little return, and much of the content they display is low quality. Thebiguglyalien (talk) 00:50, 19 February 2024 (UTC)[reply]
Fucking excuse me? How the heck are the articles that we've vetted low quality? ITN gives us some global perspective and is one way readers could keep themselves up to date in current events. DYK makes everything a bit more fun for everyone and trivia is fun. Both highlight our utility as an online encyclopedia and good work on our behalf. Removing it would make no sense at all. It has worked, it is working, and it returns. Aaron Liu (talk) 02:51, 19 February 2024 (UTC)[reply]
@Aaron Liu: The problem with opening remarks such as Fucking excuse me? is rather that they invite a retort along the lines of, yes, well, "fucking excuse you".Regarding the gist—How the heck are the articles that we've vetted low quality—I think what Thebiguglyalien might be getting at is that simply undergoing a vetting process is insufficient; it is the quality of the vetting that is important, and so by extension, the quality of those doing the vetting. If, for example, ITN and DYN undergo a lightweight review which is perhaps keener on filling slots and reducing backlogs than ensuring the integrity of the main page, then it would be unsurprising, in some eyes, if these processes came under extra scrutiny, hein. Some might also argue that trivia—however much "fun" it is—is incompatable with an encyclopedia that aspires, where possible, to serious scholarship. HTH! ——Serial 16:30, 20 February 2024 (UTC)[reply]
Thanks for the detailed explanation, though I don't think the vetting that we do is low-quality. At least at ITN we do a pretty big referencing pass. I also wonder what you mean by "hein". A dictionary search shows that it is 1. surprisingly not German 2. Dutch for death 3. French and Portuguese for "huh?". Is that last one what you meant? Aaron Liu (talk) 17:10, 20 February 2024 (UTC)[reply]
@Aaron Liu:, indeed, I know no German or Dutch! But yes, a "huh" because I wasn't speaking for myself on the quality of the vetting, merely that it's a view (among others, of course, as you point out.) Cheers, ——Serial 17:14, 20 February 2024 (UTC)[reply]
Thanks for the work, but unfortunately I don't like it very much:
I don't know any good ways to fix this, but flushing the Welcome banner's text to the left leaves a lot of blank space in the rest of the box, making it feel weird.
We already have a search box; we don't need another one.
The third column has line lengths that are way too short in the limited width. That makes the excessive space to the right of the descriptions all the more jarring. And that is in my version of V22 enhanced with my private styles. Under the normal limited width all the columns have line lengths that are too short and the sister projects' descriptions run off the page.
Something feels wrong about the concept of giving that much prominence to our sister projects. Wikipedia readers are hardly gonna go there and this introduces a lot of colorful icons that clutter up your attention. Previously it'd only take attention when you scroll/look down and want to dedicate attention to it.
Lots of useless blank space under the third column.
Probably a bug, but Other areas of Wikipedia appears twice.
User:Cremastra/MP: using Galobtter's design for the main portion. I think a large prominent search box on the main page is a good idea, though, as opposed to a redundancy. 🌺 Cremastra (talk) 16:59, 19 February 2024 (UTC)[reply]
That does look much better! Combining the search box with the first box seems alright, though maybe I'd use the tagline "Search free knowledge". I'd also recommend making the globe logo stick to the bottom of its box, replacing the whitespace between the first two boxes with a horizontal rule, and maybe put the occasional banner before that rule with a white background. Aaron Liu (talk) 18:48, 19 February 2024 (UTC)[reply]
I'm not sure about the search box, but I like the top banner otherwise, especially the logo in the bottom left. Galobtter (talk) 01:09, 20 February 2024 (UTC)[reply]
I don't think WPAds should be isolated. Maybe it could replace the search box.Also, any ideas for how to eradicate that awkward gap below the image for the first box? Aaron Liu (talk) 02:20, 20 February 2024 (UTC)[reply]
I think the portal links should be omitted, especially since previous consensus is to do so. Also, I don't think that the Wikipedia Ad should be present, and I'm not sure about how the logo is presented. QuicoleJR (talk) 18:39, 3 March 2024 (UTC)[reply]
Oh, ok. Still, the portal links need to go, and I'm not sure why we only display 1/4 of the globe logo. QuicoleJR (talk) 18:51, 3 March 2024 (UTC)[reply]
I don't understand what you mean about the globe logo. The logo is visible on all pages. 🌺 Cremastra (talk) 18:55, 3 March 2024 (UTC)[reply]
I mean the corner of the globe that you placed next to "Welcome to Wikipedia!" QuicoleJR (talk) 21:32, 3 March 2024 (UTC)[reply]
Yeah, that's common across Wikipedias, e.g., see fr:. 🌺 Cremastra (talk) 21:56, 3 March 2024 (UTC)[reply]
If we modernize it, I suggest we make it like eswiki's (which happens to be adapted from ruwiki's). It's OOUI, modernized and is in a familiar layout, though I might make the "other projects" part full-width. Aaron Liu (talk) 02:48, 19 February 2024 (UTC)[reply]
Honestly I quite like eswiki's, but I would only change the style, and leave how ITN and etc are formatted as is. But, strongly support changing the "Welcome to Wikipedia" header Pksois23 (talk) 09:06, 15 March 2024 (UTC)[reply]
I like the eswik's too, clean and simple Riad Salih (talk) 11:40, 18 March 2024 (UTC)[reply]
I think people will support a new main page design as soon as they're shown a new main page design that they like. I would encourage people who are so inclined to create and share mockups of new main page designs. Eventually someone will make something that enough people like. Levivich (talk) 17:16, 20 February 2024 (UTC)[reply]
BTW my 2c: make the main page, en.wikipedia.org, look much more like www.wikipedia.org: a minimalist interface, with a prominent search bar, to which I'd add prominent display of TFA and FP. Like maybe FP centered at the top, search bar below that, and TFA below that. But I'm no web designer though so I'm not sure exactly how that should all look. Levivich (talk) 17:21, 20 February 2024 (UTC)[reply]
This, but for WikiProjects, which are largely bland and uninviting. This is something I've felt for a long time, but have just now worked up the courage to say... so be nice. heh. (but isn't it obvious?) Stefen Towers among the rest!Gab • Gruntwerk 07:15, 6 March 2024 (UTC)[reply]
What do you mean by a wikiproject redesign? Aaron Liu (talk) 12:34, 6 March 2024 (UTC)[reply]
Is it possible to have, say, the current main page visible to users with the Vector legacy skin, but a main page similar to eswiki's for Vector 2022 users? This way we could keep up the "modern" look for Vector 2022, but keep the "legacy" style for Vector legacy. I just don't know if this is technologically feasible. Relativity 03:06, 19 February 2024 (UTC)[reply]
The current main page has no problems to view in Vector 2022. That said, it should be possible with CSS selectors. Aaron Liu (talk) 03:35, 19 February 2024 (UTC)[reply]
I am dubious Why? No clear argument for why this would be desirable. Can we be sure it would not lower general accessibility depending on the device being used to access the site? I am not adamantly opposed to sprucing things up a bit. But the oft quoted adage "if it aint broke, don't fix it," definitely comes to mind. -Ad Orientem (talk) 04:43, 19 February 2024 (UTC)[reply]
I think where previous proposals have failed before is in trying to do many changes at the same time (e.g. changing the emphasis of different parts of the main page while also restyling it). Anyways I have a modest proposal, under the principal that less is more and that the boxes around everything is the most dated part of the main page, at User:Galobtter/sandbox/Main page. It could do more work from someone who actually knows how to design (I like ptwiki's main page header a lot and that could be incorporated), but all I did was basically remove unnecessary (imo) styling. Galobtter (talk) 06:13, 19 February 2024 (UTC)[reply]
Hey, I like that! Zanahary (talk) 06:34, 19 February 2024 (UTC)[reply]
I like that! It's simpler but clearer. Although something seems a little off with the header box, the lack of border makes it feel poorly-defined to me. 🌺 Cremastra (talk) 13:45, 19 February 2024 (UTC)[reply]
I like it, but I think the margins around each section need to be a little more generous if there are no borders. --Ahecht (TALK PAGE) 15:17, 19 February 2024 (UTC)[reply]
I also like this. While we're at it, maybe align DYK with On this day Aaron Liu (talk) 16:26, 19 February 2024 (UTC)[reply]
That's done manually by admins each day since aligning depends on how much content is in each of the sections. Galobtter (talk) 23:17, 19 February 2024 (UTC)[reply]
Can't we add padding to the bottom of TFA, like ptwiki seems to do? Also the manual alignment doesn't seem to be working for me Aaron Liu (talk) 23:47, 19 February 2024 (UTC)[reply]
I like a lot of that, but (at least on Desktop on MonoBook) the colored section headers only seem to have a thin border on the bottom and nothing on the other 3 sides. Much better than the es.wiki one linked above, which is visually clean but seems to lack any sort of flavor. The WordsmithTalk to me 16:42, 19 February 2024 (UTC)[reply]
I think the border's supposed to be like the heading's border. I believe that whatever we think about the rest of it, we should adopt the first box of the eswiki/ruwiki main page. Aaron Liu (talk) 16:52, 19 February 2024 (UTC)[reply]
colored section headers only seem to have a thin border on the bottom and nothing on the other 3 sides is intentional - I wanted to have a simple header style rather than having an unnecessary box around the headers. Yeah, I liked ptwiki's a lot more than eswiki's, which is probably technically the "best" in terms of modernization but is too bland. Galobtter (talk) 23:17, 19 February 2024 (UTC)[reply]
My proposal would be to change the boxes to a very light gray and then remove the border. 71.239.86.150 (talk) 18:20, 19 February 2024 (UTC)[reply]
@Ahecht I added 1px of margin, which was missing since I removed the 1px border. It looks ok to me now, although you might be right that more margin is needed. @User:Cremastra I stole the box shadow from ptwiki - what do you think now?
I want to avoid doing more with this, since I think that's where previous proposals have failed - people want some of the changes but not others so it ends up a whole mess. And since at least some people seem to like this, I might try to put it up for RfC soon, but want to make sure there aren't small tweaks needed to what I've done. Galobtter (talk) 00:24, 20 February 2024 (UTC)[reply]
I'd support it at the RfC stage, but unfortunately I doubt it would pass. 🌺 Cremastra (talk) 00:40, 20 February 2024 (UTC)[reply]
Another idea would be to use light gray rounded rectangles, because rounded rectangles are a very common part of modern web design. 71.239.86.150 (talk) 13:47, 20 February 2024 (UTC)[reply]
Yes they're common but Wikipedia and mw:Codex, our design language, never use them. That would be completely alien to the rest of the encyclopedia. Aaron Liu (talk) 14:43, 20 February 2024 (UTC)[reply]
I have a visceral dislike for rounded rectangles, possibly because they are now so prevalent. 🌺 Cremastra (talk) 20:49, 20 February 2024 (UTC)[reply]
Probably, yes it is time, however the problem is not to change the design, it is how to herd the cats without them canabalizing themselves. —TheDJ (talk • contribs) 21:14, 20 February 2024 (UTC)[reply]
What is that graphic metaphor supposed to mean? Aaron Liu (talk) 22:26, 20 February 2024 (UTC)[reply]
When you try to get a lot of people to make a decision together, they often spend more time attacking each other than they do collectively moving in any productive direction, if I understood the metaphor correctly. Levivich (talk) 23:15, 20 February 2024 (UTC)[reply]
What's needed is a brainstorming RfC process like is currently being done for RfA. This gives an opportunity for a variety of ideas to be suggested and we can then see what sticks. For example, I'm most interested in structural change -- amending the section order and content so that the featured picture and ITN swap places so that ITN can expand coverage of its recent death entries. Issues like this can't be resolved by the editors who maintain the individual sections and so an overall mainpage forum is needed. Andrew🐉(talk) 09:33, 21 February 2024 (UTC)[reply]
I don't think expanding coverage of RD entries is needed much, and the POTD often needs a dedicated row due to its image size. We're currently kinda designing some layouts, so a more formal workshopping process should begin when we have more proposals. Aaron Liu (talk) 16:01, 21 February 2024 (UTC)[reply]
That would be wasting a lot of space. Aaron Liu (talk) 20:06, 21 February 2024 (UTC)[reply]
No, that would be allowing the text and images to spread across the screen instead of being cramped into tiny corners. --User:Khajidha (talk) (contributions) 20:19, 21 February 2024 (UTC)[reply]
Why would we need all the text and images to spread across the screen? They don't gain anything from being wider. Aaron Liu (talk) 20:41, 21 February 2024 (UTC)[reply]
You don't think that a larger image and prose that isn't chopped into tiny sections that resemble the old "See spot. See Spot run. Run, Spot, run." children's books would be useful?--User:Khajidha (talk) (contributions) 01:51, 23 February 2024 (UTC)[reply]
As I don't have a childhood,[Joke] I'm not sure what you're talking about. We do not have an overabundance of blurbs, blurb words, recent deaths or DYK hooks. Besides size limitations, there's a reason newspapers separate every single article into columns. Aaron Liu (talk) 01:59, 23 February 2024 (UTC)[reply]
As a mobile user, I quite like the one-column design. QuicoleJR (talk) 18:41, 3 March 2024 (UTC)[reply]
The most popular view or Wikipedia is the mobile one and that's already one column. We should therefore be designing and optimising for that as the primary interface. The balance issue is absurd in that it often causes ITN admins to remove news entries -- form rather than function. Andrew🐉(talk) 20:31, 22 February 2024 (UTC)[reply]
Remind me what happened the last time a bunch of editors thought Wikipedia was optimizing for the mobile view. Aaron Liu (talk) 20:36, 22 February 2024 (UTC)[reply]
The most popular editing view for Wikipedia is desktop, not mobile. Alienating the site’s most essential users is a serious risk to take. If there had been no way to revert the Vector 2022 and recent line height changes, I would have been strongly alienated from Wiki and contributed way less. Zanahary (talk) 23:58, 22 February 2024 (UTC)[reply]
Most editors are not allowed to edit the main page and so we have a frozen format which is alienating too. What's needed is a process for making changes which allows the main page to evolve. Perhaps there could be an annual update. During the year, there would be a beta test version to trial proposals and then a confirmation and release process at the end of each annual cycle. Andrew🐉(talk) 09:37, 23 February 2024 (UTC)[reply]
I don't think we'd need to change the main page every year. Aaron Liu (talk) 14:00, 23 February 2024 (UTC)[reply]
I agree. Maybe changing every 3 years would be a better idea. 71.239.86.150 (talk) 21:34, 24 February 2024 (UTC)[reply]
I feel like we should only change it if we should, not force a change every 3 years. Aaron Liu (talk) 21:45, 24 February 2024 (UTC)[reply]
I think we'd need to establish a list of a couple potential designs, and start an official RfC Cocobb8 (💬 talk • ✏️ contribs) 13:49, 18 March 2024 (UTC)[reply]
An RfC which would unfortunately fail. 🌺 Cremastra (talk) 19:46, 18 March 2024 (UTC)[reply]
@Cremastra Not necessarily, there's quite a few people in this thread who would support that idea. That's also what the purpose of an RfC is: gather consensus, and if it is a quick-fail, so be it. What do others think? Cocobb8 (💬 talk • ✏️ contribs) 19:49, 18 March 2024 (UTC)[reply]
At least your (and Galobtter's) small upgrade would probably pass. Aaron Liu (talk) 20:03, 18 March 2024 (UTC)[reply]
Option 2 at the least, as proposer. The current state of affairs does not seem like a good thing. Isn't automatically revealing more private information on XTools unsavoury at the very least? Users should at the minimum have the right to restrict more private data such as the timecards from appearing in the XTools analysis. As SlimVirgin wrote during a 2014 discussion on the issue, Even though the information is in theory publicly available, presenting it in this format is still a privacy issue. (Just because we all walk down the street doesn't mean we'd want CCTV cameras joining up our activities and someone posting it online.)🌺 Cremastra (talk) 20:10, 19 February 2024 (UTC)[reply]
Option 1 The data in question is not private to begin with, and never was. This does nothing but create privacy theater. * Pppery *it has begun... 20:13, 19 February 2024 (UTC)[reply]
Option 1 I do not think users should have any expectation that information extractable from WP logs won't be compiled, and would argue that allowing them to is (mildly) against WP:5P3Mach61 (talk) 20:21, 19 February 2024 (UTC)[reply]
Option 1 per Pppery. This doesn't qualify as "private information". InfiniteNexus (talk) 20:21, 19 February 2024 (UTC)[reply]
Option 2. Option 3.Option 2.5. As I understand it, the devs only allow opting out of three areas: timecard, monthly counts, and top edits by namespace. My !vote is to require users to affirmatively opt-in for timecard and monthly counts, but not top edits by namespace, which should not allow an opt-out. I agree with @Cremastra and @SlimVirgin. When you're editing on Wikipedia isn't private information per se, since anyone can take a look at someone's edit history. However, an easy-to-use tool that lets someone know when you're generally online and making edits can pose security risks (e.g., it can show when you're usually home and usually not at home; similarly, monthly counts can show what months you're generally on vacation or away from home). Regarding @Mach61's point that users should [not] have any expectation that information extractable from WP logs won't be compiled, the only tool that currently does that compiling is XTools, and I doubt someone would go through the headache of creating, hosting, and maintaining a new tool in the event that en-wiki users are allowed to opt out. This should be disabled by default because new editors won't know that it exists, and anyone who knows enough to know that XTools exists would know how to opt in if they choose. voorts (talk/contributions) 20:44, 19 February 2024 (UTC), changed !vote 20:49, 19 February 2024 (UTC) and again 21:08, 19 February 2024 (UTC)[reply]
I doubt someone would go through the headache of creating, hosting, and maintaining a new tool in the event that en-wiki users are allowed to opt out. It's quite simple to write a quarry query doing all of this - it wouldn't look as nice, but the information would be there. BilledMammal (talk) 21:44, 19 February 2024 (UTC)[reply]
Sure, but how many people know how to do quarry queries or will take the time to learn how to do so? voorts (talk/contributions) 22:25, 19 February 2024 (UTC)[reply]
There are many tools. In addition to Quarry, there's Apache's Superset, or the PAWS JupyterHub deployment (where you can work in your preferred language), or you can go thru an API e.g. Wikimedia REST API. Or if you prefer to work in your own environment using VSCode or whatever, you can talk to the databases remotely via ssh (you'll need a Wikimedia developer account and Toolforge membership). The database schema diagram is quite handy. Sean.hoyland (talk) 09:01, 7 March 2024 (UTC)[reply]
There already is at least one other tool that shows timecards and monthly counts (wikichecker), and I'm pretty sure that creating a new version of the xtools edit counter tool would be relatively trivial, since the source code is freely available. Firefangledfeathers (talk / contribs) 23:27, 19 February 2024 (UTC)[reply]
Fair enough. Xtools is fairly integrated into Wikipedia though, so I think removing that option creates an extra step for potentially malicious people to poke around. voorts (talk/contributions) 23:30, 19 February 2024 (UTC)[reply]
Option 1.5 - Mostly agree with Pppery and Mach61. Edits are public and transparent. If someone wants to gather our public edits and make a neat tool to show patterns in those edits, that's generally a good thing IMO. What's more, we have no real say, because we already agree to make edits on a public, transparent, free, and open wiki. It's 100% up to the developers what they want to do, and an RfC about opt-in/opt-out is really just a request. If the devs honor it, anyone else could just fork it and host the same thing elsewhere. For the most part, I don't think the devs should allow opt-out. Again, it's all public information and the tool is frequently useful. The only argument I find myself sympathetic with is the one about timecards per SlimVirgin/Cremastra. Although I just finished talking about how it's all public and up to the devs, to take it to an extreme, I think this community wouldn't take kindly to developers of a tool that, for example, processed the entire text of a user's contributions to produce a profile guessing at their real life identity. In short, if you run an RfC, be sure to separate the timecard from everything else or you'll get a bunch of people like me who sortakinda think the timecard should have an opt-out, but would oppose a blanket question. — Rhododendritestalk \\ 21:00, 19 February 2024 (UTC)[reply]
Along the SlimVirgin/Cremasta line of reasoning, let me toss out another way edit timestamps might leak personal information. Lets say I looked at all your timestamps and observed that near the end of every week, you abruptly stop editing at a specific time, and pick up again 24 hours later. I might guess that those are the times of sunset where you live and thus surmise that you're an observant Jew/Muslim/etc, who stops editing on the sabbath. Other editing gaps around major religious holidays might confirm my guess. A few minutes with an almanac could narrow your location down to a few cities where sunset happens at those times over the course of a year. That's quite a bit of information just from looking at your timestamps.
If I've figured out that you're an observant Jew who lives in New York, I've narrowed you down to maybe a million people. On the other hand, if I've figured out that you're an observant Jew who lives in the Falkland Islands, according to Jewish population by country, there's only one of you, so I've got you nailed. RoySmith(talk) 22:33, 20 February 2024 (UTC)[reply]
Comment - The info page on xtools says Your wiki should have had a local discussion showing consensus for these statistics to be allowed. Did that discussion ever happen, and if so when? If not, then en wiki needs to go back to hiding that info until that discussion happens (which would be this topic if/when it becomes an RFC). RudolfRed (talk) 21:09, 19 February 2024 (UTC)[reply]
Option 1 Your edit history is always publicly available and visible to anyone and everyone, and pretending otherwise is at best ineffective and at worst misleading and harmful to the transparency that Wikipedia tries to support. Even allowing opt-out for timecards is potentially harmful, as it gives the false impression that users can hide PII such as the times they are active. Finally, it seems somewhat silly to have all this handwringing about XTools when completely unaffiliated sites such as https://en.wikichecker.com/ exist. --Ahecht (TALK PAGE) 21:11, 19 February 2024 (UTC)[reply]
Option 2.5 (My !vote is to require users to affirmatively opt-in for timecard and monthly counts, but not top edits by namespace, which should not allow an opt-out. -- voorts) What harm can one do with someone's edit count and top edits? I can see an argument against time cards and monthly edits. Someone could always try to create a tool to replicate these functions in order to act maliciously, but there's no reason for us to facilitate their aims by providing a tool to do this.Sincerely, Novo TapeMy Talk Page 21:17, 19 February 2024 (UTC)Option 1 per Novem Linguæ below. Sincerely, Novo TapeMy Talk Page 18:12, 1 March 2024 (UTC)[reply]
Why are the time cards implemented in the first place? What purpose do they serve? 🌺 Cremastra (talk) 21:25, 19 February 2024 (UTC)[reply]
Several purposes: they can help users in identifying sockpuppets, they can can help visualize when a user is likely to be active if you're waiting for feedback from them, and they can help make it obvious to editors that such an analysis is possible and that it is something they should be aware of if they are trying to keep their anonyminity. --Ahecht (TALK PAGE) 21:36, 19 February 2024 (UTC)[reply]
Option 1; scrutiny protects both the encyclopaedia and the user. Allowing some users to opt out would allow maleficent users to evade / delay proper scrutiny. If some editors' editing patterns are available, then all editors' editing patterns should be available. This data is not private like one's medical records or finances. Having said that, a warning to editors, say in the edit window, might not go amiss. The principle is simple; if you don't want your editing patterns available to all and sundry for scrutiny, then do not edit Wikipedia. Baffle☿gab 21:30, 19 February 2024 (UTC)[reply]
Scrutiny such as what? In what circumstance would the timecards serve a demonstrable purpose? 🌺 Cremastra (talk) 21:32, 19 February 2024 (UTC)[reply]
One use is to help identify sockpuppets. BilledMammal (talk) 21:33, 19 February 2024 (UTC)[reply]
Option 1; this won't improve privacy, all it will do is gate-keep it - more technically minded users will still be able to access it, while less technically minded users won't. I don't think that is a productive division. BilledMammal (talk) 21:33, 19 February 2024 (UTC)[reply]
Option 3, per North8000. I hadn't considered non-editors accessing and using this information; to reduce the potential harm caused by outing, having a technical barrier in place is a good idea. BilledMammal (talk) 21:48, 19 February 2024 (UTC)[reply]
Security through obscurity is a bad thing, and in this case it's not even that obscure since sites like https://en.wikichecker.com/ exist. --Ahecht (TALK PAGE) 22:09, 19 February 2024 (UTC)[reply]
The timecard should go. I see no reason for this data to be aggregated like this - what legitimate purpose does it serve? But the others, I see legitimate uses for them, and I don't see any good reason to allow opt-out. I think opt-out would possibly be harmful as mentioned by some responses above (ie, that it would make people think their edits are more private than they are). We've already given up that kind of privacy by editing here in the first place. -- asilvering (talk) 21:34, 19 February 2024 (UTC)[reply]
Comment Aside from all-important anonymity, Wikipedia is the most privacy-violating website that there is. It it a very easy convenient publicly searchable database of every edit that the editor ever made including the exact date and time that they made it. And there isn't a simple line between public and non public. Degree and ease of public access is important. Scratching your butt on your front lawn is technically public, as is your name and address, but if I take a telephoto video of you doing it and have it put on television and make a permanent searchable youtube video of it, I'm changing the degree of privacy and can't just say that I'm not because it's all public already. For example, if somebody outs you, anybody with no expertise can just click "edit count" can prepare a study on you in 30 seconds on how much editing you did when you were supposed to be at work and give it to your boss. I think that protecting anonymity is far more important than this proposed change, but I think that the proposed change is also a good idea. North8000 (talk) 21:44, 19 February 2024 (UTC)[reply]
Option 1. The privacy of editors is important, but we need to balance this against our goal of making an encyclopedia, which requires a degree of transparency in order to track sockpuppets and malicious editors; failing at that doesn't just hurt our mission, it has the potential to cause real-world harm even to people who haven't edited the encyclopedia, either because of BLP issues or because of harm caused when they try to rely on it. On the balance, these things are not a high privacy interest for most editors, while they are extremely valuable for identifying sockpuppets and COI editors. --Aquillion (talk) 22:02, 19 February 2024 (UTC)[reply]
No, those are not even remotely close. When you suspect that someone might be a sock of a previous user and are trying to build a case for SPI (or whether you even should attempt to do so), comparing the users' time cards is an extremely valuable way to get an initial at-a-glance sniff test. It doesn't prove anything on its own, ofc, but it allows you to avoid wasting time on editors that are clearly and obviously distinct. Editor interactions are far less valuable for this because it's natural for editors with overlapping interests to edit the same articles, and because it is easier for a sock trying to evade detection to move to another article than it is for them to change the entire times at which they edit over an extended period of time. And of course combining the two can provide enough information to tell you whether it's worth digging into their edits for more specific similarities. Losing access to time cards would make it far more difficult for editors who hunt sockpuppets to perform an initial pass to rule out possible sockmasters, while providing a "privacy" benefit that is purely symbolic at best. --Aquillion (talk) 13:09, 21 February 2024 (UTC)[reply]
Option 1. Status quo. The information proposed to be obfuscated doesn't seem particularly dangerous to me except maybe the timecard, and the timecard is an important tool for sock hunters. –Novem Linguae (talk) 22:53, 19 February 2024 (UTC)[reply]
Option 1. This is silly. It's all public information, and absolutely nothing is stopping me from forking xtools and/or developing a similar service and running it out of my personal website. -Fastily 01:23, 20 February 2024 (UTC)[reply]
Option 1 I don't see the privacy concerns with monthly counts or edits by namespace, and these are very often used by e.g. people at PERM/RfA evaluating a someone's activity and where they spend their time editing. The timecard is more concerning, but is used to find socks, and so it is useful that way; but I wouldn't necessarily be opposed to the "option 2.5" suggested above. Galobtter (talk) 01:28, 20 February 2024 (UTC)[reply]
Option 4 don't allow opt-out, but only let CUs see it, for privacy reasons. Just because something can be done doesn't mean it should be. Levivich (talk) 04:24, 20 February 2024 (UTC)[reply]
Option 1. The data is public, will remain public even if you were to opt out and even if you did opt out on Xtools it could be compiled and displayed in the exact same way by some other tool. Pretending editors can opt out from this would therefore be misleading. Thryduulf (talk) 05:19, 20 February 2024 (UTC)[reply]
New option 5 Allow only users that are not on Special:ActiveUsers to opt-out.
I tried using the en.wikichecker.org tool to look up an user that has agreed to it, and got an html code 403, so the argument of it being possible to view this aggregated data elsewhere is still moot. Might be an EU issue. I have never used timecards as an admin on an smaller wikipedia for my entire time of serving as one, which is over an decade, so I reject the argument of timecards being useful for moderation. As for timecards being useful for communication, just use some patience, volunteers do not owe you to respond within the hour.--Snævar (talk) 10:51, 20 February 2024 (UTC)[reply]
WikiChecker does that sometimes. Usually refreshing the page gets it to load correctly without the 403 error. It's probably a CDN issue. --Ahecht (TALK PAGE) 14:38, 20 February 2024 (UTC)[reply]
Option 1 with the strong reminder that no private information about editors is available in this tool at all. — xaosfluxTalk 11:34, 20 February 2024 (UTC)[reply]
Option 2. Allow users to opt out if they want - it should only be up to them and it's the kind of situation where giving the choice doesn't really hurt anyone. But because we are only speaking of publicly accessible info, GDPR isn't implicated so I don't particularly care either way. Szmenderowiecki (talk) 11:37, 20 February 2024 (UTC)[reply]
Option 1: basically per Pppery and Ahecht. The data is already publicly available for all and can be easily accessed by an external source (and one such platform is mentioned above). JavaHurricane 12:46, 20 February 2024 (UTC)[reply]
Option 1 and the RfC question is misleading. XTools does not show any private information. the wub"?!" 13:29, 20 February 2024 (UTC)[reply]
Option 1 I reject the premise in the heading. The times editors make their contributions are public information and there's no reasonable expectation they ought to be private. As others have outlined, there are many legitimate reasons to audit a user's pattern of editing – detecting sockpuppets, evaluating RfA candidates, and working out when you can expect them to respond to a question. – Teratix₵ 14:46, 20 February 2024 (UTC)[reply]
Option 1. I disagree that hiding timecards gives a false sense of security. Making it less accessible does mean fewer people are likely to see it, and I hope that doing so would be widely-accepted as still being possible to view. That being said, I strongly disagree with the idea that publicly showing XTools data should be opt-in. I also disagree that there should be an opt-out. There may be an opportunity for the XTools maintainers to remove timecards publicly, and our checkusers given an internal tool for timecards. SWinxy (talk) 19:57, 20 February 2024 (UTC)[reply]
There's already another tool which provides timecard information: https://spi-tools.toolforge.org/spi/ (which I maintain). It's integrated into the SPI toolset, but there's nothing to stop people from running it as a stand-alone tool. XTools presents the data in a nice U/I, but the basic functionality is trivial to implement, so making XTools opt-in would be meaningless. RoySmith(talk) 20:23, 20 February 2024 (UTC)[reply]
Option 1 The data is public and apparently easy to recreate. Now, I could get behind encouragement to only allow logged-in editors access x-tools, but that is a separate question. --Enos733 (talk) 20:43, 20 February 2024 (UTC)[reply]
Option 1 The data is public and anyone can aggregate it to show the same. To pretend otherwise is security through obscurity and just encourages people to have a fake sense of safety. —TheDJ (talk • contribs) 21:18, 20 February 2024 (UTC)[reply]
Option 1 the data is public; I do not think this is a privacy issue. LEPRICAVARK (talk) 03:03, 21 February 2024 (UTC)[reply]
Option 2 though it wouldn't be my ideal formulation (which would be to have a public opt-in version and a no-opt-out version accessible only to particular rights-holders). I seem to recall opining in the opposite direction when the same question was raised several years ago but my view has changed due to a factor strangely absent from this discussion: volunteers' experiences of harassment. Even though the information is all public and can be collated with some technical knowledge, reducing the ease of access of information would limit or prevent certain types of harassment and violence against volunteers. It is worth noting that privacy of a volunteer can reduce rather than increase when they create an account, as many IP addresses are not highly sensitive to that individual but the pattern of their editing behaviour is. I'm reluctant to spell out more per WP:BEANS. — Bilorv (talk) 22:26, 22 February 2024 (UTC)[reply]
Option 1 - this is all publicly available information that could just be compiled by someone self-hosting the tool to ignore opt-outs. a false idea of privacy is arguably more harmful than the status quo. Rexo (talk | contributions) 15:44, 3 March 2024 (UTC)[reply]
How trivial would it actually be to self-host the tool, though? As it is everyone on the planet with a Web browser has all those analytics their fingertips.
Option 2 with opt-in for time cards The fact that there’s no opt out combined with the fact that this is not clearly and visibly disclosed to editors (hell, maybe there should be a disclaimer in the edit window itself with the licensing and all that blah blah) is a bit shocking to a reasonable observer coming from the context of internet anonymity expectations. The amount of data that sometimes be extrapolated from a time card is concerning.
Regarding monthly edit counts, I think it needs to be balanced against the value of that info in many cases.
Option 1 - because the other options have no actual impact on privacy. XTools does not include any private information because it does not have access to private information. It talks to the database replicas, sanitized versions of the production databases that have had private information redacted. There aren't degrees of privacy in the information it accesses and presents via the website and the API. All of the information is equally public. The choices available to people are largely captured by Wikipedia:Why create an account?. People can choose to expose or not expose their IP address, they can choose an account name that is or is not related to their real name, they can choose to reveal or not reveal personal information on their user page or in interactions with other users, and so on. Sean.hoyland (talk) 06:57, 9 March 2024 (UTC)[reply]
Option 1 The information is publicly available and the tool could be recreated by someone at any time if they wished. Matt Deres (talk) 21:14, 9 March 2024 (UTC)[reply]
Proposal: Implement a community-based process for appointing CheckUsers and Oversighters
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.A summary of the conclusions reached follows.
WP:SNOW, there's a clear consensus against this being a good idea. Galobtter (talk) 02:24, 11 March 2024 (UTC)[reply]
I propose that we implement a community-based process for appointing CheckUsers and Oversighters similar to how RFAs are run. Because these positions require a high degree of community trust, I believe consensus should be higher like in appointing bureaucrats and interface administrators. I believe in this way, the community has more of a say of who gets to be a CU and OS other than our current arbitrators who currently hold those positions. I would also be open to saying with arbitration approval. Interstellarity (talk) 13:57, 26 February 2024 (UTC)[reply]
(Moral Support) I'd love arbcom to be out of the CUOS business, primarily so that we can focus on putting people on the committee primarily on the strength of their dispute management skills. — xaosfluxTalk 15:42, 26 February 2024 (UTC)[reply]
It might be good to take something off of ArbCom's plate. ArbCom has many responsibilities. SWinxy (talk) 17:42, 26 February 2024 (UTC)[reply]
ARBCOM were elected on the basis that this would be one of their responsibilities. They can tell us if they think they've got too much on their plate. Phil Bridger (talk) 19:46, 26 February 2024 (UTC)[reply]
Arbcoms tell us this year after year through their very slow action. Levivich (talk) 15:17, 27 February 2024 (UTC)[reply]
If you look at what proposals come out of the committee to increase their productivity, they are almost always about streamlining case management and especially dealing with appeals. That none of them relate to CU or OS appointments should give you a clue that it's really not a significant aspect of their workload. Over the last five years, functionaries have been asked by arbitrators to evaluate 26 candidates for CU and 16 for OS (people applying for both tools are included in both counts), This is not a large burden. Thryduulf (talk) 15:27, 27 February 2024 (UTC)[reply]
Per nom and above, and also the arbcom appointment process has generated too many false positives. Levivich (talk) 15:07, 27 February 2024 (UTC)[reply]
Please can you give some examples of these "many false positives" and explain how a different process would have produced a different outcome. Thryduulf (talk) 15:18, 27 February 2024 (UTC)[reply]
That is an inappropriate question and you're old enough to know that Thryd. No, I'm not going to name the CUs/OSs who I think shouldn't have been appointed over the years. But for starters, the ones who were suspended or removed from those positions would be good examples.
Arbcom elections and RFAs have also produced false positives, in fairness, but I think RFA has produced the fewest false positives (proportionately) of the three systems.
But you really should be ashamed for asking for names. I'll give you one name: yours. That's not nice but neither is what you just asked me. Levivich (talk) 15:30, 27 February 2024 (UTC)[reply]
OK, that wasn't a well phrased question. I was trying to understand what you meant by "false positive" (which you've now made clear means people who were appointed who you think should not have been) and importantly why you think an RFA-like process would have produced a different result. I will also follow-up your answer regarding me by asking why you feel I was/am a "false positive"? Thryduulf (talk) 15:43, 27 February 2024 (UTC)[reply]
You know what I meant by "false positive": that people were appointed who shouldn't have been. You're not confused about that. What you are asking is for me to substantiate the claim, which is an inappropriate question, because it would require naming names.
I never said I think an rfa-like process would produce a better result. The proposal is for a community based process, not an rfa-like one. I think rfa is terrible, hence my voting in favor of various reforms, consistently for years. I said I thought rfa produced fewer false positives (for rfa), but that's not the same thing as saying an rfa-like process would produce fewer false positives for CU/OS appointments. I don't know if it would or wouldn't.
But I'm in favor of trying a community based system because it might be better than the current system. In general, I think community-based systems work better than representative-based systems on Wikipedia. ANI works better than AE. RFA for all its problems yields better results on average than arbcom CU/OS appointments (calculate the #-removed-per-#-selected ratio and you'll see a much higher % of CU/OS appointments are reversed than the % of RFA passes who are later desysoped, even though both are extremely rare).
As for you personally, not really the place to discuss that nor a topic I care to spend time on, but for example this line of questioning was a poor choice. Levivich (talk) 16:02, 27 February 2024 (UTC)[reply]
ANI works better than AE if this is your opinion, then I think I understand why we feel so differently about this issue. From my perspective, AE is a very significantly better board (for the situations where they overlap) than is ANI, which vies with RFA for the title of worst venue on the project. Thryduulf (talk) 16:50, 27 February 2024 (UTC)[reply]
@Thryduulf: I'm sorry for personalizing this discussion with my earlier comments. I thought by personalizing this discussion I could make a point about not naming names and personalizing the discussion, but that was a dumb idea on my part in retrospect, my apologies. Levivich (talk) 05:29, 28 February 2024 (UTC)[reply]
Oppose (CU and OS appointments)
I see no current problem with ArbCom selecting them, and this has the slightly greater risk of granting the power to the wrong people. Moreover, it could lead to a flood of premature self-nominations. Aaron Liu (talk) 14:11, 26 February 2024 (UTC)[reply]
I don't think there's a shortage right now? Mach61 (talk) 14:58, 26 February 2024 (UTC)[reply]
lol, that's a page about redirects. You're looking for the WP:AINT essay. Levivich (talk) 15:09, 27 February 2024 (UTC)[reply]
The last year in which CUOS were selected by the community (it has been done before) was a disaster for providing the relevant privileges. Izno (talk) 16:21, 26 February 2024 (UTC)[reply]
The one from 15 years ago? That wasn't really a direct community process. It started with arbcom being able to veto any candidate and was then advisory in nature only. 15 years is a long time in the project, I'm not sure we should discard an idea based on such an old example. There are certainly things that can be learned from it - along with years of experience in how many other projects have been able to run CUOS elections themselves. — xaosfluxTalk 18:04, 26 February 2024 (UTC)[reply]
The current process is that applications, which are accepted at any time, are scrutinised by ARBCOM, those that cannot be dismissed out of hand are passed to the functionaries to for scrutiny. Based on the feedback from functionaries and arbitrators' own discussions, applications that are clearly unsuitable are closed as unsuccessful, community input is sought for all the others. All the comments (arbs, functionaries, community) are then evaluated by arbcom and the successful applicants appointed. An RFA-like process would lead to mostly the same people being appointed as now, just with a greater likelihood of acrimony, incivility, and clearly inappropriate nominations and an increased risk of untrustworthy people being appointed. I'm not clear what problem this is attempting to solve. Thryduulf (talk) 18:07, 26 February 2024 (UTC)[reply]
If that summary is correct (and I have no reason to doubt it) then it sounds like an ideal way to appoint people to those positions. Certainly better than any RFA-like process. Let's remember that ARBCOM is elected by popular vote. Phil Bridger (talk) 19:40, 26 February 2024 (UTC)[reply]
Mostly - except that that is the general "routine" process, arbcom also can just appoint anyone they want if they pass with a 50%+1 committee vote (we see this the most when there is a request from a former funct.) — xaosfluxTalk 22:02, 26 February 2024 (UTC)[reply]
This is equivalent to former admins regaining the tools on request as long as at least one 'crat is happy to flip the bit. The only difference is that there is no written activity requirement to be regranted CU/OS (although there is to retain the tools). Thryduulf (talk) 22:33, 26 February 2024 (UTC)[reply]
That process is also generally done in secret without requiring an opportunity for community feedback. — xaosfluxTalk 14:17, 27 February 2024 (UTC)[reply]
That the two are essentially the same was my point. Thryduulf (talk) 14:41, 27 February 2024 (UTC)[reply]
Thryduulf gives a good summary. I don't currently suspect that the CU/OS system we have is appointing the wrong people, and RfA is exceedingly toxic. — Bilorv (talk) 18:45, 26 February 2024 (UTC)[reply]
Oppose. I'm uneasy about making people go through the fiery pits of hell thrice total if they want CUOS. That aside, my bigger concern is the wider community's ability to judge whether someone is trustworthy enough to handle private information. CUOS isn't admin or crat, they're specific roles used to fulfill specific purposes. They carry no "social" value (no accountability requirements, etc.), and if someone who hasn't held an NDA role before asks for it, the whole thing basically boils down to "will this person invade upon privacy or leak personal information?". I sure as hell cannot answer that question. Can you?...yeah, you probably can, because you've probably been here for 15 years or something. But you are not the only demographic that goes to RfX, and with this system it won't be any different.If the problem is that you want arbcom out of the way, then sure, I could potentially get behind that. But experienced, non-temperamental people need to make this decision, not the RfA mob. Snowmanonahoe (talk·contribs·typos) 00:45, 27 February 2024 (UTC)[reply]
Oppose as I said in the RFA 2024 review @ proposal 15. I dare not to repeat the same statement. Toadette(Let's discuss together!) 07:28, 27 February 2024 (UTC)[reply]
Oppose What is the problem that has to be solved? The present RfA-process is quite a bit of mud slinging, so it only decreases the number of able & willing candidates. The Bannertalk 08:53, 27 February 2024 (UTC)[reply]
Oppose per above. Solution in search of a problem, nothing is broken. -Fastily 09:51, 27 February 2024 (UTC)[reply]
The last attempt at community-based CUOS appointments was a total failure, and the current system is more than good enough. JavaHurricane 13:37, 27 February 2024 (UTC)[reply]
Previous attempts to try this have descended into a popularity contest and produced no useful feedback about the candidates' suitability for these specific roles. These roles do not necessarily need popular editors who avoid sticking their heads above the parapet for fear of not being elected, but trustworthy, active admins who know how to use the tools and deal with abuse within the bounds of policy. ArbCom appointments with community consultation strikes the right balance in my opinion. HJ Mitchell | Penny for your thoughts? 14:13, 27 February 2024 (UTC)[reply]
Oppose A very sensitive position (including being able to do real life harm to people) which has very specific proven-trust requirements. I'm more comfortable with some experienced (elected) people making that analysis and decision. Sincerely, North8000 (talk) 15:23, 27 February 2024 (UTC)[reply]
Oppose A process "similar to how RFAs are run"? Good God, no. Also, per HJ Mitchell.-- Ponyobons mots 19:40, 27 February 2024 (UTC)[reply]
Not only is the current system not broken, the community as a whole is very poorly placed to judge an admin's skill at handling those areas that are mostly directly relevant to CUOS skills; revision deletion, SPI activity, deletion-related activity at RC patrol, VTRS activity, and more technical areas like edit-filter work. Non-admins cannot scrutinize most of this activity at all. While trust and judgement are important aspects of being a functionary, there's more to it than that. Community scrutiny is necessary but not sufficient, and the current system of the community being able to provide feedback is exactly what it should be. Vanamonde93 (talk) 19:45, 27 February 2024 (UTC)[reply]
This seems to be a solution in search of a problem. SeraphimbladeTalk to me 20:07, 27 February 2024 (UTC)[reply]
Arbcom managing this seems to be working well, and producing both enough permission holders to get the work done but not spreading access too widely. Arbcom is exceedingly unlikely to appoint any person the community expresses a decent amount of reservation in, and is aware of things the community is not that may make an individual unsuitable. Courcelles (talk) 16:35, 28 February 2024 (UTC)[reply]
RfA is a broken process as it is, leading in part to a shortage of admins. Doing the same for CUOS without improving the RfA process is asking for trouble, not in the least because CUOS deals with way more sensitive data and the community as a whole is ill equipped to assess trustworthiness. ConcurrentState (talk) 18:58, 28 February 2024 (UTC)[reply]
In discussions about the low number of applicants for functionary permissions in the 2023 round it was noted that the shortage of new administrators was likely an influential factor. RFA's brokenness is the most significant reason for the shortage of new administrators. Thryduulf (talk) 15:05, 29 February 2024 (UTC)[reply]
I don’t disagree in the slightest. I was just hedging to avoid nitpicking about all the possible factors that lead to a shortage of admins. ConcurrentState (talk) 19:28, 29 February 2024 (UTC)[reply]
I was actually agreeing with you, just noting a downstream problem of the one you identified. Thryduulf (talk) 20:13, 29 February 2024 (UTC)[reply]
Ah! My bad, I misinterpreted your comment. ConcurrentState (talk) 21:35, 29 February 2024 (UTC)[reply]
Solution in search of a problem. Sandstein 14:55, 29 February 2024 (UTC)[reply]
In agreement with Sandstein. TrangaBellam (talk) 18:17, 29 February 2024 (UTC)[reply]
The process often requires considerable privacy. ArbCom may have to learn, or deal with, very personal information of potential CUOS. An RfA like process is incapable of handling such sensitive issues. We already ask for community feedback for candidates. Why would we want more RfA, when RfA is concededly broken? (case in point: the concurrently running RfA RfC). If it ain't broke, don't fix it. CaptainEekEdits Ho Cap'n!⚓ 05:14, 1 March 2024 (UTC)[reply]
Appears to be a solution looking for a problem. Stifle (talk) 10:22, 1 March 2024 (UTC)[reply]
RfA, while it might be the only method we've come up with for selecting administrators, is not such a glorious success that we ought to be using it as a model for anything else, at least not when the current system is perfectly functional. And there are substantial differences between CU / OS and admins - adminship involves a large number of often very subjective judgments on things like eg. whether someone is likely to continue to be a problem in the future and what sanctions are necessary to prevent this. CU / OS, by comparison, are much more rigid and technical - there is a bit of subjectivity around the edges, but not nearly so much, and it mostly comes down to very simple categorizing using a few straightforward rules. This means that while judgment is important for those roles it doesn't imply as much need for additional community trust. Admins need to understand, and be trusted to accurately enforce, essentially all of Wikipedia's policies and practices; CU / OS are each mostly about a much more narrow slice of it, and a slice that generally involves a bit less subjectivity at that. --Aquillion (talk) 00:46, 2 March 2024 (UTC)[reply]
Have to be honest, but I think this is backwards in terms of how much trust is required. Admin actions can be and are scrutinized easily and regularly, that can't happen in the same way with CU/OS. OS is maybe straightforward in the way you describe though the information involved can be as sensitive as can be. CU, on the otherhand, is far from categorizing a few straightforward rules. There is a huge amount of discretion involved and judgement calls are regularly required in terms of whether a check has been justified and if it has whether the results indicate a violation of policies and guidelines. I also think most admins only operate in a narrow slice of the admin universe so they don't actually need to know every policy and guideline. Best, Barkeep49 (talk) 00:56, 2 March 2024 (UTC)[reply]
RfA has serious problems and I don't think we want to replicate them to other processes. The current system for CU and OS appointments seems to work well, and allows adequate community feedback. the wub"?!" 16:55, 3 March 2024 (UTC)[reply]
Oppose - CU and OS are both high-trust roles with real-world legal implications, with access to advanced tools to manage very sensitive information, which can do serious real-world harm to real persons and the project itself if they are misused. They are chosen by a committee which understands the purpose of the roles and evaluates individuals' aptitude and suitability for them, as well as whether or not a candidate fills an identified need. The community elects that committee, Arbcom, and community input is part of the appointment process. Making these specialized positions open to general election puts us at fairly serious risk from motivated malicious groups wanting access to the politically valuable information available; frankly it's already too much of a risk IMO that Arbcom members gain access to these tools through election. Ivanvector (Talk/Edits) 17:11, 4 March 2024 (UTC)[reply]
Oppose These roles have real-world legal effects and are required to sign an NDA. We definitely shouldn't elect them by popular vote. The current system works just fine. QuicoleJR (talk) 21:43, 7 March 2024 (UTC)[reply]
Oppose per Thryduulf finding only 42 CU/OS evaluations over the past five years, suggesting that the current system poses a minimal burden on ArbCom while avoiding the toxicity of RfA. BluePenguin18 🐧 ( 💬 ) 06:45, 8 March 2024 (UTC)[reply]
Oppose for the nth number of good reasons above, plus ArbCom just started essentially open instead of timed applications - which was the big step forward needed in this process. Lets give it a chance to work. -- Amanda (she/her) 02:09, 11 March 2024 (UTC)[reply]
Neutral (CU and OS appointments)
I'm indifferent at this point. Both systems appear to have their flaws and their benefits. voorts (talk/contributions) 15:55, 3 March 2024 (UTC)[reply]
So that would be 100 petition signatures and a majority on an up and down vote? I believe that is what it was on the vote that removed any remaining provision for an appeal to Jimbo.--Wehwalt (talk) 20:06, 26 February 2024 (UTC)[reply]
I didn't want to repeat the process since I linked to it, but mostly yes. An amendment can be also be proposed for ratification if it is approved by the committee. The majority vote to ratify must have at least 100 supporting statements. isaacl (talk) 20:38, 26 February 2024 (UTC)[reply]
Maybe ... while changing the arbcom policy requires those hoops, changing the cu/os polices don't really. This would really need to be well supported to make the change either way (with more than enough support to do both). — xaosfluxTalk 22:19, 26 February 2024 (UTC)[reply]
I think the wording in the current arbitration policy has given sole responsibility to the arbitration committee for appointment of checkusers and oversighters. I agree that meta:Oversight policy states that local elections can still be preferred over appointment by the arbitration committee, and it could be argued that meta:CheckUser policy leaves the question open. However by ratifying the arbitration policy, the community agreed on giving this responsibility to the arbitration committee, as well as agreeing that this scope has to be altered via the arbitration policy amendment process. isaacl (talk) 22:54, 26 February 2024 (UTC)[reply]
It could certainly create one of those community consensus crisis sort of situations. Regardless, I certainly would want a wholesale cleanup of everything related, including the arbpol, if this were to gain traction. Realistically, I think this proposal should have gone through more development and leaves more questions open then the change it is trying to promote. — xaosfluxTalk 23:11, 26 February 2024 (UTC)[reply]
I'm not sure if there would be a crisis. The stewards would have to ignore the English Wikipedia arbitration policy and accept community-requested assignments, and it doesn't seem to me that's likely to happen. I agree that it would have been fruitful to have more discussion to develop a rationale and proposed process. isaacl (talk) 23:24, 26 February 2024 (UTC)[reply]
I'm inclined to trust the steward when he says such a situation with the stewards would create a crisis. Perhaps it would be resolved the way you suspect but perhaps not. Best, Barkeep49 (talk) 23:07, 29 February 2024 (UTC)[reply]
In essence I agree with Xaosflux that the arbitration policy should be amended to align with community desires on appointing checkusers and oversighters. Thus I raised this need in my initial comment. In theory the arbitration committee could just agree to rubberstamp community appointments, but I think the community wouldn't feel satisfied by an approach that relied on the benevolence of the committee. isaacl (talk) 23:38, 29 February 2024 (UTC)[reply]
It would end up being a case if changing the local checkuser policy to allow elections were to be strongly supported by the community, and then there we to be an actual successful election - and how much of a counter argument the committee wanted to put up. This sort of change would certainly require a very well attended RFC for a project this size (where the supporters would likely already be over 100 as well). The best case would be that if successful a graceful transition from the current committee happened. I could see the stewards team stalling any appointment pending additional community deliberations over collisions between multiple policies. — xaosfluxTalk 23:39, 29 February 2024 (UTC)[reply]
Sure, that would be a reasonable approach. We might be thinking of different connotations for the word crisis. I agree that most likely there would be sufficient support to amend the arbitration policy at the same time. isaacl (talk) 00:03, 1 March 2024 (UTC)[reply]
Likely - it certainly wouldn't stop people from reading or creating articles! — xaosfluxTalk 00:11, 1 March 2024 (UTC)[reply]
This is a tangent, but if any of you are willing to take on these roles, please consider volunteering. I am worried that whenever m:IP masking/mw:Help:Temporary accounts gets here (not in the next few months, but could possibly be later this calendar year), that we might need more CUs than we have now, particularly during the first few months of the transition. WhatamIdoing (talk) 04:22, 27 February 2024 (UTC)[reply]
Another point that I don't think has been made is that, particularly for OS applicants, one thing that is often significant is what the requests they've submitted have been like as this can give an indication of what their judgement will be like in assessing requests from other people. For example I likely would not support an application from someone who frequently asked us to suppress things that clearly don't need it, and I likely would support someone whose reports were almost always of things that do need suppression. However, editors who are not oversighters do not have access to this information (indeed when oversight works perfectly almost nobody knows it has happened). Thryduulf (talk) 01:11, 2 March 2024 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Adding move, create and upload protection locks to the top right corner
Currently, articles that are protected from editing have the relevant lock in the top right hand corner. Userpages may not have the relevant edit lock on the top right. With regarding edit protection, it will stay as it is but why don't we do the same for move, create and upload so that articles (other than user pages) require all types of protection to be shown on the top right. The lock icon will display in the same way shown in the protection policy page (linked above). With move protection, the only way to tell that the page is protected is if the move button is not seen (this article for example, doesn't have the move button for me, but it does have subscribe) with the possible exception for administrators as they can move any page even if it's protected. Even if accounts are able to edit semi and EC protected pages, the relevant lock is still there. But like I said, that will not change. Admins will also be able to see if a page is move protected from the green lock icon at protection policy page.
The only way to see the green (move) and blue (create/also known as salting) lock is if the URL was typed for some reason, like here and here respectively. (for ECP create protection this appears instead). JuniperChill (talk) 21:40, 22 February 2024 (UTC)[reply]
Also, I forgot to realize most people (I think) replying to be are actually ECP, so please do not even try to recreate the linked page. I am not ECP myself (have ~260 edits). This is just an example of what it looks like for non ECP users to try and (re)create a salted page. You may wish to use an incognito tab to do so.
Support, though what's stopping us from doing this right now? Aaron Liu (talk) 16:03, 27 February 2024 (UTC)[reply]
{{Pp}} already supports move protection, it just needs admins to apply the template when they move protect a page. It cannot be used for create and upload protection as there is no page to put the template on. It might be possible to add the padlock icon to MediaWiki:Nocreatetext, but that seems redundant. --Ahecht (TALK PAGE) 20:12, 27 February 2024 (UTC)[reply]
Comment{{pp-move-indef}} hasn't displayed a visible icon since 2009 [1], and visible display for {{pp-move}} was removed following this TfD because participants saw it as unnecessary bloat. Personally I always found them a little useful, even though us unregistered types haven't been able to move pages for a long time since it was still a quick indicator that a title was potentially contentious, but I can understand why it was removed. 184.152.68.190 (talk) 20:52, 27 February 2024 (UTC)[reply]
I'm fine with a lock icon for creation-protected pages if technically feasible (obviously not by placing a lock template on the non-existent page). I'm also fine with an upload protection icon although almost all files are at Wikimedia Commons and we don't need to invest a lot of time into improving the display of the few remaining local image pages. A move protection icon, however, is an unneeded gimmick that is more likely to confuse readers than to help the few editors who intend to move the page. ~ ToBeFree (talk) 21:08, 27 February 2024 (UTC)[reply]
Displaying a lock for move-protected articles would confuse far more people than it would help, I agree with ToBeFree. I'm ambivalent about displaying a lock for the other two cases. Daniel Quinlan (talk) 08:24, 29 February 2024 (UTC)[reply]
Alternate proposal: What if we grayed out the move button and put a lock next to it? I agree with Daniel and ToBeFree that locking the edit button would be too confusing, but this could work if technically possible. QuicoleJR (talk) 21:40, 7 March 2024 (UTC)[reply]
IMO just greying it out would be enough. Putting an icon draws too much attention to it for an otherwise icon-barren menu. Aaron Liu (talk) 21:56, 7 March 2024 (UTC)[reply]
That is true. Greying it out would likely be enough. QuicoleJR (talk) 22:02, 7 March 2024 (UTC)[reply]
Erm, I said one comment above in support of just greying it out. I suppose this proposal would be a strong recommendation to the WMF to implement such a feature. Aaron Liu (talk) 19:45, 10 March 2024 (UTC)[reply]
Oops, sorry. I missed that when checking who I needed to ping. QuicoleJR (talk) 20:24, 10 March 2024 (UTC)[reply]
That might be alright but then thing is, if a page is (edit) protected, then the lock is still there, even if they are able to edit it themselves. So that is why I proposed a plan to introduce the green move icon lock in the top right to be shown to all. Again, like with edit locks, the move lock will be there for all, including unregistered users and admins. If a page is not move protected, then the lock will not show even to unregistered users despite the fact that unregistered users cannot move pages anyway.
In addition, the pending changes protection (check mark) and semi protection (user icon) are both grey with the semi protect lock being slightly darker so all could be grey, but I still prefer it to be green.
The reason I propose those changes is because they are shown in the relevant links but the non edit protection locks are barely used. It also tells users that the page is protected (the move option should be visible to admins if protected) With regarding salted pages (see red link example for an example), the lock could be displayed within the infobox or even the top right, or somewhere before the 'This page is protected from creation, so only administrators can create it'. JuniperChill (talk) 20:02, 10 March 2024 (UTC)[reply]
Actually, edit locks do not show up for users who can edit the article anyway, at least not on mobile. I have not seen them for EC-protected articles since I reached extended confirmed. QuicoleJR (talk) 20:26, 10 March 2024 (UTC)[reply]
Mobile shows no padlocks whatsoever. Not all anons are mobile users. Aaron Liu (talk) 20:27, 10 March 2024 (UTC)[reply]
That is not true, I still see the lock over the edit button when I go to, for example, Brianna Wu. The colors are all the same, but it is there. QuicoleJR (talk) 20:29, 10 March 2024 (UTC)[reply]
That's a different thing. I was talking about the standard padlock images. Aaron Liu (talk) 20:31, 10 March 2024 (UTC)[reply]
Oh, I see what you are talking about now. I think that the padlock would be a type of topicon, and those really should be visible on mobile. QuicoleJR (talk) 20:37, 10 March 2024 (UTC)[reply]
If a page is not move protected, then the lock will not show even to unregistered users despite the fact that unregistered users cannot move pages anyway.
Then what purpose would the lock serve? Why would we want anons to see them? I don't think this or "it's not used much" are valid reasons to use them.
I still prefer it to be green.
The color of the padlock would not change.
With regarding salted pages (see red link example for an example), the lock could be displayed within the infobox or even the top right
What do you mean by "infobox"? If we can add it, it'd be ideally where padlocks usually are. Aaron Liu (talk) 20:28, 10 March 2024 (UTC)[reply]
I proposed it so that users are able to see if the page is move protected or not, just like edit protected. With regarding salted pages, I meant to add, they would also be on the top right if at all possible, otherwise I suggested the alternatives.
And with someone requesting move locks at WP:US/R, I think they must have read this. JuniperChill (talk) 20:43, 10 March 2024 (UTC)[reply]
Why should someone who can't move any page anyways see if a page is move-protected? They can edit most of them, so edit padlocks are definitely needed. Aaron Liu (talk) 20:55, 10 March 2024 (UTC)[reply]
I think graying out the Move button is a bit dubious from a UX perspective. The warning on the Move page after clicking on the button is already quite clear. Trying to illustrate that a page is move protected prior to an attempt to move a move-protected page when it's such an uncommon occurrence seems to have very little if any benefit. The lock icons not being used often is a non-problem. And most users that want to move a move-protected page are going to click on the button regardless of the color. If you just want to gray it out for yourself, it would be possible to do that with some JavaScript that you could put into your common.js. Daniel Quinlan (talk) 20:44, 10 March 2024 (UTC)[reply]
Feedback sought for proposal to drop archival bot notice params from Template:Talk header
Your feedback would be appreciated at Template talk:Talk header#Proposal to drop archiving params. The {{Talk header}} template has no control over Talk page archiving, but it does have four params used to generate a "bot notice" in the header box which says something like: "Archiving: 90 days" (plus a tooltip with more info). It's just a string displayed in the header, which may or may not reflect what the actual archiving period is. A recent change to Template:Talk header automates the generation of this string directly from the archive config, rendering the four Talk header params unnecessary. Imho, they should be deleted from the template in order to prevent misleading bot notices in the Template header box when the given params get out of sync with the config. More details at the proposal discussion. Thanks, Mathglot (talk) 04:43, 29 February 2024 (UTC)[reply]
Template:Talk header is a highly visible template, so I've added {{subst:DNAU|3|weeks}} to this discussion to give it sufficient time to air. Mathglot (talk) 10:37, 3 March 2024 (UTC)[reply]
Proposal: Remove the topicons for good and featured articles
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.
WP:SNOW closing this proposal as a clear consensus to keep topicons for good and featured articles. I find it very unlikely that consensus will change from here given the overwhelming !vote to keep. (non-admin closure) JML1148(talk | contribs) 07:51, 10 March 2024 (UTC)[reply]
We recently rejected a proposal that would put the vital article topicon on the page. Discussion: Wikipedia_talk:Vital_articles/Archive_25#Proposal_for_a_VA_"top_icon". Some editors in that discussion said that they would support removing the good and featured article topicons as well. If either readers or editors are interested in whether they are good or featured articles, they can be found on the talk page. Interstellarity (talk) 00:30, 2 March 2024 (UTC)[reply]
Strongly support removing GA topicons. GA reviews are essentially random. It's just one editor reviewing it and there is literally no training or qualifications that the reviewing editor needs to have. To suggest a GA article has gone through any kind of meaningful review process is misleading the reader. All it means is someone else has read it. Exhibit A is the editor from a year and a half ago who had hundreds of GAs that turned out to be full of misinformation (and copyvio and other stuff, the editor ended up indef'd).
I'm neutral about removing FA topicons. At least that process can be said to involve multiple editors reviewing it, and the FA folks take their FA reviews pretty seriously AFAIK (unlike GAs, which some take seriously but others don't). I don't think it matters much if the FA topicon is there or not -- I don't think readers know or care about that -- but GA should definitely go IMO. Levivich (talk) 04:02, 2 March 2024 (UTC)[reply]
Actually, I support removing FA top icons too. I'd forgotten that most FAs no longer meet the criteria. Levivich (talk) 17:19, 2 March 2024 (UTC)[reply]
I support removing both. — Fourthords | =Λ= | 14:02, 2 March 2024 (UTC)[reply]
- due to the fact readers have no clue what these mean and the fact the majority no longer meet their FA and GA criteria and 60%+ are mobile viewers don't even see them anyways. I can see how they are an incentive to get editors to improve articles though. That said I would slow down on rfcs that will go nowhere..... Time wasters.Moxy- 16:50, 2 March 2024 (UTC)[reply]
Our loyalty is to the WP:READER, to whom these icons—where they're even noticed, that is (on mobile view they don't exist!)—are merely inside baseball. Their real purpose to allow editors a chance to gussify their user, talk pages etc. Stick em a table on a subpage if you have to :) ——Serial 16:58, 2 March 2024 (UTC)[reply]
As others have ably noted, these icons provide no discernible benefit to the reader. We would therefore better serve the reader by eliminating this visual noise. Frankly, we would probably do well to reconsider the centering of FA and GA work in general. The hundreds of hours it takes to nurse a single article through FAC would surely be better spent improving some of the millions of articles that have been substantially untouched for a decade or more. But in any event this would be a good step. -- Visviva (talk) 03:07, 4 March 2024 (UTC)[reply]
I don't think I've ever met a reader who knew we had FA topicons, let alone what they meant. —TheDJ (talk • contribs) 19:24, 4 March 2024 (UTC)[reply]
The icons are not for readers. The 2004 article ranking system devised in Wikipedia:Version 1.0 Editorial Team and still in use today needs revision to be practical. GA ranks are varying quality; FA ranks are easier to attain for less popular topics than highly read ones where they are most needed. Removing icons could be the start of recognizing that our quality reporting system is insufficient for meeting its objective. Bluerasberry (talk) 15:28, 6 March 2024 (UTC)[reply]
The top-icons lack context. I'm in favor of removing them or improving the top-icons to something that make more sense to readers. CactiStaccingCrane (talk) 16:31, 6 March 2024 (UTC)[reply]
Oppose (remove GA & FA topicons)
The topicons are useful for readers as indicators that an article has gone through some kind of review process. This is in contrast to vital articles which is editor facing information. Barkeep49 (talk) 00:40, 2 March 2024 (UTC)[reply]
I think all quality ratings should be shown, not just GA/FA. Analogous to maintenance tags, it's useful for readers to know how much they should trust what they're reading on Wikipedia. Moreover, topicons are unobtrusive and might have the benefit of converting a few readers to editors. As an aside, I think the distinction that's been drawn between quality ratings and vital article status is strained. Both are done through the work of a relatively small group of editors and both indicate something important to the reader about how the community has assessed an article. voorts (talk/contributions) 00:46, 2 March 2024 (UTC)[reply]
Why should a reader care about how vital wiki editors think an article is? The reader has their own ideas about how vital that article is to them in that moment and in general. The idea of showing all rating indicators is an interesting one in terms of helping readers clue into what they are. I'd love to see that discussed more. Best, Barkeep49 (talk) 00:49, 2 March 2024 (UTC)[reply]
By that logic, I think one could say: Why should a reader care about that one editor came to the conclusion that an article is GA quality and 5-10ish editors—none of whom are necessarily subject matter experts—came to the conclusion that an article is FA quality? I'll make a note to return to the topic of showing all ratings after this discussion closes. voorts (talk/contributions) 00:55, 2 March 2024 (UTC)[reply]
I've had a similar thought before myself, but I've come to believe that in practice, the distinction between Start/C/B-class is often too poorly defined to be useful information to the reader. —Compassionate727(T·C) 15:34, 2 March 2024 (UTC)[reply]
This is how I think about the distinctions: start is longer than a stub, but either not very well-cited or written, C is a start class article that's starting to meet some core PAGs, and for B we have clear criteria. voorts (talk/contributions) 20:41, 2 March 2024 (UTC)[reply]
Plus from my experience it is often not kept up to date as the article content changes. ― novov(tc) 01:58, 3 March 2024 (UTC)[reply]
Oppose. The topicons are useful, and have been this way for a long time. What exactly is the advantage of removing them? –Novem Linguae (talk) 00:50, 2 March 2024 (UTC)[reply]
Per Barkeep. I'm not sure how valuable fronting the lower ratings would be (they're often out of step with the quality of the article) but I'm not immediately opposed to adding them. Thryduulf (talk) 01:14, 2 March 2024 (UTC)[reply]
Oppose: It's good to show readers in an unobtrusive way that the article they're reading has been reviewed and is of quality. There is no benefit to removing them. 🌺 Cremastra (talk) 01:59, 2 March 2024 (UTC)[reply]
Oppose: per Barkeep, however, the GA topicon was a bit confusing to me when I was only a reader and I wouldn't mind a reform. ❤HistoryTheorist❤ 02:36, 2 March 2024 (UTC)[reply]
Why? I think it's a convenient way to show that articles are of a decent quality to our readers. It's not causing any problems. Elli (talk | contribs) 03:51, 2 March 2024 (UTC)[reply]
Oppose per Barkeep49. Headbomb {t · c · p · b} 04:19, 2 March 2024 (UTC)[reply]
Oppose: GA and FA symbols are no guarantee of any kind of quality, but it is one piece of information that media literate readers should be using to help them assess the reliability of what they read. These topicons may also be motivating to editors who put articles they have improved through GA/FA processes. — Bilorv (talk) 09:41, 2 March 2024 (UTC)[reply]
Oppose per all the opposers, but I'm mainly here to comment: I consider it a win that no one has even mentioned featured lists in this discussion or the previous one. The process basically works, and judging from the silence, it doesn't seem to be contentious these days. Congratulations all around. - Dank (push to talk) 15:32, 2 March 2024 (UTC)[reply]
Featured lists should undoubtedly follow featured articles in this regard. If any decision is ever made to change or remove the FA icon, featured lists should get the same result. Animal lover|666| 16:38, 4 March 2024 (UTC)[reply]
The topicons are what first informed me of the GA and FA processes back when I was an unregistered lurker. I can imagine other unregistered users falling down a rabbit hole and potentially getting involved with curating content after seeing one of them. Also Barkeep49 presents another good rationale for keeping them. The Night Watch(talk) 17:22, 2 March 2024 (UTC)[reply]
Oppose We need to make them more prominent, not less. Sohom (talk) 17:35, 2 March 2024 (UTC)[reply]
Oppose per Barkeep and Bilorv. Moreover, just because mobile readers are unable to see them it does not mean we should remove them from PC readers (if anything it means that we should add them to mobile view). Spy-cicle💥 Talk? 17:43, 2 March 2024 (UTC)[reply]
Oppose per Spy-cicle. – SD0001 (talk) 21:48, 2 March 2024 (UTC)[reply]
Oppose, per Barkeep and Bilorv. ♠PMC♠ (talk) 00:02, 3 March 2024 (UTC)[reply]
Oppose Like voorts, I would not object to all ratings being shown. In fact, I use a plugin that does just that. Hawkeye7(discuss) 00:51, 3 March 2024 (UTC)[reply]
I use the same plugin, which is where the idea came from. voorts (talk/contributions) 00:59, 3 March 2024 (UTC)[reply]
Oppose - I agree with Levivich that the quality of the GA process can be inconsistent, but in practice I still find that they are almost always better than your average non-good article. Yes there can be stuff like what Doug Coldwell did, but the same goes for every other part and process of Wikipedia. Most readers aren't likely to grasp what the means anyway, in my mind it serves as more of a motivational little trinket for editors, and I'm concerned that removing the most prominent area where it's featured could decrease the impetus to improve content. ― novov(tc) 01:57, 3 March 2024 (UTC)[reply]
Not clear what the harm is, and if the only benefit is making people feel good about getting an article to GA/FA (by having a shiny icon on the article) that seems enough. Galobtter (talk) 01:58, 3 March 2024 (UTC)[reply]
Oppose. The provided rationale is extremely unconvincing - "some people mentioned it?" Lay out the case yourself if you believe it. Marking quality is fine (which is what FA / GA icons do), the problem with VA marking was - too many to list, see previous discussions. This proposal comes across as an extremely weak "well this one proposal was voted down, let's do the same thing in a separate vaguely similar area out of some misguided fairness." SnowFire (talk) 02:27, 3 March 2024 (UTC)[reply]
@Voorts: The statement is expected to be neutral, yes. However, somewhere (whether in a separate section after the description, or in the nominator's initial !vote) there's expected to be some reasoning for why the heck we're voting on this at all and some sort of case to modify the status quo. The RFC creator gave no such explanation other than what I already cited that "other people mentioned it" and "readers can find out on the talk page" which is not conversant at all with the issues involved. People could propose random changes all day; why is this change being proposed? You shouldn't start an RFC as just a thought experiment, that's what a normal discussion is for. SnowFire (talk) 05:15, 3 March 2024 (UTC)[reply]
Oppose: Not causing any harm, and is a nice bit of encouragement for editors. ARandomName123 (talk)Ping me! 02:46, 3 March 2024 (UTC)[reply]
Oppose If my GA/FA articles didn't get the topicon, I rather doubt I'd have even known they existed, or felt compelled to get my articles to that status. The badge is useful to readers, and a great inducement for editors. CaptainEekEdits Ho Cap'n!⚓ 03:26, 3 March 2024 (UTC)[reply]
Oppose, mostly per voorts. We should show more of this, not less; readers deserve to know if an article has passed some quality gate. On the topic of substandard GA/FAs, yes they exist, no we shouldn't let perfect be the enemy of good. ~ A412talk! 04:24, 3 March 2024 (UTC)[reply]
Oppose. This does not really seem like a good idea to me; if there's a bunch of crappy GAs we do not need to address topicons to deal with them. jp×g🗯️ 06:07, 3 March 2024 (UTC)[reply]
Oppose. I would prefer we go in the opposite direction and make the icons more visible and more intuitive. Readers will not know which one is more "trusted". —Femke 🐦 (talk) 07:48, 3 March 2024 (UTC)[reply]
Oppose - Nothing wrong in letting readers know which articles are trusted and have underwent community review. The Herald (Benison) (talk) 09:14, 3 March 2024 (UTC)[reply]
also noting that I will support introducing FA and GA topicons to mobile and apps, but not supporting the entire removal of the badges. Toadette(Let's discuss together!) 16:58, 3 March 2024 (UTC)[reply]
Oppose. Do not see any positive from this action. On the contrary, will be some amount of value subtraction (if that is even a term). Ktin (talk) 17:49, 3 March 2024 (UTC)[reply]
Oppose The great majority of Wikipedia's readers are unaware that there is a quality scale. Indicators of article quality need to be more visible, not less. MartinPoulter (talk) 18:16, 3 March 2024 (UTC)[reply]
Oppose I'm piling on to say that FA and GA are very important tools for developing quality articles and qualifying articles should be highlighted. The icons are also a learning experience for anyone wanting to click them. Johnuniq (talk) 02:54, 4 March 2024 (UTC)[reply]
Strong oppose Might actually reduce the amount of FAs and GAs that will start coming out because there will be less motivation to do so. Relativity 05:31, 4 March 2024 (UTC)[reply]
Oppose The FA topicon linked to the first projectspace page I read. It probably contributed to me becoming an editor. Snowmanonahoe (talk·contribs·typos) 13:57, 4 March 2024 (UTC)[reply]
The proposal might be an argument for a double-check system for GAN's, but it isn't a reason to remove the topicons. They at least show articles that have been through some vetting. Courcelles (talk) 14:21, 4 March 2024 (UTC)[reply]
Oppose The icons are an extremely powerful motivator to get involved and improve Wikipedia. It only works because they are shown by default. I'm sure it would be trivial to squelch display with a script for an opt-out option. GreenC 16:41, 4 March 2024 (UTC)[reply]
Oppose - articles exist for the benefit of the readers, no tenth editors. A reader has no idea how good an article is without reading a significant part of it; how vital it is requires little more than a definition. There is no need to tell a reader how vital an article is; there is much more to tell the reader about the quality. Animal lover|666| 16:36, 4 March 2024 (UTC)[reply]
Oppose - FA/GA topicons highlight Wikipedia's best content in-place. Readers shouldn't have to go to a talk page or a list somewhere else to see that the content they're reading has been reviewed and is considered Wikipedia's finest, and there is benefit to distinguishing it from content that hasn't been through or has failed such a review. Ratings below that level are part of a content rating system that's been dead in the water for 20 years (though projects still use it) and there's no point in highlighting it for readers since there are practically no standards to the ratings, but if you want to see these ratings when reading articles anyway you can enable Wikipedia:Metadata gadget (Preferences > Gadgets > Appearance). Ivanvector (Talk/Edits) 17:26, 4 March 2024 (UTC)[reply]
Oppose These are meaningful, particularly FA. North8000 (talk) 17:28, 4 March 2024 (UTC)[reply]
Oppose. The indication that an article has had internal quality-control is very useful to a reader. Vanamonde93 (talk) 19:26, 4 March 2024 (UTC)[reply]
Adding: I fully acknowledge that both review processes have serious issues, but the average quality of a GA/FA far outstrips that of other articles. Vanamonde93 (talk) 19:29, 4 March 2024 (UTC)[reply]
Oppose. The topicons are an easy-to-find, yet also unobtrusive, way to indicate that an article has received (and passed) some level of vetting. The fact that they're visible in mainspace also means that they're relatively easy for readers to find and interpret as well, a benefit that would be lost (or at least reduced) if the indicators were kept confined to talk pages. (I also second the comments made by Barkeep, Bilorv, and The Night Watch.) ModernDayTrilobite (talk • contribs) 19:33, 4 March 2024 (UTC)[reply]
Oppose per Voorts. Acknowledging the lack of professionalism at WikiProject Good Articles, the icons at top mean something. I'd suggest Wikipedia:Metadata gadget should be "on" by default because the readers are not savvy enough. Chris Troutman (talk) 21:55, 4 March 2024 (UTC)[reply]
Strong oppose per the commenters above. These are not mere decorations; the icons signify that the GAs and FAs have undergone their respective quality control processes, and are thus helpful to the WP:READER. If GAs and FAs don't meet criteria, then WP:GAR and WP:FAR are that way. The reader may not know what they mean initially, but they'll certainly know if they click on them - the solution is to make it more obvious that the article has undergone a quality control process, not less so. There are some valid issues with the GAN and FAC processes, but they are in no way relevant to the use of topicons. Epicgenius (talk) 15:34, 5 March 2024 (UTC)[reply]
To add: I agree with Aaron Liu's rebuttal, below, as to the "randomness" of GA reviews. Any bad GAN review can be deleted, and any bad FAC/FLC review can be stricken through. My point is that the existence of bad reviews is not a good argument, in my view, for removing the topicons. – Epicgenius (talk) 00:07, 6 March 2024 (UTC)[reply]
Oppose. These icons bring more visibility to the assessment project, motivate editors, draw in readers, and are informative. Zanahary (talk) 16:52, 5 March 2024 (UTC)[reply]
FA/FL/GA is about quality while VA is about being on a list drawn up by a wikiproject --GuerilleroParlez Moi 21:06, 5 March 2024 (UTC)[reply]
FA/FL/GA are also a lkist drawn up by a project. The point is that they are about article quality whereas VA is a bout article importance. Hawkeye7(discuss) 22:53, 5 March 2024 (UTC)[reply]
Oppose: The usefulness of these icons is different than the possible usefulness of a vital articles topicon. Also not seeing an actual reason listed for why we would want to remove these. Hey man im josh (talk) 21:37, 5 March 2024 (UTC)[reply]
the majority no longer meet their FA and GA criteria
Then nominate them for delisting.
GA reviews are essentially random. It's just one editor reviewing it and there is literally no training or qualifications that the reviewing editor needs to have.
There are great guidelines for reviewing, and bad GA reviews can be overturned.
readers have no clue what these mean
I don't see any evidence of that, and having a tooltip and link seems obvious enough.
I don't think I've ever met a reader who knew we had FA topicons, let alone what they meant.
I don't think a reader knows what "topicons" are either. Aaron Liu (talk) 22:45, 5 March 2024 (UTC)[reply]
Oppose Useful indicators of top quality. Curbon7 (talk) 23:05, 5 March 2024 (UTC)[reply]
Piling on. Same reasons as Barkeep. — Rhododendritestalk \\ 00:18, 6 March 2024 (UTC)[reply]
Oppose per Barkeep, Bilorv, Epicgenius, Aaron Liu, and others. I don't see any point in removing topicons; I find them useful and evidently a lot of others do too. Even if readers don't care about them (which I haven't seen any good evidence of, just assumptions), they're helpful from an editor's point of view. If I see a blatantly terrible article with a little green icon on the top right, that catches my attention and makes me want to either send it to GAR or fix it up. sawyer * he/they * talk 02:16, 7 March 2024 (UTC)[reply]
As primarily a reader of Wikipedia, I find the GA/FA top icons to be useful information. Removing them would do some readers a disservice, and there is no advantage to removing them. Senior Captain Thrawn (talk) 03:41, 7 March 2024 (UTC)[reply]
Strongly oppose Opponents of the GA and FA topicons claim they are visual noise, yet they criticize the choice to not include them in mobile viewing as proof the review process is wasteful. While Levivich is correct that the peer review process can be hijacked by sockpuppeting, they present no evidence that this is widespread to convincingly argue the review process' collaborative editing is a net waste. While the GA and FA criteria are no different from the normal aims of article editing, the pursuit of specific quality metrics encourages greater compliance. BluePenguin18 🐧 ( 💬 ) 04:59, 8 March 2024 (UTC)[reply]
Oppose removal and Support addition of sitewide ratings for all mainspace articles and for all devices. The purpose of such a system is to indicate an article's quality to readers in advance, so they could anticipate whether an article is worth reading or not - or at least have a glimpse of what to expect. It's no different than rating systems for various things, like for movie, book, video game and music reviews. PantheonRadiance (talk) 06:10, 8 March 2024 (UTC)[reply]
Neutral (remove GA & FA topicons)
I suspect that the vast majority of our readers pay absolutely no attention to article ratings and their associated topicons. However, because I don’t think they harm the project in any way… I am neutral on the question. Blueboar (talk) 13:16, 2 March 2024 (UTC)[reply]
If it helps 1% of the readers, that should be a good enough reason to retain them, unless they actually harm the site or reduce it's quality, at least for some readers. If it's 100% neutral for 99% of the readers, this should not weaken the fact that it helps the other 1%. Animal lover|666| 16:41, 4 March 2024 (UTC)[reply]
I don't feel strong enough to sit on either side of this discussion. There are genuine grounds for concern about quality control and the ad hoc nature of the review process. It does seem that the topicons are very much inside baseball, so to speak. Nevertheless, despite the extreme example highlighted above (for which I have direct experience) I still think indicating some kind of independent review has taken place is worthwhile, no matter how limited in nature...I might have an easier time supporting this proposal if an alternative was being proposed. Regards, --Goldsztajn (talk) 01:36, 3 March 2024 (UTC)[reply]
Discussion (remove GA & FA topicons)
Barkeep49, as far as I know, we have no evidence that ordinary readers have any idea that those topicons exist or what they mean. WhatamIdoing (talk) 03:42, 2 March 2024 (UTC)[reply]
That's probably true. But that's a reason to improve them, not remove them. Sdkbtalk 07:04, 2 March 2024 (UTC)[reply]
We having no evidence for something doesn't necessarily mean it isn't true. Readers curious to find out the meaning of the icon would hover over it - it says "This is a featured article. Click here for more information". The click leads to WP:FA which begins with "Featured articles are considered to be some of the best articles Wikipedia has to offer". – SD0001 (talk) 07:54, 2 March 2024 (UTC)[reply]
The vast majority of readers don't see these anyways because they are not displayed in mobile view. Moxy- 17:18, 2 March 2024 (UTC)[reply]
We can actually figure out how many people click these. I've created Wikipedia:Good articles* and Wikipedia:Featured articles* and changed the links in the template accordingly, so after a month or so we should have good data on how many clicks these get. Elli (talk | contribs) 17:36, 2 March 2024 (UTC)[reply]
Great work....thank you! Moxy- 20:13, 2 March 2024 (UTC)[reply]
Related to this: I wonder what a reasonable comparison would be. (If it's 1,000 clicks, is that a lot or a little?) I wonder whether it could be compared against the Portal: links that used to be at the top of the Main Page. We could scale it for page views (which I think could be obtained through https://pageviews.wmcloud.org/massviews/ for the FAs and GAs). WhatamIdoing (talk) 22:05, 6 March 2024 (UTC)[reply]
I agree with Skdb. Best, Barkeep49 (talk) 08:16, 2 March 2024 (UTC)[reply]
I've nothing against the topicons; I'd be happy to keep them just because they're useful to experienced editors, a nice reward for hard work, and traditional for the site. However, I don't think we should be making this decision on the grounds that we speculate that they're useful to non-editing readers, when
we don't know that they're useful,
we have a limited amount of evidence suggesting that they're not (or that the utility is very limited), and
we know that most readers don't see them because 66% of page views are on the mobile site.
A month from now we will know whether those topicons get clicked on at any significant rate. WhatamIdoing (talk) 02:57, 3 March 2024 (UTC)[reply]
I have occasionally told people who have questions about whether/when Wikipedia articles are reliable to look for the topicons. —Compassionate727(T·C) 15:38, 2 March 2024 (UTC)[reply]
Question: how often are ratings/topicons reevaluated and lowered due to subsequent crappy edits? Blueboar (talk) 01:53, 3 March 2024 (UTC)[reply]
I think that a modified version of Wikipedia:Metadata gadget without the colored title text would make the most sense here. It shows the article assessment in an intuitive way and clearly indicate links for curious readers to read more about our assessment criteria. CactiStaccingCrane (talk) 16:35, 6 March 2024 (UTC)[reply]
I use and value that gadget. Also, I think it's Inside baseball (metaphor). Nobody except the tiny minority of high-volume Wikipedia editors cares about how we rate articles. Like: there are 8,000,000,000 people in the world, and maybe 8,000 of us care about the ratings. WhatamIdoing (talk) 22:02, 6 March 2024 (UTC)[reply]
On one hand, it's definitely an improvement over nothing, and should minimize confusion. On the other hand, topicons look better, and nobody might care enough anyways so that these who care would click on the icons to learn more... Aaron Liu (talk) 23:15, 6 March 2024 (UTC)[reply]
Many editors have stated that finding out about the GA/FA process has made them motivated to contribute to Wikipedia. I think the article ratings should be made more explicit to the reader, but if we can't bother to improve the top-icons, then we should get rid of it. CactiStaccingCrane (talk) 00:07, 7 March 2024 (UTC)[reply]
If we are going to remove an icon, I would hide the protection icons from logged out users (I don't see the benefit - they are anyways shown a "view source" button instead of "edit source" if they can't edit the article). That truly is inside baseball unless you actively try to edit an article. Galobtter (talk) 02:01, 3 March 2024 (UTC)[reply]
Any argument about reader understanding of topicons applies equally to page protection topicons. Anecdotally, some years ago, in a former life, I was observing a high school social studies class in the American Midwest and the teacher, as part of a lesson on research methods, told the class that the lock icon in the upper corner meant that it was vetted. We should be discussing how better to present this information for readers, not its removal. The 2023 GA proposal drive agreed to start an RFC for options on making GA status more prominent in mainspace. I've also been a big proponent of requesting Foundation staff to run user testing on some of our community design norms, i.e., banner blindness or in this case topicon literacy. I can track down those requests if useful. czar 13:57, 8 March 2024 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
New technology reference desk
The computing reference desk has a lot of questions not about computing. For example, there are a lot of questions about cell phones. I think there should be a reference desk about technology that isn't computing. Bubba73You talkin' to me? 00:22, 5 March 2024 (UTC)[reply]
I've never used the reference desks, but are there enough computing questions to justify the existence of both this new board and the current one? Seems like a better idea to just widen the scope. ― novov(tc) 04:43, 5 March 2024 (UTC)[reply]
I use and read the math and computing reference desks frequently, and sometimes science or others. I think that there is enough for both, but widening computing to technology would work. There are so many questions in computing that are help with phones and not about computing. Bubba73You talkin' to me? 23:19, 6 March 2024 (UTC)[reply]
That sounds like a reason not to do this. We don't want the Wikipedia:Reference desk to turn into a page for free tech support. WhatamIdoing (talk) 03:59, 7 March 2024 (UTC)[reply]
Well, right now there are two questions about cell phones on the computing reference desk. Bubba73You talkin' to me? 22:14, 7 March 2024 (UTC)[reply]
Why wasn't this brought up on the RefDesk talk page? Or mentioned there? The Computers and IT page says it is for "Computing, information technology, electronics, software, and hardware" which seems pretty broad already. And there's a miscellaneous desk for people confused about where a question should go. What exactly is the problem you seek to fix? Matt Deres (talk) 20:16, 8 March 2024 (UTC)[reply]
I'm pretty sure that it's possible, although that question would be better asked at WP:VPT. The more interesting question, that belongs here, is whether it is desirable. Phil Bridger (talk) 20:10, 6 March 2024 (UTC)[reply]
This new design is eye catching and could be more user friendly. Ktkvtsh (talk) 04:24, 7 March 2024 (UTC)[reply]
How about <div class=plainlinks>[https://en.wikipedia.org/w/index.php?title=Wikipedia:Sandbox&action=edit&preload=Template:Sandbox+reset&summary=Reset+sandbox&oldid=596189391 {{Clickable button 2 | '''Click here to reset the sandbox''' |link =no |color = blue}}]</div> which renders as
I think it is a good idea, and it seems more user-friendly. It draws more attention to itself, but I don't think that is a problem. QuicoleJR (talk) 19:46, 10 March 2024 (UTC)[reply]
Agree, I think it's better for users new to the sandbox to have it emphasized that you can reset it. Pksois23 (talk) 09:09, 15 March 2024 (UTC)[reply]
AI for WP guidelines/ policies
I propose following 2 things, either one or second.
Proposal 1: Create AI for Wikipedia by taking existing model and feeding it the guidelines and policies. This will make it easier to find relevant policy. Example: I ask AI for any policy regarding 'using notably' or 'words to watch' in articles, and it comes back with WP:EDITORIAL. There are already AI's like pdf readers, which you can feed on with pdf and ask questions on it.Make AI optimized search, for reasons that are struck(still valid) before.(Added on 18/3/24 by ExclusiveEditor)
Proposal 2: Proposal 1 + Giving AI more AI feel, by letting it become more than better search engine, by becoming suggestion judge for small situations. Example: You editors are creative, you may add one.
Note: AIs like SIDE seem to help, so will this which may be easier to build. But couldn't find discussion for one like this. The proposed proposals may be amended for better use. ExclusiveEditorNotify Me! 16:08, 7 March 2024 (UTC)[reply] (Note: AI is supposed to complement search)ExclusiveEditorNotify Me! 13:59, 18 March 2024 (UTC)[reply]
Re proposal 1, ChatGPT can already answer this question decently. Presumably its training data includes pages in the Wikipedia namespace. Barnards.tar.gz (talk) 16:17, 7 March 2024 (UTC)[reply]
@Barnards.tar.gz: ChatGPT requires email for registration. But it also has that 2021 bias, and couldn't list any policy/ guideline's specific article. ChatGPT is more like proposal 2, but that makes it erroneous. It's also third party, so it may not be fed with new ones and also combine non-wikipedia related data it is fed on with its response, which will make it even more erroneous. Proposal is to simply feed an AI on Wikipedian data only and program it to link specific policy it found the info on. ExclusiveEditorNotify Me! 16:25, 7 March 2024 (UTC)[reply]
Also, new data like various discussions going on ANI, Village pump, IANB etc. could be fed to AI so as to decrease discussions on already discussed topic, a user is not aware/ couldn't find about. Currently only search method is using Wikipedia search within specific category which could produce innumerable irrelevant matches, and there are numerous categories too. ExclusiveEditorNotify Me! 16:29, 7 March 2024 (UTC)[reply]
@Cremastra: I assumed that this shall help, or else I wouldn't have proposed it. We may not need it, but it's worth considering the potential advantages such an AI could bring, taking into account factors such as efficiency, accuracy, accessibility, and standardization all throughout Wikipedia it could bring with community's grace. ExclusiveEditorNotify Me! 09:41, 8 March 2024 (UTC)[reply]
Sounds like a solution looking for a problem. You only get familiar with current expectations by doing more editing. AwesomeAasim 01:23, 8 March 2024 (UTC)[reply]
@Awesome Aasim:WP:CHOICE. While practicing editing is important, AI tools can greatly enhance the editing process on Wikipedia by providing valuable assistance, improving accuracy, and streamlining search. They are designed to complement human editors, not replace them. ExclusiveEditor (talk) 10:09, 8 March 2024 (UTC)[reply]
No for several reasons. 1) We already have a search capability, as well as numerous other features like lists, disambiguation pages and redirect shortcuts to help guide users to find what they're looking for. 2) The risks of AI misinterpreting, hallucinating, or otherwise giving users inaccurate information about policy is non-trivial. 3) Because our policies are wiki articles themselves, they too are constantly evolving; without constantly updated training, the AI would forever be operating from an outdated understanding of what our policies actually are. 4) This is not really within the purview of a single project to pursue nor is it likely to gain broad consensus across a wide variety of projects and languages necessary to make it worth the effort and cost. The scenario you're describing is better suited as part of the MediaWiki interface. 5) I suspect there are also non-trivial concerns about license compatibility as well as ensuring an open-source software/tools stack for this. 6) Where is this model going to be hosted? Who is paying for the compute time? The foundation? Some foundation-adjacent entity? Donations? A private research institution? There are too many unanswered questions and this proposal addresses none of them in a way that shows sufficient time and thought was put into making this a realistic suggestion. AI is not a "magic bullet" solution to problems that you haven't validated actually exist; nor that it is a product fit for what this community actually wants. ⇒SWATJesterShoot Blues, Tell VileRat! 04:26, 8 March 2024 (UTC)[reply]
The risks of AI misinterpreting, hallucinating, or otherwise giving users inaccurate information about policy is non-trivial. Is this referring to an AI generating freeform text, or referring a user to a certain page? I think that this program should probably be restricted to answering in links. I don't see a reason to believe the AI would consistently get that much wrong, or get it wrong more than a user. AI is not a "magic bullet" solution to problems that you haven't validated actually exist; Beyond a shadow of a doubt, people have trouble searching for policies and boards. Half the time I use Google Search. Overall, there seems to be unharnessed potential, which could make newbies stick around or make learning and navigating between policies, past and present, easier. - Mebigrouxboy (talk) 04:48, 8 March 2024 (UTC)[reply]
@Swatjester: 1) The stance is like 'We have candles, why need bulb?" The very reason I proposed this is that it is really difficult for a non-experienced user (even a mid-experienced user like me having 3000+ edits) to find relevant policy, and sometimes not sure if there exists any for it even with the legacy tools. To be clear, there are numerous similar policy pages, and it is difficult to find out where the exact guideline is located and it takes lot of time if not hours finding one. Also even, forums avoid/ aren't sure of such questions as they themselves find it hard to locate sometime (not sure).
2) As of now, i go with what Mebigrouxboy says.
3) That's the other primary reason I am proposing this. Assuming that a constantly evolving policy may make the "AI" old, seems like saying editors have super power of going though entire policy updates within less time AI is updated. AI may help editors know what updates are in guidelines.
4) This is just a tool. I may be wrong, but it is not even a major update like enforcing new vector design on IP editors/ readers. Just a sidebar for easy searching, and policy updates will do it.
5) Wikipedia itself would not have got the success, if it was not launched due to such considerations. Solving the problems is necessary to establish anything.
6) I am not considering myself eligible to answer questions related to financial side, as it dependent on what the community and foundation decides and how this proposal evolves. ExclusiveEditor (talk) 10:02, 8 March 2024 (UTC)[reply]
If we're going to use that analogy, your suggestion is like switching from candles to incandescent bulbs, without having addressed why the lighting difference matters, what type of lamp we're going to use, whether the power grid can support it, and who's going to pay for the electric bill. I stand by all of my points -- your idea is incomplete, premature, and lacking sufficient detail or information to be executed on even if there was consensus that it was desirable. You can't simply handwave away critical considerations like "who's going to pay for this" and "is this compatible with our open-licenses and our mission" as trivialities that we'll figure out later. That kind of techbro fastspeak won't fly here. We are the 7th most popular website in the world; even small changes here can have drastic impacts on millions of people. The burden is on you to show that you've actually given the serious consideration and planning due for a change that would affect people in that magnitude. Until then, you don't have a proposal; you have a fantasy. ⇒SWATJesterShoot Blues, Tell VileRat! 15:35, 8 March 2024 (UTC)[reply]
@Swatjester: I presented my ideas here (on proposal) as conjectures, indicating that they are open to improvement and further development. This allows for collaboration and the exchange of ideas among editors. The proposed proposals may be amended for better use. Also I believe that just because I did not elaborate every problem we may face with this, doesn't make it useless, and it could further be developed. However, I assume your point to make sense, and would like to further detail my proposals. And yes, we are one of the most visited website, so we should not be stagnant with the influx of improvement we are capable of. ExclusiveEditor (talk) 17:28, 8 March 2024 (UTC)[reply]
An AI that can instantly forward you to the correct venue for a dispute, find help pages for any question, or search the archives of boards, and other capabilities mentioned above would be a massive benefit to editor QoL. A proof of concept might be possible by creating a custom GPT on the ChatGPT store. - Mebigrouxboy (talk) 04:24, 8 March 2024 (UTC)[reply]
I agree, this would be nice. Since training / fine-tuning AIs on volatile user-provided data is a hot area of research and product development at the moment, I don't think it would be a wise use of Wikipedia funds to get involved just yet. It feels like we would just be duplicating work that is being done elsewhere. At the current pace of development, I would expect that production-ready open source systems that do this are not far off. Barnards.tar.gz (talk) 11:03, 8 March 2024 (UTC)[reply]
Support. It could really help finding policies when you forget the name or just don't know it. — Preceding unsigned comment added by Nononsense101 (talk • contribs) 16:27, 8 March 2024 (UTC)[reply]
This proposal is in essence about creating a better search tool. It could be a good project for a university computer science department. If you know anyone with appropriate connections, or any developers with available resources who might be interested, perhaps you can suggest it to them. isaacl (talk) 17:14, 8 March 2024 (UTC)[reply]
Yes, AI optimized search tool is the first and foremost thing I proposed. Other things can be discussed within the community. ExclusiveEditor (talk) 17:31, 8 March 2024 (UTC)[reply]
I think you need to first find people with appropriate experience and resources who can work on this type of project. This will allow them to engage in any discussions and thus guide them down more productive paths. isaacl (talk) 17:38, 8 March 2024 (UTC)[reply]
@Isaacl: Okay. Can you tell where could I search for such people who may have related experience? Thanks, ExclusiveEditor (talk) 17:46, 8 March 2024 (UTC)[reply]
Sean.hoyland gave one pointer above to a Wikimedia Foundation team that might be able to give some pointers or advice. You can also look at the foundation's pages to find other potential contacts. Think of everyone you know and if they have any related experience or connections to those who do, and if they might be receptive. isaacl (talk) 18:59, 8 March 2024 (UTC)[reply]
Support proposal 1. Happy to be invited to join this discussion. By way of introduction, I am a new editor who has done some deep diving into AI as well as algorithmic and data biases. As a newcomer, I can say that navigating Wikipedia's trove of policies and guidelines can feel very daunting. I’ve read posts in the Teahouse from new editors who say they feel paralyzed due to their fear of being criticized for doing the wrong thing or making mistakes. As such, being able to get easy access to policies would help to reduce policy breaches, support retention of new editors, and help create a “psychologically safer” environment for all editors. In my experience with AI and LLMs such as ChatGPT, they are very efficient when they are dealing with well-defined inputs for a request. A set of Wikipedia policies and guidelines would be an example of well-defined inputs. Generally, when LLMs stumble into "hallucinations", it tends to be when they are tasked with open-ended topics such as “blank sheet of paper” requests where they need to create something new with no prior input other than their own information. HerBauhaus (talk) 13:37, 17 March 2024 (UTC)[reply]
Oppose Feel like this is an unnecessary way to teach policy (and it's just asking for issues). We should avoid AI in general, and instead we should be improving new user onboarding so that we don't need this solution.Support AI in a very limited form
@Vghfr: Proposal 1 is AI- optimized search. Proposal 2 may better suit your oppose. Also the proposal 1 is not asking for issues as it is already evident from my and others(response above yours) experience that new wikipedians do face lot of issues when it comes to make even the slightest edits, and WP:CHOICE finally. We are not a company, but encyclopedia's community which should be not conservative in approach of helping Wikipedia's editor base growth in fears which make no sense.ExclusiveEditorNotify Me! 14:27, 18 March 2024 (UTC)[reply]
Sorry, got trigger-happy when I saw 'AI.' I could see it working if it was used as an addition to the search. Something similar to how Bing uses Copilot to summarize search results. We would just have to be careful. vghfr (✉ Talk) (✏ Contribs) 21:52, 18 March 2024 (UTC)[reply]
Strong Support - I'd find it so useful to find policies and guidelines, as long as the AI is only used for that and is not involved in anything else around Wikipedia. Cocobb8 (💬 talk • ✏️ contribs) 13:46, 18 March 2024 (UTC)[reply]
Absolutely not - The state of the art of AI does not have sufficient quality assurance to be able to operate in such an open-ended domain as Wikipedia policy and guidelines. This proposal is begging for trouble, and there is currently no time frame for when AI will reach this level of sophistication beyond a useless guess of "maybe in a few years at best". signed, Rosguilltalk 14:09, 18 March 2024 (UTC)[reply]
@Rosguill:No, I never deemed the proposal to be the way you are thinking, I myself may have opposed such proposal. I proposed for an AI optimized search for Wikipedia's policy and guidelines. There are lot of chatbots out there (including ones made on small budget) which could answer question based on web results in real time by 'searching' on internet, but the Wikipedia(AI-opt-search) work would be simpler even in term that it is just based on internal pages of just Wikipedia. In other words, right now Wikipedia's traditional search is 'Google', and I propose something like 'perplexity.ai' but much less sophisticated and easy to build. Also this would complement the search and may not be major change, it is proposal 2 which may suit your oppose. Regards, ExclusiveEditorNotify Me! 14:20, 18 March 2024 (UTC)[reply]
I have put some thought into this and I do think there could be merit for a tool to help new editors see their revision draft is violating a WP policy prior to submission. That isn't necessarily a "WP Policy chatbot" but probably something more akin to a spellchecker but for WP policy. If it could cause a new editor to fix their bad edit before another editor had to deal with it, it could make things better. That said, the model is only a small part of what would be needed to make this work, a bigger aspect would that the UI/UX that makes it seemless for a newer user while not annoying experienced editors (maybe make it opt in?). CAlbon (WMF) (talk) 15:57, 18 March 2024 (UTC)[reply]
@CAlbon (WMF): Maybe we could add that in 'beta features'. Proposal 2 or related would surely be more complex idea than 1, but it will increase the overall efficiency and quality of articles produced/ or edits. However 'AI' is the "popular" term so I used it, but the real solution would be to somehow reduce the pressure of getting 'edit wrong due to policy/ guideline' fear from new editors, because those who have such worries are the ones who are most dedicated. And it may surely ease the navigation process like gps did. ExclusiveEditorNotify Me! 16:10, 18 March 2024 (UTC)[reply]
Yeah, I do think helping new editors overcome the hurdle of their (and everyone's) first edits often being pretty rough. Structured Tasks can help with this, but the "policychecker" idea has merit, at least as an exploration. CAlbon (WMF) (talk) 16:51, 18 March 2024 (UTC)[reply]
Unnecessary – It'd be a big hassle for Wikipedia to implement such a proposal and, at least to me, seems like a pretty unnecessary thing to do, since there already are such third-party tools. If anyone wants to use them, they should feel free to do so (and accept responsibility for any error), like with any tool. I don't oppose the idea though, I just see it as another solution to a problem that already has (or is close to having) a solution. Gedditor (talk) 16:15, 18 March 2024 (UTC)[reply]
@Gedditor:Specifically proposed for new editors (and in extension can be used by others). Some newbies don't even know Wikimedia projects other than Wikipedia exist, being aware of third party tools seems improbable. I don't think hassle can be the reason to deny working on (discussion), which may result in at least a minor change which may make it a process easier (and yet efficient) to edit for Wikipedians. Also I don't think any 'third party tool' or any 'tool' is currently better than Wikipedia's own "search engine" which is not very effective, I very first proposed, and even if any exists, they mostly are highly unreliable. ExclusiveEditorNotify Me! 16:30, 18 March 2024 (UTC)[reply]
I don't think that things shouldn't be done because they are hard to do. I just personally think that it's not worth it. I'd say I'm neutral on this issue. If such a feature is implemented, good. If not, that's fine too. Just wanted to add my opinion here :) Gedditor (talk) 16:43, 18 March 2024 (UTC)[reply]
Reworking Sandbox Heading
Hello! I am requesting that {{sandbox heading}} be changed to this:
Proposed sandbox heading text
<center><big>'''Click on the "Edit this page" link above to experiment!'''</big></center><center><big>'''Please leave this heading alone'''</big></center> Welcome to the sandbox! Anybody can edit this page and it is automatically cleared regularly (anything you write will not remain indefinitely). You can either [[Special:EditPage/Wikipedia:Village pump (proposals)|edit]] the source code ("'''[//en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(proposals)&action=edit Edit source]'''" tab above) or use [[Wikipedia:VisualEditor|VisualEditor]] ("'''[//en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(proposals)&veaction=edit Edit]'''" tab above). Click the "'''Publish changes'''" button when finished. You can click "'''Show preview'''" to see a preview of your edits, or "'''Show changes'''" to see what you have changed. this page is cleared regularly, feel free to try your editing skills below. <span class="plainlinks clickbutton">[//en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(proposals)&action=edit&preload=Template:Sandbox+reset&summary=Reset+sandbox&oldid= <span class="mw-ui-button mw-ui-progressive">Click here to reset the sandbox.</span>]</span> If you are logged in, you can access your personal sandbox: "'''[//en.wikipedia.org/w/index.php?title=Special:Mypage/sandbox&action=edit&preload=Template:User_sandbox/preload Sandbox]'''". [[Wikipedia:Misuse of the sandbox|'''DO NOT''' place promotional, copyrighted, offensive, or libelous content]] in sandboxes.<span style="font-size:85%;">''For more info, see [[Help:My sandbox]]. New? See the [[Wikipedia:Contributing to Wikipedia|contributing to Wikipedia]] page or [[Help:Introduction|our tutorial]]. Questions? Try [[Wikipedia:Teahouse|the Teahouse]]!'' [[:Category:Wikipedia Editing Aids]]</span>
Yes, it should be changed to this version. 23.245.44.64 (talk) 18:34, 10 March 2024 (UTC)[reply]
Support. This makes the reset option more visible. It might make people pay less attention to the heading, but I doubt it. Sincerely, Novo TapeMy Talk Page 16:17, 11 March 2024 (UTC)[reply]
Please note that this is a discussion regarding whether Wikipedia should do this in the broad sense; detailed arguments like "I don't like the suggested banners" or "but we shouldn't promote [this project I don't like]" should be saved for later discussion. Please respond to the idea in the RfC statement.
Thank-you, 🌺 Cremastra (talk) 18:39, 15 March 2024 (UTC)[reply]
Sister Wikimedia projects have a lot to offer readers, and as one of the most viewed sites on the internet (globally!) we should help introduce readers to these resources. As you know, other Wikimedia projects include a dictionary/thesaurus which includes translations; a travel guide; a library of digitized public domain texts that anyone can download or distribute; a travel guide; a media repository; and many others. The sister project links are currently buried far down on the Main Page, and are especially distant for mobile viewers who make up an increasing share of our readership. Why would we not want to help readers discover some of the useful resources our sister projects have to offer?
No. Several of the 'sister projects' are worse than useless. At least one is run in a manner entirely contrary to the stated objectives of Wikipedia. We should not be encouraging them. AndyTheGrump (talk) 19:18, 15 March 2024 (UTC)[reply]
@AndyTheGrump: They're Wikimedia, not Wikipedia. This is the exact Wikipedia-is-the-best-and-most-important-project conceit I've been talking about. And I wonder which project you object to— Wikidata doesn't follow our notability guidelines, Wiktionary clearly violates WP:NOTDIC, Wikisource has no citations at all (!) Wikifunctions is just a bunch of code or something, Wikivoyage goes against WP:V and, to a degree, WP:NPOV… I could go on. Judging other projects by Wikipedian standards in nothing less than absurd. 🌺 Cremastra (talk) 19:39, 15 March 2024 (UTC)[reply]
I'd appreciate it if you didn't put words into my mouth. I am under no illusion that Wikipedia is 'the best' anything. It is however, the only online encyclopaedia that has any significant readership (thanks in no small part to Google), and is thus worthy of critical scrutiny. And I'm not judging the other projects by 'Wikipedian' standards, I'm judging them by the standards of someone who considers Wikipedia structurally flawed, even if its objectives are worthy in the abstract. The projects I refer to are in my opinion worse, in several ways, but mostly of little significance. AndyTheGrump (talk) 19:58, 15 March 2024 (UTC)[reply]
AndyTheGrump, could you please expand on how the projects are worse and the project that is run in a manner entirely contrary to the stated objectives of Wikipedia? — Frostly (talk) 21:14, 16 March 2024 (UTC)[reply]
At least one is run in a manner entirely contrary to the stated objectives of Wikipedia. Which project is it?
You first say that we should not encourage our sister Wikimedia projects because they go against Wikipedia objectives, and then you say that you aren't judging them by Wikipedian standards. I don't understand. 🌺 Cremastra (talk) 22:40, 15 March 2024 (UTC)[reply]
Is it your intention to get into long-winded discussions with everyone who participates here, or just the ones you disagree with? AndyTheGrump (talk) 23:11, 15 March 2024 (UTC)[reply]
Yes, provided it is limited to a few projects. Some of our projects are of limited interest to the average reader (Wikidata, Wikispecies and Wikifunctions) and others aren't in a state where it's worthwhile directing users to them (Wikinews). I think that such a campaign would be best served by a focused group of 3 or 4 of them that is more able to effectively direct attention their way. ― novov(tc) 02:32, 16 March 2024 (UTC)[reply]
Absolutely not. Banners steal our readers' attention. By distracting them and taking them off task, we slow down them learning what they're here to learn. Ads make people stupider. We should display as few as humanly possible for as little time as possible.—S MarshallT/C 02:37, 16 March 2024 (UTC)[reply]
No for the same reason I don't like banner ads for donations or dishwashing soap. You diminish the encyclopedia by pasting ads for things that are completely unrelated to the topic they are searching. First and foremost, the READERS matter, and this diminishes the encyclopedia by putting information in the way of what they came for: verifiable facts about a topic. We aren't here to promote anything, including ourselves. Dennis Brown - 2¢ 07:27, 16 March 2024 (UTC)[reply]
No as per above. Banner ads do not benefit the encyclopedia, which is our primary concern. LEPRICAVARK (talk) 14:12, 16 March 2024 (UTC)[reply]
This is the kind of self-centredness that is detrimental to the Wikimedia project as a whole. 🌺 Cremastra (talk) 17:16, 16 March 2024 (UTC)[reply]
I could just as easily say that proposals like this one are detrimental to the English Wikipedia because they consume editor time that might otherwise have been spent improving articles. LEPRICAVARK (talk) 01:43, 17 March 2024 (UTC)[reply]
By that logic, every proposal here is detrimental because they take time away from editing articles. 🌺 Cremastra (talk) 12:55, 17 March 2024 (UTC)[reply]
No, a proposal that seeks to improve the encyclopedia is not a detriment. This, however, is a proposal that diminishes the encyclopedia, which is why I opposed it. LEPRICAVARK (talk) 16:28, 17 March 2024 (UTC)[reply]
Yeah, obviously: it's common knowledge that enwiki's love for sister projects is... lackluster at best. Thank god we're not in charge of creating new projects, because otherwise there wouldn't be any. But raising awareness for sister projects raises the probability that we'll be able to help someone find what they're looking for (like, say, a quote or a definition) next time they need something. Maybe they're looking for that information right now, and don't know where to find it! theleekycauldron (talk • she/her) 16:52, 16 March 2024 (UTC)[reply]
I don't think this is a good idea, beyond directing users to all Wikimedia sites in general. If English Wikipedia starts choosing individual sites to promote, and thus selecting ones not to promote, failure to promote a site will be seen as a negative endorsement. This may have an unduly discouraging effect on the expansion of the related communities. I am wary of putting English Wikipedia in a position where it can determine the success or failure of other Wikimedia sites. isaacl (talk) 17:52, 16 March 2024 (UTC)[reply]
No There are far fewer reasons to do this than not to do this; some of the reasons that I can think of off the top of my head include NPOV & not wanting to have to look into the editorial practices of other projects. JuxtaposedJacob (talk) 00:45, 17 March 2024 (UTC)[reply]
NPOV only applies to articles. If we start interpreting it that strictly, then we're going to need to delete a lot of essays... 🌺 Cremastra (talk) 12:56, 17 March 2024 (UTC)[reply]
No. I have seen no convincing argument why and how this would benefit the encyclopedia. Also per Isaacl · · · Peter Southwood(talk): 11:32, 18 March 2024 (UTC)[reply]
No. The purpose of Wikipedia is to be an encyclopaedia, not to recruit users for other projects. If the Wikimedia foundation thinks they need more users elsewhere, they can do their own advertising. Modest Geniustalk 12:03, 18 March 2024 (UTC)[reply]
@Modest Genius: Ah, so we don't want to actually help readers, we just want them to read the encyclopedia? 🌺 Cremastra (talk) 20:32, 18 March 2024 (UTC)[reply]
Yes. leeky puts it perfectly. Most readers don't know what on Earth a Wikivoyage is, when in reality, it could be exactly what they're looking for. Queen of Heartsshe/theytalk/stalk 20:30, 18 March 2024 (UTC)[reply]
No largely per Isaac. If we do every project, we're making a lot of noise for very little benefit. If we select only some, we functionally decide which projects we endorse (and which we don't by omission). Neither is a particularly good outcome. I also think banner campaigns are over-used in general and not a good way to support sibling projects if that's the goal. It's indiscriminate and for the majority of readers completely useless given what they're here to learn about. Why show a reader a banner about wikispecies if they're here reading about the Andromeda Galaxy? I don't see the benefits outweighing the costs. — Wug·a·po·des 20:46, 18 March 2024 (UTC)[reply]
General discussion (advertising sister projects)
The main page already has a large section, Wikipedia's sister projects. Why is something else needed? Schazjmd(talk) 19:55, 15 March 2024 (UTC)[reply]
Those links are hard to find and do little. Especially for mobile readers, they are unlikely to be actually seen. 🌺 Cremastra (talk) 20:00, 15 March 2024 (UTC)[reply]
Adding 'sister project' banners is inevitably going to make other content less likely to be seen, given finite screen sizes. AndyTheGrump (talk) 20:05, 15 March 2024 (UTC)[reply]
I think there inevitably will be tradeoffs with inclusion of any type of content. — Frostly (talk) 21:16, 16 March 2024 (UTC)[reply]
And how much space will the banners take up on mobile screens? Donald Albury 20:08, 15 March 2024 (UTC)[reply]
It depends what the final design is. Presumably the design used for mobile will be much smaller than that for desktop. 🌺 Cremastra (talk) 20:09, 15 March 2024 (UTC)[reply]
If banners were approved and shown, how would you determine whether they were worth the effort? Schazjmd(talk) 20:11, 15 March 2024 (UTC)[reply]
One could look at siteviews of projects, number of edits made, number of active users... and see if there was noticeable change. 🌺 Cremastra (talk) 20:12, 15 March 2024 (UTC)[reply]
Related discussion: Those here concerned about excessive banner use (or, conversely, wishing we'd use banners more) may be interested in discussion about the appropriateness of displaying the banner for Ukraine's Cultural Diplomacy Month globally without any geographic targeting. Sdkbtalk 21:16, 15 March 2024 (UTC)[reply]
During the brainstorming session for the 2021 RfA review, I suggested having regularly scheduled volunteer weeks, where editors representing different initiatives could host "open house" activities to engage potential volunteers. I didn't pursue the idea, though, since there was almost no interest expressed. However if it were to occur, it would be an opportunity for editors from other projects to set up open houses to publicize their work. isaacl (talk) 21:36, 18 March 2024 (UTC)[reply]
Maybe rather than banners for individual projects, there could be a banner about sister projects in general linking to a page that transcluded {{Wikipedia's sister projects}}, had a paragraph overview of each project, links to any welcome portals on that project, and links to any coordination or other related groups on en.wp. Thryduulf (talk) 22:17, 18 March 2024 (UTC)[reply]
Whilst I'm not necessarily opposed to focusing on other Wikimedia projects, personally I prefer a venue that is open for any initiative looking for more participation. There are a lot of areas on English Wikipedia that could either be helpful to more readers, if they knew about them, or could use more participants, if they were drawn to help out. isaacl (talk) 22:24, 18 March 2024 (UTC)[reply]
When discussion has ended, remove this tag and it will be removed from the list. If this page is on additional lists, they will be noted below.
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. Cocobb8 (💬 talk • ✏️ contribs) 15:19, 16 March 2024 (UTC)[reply]
Oppose "Template" is not a long word, and nobody abbreviates it as "tp" these days. This seems pointless. * Pppery *it has begun... 15:27, 16 March 2024 (UTC)[reply]
I just thought it'd make it consistent with wp: for Wikipedia:, which is 10 characters, while Template: is 9 characters. Cocobb8 (💬 talk • ✏️ contribs) 15:29, 16 March 2024 (UTC)[reply]
Nobody abbreviates it as "tp" these days. Even if that is true it is not a reason for us not to do so. Wikipedia is big enough to be making fashions rather than following them. Phil Bridger (talk) 21:16, 16 March 2024 (UTC)[reply]
Support I'd find it useful. It's less effort to type "tp:infobox person" in the search box than "template:infobox person" (which is how I usually navigate to wp: and template: pages). Schazjmd(talk) 15:52, 16 March 2024 (UTC)[reply]
Support I'd absolutely love this. I've often wondered if there was some technical problem that was preventing us doing this. Usedtobecool☎️ 16:00, 16 March 2024 (UTC)[reply]
Support: Pretty nice QOL change. Per Schazjmd. ARandomName123 (talk)Ping me! 16:35, 16 March 2024 (UTC)[reply]
I don't think it's a good idea to create an alias (and implicitly creating more English Wikipedia jargon) just to improve the search function. We should instead improve the search capability directly. isaacl (talk) 17:41, 16 March 2024 (UTC)[reply]
Yeah, but you don't want a casual reader to be confused as to why they ended up on a template page Cocobb8 (💬 talk • ✏️ contribs) 17:42, 16 March 2024 (UTC)[reply]
It would be a lot easier for the casual user to stumble upon a namespace alias, which could happen anywhere they enter an URL that might trigger a browser to launch, than for them to deliberately select the search box and type there. Furthermore, if this isn't intended to be used by a broad audience, then a more targeted solution would be better. Users wanting this functionality can make use of the script to which you were pointed in the previous thread, or they can configure their OS to provide an appropriate macro expansion to shorten the number of keystrokes they use. isaacl (talk) 18:08, 16 March 2024 (UTC)[reply]
"tp" seems very easily misconstrued as "Talk Page" at a glance. CMD (talk) 18:12, 16 March 2024 (UTC)[reply]
Good point. Sdkbtalk 18:22, 16 March 2024 (UTC)[reply]
Support I've been wanting this. It really is irksome to type out "Template:" I since learned today there are scripts, and of course {{tld}} for talk pages, but it would be much cleaner and simpler to have a standard abbrev. and this is technically easy to implement. TP: or T: it doesn't matter they both are fine. I prefer T: -- GreenC 18:56, 16 March 2024 (UTC)[reply]
Oppose For the reasons in WP:PEREN#Create shortcut namespace aliases for various namespaces. In particular, the Template namespace is generally not linked often enough that saving the typing of 6 characters is likely to be at all worthwhile and there's nothing available to use for the corresponding talk pages. Anomie⚔ 20:00, 16 March 2024 (UTC)[reply]
The template for linking a template is called {{tl}}. Shouldn't we have some consistency between this and the short-cut? Or is "tl" already used? Phil Bridger (talk) 21:16, 16 March 2024 (UTC)[reply]
{{tl}} is short for {{template link}}, so the el doesn't have anything to do with templates qua templates. jlwoodwa (talk) 04:31, 18 March 2024 (UTC)[reply]
Support – While there are helpful template shortcuts, like {{t}} and its siblings, that can be used in discussions, and a script that can be used in the on-wiki searchbox to convert {{ to Template:, a namespace shortcut (tp:) would help in edit summaries and customised browser search boxes. -- Michael Bednarek (talk) 23:55, 16 March 2024 (UTC)[reply]
Oppose Adding layers of obfuscation is not helpful. If I want to refer to {{convert}}, writing Template:Convert is easy and helpful to someone reading my comment. Writing Tp:Convert is unnecessary jargon that saves under a second of typing at the cost of head-scratching for readers. tp would be "talk page" for many. Johnuniq (talk) 01:00, 17 March 2024 (UTC)[reply]
Oppose As someone who has next to no involvement with template editing, I immediately think of 'talk page' when I see 'tp'. It would confuse many people who edit outside of the technical areas of Wikipedia. (Summoned by bot) JML1148(talk | contribs) 06:57, 17 March 2024 (UTC)[reply]
Rename the template mainspace from "Template:" to "Plantilla:" and use "Pl:" as a shortcut CactiStaccingCrane (talk) 18:02, 18 March 2024 (UTC)[reply]
That would be quite a big change, but I'm not against it lol Cocobb8 (💬 talk • ✏️ contribs) 19:50, 18 March 2024 (UTC)[reply]
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]
Showing "Redirected from" notice at top of section
When one arrives at an article via a redirect, the page is rendered with an additional line saying "(Redirected from [...])", directly (?) below the "From Wikipedia, the free encyclopedia" byline below the article title.
For most of the many redirects that target sections of articles, instead of entire articles, that means that this line isn't in view, which makes little sense to me. After all, if the page includes any {{redirect}}-type dab templates, those are placed as section hatnotes, not article hatnotes, which makes a lot of sense.
Why not show the notice below the section title, either instead of or in addition to where it is now?
I think this is a good question. The notice linking to the redirect is useful as a way to get to the redirect page. and it informs the reader why they are at a place they would not expect to be, but it should be displayed where it can be seen, and preferably where it is most relevant, which would usually be at the redirect target. At the section header would be appropriate for R to section. Not sure about R to anchor. Cheers · · · Peter Southwood(talk): 17:03, 16 March 2024 (UTC)[reply]
Ah, yes, anchors, good thinking. Their essential invisibility tends to make me fail to consider them more often than not. In this context, I recken that's probably fine, though, because keeping the thing itself hidden but then implicitly or explicitly drawing attention to it in a visible notice would be a bit weird, even if there were a nice space for it.
That said, I suppose a generic phrasing like "(Redirected from [...] to this location)" would work for both, or even all three, cases. That'd leave the space issue to be solved.
Good idea. Cuts down on confusion. How it would be implemented is another question. 🌺 Cremastra (talk) 17:17, 16 March 2024 (UTC)[reply]
+1 Good idea. I'd suggest filing a task on Phabricator to get some developer attention. Sdkbtalk 18:19, 16 March 2024 (UTC)[reply]
Yeah, I've noticed that. Thanks for proposing this. Donald Albury 18:54, 16 March 2024 (UTC)[reply]
This would've been a perfect technical wishlist submission if they hadn't just gotten rid of the technical wishlist. --Ahecht (TALK PAGE) 13:41, 17 March 2024 (UTC)[reply]
Definitely "in addition", rather than "instead of". At the very least, this would help editors whose muscle memories have them press Home when following a redirect to a section. jlwoodwa (talk) 04:57, 18 March 2024 (UTC)[reply]
There is a counterargument to be made, using the same scenario: If, after jumping to the top of the article, for whatever reason, one decides one wants to go back to the redirect's target location, again for whatever reason, the proposed change adds a new way to do that - Ctrl+F "redirected". Works either way, of course, but a bit better when there are no duplicates elsewhere.
Ah, but now that I imagine myself doing that, selecting "redirected" in the notice at the top, then Ctrl+F, then just hitting Enter once or twice may be even more convenient than typing it in. Never mind!
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]
I envision that there will be three things that needs to be done before this proposal can be enforced:
Make a new template similar to {{Proposed deletion}} for this proposal
Communicate to new editors that articles on Wikipedia must have reliable sources cited, and it is strongly encouraged that they find reliable sources before writing the article
A way to tackle editor disputes about what constitutes "third-party" and "reliable".
Number two is extremely difficult. Anyone who knows English could be a new editor. There are many hundreds of millions of them. Phil Bridger (talk) 10:49, 17 March 2024 (UTC)[reply]
We should also find ways to retain new editors if this proposal is enforced, because that would set an even higher barrier for entry for new editors to Wikipedia. This is the reason I why invited WP:Wikiproject Editor Retention to this topic. CactiStaccingCrane (talk) 07:12, 17 March 2024 (UTC)[reply]
As in discouraging. It would be bad if we start to vandalize new articles in order to depreciate them though :) CactiStaccingCrane (talk) 07:19, 17 March 2024 (UTC)[reply]
New editors are already forced to go through WP:AfC, which is not going to approve an unsourced article. --Ahecht (TALK PAGE) 13:39, 17 March 2024 (UTC)[reply]
If you think the new editor article-writing experience is so demoralizing, maybe we should just not let new editors create articles in the first place? 2603:8001:4542:28FB:E9B3:2893:5C25:E68F (talk) 07:28, 17 March 2024 (UTC) (Send talk messages here)[reply]
No. We already have the WP:Article wizard to aid completely new editors to create a new article. I think that the wizard should be shown more prominently in "Wikipedia does not have an article with this exact name" notification box, as well as making {{AfC submission/draft}} and {{AfC submission/declined}} easier to understand for new editors. But we need new editors and we MUST NOT make Wikipedia harder for newcomers to contribute. CactiStaccingCrane (talk) 07:33, 17 March 2024 (UTC)[reply]
The fundamental problem for newcomers is that editing Wikipedia is not convenient. It takes a substantial effort to do so. So, one way to make this easier is to improve on the article wizard and ask people to find a few sources before citing them. I imagine that the new article wizard would ask you for URLs/book titles (and pages), and once you create a draft it would show you how to expand these fragments of info into fully-fledged "wikipedia-compliant" citations. CactiStaccingCrane (talk) 08:04, 17 March 2024 (UTC)[reply]
Sorry for the horrendous MS Paint drawing, but this is what I envision it to be like this:
All of the objections raised to the two similar proposals in the last few months still apply. I really can't be bothered to repeat them again. We're supposed to be building an encyclopedia here. Clearing a backlog is only incidental to this. Phil Bridger (talk) 08:52, 17 March 2024 (UTC)[reply]
I like this idea in theory, but will only support it once tools and wording changes for newcomers are instated. The risk of this detracting newcomers is high enough that I think the community should have a consensus that the new wording/templates etc. alleviate harm, and they should be ready to go before any changes are made. ― novov(tc) 09:52, 17 March 2024 (UTC)[reply]
Support per all the arguments I've made before. WP:BURDEN, basically. 🌺 Cremastra (talk) 12:47, 17 March 2024 (UTC)[reply]
Rather than a PROD, we should really just move new unsourced articles to draft. Lee Vilenski(talk • contribs) 12:56, 17 March 2024 (UTC)[reply]
This again? While consensus can change, it seems unlikely that consensus will have changed in the month since Wikipedia:Requests for comment/Deletion of uncited articles was rejected. Let's not make this another topic area where people keep pushing essentially the same proposal with slightly different wording until, through tendentiousness and exhaustion, they manage to get something in (and then ratchet and repeat). Anomie⚔ 13:38, 17 March 2024 (UTC)[reply]
Support Moving to Draft with a x day prod-like notice. I'm impressed by the relentless work done by a small number of overwhelmed volunteers trying to address this problem, and I support their efforts. I disagreed with the former proposal, but this one is acceptable, grandfather the existing article and raise the quality bar for new articles by a very small degree. We already do this with AfC, where quality standards are much higher, it is nothing we don't already do. -- GreenC 14:42, 17 March 2024 (UTC)[reply]
Query: Can someone speak to how the newer entries in Category:Articles lacking sources are ending up there? Don't all new articles these days have to go through WP:NPP, which ought not to let them pass if they are unsourced? Sdkbtalk 14:44, 17 March 2024 (UTC)[reply]
Did you find many such new articles? New page reviewers can mark unsourced articles reviewed if the topic is notable but I doubt that happens very often. Someone would have to sort those articles by creation/expansion-from-redirect date to find out. — Usedtobecool☎️ 15:09, 17 March 2024 (UTC)[reply]
First one I checked from March 2024 was created by an autopatrolled editor, so even NPP wouldn't see it necessarily. Schazjmd(talk) 15:23, 17 March 2024 (UTC)[reply]
The categories track the tagging date. And iirc some automated tools update tag dates when making unrelated edits. So, it's likely the new categories are just populating with old articles. Autopatrolled editors wouldn't remain autopatrolled if they created unsourced articles nowadays. I actually think autopatrolled has a higher bar than necessary but admins are very risk-averse. — Usedtobecool☎️ 16:12, 17 March 2024 (UTC)[reply]
@Usedtobecool, you're right, it wasn't created in March 2024, I should have looked more closely. Schazjmd(talk) 16:22, 17 March 2024 (UTC)[reply]
In general, I expect almost all the articles in those categories are old articles. Notability would have to be completely obvious and there would need to be no BLP element in the article for a reviewer to pass an unsourced article in 2024, if someone were to start Ancient history of Botswana that more or less concurs with relevant content in existing articles, for example. — Usedtobecool☎️ 16:31, 17 March 2024 (UTC)[reply]
I draftify all new unsourced articles I see, but sometimes the creator tendentiously undraftifies it, and per WP:DRAFTIFY, I'm not allowed to redraftify it, so I just tag it. 🌺 Cremastra (talk) 19:03, 17 March 2024 (UTC)[reply]
Oppose per the most recent discussion and disallow any new discussions on this for a few months. I've already seen several notable topics without sources or with only one source being moved to draftspace and then deleted after six months. A PROD would make this even worse. SportingFlyerT·C 15:27, 17 March 2024 (UTC)[reply]
Oppose Unsourced articles are bad but etching explicit grandfather clauses into Wikipedia's rules is worse. * Pppery *it has begun... 15:39, 17 March 2024 (UTC)[reply]
Yeah, I don't like the idea of grandfathering, especially given the potential to reinforce systemic bias, given that Wikipedia's content is becoming more diverse over time. Sdkbtalk 16:34, 17 March 2024 (UTC)[reply]
That's why there is a moving deadline to the left to clear out the backlog. Stage one of this proposal is to prevent further growth of the backlog, stage two of this proposal is to start tackling the remaining articles from newest to oldest. CactiStaccingCrane (talk) 17:30, 18 March 2024 (UTC)[reply]
Oppose, draftifying does the trick already. There do not seem to be many (any?) totally unsourced articles that make it through NPP, so I am not sure there are any articles that this proposal applies to (the category mentioned by the nominator contains mostly old articles that have been recently tagged as unsourced). —Kusma (talk) 16:32, 17 March 2024 (UTC)[reply]
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]
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]
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]
Support I think the is an extension of WP:CIR. Beside it is very frustrating to see in AfDs the comments "there are sources available" and "normal editing can solve this" after which absolutely nothing happens. Not even by the editors that state that there are sources available (when you know that, why do you not add them???). The Bannertalk 17:48, 18 March 2024 (UTC)[reply]
Strong support. I opposed the previous proposal to remove all unsourced articles, but this encyclopedia has existed for 23 years, and the standards have dramatically increased since then. Back then, this might've been acceptable, but it is no longer, hasn't been for quite a while, and this just codifies that. This is also in line with WP:BURDEN; we shouldn't have to prove a lack of notability to throw these articles out. Queen of Heartsshe/theytalk/stalk 20:25, 18 March 2024 (UTC)[reply]
Strong support. Wikipedia is a tertiary source, let's not forget that, and its purpose is to benefit readers by presenting information on all branches of knowledge. As others have said, having at least one source will at least verify the topic is not a hoax, and will ensure that the mentioned knowledge is not fake. These unsourced articles should at the very least be moved to a draft, in my opinion. Cocobb8 (💬 talk • ✏️ contribs) 20:38, 18 March 2024 (UTC)[reply]
Support. I don't love grandfather clauses either, but I think this is the least bad of the available solutions (the most bad being "Do nothing; just keep accumulating unsourced material indefinitely".) At some point, we have to turn the water off to the gushing pipe, and then we can focus on cleaning up the remaining mess. We really need to get across the idea of a "reverse BEFORE": Before you create or substantially add to an article, have in hand the reference material that verifies what you will write, and cite it. "Write first, hope someone sources it later, in practice let it sit unreferenced or CN tagged for the next ten years" should be an approach that is deprecated and ultimately not permitted (at least not in mainspace; if people want to do things backward in a draft or userspace, that's up to them.) An alternative might be to draftify unsourced new articles, and forbid returning them to mainspace until at least one source is added, but when you're already dealing with a flood, first turn the tap off. SeraphimbladeTalk to me 21:04, 18 March 2024 (UTC)[reply]
Oppose mostly because a grandfather clause is generally a bad idea at best: why does this only become a problem on April 1, 2024? As other have pointed out, unsourced articles rarely make it through NPP and AfC, and even if we let PROD be used for this, it can still be contested and forced to go through AFD where WP:NEXIST makes it likely to be kept regardless of the number of citations in the article. The main practical effect I see is the grandfather clause, and it only makes sense if the goal of slowly removing the protection is bought into. The problem is that consensus from about a month ago doesn't show an appetite to apply this rule to articles that already exist, and without a mechanism to move the grandfather date automatically we'll have to keep having discussions to move it around which wastes time and risks running around consensus by tiring people out with constant discussions. I don't see this going well in practice. — Wug·a·po·des 21:05, 18 March 2024 (UTC)[reply]
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]
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]
Make Todays Featured List appear exactly every 3 days instead of 3-4 days
I'm not sure if this is the right place to ask, but I'll ask it here.
Something that I've always been confused about is why TDL has a schedule where one list will appear three days after a list and then the next list will appear 4 days after instead of just three days again. I don't see how this could be for "we could run out of unique lists" purposes because there are over 3100 lists that haven't been featured on the main page.
So I propose that Todays Featured List should appear every 3 days instead of every 3-4 days on the main page. Onegreatjoke (talk) 00:41, 18 March 2024 (UTC)[reply]
Per Wikipedia:Today's featured list, it's because TFL appears Mondays and Fridays, aligning with days of the week. That seems to work fine, so I don't see a need for a change. Sdkbtalk 08:12, 18 March 2024 (UTC)[reply]
16:50, 2 March 2024 (UTC)
means anyway, in my mind it serves as more of a motivational little trinket for editors, and I'm concerned that removing the most prominent area where it's featured could decrease the impetus to improve content. ― novov (t c) 01:57, 3 March 2024 (UTC)
Moved from Template talk:Sandbox heading
You are invited to join the discussion at MediaWiki talk:Editpage-head-copy-warn § New design. Sdkb talk 17:10, 11 March 2024 (UTC)
🌺 Cremastra (talk) 12:56, 17 March 2024 (UTC)
