Wikipedia:Village pump (proposals)
From Wikipedia the free encyclopedia
Policy | Technical | Proposals | Idea lab | WMF | Miscellaneous |
The proposals section of the village pump is used to offer specific changes for discussion. Before submitting:
- Check to see whether your proposal is already described at Perennial proposals. You may also wish to search the FAQ.
- This page is for concrete, actionable proposals. Consider developing earlier-stage proposals at Village pump (idea lab).
- Proposed policy changes belong at Village pump (policy).
- Proposed speedy deletion criteria belong at Wikipedia talk:Criteria for speedy deletion.
- Proposed WikiProjects or task forces may be submitted at Wikipedia:WikiProject Council/Proposals.
- Proposed new wikis belong at meta:Proposals for new projects.
- Proposed new articles belong at Wikipedia:Requested articles.
- Discussions or proposals which warrant the attention or involvement of the Wikimedia Foundation belong at Wikipedia:Village pump (WMF).
- Software changes which have consensus should be filed at Phabricator.
Discussions are automatically archived after remaining inactive for nine days.
RfC: Converting all current and future community discretionary sanctions to (community designated) contentious topics procedure[edit]
|
Should all community discretionary sanctions (DS) be updated to use the new contentious topics procedure? Awesome Aasim Refreshed 01:18, 8 March 2024 (UTC) 05:55, 7 February 2024 (UTC)
Background[edit]
In late 2022/early 2023, the discretionary sanctions procedure was overhauled by ArbCom and converted to "contentious topics". With now two different processes for two different kinds of sanctions there is now a lot of fragmentation and inconsistency in how contentious topics should be handled, with even conflicting wording. The main goal of this RfC is to unify the procedure used for all areas where general sanctions are in effect with the one designated by ArbCom, going forward.
As proposed at this time, there will be the some similarities and differences between community and arbitration contentious topics, including:
- The imposition of the standard set of restrictions by consensus of administrators in a community designated topic would be at WP:ANI rather than WP:AE.
- Reconsideration of contentious topic restrictions would be done at WP:AN instead of at WP:AE or WP:ARCA.
- Awareness of a community contentious topic would include but not be limited to being mentioned in the discussion closing summary regarding that contentious topic, which is the closest there is to a "final decision".
And of course, ArbCom would be able to convert community contentious topics to those designated by the committee, after which all the ArbCom venues would have to be used from that point forward, though existing restrictions would remain appealable to WP:AN until renewed at ArbCom.
Survey (community contentious topics)[edit]
- Support as proposer. It needs to be clear, especially for new editors, what contentious topics are and what the expectations are for editing topics designated as contentious by either ArbCom or the community. A unified procedure will ensure consistency rather than fragmentation and will make editing the list of contentious topics and their restrictions much easier. (I did do a little bit of work in the Module:Sanctions/sandbox adding in support for ArbCom contentious topics, as it would make it so much easier to use the related sanction templates. I also did work in user space to help envision what a unified contentious topics page might look like.) Awesome Aasim 05:55, 7 February 2024 (UTC)
- 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)
- 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)
- 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)
- Support. The contentious topics procedure incorporates all of the improvements from the 2021-22 review of the discretionary sanctions procedure. Compared to the discretionary sanctions procedure, the contentious topics procedure is much easier to understand and follow. For example, many editors currently need to be reminded of topic areas under community sanctions every 12 months to be eligible for certain remedies, which led to complaints in the 2021-22 review. Switching from discretionary sanctions to contentious topics would eliminate this requirement: "Editors no longer need to be alerted every 12 months, as they are presumed to remain aware after their first alert." — Newslinger talk 04:45, 9 March 2024 (UTC)
- 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)
- Support making the rules clear and consistent for all editors. Let'srun (talk) 19:33, 10 March 2024 (UTC)
- 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)
- 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)
- 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)
- Oppose (despite abstract support) as ANI has generally been the wrong forum for General Sanctions work. In my mind it should be a pump or AN and ANI should be out of the whole system. I also think it's a missed opportunity to not allow community GS to be heard at AE. There is already the community option for AN but this proposal would have created the option of using AE which is the forum many think about anyway. Outside of these details I'm supportive of the effort (given the fact that amongthe few who have expressed an opinion there seems to be overall support). Barkeep49 (talk) 14:55, 21 March 2024 (UTC)
- Oppose Ivan (talk) 20:58, 21 March 2024 (UTC)
- Support - I don't have anything to add beyond what Galobtter said - perfectly expressed. —Ganesha811 (talk) 01:18, 22 March 2024 (UTC)
Discussion (community contentious topics)[edit]
Cooperation of ArbCom[edit]
I wonder if adding in stuff to the WP:CTOP page and similar would require the petition and referendum process. If so, then I guess the merging of templates would have to hold off until a former petition and request for amendment actually passes. It is possible ArbCom will green light the merge if this RfC passes, but I do not know. Awesome Aasim 05:55, 7 February 2024 (UTC)
- 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)
- 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)
- 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)
- That also sounds like a good idea: community authorizes the remedies that are appropriate, ArbCom implements them. If ArbCom were to deviate then they would just need to ask the community whether it is an appropriate deviation or not. Awesome Aasim 17:28, 9 February 2024 (UTC)
- 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)
- I think you know what I mean :)
- WP:ARBECR is already used a lot by both the community and by ArbCom, like in WP:RUSUKR and WP:CT/A-I. What I am saying is if ArbCom feels that a specific sanction that there has never been any precedent for is necessary, they should propose it to the community, where there then can be consensus on the exact wording. Placement, enforcement, and appeals are all going to differ though depending on whether the restriction is placed by the community or ArbCom. Awesome Aasim 18:43, 9 February 2024 (UTC)
- 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)
- 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)
- 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)
- 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)
- 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)
- 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)
- That also sounds like a good idea: community authorizes the remedies that are appropriate, ArbCom implements them. If ArbCom were to deviate then they would just need to ask the community whether it is an appropriate deviation or not. Awesome Aasim 17:28, 9 February 2024 (UTC)
- 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)
- 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)
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)
- I definitely think we should split contentious topics from WP:AELOG. A separate contentious topics log would make restrictions much easier to follow - and, if the restriction is rescinded or converted from community to ArbCom or the other way around - it can be logged as well. Awesome Aasim 21:21, 10 February 2024 (UTC)
Request revision to initial question[edit]
The statement all community general sanctions (DS)
in the initial question is misleading. "General sanctions" is not synonymous with community authorization for discretionary sanctions. I think the intent should be clarified that the proposal only affects discretionary sanctions authorized by the community, and not all general sanctions. isaacl (talk) 19:03, 7 February 2024 (UTC)
Tag Refreshed[edit]
I refreshed the RfC tag because there is not enough input to gauge consensus. Could this be because this is uncontroversial or what? Awesome Aasim 19:58, 8 March 2024 (UTC)
- Could well be :) Selfstudier (talk) 10:27, 9 March 2024 (UTC)
- 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)
- @Darkfrog24 The question is really just about making community sanctions use the new contentious topics procedure. Awesome Aasim 23:45, 17 March 2024 (UTC)
- 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)
- 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)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)- 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)
- 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.
- Again, not all community sanctions, but community-authorized discretionary sanctions. isaacl (talk) 01:36, 18 March 2024 (UTC)
- 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)
- @Darkfrog24 The question is really just about making community sanctions use the new contentious topics procedure. Awesome Aasim 23:45, 17 March 2024 (UTC)
- 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)
Is it time for a new design for the main page?[edit]
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.
Best regards, Riad Salih (talk) 02:50, 14 February 2024 (UTC)
- Ain't broke, don't fix it. * Pppery * it has begun... 03:02, 14 February 2024 (UTC)
- +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)
- Yea, the main page is good enough (there could be some changes however) mer764KCTV5 (He/Him | t • c) 04:05, 19 March 2024 (UTC)
- This contradicts the well-established community consensus of “ain’t broke, let’s break it and pretend we might fix it later”. 216.147.126.60 (talk) 20:52, 14 February 2024 (UTC)
- Fair, true, and appropriate.
- I agree. ProofCreature (talk) 18:24, 15 February 2024 (UTC)
- Agree. The main page as it is is beautiful. Pksois23 (talk) 09:00, 15 March 2024 (UTC)
- +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)
- You may want to review Wikipedia:Perennial proposals#Redesign the Main Page. Anomie⚔ 03:47, 14 February 2024 (UTC)
- 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)
- 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)
- "We don't like change" says the group of people who made over one billion two hundred million changes to a single website. :-) —andrybak (talk) 04:18, 10 March 2024 (UTC)
- 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)
- 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)
- 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)
- 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 (t c) 08:33, 15 February 2024 (UTC)
- VECTOR2022 should just be reversed. ~WikiOriginal-9~ (talk) 18:35, 15 February 2024 (UTC)
- 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)
- 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)
- Hi @331dot @Anomie @Certes @Cremastra @Joe Roe @Mir Novov @Pppery @RudolfRed @
- What do you think, for example, of the design of the main page of the Spanish Wikipedia? Or the Portuguese version or Turkish?
- Regards Riad Salih (talk) 10:39, 15 February 2024 (UTC)
- 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)
- @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)
- 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) - 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)
- 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)
- 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 (t c) 08:38, 15 February 2024 (UTC)
- Is there something particular you feel is a problem with the current design? – Teratix ₵ 09:17, 15 February 2024 (UTC)
- 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)
- 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)
- 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)
- @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)- 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)
- 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.
- @Aaron Liu: The problem with opening remarks such as
- 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)
- User:Cremastra/MP looks fine to me. What do you think of the changes here? 🌺 Cremastra (talk) 01:49, 19 February 2024 (UTC)
- 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.
- Aaron Liu (talk) 03:02, 19 February 2024 (UTC)
- 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)
- 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)
- 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)
- 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)
- There has been consensus to remove portal links, so the "Look through content portals" part should be omitted. ObserveOwl (chit-chat • my doings) 09:05, 2 March 2024 (UTC)
- 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)
- @QuicoleJR Oh, I just put in the ad for fun. 🌺 Cremastra (talk) 18:49, 3 March 2024 (UTC)
- 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)
- 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)
- I mean the corner of the globe that you placed next to "Welcome to Wikipedia!" QuicoleJR (talk) 21:32, 3 March 2024 (UTC)
- Yeah, that's common across Wikipedias, e.g., see fr:. 🌺 Cremastra (talk) 21:56, 3 March 2024 (UTC)
- I mean the corner of the globe that you placed next to "Welcome to Wikipedia!" QuicoleJR (talk) 21:32, 3 March 2024 (UTC)
- It looks cool Aaron Liu (talk) 01:56, 4 March 2024 (UTC)
- 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)
- 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)
- @QuicoleJR Oh, I just put in the ad for fun. 🌺 Cremastra (talk) 18:49, 3 March 2024 (UTC)
- 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)
- Thanks for the work, but unfortunately I don't like it very much:
- 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)
- 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)
- I like the eswik's too, clean and simple Riad Salih (talk) 11:40, 18 March 2024 (UTC)
- eswiki looks really good vghfr (✉ Talk) (✏ Contribs) 13:44, 18 March 2024 (UTC)
- 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)
- 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)
- 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)
- 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)
- What do you mean by a wikiproject redesign? Aaron Liu (talk) 12:34, 6 March 2024 (UTC)
- Too complicated to go into here. Probably best for discussion at the WikiProject Council. Stefen Towers among the rest! Gab • Gruntwerk 19:01, 6 March 2024 (UTC)
- What do you mean by a wikiproject redesign? Aaron Liu (talk) 12:34, 6 March 2024 (UTC)
- Good luck. This is going to be harder than Vector 2022. CactiStaccingCrane (talk) 17:35, 22 March 2024 (UTC)
- @CactiStaccingCrane I will quote you :"Ignore all rules and be the change that you want to see" so Idecided to take the initiative to make the first step. Riad Salih (talk) 00:18, 23 March 2024 (UTC)
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)
- 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)
- 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)
- 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)
- Hey, I like that! Zanahary (talk) 06:34, 19 February 2024 (UTC)
- 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)
- 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) - 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)
- 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)
- 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) 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)
- I think the border's supposed to be like the heading's border.
- 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)
- @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)
- I'd support it at the RfC stage, but unfortunately I doubt it would pass. 🌺 Cremastra (talk) 00:40, 20 February 2024 (UTC)
- 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)
- 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)
- I have a visceral dislike for rounded rectangles, possibly because they are now so prevalent. 🌺 Cremastra (talk) 20:49, 20 February 2024 (UTC)
- 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)
- What is that graphic metaphor supposed to mean? Aaron Liu (talk) 22:26, 20 February 2024 (UTC)
- 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)
- 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)- If you go to one column, you won't have to worry about balance. --User:Khajidha (talk) (contributions) 19:17, 21 February 2024 (UTC)
- That would be wasting a lot of space. Aaron Liu (talk) 20:06, 21 February 2024 (UTC)
- 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)
- 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)
- 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)
- 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)
- As I don't have a childhood,[Joke] I'm not sure what you're talking about.
- 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)
- 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)
- 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)
- 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)
- 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)
- 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)
- 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)
- I don't think we'd need to change the main page every year. Aaron Liu (talk) 14:00, 23 February 2024 (UTC)
- I agree. Maybe changing every 3 years would be a better idea. 71.239.86.150 (talk) 21:34, 24 February 2024 (UTC)
- I don't think we'd need to change the main page every year. Aaron Liu (talk) 14:00, 23 February 2024 (UTC)
- 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)
- That would be wasting a lot of space. Aaron Liu (talk) 20:06, 21 February 2024 (UTC)
- If you go to one column, you won't have to worry about balance. --User:Khajidha (talk) (contributions) 19:17, 21 February 2024 (UTC)
- 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)
- An RfC which would unfortunately fail. 🌺 Cremastra (talk) 19:46, 18 March 2024 (UTC)
- @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)
- At least your (and Galobtter's) small upgrade would probably pass. Aaron Liu (talk) 20:03, 18 March 2024 (UTC)
- I wouldn't bet on it. :/ 🌺 Cremastra (talk) 20:10, 18 March 2024 (UTC)
- An RfC which would unfortunately fail. 🌺 Cremastra (talk) 19:46, 18 March 2024 (UTC)
- 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.
- This proposal may have met with a more favourable response if the proposer had suggested some concrete ways in which s/he would like the Main Page changed. I do have a suggestion, and that is we could include a box listing some of the new articles in Wikipedia in Wikipedia: Main Page. I do not know how many new articles are created on Wikipedia each day, but it could be dozens, and we only need to list a handful of them to make the Main Page show Wikipedia is a developing project. YTKJ (talk) 22:16, 20 March 2024 (UTC)
- nominally, that'd be DYK. theleekycauldron (talk • she/her) 22:18, 20 March 2024 (UTC)
- That's a great idea! I support it Cocobb8 (💬 talk • ✏️ contribs) 22:18, 20 March 2024 (UTC)
- And most of those articles are probably pretty bad. DYK fills that role, and DYK is at least slightly vetted. 🌺 Cremastra (talk) 22:19, 20 March 2024 (UTC)
- A DYK hook can be extracted from nearly every article that satisfies DYK's very basic criteria. Aaron Liu (talk) 22:50, 20 March 2024 (UTC)
- Support a redesign With V22 rolling out, the main page has become quite squashed, with very short line lenghts, tiny images, and a general bloated feel. It would be great to redesign this, probably by stealing ideas from other editing communities. The Spanish Wikipedia design would definitely get support from me, but I think we can make this into a more responsive design, so that we can use modern screen sizes more optimally. There are two columns, so the arguments for V22 giving up screen space are not transferable. Easiest is probably taking one small step at a time. Is it possible to widen the main page in V22? —Femke 🐦 (talk) 16:11, 24 March 2024 (UTC)
There is already a different Main Page on the app[edit]
Nobody ever seems to mention this, so I think it might just not be generally known -- seriously, go look if you don't believe me -- there is a different Main Page on the app with completely different sections that are not put together by the editing community. It has totally different stuff, some sections are missing and there are sections that only show up on the app's main page, et cetera. jp×g🗯️ 05:03, 21 March 2024 (UTC)
- Not really? The sections are Featured article, On this day, Featured image, Most visited articles, and Random article. It's not totally different by any means, and I don't think it needs consideration when we think about a main page redesign. Aaron Liu (talk) 11:28, 21 March 2024 (UTC)
- So is someone going to let the people at DYK and FLC know that they were deemed unimportant and removed from the main page, then? If this is just being done unilaterally by the fiat of app developers, does it really matter what the community decides should be there? jp×g🗯️ 15:23, 21 March 2024 (UTC)
Feedback sought for proposal to drop archival bot notice params from Template:Talk header[edit]
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)
- 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)
AI for WP guidelines/ policies[edit]
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. ExclusiveEditor Notify Me! 16:08, 7 March 2024 (UTC)
(Note: AI is supposed to complement search) ExclusiveEditor Notify Me! 13:59, 18 March 2024 (UTC)
- 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)
- @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. ExclusiveEditor Notify Me! 16:25, 7 March 2024 (UTC)
- 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. ExclusiveEditor Notify Me! 16:29, 7 March 2024 (UTC)
- @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. ExclusiveEditor Notify Me! 16:25, 7 March 2024 (UTC)
- @ExclusiveEditor You seem to assume that we want these things and that they are good. 🌺 Cremastra (talk) 22:38, 7 March 2024 (UTC)
- @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. ExclusiveEditor Notify Me! 09:41, 8 March 2024 (UTC)
- Sounds like a solution looking for a problem. You only get familiar with current expectations by doing more editing. Awesome Aasim 01:23, 8 March 2024 (UTC)
- @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)
- 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. ⇒SWATJester Shoot Blues, Tell VileRat! 04:26, 8 March 2024 (UTC)
- 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)
- @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)
- 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. ⇒SWATJester Shoot Blues, Tell VileRat! 15:35, 8 March 2024 (UTC)
- @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)
- 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. ⇒SWATJester Shoot Blues, Tell VileRat! 15:35, 8 March 2024 (UTC)
- 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)
- 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)
- The Wikimedia Foundation's Machine Learning Team already seem quite busy. Sean.hoyland (talk) 16:23, 8 March 2024 (UTC)
- 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)
- 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)
- 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)
- 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)
- @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)
- 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)
- @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)
- 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)
- 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)
- 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)
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 (✉ Talk) (✏ Contribs) 03:34, 18 March 2024 (UTC)
- @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.ExclusiveEditor Notify Me! 14:27, 18 March 2024 (UTC)
- 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)
- 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, Rosguill talk 14:09, 18 March 2024 (UTC)
- @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, ExclusiveEditor Notify Me! 14:20, 18 March 2024 (UTC)
- I still think that this is a solution in search of a problem, and that it will in fact find several new problems if implemented. The same concerns of lack of reliability apply: how do we know that the chatbot will direct people to the correct p&g page given a query at runtime? What dataset of queries and responses could we possibly train it on? How will the AI know how to balance essays, guidelines, and policies, or how to recognize an essay that nevertheless has broad buy-in from the community and is a guideline in all but name? How would the AI know how to adapt to IAR, to contradictory essays and guidelines, or to the fact more broadly that our documentation is descriptive rather than prescriptive of Wikipedia practices? There is no publicly-available dataset that we could train an AI off of that would even begin to address these use cases. I am raising these concerns as someone with several years of professional experience in AI research. signed, Rosguill talk 15:14, 19 March 2024 (UTC)
- @Rosguill: Your have very valid points of concern. I think that this could be implemented step by step, whenever the community and foundation feel ready. There are lot of proposals in this discussion itself: First two are the proposals I presented, then a new one is too just let the already existing search engine get AI optimized, other is to make 'policychecker' (spellchecker but for WP policy... which(idea) is at least worth exploring), then we have something like Wikipedia Library type, difference that it provides access to some third party model like ChatGPT fed with p&g which could be used in a while, etc. I have even posted an example of basic AI which we could think of in first step. ExclusiveEditor Notify Me! 16:32, 19 March 2024 (UTC)
- I still think that this is a solution in search of a problem, and that it will in fact find several new problems if implemented. The same concerns of lack of reliability apply: how do we know that the chatbot will direct people to the correct p&g page given a query at runtime? What dataset of queries and responses could we possibly train it on? How will the AI know how to balance essays, guidelines, and policies, or how to recognize an essay that nevertheless has broad buy-in from the community and is a guideline in all but name? How would the AI know how to adapt to IAR, to contradictory essays and guidelines, or to the fact more broadly that our documentation is descriptive rather than prescriptive of Wikipedia practices? There is no publicly-available dataset that we could train an AI off of that would even begin to address these use cases. I am raising these concerns as someone with several years of professional experience in AI research. signed, Rosguill talk 15:14, 19 March 2024 (UTC)
- @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, ExclusiveEditor Notify Me! 14:20, 18 March 2024 (UTC)
- 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)
- @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. ExclusiveEditor Notify Me! 16:10, 18 March 2024 (UTC)
- 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)
- @CAlbon (WMF): In editing energy and telecommunications articles, I've noticed that several key editors who made significant contributions have left Wikipedia, likely due to criticisms or disputes. These criticisms, not always expressed in a civil tone, have highlighted issues in their newly created articles or edits such as subjective language, the inclusion of original ideas, and potential plagiarism. Implementing a "policy checker" for articles before they "go live" could greatly reduce such friction, helping to retain passionate contributors. HerBauhaus (talk) 14:24, 19 March 2024 (UTC)
- This is a really good insight. Thanks for sharing the example. CAlbon (WMF) (talk) 16:44, 22 March 2024 (UTC)
- @CAlbon (WMF): In editing energy and telecommunications articles, I've noticed that several key editors who made significant contributions have left Wikipedia, likely due to criticisms or disputes. These criticisms, not always expressed in a civil tone, have highlighted issues in their newly created articles or edits such as subjective language, the inclusion of original ideas, and potential plagiarism. Implementing a "policy checker" for articles before they "go live" could greatly reduce such friction, helping to retain passionate contributors. HerBauhaus (talk) 14:24, 19 March 2024 (UTC)
- 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)
- @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. ExclusiveEditor Notify Me! 16:10, 18 March 2024 (UTC)
- 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)
- @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. ExclusiveEditor Notify Me! 16:30, 18 March 2024 (UTC)
- 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)
- @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. ExclusiveEditor Notify Me! 16:30, 18 March 2024 (UTC)
- Oppose – Don't think this should be an official tool. I support any unofficial ones that people want to build. I've personally built a GPT with access to all Wikipedia namespace articles concatenated into a single file. Go ahead and ask it about Wikipedia rules and guidelines and maybe it will actually give an accurate answer. – Kjerish (talk) 04:53, 19 March 2024 (UTC)
- @Kjerish: Okay, great! But it requires ChatGPT plus. Maybe somewhat like Wikipedia library, WM could give us any one such model's access. ExclusiveEditor Notify Me! 13:11, 19 March 2024 (UTC)
- Oppose - First and foremost, I understand and respect your vision to expand Wikipedia but I fear that AI (such as ChatGPT) is not to the level that it should be. I understand that AI has been around for quite a long time, but only recently has it been ignited to the public and is used through numerous high-end companies (such as Google, Microsoft, Apple, you name it). I oppose this because Wikipedia is about humans checking the article. And yes, it would make it go faster, but it will make mistakes and those mistakes could time consuming for an individual (or a community) to resolve them. I think we should pilot it to a few selective articles rather than making it public to the entire Wikipedia articles. I think it's a great idea, no doubt, but we should be cautious when it comes to making it public for all without really piloting it. I have a couple more opinions on it, feel free to reach out if you want to. Jack Reynolds (talk to me | email me) 15:05, 19 March 2024 (UTC)
- First of all I appreciate your civil tone. I understand the lack of confidence on currently available AI platforms, and that implementing it site wide may bring issues, increasing the overall time to solve. But for that you said Wikipedia is about humans checking the article, I would also point that we have bots, which do not directly edit and cross check the articles (as a dystopian editor-less Wikipedia may have, and I oppose this), the bots have proven to be very effective in side tasks other than automating repetitive tasks. Bots like ClueBot NG are active examples. AI has wide applications, and I think that there are lot of applications to it on WP too, to some I oppose just like you, but others, like AI optimized simple search, or beta tested policy chatbots are some I have eyes on, as they rather than replacing existing resources, would only complement them. And as they say it, something is better than nothing (being added), especially when it is promising to look at. I would also like to know 'more opinions' you mentioned to have. ExclusiveEditor Notify Me! 15:37, 19 March 2024 (UTC)
- Comment: For those who oppose major change related to AI, the ai need not take a very inclusive part in Wikipedia's working for now, but a simple AI search like this would really ease the problem:
User: I am editing person's article, but she has lot of names, I want to write all of them, what I do?[1]
WP AI: I found the following results:
1.MOS:NAME: The guidelines talks about various cases in which the subject has Anachronistic names, Changed names, Multiple changed names, Pseudonyms and stage names, Hypocorisms, Nicknames etc. .....
or something I have seen many editors not knowing about:
Editor: I added name of subject in Hindi in information box at right side, but somebody removed it and warned me. Why?[2]
WP AI: I found the following guideline regarding the usage of Indic script (which the Hindi language is predominantly written in) in infobox:
WP:INDICSCRIPT: The guidelines says that per a consensus at 2017 request for comment, the use of Indic sript in India related articles is to be avoided for multiples reasons listed below:
1).....
2)......
3)......
This could be the possible reason that your edit was removed. For more information, you may ask the editor who reverted your edit for a response.
References
-- ExclusiveEditor Notify Me! 16:17, 19 March 2024 (UTC)
- Oppose: I anticipate little benefit to the Wikipedia project. Clarinetguy097 (talk) 17:10, 19 March 2024 (UTC)
- @Clarinetguy097: And how do you? ExclusiveEditor Notify Me! 17:26, 19 March 2024 (UTC)
- Oppose. Wrong page? This seems like a request for software rather than something that needs consensus. Any volunteer may create a user script or Toolforge tool that uses AI. –Novem Linguae (talk) 21:22, 19 March 2024 (UTC)
- @Novem Linguae: User scripts are add-ons that are commonly used by experienced users, while new editors are often unaware of them. Even mid-level editors may naturally find them uncomfortable to use. While volunteer-created scripts or tools are valuable, official integration ensures widespread accessibility and consistency across the platform. So I propose a direct integration of this feature in Wikipedia's interface, and so I started the discussion here. ExclusiveEditor Notify Me! 12:19, 20 March 2024 (UTC)
- Conditional Support. Using ChatGPT to augment the wikipedia search engine isn't a good idea. It hasn't been tested enough, isn't built for searching, and doesn't like certain queries (medical, legal, political, and anything containing the phrase "root access"). If Wikimedia wants to build its own AI to help with searching, however, then I do support this. DarklitShadow (talk) 21:49, 19 March 2024 (UTC)
- Comment: The Financial Times is just doing something similar with their internal content. We may do the same with Wikipedia's internal pages and (maybe conversations/ discussions also) for editors (especially new) as I already proposed. AI already serves Wikipedia's content for readers, with this editors may benefit from something similar for sure. ExclusiveEditor Notify Me! 07:29, 25 March 2024 (UTC)
- Using ai to help users find policy pages seems fine, but asking it for advice when it comes to editing conflicts seems like a poor idea. We already have the teahouse and help desk, and the likeliness of ai giving an incorrect answer is high. Industrial Insect (talk) 16:20, 25 March 2024 (UTC)
- @Industrial Insect: AI (if build in chatbot form) would not be asked doubts/ queries regarding existing policy known to editor. At max, AI will be given a problem faced by editor and AI will suggest pages which may be related to editor's problem. Reading the policy/ guideline page and deciding next move is solely editor's responsibility and choice. ExclusiveEditor Notify Me! 17:30, 25 March 2024 (UTC)
- Oppose An AI interpreting the policies and guidelines is simply asking for trouble. Nor is there a need, as pointed out above, to force anything official right now given that user scripts exist and the WMF may be carrying out its own research. CMD (talk) 16:48, 25 March 2024 (UTC)
- @Chipmunkdavis: No, no!! Never in my any statement have I ever mentioned that AI will come and interpret policy and suggest editors the next move. Sorry if I am being too expressive as lot of editors here are having same misunderstanding. Ok, so simply as it goes, AI is for new editors, so user script better be kept out of frame, also WMF does not look to have been actively sorting out in something specific before this proposal as seen in CAlbon (WMF)'s reply above. And to the troubles which we may face in this, first we have to start somewhere, second that implementation could be step by step. This cycle is just like an unemployed being denied a job because of lack of experience which he will never get without a job which he is being denied. The ending was not reply to you specifically but rather to the discussion as whole. ExclusiveEditor Notify Me! 17:38, 25 March 2024 (UTC)
- Also, at max, AI will be given a problem faced by editor and AI will suggest pages which may be related to editor's problem. Reading the policy/ guideline page and deciding next move is solely editor's responsibility and choice. ExclusiveEditor Notify Me! 17:40, 25 March 2024 (UTC)
- You gave a very specific example of an AI hearing a generic problem and deciding what guideline it thought applied. That is interpreting policy. Your example also specifically includes a suggestion of the editor's next move: "For more information, you may ask the editor who reverted your edit for a response." CMD (talk) 17:43, 25 March 2024 (UTC)
- @Chipmunkdavis: How can any AI/ algorithm work without interpreting its query and relate it to the search results. What you mean by 'interpretation' is the vary backbone of any AI that I could propose. Otherwise what is difference between current search bar which just cares to match the words you enter? The 'interpretation' I consider wrong is that WP AI is given specific cases by user, say related to NPV, and the AI presents a 'solution' rather than simple 'AI optimized search' that too based on its own 'interpretation' of WP:NPV just like there are different interpretations of Bible/ Quran. The last line For more information, you may ask the editor who reverted your edit for a response. is just a simple advice which may be made compulsory for AI as a disclaimer for issues related to 'warnings for unknown reason'. If you still oppose the idea, please list the reason and I will try to be more objective in answering those. ExclusiveEditor Notify Me! 21:33, 25 March 2024 (UTC)
- As I suggested earlier, I feel continuing to try to discuss your proposal without the involvement of those who are experienced and ready to start planning development isn't the best way forward. At present, this is discussion is about a hypothetical project where there are reasonable doubts about its viability, which means there isn't any impetus to work towards refining the scope and objectives. I think the proposal needs to have more concrete resources and expertise behind it in order to get better feedback. isaacl (talk) 20:36, 25 March 2024 (UTC)
- @Isaacl: I have indeed invited dozens of editors shown to have expertise/ special interest in AI or its branches since you last suggested. We even have the attention of director of machine learning at WMF. I will try to expand this over now, streamlining its focus as you said. Thank you. ExclusiveEditor Notify Me! 21:36, 25 March 2024 (UTC)
- I apologize for being unclear: personally, I do not recommend that you expand this discussion further. Instead, I think you should let those who are interested in planning development to drive the conversation, so that they can use their expertise and constraints to help direct further discussions. That will make it very concrete from both their perspective and the community's. Thanks for getting more people involved. isaacl (talk) 21:46, 25 March 2024 (UTC)
- @Isaacl: I have indeed invited dozens of editors shown to have expertise/ special interest in AI or its branches since you last suggested. We even have the attention of director of machine learning at WMF. I will try to expand this over now, streamlining its focus as you said. Thank you. ExclusiveEditor Notify Me! 21:36, 25 March 2024 (UTC)
- You gave a very specific example of an AI hearing a generic problem and deciding what guideline it thought applied. That is interpreting policy. Your example also specifically includes a suggestion of the editor's next move: "For more information, you may ask the editor who reverted your edit for a response." CMD (talk) 17:43, 25 March 2024 (UTC)
- Oppose Side note, it's unclear what is meant by "AI" in the proposal. Wikipedia has long had AI (it's search bar). I'm assuming the proposal meant generative AI. Strongly against that. Such is a black box with a mind of it's own. We don't need it to be presenting its creations as policies/guidelines or as interpretations of them. North8000 (talk) 18:15, 25 March 2024 (UTC)
- @North8000: Firstly, AI here does not directly indicate to generative AI, rather it may be complementary. Secondly, the first and foremost thing I propose(d) is AI in search bar, not just as significant as it looks on paper, but practically useful. It is the present 'tune' I say, that as anyone says AI, first thing in mind is ChatGPT and its fuzzy mistakes and/or the wrong hands that image making 'AI' hallucinates. Artificial Intelligence is much more that this, and I am sure many of you are clear to this. Now what if I assure you that the AI will make equal or lesser percent mistakes than ClueBot NG in terms of overall damage to Wikipedia? My point is that I am sure if I had proposed inculsion of bots to Wikipedia (assuming they weren't involved yet) I must have met a fierce resistance than I am getting now. By AI, I don't mean hallucinating ChatGPT or an AI which will make Wikipedia human editor-less but a algorithm that will better serve the knowledge gap regarding 'policies' and 'guidelines' to new editors, so they can edit without fear of getting 4 warnings quickly and blocked, all because they never knew what they were doing wrong. If you still oppose the idea, please list the reason and I will try to be more objective in answering those. ExclusiveEditor Notify Me! 21:26, 25 March 2024 (UTC)
Reworking Sandbox Heading[edit]
Hello! I am requesting that {{sandbox heading}} be changed to this:
Proposed sandbox heading text |
---|
|
Should this change be made? - Master of Hedgehogs (converse) (hate that hedgehog!) 18:31, 10 March 2024 (UTC)
- Yes, it should be changed to this version. 23.245.44.64 (talk) 18:34, 10 March 2024 (UTC)
- 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)
- Noting that I've left an invitation to this discussion at Template talk:Sandbox heading. All the best. —a smart kitten[meow] 19:35, 16 March 2024 (UTC)
Advertising sister projects[edit]
|
Should Wikipedia run a period of banners (one or multiple weeks) encouraging readers to use and edit sister projects? (previous discussion)
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)
- Notifying participants in previous discussion: @Aaron Liu, Harvici, Commander Keane, WhatamIdoing, Theklan, The Wordsmith, and Vghfr:
Survey (advertising sister projects)[edit]
- Yes as proposer. As I wrote previously:
- 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?
- 🌺 Cremastra (talk) 18:39, 15 March 2024 (UTC)
- 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)
- @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)
- 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)
- AndyTheGrump, could you please expand on how the projects are
worse
and the project thatis run in a manner entirely contrary to the stated objectives of Wikipedia
? — Frostly (talk) 21:14, 16 March 2024 (UTC)
- AndyTheGrump, could you please expand on how the projects are
- 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)
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)
- 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)
- @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)
- 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 (t c) 02:32, 16 March 2024 (UTC)
- 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 Marshall T/C 02:37, 16 March 2024 (UTC)
- 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)
- No as per above. Banner ads do not benefit the encyclopedia, which is our primary concern. LEPRICAVARK (talk) 14:12, 16 March 2024 (UTC)
- 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)
- 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)
- By that logic, every proposal here is detrimental because they take time away from editing articles. 🌺 Cremastra (talk) 12:55, 17 March 2024 (UTC)
- 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)
- By that logic, every proposal here is detrimental because they take time away from editing articles. 🌺 Cremastra (talk) 12:55, 17 March 2024 (UTC)
- 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)
- 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)
- 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)
- 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)
- 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)
- 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)
- 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)
- 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 Genius talk 12:03, 18 March 2024 (UTC)
- @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)
- How would showing readers advertising possibly help them? Modest Genius talk 12:02, 19 March 2024 (UTC)
- See Queen of Hearts' comment below. 🌺 Cremastra (talk) 12:19, 19 March 2024 (UTC)
- How would showing readers advertising possibly help them? Modest Genius talk 12:02, 19 March 2024 (UTC)
- @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)
- 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 Hearts she/theytalk/stalk 20:30, 18 March 2024 (UTC)
- 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)
- Yes per leeky. General support for the idea, without committing to doing all of them (after all, we can't say too much about the Incubator, Meta, etc.). — Rhododendrites talk \\ 03:39, 19 March 2024 (UTC)
- No - Advertising (especially in banner form) is annoying and intrusive, distracting and wasting of screen space. It doesn't matter how noble or sororal the entity being advertised. We already link to the sister projects in the main page (left panel and bottom) and we routinely mention relevant sister projects explicitly from articles where applicable (many articles include templates linking to specific pages on Commons, Wikivoyage, Wiktionary) and link inline where appropriate, most often via images. Mitch Ames (talk) 07:40, 19 March 2024 (UTC)
- No, good points above on the value of ads and on being cautious with the power of en.wiki within the WMF ecosystem. On a pragmatic note, a general link to go look at WikiSource or WikiData or even WikiCommons is of any use. How to contribute to those is opaque at best. If these resources are promoted, it should be through specific useful ways, such as our practice of including relevant WikiSource pages in See also sections (occasionally they pop up in infoboxes too). CMD (talk) 07:53, 19 March 2024 (UTC)
- Yes, as leeky put it. Other sister projects are very well what readers may be looking for, like WikiVoyage or Commons. There should be an option to opt-out though. Cocobb8 (💬 talk • ✏️ contribs) 12:59, 19 March 2024 (UTC)
- No to all forms of distracting and inappropriate advertising. There will always be sound and moral reasons behind any banner campaign - I'd like us to allow various charitable banners which fund-raise to help starving children, or prevent climate change, etc. But Wikipedia was set up not to be such a platform, and so it seem highly inappropriate and immoral and incestuous that we don't allow banners which may improve or even save people's lives, but will allow banners purely to inflate the traffic flow of various WikiMedia projects. If there is an appropriate need to link to another project, that is already done within articles, such as via External links. SilkTork (talk) 14:26, 19 March 2024 (UTC)
- No per SilkTork. Besides, a lot of people, both editors and readers, are already frustrated by the endless, huge banner ads that get foisted on articles every December, grubbing for money for the WMF. We don't need to add to that. Writ Keeper ⚇♔ 14:37, 19 March 2024 (UTC)
- No due to banner blindness, and due to the fact that just because a project is a sister project doesn't mean it's a good project. I just don't see the value in telling readers about other projects. BTW, I also would oppose a banner that encouraged people to edit this project. I'm generally opposed to taking up screen real estate to try and recruit readers, let the readers read in peace without distraction. BTW, the way to let readers know about sister projects they may find useful is "inline," the way we do it now, with those boxes/links/hatnotes/whatever-you-call-them that say, e.g. "full text is available at WikiSource," or "there is an entry at WikiData," or "there is media on Commons," etc. It's better to put those more-targeted notices in the place where they'll matter. Levivich (talk) 17:18, 19 March 2024 (UTC)
- No as conceptually wrong. Very, very, VERY few people, even linguaphiles, are hardcore "let me sit down and read the dictionary some" types. Similarly, even people who love reading books aren't going to be enticed by "oh hey, let me go to the local library and pick some books at random" from Wikisource or Wikibooks. And yet that's precisely what these suggested banners provide: essentially a link to the front door of the library, or to a full dictionary. What is far more effective is a relevant link for a word or topic that the reader has already shown themselves interested in, hence them being at an article in the first place. So something like The_Red-Headed_League#External_links having its first EL being to Wikisource? Great. The reader is interested in the topic, here's a link to where you can read the story on Wikisource. Or disambig pages including a prominent Wiktionary link, especially for less-used words or foreign terms like Anabasis. There's an argument we should link sister projects when relevant more aggressively, sure. That might be a good way to spend time. But these banners don't have any relevance, and therefore aren't useful. SnowFire (talk) 20:19, 21 March 2024 (UTC)
- No. Unnecessarily distracting and annoying. Stifle (talk) 12:04, 22 March 2024 (UTC)
- Yes, but with opt-in, because banners can be annoying.--OrdinaryGiraffe (talk) 01:08, 24 March 2024 (UTC)
- Possibly opt-out? Of course users should have the right to opt-out of showing the banners. 🌺 Cremastra (talk) 01:10, 24 March 2024 (UTC)
- Rather than asking readers to take an action to see banners about other Wikimedia sites, we may as well just ask them to visit another page to learn about other Wikimedia sties. isaacl (talk) 01:28, 24 March 2024 (UTC)
- No. The current central banner system is somewhat sufficient for this purpose. Even if we want to work on the sister projects, one has to be cognizant that every project has different levels of maturity and sets of social norms. We shouldn't be the ones pushing ourselves and sensibilities over to the other projects. If so, can the targeted project take on an influx of editors who are bringing a foreign set of norms and sensibilities over to their projects? As one who occasionally straddles between English and Chinese Wikipedias, as well as commons, I can say that it takes awhile to pick up the norms of the individual projects, an effort that would likely be significantly longer than the run on the banner. If the other projects would like to have us and other projects to contribute, have them to come up with their own campaigns, banners through the central banner system, and processes. If anything, I think improvements in other parts of the interface may be more feasible, for example a better call-out to translate the article if it is known that the viewer is good in a certain language, or call outs somewhere to contribute to wikivoyage if somehow we know if the viewer is actively editing in geographic based articles, Wikisource if one is editing articles related to manuscripts or other types or texts and printed materials. – robertsky (talk) 12:25, 25 March 2024 (UTC)
General discussion (advertising sister projects)[edit]
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)
- 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)
- 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)
- And how much space will the banners take up on mobile screens? Donald Albury 20:08, 15 March 2024 (UTC)
- 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)
If banners were approved and shown, how would you determine whether they were worth the effort? Schazjmd (talk) 20:11, 15 March 2024 (UTC)
- 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)
- 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. Sdkb talk 21:16, 15 March 2024 (UTC)
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)
- 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)
- 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)
Create an alias for the Template namespace[edit]
|
I am proposing that tp:
be added as an alias to the Template:
namespace per this discussion.
Note: Though previous aliases were already listed on perennial proposals, it proposed t:
, which would have conflicted with some article titles, or be confused with the Talk:
namespace. Tp:
, on the other hand, wouldn't, and would make it way quicker to look up a template in the search bar.
Edit (during rfc): tp:
was not fully supported due to it being confused with "Talk Page", however other options were proposed, like hard coding {{
being replaced by Template:
in the search bar. Cocobb8 (💬 talk • ✏️ contribs) 15:19, 16 March 2024 (UTC)
- 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)
- I just thought it'd make it consistent with
wp:
forWikipedia:
, which is 10 characters, whileTemplate:
is 9 characters. Cocobb8 (💬 talk • ✏️ contribs) 15:29, 16 March 2024 (UTC) 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)
- I just thought it'd make it consistent with
- 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)
- Support per Schazjmd. 🌺 Cremastra (talk) 15:57, 16 March 2024 (UTC)
- 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)
- Support: Pretty nice QOL change. Per Schazjmd. ARandomName123 (talk)Ping me! 16:35, 16 March 2024 (UTC)
- 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)
- 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)
- 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)
- For reference, the script seems to be User:Ahecht/Scripts/TemplateSearch. jlwoodwa (talk) 04:53, 18 March 2024 (UTC)
- 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)
- 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)
- "tp" seems very easily misconstrued as "Talk Page" at a glance. CMD (talk) 18:12, 16 March 2024 (UTC)
- 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) - Comment: Unless I'm missing something, the
TP:
prefix was proposed in 2015, in a discussion which was closed as no consensus - Wikipedia:Village pump (proposals)/Archive 127#Prefix suggestion: TP: for Template:. All the best. —a smart kitten[meow] 19:00, 16 March 2024 (UTC) - 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)
- 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)
- @Phil Bridger tl is ISO639 for tagalog. — xaosflux Talk 22:20, 16 March 2024 (UTC)
- {{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)
- 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
{{
toTemplate:
, a namespace shortcut (tp:
) would help in edit summaries and customised browser search boxes. -- Michael Bednarek (talk) 23:55, 16 March 2024 (UTC) - 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. WritingTp: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) - 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)
- Rename the template mainspace from "Template:" to "Plantilla:" and use "Pl:" as a shortcut CactiStaccingCrane (talk) 18:02, 18 March 2024 (UTC)
- 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 theWP
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)- @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)
- @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
- neutral i could go either way. I like the hard coding option of having 'template' be dropdown option in the menu. Slacker13 (talk) 01:29, 20 March 2024 (UTC)
- Support – I don't think that adding the
t:
will add an another level of obfuscation. The current method of making interwiki link is already obscure and complicated, specially for newbies, instead a simple alias to the template namespace will be easy and handy in researches. -- ZandDev 13:57, 20 March 2024 (UTC) - Oppose I do work with templates but I feel that this is not an intuitive shortcut and could easily be confused with "talk page". (t · c) buidhe 04:57, 21 March 2024 (UTC)
- Support , I had typed TP: prefix in the past thinking that I would get the template page without success. This would be useful in different scenarios (just like the WP: prefix). And its use is optional, so if someone doesn't like it, they can go with the full Template: as ever. Alexcalamaro (talk) 05:32, 21 March 2024 (UTC)
- Oppose. Unnecessary, and just as with T=Talk, TP=Talk Page. wjematherplease leave a message... 08:01, 21 March 2024 (UTC)
- Neutral Agree with the principle, would prefer access to a shortened version; but also agree that the proposal is too close to talk page. Regards, --Goldsztajn (talk) 22:08, 21 March 2024 (UTC)
- I think supporting
{{
in the search bar would be sufficient to support the use case of issue. But beside that, I agree with oppose comments above. Izno (talk) 02:48, 22 March 2024 (UTC) - Oppose per above. Not intuitive and I'm not convinced this solves a genuine problem -Fastily 21:26, 24 March 2024 (UTC)
- Strong support because I have typed "Twmplate" in the search bar too many goddamn times. Mach61 21:03, 26 March 2024 (UTC)
- Support: I have to do everything on mobile, and am looking up templates all the time. This would make that a significantly less laborious and typo-prone experience. But I'd be happy with some other 2- or 3-letter shortcut if TP: is a problem. No more than 3 letters, though. Also I keep typing TP:, TMP: or TPL: without thinking, expecting them to work. But I only want it for search purposes. I'd be opposed to its use as jargon for referring to templates. — Preceding unsigned comment added by Musiconeologist (talk • contribs) 01:34, 28 March 2024 (UTC)
Showing "Redirected from" notice at top of section[edit]
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?
- 2A02:560:5829:B000:7D78:FB68:39A:4A28 (talk) 16:22, 16 March 2024 (UTC)
- 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)
- 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.
- - 2A02:560:5829:B000:7D78:FB68:39A:4A28 (talk) 22:46, 16 March 2024 (UTC)
- Good idea. Cuts down on confusion. How it would be implemented is another question. 🌺 Cremastra (talk) 17:17, 16 March 2024 (UTC)