Jump to content

Wikipedia:Village pump (idea lab)/Archive 35

Add links
From Wikipedia, the free encyclopedia
Village pump (idea lab) archive  

This page contains discussions that have been archived from Village pump (idea lab). Please do not edit the contents of this page. If you wish to revive any of these discussions, either start a new thread or use the talk page associated with that topic.

< Older discussions · Archives: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62

There should be more "in a nutshell" bulleted lists at the top of the page

I like when some articles have summaries at the top, they are really helpful, especially when I just want to get the most important information. Might be cool — Preceding unsigned comment added by TheFirstVicar4 (talk • contribs) 01:40, 27 January 2021 (UTC)

TheFirstVicar4 - sorry, are you suggesting that this should be adopted for main-space articles? Or just that it should be used more widely on essays/guides/etc? --Paul ❬talk❭ 12:48, 27 January 2021 (UTC)

I'm saying for articles, not only wikiguides. I thought that it would be helpful for slow readers like me — Preceding unsigned comment added by TheFirstVicar4 (talk • contribs) 14:32, 27 January 2021 (UTC)

Does an WP:Infobox fulfill this function? --A D Monroe III(talk) 17:09, 27 January 2021 (UTC)
Left to right: Article body; lead; infobox; first sentence of lead; summary of first sentence of lead. EEng 21:26, 29 January 2021 (UTC)
  • This sounds like a good idea. The Encyclopedia Brittannica used to have a Micropedia section and a Macropedia section, the former largely consisting of summaries of articles in the latter. If you looked at one of the many articles on famous people in the Macropedia, and then read that person's entry in the Micropedia, you would see that the Micropedia article would read "Abstract of text biography". Wikipedia does not need to have separate Micro-Wikipedia and Macro-Wikipedia versions, but if abstracts of the articles appeared at the top of articles, that would serve this function. Rollo August (talk) 14:28, 16 February 2021 (UTC)
  • Oppose We already have short descriptions for that. 🐔 Chicdat  Bawk to me! 12:26, 25 February 2021 (UTC)

Should the COI edit request queue function more like RfCs?

Conflict of interest (COI) editing has long been a challenge for Wikipedia. While much of the controversy has centered on undisclosed paid editing (UPE), there also has developed an operating consensus, with support from Jimmy Wales, to encourage an "edit request" process consistent with the Conflict of interest guideline. In a nutshell, it is for responsible paid editors to suggest changes, and for volunteers to implement them if they make the encyclopedia better. This is described in more detail at WP:PSCOI and it has worked reasonably well over time, although like many request queues at Wikipedia, it often has a lengthy backlog.

As of this writing, there are more than 180 open requests, the oldest of which dates back to October. If not an all-time record, it's certainly close, especially following a period from 2018 to 2020 where the efforts of mostly a single editor kept the queue very manageable. Various suggestions have been made at the Village pump over the years to improve upon this process, including adding new parameters to the edit request template and promoting the recently-created Edit Request Wizard. I've given some thought about another way to potentially improve this system, which I've outlined below. My goal is to outline the issues as I see them here, gain some feedback, and hopefully even some support, before taking a more defined proposal to Village pump (proposals). Here's my analysis and initial suggestion:

Review of the current process

Template:Request edit has become the preferred tool for COI editors to submit requests for editor review. Currently, when an editor adds this template to a request posted on an article's Talk page, the request is added to a queue, displayed to editors in the form of a category and summary table. Reviewing volunteers who start from this queue may click on specific links to review individual requests and reply on the article's Talk page.

This template is helpful to the community by centralizing these requests, and to responsible COI editors because there's a much greater likelihood the request will be reviewed by at least one editor, eventually. It therefore provides a guideline-compliant alternative to UPE for those who are willing to take Wikipedia's rules seriously. When the process works, everyone benefits, including Wikipedia's readers.

Problems with the current process

However, the process has its shortcomings:

  • The current framework is not user friendly, for reviewers or COI contributors
    • No instructions are provided, so it is difficult for either volunteers or COI editors to learn how it is supposed to work
    • No information about the request is available prior to clicking through, other than the name of the article
    • Requests are not sorted in any way, preventing reviewers from selecting topics based on knowledge, interest, or type of request
    • Protection level and Last protection log entry information is rarely useful
  • As a result, requests can sit for weeks or even months before being reviewed
  • It is very unusual for an edit request to receive replies from more than one editor, limiting the potential for collaborative solutions

These shortcomings have the potential to negatively impact Wikipedia as a whole:

  • Readers do not benefit from the project clinging to incorrect information only because the person who pointed out the error has a COI
  • Poorly formatted requests waste volunteer time; if the queue was located on a page with a link to WP:PSCOI or the Edit Request Wizard it would be easier to triage these requests for revision
  • Some requests are rejected without substantive consideration, as the queue sometimes attracts editors who seem to have an aversion to COI editing. I understand and appreciate why Wikipedia editors are skeptical of COI editing. They should be! But at the same time, this process exists for a reason, and requests should be decided on the merits. Greater transparency would make these summary dismissals less common
  • A cumbersome submission process and very long wait times incentivizes undisclosed paid editing
Proposed solutions for improving the process

I have lately begun to think it might be better for the edit request process to more closely resemble the Requests for comment (RfC) process, especially the way it transcludes the initial Talk page requests, sorts them into differentiated noticeboards (i.e. /Biographies), and provides a centralized noticeboard consolidating all open requests.

Whatever faults one may identify with the RfC process, it's easier to review questions at a glance, more likely to generate greater participation, and thereby reduce the burden on any one volunteer. RfCs also include designated time limits on discussion, and include invitations delivered by bots to advertise discussions to uninvolved editors. What's more, RfC statements are meant to be brief and neutral, and a revised edit request process could encourage COI editors to take a similar approach.

In this way, the RfC framework could be applied to the edit request process, where submitted requests are hosted on a centralized noticeboard and editors are given a designated length of time to discuss proposed changes and form a consensus. In many cases, requests may still be rejected, and that's fine. If a few editors quickly agree a request is unreasonable, the discussion can be closed, but at least the request was reviewed by more than one person. If editors decide a request is generally appropriate, then the article can be updated based on consensus.

My goal is to allow opportunity for reasonable requests to receive adequate consideration and implementation by neutral editors, not to influence which types of requests are accepted or rejected, nor to dictate who should be allowed to participate in discussions. I do understand that reviewing edit requests takes a toll on the Wikipedia community, i.e. the WP:BOGO analysis. But this is also why I think that making the COI request process more user-friendly and reducing the friction inherent in the current design could make things less taxing on individual volunteers.

Invitations for feedback

In addition to editors watching this idea lab page, I'd like to invite editors to this discussion who may be at least somewhat familiar with the current process because they have responded to submitted requests. Back on January 4, I reviewed the 100 most recently answered COI edit requests, dating back to December 7. Below I've compiled a list of editors who replied to those requests, and I am pinging them in the hope of getting feedback about the changes I've proposed.

Editors who responded to COI edit requests during December 7, 2020 – January 4, 2021

This test was conducted at a good time because User:Spintendo generally stopped editing on October 26. He monitored the queue closely and responded to requests often, until recently. I would certainly welcome his thoughts as well, but by completing this assessment when I did we are able to see what the process looks like without him (much slower!).

So, here's where I solicit feedback from editors. What about the current COI request system is working? What about it is not? What thoughts and concerns do you have about making changes to the system, possibly one which looks more like the RfC process? What is valuable about the RfC process that could benefit COI edit requests? Which aspects of RfC would not be suitable for this purpose?

In closing, I'm hoping to get constructive feedback here before putting forth a more detailed proposal at another village pump page. I look forward to all responses, and I'll take them into consideration as I ponder next steps. Thanks in advance, WWB (talk) 22:55, 8 February 2021 (UTC)

Quick thought: The main problem we're currently experiencing is the lack of Spintendo. The whole process worked mainly because one single editor managed to keep up with the high amount of time-intensive requests, and it broke in the moment they stopped investing volunteer time to help paid editors. There are multiple areas behind Wikipedia's scenes where too much reliance is put on a single person; having to wait years for a bot update at WT:RFPP is another one. I can't provide a proper solution, I can only complain. ~ ToBeFree (talk) 22:59, 8 February 2021 (UTC)
(ec) I have not been as active in answering COI edit requests, and am not necessarily in favor of having an overflow of what would function as RfCs (and I'm not sure how this process would be any different to the current process - RfCs are categorized just like Requested edits, and such cat pages are watched by editors), but I think a solution to addressing the number of COI edit requests is most certainly necessary. What the COI edit request queue needs is editors to address the ERs, not necessarily a bigger process. I thus think that an editor organization or editing rally would be more useful. I would be in favor of WikiProject, or maybe a edit request drive, but not this idea - I'm not sure it would fix anything. P,TO 19104 (talk) (contribs) 23:05, 8 February 2021 (UTC)
I'm not a regular COI-request editor (I answer edit requests on articles I watch), so I didn't know about Category:Requested edits. On first glance, it's rather...offputting. I like the RFC format better, but I'm not sure how simple it would be to display COI requests in that format. They don't have a brief summary or description to transclude the way RFCs do. And if the entire edit request is transcluded, it would be a complete mess. I agree that the process could be improved but I don't know what would make it better. That's probably not very helpful, sorry! Schazjmd (talk) 23:12, 8 February 2021 (UTC)
I don't watchlist Category:Requested edits. I don't like paid editing. I suspect that one of the reasons for the backlog is that I'm not the only one who feels that way. The requests are often very poorly structured, and frequently completely unreasonable. Maybe if the requesters learned how to do it properly, stopped asking for inclusion of anything that is not independently verifiable and gave up on trying to use Wikipedia as a platform for promotion. The latest entry in Talk:Wellendorff is a pretty good example of how not to do it. The solution? Decline such requests faster and block the requester for wasting volunteer time. Vexations (talk) 23:15, 8 February 2021 (UTC)
  • I haven't fulfilled many requests either. Most requests I've seen are usually not directly actionable and require a significant amount of time to fulfill properly. I would expect a good request to be formatted as paragraphs that can be copy-pasted to the article after review. --MarioGom (talk) 23:37, 8 February 2021 (UTC)
I watch Category:Requested edits and I enjoy helping making those edits, but--to be honest--I always pick from recent requests, looking for interesting or easy ones. I like educating the requesters and I like meeting editors through it. I had no idea Wikipedia:Edit_Request_Wizard existed, so I imagine most other people don't. The biggest problem with this process, as I see it, is that there is no process. Some editors list out their editors in a "change X to Y" model, which is incredibly helpful. Most don't, and half my time is spent deciphering what exactly they want to do. Fixing that would do a lot for this process. When edits are formatted like that, I can breeze through them. I'd even be willing to commit to X per month. I haven't yet checked out the wizard, but if it is formatted as:
  • Where is the change?
  • What do you want to change?
  • What's the source?
Then I could run through edits. I also wish there was a simpler approve/deny/more info approach/process in place. Talk page conversations take more time than actual edits.
Just my $0.02. Hope it's helpful. --FeldBum (talk) 23:58, 8 February 2021 (UTC)
@WWB, have you looked at the Wikipedia:Article alerts system, e.g., Wikipedia:WikiProject Medicine/Article alerts? I don't mind processing the occasional edit request (they aren't just paid editors, either), but I don't really want to see requests related to subjects that I don't know anything about. I glanced quickly through the current list of 183 edits, found just one that relates to an area I'm familiar with, and clicked through to discover that one of the best-informed editors was already there. (Then I found two more similar requests, and pinged her to those, too.) If it was easy to find just the (five?) that might be relevant to WPMED editors, then I suspect that these requests might get processed more quickly. I think that Wikipedia:Articles for creation and Wikipedia:WikiProject Disambiguation editors have found that WPMED is very responsive to small requests, and I imagine that the other large WikiProjects would be similarly responsive. WhatamIdoing (talk) 00:46, 9 February 2021 (UTC)
Also, switching hats: @PPelberg (WMF), this problem probably relates to mw:Talk pages project/Notifications and the goal of getting timely responses to comments left on talk pages. Whatamidoing (WMF) (talk) 00:48, 9 February 2021 (UTC)

The biggest problem with the queue is the number of large requests that sit there for months. These requests include changing vast amounts of information, adding paragraphs or completely rewriting the article. I try to complete the requests at the top of the queue, but these are very time-consuming. My process is as follows: I usually rewrite the text to remove the promotional language, off-topic facts and non-notable information. Then, I verify the text because I am not putting my name on a bad edit. If I can't access the sources I ask the requesters to email pdfs. If the information isn't verified, or if the source is not reliable, I discuss the problem on the talk page. This sometimes results in a back-and-forth conversation over several days. This is an exhausting, time-consuming process. I've had requests take over a month to complete. I can't quick-fail these large requests because most of the information is good, adding the text is a net-benefit to the project and I want to encourage COIs to use this process. Sometimes I feel like the queue is getting smaller (I was excited when the backlog got under 100) but then it rapidly increases a couple of days later. If this continues as-is, I'm going to burnout and devote more time to articles I am actually passionate about instead of helping companies promote themselves on Wikipedia. Here are some proposals:

  1. Clearer instructions for reviewers: Template:Request edit/Instructions#For reviewers needs a rewrite. When I started reviewing I had to read the instructions several times before I was confident to begin reviewing. One time I guided an editor on Wikipedia's Discord through the last few steps because they were confused by these instructions. It should be simple to follow, welcoming to new reviewers and feel like it will take a short amount of time.
  2. A WikiProject to support this process, similar to AfC or NPP: I like this idea, proposed above by PTO. We need a place where new reviewers can ask questions and get feedback.
  3. A process where the requester has to fix the problems, instead of putting the burden on reviewers. This might work similarly to AfC, where the article is declined and reasons are given, but the nominator has to go away and fix the problems.
  4. Spin out requests to remove tags: Some requests are to remove tags at the top of the article. If we spin this out this from the queue, it might bring in editors who will focus on that specific section and reduce the backlog.
  5. A limit to how much you can change or add to an article: Each proposal should be limited to four new paragraphs of new text, or text for one section. For example, an editor can request adding four paragraphs to the "History" section of a company, or an update to the "Operations" section, but not both. I chose four because Wikipedia articles rarely have sections that are larger than four paragraphs.
  6. The Edit Request Wizard should include a page that lists common mistakes. These include: adding non-notable awards to articles, off-topic information, announcements of future events, press releases used as sources to show something is notable, press releases to verify a controversial fact, trying to remove negative information, various promo and peacock words. This should be shown before an editor can submit their request.

It is a shame that this queue was supported by one editor for so long. We need this process to stop companies from promoting themselves our platform. I am sorry about my long comment, and I welcome thoughts, ideas, questions and suggestions. Z1720 (talk) 01:46, 9 February 2021 (UTC)

EPW does not trigger on these edit requests. Making it do so might be a good place to start. Subsequent judicious use of the standard responses would probably help keep the queue down. (Maybe an additional one of "rewrite it so it doesn't whiff of promotionalism".) --Izno (talk) 04:05, 9 February 2021 (UTC)

I believe the COI request concept is enormously important to this project. This strong comment may be somewhat surprising given how little I've contributed. I'm using this discussion as an excuse to examine this conflict — why do I sign you tenuously think it's very important yet I am barely involved. Four main thoughts come to mind:

  1. Taking on a request can be hard work if done properly. (@Z1720: hit on some of the reasons.)
  2. There are insufficient rewards for taking on a request.
  3. There are inadequate resources for collaborating with editors with experience in this area (with a slight possibility that those resources exist and I just don't know where they are).
  4. Our advice to editors preparing a request is inadequate

I'd like to address items two and three — they're not the same issue but a potential solution may address both. I invite you to take a quick glance at the CopyPatrol Leaderboard the page related to the tool used to help identify and address recent copyright violations. I pointed out to you with some trepidation — I cannot hold it up as a model of something that works very well, but it has two key elements that are not shared with the COI process. The first is that it acts as its own small reward system. My guess is that most people reading this have never seen that before, so it doesn't fully achieve the goal of being a prominent reporting of accomplishments, but if someone felt that recognizing those who take on this task up to be rewarded, one has to start with identifying them. Unless there is something about the current process that I'm missing, I have no idea who is taking on requests, and how many are handled by each editor. that leads me to the second point. If I'm evaluating a potential copyright issue, and want to consult with others, it's trivial to click on the leaderboard and identify several people to talk to. I try not to pester Diannaa all the time, use this board to identify editors to open up discussion about some thorny copyright issue. Right now, if I looked at a COI edit request, and thought I might be able to handle it but had some questions about best practices, I have no idea whom to contact.

The fourth item might be the most bang for the buck. I've looked at a number of edit requests and most are badly formed. While it would be a little bit of work, conceptually we ought to be able to mockup four or five examples of how an edit request should be formulated covering a range of situations (minor correction of a fact, addition of a reference supporting existing text, substantial rewrite, etc.) I think it's unfair to ask the responding editor to tease out exactly what the intended edit is supposed to be. While I don't propose that the responding editor simply copy and paste a proposed edit, that ought to be a minimum starting point. If we can provide decent examples, we could take a harder line on rejecting requests that don't meet the requirements.

I'm also on board with the observations that the existing list doesn't provide a lot of information about the type of edit requested, or much beyond a hint of the subject matter, and improvement in that area might help.--S Philbrick(Talk) 21:26, 9 February 2021 (UTC)

WWB, thanks for the time you've invested in this matter. The backlog is a serious issue, because COI editors would (understandably) get frustrated with the time they have to wait and it would be very tempting to edit the pages directly. A couple of points:

  • The WikiProject idea suggested by P,TO 19104 sounds like a good one to me and frankly, I am kicking myself for not thinking of it sooner.
  • The edit request wizard needs to be promoted more heavily in the COI help pages etc. Like many other editors here, I hadn't heard of it before it was brought up.
  • While the RfC comparison is interesting, I am not a fan of transcluding all of the information into a dedicated page. It only works for RfC because a short question is supposed to be posed. Edit requests are frequently extremely long. However, the centralised noticeboard is certainly interesting and should be considered alongside the WikiProject idea; classifying edit requests into different categories would make it a lot easier to answer them.
  • I am opposed to Vexations's idea of blocking COI editors who write bad edit requests. That seems over-the-top and would not be useful.
  • FeldBum's recommendations for making an "X to Y" model is great and that should be made clearer to COI editors.
  • WhatamIdoing's article alerts idea seems good, though I confess to not being very familiar with article alerts in general.
  • Z1720's recommendations for clearer instructions are much-needed and I agree strongly with suggestions #1, #2 and #6.
  • I'm on board with pretty much all of Sphilbrick's suggestions. The leaderboard and incentives seem like a natural extension of a WikiProject, and I think collaboration amongst request answerers is definitely a good thing.

All in all, streamlining and making the process more coherent is definitely a good thing, as answering COI requests is not a fashionable thing (I was dragged to COIN just today over a related incident). Making the process better is certainly welcome, and hostility to COI editors who use edit requests in good faith is not helpful. Sdrqaz (talk) 23:50, 9 February 2021 (UTC)

I'm interested in @Z1720's suggestion #5. Should large requests be broken up into smaller bits? You might end up with 10 requests on a talk page, but maybe some of them could then be accepted or rejected easily, and the overall workload would be more manageable. WhatamIdoing (talk) 04:36, 10 February 2021 (UTC)
Another restruction could be to limit one open request per article. This can be combined with limiting the length of the requests and hopefully allow for a faster completion rate. Z1720 (talk) 14:54, 10 February 2021 (UTC)

Reply by OP: consolidated list of ideas

First of all, thanks to everyone who weighed in here with a comment. I didn't know if this would find much interest, but I'm glad to see that a number of others agree that the current process could be improved upon, with many different ideas suggested.

Having read through them all, I am persuaded that a straight "RfC but for COI" is not the right approach—but the COI process could stand to incorporate some things that other projects are doing. Here is a consolidated list of suggested ideas, a few of which were mentioned favorably by multiple respondents, with short explanations where helpful:

Clearer guidance for COI editors

  • List common mistakes and corrections—Some aspects of WP:PSCOI do this, but not clearly enough
  • Point COI editors to Edit Request Wizard (ERW)—From guidelines and advice pages, and perhaps elsewhere

Suggest improvements to ERW

  • Integrate with Template:Edit request—An obvious oversight that should be easy enough to correct, good catch by Izno
  • Build out ERW around common request scenarios—Building on a point made by FeldBum, the current template asks for the suggestion, rationale, and references, which is good but could be expanded, e.g. customized for situations where the COI contributor wants to suggest additions, removals, or modifications
  • Update to use fields more than talk pages—ERW currently sends users to multiple talk pages; if fields could be used like the Commons upload wizard, it would be easier to use still

Improved process for reviewers

  • Clearer instructions for review process—As noted by Z1720
  • Leaderboard to recognize active editors—Suggested by Sphilbrick

Improve Edit request template in a few ways

  • Add a TLDR summary parameter for possible transclusion—As noted by Schazjmd and Sdrqaz, edit requests are too long to transclude; this could be one solution
  • Make more like AfC with feedback and cure period—Suggested by more than one respondent, and I wonder if some templated responses might be helpful in saving reviewers' time

Organize under a WikiProject—First suggested by P,TO 19104 and seconded by others

  • Consolidate guidance for both parties—Improved instructions for both COI editors and reviewers available here
  • Centralized noticeboard—List all requests for reviewers, perhaps with transcluded TLDR summary
  • Prominent ERW access point—Explain ERW and make access prominent here for COIs

Incorporate article alerts—Fascinating suggestion by WhatamIdoing that I don't know enough about, which would require associating the edit request with topics, likely by WikiProject

I think that's a pretty good summary of various ideas that could all work together in some form. A few questions here, to suggest next steps:

  1. If I left out an idea you think is important, by all means feel free to make the case for it in reply here. :)
  2. Any points of clarification or additional information to add about specific ideas mentioned above?
  3. Are there specific ideas in the above that editors weighing in here are experienced with or feel qualified to actively work on?
  4. Any suggestions on how some or all of this could be effectively proposed on Village pump proper?

Thanks in advance, WWB (talk) 17:45, 12 February 2021 (UTC)

WWB, excellent summary. Maybe one step on the "clearer guidance" could be adding a Wikipedia:Edit Request Wizard/COI link to Template:Connected contributor, and a Wikipedia:Edit Request Wizard/Paid link to Template:Connected contributor (paid)? That would give the wizard a little more visibility. (I didn't know it existed.) Schazjmd (talk) 18:10, 12 February 2021 (UTC)
Associating edit requests with topics is usually easy, because most articles are tagged by at least one WikiProject. WhatamIdoing (talk) 19:01, 12 February 2021 (UTC)
Those are good ideas. I just realized I should have pinged Sam-2727, who is the creator of the ERW tool, so now I have! WWB (talk) 20:59, 12 February 2021 (UTC)
@Certes has given me a URL that lets me find edit requests on pages tagged by WP:MED. Here it is:
https://petscan.wmflabs.org/?&sortby=ns_title&ns%5B1%5D=1&edits%5Banons%5D=both&ns%5B0%5D=1&search_max_results=500&cb_labels_yes_l=1&depth=3&language=en&edits%5Bbots%5D=both&project=wikipedia&interface_language=en&categories=Requested%20edits%7C0%0AWikiProject%20Medicine%20articles&edits%5Bflagged%5D=both&cb_labels_any_l=1&cb_labels_no_l=1&before=
If you click the "Do it!" button and then wait a moment, you should see that there are three articles listed at the moment. You can do the same thing for WikiProject Biographies with this link, and in general, you can swap in the analogous category for any WikiProject in the box in the middle of the page. WhatamIdoing (talk) 02:59, 14 February 2021 (UTC)
WWB, thanks for the ping. I didn't know this discussion was ongoing. I was just reviewing the performance of the ERW tool (using this search [1]), and have found mixed results. On the one hand, we seem to have some editors successfully using the suggested fields. On the other hand, we have some editors ignoring the suggested fields and writing a very unhelpful edit request. There are some other problems as well, albeit not as large such as not using the tool for its intended purpose (e.g. to request page moves). I think the proposal above to make the tool in javascript, similar to WP:FUW, is a great idea. Although we've tried to limit the technical knowledge required for edit requests as much as possible, there are still problems. In fact, I feel strongly enough that this change should be made that I would like to work on it. Unfortunately, as I have a limited knowledge of javascript (and particularly its use on Wikimedia), it will take me some time to do so, so if somebody wants to step in and help me/take over, that would be much appreciated.
Overall, I see a very large lack of organization surrounding edit requests. Inconsistency into how users should request edits, how we are responding to edits, and poor documentation surrounding the edit request process. Hopefully WP:Wikiproject Edit Requests could alleviate this. Could someone set up the wikiproject (since it sounds like most people support this idea)? Sam-2727 (talk) 03:22, 13 February 2021 (UTC)
​​​​​​​​​​​​Pinged responding editors Given that I have not had previous experience setting up a WikiProject, I have made it a formal proposal at Wikipedia:WikiProject Council/Proposals/Edit requests. If interested, please leave suggestions/feedback. Sdrqaz (talk) 02:22, 14 February 2021 (UTC)

The OP emailed me to request a comment as another paid editor. IMO, Wikipedia would be better-off consolidating processes, rather than creating new ones. Edit-requests and pending changes are already well-suited for requested edits. Both are easy to add COI disclosures to in an edit-summary or Talk page. Both already attract editors that have an interest in reviewing edits by others.

IMO, adding a feature that allows a user to opt-into pending changes is the best option. Many new volunteers may also find this feature useful, if they are uncertain about an edit. It would give the reviewing editor a diff of the requested change(s) and make it easy to request small changes at-a-time with an explanation of each change in the edit-summary. It would also avoid flooding the Talk page with something edit-summaries are better-suited for.

Frankly, I think the complaints about reviewing Request Edits being time-intensive are largely self-inflicted. Editors treat requested edits as if they were RfCs and are often obsessive about trivial details like wikilinks, accessdates, and so on. I can review most request edits in less than one minute. It may take hours to ensure the requested edit is perfect, but less than a minute to see if it is an improvement. CorporateM (Talk) 19:23, 14 February 2021 (UTC)

Agree with CorporateM--I've been through many GANs that are less exhaustive than COI requests. The current process is clearly not working. For example, I had an edit request made in October. When I reached the front of the queue in February, It looked like someone might answer it, and then they didn't, putting me back at the end of the queue with 200 requests in front of me (probably another six months of waiting at current pace). I see how proposals to limit edit request size could be tempting from a reviewer perspective, but then from the COI side, if it takes 6-10 months to get a response to a single request, you want to put in all your requested changes at once. I would love to have input from more than one reviewer for edit requests, and more of an emphasis on "is this a net positive?" rather than "does this meet the standards of FA?" Enwebb (talk) 15:32, 26 February 2021 (UTC)
I looked a few of them recently, so I'll share my experience:
Only the second was a really long request. WhatamIdoing (talk) 01:44, 3 March 2021 (UTC)

i would like a article on Tim's reinforced slingshot

this is the reinforced slingshot https://cults3d.com/en/3d-model/various/tim-postma-s-reinforced-slingshot though is also available on MyMiniFactory — Preceding unsigned comment added by Tim3dPostma (talk • contribs) 17:24, 24 February 2021 (UTC)

@Tim3dPostma, TimPatAlPostma1996, TimPostma3DPrints, Timpatalpostma, and 3DPrintingTimPostma: You need to immediately stop trying to promote your catapult. It does not, nor ever will deserve an article here. Wikipedia is not for promoting your inventions or design modifications. Your editing has become disruptive, and I am about to leave you a formal warning on your multiple usepages, not only about creating and using multiple accounts at the same time (see WP:SOCK), but also to warn you to stop using Wikipedia a forum to try to discuss silly off-topic matters, unrelated to the article in question. In essence: stop editing rubber band-related articles. Nick Moyes (talk) 23:59, 24 February 2021 (UTC)
@Nick Moyes, how big of a problem is this? We could ban the URL if it would help... WhatamIdoing (talk) 01:53, 3 March 2021 (UTC)
@WhatamIdoing: Not a big problem. Just a young kid, possibly on the spectrum, who misunderstood the purpose of Wikipedia. Another admin has since blocked their various, good faith sockpuppet accounts (if that isnt an oxymoronic term) so no further action is needed. Thanks, Nick Moyes (talk) 07:47, 3 March 2021 (UTC)
Thanks for the explanation. WhatamIdoing (talk) 19:44, 3 March 2021 (UTC)

Allow all users to view only their own deleted contributions

Today I was looking at my edit count. It had said that I had "306 deleted edits" and I wondered, to what pages were they. I looked, and got the following message:

You do not have permission to view a page's deleted history, for the following reason:

The action you have requested is limited to users in one of the groups: Administrators, Oversighters, Researchers, Checkusers.

And I was all like, "Well, it's my contributions. Why can't I see it?" And I know all their arguments: The pages are deleted so that people can't view them, and some are actually harmful etc. But I am proposing that, say, if there was a non-admin named Example, then, under my proposal, the only people who would be able to see Special:DeletedContributions/Example would be admins, and Example himself. I must clarify that. It would be like editing /js and /css pages (only user and interface admins can) except that all admins would be able to view it. Any thoughts on this? Changes to the proposal are welcome. 🐔 Chicdat  Bawk to me! 12:25, 25 February 2021 (UTC)

This is not going to happen. We could hypothetically amend MediaWiki to allow you to view deleted pages to which you were the only contributor, but what you're proposing would mean that if someone wrote a page filled with libel and you happened to make a single typo fix to it before it was deleted, we'd be granting you the right in perpetuity to read that libel. I can't imagine any circumstances in which Legal would ever allow this. ‑ Iridescent 13:10, 25 February 2021 (UTC)
As a practical matter, if you want/need to see something of yours that has been deleted, you could ask at WP:REFUND. Depending on what it was, an admin might be willing to undelete it to your sandbox, or perhaps even email it to you (not all admins are willing to do that). Alternatively, there's a number of wikipedia mirror sites where you might still be able to find a copy. I think most of them are pretty slimy, so I won't mention by name, but I'm sure you can find them if you google for "wikipedia mirror". -- RoySmith (talk) 13:27, 25 February 2021 (UTC)
That's not what I'm looking for. I myself saved a userspace copy of my only real article that was deleted. I was talking about Aasim's idea. 🐔 Chicdat  Bawk to me! 11:19, 27 February 2021 (UTC)
I think deleted edits should show up in the same manner as revision deleted edits. So if a page is deleted, it removes the edit summary and the revision, but not the user from the contributions page. Aasim (talk) 18:37, 25 February 2021 (UTC)
But like was noted above; there are reasons outside of notability why an article might be deleted (copyvio, libel, gross vulgarity, etc.) and the software has no means of telling one edit from another. Lets say you were a new page patroller who tagged an article for speedy deletion as a offensive attack page. Now you're an editor of that article. There's no gain to be made from allowing you as the article tagger to view the content. It's not like you had a meaningful contribution. A large proportion of deleted articles fit in this type; I understand the impetus from the OP, they're envisioning an article they created which failed notability checks, and was deleted via an AFD or something, and now they want to look in on it and see if they can fix it up and make it acceptable. That's certainly some of what we delete, but it isn't all of what we delete, and much of what is deleted really should never be viewable again. The software has no means to differentiated between that kind of content NOR does it have a means of distinguishing from among a group of several editors, who created the content and who tagged it for deletion. Those are all just "edits". --Jayron32 18:57, 25 February 2021 (UTC)
I don't think Aasim is talking about content or edit summaries, but rather just revision history of deleted edits. If I remember correctly from a past discussion, this data is already available via the API. See Wikipedia_talk:Sockpuppet_investigations/Archives/Archive23#Useful_user-right ProcrastinatingReader (talk) 19:32, 25 February 2021 (UTC)
You mean like just a raw list of the edits that were deleted, not like diffs or anything? That seems less objectionable. --Jayron32 19:55, 25 February 2021 (UTC)
Basically: 1 January 1970 (diff | hist) . . (Edit summary removed) on the contributions page. Aasim (talk) 20:51, 25 February 2021 (UTC)
Yes! That's what I mean. I can't see the revision, or edit summary, or history — I can just see the name of the page I edited. 🐔 Chicdat  Bawk to me! 10:54, 26 February 2021 (UTC)
The WMF actually already does make this public, but doesn't provide an on-wiki interface to it. The query looks like this. —Cryptic 07:33, 5 March 2021 (UTC)
Well, thank you. 🐔 Chicdat  Bawk to me! 11:05, 5 March 2021 (UTC)
This request basically requires phab:T20493 to be resolved first, which has some issues as-is. --Izno (talk) 20:58, 25 February 2021 (UTC)
You can still make a request at WP:REFUND for various bits of information like this. Revision history, even with edit summaries without text, should be available in most cases. Sometime people will ask for references, or just ask a question - was the delete page about x? When it comes to user:Chicdat deleted contributions, many are due to speedy delete tagging by the user. Quite a number of edits are to sandboxes or pages in Chicdat's userspace. Some are AFC work, that later was deleted; in one case a draft that you improved was deleted as the original was a copyright infringement. The biggest number of deleted edits was to List of nicknamed tropical cyclones. Graeme Bartlett (talk) 12:16, 3 March 2021 (UTC)

Rfc: More informative edit changelog

I propose to show the change in the number of words on a page for each edit in the revision history, in addition to the current metrics shown. This should exclude references, but include paragraph text and headings. There are some questions to be answered on whether changes in tables, captions and other types of formatted content should be shown, but my inclination would be to keep it simple and only show headings and text. Perhaps in the future, changes could be automatically tagged with the type of change that was made (i.e. adding images, or adding citations etc).

My motivation for this change is that the current system showing the change in bytes, does not tell me how much text was added and hence someone who adds a couple of references and citations could have a similar change in bytes as someone who has written a paragraph without citations. Philipp.governale (talk) 23:25, 4 March 2021 (UTC)

Philipp.governale, enable Navigation popups in your Preferences under Gadgets. One of the features is Preview diffs and access both revisions in watchlist, history and related changes just by putting your mouse over "prev" or "diff". StarryGrandma (talk) 02:19, 5 March 2021 (UTC)
StarryGrandma, Thanks a lot, I have discovered a whole lot of additional settings to try out as well! Very useful! Philipp.governale (talk) 02:31, 5 March 2021 (UTC)

Require mainspace edits for AfC/NPR/PCR/rollback

I decided we didn't have enough awful ideas here and I'm just throwing this one at the wall to see if it sticks. The idea: require some number of sourced statements added to articles (or copyedits, or any sort of substantive mainspace edit) before requesting permissions where you review others' work (initially I'm thinking AfC/NPR/PCR/rollback). Besides CREEP, I figure the biggest issue with this is there's no good number. If we require enough edits that it actually has the desired impact (that people get a reasonable amount of content creation experience), the two downsides of excessive overhead for PERM admins and excessive barrier to entry would outweigh any positive effects. And if we require a tiny number (single-digits), people will just grind through and make crappy edits, and nobody learns anything (and there's still PERM overhead and a barrier to entry). Interested, at any rate, in hearing what people think. Enterprisey (talk!) 06:23, 5 March 2021 (UTC)

Enterprisey, how would permission granters tell how many sourced statements someone has added? {{u|Sdkb}} talk 07:15, 5 March 2021 (UTC)
Ask them to link diffs, or check their revision history, maybe?
Saying "you have to link two diffs where you add sources" would pretty easily filter out requests by people who don't read the guidelines. Elli (talk | contribs) 07:19, 5 March 2021 (UTC)
Is complete newbies or other clearly unqualified editors requesting these perms much of an issue? (I haven't spent time on those noticeboards, so I don't know, but just double checking that this is addressing a problem.) {{u|Sdkb}} talk 07:30, 5 March 2021 (UTC)
I dunno, ask Enterprisey. I just don't see the implementation as a big barrier. Elli (talk | contribs) 07:38, 5 March 2021 (UTC)
The problem this proposal (which I must emphasize again is extremely half-baked) tries to address: getting one's stuff shot down, or even reviewed at all, is a bit of a pain. Thus, people who get the privilege of reviewing others' work should have done some of that work themselves before they get that privilege. A required mainspace edit count is insufficient, because of course not all mainspace edits are the same amount of work. So to sum it up, there's currently an imbalance between the work needed to write something and the work needed to dismiss it, and it would be nice to close that gap a little, or at least ensure the latter is done with some empathy. And yeah, I was thinking of asking candidates to list diffs as the most likely implementation. We could even have some automatic validation using a "withJS form" (a form shown by a script loaded by withJS), so "malformed/incomplete request" rejections become a thing of the past. Enterprisey (talk!) 08:52, 5 March 2021 (UTC)
And, of course, is that a problem - i.e. are newer editors actually getting bitten by reviewers who don't have enough content experience? I don't know at all, but I wouldn't be surprised if so. I'm not sure how to collect hard numbers on this, but I'll think about it some more. Enterprisey (talk!) 09:04, 5 March 2021 (UTC)
The problem is that the newbies that feel bitten don't usually report it, at least not in constructive ways. Elli (talk | contribs) 10:03, 5 March 2021 (UTC)
For better or worse, a lot of RCPs/Hugglers (=> rollbackers) don't create content. I don't think this leads to issues with NPR/AfC. My feeling is that many AfC reviewers have high standards because they've added content before, but it's worth asking @Barkeep49 and Primefac (respectively) about those two areas. ProcrastinatingReader (talk) 16:48, 5 March 2021 (UTC)
AfC already has this requirement. Primefac (talk) 17:11, 5 March 2021 (UTC)
So I can tell you how I evaluate people who ask for NPR (the only PERM, I semi-regularly grant at this point). Before doing that I will ping Rosguill who is the most frequent admin responding to NPR requests these days (and who in my experience is a little bit more willing to grant the permission than I am).
When I look at a request, I am looking for a reason to grant the permission (as the first grant for me will always be some sort of trial which inherently removes some level of risk). I ask myself two questions: does this user have a demonstrable track record of being able to understand/apply the policies/guidelines involved and do they have the disposition to uphold the standard of conduct I expect from a New Page Patroller. The disposition checks are easy - I look at their block log, examine their user talk history, and check if they have any DS notices (as this can be a way to explore disposition in a more "heated" environment). User talk also gives me ideas of things I make need to explore when checking for understanding. I'm always going to check a CSD log (or failing that their edit/deleted history) as that's important to me one way or another - no CSD track record (or a poor one) is going to make for me to look for a higher standard for the rest of what I do. I'm going to look if they've done AfC. Since AfC and NPP have a lot of overlapping needs if they've done AfC and have a good record there that'll be enough for me to grant the PERM. After that I will switch to content creation. If they have created content, whether new articles or gone through FA/GA, that's going to be an excellent sign. I'm also going to check AfD participation as a way of applying this information if they don't have an AfC track record. Like I said if I get to a yes (i.e. they have done well at AfC) I'm going to probably stop looking and grant the trial.
Bigger picture, I do want to point out that NPR requires mainspace edits (500) rather than any kind of edit. Best, Barkeep49 (talk) 17:32, 5 March 2021 (UTC)
My process for reviewing candidates is similar enough to Barkeep49's that I don't think it's necessary to list the steps out in detail. I also agree that at least as far as NPR is concerned, the existing bar is high enough that I don't think we need any additional explicit requirements (although we may want to reconsider rewriting the rather sparse guidelines for granting to be more in line with what we actually expect from candidates). signed, Rosguill talk 19:12, 5 March 2021 (UTC)
To be honest, a requirement of "at least one non-stub created" might be better than 500 edits. Either-or, or as a replacement, I dunno, but I think content creation might be a good requirement, when the role is all about content creation. Elli (talk | contribs) 20:05, 5 March 2021 (UTC)
Enterprisey, I admit I don't have enough time to read the entire discussion here, but reading your post left me with thoughts I thought I'd just get out here – these are not going to be polished. Sounds like there are two general purposes you might seek to address with this proposal: (1) on the applicant side, signaling the right kind of experience needed, and (2) on the admin side, reducing discretion to grant (to reduce inconsistency, raise standards, etc.). The best way to accomplish these is with advisory, not mandatory, guidelines. On the first point, you'd be right to say that there's good reason to reduce the number of applicants who aren't qualified by discouraging some by raising standards: when we deny applicants, it's probably the first time they've been formally denied something on Wikipedia, and it can be perceived as a significant rebuke – not something we want to do if we can help it; plus, good guidance can provide information beyond "show competence" on exactly how to establish a track record. On the admin side, a mandatory standard simply is not going to work; your best bet is likely to (1) work PERM for a few months, then (2) write up what you think are good general guidelines, then (3) convince the dozen-or-less admins who work PERM that those guidelines (maybe with edits from them) are the right ones. Best, KevinL (aka L235 · t · c) 20:35, 5 March 2021 (UTC)

Regarding falseblocks under Sockblock

I recently came across User:IHateAccounts's talk page, and I think that we should allow appeals through socks only if they claim that they are not actually socks of the sockmaster. Like, suppose person A is not a sockpuppet of person B (sockmaster), then under WP:SOCKBLOCK, person A cannot appeal, as all sockblock appeals must be done through the sockmaster, which they cannot access. ThatIPEditor (talk) 08:13, 23 February 2021 (UTC)

How would you differentiate the innocent editors from the liars? WhatamIdoing (talk) 01:51, 3 March 2021 (UTC)
WhatamIdoing, By assuming good faith, and letting them have a shot. ThatIPEditor Talk · Contribs 17:06, 9 March 2021 (UTC)
So, in practical terms, you propose cancelling the rule entirely. Socks that choose to admit it could appeal through the sockmaster, but anyone could just claim that they're not a sock. Their lies will be believed even though we have some evidence to indicate that they're lies.
What exactly was the benefit to the community for your proposal? WhatamIdoing (talk) 17:13, 9 March 2021 (UTC)

Bringing back the GA Cup

Congratulations! Your GA has been approved!

The GA Cup used to be a competition that directly encouraged editors to improve more articles into GA status. But the last GA Cup was in 2016 and there hasn't been a competition since. To deal with the backlog of GA nominations, as well as to improve more articles to GA status in general, I suggest bringing this competition back. Thoughts? X-Editor (talk) 06:20, 27 February 2021 (UTC)

Yes. It always says on the template, "Please wait patiently", but many editors are impatient. A GA Cup would really reduce the backlog. 🐔 Chicdat  Bawk to me! 11:16, 27 February 2021 (UTC)
There was a major GA-backlog drive that got many of the same results without being in an actual cup form, last year I believe Nosebagbear (talk) 13:31, 3 March 2021 (UTC)
Nosebagbear, As somebody with a submission that's been on the queue for 3 months, and it looks like another 4 months to get reviewed, yeah, this would be awesome. Not that I'm complaining, mind you. I've only done a few GAs, but I've been totally impressed with the effort the reviewers put into it, with the end result being way better than how they were when the reviews started. -- RoySmith (talk) 21:49, 4 March 2021 (UTC)
RoySmith - I should clarify, I don't mind if the GA Cup is utilised, just that it wasn't because GA has just sat around not countering the backlog since 2016 - they've just utilised a non-competitive method. Either is good to me. My 1st submission to GA was at peak backlog - took c. 10 months before I caved and asked TRM to take a look directly, so I get the pain. Nosebagbear (talk) 22:01, 4 March 2021 (UTC)
There have been concerns raised in the past about poor qualities of reviews associated with the GA Cup (with similar concerns raised about the Wiki Cup) with worries about some editors being more concerned with passing articles in order to get the points rather than the quality of the articles. Any resumption of the GA Cup would have to address these concerns.Nigel Ish (talk) 22:52, 7 March 2021 (UTC)

Colourised photos

I don't think wikipedia should use colourised versions of photos that were originally made in black and white. A colourised photo is basically someone's artwork, and using it could be considered a form of Original Research. This issue has come up twice in the wikipedia chess project in relation to the Bobby Fischer and Alexander Alekhine articles and I'm sure it has come up elsewhere too. 10:07, 5 March 2021 (UTC)

The WP:No original research policy has a subsection that discusses user artwork and images (see: WP:OI)... in general such works are ok, but there are exceptions. Blueboar (talk) 13:17, 5 March 2021 (UTC)
In both of those cases, the original publication of the photograph was already colorized. There was no colorization by Wikipedians. That's a key distinction. Wikipedians aren't doing any original research on those photos because Wikipedians did not colorize them. Chess Life magazine did. --Jayron32 13:22, 5 March 2021 (UTC)
  • I mean, one could argue that taking a photograph and uploading it to Commons is a form of original research itself. My main concern about colourising isn't that it's OR or that it's artwork (we use paintings of people all the time), but rather that it has the potential to mislead. When colourised photos are used, it's important that we note that they have been colourised in the caption. If the colours are significant to the photo and it's not known whether they match those from real life, that makes it all the more important. {{u|Sdkb}} talk 20:37, 5 March 2021 (UTC)
  • It certainly is original research. One of the things that are pretty obvious when you think about them for a few seconds but everyone tries to sweep under the carpet is that nearly all images are original research. Now, I'm not saying that that means that we should not have images in articles, but we should be honest and say that we allow original research in this area, rather than pretending that we don't. Phil Bridger (talk) 20:52, 5 March 2021 (UTC)

If we get rigorous about it, 99% of Wikipedia is OR, but IMO this isn't OR by the commonly used meaning of wp:OR. But IMO colorized photos represent a corruption of / loss of the data contained in the original B&W photo. And if it is not identified as such, it is also misleading. But we don't need yet another rule banning them. North8000 (talk) 21:07, 5 March 2021 (UTC)

What do we need then? The original from Alexander Alekhine is an excellent photo and in my opinion looks better in its original black and white. Maybe a note of some sort in WP:OI? MaxBrowne2 (talk) 00:07, 6 March 2021 (UTC)
MaxBrowne2, it looks like WP:OI already covers this: It is not acceptable for an editor to use photo manipulation to distort the facts or position illustrated by an image. Manipulated images should be prominently noted as such. So there's our answer: we're required to note colourised images whenever we use them. {{u|Sdkb}} talk 23:45, 6 March 2021 (UTC)
See also this unfortunate sequence of events; in short the consensus there was that the colourised image was an interesting art work, but that the original black and white is more significant to depict its topic. Cheers, RandomCanadian (talk / contribs) 03:06, 7 March 2021 (UTC)
My 2 cents: I hate colourised photos. They typically look as though a kid has been at them with a box of crayons, so they are seldom realistic. It has become fashionable for newspapers and magazines to use colourised photos to make them appear modern, but Wikipedia should not be doing this.--♦IanMacM♦ (talk to me) 10:31, 7 March 2021 (UTC)
Moved from WP:VPR

Hello. I believe making a footer version of this sidebar would be of great help, as the sidebar sometimes takes too much space within the body of the article. What do you think? Also, I have no knowledge in coding, so if you agree then feel free to create said footer. Moreover, I am not sure if this forum is the proper place to ask. Veverve (talk) 13:04, 9 March 2021 (UTC)

@Veverve: here you go: {{Translation navbox}}. I've added it to all articles linked from it per WP:BIDIRECTIONAL. – Finnusertop (talk ⋅ contribs) 22:56, 10 March 2021 (UTC)

Encourage and switch raw Infobox data to to Wikidata

This was originally proposed on Wikipedia_talk:WikiProject_Wikidata#Encourage_and_switch_raw_Infobox_data_to_to_Wikidata but nobody responded so I'm posting it here before I formally propose it.

I notice that popular templates like Template:Infobox company's documentation indicate that Wikidata is supposed to be used a fallback, and that data that you know should still be inputted as arguments.

This seems a bit counterintuitive to the purpose of Wikidata. It also makes me, a Wikidata editor and Wikipedia Infobox Wikidata converter, feel like what I'm doing is pointless.

If people are still recommended to input raw information into infoboxes, then some data that they input might not be present on Wikidata. And that means that someone else is going to have come around manually add that data and it's reference to Wikidata.

Clearly, the best situation would be everyone that adds information and references to Wikidata and the data then shows up on Wikipedia in all parameters. That way all data is linked on Wikidata with appropriate items, can be used by other language Wikis (I think this is a really strong point), and is referenced.

But unfortunately this does not happen. Yes, we have bots that copy data from infoboxes to Wikidata, but that isn't set up or running for every type of infobox. Also, it shouldn't be needed. We should just have editors edit Wikidata and we wouldn't ever have to worry about it.

What I propose

  • Encourage editors to add statements for appropriate Infobox parameters on Wikidata so that they can simply just use the Infobox template and not have to fill in any parameters.
  • Create a Wikiproject/process of deleting raw-text Wikidata-backed arguments currently in Infoboxes so that they use Wikidata. This is to demonstrate what parameters have documented Wikidata, show that they are referenced, and encourage editors who see the Wikidata to continue using it.
    I'm aware this is quite radical, but I'd really like Wikidata to be of use and "linked", and not just replaced by duplicate work.
    Another solution could be just to have Wikidata override raw-text values or maybe just make it so that raw-text values can't even be used anymore (the template parameter would not even be used). See (Extra) solution below how Wikipedia editors could add this Wikidata easily.
  • (Extra) Maybe develop an indicator on infoboxes or some sort of process or program that makes adding statements for infobox parameters easier for Wikipedia editors. For example, an edit icon on a parameter that does not have Wikidata, but whose statement could be added by clicking on the icon.
    If that parameter has a raw text value, maybe it could be highlighted red to indicate it's not on Wikidata. An edit icon could be next to that as well that leads to Wikidata, and maybe even copies the data to Wikidata.

--Lectrician1 (talk) 21:06, 28 February 2021 (UTC)

  • Strongly oppose There are many reasons why this is a bad idea. Some are:
    1. Wikidata does not insist on sourcing in the way that we do, so picking up information from Wikidata means giving up our standards on requiring reliable sources.
    2. There are many fewer active editors at Wikidata than there are here, so vandalism is much less easily detected and dealt with.
    3. Simple data, such as dates of birth and death, might be appear to be appropriate to be retrieved from Wikidata (provided WP:BLP issues were fixed). Other apparently straightforward data is both disputable and disputed. People's nationality is a good example. Different language wikipedias can legitimately have different policies on matters like these (is "Tibetan" an acceptable nationality or not? do you use current or historical borders?). Taxoboxes are a particular case of infoboxes where multiple discussions have shown why using Wikidata would be a bad idea since classifications are subjective and different wikis make different choices.
A more general problem is that the data analysis and design of the Wikidata item has to closely match that used here for this to work. As an example, review the discussions at Template talk:Cite Q to see some of the problems in the case of citations. Unless the Wikidata item handles fields in the same way that our citation templates do, the information can't be retrieved properly. I think most data design problems can be overcome, but it does require an open dialogue between editors in language wikis and Wikidata editors, and an acceptance there that Wikidata has to fit the language wikis and not vice versa. This has been difficult to achieve to date, to say the least. Peter coxhead (talk) 09:38, 1 March 2021 (UTC)
Since these same points inevitably come up in every Wikidata-related discussion, I feel obliged to comment. While the gist of the critique is correct, some details are outdated.
  1. While it is true that, in practice, Wikidata is not as well sourced as Wikipedia, in theory, the verifiability standard is very close to ours – although as of this time, the d:Wikidata:Verifiability policy has not been formally approved. In any case, whatever templates we use here may be configured to fetch only data that is referenced, and referenced to a particular standard (e.g. not to Wikipedia).
  2. It is probably true that vandalism is usually not fixed as fast on Wikidata as it is here (though I'd like to see some numbers), there is also much, much less of it.
  3. Wikidata supports multiple values for a single fact. It's up to templates on Wikipedias that use it to determine which value to fetch, or what to do with the value (such as aggregate them to a parent class or category). As for BLP, Wikidata now has a d:Wikidata:Living people policy.
Cheers – Finnusertop (talk ⋅ contribs) 11:09, 1 March 2021 (UTC)
@Finnusertop: I accept that there are changes happening at Wikidata, albeit slowly. The problem with vandalism (or indeed well meant but incorrect changes) if Wikidata is used is similar to the problem with the automated taxobox system, which pulls taxonomic data from taxonomy templates stored here. I monitor the taxobox error-tracking categories most days, and, yes, there are fewer problems caused by vandalism to the taxonomy templates than directly in articles, because they are less obvious. But vandalism does occur, and when it happens it usually impacts multiple articles and can only be fixed by an editor who understands how the system works. If we do pull data from Wikidata, we would need some way of being notified here when the relevant Wikidata items change and some good error-tracking categories or other system. Peter coxhead (talk) 12:50, 1 March 2021 (UTC)

So it looks like some more technical challenges need to be addressed before we move to this system. --Lectrician1 (talk) 18:58, 1 March 2021 (UTC)

@Peter coxhead: Oh I agree. By the way, the English Wikipedia watchlist already shows if the associated Wikidata entry has been edited. – Finnusertop (talk ⋅ contribs) 03:22, 2 March 2021 (UTC)
@Finnusertop: showing changes in the single linked Wikidata item is not very helpful – which is what I understand happens at present – given that many uses would need to pull data from multiple items. This is already an issue with taxonbars when the taxon has multiple synonyms, each with a Wikidata item from which the taxonbar draws data. To watch Acmispon haydonii fully, for example, I would need to receive notifications about the four Wikidata items the taxonbar uses. The issue is even more obvious with {{Cite Q}}. It has to be possible in some way for a language wiki article to be linked automatically to each and every one of the Wikidata items it uses. Peter coxhead (talk) 07:16, 2 March 2021 (UTC)
  • Wikidata is also not inherently usable for those who know how to edit Wikipedia, and gets harder the more you need to do on it. This means any changeover would be particularly tough. I'd ideally want a cross-project tool that made it easier to work across to fix things. With regard to sourcing, when en-wiki upped its sourcing rules years back, actual implementation took a long time. I imagine it will take wikidata a fair while to fully promulgate and internalise any changes they're doing. Nosebagbear (talk) 13:30, 3 March 2021 (UTC)
  • @Lectrician1: We're not supposed to be making bolded !votes here, but despite personally largely agreeing with the proposal, I have a strong sense it would not have consensus here. The sourcing and vandalism problems are foundational blocks to Wikidata being adopted more widely on en-WP, so if you want to see adoption of the sort you propose, focus on solving those, then come back. It's also clear from the above that conversion would have to be limited to non-controversial parameters. As I'm sure you're aware, centralizing on Wikidata would be hugely useful for all the non-English languages, but most English editors only care about English and thus don't see that as a big plus. I predict it'll have to get to a point where it's just as convenient as adding data locally with no significant downsides before it'll achieve consensus. {{u|Sdkb}} talk 16:41, 3 March 2021 (UTC)
  • NO - This has now become a perennial question, and the answers as not changed: consensus at Wikipedia.en is that we do NOT want information exported from Wikidata (except in a few very limited situations). Perhaps we need a new policy page that enshrines this consensus in clear language (something we can point to whenever it comes up... but more importantly, something that explains why exporting information from Wikidata is not considered acceptable, and lays out what the few exceptions are). Blueboar (talk) 15:13, 4 March 2021 (UTC)
I want to expand a bit to explain my (admittedly extreme) negativity towards Wikidata... I find that it is NOT user friendly. Perhaps the problem is that I am text oriented (and WD is data oriented), but when I have tried to locate and edit information at WD, I quickly become confused and intimidated to the point where I have to give up. I don’t understand how a typical WD page is set up. I can not even figure out how to locate the information I want to edit. Thus, I am not going to go there to edit something I can easily edit here.
Wikipedia is supposed to be an encyclopedia that anyone can edit. If, in order to change something here, I were required to go over to WD to implement it, I could no longer make my edit. Wikipedia would cease to be an encyclopedia anyone (ie me) can edit.
The proposer mentions that the way Wikipedia operates, it is “counterintuitive to the purpose of wikidata”. My reaction to that is: “So what?... that’s WD’s problem, not ours”. To go a step further, I would say that WD’s “purpose” may actually be at odds with the “purpose” of WP... and because of this, it may be that the two projects will never mesh the way you would like. Blueboar (talk) 16:57, 4 March 2021 (UTC)
It's already been discussed in RfCs and even an ARBCOm ruling a few years ago, though it's not so simple as "yes" or "no". -- GreenC 17:27, 4 March 2021 (UTC)
Blueboar, I agree that Wikidata's interface is not user-friendly, which is a big problem. Part of the issue is that it needs to format information so that it's accessible to both computers and humans, rather than Wikipedia which only needs to focus on humans. Still, that aside, I think there's a lot of room for improvement, and once that's taken place, I don't agree that the aims are irreconcilable. There is a lot of information that we currently waste energy updating manually (e.g. the annual revenue of companies each year), when it could just be imported in bulk to Wikidata and updated automatically. That would help keep a lot of lower-traffic pages (and pages in lower-traffic languages; Wikimedia is a global movement, so let's not be Anglocentric) more up to date and save a colossal amount of editor effort. All of that directly aids us here. {{u|Sdkb}} talk 07:25, 5 March 2021 (UTC)
Yes, more integration between Wikipedia and Wikidata will be a big positive for small wikis that have few active editors. For example Kannada Wikipedia's article about Michelle Obama showed her as the current first lady of USA till I corrected it today [2]. Wikidata integration of Infoboxes will solve problems like this in small wikis. I understand Wikidata's interface it too technical. Wikipedia editing itself is hard for new users when compared to some other sites. Unless Wikidata becomes more user-friendly, we can't expect regular Wikipedia editors to edit there. AVSmalnad77 talk 17:15, 16 March 2021 (UTC)

Easier new articles suggestion for non-contributors

Personally, I think that proposing a new article for Wikipedia readers has more barriers than it should. I think readers in particular should be able to suggest new articles for creation very easily with the assistance of a helpful user interface that simplifies the process. As far as I understand it (I am quite a new contributor myself), everyone that wishes to request an article, has to navigate to Wikipedia:Requested_articles , find the correct subject and category and then edit the page and add the suggestion. This is probably much too cumbersome for most Wikipedia readers.

I see multiple benefits should something like this be developed:

  • · Help create a wider coverage of content. In turn this will probably increase engagement with Wikipedia as a whole
  • · Help balance bias of typical editors (most editors are males from western nations) however readers I believe are more diverse (needs verification)
  • · May encourage some readers to become editors themselves

These advantages could help make Wikipedia a more useful resource for more people. In terms of the implementation, I think such a feature should include a searchable dropdown menu that helps people select the correct category. Additionally I believe users should be provided the opportunity to explain why the subject is notable and deserves a Wikipedia article.

My apologies if something like this has already been suggested. Philipp.governale (talk) 01:23, 6 March 2021 (UTC)

Philipp.governale it's a laudable goal, but the requested articles system is already overwhelmed with thousands of non-notable entries that will never be created. There is probably a better way we could be doing this, but a bit of a barrier to entry to cut down on a huge influx of entries isn't the worst thing - there is no lack of requests. Elli (talk | contribs) 01:57, 6 March 2021 (UTC)
Elli with regard to your concern of overwhelming the requested articles system:
  • With this new proposed UI we could have a clear summary of the criteria for notability and eligibility on Wikipedia. The current requested articles system does not explicitly put those critera on the page, instead users need to navigate elsewhere to find them.
  • Perhaps a notability flagging system on new article suggestions could be used to filter out non-notable entries. The suggestions that get a lot of non-notable flags by users are burried to the bottom of the list and eventually deleted
  • Having to explain why the proposition is notable may lead some people to realise that their subject is not notable enough
and with regards to your comment that some barrier to entry is a good thing, I disagree.
  • The barrier to entry will primarily only discourage those who may be not so comfortable with the technology, but may nevertheless have a perfectly good article suggestion. As such, we may be reinforcing Wikipedia's content bias by making it harder for certain communities to contribute. These communities may for example include the elderly and people with little or only recent access to the internet
  • If requests are primarily of notable or valid subjects, I wouldn't personally mind having many entries. With greater variety more people may find articles that they have interest or experties with - Philipp.governale (talk) 04:25, 6 March 2021 (UTC)
    Philipp.governale fair enough. I definitely think the process could use a redesign - requested articles should require RS for example. How that happens is... well, all ideas should be on the table. Elli (talk | contribs) 04:30, 6 March 2021 (UTC)
Elli good point on requiring RS. I am not sure though that we should require RS on submission, but perhaps make it optional and then allow others to add RS if they find any? Not really sure on how this should be best done as for me a careful balance should be found between reducing entry barrier and ensuring the system is not overflooded with non-eligible entries as you mentioned. The reader that made the suggestion may not necessarily be comfortable with performing research and shouldn't have to in order to suggest an article. On the other hand, this significantly increases the burden on the community that is already stretched as it is. If we do require RS, we would still need to the community to somehow vet the sources. This would still be easier than requiring the community to find the sources themselves. - Philipp.governale (talk) 05:00, 6 March 2021 (UTC)
Philipp.governale if we don't require RS the system gets backlogged with thousands of non-notable pages that no one bothers to remove. Elli (talk | contribs) 05:14, 6 March 2021 (UTC)
Elli Okay agreed. Should the responsibility lie on the editor that is considering writing the article to check the reliability of the supplied sources? - Philipp.governale (talk) 05:24, 6 March 2021 (UTC)
Philipp.governale yes. My point is that editors who monitor the lists should be able to remove entries without a reliable source listed. I think this is already kinda the case, but there are still thousands of requests without them. Elli (talk | contribs) 05:37, 6 March 2021 (UTC)
I have a proposal: how about only letting users post things on Requested Articles if they give at least one reliable source that states notability? 🐔 Chicdat  Bawk to me! 11:11, 6 March 2021 (UTC)
Chicdat In my opinion finding RS which explicitly state notability may be too difficult and simply impossible for some subjects. Another question I would have is: what counts as stating notability? Usually the existence of multiple RS should be sufficient to determine subject notability. - Philipp.governale (talk) 11:51, 6 March 2021 (UTC)
@Philipp.governale and Chicdat: If we can't prove notability of something, it should not have an article and the article will never get made. Requiring some amount of significant coverage, or another reason the person is notable (meets a SNG) is reasonable. Elli (talk | contribs) 02:55, 7 March 2021 (UTC)
  • I mean a button at the top of each that would open a templated page with at the top noting that to show notability sources that were: reliable, independent and secondary (and giving examples of secondary), as well as in-depth, and then having bulletpoints for sources 1, 2, & 3. If individuals can't find at least 2 sources then they shouldn't be being added. Obviously anyone who ultimately considers the suggestion will have to give their own review, but passing a prima facie notability case should be required for any inclusion in RA. We could even attach an edit filter that barred it if there weren't at least 2 URLs in it. Nosebagbear (talk) 11:18, 7 March 2021 (UTC)
NosebagbearI like the idea of including examples of what secondary and reliable sources look and don't look like. What do you mean by having bullet points for sources 1, 2, &3? In terms of an edit filter detecting URLs we would have to pose the question: are there notable subjects which may not have RS online? Philipp.governale (talk) 03:47, 8 March 2021 (UTC)
Like when using the WP:ERW it loads a template with several bullet points and a comment next to them, saying what should be put there (reason for change, source etc), that method could be used here. The online source is a fair one, but any thoughts on how to use some process to filter - otherwise, if it becomes more visible/easier, it's going to get skipped past by large numbers and require manual reviewing to filter. Nosebagbear (talk) 09:03, 8 March 2021 (UTC)
Nosebagbear I completely agree that it would be really nice not to have to manually review the sources, but nevertheless I think all sources (including online ones) will need to be checked to make sure they meet RS criteria. Perhaps for offline sources we could require additional fields for author, publisher, year etc. to make it harder for people to circumventing the system? That way we could also include the edit filter which detects the URL and the user simply selects the type of source they are using. Philipp.governale (talk) 00:39, 9 March 2021 (UTC)
@MMiller (WMF) and @Trizek (WMF), is this something you're looking at? I know there has been discussion in the past among edit-a-thon coordinators about the difficulty of making lists of notable subjects. Some editing events want to start with a pre-vetted list of suggested topics, so they'll talk to subject-matter experts to make a list in advance. If you've got a professor of indigenous art who's willing to identify a dozen important indigenous artists missing from Wikipedia, you don't really want this to be stopped by a UX problem. Whatamidoing (WMF) (talk) 00:50, 9 March 2021 (UTC)
The Growth team works on easing newcomers first steps, but we aren't covering article creation (yet).
However, we offer several features to help newcomers discovering how Wikipedia works. Newcomers make real edits based on their favorite topics and some maintenance tasks, and they are guided while editing. Creating an article is a complicated task, which requires to know which style to use, which sources to provide, etc. Growth features are here to help people learning about all this, step by step.
There is a project page about these features here on English Wikipedia. Trizek (WMF) (talk) 13:32, 9 March 2021 (UTC)
I like the idea of restricting requested articles to only requests that can quote two sources. But two URLs would be a problem as it precludes some reliable offline sources and doesn't filter out some of the usual suspects for unreliable urls - facebook, LinkedIn, the Daily Mail etc. Ideally we need a system that guides people into not using such sources. As for editathons, in my view best to avoid new articles. Something like 75% of editors start by altering an existing article, and it is much less contentious to start newbies by improving existing articles. ϢereSpielChequers 16:36, 17 March 2021 (UTC)

Authority control

Now at Wikipedia:Village pump (proposals)#RfC: make Template:Authority control more reader-friendly
The following discussion has been closed. Please do not modify it.


Due to the long-standing disputes concerning Template:Authority control, and the ongoing TfD for Template:ACArt which seems unlikely to get a clear consensus either, I have been brainstorming 2 potential RfCs: but I would like lots of input and improvements before actually starting them, to get it as neutral, clear and useful as possible.

Background

Authority Control is a template that is included in 1.7 million enwiki articles by now: it shows as links a number of "unique identifiers" from organisations around the world. All the data is stored on Wikidata, nothing is stored here. The proposed RfCs won't change anything about how Wikidata deals with these: it is purely about what, and how, we want to show at Enwiki.

Opinions about authority control are (sometimes fiercely) divided, and two of the main objections against the current template are a) the looks: obscure acronyms followed by (often long) meaningless IDs, and b) the linked sites, where often a considerable number of them are useless for nearly all readers of enwiki.

With an example taken from Kenzaburō Ōe, the current result of the Authority Control template looks like this;

Proposals

Proposal A

Change the links to authority IDs: currently they are an acronym plus a unique but often meaningless ID. In the proposal they would become a readable, textbased link. The links could also be organized to make their use clearer, and to avoid repetition.

The above is a very simple mockup of how it could look. This is an example, and not necessarily the end result.

Proposal B

Restrict the links to authority IDs based on the topic and country of the article: currently all IDs which are defined in the AC template are shown by default, even if they have very little use on enwiki: for example, here we have the link to the ID of the Swedish national library[3], for a Japanese author on the English Wikipedia. The value for readers is nil; the few people who actually can use this (software developers, librarians) would do better to find this at Wikidata, where they can e.g. also find the "Hong Kong Chinese Authority (Name) ID"[4] or the Portuguese National Library ID[5].

The above is a very simple mockup of how it could look. This is an example, and not necessarily the end result.

Proposal A+B

The above is a very simple mockup of how it could look if both proposals were combined. This is an example, and not necessarily the end result.

Purpose

Proposal A (layout) could either be a change to the default (i.e. immediately visible on every page that uses Authority control), or an option.

Proposal B (contents) would not change anything to the authority control default template: it would either be a series of wrapper templates like Template:ACArt, or options on the main template. If these would be accepted, then some decision is needed whether they can be added en masse to relevant articles, or need to be discussed individually (or per project, or...).

Discussion

Please discuss, brainstorm, improve. Fram (talk) 13:39, 15 March 2021 (UTC)

  • I'm not bothered by how this looks but, at a glance, version A looks best.
What bothers me more is that the edit count grinders have discovered this template and are putting it everywhere – that's why the usage is so high. If the template can be used on an article like Welsh rarebit then it can be used for any topic. It would thus be efficient to incorporate it within an existing footer template like {{reflist}} so that all the references are shown together in a consistent manner without any need for additional edits. If there are no relevant authority control IDs then nothing will be shown.
Andrew🐉(talk) 14:41, 15 March 2021 (UTC)
    • That's a horrible idea. AC is not a reference nor a reference system, nor should we depend on reflist to be present to have access to authority control cross-linkage. And there are no other templates of particular interest that fit the requirement of merging. (And fundamentally, our templates should do one thing well, and only that one thing.) --Izno (talk) 15:16, 15 March 2021 (UTC)
      • It doesn't have to be the {{reflist}} template. It might just as well be the {{infobox}} or {{short description}}. These templates are all intended for general use in most articles and typically crosslink to external data, references or sources. It's silly to have multiple templates for such standard boilerplate. Andrew🐉(talk) 15:28, 15 March 2021 (UTC)
  • I am not personally sold on the utility of this template, but there seems to be a large set of people who are. So there's that.

    I like the look of A, especially 1) getting rid of the opaque identifiers, and 2) grouping as suggested (I have a minor suggestion which is to give this template a heading like normal navboxes and then move "Authority control" there, leaving general for the top row). Users interested in the identifier are more than welcome to navigate (as I am sure many will).

    I am not particularly a fan of option B, as this is not an English-only wiki at the end of the day (in language and in super-national entity of English-speaking states), nor is that true of any other language. (In other words, I directly disagree with one of the unsupported assertion that many links are useless for our readers [should we have this template].) --Izno (talk) 15:12, 15 March 2021 (UTC)

  • This template evolved over time because people were adding individual links in the External links section. So they were aggregated into a pithy template. Good idea. Remove this template and it creates the same old problem, and good luck trying to stop IDs from being added at all because there are some good arguments for inclusion. Thus we need this template. They all seem fine to me. -- GreenC 15:44, 15 March 2021 (UTC)
    • When you say "they all seem fine to me", do you mean all proposals, all IDs, all...? Proposal A doesn't remove any IDs, it only changes the layout. Proposal B and AB remove some IDs (but not all by far), and they are mostly IDs no one would bother to add manually in the vast majority of cases (like the Croatian national library for non-Croatian subjects); otherwise, why aren't people adding the IDs which exist on Wikidata but not (yet) in the authority control template, like the Icelandic or Portuguese national library? Removing the template completely, while raised by some responders here, is not the subject of this proposal (directly or indirectly). Fram (talk) 15:56, 15 March 2021 (UTC)
  • I agree that the original template is a rather messy list of acronyms that could best be replaced with some descriptive text — as in option A — but that does make the output a bit bulky. The "correct" solution is to have a separate special page, much as we have for ISBNs. For AC, it could even be linked from the Tools menu and not be output in the article at all. Still, in the real world, changing the links to text is achievable. Limit the RFC to a change of template presentation (keep the same number of links...) otherwise it will never get anywhere — GhostInTheMachine talk to me 16:04, 15 March 2021 (UTC)

Okay, thank you all. Unless new discussion follows, I'll start an RfC about proposal A. I'll keep proposal B for a later date (or never), at the earliest after the Proposal A RfC is finished, as the two are independent of each other anyway. Fram (talk) 09:05, 17 March 2021 (UTC)

Define "recently" for CSD R3

started at WP:VPPOL#Define "recently" for CSD R3

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Wikipedia:Criteria for speedy deletion#R3: "This criterion does not apply to redirects created as a result of a page move, unless the moved page was also recently created."

Here, "recently" is undefined, which caused Fastily to be screamed at. Now we have to discuss page moves like these.

I'd suggest defining "recently" as "less than 7 days ago" (page created on Monday, eligible for R3 up to and including Sunday) but open to other ideas. — Alexis Jazz (talk or ping me) 11:22, 22 March 2021 (UTC)

Support, although I would also support "unless the moved page was created within the past month", as not all new articles are immediately reviewed which is often when titling problems are addressed. Schazjmd (talk) 15:09, 22 March 2021 (UTC)
  • Great idea. Many other community processes run on 7-day intervals, so this is a sensible length of time. -FASTILY 19:19, 22 March 2021 (UTC)
  • Support as "recently" could mean anything up to years. So good to define it, a week is OK, a month would also be acceptable. Graeme Bartlett (talk) 00:01, 23 March 2021 (UTC)
  • Support I would have suggested 30 days, but if people are saying that three days isn't sufficiently recent, this is an improvement. 力 (power~enwiki, π, ν) 00:05, 23 March 2021 (UTC)
  • The original reasoning was to avoid breaking incoming external links. Anything up to a couple months is sufficient for that. I think 7 days is so short that it imposes an unnecessary maintenance burden here, though. —Cryptic 00:22, 23 March 2021 (UTC)
The main benefit is IMHO in defining "recently" to avoid people being screaming at, the actual period is less important. I see multiple suggestions for a month above, I would be just as happy with that. "30 days" is slightly less practical as it will sometimes require calculation, with "a month" one can simply look at the day of the month. — Alexis Jazz (talk or ping me) 10:08, 23 March 2021 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

"Year in review" articles

I've noticed that different topics have different lead sections and different ways to put events, so I would like to make a proposal to fix them. I think this would be added to Wikipedia:Manual of Style/Lists.

PROPOSAL: Year in review articles are articles that review and summarize all of the events in the year.

General

The article should be the name of the year, then in, and then the topic it is referring to. For example, an article talking about politics in 2005 would be called 2005 in politics. The lead section should be just "Events from the year Year in review.", with no links in the lead. Everything should have a bullet point.

Topics

Places

It should start with a section for the monarch and/or leader(s) of the place, titled Incumbents. Then it should have a section titled Events, with subsections for each month if and only if there is at least one event for each month. Only events with specific articles should be listed. For example,

  • 1 July – Sony releases a new brand of headphones.

should not go in the article (unless there is a specific article about its release), but

should go in the list.

Art

After the lead, there should be a section called Works. Every work listed must have a separate article. Do not link to files. It should then include a list of Births, then Deaths in the year, in that order.

— Preceding unsigned comment added by -noah- (talk • contribs) 22:43, 29 March 2021 (UTC)

"Year in review" discussion

@-noah-: That sounds too rigid for many articles. For example, should 2020 in Burkina Faso have four one-line subsections for events by month? Or maybe less if we remove items with no article, which would leave 2010 in Burkina Faso essentially blank. Or maybe make 12 sections whether there are events or not like the ugly 1997 in Burkina Faso? If you want to work on years then you can join Wikipedia:WikiProject Years. PrimeHunter (talk) 23:42, 29 March 2021 (UTC)
@PrimeHunter:. Thanks for the feedback. Do you have any suggestions about what I could change it to? Noah 💬 13:08, 30 March 2021 (UTC)
@-noah-: I'm not active in the area. Wikipedia talk:WikiProject Years seems a better place to discuss it. Note that Wikipedia:WikiProject Years#Scope links to Wikipedia:Timeline standards. Many year articles display Template:Year article header. PrimeHunter (talk) 14:41, 30 March 2021 (UTC)
I think a way to fix this issue would be to only make articles like this if that year was fairly significant for the specific topic. So 2021 in Burkina Faso would only be made if something significant happened that year for Burkina Faso. Blaze The Wolf | Proud Furry and Wikipedia Editor (talk) 18:08, 31 March 2021 (UTC)
Burkina Faso has 22 million people. People would be screaming about systemic bias if we deleted a whole year of the country "because nothing significant happened". The problem is that we haven't added much to those articles yet, probably mainly due to a shortage of editors from the country. PrimeHunter (talk) 21:59, 1 April 2021 (UTC)
WikiProject Years, under whose purview this should fall under, doesn't seem to be very active currently. In any case, I think further development of such guidelines should probably be based on WP:Timeline standards, which already exists as a former guideline. More specifically, I would strongly oppose the proposed guidance that "The lead section should be just 'Events from the year YYYY.', with no links in the lead." This is in direct contravention of the manual of style. All lists, year lists included, should have a proper introduction as the lead section. That most of them don't is a current failure, not something to be advocated. --Paul_012 (talk) 15:28, 1 April 2021 (UTC)

Thank summary

Currently we can thank users. We thank them for a specific edit, or several. But what if we wanted to say why we were thanking the user? What if we wanted to add an additional comment? Similar to edit summaries, I think it would be nice if there were thank summaries. I've thanked a lot of users, and a lot of users have thanked me, but sometimes I'm wondering, what about the edit was so great? I know that thanks should be shorter than, say, barnstars, but these thank summaries would just be optional. 🐔 Chicdat  Bawk to me! 10:15, 3 April 2021 (UTC)

  • I have no comment on the merits of this issue, but I believe it would require developer time to implement. Dev time is a scarce resource, which I feel could be better spent elsewhere. ƒirefly ( t · c ) 10:59, 3 April 2021 (UTC)
  • My take... automated thank you messages are rather impersonal. I appreciate it when someone composes a more personalized message, and posts it on my user talk page. Much more meaningful to receive than an automated message. Blueboar (talk) 11:39, 3 April 2021 (UTC)
  • Some users would use it for other things, e.g. harassing or canvassing. Would the summary be public or private? If it's private then should some user groups like administrators be able to see it? We value transparency. As long as we don't have private messaging (I know we have email), I don't think we should introduce a similar feature for an unimportant official purpose. If it's public then you may as well post to them or ping them somewhere. PrimeHunter (talk) 11:42, 3 April 2021 (UTC)
    It would be public, viewable to other users (apart from the two, the performer and the receiver) through thanks logs. 🐔 Chicdat  Bawk to me! 12:41, 3 April 2021 (UTC)
  • Personal messages are always appreciated—please feel free to put a note on the user's talk page and let them know exactly what is so great about the edit in question! The thank you function works well as a way to give a quick indication of appreciation. In terms of cost-benefit ratio, I wouldn't want more effort spent enhancing it to replicate the functionality of editing a talk page. isaacl (talk) 15:56, 3 April 2021 (UTC)

Creating Articles for Restoration

I have had this idea for a while now, and I have been considering that we could make Articles for Restoration to vote on whether an article that has been deleted should be restored, much like Articles for Deletion. There have also been some pages that I would support restoring such as List of people with autism spectrum disorders and New England Independence Campaign. I am not sure if this has been proposed before, though I feel like this should be implemented. Blubabluba9990 (talk) 21:20, 3 April 2021 (UTC)

Note that Wikipedia:Requests for undeletion is meant for articles that were deleted via WP:PROD or after AfDs closed as WP:SOFTDELETE. Something like Wikipedia:Articles for deletion/New England Independence Campaign definitely won't qualify. Nsk92 (talk) 22:40, 3 April 2021 (UTC)

I have an idea

My idea is that when you hover you're cursor over an image, You should be able to see a larger version of the image. A lot of the time, It takes awhile to load an image when you click on it. If this would be added, It would be a switchable setting. Starman2377 (talk) 13:02, 25 March 2021 (UTC)

I like it. I already have Wikipedia:Tools/Navigation popups turned on. It's quite pleasant, and this feature would also make pictures more useful. Jim.henderson (talk) 11:43, 28 March 2021 (UTC)
There's a browser extension for Chrome and Firefox called ImagePreviewer that does this. Fences&Windows 23:46, 3 April 2021 (UTC)

Watchlist/Notifications for specific sections

Tracked in Phabricator
Task T2738

Please let me know if this is already a feature, but I think it would be incredibly helpful if a user could add a specific section of a talk page or other discussion-based page (like this one) to their watchlist. This would make it so they don't see notifications pertaining to different sections that they may not care much about. Ajshul 😃 02:12, 6 April 2021 (UTC)

@Ajshul, please see Wikipedia:Talk pages project. WhatamIdoing (talk) 05:12, 6 April 2021 (UTC)
This is a long-term wish list item, see phab:T2738 for more on it. — xaosflux Talk 14:29, 6 April 2021 (UTC)
@Ajshul: This is being worked on as part of DiscussionTools, see phab:T263820. In the interim, User:Enterprisey/section-watchlist provides the same functionality as a user script. – SD0001 (talk) 16:29, 6 April 2021 (UTC)
@SD001 and @Xaosflux – my apologies. I was not aware of these projects.

Identifying extra line breaks

One of the most common errors I see in stubs and similar pages is erroneous instances of double line breaks. Surely there's some way to automatically identify this and flag pages that might have the error for review? {{u|Sdkb}} talk 03:53, 10 April 2021 (UTC)

I think there's already a bot that does it. It might also be a built-in WP:AWB task. Ivanvector's squirrel (trees/nuts) 14:03, 10 April 2021 (UTC)

Audio Summaries

It would be very helpful for many people who are illiterate (~14% of the world), blind, or can't understand the content of Wikipedia pages (simple English Wikipedia is, unfortunately, not heavily updated and contains few articles compared to Wikipedia) if there were short (~1-5 minute) audio summaries of pages at the top that can be listened to. The audio summaries would be created by any confirmed users and then "Audio Summary Reviewers" (new permission) would approve the summaries. I know there are audio recordings of some pages, but this is just a reading of the page as opposed to a summary; a summary would serve a separate, and arguably, more broad purpose. Thoughts? Ajshul 😃 02:01, 6 April 2021 (UTC)

What do you expect people to get from a short audio summary that they can't get from using text-to-speech tools on the first few paragraphs of an article? WhatamIdoing (talk) 05:12, 6 April 2021 (UTC)
Illiterate people are mostly in countries that dont have great access to the internet. Which you need to access Wikipedia. The priority wouldn't be high, but this could work if enough people would volunteer. Just... dont expect it to happen anytime soon. Arsonxists (talk) 14:05, 6 April 2021 (UTC)
I also think that for larger articles (for which I foresee this being the most useful), a 1-5 minute audio summary would be extremely helpful for those who can read but just want to gain some knowledge without having to pick through a large article. It can also be great for people who just want to learn something new for fun quickly while doing another task (similar to a short podcast). I also think that for some very long articles about very complex topics (mathematics, sciences, philosophical theories, etc.) if an audio recording with a summary can be provided, it would help a lot of people gain a deeper understanding. By no means do I think that if implemented, audio recordings will appear overnight on all articles, but by developing a framework for this to be possible, I think it would be incredibly helpful; further, with certain permissions needed for posting and reviewers needed to approve, I foresee few problems arising from this: only upsides. Ajshul 😃 17:04, 6 April 2021 (UTC)
That is, mostly better reasoning. Audio transcripts do exist already (solved the illiteracy problem), so I think a text based summary would work better. Also, I don't think that the permissions would be nessecary for a text based summary system and way too infuriating, as audio is way harder to make new versions of then text. Arsonxists (talk) 18:32, 6 April 2021 (UTC)
I think a text based summary would work better that is what the MOS:LEAD is supposed to be... Elli (talk | contribs) 22:44, 7 April 2021 (UTC)
Agreed, which is why I think audio would be best. An audio summary would allow people to learn about the subject without having to devote their entire attention to reading. As for the revisions, the audio would only cover a broad summary and not any extremely new or controversial information; similar to what is currently being done with Spoken Wikipedia. Ajshul 😃 22:41, 8 April 2021 (UTC)
Perhaps you can work with some people at Wikipedia:WikiProject Spoken Wikipedia on this idea. isaacl (talk) 19:27, 6 April 2021 (UTC)
I don't see why a new permission would be necessary here. Elli (talk | contribs) 09:56, 7 April 2021 (UTC)
This isn't even a problem (we have something called a "lead" that summarizes the content of the article, and readers can use TTS tools if they need help reading the lead. (Illiterate or blind people most likely aren't reading WP) Lettlerhello • contribs 14:48, 10 April 2021 (UTC)
Lettler, blind people most likely aren't reading WP Blind people read and edit Wikipedia. They even have their own usergroup: http://meta.wikimedia.org/wiki/WikiBlind_User_Group Vexations (talk) 16:02, 10 April 2021 (UTC)
I did not say that there were no blind people reading or editing WP. Either way, they are a minority of our readers and editors, so they most likely should just use an external TTS tool if they need help reading articles. Lettlerhello • contribs 01:29, 11 April 2021 (UTC)

Obtaining BLP photographs from their subjects

Wikipedia articles about living people tend to have portrait pictures in the infobox that are rather low-quality compared to what one would expect on the internet in 2021, or in many cases no picture at all. I suppose this is due to the difficulty of finding a freely-licensed image given that Wikipedia lacks professional photographers. (The exception is government officials, who tend to have official portraits.) I wonder if any thought has been given to creating a streamlined way for subjects of BLP articles, or their representatives, to contribute a freely-licensed image to Wikipedia for use on their article, and then advertising this in some way. While some subjects are doubtless too busy to entertain such a request, given the ubiquity of Wikipedia in today's world I would be surprised if no BLP subjects were willing to contribute an improved picture for use on their article. CapitalSasha ~ talk 22:55, 7 April 2021 (UTC)

@CapitalSasha: there is Wikipedia:A picture of you. I agree that the process should be improved. Elli (talk | contribs) 23:16, 7 April 2021 (UTC)
Thanks, I wasn't aware of that page! I wonder if a dedicated email address could be set up, connected to OTRS somehow, so that all was required was to send an image attached to an email. That would be a lower barrier to entry. CapitalSasha ~ talk 00:41, 8 April 2021 (UTC)
@CapitalSasha: that sounds like quite a good idea. Elli (talk | contribs) 01:23, 8 April 2021 (UTC)
@CapitalSasha and Elli: There actually is a dedicated email address set up and connected to OTRS: photosubmission@wikimedia.org. See Wikipedia:Contact us/Article subjects for the details. Given that it was so hard for people to find this, it's probably not being used to its full potential, but it is there. Vahurzpu (talk) 01:04, 12 April 2021 (UTC)
@Vahurzpu: thanks - I've added this to Wikipedia:A picture of you (see the section "By email"). Elli (talk | contribs) 01:20, 12 April 2021 (UTC)
I didn't know until now that the page Wikipedia:A picture of you exists but it surprises me that the page doesn't mention the simplest way someone can provide a free picture of themselves. Many people maintain personal webpages and have photos of themselves posted there. They almost always own copyrights to those photos. All they need to do is post a note at their webpage saying that the copyright for a particular photo is being released under a suitable free license (like CC-by-sa 4.0), with the necessary basic info (where and when the photo was taken). Then any other Wikipedia editor can upload the photo to Commons or to Wikipedia directly. I think that's easier than asking BLP subjects to upload their photos to Commons or to e-mail something somewhere. Nsk92 (talk) 01:40, 12 April 2021 (UTC)
@Nsk92: feel free to update said page. It could certainly use some help. Elli (talk | contribs) 02:03, 12 April 2021 (UTC)

Image use proposal

I'd like to deprecate the use of nude or sexually explicit photographs uploaded by anonymous single-purpose accounts. (This would include both Wikimedia accounts and accounts on other image hosting websites such as Flickr.) I'd appreciate any thoughts or advice on formulating an RfC. Cheers, gnu57 15:06, 5 April 2021 (UTC)

@Genericusername57: do you have any statistics as to the prevalence of this condition? Keep in mind that it should only be about local uploads here on the English Wikipedia as any uploads to Commons are outside the scope of enwiki RfC's. — xaosflux Talk 15:26, 5 April 2021 (UTC)
...and I don't see how we can police an unrelated site like Flickr. I know that this is the village pump for discussing vague ideas, but I still think that you should think about this a bit more before starting a discussion. I'm pretty sure that our policies and guidelines already prevent Wikipedia editors from including gratuitous nudity or sexually explicit content, but there are some articles where such content should be expected. Phil Bridger (talk) 17:44, 5 April 2021 (UTC)
@Xaosflux: Commons has no rule against hosting mugshots, but the English Wikipedia places limits on their use in biographies of living persons (WP:MUG). I am proposing something similar: not that we somehow prevent Commons from hosting these photos, but rather that we stop using them to illustrate English Wikipedia articles. As far as statistics go, I'm not sure. Using Petscan to intersect the Commons categories "Human genitalia" and "Self-published work", then subtracting out various art and diagram categories and the "User categories" tree (most photographers with dedicated categories are non-anonymous) yields several thousand files, several hundred of which are in use on the English Wikipedia. Someone better at SQL than I am could probably use Quarry to figure out what percentage of the files in Commons category trees like "Nudity" and "Sex in humans" were uploaded by accounts with fewer than, say, 50 global edits.
@Phil Bridger: The problem is that we have no way of verifying that the subjects consented to their photos being published on the internet. Commons and Flickr both let anyone with an anonymous throwaway account upload sexually explicit content. For illustrating English Wikipedia articles about human anatomy, medical conditions, social and artistic nudity, etc, there are plenty of high-quality, freely licensed images from reputable photographers and institutions. There's really no need to keep using sketchy amateur snapshots from anonymous randos. gnu57 14:26, 6 April 2021 (UTC)
Disagree with doing this on enwiki - the proper place to make this decision is Commons (there, I do generally support deleting non-education nudity uploaded by new users). Elli (talk | contribs) 09:57, 7 April 2021 (UTC)
  • This is pretty well covered by WP:GRATUITOUS. If you're proposing that we somehow filter uploads before they appear, I'm not sure we can do that. Ivanvector's squirrel (trees/nuts) 14:00, 10 April 2021 (UTC)
    • @Ivanvector: WP:GRATUITOUS addresses the content of images, not their provenance. It would be counterproductive to point out specific examples here (hey everyone, take a look at this potential privacy violation), but I can think of several images currently in use that aren't all that gratuitous in context (surely someone reading about human anatomy can expect to see images of the human body), but still might embarrass or distress the subject if they were posted on the internet without the subject's permission. Cheers, gnu57 16:13, 12 April 2021 (UTC)

This has been a minor annoyance to me, so I'm wondering if there's any opposition to this. Special:WantedPages is pretty much useless because talkpage banners, for example {{WikiProject Northern Ireland}}, link to articles such as Shauna Gunn (which is, for the record, salted). Not only does this make WhatLinksHere of those pages useless, it makes WantedPages useless, as it mainly tracks what happens to be linked in WikiProject banners.

Additionally, this slows down loading (though small, it can add up) of any pages tagged with the banner, since it pulls in information that hardly anyone on that talkpage cares about.

Therefore, I would suggest that WikiProject banners are not allowed to include lists of tasks in them, and must instead only link to such lists. Elli (talk | contribs) 20:57, 11 April 2021 (UTC)

@Elli: I suggested that at Wikipedia talk:WikiProject Council/Archive 21#Proposal: Disallow transcluded to-do lists in 2015. There was support but also a suggestion of wider notification about the discussion. That wasn't done and the discussion died without action. I don't want to spend time on this now but others are welcome to use content from my post if they revive the issue. PrimeHunter (talk) 22:21, 11 April 2021 (UTC)
@PrimeHunter: seems like it gained support so... would an RfC be necessary, or simply asking the relevant WikiProjects? Elli (talk | contribs) 22:23, 11 April 2021 (UTC)
@Elli: An RfC may be best. It affects many other users than the WikiProjects which use the system. PrimeHunter (talk) 22:36, 11 April 2021 (UTC)
@PrimeHunter: ugh, that means I have to do writing :( I'll probably start one later this week, then Elli (talk | contribs) 22:38, 11 April 2021 (UTC)
  • I agree that WikiProject banners shouldn't be linking to to-do lists. It's not because of Elli's rationale, though, but rather that it's just not appropriate to be advertising tasks you'd like for your project to get done at talk pages that have no connection to those tasks. "Spam" would be the most blunt way to put it. It's part of the larger problem of talk page banner bloat. Regarding Elli's rationale, Special:WantedPages exists to serve the encyclopedia, not the other way around, so I don't buy that we should ban the lists to get it functioning better. Rather, I would suggest technical solutions, such as making Special:WantedPages only go by mainspace transclusions, or identify when a page is only showing up because it's part of a widely-transcluded template. {{u|Sdkb}} talk 22:41, 12 April 2021 (UTC)
  • I agree with Sdkb on the argument that these lists should be removed on the grounds of banner bloat. I doubt the utility attained in recruiting editors justifies inserting non-relevant information on every talk page in a project's scope (it's precious space). These todo lists should be kept strictly in the realm of WikiProjects and their subpages. — Goszei (talk) 18:20, 13 April 2021 (UTC)

Category

Hi!, I wanted to ask something interesting, at least to me. I hope to be in the right place. I am enthusiast about both World Wars and the people who served in both (I don't say men just out of respect for Florence Green) xD. I wanted to know if it would be a good idea to create a category of the few flying aces during both World Wars, mostly German flying aces who later became Luftwaffe members. Wouldn't it be a suitable category or it's too specified? Thanks all. CoryGlee (talk) 22:46, 13 April 2021 (UTC)

Hello CoryGlee. I will let others comment on whether a category is feasible but I think the info might be better in a list article. For me categories can get lost in the shuffle especially if the person's article has ten or more cats. In a list article things like what company of each air force can be included. Other editors will have more and different input for you to consider. Regards. MarnetteD|Talk 23:29, 13 April 2021 (UTC)
Perfect friend! Thank you! CoryGlee (talk) 23:50, 13 April 2021 (UTC)

New user 'problem'

This might be in the wrong place; feel free to move the discussion: Recently I've been seeing many new users get bitten by more experienced users, such as in this diff. In it, User:David notMD thought the user's edit was vandalismunconstructive, so they reverted, and now the new user is saying 'And this is now my really last edit in any article' about a word choice. Wikipedia is supposed to be an open place, but all too often at talk pages, RfCs, AfDs, etc. there is just a lot of harshness, if not intentional, that drives away even experienced users. Is there a way to make the Wiki more open?

Ideas:

1. Whenever someone signs up, guide them through a mandatory tutorial. This is hitting two birds with one stone: Vandals will be discouraged from creating socks, and new editors won't try something like editing a featured article too soon.

2. Make Wikipedia's policies and guidelines more accessible to new users. For example, upon creating an account, new users would be directed to a page which summarizes policies and isn't too long, so that they understand what to do and what not to do.

I'm sure doing this will help problems with vandals and subtle vandalism. Anyone have any other ideas about this? Sungodtemple a tcg fan!!1!11!! (talk) 00:39, 11 April 2021 (UTC)

  • I don't think anyone has a suggestion for a good "mandatory tutorial" or a short summary of all important policies. Requiring a "mandatory tutorial" certainly won't "make the Wiki more open". Many contributions from new users are not constructive and have to be reverted, no desire to be nice will change that. And your example is not as you describe; nobody said the initial edit was vandalism, and the editor who made it has been here over a year with over 500 edits. User:力 (power~enwiki, π, ν) 01:14, 11 April 2021 (UTC)
  • FYI - The editor was accusing me of vandalism for having reverted additions to "See also" at more than one article. I engaged the editor in discussions at the Talk pages of the articles in question and at Teahouse. Furthermore, V is not a new editor, having been actively editing since April 2019. David notMD (talk) 01:23, 11 April 2021 (UTC)
  • This doesn't look like any sort of problem at all. The new editor was told that there was a disagreement about their edit and that the article talk page was the place to discuss it. If the user then calls the disagreement vandalism and refuses to take advice about the appropriate place for discussion then that user is unsuited to be editing Wikipedia, which involves civil disagreement and discussion. It is better to be told that sooner rather than later. Phil Bridger (talk) 19:35, 11 April 2021 (UTC)
  • @Sungodtemple: There is the WP:HI for this purpose. In defense of David notMD I can say for sure that he didn't fail to WP:COMMUNICATE completely, he explained himself briefly here. On the other side his this contribution wasn't that friendly. Summarily I don't think the idea is worth pursuing it so I propose to close this discussion. (I also made a suggestion here in order to calm down everyone).--AXONOV (talk) ⚑ 15:37, 15 April 2021 (UTC)
  • I have a few ideas. Firstly, a "tutorial" already exists, or something similar to one. When new users create an account, an interface pops up recommending articles to edit, however, albeit with no mention of policy. WP:TFA is a good, currently maintained, detailed and easy-to-use longer "introduction". Also, there are already simplified versions of many WP policies, including WP:SMOS, HELP:PG, WP:SR, WP:8, WP:10SR, WP:SRI, etc.

Potential implementations relating to above:

  • Make the simplified rulesets more accessible and publicized, e.g. linking on Main Page.
  • Link to TFA in the already existing "introduction".
  • Add a short summary of policy to the already existing "introduction".

Including ethnic or religious heritage

When did Wikipedia become the enforcer of the Nuremberg Laws? I notice that people are constantly inserting information to identify subjects as being of Jewish descent, irrespective of whether that is relevant to the person's occupation (say, as a Rabbi or activist on behalf of Jewish causes.) Far, far less frequently is anyone else's religion mentioned. Protestants are never identified as Protestants, unless they are official members of a Protestant Church. Catholics are rarely identified as Catholics. But Jews are almost always identified as Jews.

I would recommend a policy of not including someone's ethnic or religious heritage unless that is directly related to their profession. — Preceding unsigned comment added by Wixifixer (talk • contribs) 20:30, 30 March 2021 (UTC)

@Wixifixer: I think this has to do with reliable sources noting these things more prominently in the case of those who are Jewish. In the western world, anyway, you'd see a similar thing for those who are Muslims, or those who are gay, or any other minority - it's not the default, so it's more worthy of note. Elli (talk | contribs) 01:57, 31 March 2021 (UTC)
@Wixifixer: You hint at a significant reason yourself: Jews are both considered an ethnic and religious group, an ethnoreligious group. Wikipedia:Manual of Style/Biography#Context says: "Ethnicity, religion, or sexuality should generally not be in the lead unless it is relevant to the subject's notability." If reliable sources often mention it then we usually don't omit it from the whole article. PrimeHunter (talk) 12:37, 31 March 2021 (UTC)
Maybe I'm reading too much into your comment, but since the discussion is about Jewish descent, it seems like you're implying people talk about having a homosexual ancestor as part of their identity.118.208.187.206 (talk) 06:21, 16 April 2021 (UTC)
I think you would find a very high proportion of the editors adding such information are themselves Jewish, so your implication is wrong. Johnbod (talk) 13:32, 31 March 2021 (UTC)


I don't know. In an earlier period, all those things would also have been true of Catholics--from the majority Protestant point of view. Catholics were not just regarded as a different religious group; most Protestants regarded them as at least an ethnic "other," if not a racial "other." In that world, too, "reliable sources" would have mentioned that one of their subjects was Italian/Irish/Catholic, because that fact would be "worthy of note." Now, tastes have changed. Catholics don't need to be noted as Catholics anymore. I haven't done the research to figure out why that changed. Maybe you guys know. But it's still the same phenomenon. And I just think it's time for us to be more sensitive to it. If many other Jews don't agree with me, that's fine. I think they're wrong. — Preceding unsigned comment added by Wixifixer (talk • contribs) 21:24, 31 March 2021 (UTC)

Getting a Wikipedia biography is usually a sign you are successful. I doubt Jews in general want it hidden that article subjects are Jews if they don't hide it themselves. PrimeHunter (talk) 21:52, 1 April 2021 (UTC)

well, by that logic, we would have to assume that Jews are the only ones who don't want their religious/ethnic identity hidden, while Episcopalians and Presbyterians DO want it hidden? Honestly, what are you talking about? 47.35.240.141 (talk) 16:34, 4 April 2021 (UTC)

What are YOU talking about? I have never in any way indicated that Episcopalians and Presbyterians want it hidden. The discussion is about Jews because that's what Wixifixer posted about. The reason we are more likely to mention whether somebody is Jewish is that it's also an ethnicity, and the reliable sources we use are more likely to mention it. PrimeHunter (talk) 19:43, 4 April 2021 (UTC)
This question has come up fairly often, so we might need to write an essay somewhere. What seems to throw people off is the combination of ethnicity and religion. If you feel like "Jewish" is primarily a religion, then it seems weird to say "He's Jewish" but not "She's Presbyterian". The difference, of course, is that the ethnic background of many Presbyterians is spelled "Scottish", not "Presbyterian". WhatamIdoing (talk) 01:47, 8 April 2021 (UTC)

Deserted WikiProjects around drinks – or anything? Merge, let be, or something else?

I have noticed that there are several WikiProjects and at least one task force revolving around some sort of beverage, WikiProject Spirits, WikiProject Wine and WikiProject Food and drink with task force Beverages that I know of, all of them inactive. It's a real pity as it looks like a lot of effort has been put into them. Perhaps they could be merged in some way. What happened to them? Is it this perhaps a general trend that WikiProjects fade away? How should Wikipedia handle that? --Mango från yttre rymden (talk) 23:59, 31 March 2021 (UTC)

@Mango från yttre rymden: some projects manage to provide context that helps editing – such as guidelines, coordinated reviews and a forum for discussion – and it's those projects that thrive. We've had even big projects fail, such as Wikipedia:WikiProject Culture, but it doesn't necessarily mean that editors will not be able to edit those topics effectively. If a project goes inactive, it's a good idea to link to a related project (see the Culture example). I suppose it would also be possible to revive Wikipedia:WikiProject Food and drink since it has a broad scope and thus many potentially interested editors. By the way, there is also a project on my favorite drink that is active: Wikipedia:WikiProject Beer. – Finnusertop (talk ⋅ contribs) 18:16, 1 April 2021 (UTC)
@Finnusertop: I wasn't implying that WikiProjects are indispensable. I'm just airing thoughts. I'm thinking that all those WikiProjects that revolve around the same wider subject, like food and drink, could be merged into WP Food and drink, that way is it more likely the projects(s) revive and the subject(s) get some more attention. The result could be worth more than the sum of it's parts, as more people are likely to join and engage if there are a few people in the same group, even though each person focus on different things, than if the same amount of people would be separated into one project each. Wine, beer and spirits could be task forces within WP Food and drink.
I have looked around a little, and I get the impression that WikiProjects sprung up like mushrooms at the early 2010s, presumably shortly after the concepts inception, but now have lost peoples interest and half of them are deserted. --Mango från yttre rymden (talk) 19:37, 4 April 2021 (UTC)
A Wikipedia:WikiProject is a group of people. Some groups form for time-limited tasks; others form indefinitely, but then sort of drift apart. That's okay. You are welcome to WP:REVIVE any WikiProject. You do that primarily by banding together with interested wiki-friends. Pages such as Wikipedia:WikiProject Directory/Description/WikiProject Food and drink will help you find interested editors.
Sometimes, two groups will voluntarily merge. This can be helpful, but it is never forced. WhatamIdoing (talk) 01:51, 8 April 2021 (UTC)
There are some Wikiprojects such as MilHist that are always active, but I think most will have flurries of activity in between longer periods of dormancy. But they still serve a role and are the relevant place for reports and source discussion re their subject area. ϢereSpielChequers 12:58, 16 April 2021 (UTC)

Rewording the Watchlist interface

Currently, when editors finish an edit and scroll down to the button strip, the dropdown next to "Watch this page" reads: "Permanent". I believe that this isn't an ideal wording, as it implies that you cannot remove an article in your watchlist. Instead, I think that it should be reworded to either Until I remove or Until I delete. Any thoughts on this? EpicPupper 21:03, 17 April 2021 (UTC)

The other options 1 week, 1 month, 3 months, 6 months can also be removed or changed earlier by the user. I think it's best to just continue briefly stating what happens without further action. Most users probably know or can guess that pages can be unwatched. "Until I remove/delete" can give the impression that the user is expected to remove it at some time. I guess most of the watched pages will never be removed. PrimeHunter (talk) 00:41, 18 April 2021 (UTC)

Comma bot

I don't really know how bots work, but there is a grammar mistake (not too extreme) I see consistently. It's in a list of words, such as "One, two, three and four". It is supposed to be "One, two, three, and four". Again, I don't know how bots work/how to create one. Does anyone think this is a good idea? TheFirstVicar4 (talk) 15:21, 28 March 2021 (UTC)

Both forms are allowed by Wikipedia:Manual of Style#Serial commas. PrimeHunter (talk) 15:25, 28 March 2021 (UTC)
See also WP:CONTEXTBOT. This is not a task bots can do. —  HELLKNOWZ   ▎TALK 16:27, 28 March 2021 (UTC)
No!! Adding Oxford commas to existing articles would be a fine way to start a war — GhostInTheMachine talk to me 17:00, 28 March 2021 (UTC)
Alas, for the sake of peace, TheFirstVicar4, Wikipedia has to allow people to eat Grandma. Nosebagbear (talk) 10:29, 29 March 2021 (UTC)
I see where you're going, but it's too much work for too little overall benefit. As Hellknowz partially pointed out, even though it's just a comma you're working with, the way it's used can affect the clarity of the article, and this largely depends on the type of sentence it's being used in. Getting a bot to understand this will probably require a lot of volunteers' time, and in the end, there will almost always be false positives/negatives. As a general rule of thumb, I prefer most grammatical ambiguities to be picked up and corrected by human editors (and I also believe that's the status quo) - Lankyliver (talk) 00:55, 18 April 2021 (UTC)

Trigger warnings

WP:SNOW close. – Finnusertop (talk ⋅ contribs) 06:11, 18 April 2021 (UTC) (non-admin closure)

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Trigger warnings should be added at the beginnings of articles or at least somewhere on the page. Avoids people accidentally stumbling across triggering content. Perhaps in the form of one of those template notice thingies that go at the top of the page? -LocalPunk (talk) 11:14, 25 January 2021 (UTC)

It would be nigh-impossible for Wikipedians, who may not share each others' societal or cultural norms, to agree on a comprehensive standard for what constitutes "triggering content". If the principle of least astonishment is properly followed, readers should generally come across offensive material only when it is expected (e.g. readers should anticipate articles on anatomy will contain images of sexual organs) and enhances their understanding of the topic, which would negate the need for warnings. There is also a general content disclaimer which explicitly warns readers that Wikipedia hosts objectionable content. (See also WP:NOTCENSORED). – Teratix ₵ 14:01, 25 January 2021 (UTC)
True. Perhaps a card with a link to the content disclaimer could be an idea? -LocalPunk (talk) 15:40, 25 January 2021 (UTC)
The problem is still which articles should have it, which is a highly subjective choice. —  HELLKNOWZ   ▎TALK 16:24, 25 January 2021 (UTC)
There'd probably have to be some sort of free-to-update list or something. -LocalPunk (talk) 19:19, 25 January 2021 (UTC)
@LocalPunk, I think you will want to read Trauma trigger. There might be some practical value in having a NSFW warning, but there is probably no benefit to a trigger warning. WhatamIdoing (talk) 02:35, 26 January 2021 (UTC)
I strongly disagree with the first paragraph of "In higher education". LocalPunk (talk) 11:35, 26 January 2021 (UTC)
It might be useful to differentiate between trauma trigger and thing that makes some people uncomfortable. For example, if you saw a person stabbed to death, then you might (or might not) develop long-term PTSD as a result. Your trauma trigger, however, is statistically unlikely to be "seeing people stabbed" or "reading about people being murdered". It's likely to be something like the metallic smell of blood, or the odd motion of the murderer's head, or the food that you had eaten just beforehand. Reading about crimes or watching a violent movie might be uncomfortable (or not; some traumatized people seek out horror films[6]), but it is unlikely to be an actual, bona fide trauma trigger.
There has been talk in the past about certain kinds of content filters. Nobody should have to look at a photo of someone gouging out another person's eye or dead bodies just because Special:Random will sometimes take you to pages related to mixed martial arts or war crimes. But actual trauma triggers, rather than things that make people feel uncomfortable, are probably few and far between on wiki, and warnings for true trauma triggers are probably neither possible (how is anyone supposed to know what your personal trigger is?) nor necessarily helpful. WhatamIdoing (talk) 03:35, 30 January 2021 (UTC)

The University is not engaged in making ideas safe for students. It is engaged in making students safe for ideas. Thus it permits the freest expression of views before students, trusting to their good sense in passing judgment on these views.

What if it's like one of the banners Wikimedia puts up on articles that need to be reviewed. Just a pale yellow warning "Common Trigger Warning" and editors and decide how specific that needs to be. — Preceding unsigned comment added by Totalart44 (talk • contribs) 06:05, 23 February 2021 (UTC)
  • I agree that there should be trigger warnings on things that everyone can agree on is triggering, like the holocaust or KKK. Starman2377 (talk) 16:25, 25 February 2021 (UTC)
    The problem is that we can't actually agree that those subjects are triggering. We can agree that they are uncomfortable. We can agree that they involve evil things. We can agree that one might wish to be careful about how one describes those to children. That is not actually the same thing as those subjects being coupled to any individual's PTSD-producing experience.
    Trauma trigger is "the Vietnam vet flinches when he hears a helicopter fly by". Trauma trigger is "mother collapses every time she hears her dead child's favorite Christmas song". A trauma trigger is not "reading about evil makes me uncomfortable". You're actually supposed to feel uncomfortable when you read about the Holocaust and the violent racist groups. Feeling uncomfortable when you encounter the evils of racism and genocide means you still have a functional conscience. WhatamIdoing (talk) 23:37, 2 March 2021 (UTC) You're right. Starman2377 (talk) 14:46, 25 March 2021 (UTC)
  • I don't think this should be dismissed out of hand - such warnings would not impact article content and would go a long way to making the website more accessible to some. As for what topics should be "warned" for, we could decide on that the same way we do anything else - through editor consensus. A standardized banner template with slot-in content warnings seems feasible and reasonable. BlackholeWA (talk) 23:51, 1 March 2021 (UTC)
  • Seriously, how about if someone creates a browser extension that searches a page for key words and phrases, does some kind of image search automagic, etc., before presenting it. Then it would work on everything, not just Wikipedia. And we can get out of the nannying business. EEng 06:42, 2 March 2021 (UTC)
  • I agree with WhatamIdoing's statement above. But, supposing that we could agree on a "trigger warning" banner and come up with a list of subject areas that the community agreed should display the banner, here's what I would expect to happen:
  1. Most readers would not see it (banner blindness).
  2. Word would get around that some articles have trigger warnings.
  3. People would complain when an article that bothered them personally in some way didn't have the warning.
  4. There would be demands for warnings on unmarked articles for a myriad of reasons (many patently ridiculous on purpose in the hopes of being denied so they can broadcast their fauxrage and get their 15 minutes), which, if we failed to comply, would result in accusations of bias or complicity or indifference to their suffering that would spread rapidly across social media to then be picked up by mainstream media who seem to welcome twitter mobs creating clickbait "news" for them.
I'm not convinced the lack of trigger warnings on articles is a problem, nor am I convinced there's a problem that would be solved by banners. Schazjmd (talk) 16:35, 2 March 2021 (UTC)
  • Yes, i think we should make a banner for triggering content. I know not everyone thinks that something is triggering. But what we should do is have discussions on pages if they should have a trigger warning or not. Starman2377 (talk) 16:40, 2 March 2021 (UTC)
    So, what if someone is triggered by snakes. Or dogs. Or birds. Or spiders. Would we have to put trigger warnings on all of those pages too? Because some people are as frightened of those as other people are of violence. Where do we draw the line? We could easily end up with virtually every article having some sort of trigger warning. MeegsC (talk) 17:23, 2 March 2021 (UTC)
    Phobia object ≠ trauma trigger. NSFW warning ≠ trigger warning. WhatamIdoing (talk) 23:29, 2 March 2021 (UTC)
  • Incredible, and sad, that we are even discussing such a silly, infantilizing, idea. Of course, this is assuming text. Photos might be another issue. Rollo (talk) 21:51, 2 March 2021 (UTC)
  • Although a trigger warning is much more serious than a spoiler warning, I think Wikipedia's experience with spoiler warnings is instructive here. I don't think it's a good idea, and would be subject to similar problems. ~ ONUnicorn(Talk|Contribs)problem solving 23:41, 2 March 2021 (UTC)
  • Oppose for text. Wikipedia isn't in the business of censoring text on this type of basis. An effort independent of Wikipedia, probably a browser toolbar, may be what you want to support. power~enwiki (π, ν) 23:41, 2 March 2021 (UTC)
    Everyone keeps stealing my ideas -- see my earlier post. I feel triggered. EEng 23:44, 2 March 2021 (UTC)
  • Oppose, regretfully. I am a person who generally benefits from content warnings; I have strong post-traumatic reactions to certain subjects, and so I find it useful to be prepared I am going to experience certain subjects before I experience them - especially in video content/etc, where it's much easier to be surprised by content. I am opposed to this proposal for two reasons: I do not generally have these problems on Wikipedia because this is an encyclopaedia, and article subjects are narrowly scoped enough that the lead generally already contains the information to allow me to nope out if I need to. Secondly, I don't think we are capable as a community of delivering effective content warnings with anywhere near enough consistency and empathy across the project for them to be anything more than a weak gesture. I would support more stringent policy on describing the content audiovisual media embedded in articles, because that has caught me out before. -- a they/them | argue | contribs 07:13, 3 March 2021 (UTC)
  • Oppose I have no idea what would even constitute a trigger warning. I think the introduction of an article should be enough for each user to decide if they personally wish to read the article. If the introduction says, for example, "The Holocaust, also known as the Shoah, was the genocide of European Jews during World War II. Between 1941 and 1945, Nazi Germany and its collaborators systematically murdered some six million Jews across German-occupied Europe, around two-thirds of Europe's Jewish population.", you can decide based on that information if you wish to continue reading. I believe triggers would be highly subjective. I don't see a point in adding a banner to a bunch of articles. jort⁹³|talk 00:04, 8 March 2021 (UTC)
  • Oppose - this is an encyclopedia. It covers the world in all its variety: good, bad, beautiful, ugly.... --Khajidha (talk) 11:40, 17 March 2021 (UTC)
  • Doesn't No disclaimers in articles cover this? On a semi-related note, though, I wonder if there'd be any benefit to showing new readers the disclaimers Wikipedia does have which they have to take an action on – i.e. clicking "Okay, continue" or "Cancel" so that they're properly informed about what sorts of things exist on Wikipedia before they enter. Then again, if this were shown to anyone without a cookie set, or something, it could become an annoyance. Maybe a link to the disclaimers could be prominently shown on the main page? Another problem with this sort of thing is you then get a "don't stuff beans up your nose" violation – as in, if we warn readers about what sort of objectionable stuff exists on the site, they then might try to seek it out, if they're curious youngsters or something. Well, anyway, there's my inane rambling quota fulfilled for the day. DesertPipeline (talk) 13:32, 19 March 2021 (UTC)
  • Oppose For some reason, the proposer believes that the average WP reader has only a few brain cells and cannot make inferences based on the names of articles that they will see graphic content. We can't pander this site to everyone. Putting trigger warnings on articles would only be obstructive to the 99% of readers who would not be triggered by the content of said article. Lettlerhello • contribs 22:07, 3 April 2021 (UTC)
  • Oppose page-level content warnings, but support the concept in general. We ought to have a disclaimer to readers somewhere on the site that Wikipedia is not censored and so they may come across content or images they may find offensive or may be inappropriate to display in (for example) a workplace, but I agree that we could never decide on universal criteria for what is offensive. Ivanvector's squirrel (trees/nuts) 13:39, 10 April 2021 (UTC)
    Is something like Wikipedia:Content disclaimer what you have in mind? — Goszei (talk) 18:12, 13 April 2021 (UTC)
  • @LocalPunk: you may want to take a look at Wikipedia:Perennial_proposals#Content_warnings.
  • Oppose. Why does truth and information need disclaimers? Why should be help discourage people from seeking those things? Life can be harsh and if a person cannot handle certain topics, why are they even searching for that information? It extremely childish to protect people from the harsh realities of history and life. We learn about some things *because* they are horrible and we don't want them to be repeated. We learn about some things to educate ourselves about the topic. The proposed templates are coddling. Jason Quinn (talk) 02:10, 18 April 2021 (UTC)
  • Oppose if some of our readers need trigger warnings this is not the way to do it. People who are triggered by rape, spiders, clowns or whatever can use searches and our category system to drive their own trigger warning systems. As different people are triggered by different things, it isn't our role to create some sort of general trigger warning system - just stick to the rule of least surprise. ϢereSpielChequers 05:09, 18 April 2021 (UTC)
  • Oppose. I'll point out the obvious - readers and editors have to consciously select the page they wish to view. If they choose Facial (sexual act) instead of Facial, they've made the decision to open that article. The article title is almost always sufficient to allow the prospective reader to decide whether or not they want to view the article. People need to take a bit of responsibility themselves. Risker (talk) 05:56, 18 April 2021 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

My "not search engine" essay

In my attempt to contribute to RfDs, I have decided to write another essay intended to say that we are not a search engine. How does the Community think of this? I believe it would be a good addition to WP:NOT. The essay is at WP:NOTSEARCHENGINE, NotReallySoroka (talk) (formerly DePlume) 03:05, 21 April 2021 (UTC)

I don't think this essay is accurate – after all, Wikipedia does have a search engine. True, it's not a general-purpose search engine like Google or Bing, but it is a search engine nonetheless. Wikipedia's primary purpose may be to be an online encyclopedia, but to fulfil this purpose we need to provide readers with an effective way to find desired information. – Teratix ₵ 04:38, 21 April 2021 (UTC)

Filter for special:random or the random article button

I feel like there should be some way to filter what pages you can be taken to by either using Special:Random or clicking on the Random Article button. I usually try and use it to find a random page and see if it needs any editing but often it takes me to a page on a topic I know nothing about or a page with very little information on a subject I don't know anything about. So maybe creating some kind of way for users to filter what kind of articles either of those will take them to or something else. I'd like to hear what you guys think about this idea. Blaze The Wolf | Proud Furry and Wikipedia Editor (talk) 20:00, 29 March 2021 (UTC)

I'd also like it if there was a "random" for all namespaces, or at least the major ones. 🐔 Chicdat  Bawk to me! 20:05, 29 March 2021 (UTC)
There is. See Wikipedia:Random. PrimeHunter (talk) 20:48, 29 March 2021 (UTC)

Adminship rights debundling

I would like to work on a proposal to debundle all rights that normal users can apply for from the administrative toolkit. I know auto patroller is an example, but I'm not sure what other rights are included in the administrative toolkit that normal users can also apply for. To add a little additional detail, I would like to propose that all user rights aside from the 3 core administrator rights ( Delete pages , block users, and protect pages), are no longer automatically given to administrators, and administrators have to apply for those user rights at the regular forum. ( The point of this is to enable taking away certain rights from administrators without requiring a formal Desysop by Arbcom) The main technical question is whether the ability for an administrator to grant themselves the newly unbundled user rights could be disabled while keeping the ability for admins to grant those rights to other users. I assume that this would probably take a formal RFC, and I am seeking a coauthor to help draft an official RFC proposal. Jackattack1597 (talk) 01:27, 1 April 2021 (UTC)

Can you see any situations where this would have been useful - eg rather than desysop, are there cases where taking away autopatrol from an admin would have been useful? Mostly when arbcom desysop I see it for admins offending some people, rather than creating problematic articles, or using rollback wrongly. Graeme Bartlett (talk) 03:48, 1 April 2021 (UTC)
I can't imagine a situation where an admin is trustworthy enough to block people, delete articles, view deleted material, and protect and unprotect pages, but could not be trusted with rights like rollback or autopatrolled. If they cannot be trusted with those, they certainly should not have the admin tools either. Seraphimblade Talk to me 05:02, 1 April 2021 (UTC)
If there are enough administrators that feel personally that their article creations should be independently patrolled, they could add themselves to a black list for a bot to unpatrol the articles (if DannyS712 is kind enough to repurpose it). The issue then becomes new page patrollers have to patrol pages admins create, when the vast majority are okay. You’ll unbundle it and find admins handing it back to each other because they are sick of patrolling fine pages. Yes, there is an application but hard cases make bad law.
Maybe there’s admins who never use rollback and could shed that right so as not to need a script to hide it. –xenotalk 05:17, 1 April 2021 (UTC)
Thanks for the ping. @Jackattack1597: "The main technical question is whether the ability for an administrator to grant themselves the newly unbundled user rights could be disabled while keeping the ability for admins to grant those rights to other users." as a matter of fact, it should be fairly easy to do - I wrote the code to do it in December 2019, see gerrit, but it hasn't merged yet because there wasn't a need for it - if enwiki decided to request this feature, it would likely be approved. The relevant phab task is phab:T44072. @Xeno: If any admin wants their articles to be unpatrolled automatically, I'd be happy to file a BRFA, should be fairly easy to code (ridiculously easy since the bot already unpatrols new pages by global rollbackers, so the logic is all there). DannyS712 (talk) 05:26, 1 April 2021 (UTC)
@Xeno: I requested a way for someone to have a session with less than all their access years ago in phab:T153454 - it hasn't taken off. This is currently available in the API, but not the WEBUI. — xaosflux Talk 13:23, 1 April 2021 (UTC)
Hmm, looks like I may have had an off-phab on that, since I'm not the author of that one (I think I was the wishlist author for it maybe?) - but same thing. — xaosflux Talk 13:25, 1 April 2021 (UTC)
  • This is never going to happen as written. Special:ListGroupRights shows the 63 permissions that sysops have. Also the current permission system doesn't allow for direct assignment of a permission, only a group - so they would need a group for each permission and that would overkill - and there is no way we are going to put the community through a "Request for globalblock-whitelist access" process for example. The partial blocks system may grow to allowing someone to be blocked against arbitrary actions, phab:T242541 has some more information on that. — xaosflux Talk 11:01, 1 April 2021 (UTC)
    • OK, so I re-read this focusing on the "can apply for" part. Keep in mind that noone gets rights still, they get groups. Still see issues, for example "event coordinators" get "no rate limit" and "add +confirmed to users", but you are proposing removing these from sysops and making them also be event coordinators to get them back? Sysops get "import" , but so do "transwiki importers" and "importers", so sysops would also have to apply for those? Making admins also be a member of a dozen other groups is quite cumbersome, we have role-based access controls for good reason. — xaosflux Talk 17:48, 2 April 2021 (UTC)
  • I firmly believe that unbundling admin rights is necessary but I also think that it has to be done in stages, rather than all at once. I would do this in the form of introducing new userright groups, for which regular users can apply, rather than taking any userrights away from admins. A good place to start seems to be creating a "vandalfighter" userright. I think it should include the ability to issue short blocks (up to 72 hours) to IP and non-autoconfirmed users engaged in vandalism and severe disruption and the ability to semi-protect pages for short periods (say up to a week). In my observations, the noticeboards such as RPP, AIV and 3RR are now frequently backlogged and it often takes hours to get action from an admin on a report there. But, unlike the admins, vandals don't take a break for hours. To give a specific example, several days ago I observed severe BLP disruption by a dynamic IP on an article on my watchlist, 2019 World Figure Skating Championships. I reported it to RPP,[8] but for several hours the report sat without action even though the article was getting clobbered. In the meantime, other users filed reports at 3RR Wikipedia:Administrators' noticeboard/3RRArchive430#User:117.111.0.0/19 reported by User:Jasper Deng (Result: Block, Semi) and ANI Wikipedia:Administrators' noticeboard/IncidentArchive1062#Urgent edit warring rangeblock needed, but again, nothing was happening. Eventually more than seven (!) hours after my initial RPP report, an admin was pinged directly and protected the page [9] and set a range-block for the dynamic IP. Yesterday, after the block and the semi protection expired, the disruption resumed. We were lucky this time that the same admin was online and responded to a ping quickly, since otherwise it would have again been several hours of chaos. This situation was ridiculous and I am certain that it is not an isolated case. Since we don't have enough admins to respond quickly to AIV and RPP reports, we need to give regular users the ability to do something. Nsk92 (talk) 12:13, 1 April 2021 (UTC)
    • We've looked at "mini-block" and "mini-protect" rights on multiple occasions just in the last 2 years. I think a case can be made, but we've failed to garner firm backing - there are issues that arise with either route. Nosebagbear (talk) 17:15, 2 April 2021 (UTC)
    A proposal for a "vandalfighter" user right was brought up in 2015 and failed to gain consensus. See Wikipedia:Village_pump_(proposals)/Archive_120#Proposed_user_right:_Vandal_fighter. --Ahecht (TALK
    PAGE    ) 03:35, 12 April 2021 (UTC)
  • I'm lost as to why this makes any sense. Give admin the three most important tools requiring the most trust, but make them ask for a whole bunch of other user rights? And also everything Xaosflux has said. You mention deleting pages as a right they would keep, but would they keep the ability to view deleted pages and to delete only specific revisions? They would still be able to protect pages, but would they retain the ability to edit through protection? None of this seems to have been considered before this was proposed. It is my personal opinion that we already have too many user groups. WP:PERM already experiences backlogs, sometimes fairly substantial ones. This would make that problem worse, much worse actually in that assigning permissions is not one of the three "core" abilities identified in the proposal. So would we need another new forum for requesting that ability? There might be an unbundling proposal I would support, but this is for sure not it. Beeblebrox (talk) 20:04, 2 April 2021 (UTC)
Sorry, I really don't think my original proposal was clear enough at all. Really, what I am trying to propose is that any permission that can be requested at WP:PERM is no longer automatically given to administrators, but it wouldn't affect any other permissions. Instead, administrators would need to request them at WP:PERM. If we were concerned about a backlog, I could propose an RFC on doing this for a few permissions at a time instead of all at once, to avoid a logjam of most active administrators requesting every perm back at WP:PERM at once. Also, to me the point of this is so that if an admin minorly misuses WP:PERMpermissions, the permissions in question can be removed without requiring a Desysop. I'm glad I was pointed to idea lab, because I definitely need to iron this out some more. Jackattack1597 (talk) 23:20, 2 April 2021 (UTC)
  • As far as the question of would we need a technical control to allow +sysop to give this to anyone except for themselves - why? If we don't want them to do that, just make a policy and block them if they violate. Such a technical control wouldn't prevent me from giving some flag to my own alt-account for example after all. — xaosflux Talk 21:02, 2 April 2021 (UTC)
Good point, on second thought I'll take the technical control out of the proposal, and just include a prohibition on self or alt perm granting in the RFC.Jackattack1597 (talk) 23:20, 2 April 2021 (UTC)
  • Per Beeblebrox. based on what Xaosflux said. The user rights system on Wikipedia is already highly granular and confusing to many who don't necessarily work in governance areas or are not involved in them until their creation is tagged for deletion, or they become a target for sanctions for some infringement or another. It would be interesting to define what actually constitute the 'core' rights of adminship. Traditionally blocking, deleting, and protecting may be perceived as the most important but as many admins focus on specific areas of their choice, they might not be the tools that are most often used by all admins - someone with some time on their hands might wish to do some data mining, the results of which could/should have been in the preamble of such an RfC (and might cast a different light on the proposal). While it may be possible to come up with reasons why autopatrolled for admins might need to be reviewed, they are rare. More rights mean more opportunities for hat-collecting, hence the En Wikipedia has probably reached the point where suggestions for further ideas for unbundling only serve for academic discussion, and they possibly fall under WP:SLOP. Kudpung กุดผึ้ง (talk) 23:55, 2 April 2021 (UTC)
  • I don't think we should be concentrating on taking away any userrights from admins, despite the currently pending arbitration request. However, I do believe that we should be thinking about creating new userrights that would allow regular users to perform parts of admin functions in areas where there is particularly urgent need and the shortage of admins is already acutely felt. In my observations, one area where the shortage of active admins is already acutely felt is vandal fighting. As I noted above, AIV and RPP are often backlogged for hours and even screaming for help at ANI doesn't necessarily produce a sufficiently fast response. That's why I suggested above creating a "vandal fighter" userright with the ability to issue short term blocks to non-autoconfirmed editors and to semi-protect pages for up to a week. Another such area is CfD. As it turns out, the persistent backlog there is so bad, that admins have a de-facto practice of allowing non-admins to perform NAC "delete" closures of CfD discussions, disregarding WP:NACD. So creating some kind of a userright (if technically possible) allowing regular editors to perform some low-level deletion functions, such as deleting expired PRODS and maybe deleting categories in non-controversial cases, plus possibly something else, would be useful. Nsk92 (talk) 00:34, 3 April 2021 (UTC)
    I would probably oppose any effort to unbundle the three "core admin rights" (delete, block, protect) per the rationale I wrote at WP:COREADMIN. It's true that AIV, RFPP, and other areas have been backlogged lately, but I see this as more of a short-term problem that can be solved by promoting two or three additional administrators who are specifically interested in those areas. A new user group would likely have unintended consequences and would be an ill-advised long-term solution to a short-term problem. Mz7 (talk) 01:58, 3 April 2021 (UTC)
    You are completely wrong. The arguments in WP:COREADMIN are abstract, but the problems I am talking about are concrete and practical that need addressing and are getting worse. And they are not "short-term", far from it. I have observed backlogs at RPP and AfD for a while and they have been quite chronic for at least over a year. As I said, things at CfD have gotten so bad that they now allow NAC "delete" closures in violation of WP:NACD. I haven't paid as close attention to AIV but I would bet good money that if one checks the data for the last year, we'd find that serious backlogs are persistent. All of these problems are only going to get worse if unadressed (just look at what's happening at Commons). The supply of new admins has slowed almost to nothing. At the same time we are losing quite a few admins due to retirements, inactivity, desysops, etc. At the same time WP as a project is getting more and more complicated. The number of admin tasks increases and the level of technical expertise required to perform them increases as well. Our current model of adminship is simply unsustainable and we are already seeing signs of things coming apart at the seams. Nsk92 (talk) 13:31, 3 April 2021 (UTC)
    I'm actually unopposed to the narrow proposal of allowing non-admins to close CfDs as "delete" if that would actually reduce a chronic backlog. In the past, I have supported such a strategy for WP:RFD, see [10]. Doing this would not require a technical change to the admin toolset, and any such close would eventually have to be reviewed by an administrator anyway when they go to press the "delete" button.
    On the issue of WP:AIV, I am an active admin there, and in my experience, whenever that page is filled with a backlog, it is not because there are a ton of urgent requests waiting for attention, but rather because editors have overfilled it with marginal reports that should really be declined as "not vandalism, take it to ANI", "user incorrectly or insufficiently warned", or "no edits since last warning". From a psychological perspective, it's harder to decline a report than to action the report because it requires taking a confrontational stand, which is why it might take longer for someone to actually say something (nowadays we even have a bot that clears stale AIV reports automatically). I'm not as much of a regular at WP:RFPP, but when I worked there a few weeks ago when there was a chronic backlog, it was the same thing: I declined the wide majority of the backlogged reports rather than taking action on them.
    What this tells me is that the truly urgent issues at AIV and RFPP—e.g. vandals who spam dozens of changes per minute on a variety of articles—already get dealt with quickly in the wide majority of cases, and it's the less urgent, more marginal reports that are the ones that form a backlog, the ones that wouldn't really benefit from non-administrator intervention anyway. Mz7 (talk) 16:11, 3 April 2021 (UTC)
    I think that admins' rights should stay as they are, unless anyone proposed automatically assigning edit filter manager to administrators, which I support. No unbundling, no debundling, our current number of administrators is too fragile. 🐔 Chicdat  Bawk to me! 10:08, 3 April 2021 (UTC)
  • At the moment, I would probably look favorably upon a proposal that would unbundle only autopatrolled, but allowing any administrator to self-grant to themselves without restriction, similar to edit filter manager. This would allow administrators who are not as experienced as others in content creation to get WP:NPP feedback on their article creations if they wish to do so. Other rights like rollback and page mover probably don't need to be unbundled. Mz7 (talk) 01:58, 3 April 2021 (UTC)
    @Mz7: not sure this is really needed - if an admin can't create a page that would pass basic new page patrol - they really shouldn't be creating pages - but if they just want feedback don't they now have the option to "unreview" the page to throw it back in to the queue? — xaosflux Talk 15:38, 3 April 2021 (UTC)
    I suppose that's fair. I guess it goes back to that contentious question at WP:RFA, which is whether considerable experience in content creation is needed to be an administrator. Currently, the guideline for granting autopatrolled to non-admins is prior creation of 25 valid articles, not including redirects or disambiguation pages. I know I didn't have 25 articles created when I did RfA (although I did have two GAs, but I know some admins who were promoted with much less). Mz7 (talk) 16:11, 3 April 2021 (UTC)
    @Mz7: that is a good guideline, but the primary component of patrolled new pages is that they aren't a CSD - which admins are expected to be able to recognize (i.e. that it doesn't violate "Wikipedia's criteria for inclusion, copyright violations, biography of living persons violations, conflicts of interest, and advertising.") If we are electing admins that really can't tell if a page is a violation of these policies we have a much bigger problem; not to mention that admins are also patrollers/reviewers themselves. — xaosflux Talk 20:08, 3 April 2021 (UTC)
    @Nosebagbear mentioned this point at WP:VPP recently. The problem is, I don't think he's correct. When he accepts an article at Wikipedia:Articles for creation, he's making an informed judgement about whether it has at least an 80% chance of surviving Wikipedia:Articles for deletion. He'd like a second or third person to go through the same assessment process. However:
    • Editors' subject-matter expertise varies wildly, so a second opinion may be worth less (or worthless).
    • He says that he's aiming for an 80% chance of the article surviving AFD, but exactly 0% of the 90 AFC drafts he's accepted have been deleted at AFD. Only three out of the 90 have been deleted. Two of the 90 articles were moved back to the draft namespace by someone else and were deleted as abandoned drafts (one of those subjects was moved to the draft namespace for non-notability reasons) and the third was deleted at the author's request. All three of those are eligible for a WP:REFUND.
    So I'm doubtful that we'd be getting any value out of a second opinion. In fact, maybe what we really need is to tell AFC folks that if none of the articles they accept end up at AFD, then that's a sign that their standards are too high. At any rate, what I conclude from this review is that if Nosebagbear accepts a draft at AFC, there is no point in asking another editor try to find a reason to delete it. WhatamIdoing (talk) 05:06, 6 April 2021 (UTC)
    AFC is not new page patrol. AFC assesses notability and tends to be strict, while NPP lets more stuff through with clean-up tags (while catching obvious speedy deletions). Following this, anyone competent enough to be an admin should have their pages survive NPP. Elli (talk | contribs) 10:05, 7 April 2021 (UTC)
    @Elli, well, that's what I think, too, but Nosebagbear is an admin, has a much lower deletion rate for the articles he accepts at AFC than he say's he's hoping to achieve, and he still wants the NPP folks to double-check his work. It doesn't seem like a good use of NPP's time to have them re-check the articles that he's already approved. WhatamIdoing (talk) 01:26, 8 April 2021 (UTC)
    @WhatamIdoing: well tbh, for admin-created articles I'm likely to approve them if they aren't blatant vandalism or whatever, since I trust that an admin would have an understanding of the notability policy. So it's not that big of a problem, more just pointless. Elli (talk | contribs) 01:56, 8 April 2021 (UTC)
    I agree that it's pointless. WhatamIdoing (talk) 02:11, 8 April 2021 (UTC)
    And that's really why I think rights de-bundling is pointless. Anyone trusted with blocking or page deleting should be trusted with stuff like article creation and rollback. If they've screwed up enough to merit not having those rights, they should not be an admin. Elli (talk | contribs) 02:22, 8 April 2021 (UTC)
  • Please see Wikipedia:Unbundling administrators' powers for some history. -- RoySmith (talk) 16:10, 3 April 2021 (UTC)
    Hmm, I seem to be listed on that page several times : ) - jc37 00:29, 18 April 2021 (UTC)
  • Remember our problem is not enough candidates running for adminship. Each time we unbundle part of the toolkit we remove another route to adminship, and once people become admins they often go on into other useful areas of adminship. I'm not aware of a specific right that could be unbundled in the way that rollback, file move and template editor were. We are now left with things that go together - like you can't set autopatroller without looking at someone's deleted edits. ϢereSpielChequers 13:10, 4 April 2021 (UTC)
  • I would strongly support this proposal, if it were a proposal. It does not come up often of course, but there have been instances of an administrator abusing a minor userright in a way which would normally be addressed by simply removing that one privilege, but because the user is an administrator the remedy is desysopping, which at present can only be done through a lengthy Arbcom case. If we kept the admin toolset to the userrights that are exclusive to admins, along with granting the usual non-admin userrights at the time of a successful RFA, then this is a lightweight change (other than for 'crats, who I'm sure can handle ticking a few extra boxes a few times a year, or it could be done by script) which also improves our processes. Ivanvector's squirrel (trees/nuts) 13:51, 10 April 2021 (UTC)
  • I share WSC's concern over unbundling. I support Mz7's statement that we should make autopatrol like edit filter. There is no way for an admin to unreview their own page creation so there is no easy way, for instance, that an admin could accept a marginal article at AfC and have a second editor review it as part of NPP (and since when is 80% the standard for that?). For this reason alone I support making autopatrol a flippable switch for admins. Barkeep49 (talk) 22:49, 17 April 2021 (UTC)
    @Barkeep49: I've opened phab:T280890 - can't see any reason they should be forbidden from un-reviewing the page. — xaosflux Talk 23:19, 21 April 2021 (UTC)
  • Let me repeat what I said before: Instead of taking away userrights from admins, we should be creating new userrights, enabling performing certain low level admin tasks, and making them available for regular users. We still need "full admins", but as Wikipedia is getting more and more complex and the incoming supply of regular editors is stagnating, we are not going to get a dramatic influx of RfA candidates. We should accept that as a given, start treating "full admins" more as crats, and start involving regular users in performing more of actual admin tasks. Nsk92 (talk) 00:11, 22 April 2021 (UTC)
    We do have regular users performing actual admin tasks which is how we have template editor and page mover (not to mention rollbacker which used to be the main reason someone did RfA). Historically unbundling has only made RfA harder to pass and I think it's plenty hard already. Best, Barkeep49 (talk) 01:54, 22 April 2021 (UTC)

Reconfirmation of Adminship (ROA) proposal

I am considering an RFC to add the following text to a new section on WP:ADMIN:

Reconfirmation of adminship (ROA) discussions are a voluntary re-confirmation process regarding whether administrators have community consensus to remain an administrator. ROA discussions are to be transcluded at Wikipedia:Requests for Adminship using the template {{tls|Reconfirmation of Adminship template}}. Any administrator may initiate a ROA discussion on their own adminship at any time. Like requests for adminship, a reconfirmation discussion is open 7 days during which editors may ask two questions each, and the discussion is closed by a bureaucrat. Unlike requests for adminship, the threshold for retaining administrator tools is 60% of participants, not counting neutrals, and margins between 50% and 60% should be evaluated by bureaucrats to determine whether consensus exists for continued access to the administrative toolkit. Administrators who withdraw from an open ROA or do not receive sufficient support will lose administrative privileges.

(text based on this diff; I believe Wugapodes and myself were the only editors but check that page for attribution)

A draft template can be found at Wikipedia:Requests for comment/Change to sysop activity requirements/Reconfirmation of Adminship template.

The discussion at Wikipedia:Requests for adminship/Harrias 2 (and, from several years before, Wikipedia:Requests for adminship/HJ Mitchell 3) should demonstrate why this policy is proposed. User:力 (power~enwiki, π, ν) 00:02, 20 April 2021 (UTC)

Other comments on ROA

  • Regarding the forum, I expect to start the thread as an RFC at Wikipedia talk:Administrators, with a link from the "Village Pump (policy)" page. User:力 (power~enwiki, π, ν) 00:02, 20 April 2021 (UTC)
  • Regarding the acronym, I prefer "ROA", but "RoA" may be preferred by other editors. User:力 (power~enwiki, π, ν) 00:02, 20 April 2021 (UTC)
  • There is no actually definition of what an ROA is. For example, could any administrator initiate a ROA discussion at any time about another administrator? — xaosflux Talk 00:18, 20 April 2021 (UTC)
    • I thought it was obvious that an ROA would be about the admin starting the discussion, but you're right, it does need to be stated. I also forgot the link to the draft template, fixing now. User:力 (power~enwiki, π, ν) 00:20, 20 April 2021 (UTC)
  • Isn't needed. If a particular admin really wanted to go through RfA again, they can get themselves desysop'ed and just run again. We don't need a separate process for this (unless this would provide a way for the community to remove admins, which it doesn't). This proposal needs more information on why it would be better than a re-RfA.JackFromReedsburg (talk | contribs) 01:03, 20 April 2021 (UTC)
  • I see no particular reason to encourage re-RfAs of current admins. The process strikes me as pretty self-indulgent -- not so much I'd oppose on principle as several people at Harrias 2 did, but enough to be a bit disreputable a practice. If you're doing it to follow a recall criteria, I don't see a good reason to give it a special name to...separate yourself from the riff-raff? Frankly, I'm unconvinced this isn't "oh shit we've had an empty Current RfAs box for two months, let's pump up those numbers by encouraging re-RfAs". Vaticidalprophet 01:07, 20 April 2021 (UTC)
    • I also find Harrias 2 to be, not at all a discussion about the need for such a process, but a discussion about how much the community didn't want one. That Neutral column wasn't just a couple throwaways as in an average RfA -- it was a strong statement on behalf of about a third of the participants that they were so troubled by the idea of setting a precedent in favour of these that they refused to support someone they considered worthy of the mop. Vaticidalprophet 01:11, 20 April 2021 (UTC)
  • At the moment I am struggling to see why anyone would choose to do this. Help me understand? Stifle (talk) 09:52, 20 April 2021 (UTC)
    • An admin who wishes to check whether there remains community confidence in their continued adminship. It's also a step towards a desysop proposal. The outcome of such RfAs would evidence exactly how much validity there is to claims that RfAs of existing admins will be filled with editors with gripes and grievances and thus fail (which causes desysop proposals to fail by virtue of 'need to protect admins who take tough actions'). It would take some very selfless admins willing to do this, though, so at minimum there should be evidence that there's a handful of admins that would even contemplate going through this. ProcrastinatingReader (talk) 14:02, 20 April 2021 (UTC)
      • To the degree we need evidence, I'd offer two: one would be all the admins we have who have recall criteria and the other would be the 3-4 admins who volunteered to act as a trial on the rolling mandatory reconfirmations proposal that failed recently. Nosebagbear (talk) 14:04, 24 April 2021 (UTC)
    • I once done that on the Russian Wikipedia (and became the first admin there to go through the whole procedure) because a group of users became vocal criticizing me, and I was not sure whether I still have community support. I decided to stand reconfirmation and got over 90%, with 3 users opposing.--Ymblanter (talk) 18:58, 21 April 2021 (UTC)
  • This seems to add unnecessary complexity by creating something called an "ROA" with special guidelines. Simplify the proposal; just add a sentence saying (in more elegant words): Users with admin tools (or those eligible to regain admin tools at BN) may also open an RfA. Such an RfA will have adjusted thresholds for consensus <insert>. If this RfA fails, admin rights will be revoked. ProcrastinatingReader (talk) 14:06, 20 April 2021 (UTC)
  • This is fairly similar to @Thryduulf:'s proposal here and so I'd be inclined to support. I do think that it should note that candidates may not trigger one of these while there is an outstanding ARBCOM case request or case naming them as a party. I firmly support a clear demonstration that recall RfAs are permitted, and that failure to confirm consensus to be an admin is enforceable by removal of the userrights by the 'crats. Nosebagbear (talk) 20:35, 22 April 2021 (UTC)
  • Good idea. I would have supported a more ambitious proposal, but this one is a reasonable start. Apart from what PR wrote above, a reconfirmation RfA (even if overwhelmingly successful) would also let an admin get substantive systematic feedback about their admin work from the community as a whole. Sort of like a performance review. Nsk92 (talk) 22:24, 23 April 2021 (UTC)
  • Good idea, although I think it should be workshopped together with User:Nosebagbear/Draft RfC on Confirmation RfAs#Simpler proposal (i.e. combine the two proposals into one) to sort out the missing detail. Thryduulf (talk) 21:35, 24 April 2021 (UTC)

Pronouns in Infoboxes

I believe that it could be useful to include a person's pronouns in the "infobox"/"biography" section that appears on the side specifically for people.

While this is a per-page thing, having this become standard across pages that refer to a person would be extremely helpful in having it implemented site-wide. — Preceding unsigned comment added by Itscrossboy (talk • contribs) 09:16, 5 April 2021 (UTC)

I don't believe so. The "they/them" crowd's pronouns are announced in their articles. If Wikipedia was like this: "John Doe was born in 2000. In 2010, he got a job. In 2020, she founded a pizza shop. In 2021, they expanded their menu." then that would be useful. But since it isn't, it isn't. 🐔 Chicdat  Bawk to me! 10:09, 5 April 2021 (UTC)
Off topic
@Chicdat: slightly off-topic, but in Special:Preferences#mw-prefsection-personal you can specify a language gender, this will be visible to other users using tools like popups, and may lead to you seeing "he" "his" etc more often. — xaosflux Talk 11:19, 5 April 2021 (UTC)
I have. Most users don't use popups though. 🐔 Chicdat  Bawk to me! 11:20, 5 April 2021 (UTC)
@Chicdat: hmm - yours isn't showing for me; when it's not showing I do tend to refer to people with singular they to try to be as unoffensive as possible. — xaosflux Talk 11:23, 5 April 2021 (UTC)
FWIW, Chicdat you are showing 'male' now. — xaosflux Talk 12:58, 5 April 2021 (UTC)
  • Oppose - It is actually very rare for notable people to publicly state their preferred pronouns, and even rarer for sources to comment upon that preference. Thus, we often won’t know what to put in this parameter.
The problem is that many of our editors (especially newer editors) think that we must fill in every parameter in an infobox... and to do so the editor will either guess, or use the pronouns that the editor assumes the subject will prefer (or worse, an editor will add a pronoun that the editor prefers) - and that would violate WP:No original research. In cases where we do know a bio-subject’s preference, we can simply use it in the text of the article - as is appropriate. Blueboar (talk) 12:25, 5 April 2021 (UTC)
  • I don't think this is a good idea, we are not wikidata - so putting every possible attribute about a person in a box isn't necessary. — xaosflux Talk 12:59, 5 April 2021 (UTC)
  • Oppose as unnecessary and likely to be a magnet for disruptive editing. ƒirefly ( t · c ) 13:17, 5 April 2021 (UTC)
  • Oppose due to it being an unnecessary addition, and a huge potential for edit-warring. JackFromReedsburg (talk | contribs) 19:42, 10 April 2021 (UTC)
  • Oppose Simple situations can just be used in the text. More complex or unusual uses will require explanation in the text, and will not be adequately covered in the infobox. This will not be a common thing to do at all. Having the parameter in the box will be almost always unhelpful and at the same time pushing a political point of view. Graeme Bartlett (talk) 20:52, 10 April 2021 (UTC)
  • Comment. The time for implementing this idea may come (and perhaps sooner than it may seem) but for now this proposal is probably premature. As noted above, relatively few people have made their pronoun preferences known and in even fewer cases we have WP:RS which indicate what those choices are. Where such information is available, it can be discussed in the main body of the article, and I believe that's already our standard practice. Creating a new infobox field now would likely invite a great deal of WP:OR and guesswork, and potential edit warring. Nsk92 (talk) 01:04, 24 April 2021 (UTC)
  • Oppose- Specifying pronouns is more of a "first person" thing: "Hi, I'm Taylor. My pronouns are she/her/hers." It helps because an individual rarely has cause to use gendered pronouns in a self-referential way and it signals to others what such pronouns to use when referring to that individual. But we are writing about the person and will be using the pronouns quite often. We don't need to "tell" the reader, when we can "show" them. Sure, a footnote might be useful or a note on the talk page explaining any instances that might be unexpected by the reader, but there is no reason to hit the reader over the head with this on every bio. --Khajidha (talk) 23:57, 24 April 2021 (UTC) PS - the example given above is just hypothetical, not a statement about myself.
  • Oppose - stating pronouns somewhere verifiable is not the norm and the encyclopedia covers this ground perfectly adequately through its choice of which pronouns to use in the articles themselves. If a person's gender identity is important to a biography, we put that in the body of the article, typically under "Personal life". › Mortee talk 00:02, 25 April 2021 (UTC)

Input for my WP essay wanted

Hello, can anyone please give feedback on my essay, User:NotReallySoroka/No such redirect as "Dorian Fried", which speaks against creation of middle-and-last-name redirects without first name? Thank you, NotReallySoroka (talk) (formerly DePlume) 05:06, 17 April 2021 (UTC)

Dear User: NotReallySoroka, you may like to create this article, and if it is considered too embryonic to be in Wikipedia, it will get moved to the draft space. You can keep an eye on this and see whether it gets enough attention from other users to bring it up to the quality of a Wikipedia article. Regards, Rollo August (talk) 21:38, 25 April 2021 (UTC)

An idea to solve overcrowding and spagettization of articles by context specifications

One thing I'm being noting about wikipedia is the total lack of foot notes as would whatever printed encyclopaedia in my childhood.

This leads to over extense over complicated articles that zig-zag over a topic just to clarify an specific context on the topic with extra long paragrafs when. [1]

Not to talk about the complexity at the moment of editing an article where you want to state a point of view inside a focus that is totally twisted.

The most common examples but not only are the interminable cultural variants listings where a "some countries" [2] would help interleaving the article.[3] Not to mention [4]

Wikipedia should enforce a politic of foot noting articles and add a foot notes section to it's style.

I seem to know that there's already a very unpopular notes section at the wikipedia style but i think that is used for other purposes (mostly to add cites and quotes?).

I only lament if my idea is accepted that the facility for machine readability from external scripts will be lost and the grep of a lynx dump of wikipedia would only output a predicate footnote (eg, in Argentina, Brazil, and Uruguay) without subject (e, g. asado) but in turn my human eyes would preciate that so much. — Preceding unsigned comment added by Neurorebel (talk • contribs)

References

  1. ^ a simple foot note like this would suffice
  2. ^ followed by a footnote clarification
  3. ^ i already know that ref is not the right template for this but I dont remember the proper way to add notes
  4. ^ all the terminology and ethimological babble
Neurorebel, I don't understand what your idea is. Could you clarify? Also, it is already common practice to add notes for long lists like on Bill Nye the Science Guy#Format. Sungodtemple a tcg fan!!1!11!! (talk) 01:55, 18 April 2021 (UTC)
@Neurorebel: You are looking for {{efn}} and {{notelist}}. But I guess the question asked here is this: is something really relevant enough to be mentioned in article prose? If not, it can be mentioned in a footnote, like this: The New Year is celebrated in many countries.[a] – Finnusertop (talk ⋅ contribs) 06:21, 18 April 2021 (UTC)

Notes

  1. ^ Afghanistan, Albania, Algeria, Andorra, Angola, Antigua and Barbuda, Argentina, Armenia, Australia, Austria, Azerbaijan, The Bahamas, Bahrain, Bangladesh, Barbados, Belarus, Belgium, Belize, Benin, Bhutan, Bolivia, Bosnia and Herzegovina, Botswana, Brazil, Brunei, Bulgaria, Burkina Faso, Burundi, Cape Verde, Cambodia, Cameroon, Canada, Central African Republic, Chad, Chile, China, Colombia, Comoros, Democratic Republic of the Congo, Republic of the Congo, Costa Rica, Ivory Coast, Croatia, Cuba, Cyprus, Czech Republic, Denmark, Djibouti, Dominica, Dominican Republic, East Timor, Ecuador, Egypt, El Salvador, Equatorial Guinea, Eritrea, Estonia, Eswatini, Ethiopia, Fiji, Finland, France, Gabon, The Gambia, Georgia, Germany, Ghana, Greece, Grenada, Guatemala, Guinea, Guinea-Bissau, Guyana, Haiti, Honduras, Hungary, Iceland, India, Indonesia, Iran, Iraq, Ireland, Israel, Italy, Jamaica, Japan, Jordan, Kazakhstan, Kenya, Kiribati, North Korea, South Korea, Kosovo, Kuwait, Kyrgyzstan, Laos, Latvia, Lebanon, Lesotho, Liberia, Libya, Liechtenstein, Lithuania, Luxembourg, Madagascar, Malawi, Malaysia, Maldives, Mali, Malta, Marshall Islands, Mauritania, Mauritius, Mexico, Federated States of Micronesia, Moldova, Monaco, Mongolia, Montenegro, Morocco, Mozambique, Myanmar, Namibia, Nauru, Nepal, Netherlands, New Zealand, Nicaragua, Niger, Nigeria, North Macedonia, Norway, Oman, Pakistan, Palau, Panama, Papua New Guinea, Paraguay, Peru, Philippines, Poland, Portugal, Qatar, Romania, Russia, Rwanda, Saint Kitts and Nevis, Saint Lucia, Saint Vincent and the Grenadines, Samoa, San Marino, São Tomé and Príncipe, Saudi Arabia, Senegal, Serbia, Seychelles, Sierra Leone, Singapore, Slovakia, Slovenia, Solomon Islands, Somalia, South Africa, Spain, Sri Lanka, Sudan, South Sudan, Suriname, Sweden, Switzerland, Syria, Taiwan, Tajikistan, Tanzania, Thailand, Togo, Tonga, Trinidad and Tobago, Tunisia, Turkey, Turkmenistan, Tuvalu, Uganda, Ukraine, United Arab Emirates, United Kingdom, United States, Uruguay, Uzbekistan, Vanuatu, Vatican City, Venezuela, Vietnam, Yemen, Zambia, and Zimbabwe
Neurorebel, I feel like your footnote proposal will come off as more of a feature that facilitates "fun/trivial facts", which is not something prevalent within Wikipedia: information is either notable enough to be mentioned or not. Furthermore, underlying context should belong to the main article, and if it's too long, unnecessary details should be omitted. As for terminology that requires clarification, if it's not understandable by a native or proficient English speaker, then it's probably jargon and should be avoided (see the 2nd paragraph of the manual of style). Otherwise, readers can just do a dictionary lookup or infer the word's meaning from context. However, it is a promising idea, and there might be a way to change it so that it can be successfully enacted. Lankyliver (talk) 11:59, 18 April 2021 (UTC)
Neurorebel, we already have this functionality but there is no reason to make it mandatory; it all depends on the topic. The layout section of Wikipedia's Manual of Style defines explanatory footnotes as those that give information which is too detailed or awkward to be in the body of the article. The layout of how to do this is given there: the Notes section goes ahead of the References section. See Abu al-Faraj al-Isfahani for an article which makes extensive use of explanatory notes. Template:Efn has instructions on how to construct them. Notes can cite references themselves if needed as explained at Wikipedia:Nesting footnotes. StarryGrandma (talk) 22:44, 18 April 2021 (UTC)
@力: do you mean Help:HTML in wikitext? – Finnusertop (talk ⋅ contribs) 20:51, 20 April 2021 (UTC)
Kind of. Help:Wikitext explains "how does one use hypertext", but isn't a style guide on "how writing hypertext is different than writing in a physical diary". User:力 (power~enwiki, π, ν) 16:41, 22 April 2021 (UTC)
I think it's worth having footnotes be more obvious. I always use the {{NoteTag}} style for this reason. Other footnotes just look like citations -- that is, things the reader tunes out. Vaticidalprophet 09:51, 20 April 2021 (UTC)
  • Agree with User: Vaticidalprophet - Wikipedia does have a lot of footnotes, but these are largely reference citatiions. Personally, I would not be against having more footnotes if they are adding useful information to an article, but we would need to be carefully that they link with a different list to the reference citation list. Rollo August (talk) 21:47, 25 April 2021 (UTC)

Charts (bar charts / histograms / ......) added to articles

On a page like "Canada"; I'm thinking of 1 chart showing Canada's land mass relative to other countries' land mass (Countries larger than Canada, and smaller than Canada; on either side of Canada.), another chart showing the length of Canada's coastline in relation to the lengths of other countries' coastlines, etc for all the numbers on the "Canada" page.

That's just 1 example; but eventually a "Pictorial-Pedia".

I can't decide whether; a link on the main page should open a separate page with the charts, or should each individual chart "pop-up" when pressing an icon beside the respective number ?

If a link on the main page for "Canada", opens to the pictorial page; should a map of Canada be the background, with the charts arranged on top ?

Maybe; this is beyond the scope / outside the realm, of Wikipedia ?


Maybe; someone else has implemented this idea, and I didn't see it.

I'm so new; to navigating a monstrosity, like Wikipedia.

And; I'll need a lot of "hand-holding", if I do go through with this. — Preceding unsigned comment added by I enjoy data (talk • contribs) 02:24, 26 April 2021 (UTC)

Encyclopedic articles are meant to give readers a general intro to subjects rather than display every single little bit of information possible (see WP:Wikipedia is not an indiscriminate collection of information). Sungodtemple a tcg fan!!1!11!! (talk) 15:23, 26 April 2021 (UTC)
Just checked... we do. See: List of countries by length of coastline. So again... rather than duplicate, just link. Blueboar (talk) 15:49, 26 April 2021 (UTC)

Have the ability to search for pages without talk pages or talk pages without WikiProjects

I do not know if this is feasible or has already been done, but this seems like a great new feature. It can allow WikiProjects to more easily find pages that have not been tagged that are covered by the WikiProject. It would be a great maintenance tool. (Oinkers42) (talk) 15:51, 27 April 2021 (UTC)

I'd very much like to know this as well and would be more than happy to help with adding WikiProjects. I often run into articles, even some that have existed for years, that either don't have a talk page or have a talk page with zero WikiProject banners. – Finnusertop (talk ⋅ contribs) 16:22, 27 April 2021 (UTC)
You can try this Quarry query to get articles without talk pages a thousand at a time. There's also this query that I've used in the past that restricts it to pages tagged as unsourced. Let me know if there are any other restrictions that might be helpful.
Note that to regenerate the results for yourself you have to fork the query. Vahurzpu (talk) 17:08, 27 April 2021 (UTC)
This search looks for talk pages without WikiProject banners. Many of them are talk pages of redirects. PrimeHunter (talk) 17:18, 27 April 2021 (UTC)
PetScan can be used to search for pages with a particular template (e.g. an infobox) or in a category tree that don't have particular WikiProject Banner(s). This search find articles with {{Infobox mountain}} that don't have a banner for WikiProjects Mountains, Volcanoes, or British and Irish Hills. And this search finds articles in Category:Polyphenols and it's subcategories that don't have a banner for WikiProject Chemicals. Plantdrew (talk) 20:12, 27 April 2021 (UTC)

Autopatrolled for extended confirmed users outside of article-space

Though not as prominently displayed, articles in all namespaces are subject to patrol. While patrolling in mainspace involved checking for notability, cleanup issues, etc - patrolling elsewhere is mainly just checking for obvious issues such as copyvios and attack pages. Given the vast number of pages created by experienced users outside of mainspace, patrolling these other namespaces isn't done often. To make this feature more useful, I'd propose automatically patrolling, ideally with a software feature, of pages created by extended-confirmed users outside of mainspace. Thoughts? Elli (talk | contribs) 01:55, 22 April 2021 (UTC)

Um... what? Ever heard of a user, Carlossuarez46, an administrator, abusing autopatrolled right by creating thousands of non-notable substubs? If anything, we should be more cautious about handing out autopatrolled after that recent case. So, no. 🐔 Chicdat  Bawk to me! 11:38, 22 April 2021 (UTC)
  • Support. The rationale for having projectspace pages subject to patrolling in the first place has always been fairly weak. The theoretical reason that one should watch for copyvio and attack pages there there sounds reasonable in the abstract, but in practice the overwhelming number of projectspace pages are either never patrolled at all or get patrolled accidentally, much later than they have been created. We should look for better ways of identifying highly problematic material in projectspace (e.g. trying to automate certain tasks and using bots creatively) rather than making all projectspace pages subject to patrol. The Carlossuarez46 case was an extremely isolated outlier even for mainspace and, AFAIK we've never had anything similar in projectspace with any user, admin or otherwise. I would support making all pages outside of mainspace not subject to patrol; but short of that, Elli's proposal is reasonable. Nsk92 (talk) 12:02, 22 April 2021 (UTC)
  • Oppose this particular implementation, but support in theory the idea of deprecating patrol for experienced users outside of reader-facing namespaces. EC is an automatic userright and easily gamed, and I fear we'll have LTA socks gaming EC and gaining this modified autopatrol right, creating and automatically patrolling pages we would otherwise reject in some obscure namespace, then moving them to article space where they will go undetected. Autopatrol should continue to be a userright only handed out based on a human review of an applicant's suitability. On the other hand I would support turning off patrol for NOINDEXed namespaces that are low-risk for abuse, perhaps along with adding a "this is not a Wikipedia article" banner in the software for those namespaces. Don't take my comments as a proposal, it needs work. Ivanvector's squirrel (trees/nuts) 13:12, 22 April 2021 (UTC)
    I think indexing is a good potential criterion for which pages require patrolling. {{u|Sdkb}} talk 05:36, 24 April 2021 (UTC)
  • Support the idea of this, still unsure of the correct implementation. User:PEIsquirrel brings up a concern about LTAs abusing this. The simplest solution is to have all pages moved to the mainspace require a review (unless the user has the true Autopatrolled right). I'm indifferent on banners saying "this is not a Wikipedia article". JackFromWisconsin (talk | contribs) 14:34, 22 April 2021 (UTC)
  • We shouldn't be !voting per the idea lab rules, and I'm unsure about the specific proposed implementation here, but I generally support trying to find a way to make patrolling of non-article pages more targeted. For copyvios, in particular, I wonder if that could be semi-automated—maybe only patrol pages that Earwig says have a high probability of violation? {{u|Sdkb}} talk 05:38, 24 April 2021 (UTC)
  • Support the idea, not sure with potential abuse mitigation. EpicPupper 21:58, 27 April 2021 (UTC)

Making wikipedia more graphic

Is it possible to add more images or videos in articles for a better experience and understanding of the content provided? — Preceding unsigned comment added by Souvick100Saha (talk • contribs) 09:11, 24 April 2021 (UTC)

Thumbs down icon Cabayi (talk) 10:10, 24 April 2021 (UTC)
Souvick100Saha, this is the Village Pump Idea Lab used for incubating proposals about all of Wikipedia. If you see particular articles that need more images, please be bold and add them. Thanks, EpicPupper 20:08, 24 April 2021 (UTC)
Souvick100Saha, unfortunately, licensing requirements prevent us from adding many images we might otherwise like to. {{u|Sdkb}} talk 02:01, 29 April 2021 (UTC)

"Manually-vetted" usergroup

After seeing some recent discussions, it seems to me like there is a general community want for a userright/usergroup that's more trust than "extended confirmed", but less trusted than administrator. Generally, the concern is that extended confirmed can be gained automatically, with no human oversight.

Therefore, I would think that a usergroup "manually vetted" would make sense, and would be automatically assigned to any editors with "autopatrolled", "new page patroller", "page mover", or "template editor". This is because for granting those rights, a user should either have decent content contributions, or be well-trusted.

Following this, many pages with sysop protection could be dropped to this group instead, since any members have already been vetted for being productive contributors.

Thoughts? (please don't !vote, I'm not sure of the specifics here, I just think this could be potentially useful) Elli (talk | contribs) 19:22, 28 April 2021 (UTC)

I've generally disliked most attempts to create a formal 'inside circle'. This seems like the same. We don't need even more gatekeeping IMO. Also, overprotected full protections should be dropped anyway, as they're already not in compliance with WP:PP. ECP works fine as a set of requirements for basic competence and can be obtained automatically. If ECP editors are doing problematic things the accounts can be blocked. It's not exactly trivial to have multiple ECP socks lying around, as that does take an investment of time. That all being said, there is an equivalent concept to this on metawiki ('autopatrolled' is given out freely for this purpose), but that project is a different size and purpose. ProcrastinatingReader (talk) 19:27, 28 April 2021 (UTC)
They're not overprotected for now - but usually I'd think full protection in terms of edit warring, for example, could be dropped to this level, with the warning that any edit warring would immediately get the rights pulled. Elli (talk | contribs) 19:32, 28 April 2021 (UTC)
Not being a "content wiki" patrolling on metawiki applies everywhere, but yes we normally give it out liberally there to anyone that is around for a bit and is active on a content project. It has very little impact there except on actual patrolling and a couple of filters. — xaosflux Talk 19:35, 28 April 2021 (UTC)
Elli, perhaps the template editor protection level could be repurposed for this. Articles like Gay, Beer or McDonald's should probably not be moveable by extended confirmed, but restricting them to sysop seems overkill. An edit filter could be used to stop for example an autopatrolled user from moving templates, so moving templates would still require the user to be a template editor. — Alexis Jazz (talk or ping me) 21:25, 28 April 2021 (UTC)
@Alexis Jazz: I don't see how this would be appropriate - editing templates with hundreds of thousands of transclusions is a very different task from moving pages. Elli (talk | contribs) 21:59, 28 April 2021 (UTC)
Elli, not much would really change for those. Editing templates or modules with the manually-vetted protection level would still require a user to be a member of the template editor user group. There are currently 5 protection levels, increasing this may be met with resistance. It's just a clever way of optimizing the use of protection levels. Do more with what we have. — Alexis Jazz (talk or ping me) 22:05, 28 April 2021 (UTC)
@Alexis Jazz: the problem is that far more people would end up with the ability to edit such templates than should have it. It's the same reason we split out intadmin from admin, even though pretty much any admin can get the perm on request. Elli (talk | contribs) 22:32, 28 April 2021 (UTC)
Elli, no they wouldn't. Who do you believe would gain the ability to edit what are currently called template editor protected templates? — Alexis Jazz (talk or ping me) 22:47, 28 April 2021 (UTC)
@Alexis Jazz: my point is that your idea would either lead to a lot more people requesting template editor, or far fewer people getting the right than should have it. Elli (talk | contribs) 23:02, 28 April 2021 (UTC)
Elli, that's not what I meant. My idea would be to rename the "template editor" protection level to "manually vetted" or similar and in addition to template editors apply it to patrollers, page movers, etc. while using an edit filter to ensure only the template editor user group (not to be confused with the template editor protection level) can edit/move pages in the template: and module: namespaces at this protection level. — Alexis Jazz (talk or ping me) 23:09, 28 April 2021 (UTC)
@Alexis Jazz: ah, I see. Still not sure this is a good idea, there are some template-protected pages outside of the template: namespace (like User:AnomieBOT/TFDTemplateSubster). Also an edit filter is janky and you'd be better off just making another group. Elli (talk | contribs) 23:55, 28 April 2021 (UTC)
There seems to be two concerns here and I'm not sure how they connect. Right here, the concern seems to be that extended-confirmed is granted too freely. What abuses are we seeing from EC editors that we're trying to prevent? (Or, what right are we trying to grant to this new elevated group of editors?) In the one linked discussion, the concern seems to be that move-protection is overriding the page-mover permission, which does seem weird, but it seems like an argument about what "page mover" ought to mean. I don't see why it needs to involve a new permission. In either case, template editor permissions seem quite separate. › Mortee talk 00:07, 29 April 2021 (UTC)
@Mortee: so ECP - basically the Arbitration Committee invented a protection level out of thin air with any technical implementation, leaving it to the administrators to try to figure out how to manage it, thus eventually extended confirmed was born - the original purpose remains, however the community has additionally co-opted the group and permissions model to also provide what it is today - we can't strengthen the requirements without getting back to where we started: a means to enforce the arbcom device. — xaosflux Talk 00:19, 29 April 2021 (UTC)
Xaosflux I just haven't quite understood what's actually being asked for here. Are there powers being automatically granted to extended-confirmed users that shouldn't be (Generally, the concern is that extended confirmed can be gained automatically, with no human oversight)? If so what are they and what's the problem? Or, as with the linked discussion, is it rather that powers aren't being granted to people that should have them, in which case I guess the same questions apply. The way this was framed it sounds like there's a general concern about this, but I'm not yet clear what 'this' is, so I'm interested but a little lost. › Mortee talk 00:25, 29 April 2021 (UTC)
@Mortee: currently extendedconfirmed is granted automatically when your account is at least 30 days old and you have made your 500th edit. The usergroup currently does two things: it lets you edit pages that have extended confirmed protection and it lets you bypass ~5 abusefilters (notably the one that allows use of the content translation tool). We can't grant this "less freely" though, as the protection is about those arbcom requirements in many cases - which strictly only applies to people with under 500 edits and 30 days tenure. — xaosflux Talk 00:31, 29 April 2021 (UTC)
I understand how EC works at present. I don't quite see the connection between the linked conversation about the page mover right being underpowered and this proposal of a new intermediate right between EC and admin. They seem separate to me and I haven't seen the general clamour for another level of permissions. Perhaps there's a good reason for making one, it just seems underspecified. › Mortee talk 02:07, 29 April 2021 (UTC)

Portals?

Closing, I encourage the OP to check out Wikipedia:Arbitration/Requests/Case/Portals. - Knowledgekid87 (talk) 17:43, 29 April 2021 (UTC)

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Does anyone actually use portals? Before crossing the Rubicon and becoming an editor, I had never noticed them, let alone used them. An example of their disuse, Portal:Cars is viewed by less than 100 daily on average... Is there any way to make them more accessible and user-friendly or should they just be scrapped? ~ HAL333 21:34, 26 April 2021 (UTC)

  • Scrapped, except the top level ones linked on the main page, because virtually nobody uses them (based on page views). On the other hand, their existence does no harm. We have several million pages nobody reads, and portals make up less than one tenth of one percent of them. Levivich harass/hound 21:59, 26 April 2021 (UTC)
  • I went from a portal maintainer to a portal skeptic. The idea that they are either alternative thematic Main Pages or reader facing facets of WikiProjects both failed. Readers simply don't use them the way we wanted them to. Readers hardly use them at all. There was a big RfC to deprecate portals a few years ago but that failed. The portal people have had time to come up with worthwhile ideas since then but portals are still the sad reminder of what all websites used to look like 20 years ago and why they are no longer like that. If another RfC was held in say a few years it would probably pass. – Finnusertop (talk ⋅ contribs) 22:08, 26 April 2021 (UTC)
  • Portals should be scrapped, except the very top level ones linked on the main page. Virtually no one uses them. The larger categories are helpful, but smaller portals often go unused after significant effort in making them. EpicPupper 21:46, 27 April 2021 (UTC)
  • Portal:Current events is used, but that can/should be moved to project space. Beyond that, I never use portals, but don't think they are so unused that removing the entire namespace is justified yet. User:力 (power~enwiki, π, ν) 19:28, 28 April 2021 (UTC)
  • There was a discussion back in 2019 about this, and it ended in a messy ArbCom case that resulted in BrownHairedGirl and another editor getting sanctioned. I don't want a repeat of that. --Chicdat (talk) 12:18, 29 April 2021 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

How about making all requests for comments into subpages of the RfC page?

All AfD listings that are not jokes are as subpages of the main Wikipedia:Articles for deletion page. In that manner, I propose that all future Requests for Comments be mandatorily made subpages of Wikipedia:Requests for comment. I also propose that titling of future RfCs be standardised with the following format:

  • Wikipedia:Requests for comment/In re [page name] for RfCs that concern one page. (feel free to replace "in re" with words like "regarding", but its replacement should be standardised across the board).
  • Wikipedia:Requests for comment/[question] for RfCs on general matters that cannot be easily classified as only concerning a specific/specific pages.
  • Wikipedia:Requests for comment/[proposal] for proposals.

Ideally there could be an RfC template (yes, I know about Wikipedia:Requests for comment/Example formatting) that a user would sub into when making an RfC (c.f. {{afd2}} where the only things you have to do is to type your reasoning, the page name, and its category). A side benefit of standardisation is that it could open the door for WP:Twinkle to also cover RfCs (though this is not the main reason for my proposal). Thank you, DePlume (talk) 04:17, 8 April 2021 (UTC)

I don't see a problem this solves. Elli (talk | contribs) 05:27, 8 April 2021 (UTC)
Right now the RFCs are all over the spot. Some are in Articles' talk pages, another bunch as subpages of WP:RfC, and yet another bunch as subpages of various Project (not Project talk) pages. Making all of them subpages of WP:RfC will greatly enhance unity by having one instead of 100+ locations for them. --DePlume (talk) 05:34, 8 April 2021 (UTC)
DePlume I guess it just seems unnecessary given the variability in "officialness" or whatever of RfCs. Is a subpage really needed instead of a post at WP:RSN or whatever? Feels excessive. Elli (talk | contribs) 05:50, 8 April 2021 (UTC)
I am not asking for the RfCs to be posted twice. It is just once, like the AfD nominations. NotReallySoroka (talk) 01:16, 11 April 2021 (UTC)
I think there are some benefits, like having RfCs being found and created slightly faster with Twinkle support and there not being 15 pages for the same reason. I can see why it could be unessecary, but it could have moderate benefits. Arsonxists (talk) 14:58, 8 April 2021 (UTC)
  • There are benefits of holding RFCs about particular articles on article talk pages, such as having previous discussions and the article itself close at hand, but there are other RFCs that are not about particular articles, so they need to go elsewhere. As long as RFCs are registered and advertised at a central location I don't see any benefit to standardising where the discussion itself is held. I don't think we should be making decisions on the basis of what is easy to implement in Twinkle (does it go to the library to find good sources and add them to articles yet? If so I might consider using it) but anyway I don't see what would be too difficult about having it add the correct RFC headers wherever a discussion is held, if it is really too burdensome for people to do it themselves. Phil Bridger (talk) 15:25, 8 April 2021 (UTC)
    • Thank you, but Twinkle is merely a collateral benefit, not the main reason. DePlume (talk) 17:31, 8 April 2021 (UTC)
      • Then what is your main reason? I don't see one in your initial comment here, but merely an assertion that we should do this. Phil Bridger (talk) 17:54, 8 April 2021 (UTC)
        • Phil Bridger There are unity (prevents RfCs from being scattered all over Wikipedia), convenience (those who wish to reply to an RfC can easily find some to respond to), and standardised format, just to name a few. Sorry for replying this late, NotReallySoroka (talk) 01:15, 11 April 2021 (UTC)
          • We want AfD's to remain visible if the article and talk page is deleted, so they aren't held on the talk page. RfC's don't have that concern, and they aren't transcluded on pages like Wikipedia:Articles for deletion/Log/2021 April 11. I don't see sufficient reason to remove RfC's from the page they mostly concern. And whether to designate a discussion as an RfC is often an arbitrary decision. PrimeHunter (talk) 11:18, 12 April 2021 (UTC)
            • There is another reason it makes sense to put AfD's for all articles in one place even if it makes sense to put other RfCs about an article on that article's talk page: Established articles have followers who will be interested in RfCs about the article. A brand new article has no such followers; the people interested in whether the article should be deleted are the people who are interested in the scope of Wikipedia. Those people follow the AfD page. Bryan Henderson (giraffedata) (talk) 21:46, 24 April 2021 (UTC)
  • I see the point made, RFCs are all over the shop. Unless you have every area in your watch list, or spot it on the centralised discussion board, it would make sense to make it to centralise to one location. Davidstewartharvey (talk) 13:52, 12 April 2021 (UTC)
    • Current RfCs are listed at Wikipedia:Requests for comment/All. PrimeHunter (talk) 14:13, 12 April 2021 (UTC)
    • Having RfCs exist as subpages of one page will make them easier to search (from that point on), but I don't think it'll affect how easy it is to notice new RfCs. Using the bot-maintained page that lists all current RfCs would still be the best way. And it's a bit late to try to improve searching, since there is already a long history of requests in other locations that people would still have to search through. (I don't think it's worth the effort to move them and fix all links to them.) isaacl (talk) 15:08, 12 April 2021 (UTC)
      • As I said, whether to designate a discussion as an RfC is often an arbitrary decision. I think it's of limited value to make it easier to search old RfCs. PrimeHunter (talk) 15:35, 12 April 2021 (UTC)
        Yes, I read your comment. I apologize for not discussing the desirability of searching discussions not arbitrarily marked as a request for comment, which I think is important as well and so limits the value of being able to search one set of tagged discussions. isaacl (talk) 20:01, 12 April 2021 (UTC)
        I'm just trying to weigh the use cases for searchers. How often do I specifically search for RfC's about something? Never. How often do I search archives of a page for discussions which would normally belong there? Often. I think an "RfC space" will make the discussions harder to find, not easier, for the typical searcher. Maybe they get lucky and hit a notification about the RfC in the archives they search, but the chance is much better if the actual discussion is there. PrimeHunter (talk) 23:18, 12 April 2021 (UTC)
        I don't favour this proposal, for the reasons I specified (don't see how it helps people notice new RfCs or helps with searching given the current situation), but I didn't want to ignore a potential way of interpreting the proposer's viewpoint on the proposal's advantages. isaacl (talk) 23:30, 12 April 2021 (UTC)
I believe it is preferable to keep most RfCs, particular article RfCs, at the corresponding talk pages. That's where one can view discussions leading to a particular RfC, the relevant talk page archives, etc. However, I also think there is some benefit in having old RfCs searchable. An RfC is a formal, consensus determining, step in the dispute resolution process. Although the initial decision to label a particular discussion as an RfC is often arbitrary, the decisions reached in RfCs carry greater weight afterwards and their conclusions are viewed as more authoritative, compared to ordinary talk page discussions. So I think it might be worthwhile to get the bots to somehow index old RfCs in a systematic fashion after they are closed or expire. Nsk92 (talk) 23:58, 12 April 2021 (UTC)
I agree with @Nsk92 about keeping RFCs about the content for a single article at that article's talk page.
However, I would like to see the large volume of Wikipedia:Reliable sources/Perennial sources get moved off of Wikipedia:Reliable sources/Noticeboard, so that RSN can go back to being a reasonably sized and functional noticeboard. WhatamIdoing (talk) 02:21, 23 April 2021 (UTC)

We've already solved this problem once. Look at WP:GA, where nominations are conducted on article talk pages but there's a centralised index and register. Why not copy that? Meets everyone's preferred way of working.—S Marshall T/C 09:07, 30 April 2021 (UTC)

Reminder: Help generate ideas for the Universal Code of Conduct drafting committee

I wanted to send a quick reminder that we are seeking community ideas at Wikipedia:Universal Code of Conduct/2021 consultation about the implementation the Universal Code of Conduct. The drafting committee has been selected, and input provided will be useful to their work. Xeno (WMF) (talk) 15:34, 1 May 2021 (UTC)

Policy involving Warnings and Welcomes

I feel like we should have some kind of policy concerning the use of warnings and welcomes and when to use them. I think that the policy should state that "If the user in question has not been welcomed yet they should not be warned but instead welcomed" because not all users who get warned had bad intentions. Some of them just don't know how to edit Wikipedia correctly and warning them doesn't really help them much other than discouraging them from editing. Warnings don't provide helpful links for new users unlike welcomes. Warnings only provide links to the policy they are being warned for violating. Blaze The Wolf | Proud Furry and Wikipedia Editor (talk) 16:27, 3 May 2021 (UTC)

WP:BITE has been an accepted guideline for well more than a decade. --Jayron32 16:33, 3 May 2021 (UTC)
Yes but apparently it does not apply to the use of welcomes and warnings as I have seen users who have gotten warned but haven't been welcomed yet. Blaze The Wolf | Proud Furry and Wikipedia Editor (talk) 18:55, 3 May 2021 (UTC)
It depends. I'm not sure that someone who blanks and article and fills it with racial curse words is necessarily in need of a friendly welcome. --Jayron32 19:14, 3 May 2021 (UTC)
  • meh... All that will happen is that an editor who wants to issue a warning will slap in the welcome template at the same time (even in the same edit). Blueboar (talk) 19:13, 3 May 2021 (UTC)
  • I don't think this is the sort of thing we need a firm policy on, editors should just apply common sense. If someone is just vandalising articles then giving them a polite welcome template is just a waste of time, but if someone is making mistakes akin to a newcomer trying to edit then giving them a welcome message is fairly standard. The level one warnings are designed to be non-aggressive anyhow, and most include links to advice and the teahouse. 192.76.8.91 (talk) 21:45, 3 May 2021 (UTC)
  • I think in general this is a good practice to follow. Even though I'm not as optimistic as some, I'm going to ping User:Gerda Arendt to this discussion as she has long been a strong supporter of the concept. I don't think it's something that should be codified however. There are too many WP:SOCKS, WP:SPA, vandalism, and throw-away accounts that are here for one reason, and one reason only; to be disruptive. It would be a waste of time and effort (however minimal) to welcome such users. I have no complaint with anyone who makes that honorable effort, but I do NOT think it should be part of any policy. — Ched (talk) 16:47, 4 May 2021 (UTC)
    Thank you for the ping. I wouldn't want anything "prescribed" but my sense - common or not I sometimes don't know - tells me that a new user who edits in a way worthy of good faith should first be welcomed, and contact be established between people, rather than a warning followed by a block. The example Ched and I (and Drmies and Cullen and one more I forgot) noticed was a new user who replaced black&white images by colorized ones, on John Wayne, I believe. It looked horrible, and I reverted - as some others had done before - but it was not racial, not changing meaning, so I welcomed them, only to see that another blocked "temporarily". I wouldn't be surprised if we lost that user, and am not the right judge to tell if that is good or bad. - I have been reverted often when I thought I clearly improved something, so have a soft spot for others possibly in the same situation. --Gerda Arendt (talk) 19:09, 4 May 2021 (UTC)
  • Some people are clearly unwelcome, though. Saying "thank you for your contributions" to spambots, vandalism-only accounts, and homophobic trolls isn't just a waste of time. It also makes the "welcome" sent to good-faith users a whole lot less sincere. Suffusion of Yellow (talk) 19:22, 4 May 2021 (UTC)
  • Welcomes need to be used a lot more, in keeping with WP:AGF. Many new editors make an edit which is in good faith, but is not useful enough to be kept. For example, adding uncited information, changing from one style of English to another, formatting against the MOS, or changing something in a way that has consensus against it, by someone who does not know about that consensus, to name a few. I think if somebody is not intentionally disrupting, they should always be welcomed instead of warned, with one of the "problem user welcomes". —Lights and freedom (talk ~ contribs) 20:20, 4 May 2021 (UTC)

Dark mode

Just noticed that XTools has switched to an all-black background. I really dig it. Are there any current efforts/pushes to add a dark mode to Wikipedia? Shouldn't be too difficult, right? ~ HAL333 01:44, 10 April 2021 (UTC)

@HAL333: it is actually very difficult - see many many open tasks related to that idea though. — xaosflux Talk 09:14, 10 April 2021 (UTC)
This has been implemented on the mobile version. Sungodtemple a tcg fan!!1!11!! (talk) 00:22, 11 April 2021 (UTC)
HAL333, Ugh, I hope not. Just wait until your eyes are a couple decades older and you need all the contrast you can get. -- RoySmith (talk) 23:25, 12 April 2021 (UTC)
@HAL333: There's something similar in your preferences (gadgets) that changes the text to green and the background to black, but I suspect that takes some getting used to. Sdrqaz (talk) 00:51, 20 April 2021 (UTC)
Oh wow. Just tried it and although it's easy on the eyes, I wish it weren't so garish. ~ HAL333 01:37, 20 April 2021 (UTC)
Looks like they've just released dark mode under "Testing and development", xaosflux and HAL333 (or maybe I've just missed it for ages). Doesn't look too bad. Sdrqaz (talk) 23:08, 22 April 2021 (UTC)
Sdrqaz, is Testing and Development in preferences as well? ~ HAL333 19:36, 23 April 2021 (UTC)
@HAL333: Yeah, it's near the bottom of the "gadgets" section (should be the penultimate one) of preferences. Sdrqaz (talk) 19:46, 23 April 2021 (UTC)
I just turned it on and OH GOD IT'S BLINDING ME the background is literally black and the text is white which makes it decidedly not easy on the eyes. Is there anyway to make the background dark gray instead? (Is this even the right place to post this?) ♔MEisSCAMMER(talk)(contribs) 22:04, 23 April 2021 (UTC)
@MEisSCAMMER and @Sdrqaz, this is being discussed at Wikipedia:Village_pump_(technical)#Proposal_for_a_dark-mode_gadget_addition_(before_Earth_Day_22_April?). I too find the blackness blinding, but only on certain devices. Comments would be welcome there. – SD0001 (talk) 08:43, 24 April 2021 (UTC)
@HAL333: You can also configure dark mode by following to Special:Preferences#mw-prefsection-gadgets. Scroll down to find Dark mode checkbox. AXONOV (talk) ⚑ 13:39, 13 May 2021 (UTC)
@HAL333: I have a dark mode for Wikipedia. See it on the right. I use third-party extension called Stylus for the Chrome which replaces default CSS styles by userstyles written by me. I didn't publish it yet cause I got no time to fix some bugs (there are some due to loose Wikipedia styling rules for infoboxes, tables and code tags). --AXONOV (talk) ⚑ 08:01, 5 May 2021 (UTC)
I like the look of it. ~ HAL333 05:34, 15 May 2021 (UTC)

Showing section heads only for some sections on computers (eg plot summaries), as on phones?

Hello there; I haven't posted in the Community Portal before, so I'm not sure if this is the right place or way for this, apologies if not. But it struck me that when I look at Wikipedia on my phone it shows section heads only in articles, which you then click on to see the section; on my computer, I see the whole article laid out before me. This can be tricky with, for example, articles that contain a detailed plot summary of a book/film/series which I want to know more about but don't want to kow all the plot. I wondered if it's possible to have that 'click on section head to view this section' option for some sections like these (or all sections?) on the 'computer version' of Wikipedia? Is that a user-controlled thing I haven't found? More likely a thought that's been aired before and not taken up for good reasons I haven't thought of (hard to imagine many novel suggestions coming up at this stage in the game!) Thanks. Iaineditor (talk) 10:39, 1 May 2021 (UTC)

Adding an 'Open access' option to Journal citation (RefToolbar)

Add a tickbox to this?

When I'm adding journal references I usually know if they're open access or not, but there's no way of entering that in the pop-up RefToolbar. Historically I used to run Citation bot afterwards, but that feels very resource heavy and these days I add '|doi-access=free' manually. Would it be possible to add a tick-box which would automatically add '|doi-access=free' when the {{cite journal}} output is generated? --Project Osprey (talk) 09:21, 11 May 2021 (UTC)

I would support this idea. You can likely add that "|doi-access=free" into one of the boxes on the form. It does not work in the visual editor though as it will try to reproduce what you put in by escaping it. Graeme Bartlett (talk) 11:05, 11 May 2021 (UTC)
Sounds like a good idea, and I assume it's technically doable. I should say, though, that I often don't know if a ref is open access or not without a bit of extra checking. For many subscription journals their articles become open access several years after publication (frequently about 5 years, sometimes sooner). Some journals update the article's page after that indicating that the access is now free but many don't, e.g. Springer Verlag (unless the article was published in open access format to begin with). There I have to actually click on the pdf file link to see if the article has become free or not. It's rather annoying, but I don't suppose that this part of the process can be automated. Nsk92 (talk) 11:51, 11 May 2021 (UTC)
It might be possible to semi-automate this way. If the tick-box acted as a flag for User:OAbot? Doing it that way would also correct for false-positives. --Project Osprey (talk) 09:11, 13 May 2021 (UTC)

Proposal for a new namespace: "Community:"

how about a new namespace, called "Community:"? pages here would be for specific community ventures, efforts, organizations, etc. within specific geographical communities, neighborhoods, etc. .

in creating this name space, we could use the "subpage" feature to our advantage; namely, each "community" would have a single main page as a hub or central node; then, all pages for individual groups, items, issues within that community would be subpages of the main hub page.

Please note, items within this namespace would be subject to the same criteria as regular entries, as entailed by WP:notability, WP:RS, etc etc. it is simply a way to encourage, induce and motivate greater editing activity, within various communities that may perhaps need greater coverage than they have currently.

I know this is a long shot, as is any proposal for a new namespace. However, i wanted to post it here, at the Idea page, just to get some overall feedback, input, brainstorming, etc. I welcome all comments. thanks! ---Sm8900 (talk) 🌍 20:05, 7 May 2021 (UTC)

We already do this – see WP:PROJECT. Geographical communities are also supported by chapters and language versions. Andrew🐉(talk) 08:50, 14 May 2021 (UTC)

The book namespace

This namespace is quite useless. You can't actually get to read one of these books without either buying it from PediaPress or using the volunteer maintained tool MediaWiki2Latex. While it's great that MediaWiki2Latex exists it takes hours to actually get the book if at all and if the book is excessivley long like most our books you will have to download MediaWiki2Latex, but since that is only available for Linux with support at German WikiBooks that is a quite grueling process. And then after you've gone through all that you may realize the book contains don't actually work as intended due to a navbox someone slapped onto the book or errors after hours of rendering. In practice the pages are just simple lists of articles.

In short the user experience is absolutely terrible. Books in the book namespace are also called "Community maintained" and the namespace is supposedly reader facing (although that is debatable after the systematic removal of links from templates and mainspace). The namespace contains a ton of material that seems to be individual editors testing out the book creator of very low quality and much of the rest isn't feasible to print or export as a PDF due to it simply being too large.

The pageviews are also absolutley abysmal which can be seen with the massviews analysis tool. The graphs are completley wack due to the links being resently removed, one book (Book:Full Form) ocassionally getting many times more views than the rest of the namespace combined and some editors (me included) opening a large number of books to assess the status of the namespace or try to make them less bad. I think it's fair to say that when the views stablize the views for the entire namespace will be under 500 a day spread out over 6000 books. The majority of books don't get a single view a month and very few people would miss them.

We also have PediaPress to consider which prints some Wikipedia books. They link to some of our books and it would be courteous to at least contact them about any changes that happens.

What can we do about this then? There are a lot of options here ranging from absolutely nothing since basically no one sees it any way to removing the namespace entirely (probably with a refund system and keeping a handful of books in some other namespace for PediaPress). Other options would include something like disabling saving new books in the book namespace using Special:Book (which is a simple configuration option), userfication of most books, large scale deletion or protection of the entire namespace.

I'm really unsure where I stand on this question and have been flipping back and forth. There is a non-zero value in the books for a handful of users but there is also a substantial negative in leading users to broken material they can't use. I think I would like to see us officially dropping support for community books at least with no saving new books there, no more WikiProject tagging, no more "community maintained" language in documentation pages and so on. Probably followed by a likely very controversial mass MfD of unused books which comprise most of the namespace for possible soft deletion. I wouldn't be opposed to going further either though.

What do the pump think? I'm like I said quite conflicted on what to do here. --Trialpears (talk) 14:33, 6 May 2021 (UTC)

Trialpears, I don't get it. I looked at Book:Full Form, Book:Fringe (season 2) and Book:The Funk Brothers. When I pick "Wikitext in "Edit this book: Book Creator · Wikitext", there's nothing but a list of articles. For books, we have b:Main page, right? What even is this Book: namespace? I didn't even know it existed. — Alexis Jazz (talk or ping me) 15:06, 6 May 2021 (UTC)
Alexis Jazz At this point it is basically just lists of articles. There used to be a simple way to download these but due to bugs and security issues this was removed in 2017. No replacement is planned and the prospects of it ever working again is very low. There is like I said above a workaround which isn't great and the possibility to order a printed book consisting of these articles. --Trialpears (talk) 15:46, 6 May 2021 (UTC)
Trialpears, inform the printing company, freeze the business for 3 months, create a new username for this and move the business to the userspace of that user in case someone has a use for these lists and to avoid a potentially controversial XfD, kill the zombie. In that order. http://medi.wiki2latex.wmflabs.org/ doesn't seem to care about namespace, I copied Full Form to my userspace and I was able to run the tool. When it finished it asked me to click some arrow in the corner of my browser.. no idea what it's talking about, so I never got the PDF. With Full Form in the Book: namespace, it did exactly the same thing. Looking at the HTML, it seems to try to redirect to http://medi.wiki2latex.wmflabs.org/file/1230.pdf (number is a job number so varies) but that just loads the home page of the project. — Alexis Jazz (talk or ping me) 17:27, 6 May 2021 (UTC)
  • Amazing! I turned on the book gizmo, added some articles to my book, made book chapters, shuffled the articles into chapters, saved the book, previewed it at Pediapress and could have ordered a hardback copy delivered to me in the UK for about 17 GBP or 24 GBP printed in colour. Instead, I then used the MediaWiki2LaTeX magic to create a PDF. It churned away for over 30 minutes and then spat out a 42Mb PDF with my 7 articles presented nicely, pictures tidily resized to fit the pages, all of the links as footnotes, a full set of the references and a full list of contributors – all spread over 244 pages. Lovely. Impressive stuff. Awesome technology — GhostInTheMachine talk to me 18:30, 6 May 2021 (UTC)
    — And arguably quite pointless. Wikipedia is on the Interwebbly. Why do I want to make a book of frozen pages? However, not everybody has a live network connection like I have and some people may want a hardcopy and it does work, so why worry about it? How much is the namespace costing us? — GhostInTheMachine talk to me 18:39, 6 May 2021 (UTC)
    I'm glad you liked it! Experiences like these are what makes it difficult to deal with the book namespace. Books can work well but more often than not the experience is something more akin to Alexis above. It is worth noting that what you did (starting the book creator at Special:Book, creating a user page storing the book and using MediaWiki2LaTeX and PediaPress to render it) will still be possible if the Book namespace goes away. It would perhaps not be possible to go to Book:Elements and do the same with that book. I doubt that is much of a loss since that page is like most other books in the namespace not that great (what happened with groups 7 and 8, why is Mixture included, what's up with the stray hyphen and so on). Books that people wished to be retained would of course be refundable to userspace or potentially somewhere in Wikipedia space.
    There really isn't that large cost to retaining the namespace, my main concern is simply that it's a very bad user experience. Not being able to download you PDF after a long rendering session, or buy books where the reference section is "<templatestyles src="Reflist/style.css">" isn't great.
    Finally it's worth pointing out that we do have a download as PDF feature in the sidebar which is good at dealing with PDFs of single pages. --Trialpears (talk) 19:45, 6 May 2021 (UTC)
    • Not sure that I exactly liked it, although the technology did seem rather cute. When I tried the book gizmo, it did not seem to allow me to save the book directly to my user space. I made the copy from the Book namespace myself. If the resulting plan is to kill off the Book namespace, then the save option needs to be checked and possibly changed/fixed — GhostInTheMachine talk to me 20:52, 6 May 2021 (UTC)
      I don't think it likes subpages which it should be able to handle. Did you try to use a / in your book title? I'll file a phab ticket shortly if so. --Trialpears (talk) 21:00, 6 May 2021 (UTC)
      GhostInTheMachine I am not able to reproduce this. I noticed the save book button doesn't light up when you enter something in the box but rather when you press away from the box. I remember that I had mild problems saving a user book once though possibly because the button didn't light up as expected. Could you try it again and see if you encounter any issue again? I'm not gonna report the graphical issue since the extension is only bugfixed maintained. --Trialpears (talk) 20:39, 8 May 2021 (UTC)
    GhostInTheMachine, However, not everybody has a live network connection like I have and some people may want a hardcopy Try Kiwix? — Alexis Jazz (talk or ping me) 21:07, 6 May 2021 (UTC)
    Yes, and the Internet-in-a-Box project, but even a limited real paper hardcopy still has advantages for some situations — GhostInTheMachine talk to me 21:42, 6 May 2021 (UTC)
  • Wikipedia is good at trying out experiments with new ideas, but we are not good at cutting our losses and retiring those ideas that don't work out (see also: Simple English Wikipedia). The maintenance burden of books is greater than any benefit it will ever bring us in its current manifestation. {{u|Sdkb}} talk 09:21, 7 May 2021 (UTC)
  • I would fully support retiring the Book namespace and any associated tech that we have. If removing the namespace would cause issues or be a waste of dev time (probably!), then I'd support deletion of all pages in the namespace and preventing the creation of any new ones. They serve precisely zero purpose any longer. ƒirefly ( t · c ) 15:01, 7 May 2021 (UTC)
  • "In short the user experience is absolutely terrible." Indeed. The solution here is to improve it, not to kill it. Headbomb {t · c · p · b} 20:58, 8 May 2021 (UTC)
    That would be ideal, but I can't see that happening. The extension is under bugfix only support and there have been no developer intrest for years and I don't see any developer prioritizing it in the future. I don't blame them either: The entire namespace has about the same amount of views as a popular portal like South Africa. Whether it's better or worse to keep or delete something with this bad a user experience is up to opinion but I don't feel like the issues are solvable without significant amounts of developer attention which would be much better spent on any item of the community wish list. --Trialpears (talk) 21:13, 8 May 2021 (UTC)
Chicken and egg issue. There were a lot more view before {{Wikipedia books}} got deleted. Fix book rendering, {{Wikipedia books}} can be restored, and the views will skyrocket. Headbomb {t · c · p · b} 00:00, 9 May 2021 (UTC)
  • Other publishers make books out of Wikipedia content so it's reasonable for us to have an official way of doing this. Reasons one might do this include:
  • Commemorative or festschrift works such as the collected writing of SlimVirgin.
  • Collections of WikiEd or WIR type activity such as the ongoing Coventrypedia.
  • Collections of a body of work under attack by deletionists
  • Thematic work such as articles written during and about the COVID-19 pandemic.
Andrew🐉(talk) 08:43, 14 May 2021 (UTC)
There are definitely use cases for printing Wikipedia books. Regardless what happens with the Book: namespace it will still be possible to use the Book creator and save said books in user space (or move them to Wikipedia: space). I also wouldn't feel that it's appropriate to keep most of your suggestions in a reader facing namespace which the Book: namespace supposedly is which would make user or Wikipedia space more appropriate. --Trialpears (talk) 13:47, 14 May 2021 (UTC)

HistoryHelper userscript

I made a HistoryHelper userscript. Am I at right place to request a feedback? In short the script can extract diffs from «View history» and «User contributions» pages» into a wiki {{diff2}} tags. -AXONOV (talk) ⚑ 21:07, 12 May 2021 (UTC)

User:Alexander_Davronov, looks cool, installed. Any problems will let you know. -- GreenC 18:30, 15 May 2021 (UTC)

Collection of local information for someone who is new in town

The idea is to make a section in wikipedia that is dedicated to welcome information. Example: an english speaking person is coming to live in Modena/Italy. He/she will have plenty of questions concerning schools, administrations, doctors, restaurants, sports etc. In the wikiyournewtown she/he will find the information they are looking for. — Preceding unsigned comment added by 2001:861:3204:B40:18B5:FDD0:36BE:26B9 (talk • contribs) 06:46, 15 May 2021 (UTC)

There is a separate Wikimedia project called WikiVoyage for tourism. Also see WP:NOTGUIDE. Sungodtemple (talk) 01:46, 16 May 2021 (UTC)
Retrieved from "http://en.wiki.x.io/w/index.php?title=Wikipedia:Village_pump_(idea_lab)/Archive_35&oldid=1110553300"