Wikipedia:Village pump (idea lab)

 Policy Technical Proposals Idea lab WMF Miscellaneous 
The idea lab section of the village pump is a place where new ideas or suggestions on general Wikipedia issues can be incubated, for later submission for consensus discussion at Village pump (proposals). Try to be creative and positive when commenting on ideas.
Before creating a new section, please note:

Before commenting, note:

  • This page is not for consensus polling. Stalwart "Oppose" and "Support" comments generally have no place here. Instead, discuss ideas and suggest variations on them.
  • Wondering whether someone already had this idea? Search the archives below, and look through Wikipedia:Perennial proposals.

Discussions are automatically archived after remaining inactive for two weeks.

« Archives, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34

Trigger warningsEdit

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[1]), 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.

Clark Kerr, 1961 [2]

  • Someone should have warned me there'd be a Trigger warning discussion on this page before I visited it, because every time I see someone proposing trigger warnings I just want to cry. EEng 21:34, 29 January 2021 (UTC)
    I think you're missing a ⸮ there, EEng. 4D4850 (talk) 19:43, 15 February 2021 (UTC)
    What, you think I wasn't serious? EEng 06:42, 2 March 2021 (UTC)
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 (talkcontribs) 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)
  • 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)

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

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 (talkcontribs) 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? --Paultalk❭ 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 (talkcontribs) 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)


Some companies do mandatory vacations for employees to make sure nobody's absolutely required. I wonder if the same concept could be applied here. Or maybe it's general knowledge what the results would be. Enterprisey (talk!) 09:56, 30 January 2021 (UTC)

everything we do here is written down since writing things down is like, the only thing we can do - so I'm not sure how the bus factor could possibly apply. --Paultalk❭ 21:38, 30 January 2021 (UTC)
There are various areas of wiki which would stop functioning properly, or be notably reduced in quality, if one editor left. Of course, the wiki keeps going in any case. ProcrastinatingReader (talk) 21:50, 30 January 2021 (UTC)
Recorded actions don't tell the whole story, in particular why something was done. Enterprisey (talk!) 23:55, 30 January 2021 (UTC)
It is worth noting, however, that I’m not sure this test helps. The only solution to these areas is to recruit more people to take that spot, which are functions of both our general editor recruitment efforts (from non-editors), and our ability to give existing editors permissions needed to elevate their roles. For example, there was a point last year when Primefac took a short break and BRFA grinded to a halt (and TFDH). There’s no solution to that other than more BAG (which, currently, I guess myself and Earwig are quite active), and more competent template editors with general TfD authorisations. Unblock request patrolling tends to be Yamla and another whose username escapes me. Edit filter requests pretty much rest on SoY, as most edit filter managers don’t interact with that venue, and even SoY can only do so much, so that venue is half useless. L235 was responsible for much of the ArbCom clerking I think, and still is somewhat even after election (updating templates and such). Endless list of examples like this, some of these (and others) more effected than others. No real solution to them other than train new editors, but that’s a problem in itself due to general skepticism. Most areas are documented so someone could pick them up with time, but some more obscure areas rely on unwritten conventions (TFDH work for example, and some of TFD in general). ProcrastinatingReader (talk) 00:51, 31 January 2021 (UTC)
Enterprisey, that's an interesting thought! I don't think people would go for it, but I do think there are things we could do better to help make sure Wikipedia doesn't become overly reliant on any one editor.
There are several different realms in which this applies. With regard to maintaining articles/templates/other pages, I wrote the essay Wikipedia:Build content to endure (WP:ENDURE) with my thoughts.
And then there's bots, which I think are by far our weakest link in this area. There are lots of instances where a bot operator retires, and their bot subsequently stops working, oftentimes leading to substantial damage before anyone notices. I've brought this up before and suggested some ideas, but either they aren't workable or no one has bothered to fully implement them. {{u|Sdkb}}talk 17:19, 1 February 2021 (UTC)
So then why not have a backup operator who becomes operator when the operator retires? Then all bots would be in good quality. 🐔 Chicdat  Bawk to me! 12:29, 25 February 2021 (UTC)
  • And yet somehow we lumber forward. Once solution would be that as soon as a given editor manifests themself as high-performing and knowledgeable, we block them. Then we don't become dependent and future surprises are avoided. (Not sure themself is a word but seems to me it should go with "singular they".) EEng 15:32, 2 February 2021 (UTC)
    Or we should just pre-emptively block anyone who tries to edit. If we also deleted all of our articles we would then have a nice tidy encyclopedia. Phil Bridger (talk) 17:18, 26 February 2021 (UTC)
  • Breaks in some of the "big bots" (via their operators) would be the most impactful; we've got a lot of workflows that depend on this client-side work that is one-deep (for example look at this log: Special:Log/pagetriage-copyvio). — xaosflux Talk 15:38, 2 February 2021 (UTC)
the problem with this is that if an editor has a regular area of editing, then they may lose some credibility if they suddenly stop editing for a long period of time. --Sm8900 (talk) 19:22, 15 February 2021 (UTC)
  • I like this idea. All good organizations do something like this, although it's more commonly aimed at systems than people. See for example, Chaos engineering. -- RoySmith (talk) 16:03, 26 February 2021 (UTC)
  • I thought a more common reason for mandatory vacations was to guard against fraud. It is more likely to come to light that an employee is doing something untoward if such employee can't access an employer's systems for a couple of weeks and someone else performs their (I've been trying to avoid using the singular "they" but can't really be arsed any more here) functions. In any case, it's a nice idea that would be completely impractical in an environment where most workers are anonymous. Phil Bridger (talk) 17:14, 26 February 2021 (UTC)

Should the COI edit request queue function more like RfCs?Edit

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 ideasEdit

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:
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 [3]), 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)

Adding "Suggested edits" from Wikimedia Apps to regular WikipediaEdit

There is a useful feature in Wikimedia apps that suggests edits for users automatically. Wikimedia Apps/Suggested edits allows people to casually edit Wikipedia doing all sorts of recommended tasks and community related help, and its ease of use brings me to the conclusion that it would be a very good idea to implement something equivalent on the main site. I recognize that we have features for improving articles according with very different needs, but the automatic nature of Suggested Edits leads me to believe that it would be a convenient tool for those who want to take advantage of it.Tyrone Madera (talk) 07:39, 10 February 2021 (UTC)

Not sure about this one. Adding captions and short descriptions are helpful tasks, but the main type of suggested edits should probably be prose additions. If people on desktop Wikipedia are looking for little tasks to do, there's tons of backlog categories for little tasks. They're not as pretty looking as the mobile suggested edits, but have the same purpose.
For desktop users, User:SuggestBot/Requests is cool. Or, for smaller stuff, try Wikipedia:Task Center. ProcrastinatingReader (talk) 08:50, 10 February 2021 (UTC)
Tyrone Madera and ProcrastinatingReader, the WMF is actively working on doing so; it's just rolling out to mobile and to some other languages first. See mw:Growth/Personalized first day/Structured tasks and some of the Growth team's other work. {{u|Sdkb}}talk 21:25, 10 February 2021 (UTC)
Sdkb, I see no intention on the part of the WMF to do so in the article you sent. I have only seen mention of mobile and non-English languages, and none about mainstream Wikipedia. Tyrone Madera (talk) 21:42, 10 February 2021 (UTC)
Tyrone Madera, it's very typical for new features to be rolled out to small wikis first to beta test. They're then brought here once they're more fully developed. The WMF folks have communicated that this is their plan on talk pages, which you'll find if you poke around MediaWiki a bit. {{u|Sdkb}}talk 21:45, 10 February 2021 (UTC)
Tyrone Madera --
Newcomer tasks feature in Czech Wikipedia
I'm Marshall Miller; I'm the product manager for the WMF Growth team. As Sdkb said, we're thinking along the same lines as you are: that Wikipedians on the web could benefit from a feed of simple tasks to do. It's helpful to hear that other people have that idea, because it reinforces that we might be on the right track with our work. What we've built so far is "newcomer tasks": a feed of articles that have maintenance templates saying that they need things like copyediting, wikilinks, or references. One way to think about it is that it takes the sort of articles that ProcrastinatingReader is talking about, and puts them in a feed that can filtered by topic of interest (see image. We've run experiments in smaller wikis showing that having this feed increases the engagement of newcomers, and so we're quickly spreading it to more wikis so they can benefit.
Going forward, we're adding a new kind of task. Instead of relying on maintenance templates, we're introducing algorithms that can identify articles that might need attention, and make suggestions for changes. The first one is for adding wikilinks, which we're building now (see image). We're also doing the beginning planning around one for adding images.
Plans for "add a link" structured task
And like Sdkb said, we do build our features to work on both desktop and mobile web browsers. It's just that we talk about mobile more because it is a bigger design challenge, to get the same functionality on the smaller device. And eventually we want our team's features to be available on all wikis -- but we learn first on smaller wikis. Right now, they're on 18 Wikipedias, including some big ones like French and Russian. I've actually started a project page and discussion here on English Wikipedia, so that this community can start thinking ahead to having the Growth features (that page is due for some updates from me).
Anyway, I hope that anyone watching this page can join in the discussion either here on English Wikipedia or on ProcrastinatingReader, I would definitely be interested to hear what you think about structured tasks. -- MMiller (WMF) (talk) 23:57, 10 February 2021 (UTC)
Sdkb, I apologize for being brusque in my response. Thank you for bearing with me, and thank you MMiller (WMF) for adding explanation, answering all of my questions, and responding so politely. I can't wait for this new feature! Tyrone Madera (talk) 02:14, 11 February 2021 (UTC)
@MMiller (WMF): Apologies for the delayed response. I think structured tasks, as a concept, is a great idea. I think starting out with a blank page is intimidating. I also think adding sourced content, when one has no idea about the MOS or all the other complex policies we have around here, can sometimes be difficult. Some editors will just revert something that looks ugly (ie, violates MOS) from a new editor, rather than clean it up and make it decent. That's just one example. I suspect a lot of people have knowledge to add but not the time or interest to get deep into Wikipedia to get it in the right format, so don't bother adding at all. Anyhow, if you guys can somehow lower the barrier for editing by using structured tasks I think that may be a big + for editor recruitment.
However, the screenshots on the right are not that. Tasks like adding links etc are not well done without context of the bigger picture. See WP:LINKRELEVANT / MOS:OVERLINK etc. People could just be adding links which, yes link to the right article, but shouldn't be linked. And some MOS style suggests only the first link should be linked, and the rest not. The challenge here is that the 'bigger tasks' (adding sourced content, copyediting, etc) seem to be difficult to create into structured tasks. But I admit I haven't spent much time thinking about how they could be. If you could figure it out, that would be a great feature. There's probably some more content-focused editors compared to me who may have better ideas on how this can be achieved. ProcrastinatingReader (talk) 12:11, 23 February 2021 (UTC)
Hi ProcrastinatingReader -- thanks for thinking critically about these ideas. I'm glad you think that structured tasks are generally on the right track -- that's the first step! I agree that there are lots of potential pitfalls around users having sufficient context and understanding policies. Many community members have been pointing those issues out as we go along, and we're doing our best to build in the appropriate guardrails to make a safe and productive experience for newcomers. For example, you mentioned that the algorithm could suggest links that shouldn't be made. The algorithm is built to incorporate that concern in that it is trained on existing wikilinks, so that it has a sense of which sorts of words and phrases tend to be linked. And for when it's incorrect, the full workflow has guidance and onboarding for the newcomer so they can evaluate the suggestions with some guidelines. With the example about only linking for the first occurrence of a word in an article, that's also built into the algorithm. I know we won't solve for everything, but we want to take a good first stab, get a sense of how newcomers do with this task, and start learning how to improve. We'll be piloting this on just a few wikis first (Arabic, Vietnamese, Czech, and Bengali), and so this will manage the risk. At the same time, though, I would like to start the discussion about bringing these sorts of features to English Wikipedia eventually. I'm starting that here, and I hope that you can watch or join in! -- MMiller (WMF) (talk) 21:13, 26 February 2021 (UTC)

Linking cited papers to Connected Papers graphsEdit

I thought it might be useful for wikipedia to add a link in the Works Cited section to the Connected Papers graph of each journal article. Connected Papers finds and visualizes similar papers to the one in question. I think this would make it easier to use Wikipedia as a resource in an academic research setting. They have recently integrated with arXiv and seem likely to support FOSS projects like wikipedia, or at least support us linking to them. TripleShortOfACycle (talk - contribs) - (she/her/hers) 05:49, 12 February 2021 (UTC)

@TripleShortOfACycle: your proposal is to do this for each cited paper, right? That is an interesting idea, though I'm not sure how in-line it is with general citation styles. Elliot321 (talk | contribs) 01:14, 18 February 2021 (UTC)
@Elliot321: Yes, the idea would be to link to a graph for any paper that has a DOI included in its citation. I'm not entirely sure about how to go about setting something like that up though. TripleShortOfACycle (talk - contribs) - (she/her/hers) 07:44, 18 February 2021 (UTC)
@TripleShortOfACycle: it's quite an interesting idea, but I think it would be quite controversial - people can be touchy about citations, sadly. Elliot321 (talk | contribs) 07:59, 18 February 2021 (UTC)

Idea: discussion callout templatesEdit

Basically, templates that can go inline to call out a comment or particular groups of comments.

Discourse forums have something where an admin can post a message about a comment to everyone.

Suppose Alice opens a deletion nomination for article "Foo" and Bob writes something like "I like foo". A callout can provide a gentle reminder to remain on topic/stay civil. Of course, if it happens multiple times, then we can just use the uw series.

So the discussion would look like this:


Foo (edit | talk | etc.)

Does not meet the notability guidelines. Alice (talk) 00:00 1 January 1970 (UTC)

Foo is an amazing shaving cream that I would love to buy. Bob (talk) 00:15 1 January 1970 (UTC)
Have you tried their shaving cream? I love it. Charlie (talk) 00:19 1 January 1970 (UTC)
I could not afford it, but I think this shaving cream is notable enough that we should have it on Wikipedia. Bob (talk) 00:22 1 January 1970 (UTC)
  Please remember to stay on topic. Admin (talk) 00:25 1 January 1970 (UTC)
This article was written by a dummy, so I'd say delete. I am angry (talk) 00:15 1 January 1970 (UTC)
Yeah, look how fat this contributor is. Another angry user (talk) 00:17 1 January 1970 (UTC)
They are obviously a WP:SPA. Always suspicious (talk) 00:18 1 January 1970 (UTC)
  Please remember to assume good faith and stay civil. Admin (talk) 00:20 1 January 1970 (UTC)

I think this would be a good option before page protection if a discussion gets derailed or off topic fast. Sometimes, even a great proportion good faith contributors make mistakes and may get off topic or uncivil, so giving a gentle reminder when the discussion gets heated can cool these discussions back down. Aasim (talk) 22:11, 12 February 2021 (UTC)

  • No thanks. These templates would be cold, patronising and impersonal – editors should compose these messages in their own words. This essay gives a further overview of the problems with these sorts of templated messages. – Teratix 02:00, 13 February 2021 (UTC)
    • The goal is to give gentle reminders which is difficult to do if the discussion becomes heated. The goal of callout templates is not to bite or assume bad faith but to remind all editors about general wiki and forum ettiquette, especially if the discussion is, well, heated and derailed. These callouts would even be useful to remind a large group of new editors our purpose.

I think we should add information about how good the service is to this article. Spammer (talk) 00:25 2 January 1970 (UTC)

  Please remember to adhere to the purpose of Wikipedia when commenting. Admin (talk) 00:25 2 January 1970 (UTC)
Clearer? Aasim (talk) 07:01, 13 February 2021 (UTC)
      • I understand these templates are intended to be gentle reminders, but they will not be perceived as such. – Teratix 23:11, 14 February 2021 (UTC)
      • Putting a box around these makes them sound far stronger and more aggressive. It would be better to have just written a custom comment, if indeed it was worth making. In most cases above, making the callout was undue, and should have waited for more off topic/scope first — Preceding unsigned comment added by Graeme Bartlett (talkcontribs) 00:24, 15 February 2021 (UTC)
  • Awesome Aasim I don't think involving more templates in discussions is a good idea. And admins don't have more power in discussions than any other users. Elliot321 (talk | contribs) 01:13, 18 February 2021 (UTC)
    • I don't feel like the admins would like this much, either. I'm thinking that there might become a backlog of "Stuff the admins must put callouts on." We already have quite enough backlogs. 🐔 Chicdat  Bawk to me! 11:30, 27 February 2021 (UTC)

Monthly articles for all years since 1990Edit

(This might have been proposed before. Also, if this idea is in the wrong place, please tell me where I should put it.)

In each year article from 1900 to 1989*, the events section links to detailed monthly articles for each month, each of which in turn lists several events for each day therein (as well as the corresponding day of the week). Meanwhile, for all the year articles from 1990 to 2021*, the events section is merely a sparse listing of various occurrences, with no monthly articles at all (each monthly title is a redirect to the appropriate subsection of the events section). However, the period since 1990 has been hardly lacking in historically important events. To fix this discrepancy, I propose that, for each year since 1990 to the present, monthly articles should be created for each month, with content for each day. This would greatly improve our historical understanding of recent & important events.

*At least I think so. I haven't bothered to check every article, but this seems to hold for every one I've visited.

Duckmather (talk) 18:08, 15 February 2021 (UTC)

You don't need to ask permission to create articles. If you think you have enough material to write a stand-alone September 1997 (or whatever) article, you can just go ahead and do it. ‑ Iridescent 20:18, 15 February 2021 (UTC)
There is no such article for any month from 1986 to 1989. April 1985 is the last. Portal:Current events/Events by month has links to portal pages about every month from July 1994. The months only transclude daily pages like Portal:Current events/1994 July 2. At Wikipedia talk:WikiProject Years/Archive 11#Using archives of Portal:Current events for month articles it was decided to not show them in mainspace. PrimeHunter (talk) 08:25, 16 February 2021 (UTC)
Thank you for the reply! I'm going to shelve this idea because it's already been discussed to death, and consensus seems to indicate that yearly articles are enough. (My dad tells me that these monthly articles have questionable historical significance anyways.) Duckmather (talk) 20:36, 19 February 2021 (UTC)

Democracy of wikipediaEdit

I wondered if, even if it is possible, that discussions that occur, like changes to Notability, that editors are notified to make Wikipedia more democratic? At the moment it seems that when policy changes are being discussed and made, it seems to be the same small band of editors, and in most cases most editors don't know it is actually happening.

My idea is that when policy is being discussed all editors get a discussion notification, and at the end of the discussion all editors get a notification to vote. Once the vote has been completed then the notification is sent to all editors to let them know of the change, if any, to policy.Davidstewartharvey (talk) 06:59, 16 February 2021 (UTC)

Any proposed major change already gets listed on {{Centralized discussion}} which in turn appears at the top of over 5000 noticeboards and policy pages (including this one); it's not as if we're hiding discussions to keep them the preserve of a clique of insiders. At any given time, we have a lot of Requests for Comment ongoing (these are just the currently-open ones, and posting notifications of all of them to all 41,083,203 editor talk pages would totally flood Wikipedia; there isn't a practical way to only notify of the major ones, since no two editors will agree on what constitutes "major". If you want to increase the likelihood of your being notified about proposals in particular areas, add your name to the relevant sections at Wikipedia:Feedback request service. (For what it's worth, Wikipedia's definition of "notability"—significant coverage in reliable sources that are independent of the subject—has been unchanged since May 2007, and is one of the few things on Wikipedia which is never seriously challenged; changing it to even a minor degree would have such a huge knock-on effect on Wikipedia's existing content as to be unworkable.) ‑ Iridescent 07:45, 16 February 2021 (UTC)
We could advertise T:CENT discussions on watchlists, like RfAs? In a streamlined columns way (eg 3 items per row), so it's not too crowded. Usually not more than 5 enwiki CENT discussions running at a time. Not saying it's a good idea, but just a thought. Btw, surely we don't have 5000 noticeboards and policy pages? ProcrastinatingReader (talk) 14:13, 16 February 2021 (UTC)
A lot of that 5000 that have T:CENT transcluded are archives rather than active noticeboards, but if anything we probably have more like 10,000 active noticeboards. There are thousands of de facto "anyone who's interested in the topic is going to have this watchlisted" noticeboards like WikiProject talk pages and high-traffic article talk pages like Talk:Joe Biden. If there were a way to restrict who it was shown to, I think putting T:CENT at the top of everyone's watchlist would be a good idea, but if and only if we could restrict it so it wasn't shown to everyone (maybe the 500 edits and 30 days threshold we already use elsewhere?). One lesson the watchlist notice for RFAs has taught is that it can be counterproductive to invite brand new editors to participate in discussions on complex issues, as they make good-faith comments, get slapped down for failing to understand the issues, and in turn get demoralised and quit, and a lot of the issues that come up at T:CENT are quite inside-baseball. ‑ Iridescent 15:43, 16 February 2021 (UTC)
Technically speaking, at least, I think it might actually be possible to limit it to showing for ECP only. Usually you can add a class “sysop-show” or “autoconfirmed-show” to things to hide them from everything but that group. There’s probably one for ECP too. ProcrastinatingReader (talk) 16:31, 16 February 2021 (UTC)
Ah, yeah, “extendedconfirmed-show” exists in mediawiki:Group-extendedconfirmed.css, so that’d probably work. ProcrastinatingReader (talk) 16:35, 16 February 2021 (UTC)
I'd support only showing it to ECP users. We probably don't want too many newbies stumbling into these discussions, but it's better for more people to find out about them. Elliot321 (talk | contribs) 01:09, 18 February 2021 (UTC)
There's definitely room for improvement in this. Yes, super major changes might make it to centralized discussion, but let's not pretend that all discussions get the amount of discussion they deserve. There's definitely some RfCs and changes that set precedent that are done in backwater places with an element of "gaming the system" at play. One thing that we need to improve upon is reprimanding editors that appear to be doing this. Jason Quinn (talk) 12:55, 16 February 2021 (UTC)
I'm not sure how you plan to determine which editors are gaming the system and which are just raising it on the most applicable (but less viewed) pages. There isn't a clear marker on which discussions belong on the central hub and which on their relevant policy/guideline talk pages. Nosebagbear (talk) 00:50, 18 February 2021 (UTC)
Very impacting RFC's are also added to the watchlist notice, generally related to major changes that affect large numbers of editors. Inclusion criteria is subjective, but in general WLN's about RFC's are more stringent then for T:CENT. (e.g. Special:PermaLink/975679275 from a few months ago. — xaosflux Talk 20:19, 18 February 2021 (UTC)

Second Opinion Symbol ConceptEdit

Over at WP:GA they have support symbols ( ), oppose symbols ( ), and on-hold symbols ( ) to represent the various results of a good article review. However, one neglected result is asking for a second opinion, which currently is represented with a neutral vote ( ) which I believe does not make much sense and doesn't convey much. I propose an icon similar to one like this; forgive the terrible art, I made this on Chrome Canvass with a mousepad. Panini🥪 14:17, 16 February 2021 (UTC)

To clarify for folks, if I understand correctly, this would only affect the Wikipedia:Good_article_nominations queue. You can see how it currently looks by going to that page and searching for the words "Second opinion" (there's one at the top of the World history queue now, but who knows if it'll be resolved by the time you read this). I think it's a nice idea. Ajpolino (talk) 20:34, 16 February 2021 (UTC)
Panini! I like the idea of a question mark too, though obviously it should be drawn with a bit more, uhm, accuracy than what you did. Elliot321 (talk | contribs) 01:07, 18 February 2021
Well, no duh, it was just a concept. Panini🥪 02:00, 18 February 2021 (UTC)
Great idea! How to find people to make it into a proper symbol? FemkeMilene (talk) 20:56, 18 February 2021 (UTC)
  • DYK uses {{DYK?again}} to request another review(er). The symbol is  .
There are also lots of symbols on Commons such as File:SegundaOpinión-Artículo bueno.svg which was intended for this purpose. It doesn't work so well at the size of the other icons – 16px:  
Here's how it looks at 128px:
Andrew🐉(talk) 21:43, 18 February 2021 (UTC)
I'm not sure how helpful such a symbol would actually be, but repurposing the DYK icon that Andrew pointed out seems like a good solution. The issue I have with the Panini's proposed image is that—when used at the same px size as support and oppose symbols—the 2 and ? would probably be too hard to see. Aza24 (talk) 02:46, 22 February 2021 (UTC)
Well, how about this? 🐔 Chicdat  Bawk to me! 11:20, 27 February 2021 (UTC)

Wikivoyage Mobile AppEdit

Wikivoyage is one of the best projects of Wikimedia. In last days, I'm so concentrated to develop the new opened Turkish Wikivoyage page. And I think, an official mobile app for Wikivoyage is a good idea. It can be perfect for the travelers around the world. The people mostly use their smart phones during traveling. This project will not make much sense if there is no app of WV.UcuncuUlus (talk) 13:27, 20 February 2021 (UTC)

That is a separate project from Wikipedia, and so it should be discussed there instead. According to Wikivoyage Community Portal [4], feature requests go into phabricator [5]. There is also the "Traveler's Pub", which looks to be like the Wikipedia Help Desk, so maybe try there first [6] RudolfRed (talk) 21:11, 20 February 2021 (UTC)

Regarding falseblocks under SockblockEdit

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)

Idea for new possible skinEdit

Since I started using Ubuntu, it has seemed like an interesting idea to have a skin on Wikipedia that makes Wikipedia look like a command prompt or a terminal. I know it probably won't get implemented, and even if it gets implemented, very few people will use it, but it seems like an interesting idea. 4D4850 (talk) 01:27, 24 February 2021 (UTC)

What do you mean by "look like a terminal"? If you just want fixed-width fonts and no graphics, just install Lynx; you don't need to mess around reskinning websites. ‑ Iridescent 05:33, 24 February 2021 (UTC)
Ok, that is basically what i was imagining. Thank you. 4D4850 (talk) 16:26, 24 February 2021 (UTC)
4D4850, Also, Wikipedia:Wikipedia-mode.el for the truly hard-core. -- RoySmith (talk) 13:29, 25 February 2021 (UTC)

i would like a article on Tim's reinforced slingshotEdit

this is the reinforced slingshot though is also available on MyMiniFactory — Preceding unsigned comment added by Tim3dPostma (talkcontribs) 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)

Adminbot for WP:U1Edit

Curious if anyone has considered writing a bot to automatically handle many WP:U1 speedy deletions? To prevent abuse, it should make sure that the page was either created in the user's userspace, or never edited by anyone other than the user (so someone couldn't move a page to their userspace to get it deleted, or U1 an article they created but others had built). This could significantly speed up U1 and leave admins to do things more useful. Elliot321 (talk | contribs) 02:31, 25 February 2021 (UTC)

You might want to check out 7SeriesBOT. If you're a glass-half-empty type of person, see this instead. -- zzuuzz (talk) 03:16, 25 February 2021 (UTC)
Ah, interesting, didn't realize such a bot existed. Elliot321 (talk | contribs) 06:46, 25 February 2021 (UTC)

Allow all users to view only their own deleted contributionsEdit

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)
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)

Bringing back the GA CupEdit

Congratulations! Your GA has been approved!-EEng

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)

Talk pages redesignEdit

I tried looking through the archives and couldn't find something like this, so I'm posting here.

In my opinion, the whole talk page format needs to be radically redesigned. It is just plain difficult to use. For one, an editor needs to use source code to be able to participate in a talk page, which is a high barrier in terms of time (inputting the proper syntax correctly) and knowledge (source editing is not intuitive).

Four big issues I see:

  1. There is no easy way to input a comment and add it. Most other platforms you can type something in, click submit, and voila- you commented. On Wikipedia, you need to wade through the text and find where to write something, how to indent it, etc.
  2. No nesting of comments. There is no way to easily find who said what in a talk page discussion, and this is especially problematic for long comments, improperly indented comments, etc. It also makes reading through a long page quite cumbersome.
  3. No automatic signatures or notifications. If I make a comment, I would expect it to say that I wrote it and also to notify anyone else. Right now both those functions require someone to know how to do so and to take the time to add a ping, signature, etc.
  4. Source editing. As mentioned above, it's a high barrier in time and knowledge.

In an ideal world, I'd see the talk pages look more like Reddit or any other platform with discussion boards. A short-term solution would be to enable Visual Editor, which is currently not enabled on Talk pages.

I know I can't be the only one who has noticed shortcomings with the Talk page format. What are your thoughts on Talk Pages and how they could be improved?

Fredlesaltique (talk) 14:04, 27 February 2021 (UTC)

@Fredlesaltique: There is mw:Talk pages project/Replying, which is being worked on, where you can reply in the visual editor and (I think) add signatures automatically which should address #1, #4, and part of #3, with the visual editor having a button to add a ping to a user. Terasail[✉] 14:56, 27 February 2021 (UTC)
See also an example of Flow here: mw:Talk:MediaWiki - while it addresses some of your concerns it bring forth a whole new set of problems. — xaosflux Talk 15:59, 27 February 2021 (UTC)

Encourage and switch raw Infobox data to to WikidataEdit

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 (talkcontribs) 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 (talkcontribs) 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)

Rfc: More informative edit changelogEdit

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/rollbackEdit

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)