[go: nahoru, domu]
Jump to content

Wikipedia:Village pump (proposals)

From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by Thebiguglyalien (talk | contribs) at 18:22, 12 September 2024 (→Early close: yes). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

"WP:PROPOSE" redirects here. For proposing article deletion, see Wikipedia:Proposed deletion and Wikipedia:Deletion requests.
 Policy Technical Proposals Idea lab WMF Miscellaneous 
Shortcuts

The proposals section of the village pump is used to offer specific changes for discussion. Before submitting:

Discussions are automatically archived after remaining inactive for nine days.

Bot to correct issues in cite news and cite web

For sources that are not the primary topic, such as ABC News (Australia), it is common for citations to link to the "work" wrong target, such as ABC News which, prior to the recent move, was the article for the American source.

In the case of this ABC News, there are hundreds of articles with broken links, such as LGBT rights in Afghanistan.

It is even more common for it to omit a link to the "work", either displaying it in plain Wikitext or not at all. This excludes important contextual information, and goes against MOS:UL which says that proper names that are likely to be unfamiliar to readers, which would include news sources as few have global recognition, should be linked.

In the case of this ABC News, there are thousands of articles with missing links, such as Joel Reddy.

Following a discussion with Robertsky, I proposed a bot that would be able to rectify one or both of these issues, as well as add additional information to the citation template that can be determined from the URL or other content already in the template, such as the publisher or publication location.

To minimize impact on watchlists, it can be configured so that only some errors or omissions will trigger an edit, with the rest being done only if the article is already being edited.

I am raising this in the community now to determine whether the community believes that this task is worth completing.

In addition, the bot uses a configuration file that I would need the communities help to expand. Currently, it addresses issues with the following sources:

Please provide details for the other sources that you wish to see corrected by leaving a comment on the configuration talk page, or if you are sufficiently familiar with JSON to understand the configuration file by editing it directly. BilledMammal (talk) 09:02, 25 August 2024 (UTC)[reply]

Overall, I support more frequently linking publication names. For an article that doesn't use them, though, it should be kept consistent. Sdkb talk 22:41, 25 August 2024 (UTC)[reply]
I’ve already touched on this, with the above reference to WP:UL, but to address it in a little more depth in regards to consistency:
First, I don’t think we want to follow the pattern of the majority of the article, as in most cases they will be unlinked solely because RefToolbar doesn’t add links rather than because of any deliberate editor choice.
Second, a sufficiently expansive configuration file will be able to switch from unlinked majority to linked majority.
However, I would be able to alter the program to not include links under certain circumstances if that is what the community would prefer. BilledMammal (talk) 23:19, 25 August 2024 (UTC)[reply]
add additional information [...] such as the publisher or publication location. If that's done, it should be VERY selective, erring on the side of omission. Cites for The New York Times do NOT need to show that the publisher is A. G. Sulzberger or that the publication location is New York City. Et cetera. Bots should reduce work for human editors, not create work for them; we have too much of the latter already. ―Mandruss ☎ 22:44, 25 August 2024 (UTC)[reply]
New York Times is actually a very convenient example, as it is already in the configuration file.
Not only will it not add the publisher or publisher location, it will actually remove them if it is already editing a page, in accordance with the specifications at {{cite news}} BilledMammal (talk) 23:09, 25 August 2024 (UTC)[reply]
Ok, provided equally sound judgment is applied to all cases. I'll take that as a matter of faith. ―Mandruss ☎ 23:31, 25 August 2024 (UTC)[reply]
Just fyi, I think BattyBot (operated by GoingBatty) already did some of the things listed here before it stopped working (see this and this). ~ F4U (talk • they/it) 03:43, 4 September 2024 (UTC)[reply]

Enable Meta:CampaignEvents feature on this Wiki

The Foundation has developed a new tool at Meta:CampaignEvents which is used by other editions of Wikipedia. Anyone who organizes an Edit-a-thon knows the event management tooling is quite limited and requires lot of behind-the-scene knowledge for promotion of events.

If you believe English Wikipedia should try this feature out, please support this proposal. It does not remove any existing options or require people to use this over other forms of event management. In order to set this up, we need to establish consensus to try it out and then file a Phabricator ticket request, which I am happy to do. See the recent talk from 2024 Wikimania about it here on Youtube and notes from the same session. Here are the slides.

In the past I organized edit-a-thons using the Outreach Dashboard which helped with tracking contributions, but not collaboration between editors (see here). I am also happy for English Wikipedia to try tooling that is used by other language editions of Wikipedia and contribute insightful feedback in order to make these tools useful. ~ 🦝 Shushugah (he/him • talk) 22:24, 29 August 2024 (UTC)[reply]

Has the support team been looped in on this? There are 3 projects using so far, and it would be useful to know any outstanding issues. Also note, this requires a permission group (c.f. meta:Meta:Event_organizers) that we'd have to determine how to deal with. (some options: WP:PERM, autopromote). — xaosflux Talk 22:44, 29 August 2024 (UTC)[reply]
I would suggest (if we do this) repurposing the existing "event coordinator" group as "event organizer". * Pppery * it has begun... 22:51, 29 August 2024 (UTC)[reply]
The description says "enhance the management and visibility/discoverability of events within Wikimedia". That certainly sounds like a good thing.
But going off on a tangent, as a checkuser, one thing I'd love to see is some way for an event coordinator to register the IP address(s) which are going to be used at the event, and having that be visible in the checkuser tool (@Dreamy Jazz). One of my suckiest CU experiences was blocking a whole pile of socks only to discover after the fact that what I really did was stomp on a perfectly legitimate "Learn to use Wikipedia" event for 13 year olds. There would be much awesomeness if a notification about that could come up in the tool. RoySmith (talk) 23:06, 29 August 2024 (UTC)[reply]
I have not yet, but will ask a WMF Staffer to come here for comments. There is a recent video recording from the 2024 Wikimania. Currently available on Youtube. Repurposing WP:Event coordinator sounds excellent. ~ 🦝 Shushugah (he/him • talk) 23:06, 29 August 2024 (UTC)[reply]
Thanks for bringing this up. Regarding this tool, what are the specific implications for en.wiki? Based on Meta:CampaignEvents, it currently has two tools, Registration and Event list. I would assume we would not want Registration here, as that seems to involve the creation of a new namespace (Event:) and is a task better suited for Meta. Conversely, the Event List seems like something people may want to casually have access to, and thus locking it behind the Wikipedia:Event coordinator perm (ie. at the same level as being able to generate unlimited new accounts on a single IP) feels limiting. CMD (talk) 06:28, 30 August 2024 (UTC)[reply]
You can directly edit as a user this event: Meta:Event:Sandbox/Shushugah/Testing without any special permissions on Meta. And same would be true for English Wikipedia if approved here
We should have the Event namespace in English Wikipedia. While only users with event creator can "register" the event, any editor can still edit the content and description with project updates. To-do lists etc..
Meta:Main might be better suited for multi-wiki events it also requires advanced knowledge of Help:Interwiki syntax and is not very new user friendly. Copying and pasting a list from enwp project page to Meta wouldn’t simply work and would require juggling two different accounts. ~ 🦝 Shushugah (he/him • talk) 15:00, 30 August 2024 (UTC)[reply]
Is there an advantage to adding the new namespace on en.wiki in the days of unified accounts when new users can post on meta too? CMD (talk) 13:57, 31 August 2024 (UTC)[reply]
I mentioned a few cons, namely that wikilink templates would break, templates are not usable across different Wikis, the watchlist is separate for each. For advanced users this might be acceptable but for new users explaining difference between Meta and enWP would be a very high hurdle and counterproductive. ~ 🦝 Shushugah (he/him • talk) 14:01, 31 August 2024 (UTC)[reply]
I think it would be technically possible to do this. I would suggest filing a Phabricator task, with the Campaigns and the Trust and Safety Product Teams tagged so there is visibility by both teams. Dreamy Jazz talk to me | my contributions 14:08, 1 September 2024 (UTC)[reply]
T373764 RoySmith (talk) 14:58, 1 September 2024 (UTC)[reply]
Hello, everyone! My name is Ilana, and I’m the product manager for the Campaigns team, which developed the CampaignEvents extension. Thanks for bringing up this topic, @Shushugah, and thank you for your responses and feedback, @Xaosflux, @Pppery, @RoySmith, and @Chipmunkdavis. I’ll respond to the questions and comments so far below, and I’m happy to respond to any other questions that come up:
  • The CampaignEvents extension has three features: Event Registration, Event List, and Invitation Lists. Wikis can choose which features to enable. The extension is currently enabled on Arabic Wikipedia, Igbo Wikipedia, Swahili Wikipedia, and Meta-Wiki.
  • Event Registration was first released to Meta-Wiki in November 2022. It has been used in 600+ events with over 10k participants. The Event List was released in April 2024, and we’re now expanding it to feature WikiProjects as well (see T368115). Invitation Lists is our newest feature. It is testable on the beta cluster (see video demo), and we’re planning to release to Igbo Wikipedia & Swahili Wikipedia soon.
  • The extension has two sides: an organizer side and participant side. The participant side requires no special rights for access. The organizer side requires the Event organizer right for access. Wiki admins set the criteria for and manage the right. We are open to comments on how the right can be configured or expanded. We love the idea of bundling it with the Event coordinator right.
  • The extension comes with two new namespaces: event and event talk. You can read our rationale for why the namespaces were created. Overall, we think that there are many advantages to keeping the two namespaces, but we’re open to other ways that communities may want to define event pages. So, we are curious to hear what others think on the topic!
  • In the near future, we are hoping to integrate Community Configuration (T370829). This way, wiki communities can choose to turn on the extension, and they can choose which tools to turn on and how they should be configured.
  • I have a question for you all: How do you feel about my team inviting some organizers and/or users of the CampaignEvents extension into the conversation? Perhaps they can provide some more context. Since the extension is enabled on Meta-Wiki, we already have users from many different wiki communities.
Thank you! IFried (WMF) (talk) 21:30, 30 August 2024 (UTC)[reply]
@IFried (WMF) is there a phab workboard for this? I'd like to be able to see all open bugs. — xaosflux Talk 22:58, 30 August 2024 (UTC)[reply]
Hi, @Xaosflux. Yes, all our team work for organizer tooling can be found in the Campaign-Tools workboard. This board includes bugs, feature requests, and features that we're working on or plan to work on. We also have the CampaignEvents workboard, which specifically focuses on the extension and it has a bug column that you can check out. IFried (WMF) (talk) 23:36, 30 August 2024 (UTC)[reply]
Is there a reason the invitation list is not listed as one of the features alongside the Event Registration and the Event list on the main meta page? Anyway, if the features are separately toggleable, it sounds like enabling the overall extension is only beneficial and separate discussions can be had on the existing and upcoming features. CMD (talk) 07:50, 1 September 2024 (UTC)[reply]
Invitation list is a very fresh feature with some tickets still being worked on so that would explain why it's not mentioned yet. In any case, with Community integration coming soon, it will be easier for admins to automatically activate/de-activate features based on our wishes. I am quite curious whether embedding/transcluding the Event list in different namespaces is possible, e.g a Wikipedia Talk namespace for a WikiProject talk page. @IFried (WMF) what would be best way to test this assuming it's approved? I guess Admins/Event Coordinators would be the subset of people who could create events. Can you envision this tool being useful for backlog-drives? Is there any paper/findings about how Events have been used/evolved? ~ 🦝 Shushugah (he/him • talk) 22:57, 1 September 2024 (UTC)[reply]
Hi @Shushugah & @CMD! Great questions, which I will respond to below:
  • Why isn’t Invitation Lists on the CampaignEvents page? We just updated the page with information on Invitation Lists. We previously didn’t include this information, since Invitation Lists was not yet available to any live wikis. However, we just released Invitation Lists to all wikis with the extension (T373041), which means all such wikis can opt to enable it. It has also been enabled on Swahili & Igbo Wikipedia (T372582). For these reasons, the page has been updated, and we’re open to any feedback on the tool or interest from communities that would like to enable it.
  • Can we transclude the Event List onto a page in a different namespace?: No, there is currently no ability to do this. However, we’re interested in learning more about this request on the project talk page or in Phabricator. We’re especially interested in learning what problems would be solved by developing such a feature improvement. Thank you for bringing this up, and we look forward to learning more!
  • Can the tools be used for backlog drives?:
    • Yes, we think all three tools in the extension can be useful for backlog drives. With Event Registration, organizers can set the infrastructure in place for managing participation in the backlog drive. They can register participants, collect optional demographic information, and communicate with participants via mass email. With Invitation Lists, organizers can find people to invite who have demonstrated interest in the topics covered in the drive. With the Event List, organizers can promote the backlog drive to a wider audience. Overall, Event Registration can be used for many different types of activities, and we encourage organizers to use the tools in ways that work for them.
    • My colleague, @Astinson (WMF), an experienced editor on English Wikipedia, shared another use case: He signs up for backlog drives, but then sometimes he forgets to come back and work on them (like the Wikipedia:New pages patrol/Backlog drives/September 2024). He shared with me that the Event Registration tool could help organizers remind participants like him to participate in collaborative work.
  • Are there any papers/findings for how events have been used or evolved?:
    • We do not have an official paper like you mentioned. However, our work was initially inspired by the findings from the Movement Organizers study, along with other studies (see Evidence). Since the launch of our team, we have conducted regular office hours to collect feedback on our work. We have also launched surveys (for example, V0 findings). In the case of Invitation Lists, we conducted an experiment on its potential efficacy and published our findings (see April 2024 update).
    • Event Registration is being used for a wide range of event types, such as campaigns (example), edit-a-thons (example), training sessions (example), hackathons (example), affiliate meetings (example), office hours (example), and conferences (example).
    • Both Event List and Invitation Lists are quite new, but they’re focused on making events more discoverable on the wikis. We look forward to seeing what we can learn from them.
  • We have a survey: On the topic of continually learning, we have a survey that is going on now. We’re exploring how the toolset could be expanded for other collaboration tactics (i.e. WikiProjects, collaboration groups, tasks forces, etc). We want to see if and how the infrastructural pipeline in the extension (i.e., discovery of potential participants, registration, and communication) could be helpful to WikiProjects and other forms of collaboration on the wikis. In that case, we encourage folks to take part in our survey, and we’ll share our findings once the survey is complete: https://docs.google.com/forms/d/e/1FAIpQLScKWHPjSjSqOmca8E-eQl1HHUxYRbB4QeEV3zR2bd1_tcwuMg/viewform?usp=sf_link
Thank you for all of the great questions so far, and I am happy to answer any more questions that may come up! IFried (WMF) (talk) 23:13, 4 September 2024 (UTC)[reply]

Temporary override of existing protection, falling back after expiration

Tracked in Phabricator
Task T41038

I have often wished that there was a feature in the page protection options to assign a different protection to an already-protected article for a short duration, and when that different protection expires, it falls back to the original protection level. Whatever the current protection level is, it resumes when the temporary override protection level (which could even be "none") expires.

Use cases:

  • Content dispute between editors on a semiprotected article: I'd like to override that for a week and apply a higher protection (ECP or full as appropriate), and when it expires, the semiprotection resumes and runs it course as usual.
    • The current behavior is for the article to become completely unprotected at expiration.
  • Experimental unprotection: RFPP requests to unprotect could have the new protection level (none) override the current protection on a trial basis for a finite duration, after which the original protection resumes. This might be related to a past discussion Wikipedia:Village pump (proposals)/Archive 38#Temporary lifting long-term semi-protection of featured articles, but I would like to see just a general temporary override feature available for any article.

We currently have a pseudo-situation like this with PCP. Any protection other than "none" overrides PCP and when that protection expires, PCP goes back into effect. I am asking for temporary overrides to any protection level regardless of what it is. ~Anachronist (talk) 05:49, 31 August 2024 (UTC)[reply]

Not sure how technically feasible this is, but the first use case definitely happens all the time, and often leads to articles becoming unprotected that really ought not to be. So this is at minimum seeking to address a real problem. Sdkb talk 05:53, 31 August 2024 (UTC)[reply]
There's currently a BRFA for a bot that would handle the re-protection: Wikipedia:Bots/Requests for approval/Protection Helper Bot. Anomie⚔ 12:21, 31 August 2024 (UTC)[reply]
That would work too, except for the case of experimentally unprotecting, but that is low-priority compared to the first use case I described. I wasn't aware of that bot. I hope it can be approved. ~Anachronist (talk) 17:06, 31 August 2024 (UTC)[reply]

Page views link in the Tools menu

The Tools menu.
Same menu, but with an extra "Page views" link.

Last month, {{Annual readership}} was nominated for deletion. The Graph extension which the template used was turned off on 18 April 2023 due to a security issue. After that, the Annual readership template was changed into just a text with a link to pageviews.wmcloud.org.

Annual readership is currently used on 53,510 talk pages. The consensus on the TfD appears to be that the template should be kept, but noincluded and made invisible, pending a solution for the Graph extension.

In the same TfD, I proposed a "Page views" link in the tools menu as an alternative of sorts. See the included screenshots. Right now, the link to the page views tool is carefully hidden in: Tools -> Page information -> scroll all the way down -> External tools -> Page view statistics. Could we perhaps make the page view link appear more prominently?

I know there are scripts like User:PrimeHunter/Pageviews.js, but it would be nice if the button appears by default, regardless of whether a user is logged in or not. Cheers, Manifestation (talk) 18:34, 7 September 2024 (UTC)[reply]

For more info see:
Wikipedia:Templates for discussion/Log/2024 August 25#Extra link in the tools menu?
Few editors, and fewer average readers, are aware that the page views link is on the "page information" page:
Tools menu > Page information > Page views.
--Timeshifter (talk) 19:41, 7 September 2024 (UTC)[reply]
For me, the length of the Tools menu makes it harder to find specific items that I'm looking for. Thus I prefer that the page view link remain grouped under the page information menu item. isaacl (talk) 21:18, 7 September 2024 (UTC)[reply]
I think the "Print/export" section of the the tools menu could be consolidated and be put on a page called "Print/export". So that would consolidate 3 lines in the tools menu to one link. That would leave room for a page views link on the tools menu. --Timeshifter (talk) 11:04, 8 September 2024 (UTC)[reply]
A link to page views is also available in the "External tools" bar near the top of the history page. Thryduulf (talk) 21:21, 7 September 2024 (UTC)[reply]
That's a pretty obscure location for the average Wikipedia reader. --Timeshifter (talk) 09:58, 9 September 2024 (UTC)[reply]
I don't feel that Page views is that much more important than the other external tools linked in page information and page history. Personally, I use Revision history statistics more. Obviously adding them all would be too much clutter though, so I wouldn't propose that as an alternative. ― novov (t c) 03:12, 8 September 2024 (UTC)[reply]
So you feel that "page views" is a little more important? So then it should replace something less important.
Concerning revision history, I assume you are talking about the "View history" link at the top of nearly all pages? I agree that is very important. But we are not asking for the page views link to be put at the top of pages. --Timeshifter (talk) 10:54, 8 September 2024 (UTC)[reply]
I'm talking about the Revision history statistics tool, which is also in the page information. What I'm saying is that there's no reason why page views should be added to the tools menu when it's not been proven that it's "special" compared to the other things, and page information is in there anyway. ― novov (t c) 01:51, 9 September 2024 (UTC)[reply]

The average Wikipedia reader is more interested in page views than those arcane statistics. --Timeshifter (talk) 09:58, 9 September 2024 (UTC)[reply]

Put page views link in talk header template too

I say do both. But if not in the tools menu, let's start here in the talk header template. We could remove {{annual readership}} from all talk pages, and use this location instead. This way the number of links to page views on talk pages goes from around 53,000 to 726,000 talk pages.

{{talk header}} is on around 726,000 article talk pages out of 6,906,541 articles. {{NUMBEROF|ARTICLES|en|N}}. That is around 11% of articles.

Note that there is room on the left side for a page views link. --Timeshifter (talk) 11:42, 8 September 2024 (UTC)[reply]

This talk page header already has a lot of clutter. I am against adding anything else to it; if anything, it should be simplified. ― novov (t c) 01:54, 9 September 2024 (UTC)[reply]
{{talk header}} has been developed over a long time. There is agreement on what is there now. So I think you are in the minority on that. Adding a page views link there justifies hiding or deleting {{annual readership}}. So that means less stuff on the talk page. --Timeshifter (talk) 09:51, 9 September 2024 (UTC)[reply]
It doesn't help anyone else, but if you personally want a more concise talk page header I recommend adding to your user style:
#talkheader tr:has(> td > .talkheader-body) { display:none; }
this cuts most of it out but leaves the search box. –jacobolus (t) 15:42, 9 September 2024 (UTC)[reply]
It is true that the content in the white box isn't at all relevant for experienced editors. I'd be interested to consider a proposal not to display it for those editors. Sdkb talk 03:37, 12 September 2024 (UTC)[reply]
I have recently come to the conclusion that promoting page views information to editors is a bad idea. Here's why: the page views for most articles are very low.
I pulled the page views counts for all of 2023 for a random set of 10,000 articles. 90% of articles get less than 10 page views per day. 70% get less than 1 page view per day. Almost 40% of them get less than 1 page view per month.
Please imagine for a moment that you have created an article, or you decided to improve it. Then you look on the talk page and discover that the number of page views is far lower than you expected. A metric that never really mattered to you before has been put in your face, and now you feel discouraged. Metrics that might align better with your own values (e.g., how grateful a reader was to find information on such an obscure topic) are not available and will not be surfaced to you. We're just going to tell you that 40% of your articles are probably pointless. Or 70%, if you thought one reader a day was enough. Or 90%, if you'd hoped your efforts would help "only" 10 readers a day. My point is, for most articles, this is not a feel-good metric. This is a feel-bad metric, and we should be cautious about promoting it indiscriminately.
BTW, if you'd like to figure out how your favorite page compares, then here are a few key numbers:
  • 100K page views per year: top 1%
  • 10K page views per year: top 5%
  • 1K page views per year: top 20%
  • 100 page views per year: top 40%
WhatamIdoing (talk) 06:23, 12 September 2024 (UTC)[reply]
Though I agree that page views can be surprisingly low sometimes, I think your methodology is possibly flawed; editors don't just edit random articles. I would imagine that articles that are edited more tend to get more views, as there is most likely some overlap between reader interest and editor interest. ― novov (t c) 06:54, 12 September 2024 (UTC)[reply]
I agree that editor interest is non-random, but that means it will be worse than average for some editors. If your niche happens to be an unpopular one, then you could find yourself looking at evidence of its unpopularity very frequently.
The opposite is also true: if you happen to be impressed with the page views an article is getting, then you might feel the stakes are much higher. There can be no compromise when so many people are going to read this, right? Everything's got to be perfect. Don't be bold; be very, very, very careful. The next thing you know, editors are thinking about the fact that almost a million people read Cancer a year. Someone could die! (I'm going to die. We're all going to die.) We need editors thinking about the work that needs to be done, rather than being focused on the popularity of the page. WhatamIdoing (talk) 07:12, 12 September 2024 (UTC)[reply]
I actually do pay attention to page views for articles I work on, but I am comfortable going to the page history to access them. Very low page views for a given article can be disappointing, but every once-in-a-while something in the news will cause a hundred- or thousand-fold spike in page views for such an article, and I then take satisfaction in knowing that we had some background on the topic available to the reading public. Donald Albury 12:18, 12 September 2024 (UTC)[reply]

Make search field permanently visible

Invariably the first thing I want to do after landing at the Wikipedia home page is search for the article that I want to look at. I think it would be sensible to make the search field permanently visible. There is already room there at the top of the page, and although only a click away, it seems unnecessary to have to click on the magnifier. Why not just have the field there ready to type into? Am I right in thinking that it used to be that way? I wonder why it was changed. 2A00:23C8:7B0C:9A01:8A7:5D88:5F57:107E (talk) 19:53, 8 September 2024 (UTC)[reply]

I think the magnifying glass only appears when the window is narrower than some threshold (looks like about 1100 px). I'm not sure why they do that; there's plenty of space left at all but the most extremely narrow widths to allow for a full search box. But in any case, this is really a Vector 2022 skin issue, not something enwiki has any direct control over. Perhaps ask on meta:Talk:Reading/Web/Desktop Improvements? RoySmith (talk) 20:04, 8 September 2024 (UTC)[reply]
You're right, it's dynamically controlled. I didn't realise that. When I lower the browser zoom level the search field becomes visible. It seems to me that all that needs to be done is adjust the "trigger" level at which it is displayed, so it is only suppressed when there is "obviously" not enough room to type a search query. 2A00:23C8:7B0C:9A01:8A7:5D88:5F57:107E (talk) 20:32, 8 September 2024 (UTC)[reply]
Yes, but to repeat what I said earlier, this is not anything that is under the control of enwiki. This is a feature of the Vector 2022 skin, which is under the control of the Wikimedia Foundation web team and best discussed at meta:Talk:Reading/Web/Desktop Improvements. RoySmith (talk) 20:50, 8 September 2024 (UTC)[reply]
Page does not exist / link does not work, though actually I see now that there is another link there pointing to the correct page. 2A00:23C8:7B0C:9A01:8A7:5D88:5F57:107E (talk) 21:03, 8 September 2024 (UTC)[reply]
Ah, my apologies. The correct link is mw:Talk:Reading/Web/Desktop Improvements RoySmith (talk) 21:17, 8 September 2024 (UTC)[reply]
Thanks for your help. 2A00:23C8:7B0C:9A01:8A7:5D88:5F57:107E (talk) 21:26, 8 September 2024 (UTC)[reply]

Adding Svan and Laz languages spoken in Georgia

Hi dear Wikipedians!

I have a proposal. Please can you consider to add two Kartvelian languages of Georgia and neighboring countries spoken as a minority, which are written in Georgian script and are missing on Wikipedia like there are Georgian and Mingrelian. I want from one of the admins to create two Wikipedia editions for Svan language and Laz language. These two languages belong to the Kartvelian language family and are written in Georgian script, however they aren't mutually intelligible with each other and also with Georgian and Mingrelian. If they will be added, each of these four branch speakers of the Kartvelian language will have a better opportunity to learn more these languages belonging to the Kartvelian language family, and also these two new Wikipedia editions will have their own articles which they will belong to the article scope of the regions where these languages are spoken. In addition, the other visitors from different parts of the world will learn about these languages. Please add these two Wikipedia editions as they are old languages spoken in Georgia, which is an ancient country with rich history and culture. I would be so happy if you will take my request into consideration.

Thanks Mzeka95 (talk) 00:11, 10 September 2024 (UTC)[reply]

@Mzeka95, I think you need to start with the m:Language proposal policy. WhatamIdoing (talk) 00:26, 10 September 2024 (UTC)[reply]
All I can say is, the more languages the merrier! 87.95.81.141 (talk) 19:31, 11 September 2024 (UTC)[reply]
Yes, but, as WhatamIdoing says, there is a bureaucratic procedure that has to be followed on Meta, not the English Wikipedia, to get this proposal off the ground. Phil Bridger (talk) 20:22, 11 September 2024 (UTC)[reply]
It might be helpful to be clearer about that process: If you want Wikipedia articles in those languages, then 99% of the time, you will have to do the writing/translation work yourself. There is no secret group of people here that is skilled in those languages and just waiting for the opportunity to create the articles. If your hope is "I'll suggest this, and someone else will do all the work", then you will be disappointed. The process that is likely to work is the one that sounds a lot more like "I've got a dozen friends who speak these languages natively and would love to spend several hours per week, for the next decade, working on this". WhatamIdoing (talk) 22:21, 11 September 2024 (UTC)[reply]

Rename and re-theme ITN

This proposal is to rename Wikipedia:In the news to Wikipedia:Articles featuring current events, and also thereby re-theme the process. - jc37 12:17, 12 September 2024 (UTC)[reply]

Rationale

WP:ITN has long been a revolving door of editor-related and/or process-related issues. And I think a large part of it is merely due to the conflict between trying to feature current events on the main page, and WP:NOTNEWS.

I think we would go a long way towards fixing this if we simply remove the word "news" from the title of the section. It connotatively suggests that these are things one might find in newspapers or news sites, or even that this is Wikipedia presenting news items. When, as best as I can tell, that's not the primary intention of the section. I think the intro to Wikipedia:In the news states this pretty clearly.

In multiple discussions, the regulars there appear to be defending the process as a way for the encyclopedia to feature articles. Well, if that's the purpose, then let's call it that, and sidestep all the baggage that the word "news" can carry with it. - 12:17, 12 September 2024 (UTC)

Support (rename and re-theme ITN)

  • Support - as proposer. - jc37 12:17, 12 September 2024 (UTC)[reply]
  • Conditional support – (involved as ITN regular) It's a good thing to have a section on the Main Page featuring current events-related articles, as it helps show that the encyclopedia is kept up-to-date and engaging, but the key criterion should be to feature quality articles about current events, not decide what to feature based on perceived newsworthiness. Noting that a name change alone without underlying changes wouldn't fix much of the issues, so I wish it would come along with a fundamental change in how the articles are selected. Chaotic Enby (talk · contribs) 12:51, 12 September 2024 (UTC)[reply]
  • Weak support: Contrary to the others, I think that a name change—even by itself, only—could be a bit less misleading to newcomers, especially those who come to WP going "why isn't this news here?".
    I do feel like it would be better to just rename it to "Current events" if possible, as this name is indeed too verbose. To solve the conflict with the portal, just add a {{distinguish}}. Aaron Liu (talk) 12:55, 12 September 2024 (UTC)[reply]
    Alternate name suggestions are of course welcome : ) - jc37 13:13, 12 September 2024 (UTC)[reply]
    Like I said, just "Current events". Aaron Liu (talk) 13:20, 12 September 2024 (UTC)[reply]
    I would support Wikipedia:Current events. C F A 💬 13:53, 12 September 2024 (UTC)[reply]
    This is why you should have workshopped this rather before starting an RFC. Thryduulf (talk) 13:31, 12 September 2024 (UTC)[reply]
    WP:NOTBURO - "workshops" are RfCs too. I welcome discussion on this, whereever the discussion takes us. An RfC can result in more things than merely "support/oppose/no consensus" - WP:NOTAVOTE, after all. - jc37 13:35, 12 September 2024 (UTC)[reply]
    RfCs are meant to have a clear question that editors can answer. That's why the RFCBEFORE requirement exists: so that editors can talk it out, try to come to a consensus, and when all else fails, narrow the dispute so that uninvolved editors can help answer a clear-cut qurstuon via RfC. Citing NOTBURO to say that an RfC should be a free for all is ridiculous. voorts (talk/contributions) 13:37, 12 September 2024 (UTC)[reply]
    A "RFC" = a "request for comment". no more, no less. It is a consensual discussion. So yes, NOTBURO applies. And a simple question of renaming? That's pretty clear cut. Alternate rename suggestions are proposed in rename discussions all the time. So I'm not sure what you find so "ridiculous". Anyway, this is a tangent to the discussion itself. - jc37 13:43, 12 September 2024 (UTC)[reply]
    The idea of doing some RFCBEFORE before launching a T:CENT RFC is a good one, I think. A smaller group discussion can help figure out what the most likely options to pass are in a big RFC, and then just present those, which is a nice optimization that reduces friction and saves editor time and reduces the chance of messy closes. –Novem Linguae (talk) 14:01, 12 September 2024 (UTC)[reply]

Oppose (rename and re-theme ITN)

  • Oppose. New name is more verbose, lacking concision. The idea of rebranding something to fix its problems is a bit questionable. For example on meta they tried this with the community wishlist this year and the community made it clear that they preferred the old name. Is the fundamental problem with ITN really its name and the fact that it focuses on topics that are "in the news", or is its core problem actually something else such as toxicity, which might not be addressed by a name change? –Novem Linguae (talk) 12:48, 12 September 2024 (UTC)[reply]
    I think it could be said that at least some of that "toxicity" (to use your word) might be due to the unsaid expectations of commenters when they come to a discussion about topics "in the news". Changing the name can change that expectation and tone. And besides, the name "in the news" doesn't reflect what's said on WP:ITN - it makes it clear that this is about articles that are involved in current events in some way. So, similar to what we do with Article titles, shouldn't the name of this project page (and process) match the contents and intent? - jc37 13:10, 12 September 2024 (UTC)[reply]
  • Oppose' per Novem Linguae. The problem is not the name, and even if it were the new name wouldn't resolve the misunderstandings about what the purpose of the section is (or trying to turn it into what they, but most other editors do not, think it should be). I also agree that this should have been workshopped first as there are very probably better alternatives to the one suggested (that still wouldn't solve the problems but would not introduce waffle). Thryduulf (talk) 13:00, 12 September 2024 (UTC)[reply]
    Waffle‽ I love my yellow syrupy pastry, but what is waffle? Aaron Liu (talk) 13:04, 12 September 2024 (UTC)[reply]
    Maybe it's more of a British English thing but it means being excessively verbose in a non-meaningful way. Someone who waffles on talks a lot but says little. — Czello (music) 13:20, 12 September 2024 (UTC)[reply]
    That's exactly how I meant it, possibly it is British English but wikt:waffle#Etymology 2 doesn't mark it as being associated with any particular national variety of English. Thryduulf (talk) 13:33, 12 September 2024 (UTC)[reply]
  • Oppose I think the newly proposed name departs from the format of the ITN section. Note that "news" is information about "current events". We post blurbs that summarise news. To me, "Articles featuring current events" sounds like posting links to articles that document current events. That's not what the ITN is.--Kiril Simeonovski (talk) 13:15, 12 September 2024 (UTC)[reply]
    The very first line of WP:ITN: "The "In the news" (ITN) section on the Main Page serves to direct readers to articles that have been substantially updated to reflect recent or current events of wide interest." - As you can see, that's exactly the stated intent. - jc37 13:20, 12 September 2024 (UTC)[reply]
    Yes, but it's confusing as we don't precisify the way we direct readers to articles. "In the news" sounds simpler and clearer to my ear, and we really don't need to include "articles" in the name.--Kiril Simeonovski (talk) 13:39, 12 September 2024 (UTC)[reply]
    If it's confusing, then I think we should probably fix that. Something typically done in either changing the mission statement or the name. I'm proposing changing the name to match the mission statement. - jc37 13:50, 12 September 2024 (UTC)[reply]
    The most precise wording in the spirit of the current name would be "From the current events". Anyway, the name change won't solve a problem because there's no problem at all. We have a section called "Did you know...", which "showcases new or expanded articles that are selected through an informal review process". Shall we change it to "From the new and expanded articles" just to better match the mission statement of DYK? I think there should be some aesthetics on the main page, and "In the news" and "Did you know..." are names that provide it.--Kiril Simeonovski (talk) 15:03, 12 September 2024 (UTC)[reply]
    That's an overreduction. ITN is also new and expanded articles. Two of the DYK goals are still about being interesting. Aaron Liu (talk) 15:22, 12 September 2024 (UTC)[reply]
    No, we also post updates to existing articles.--Kiril Simeonovski (talk) 16:27, 12 September 2024 (UTC)[reply]
  • Oppose as the page isn't called "the news" (as it seems OP framed that's how it's being presented), it's called "in the news"; as in, "here are articles whose topics are currently in the news". I think renaming the page would be a blunt instrument to fix policy issues (if it even does). — Czello (music) 13:24, 12 September 2024 (UTC)[reply]
  • Oppose. This is a CREEPy, bureaucratic cosmetic change that will do nothing to address the asserted issues. Frankly, Well, if that's the purpose, then let's call it that sounds pretty pointy. Editor time is valuable. In my view, the current proposal is a waste of it. James (talk/contribs) 15:06, 12 September 2024 (UTC)[reply]
  • Oppose. With all due respect, nominator, to put it simply, I just don't believe a name change would actually do anything to improve decorum at ITN. Its issues are much deeper than a branding problem. DarkSide830 (talk) 15:49, 12 September 2024 (UTC)[reply]
  • Oppose per Czello. The problem with ITN is not the name or the theme, it's the fact that the discussions are too slow and rambling to produce punctual postings while things remain in the news. (It would also be good to get a clearer steer on subject matter - culture topics other than deaths are rarely nominated, and frequently opposed when they are, but sports get reasonably consistent coverage. Personally, I'd favour evolving some standards for a wider range of cultural stories to carry.) GenevieveDEon (talk) 16:37, 12 September 2024 (UTC)[reply]
  • Oppose Generally speaking, "current events" are "in the news". Almost everything nominated for ITN is already posted in that day's Current events section and the majority of what's posted to ITN (invariably undated) stays up well after its currency expires. If ITN storylinks should ever become as current as CE storylinks, such a similar name might make sense. InedibleHulk (talk) 17:19, 12 September 2024 (UTC)[reply]

Discussion (rename and re-theme ITN)

I feel like such a big change should've had some sort of workshopping first. Aaron Liu (talk) 12:45, 12 September 2024 (UTC)[reply]
Same, there's been RFCBEFORE discussions on the ITN talk page following the AN discussion about an RFC to reevaluate aspects of ITN which have been going on for a few days, and this seems to be jumping the gun. I recommend this be shuttered and ideas held off until the planned RFC is ready to go instead. --Masem (t) 12:56, 12 September 2024 (UTC)[reply]
This is a name change proposal, it in no way hinders whatever 'process proposals' people are working on. - jc37 13:10, 12 September 2024 (UTC)[reply]
Based on the results of this planned RFC, a different option for a new name may have fallen out from that. It goes back to raised concerns about workshopping an option first, and makes this premature. Masem (t) 13:24, 12 September 2024 (UTC)[reply]
I think that's incorrect. There's a wide ranging discussion about changing ITN right now and you should have weighed in there and helped to workshop instead of running here to start an RfC—which may very well become moot depending on what comes out of the ongoing discussion. I would boldly close this RfC to allow the RFCBEFORE discussion to finish but I'm not at my computer. Somebody else should. voorts (talk/contributions) 13:25, 12 September 2024 (UTC)[reply]
I appreciate seeing so many ITN regulars commenting here. It's interesting to see your (plural) comments. - jc37 13:30, 12 September 2024 (UTC)[reply]
I'm not an ITN regular. If you'd read the two discussions that preceded this one, you'd know I tried participating in ITN once and was so turned off I've only commented there a couple of times since. I want this to go somewhere, hopefully to fix ITN for the better. Rushing into an RfC before the BEFORE discussion is finished and ideas are hashed out is a recipe for disaster. voorts (talk/contributions) 13:40, 12 September 2024 (UTC)[reply]
And I appreciate your comments as well.
And - in my opinion anyway - we should never shy away from asking the community to comment, to provide their thoughts, about something. Especially not out of fear that some individuals might come along and try to derail the discussion, rather than discuss the matters at hand. I have faith in the community. And regardless of how this discussion turns out, I welcome the community's thoughts. - jc37 13:47, 12 September 2024 (UTC)[reply]
Asking the community to comment and provide thoughts about something is a good thing, but (a) that's what's happening at WT:ITN, and (b) that's not what an RFC is - an RFC is a specific question with a finite number of answers with the aim of generating consensus for one them. Thryduulf (talk) 13:52, 12 September 2024 (UTC)[reply]
When posting at village pump proposals, please don't forget to notify the main page affected by the proposal. I see this happen here a lot. Anyway, I went ahead and notified Wikipedia talk:In the news. –Novem Linguae (talk) 12:58, 12 September 2024 (UTC)[reply]
Thank you : ) - jc37 13:10, 12 September 2024 (UTC)[reply]

Early close

Should this RfC be closed early to allow the WT:ITN RFCBEFORE discussion to reach a conclusion? voorts (talk/contributions) 15:19, 12 September 2024 (UTC)[reply]

Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(proposals)&oldid=1245384567"