Jump to content

Wikipedia:Village pump (proposals)

From Wikipedia, the free encyclopedia
(Redirected from Wikipedia:VPR)
"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

[edit]

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

[edit]

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

[edit]
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

[edit]
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

[edit]

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,880,773 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]

Make search field permanently visible

[edit]

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

[edit]

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]
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(proposals)&oldid=1244926018"