Jump to content

Wikipedia:Village pump (proposals)

From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by James Allison (talk | contribs) at 00:29, 15 September 2024 (→Rename and re-theme ITN: support close). 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.

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]

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]

The tools menu could use some consolidation into submenus. Like the page menu discussed farther down. There would then be room for the pageviews link on the tools menu, or its submenus. Currently, there are no submenus on the tools menu. --Timeshifter (talk) 22:14, 14 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,919,524 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]
Sdkb, proposal not needed, just a doc update. That box (like most else) is already classed, this as .talkheader-help and all you have to do is add .talkheader-help {display:none} to your common.css, and that should do it. (If it doesn't, please ping me from Template talk:Talk header.) Mathglot (talk) 00:42, 13 September 2024 (UTC)[reply]
I'm interested in improving the interface for everyone, not just myself. A personal CSS hack doesn't do that. Sdkb talk 07:47, 13 September 2024 (UTC)[reply]
Oh, I see; should be pretty straightforward with a new param. If only we had a magic word for the id of the user reading the page, instead of the last one who saved it, we could do it without a param, but alas. Mathglot (talk) 07:54, 13 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]
I find this condescending to editors and readers: "We need editors thinking about the work that needs to be done, rather than being focused on the popularity of the page." You, or some committee, shouldn't be determining what is important to editors and readers. I assume now that this is why page views has been made so inaccessible to regular readers and editors. I make decisions on what and how I edit based on numerous factors, including page views. Maybe you have unlimited time to edit. I don't, and so I want to edit what I think makes a difference, and what matters to me. If I have a choice between a popular and unpopular page, and both matter to me, then I will probably edit the popular page more. --Timeshifter (talk) 00:45, 13 September 2024 (UTC)[reply]
I doubt that's why Page views isn't that visible; most likely it just wasn't considered that important.
And by definition, any user interface design makes a determination of what's important or not important. People use Talk more than, say, What links here, so it makes sense that the former is more prominent. In such a wide-ranging and community-focused project like Wikipedia there's always going to be a variety of opinions on what exactly that order is.
The closest thing to letting people decide for themselves would be if we just make every action associated with a page buttons of the exactly the same size that are always visible, which would be unbearably cluttered and intimidating to newcomers. ― novov (t c) 02:36, 13 September 2024 (UTC)[reply]

novov: Now your veering into ridiculousness. As I previously said average readers and editors are more interested in page views than other statistics. And elsewhere you said you want page views in a separate template, and not as 2 words (Daily pageviews) added to {{talk header}}. Many people do not want a separate template. So that leaves few choices if you really want pages views to be more accessible to average readers and editors. --Timeshifter (talk) 21:57, 13 September 2024 (UTC)[reply]

Strong oppose. I am a strong supporter of accessibility of page views information on Talk pages, but this is not he way to go. I won't repeat the reasoning I already gave at Template talk:Talk header, I will just say that I am coming up with a stopgap, template-based replacement for {{annual readership}} until a more permanent solution can be found, and will expose it here shortly for discussion. (I've added DNAU so this doesn't get archived in the meantime.) Please stay tuned. Mathglot (talk) 23:04, 12 September 2024 (UTC)[reply]
You haven't stated whether you oppose or support a page views link in the tools menu. Please say so in the previous talk section above. --Timeshifter (talk) 22:09, 13 September 2024 (UTC)[reply]
@Timeshifter, where is the evidence for your assertion that average readers and editors are more interested in page views than other statistics? I don't think we have any the evidence that "average readers" are interested in any statistics at all, and what we can reasonably predict about editors is that some will appreciate it and others won't.
It is very easy to assume "I want this; therefore almost everyone wants this". I'm telling you: I don't want this, and because of the page-view distribution curve, I think it is very bad for Wikipedia's future to promote page views. You are proposing that 90% of talk pages carry "proof" that those articles are unimportant. That will not make editors feel happy. It will not make them feel like contributing more. In some cases, it will scare them away from editing. Cancer has a self-contradiction in it. It's hard enough to get someone to edit that article. I don't need "help" in the form of you scaring away editors because you've made sure that they know how many people will see that edit. I very much need "editors thinking about the work that needs to be done, rather than being focused on the popularity of the page", even if you think it's condescending ("an attitude of patronizing superiority or contempt") of me to want editors to WP:Be bold and fix the problems in that article and not to be scared off by your reminder that the page gets read 1.5 times per minute. Editing articles is an anxious business for some people.
Putting the page views on all the pages will make editors feel like someone else (i.e., you) has told them that they should care about this factor. In fact, you think they should care about page views so much that you are trying to force them to see the numbers (or, for now, a link to the numbers) whenever they venture onto a talk page.
You should get to pick the articles that you want to work on. I suggest to you that a page like Wikipedia:WikiProject Politics/Popular pages would be a more efficient way of finding popular articles than clicking on each talk page, but if you like clicking on each page individually, then feel free to click away. What I'm saying is: Don't force your preference on everyone else. WhatamIdoing (talk) 04:19, 14 September 2024 (UTC)[reply]
We appear to have a WP:TALKFORK at Template talk:Talk header#Put page views link in talk header template. WhatamIdoing (talk) 04:30, 14 September 2024 (UTC)[reply]
The XTools PageInfo gadget, as seen when viewing the Jimmy Wales article.

See: Special:Preferences#mw-prefsection-gadgets. Appearance section:

  • "XTools: dynamically show statistics about a page's history under the page heading."

It lists the number of editors, watchers, and pageviews. It names the page creator, and has a link to "full page statistics" that goes here (it is filled in automatically):

For example:

The statistics bar is below both article and talk pages. There are separate stats for the talk page.

Only logged in users see the statistics bar. Turning it on by default would allow all logged in users to see it. If they don't like it they can always turn it off. But if they never turn it on, they will not know that it has a page views link. That is why it should be turned on by default.

I think this should be done, and after people see that the sky will not fall by giving editors this info, then it should be turned on by default for both logged-in users, and all readers. --Timeshifter (talk) 07:32, 14 September 2024 (UTC)[reply]

  • I don't think this is a good idea, forcing all editors (and even all readers) to make client-side calls to a volunteer project on every page load is asking a lot, also this gadget causes a screen jump as it waits to load then inserts itself in to the header. — xaosflux Talk 07:44, 14 September 2024 (UTC)[reply]
The screen jump doesn't bother me. Pages have screen jumps for other reasons too. People can turn it off if they don't like it. And it is not much of a screen jump. A line or 2.
We can start with logged-in users first and see how that goes. If it is too much of a load on the servers, then set it to only update the numbers once a day.
https://xtools.wmcloud.org is part of Wikimedia, and so I think its servers can handle it if tweaked as needed. --Timeshifter (talk) 08:01, 14 September 2024 (UTC)[reply]
I don't think these statistics are relevant to the average reader. Or average editor really, I can count the amount of times that I've looked up any of these statistics for the last twenty pages I've edited on zero hands. The same is most likely true for the last two hundred.
To be quite frank, even before it became hidden {{Annual readership}} wasn't on most talk pages. For those pages, the situation was identical to how it was now, so I don't get why this is such a huge issue. ― novov (t c) 09:29, 14 September 2024 (UTC)[reply]
It's important to the many people who liked {{annual readership}} while it had the graph of pageviews. Apparently, that does not matter to you. --Timeshifter (talk) 09:36, 14 September 2024 (UTC)[reply]
Screenshot of the Analysis menu of the Page dropdown.

See: Special:Preferences#mw-prefsection-gadgets. Appearance section:

  • "MoreMenu: add Page and User dropdown menus to the toolbar with links to common tasks, analytic tools and logs".

Unless the tools menu gets some submenus, then I like this solution best of all so far. It avoids any possible server problems (see previous talk section) since it does not show the statistics. And the page menu is short. So there is room for a pageviews link.

The pageviews link needs to be added to the page menu, or the "analysis" submenu.

This way logged-in editors have access to pageviews without having to open another page first (if they even know about it), and then scroll around, and then click the pageviews link.

Since it would be in a menu or submenu, editors are likely to see it as they look at all the menus on pages over time. They don't have to leave the page to click the pageviews link. ----Timeshifter (talk) 22:16, 14 September 2024 (UTC)[reply]

No opinion yet on whether or not this proposal should be implemented, but could you please explain why The pageviews link needs to be added to the page menu, emphasis in original? Folly Mox (talk) 23:15, 14 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)

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]
  • Oppose. I too share concerns about the process, or more specifically how certain regulars do things, but this proposal is half-baked to put it mildly. ~~ Jessintime (talk) 20:30, 12 September 2024 (UTC)[reply]
  • Oppose. From what I can see, this doesn't really have any tangible benefit, but it makes the title of the ITN page substantially longer. I do think behavior at ITN could be improved, but this feels like, to put it bluntly, putting lipstick on a pig. – Epicgenius (talk) 02:15, 13 September 2024 (UTC)[reply]
  • Oppose. Even changing the name to “Current events” is unnecessary, since the phrase “in the news” directly implies that the section is about current events. “Articles for current events” is an even worse name, since it’s unnecessarily long. 198.17.110.223 (talk) 18:45, 13 September 2024 (UTC)[reply]
    What the change would do is remove the "it appears in the news so it should be on the Wikipedia frontpage" denotation. Aaron Liu (talk) 18:57, 13 September 2024 (UTC)[reply]
    In that case, rename it to only “Current events” 198.17.110.223 (talk) 19:31, 13 September 2024 (UTC)[reply]
    You would get instead "this is a current event so it should be on the Wikipedia frontpage". Thryduulf (talk) 19:42, 13 September 2024 (UTC)[reply]
    That hasn't happened with DYK, but the ITN thing has already repetitively happened with ITN. Aaron Liu (talk) 19:58, 13 September 2024 (UTC)[reply]
    Why would it happen with DYK? What would it look like if it did? Thryduulf (talk) 22:15, 13 September 2024 (UTC)[reply]
    "Anything WP:UNUSUAL shall be promoted to the main page in chaotic order." Plus, regardless of whether this will weed out everything, "Current events" already >> "In the news". News is a superset of current "newsy" events, and such a new title would at least weed out some stuff. I see no reason this could go wrong, except potential whiplash if the current WT:ITN discussions suddenly watershed into a radically different direction. Aaron Liu (talk) 22:50, 13 September 2024 (UTC)[reply]
  • Oppose - Like others, a name change/small proposal like this is premature imo. A comprehensive way forward for the main page section in question - including not only changes to processes/procedures/policies/etc. but to the name should be fleshed out before small changes like this are proposed. Trout the nominator because while it looks like this was in good faith, it was premature given RFCBEFORE discussion ongoing. -bɜ:ʳkənhɪmez | me | talk to me! 23:00, 13 September 2024 (UTC)[reply]
  • Oppose, as a straight up ITN-abolishionist. This helps nothing. Mach61 02:26, 14 September 2024 (UTC)[reply]
  • Oppose. Just a longer way to say the same thing without addressing the underlying issues or improving the section at all. -- Patar knight - chat/contributions 05:04, 14 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]
We should absolutely shy away from asking the community to comment, to provide their thoughts, about something, because people's time is limited and valuable. We should ask for that time sparingly. Not every idea we have deserves the formal attention of an RFC, and there are specific places to go to float or brainstorm ideas for those who are interested (like the idea lab, or, in this case, WT:ITN). RFC is an "expensive" process. Levivich (talk) 06:19, 13 September 2024 (UTC)[reply]
Spending some time workshopping it might have come up with a better alternative title, too. This one is obviously going to fail because the proposed new name is incredibly clunky. --Aquillion (talk) 20:06, 13 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=1245770944"