:I'm interested in @[[User:Z1720|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. [[User:WhatamIdoing|WhatamIdoing]] ([[User talk:WhatamIdoing|talk]]) 04:36, 10 February 2021 (UTC)
:I'm interested in @[[User:Z1720|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. [[User:WhatamIdoing|WhatamIdoing]] ([[User talk: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. [[User:Z1720|Z1720]] ([[User talk:Z1720|talk]]) 14:54, 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. [[User:Z1720|Z1720]] ([[User talk:Z1720|talk]]) 14:54, 10 February 2021 (UTC)
===Reply by OP: consolidated list of ideas===
First of all, thanks to everyone who weighed in here with a comment. I didn't know if this would find much interest, but I'm glad to see that a number of others agree that the current process could be improved upon, with many different ideas suggested.
Having read through them all, I am persuaded that a straight "RfC but for COI" is not the right approach—but the COI process could stand to incorporate some things that other projects are doing. Here is a consolidated list of suggested ideas, a few of which were mentioned favorably by multiple respondents, with short explanations where helpful:
'''Clearer guidance for COI editors'''
*''List common mistakes and corrections''—Some aspects of WP:PSCOI do this, but not clearly enough
*''Point COI editors to Edit Request Wizard (ERW)''—From guidelines and advice pages, and perhaps elsewhere
'''Suggest improvements to ERW'''
*''Integrate with Template:Edit request''—An obvious oversight that should be easy enough to correct, good catch by {{u|Izno}}
*''Build out ERW around common request scenarios''—Building on a point made by {{u|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 {{u|Z1720}}
*''Leaderboard to recognize active editors''—Suggested by {{u|Sphilbrick}}
'''Improve Edit request template in a few ways'''
*''Add a TLDR summary parameter for possible transclusion''—As noted by {{u|Schazjmd}} and {{u|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 {{u|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 {{u|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:
#If I left out an idea you think is important, by all means feel free to make the case for it in reply here. :)
#Any points of clarification or additional information to add about specific ideas mentioned above?
#Are there specific ideas in the above that editors weighing in here are experienced with or feel qualified to actively work on?
#Any suggestions on how some or all of this could be effectively proposed on Village pump proper?
Thanks in advance, [[User:WWB|WWB]] ([[User talk:WWB|talk]]) 17:45, 12 February 2021 (UTC)
== Adding "Suggested edits" from Wikimedia Apps to regular Wikipedia ==
== Adding "Suggested edits" from Wikimedia Apps to regular Wikipedia ==
Revision as of 17:45, 12 February 2021
Section of the village pump where new ideas are discussed
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:
If you're ready to make a concrete proposal and determine whether it has consensus, go to the Village pump (proposals). Proposals worked out here can be brought there.
Before commenting, note:
This page is not for consensuspolling. 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.
I think re-implementing WikiMoney and the related services could be cool. What if you could use WikiMoney to buy some cool things like a "Golden Barnstar" to give to exceptional work. — Preceding unsigned comment added by Education-over-easy (talk • contribs) 14:25, 11 January 2021 (UTC)[reply]
I feel like the introduction of WikiMoney would be followed by WikiCorruption, WikiLobbying, and WikiBribery in today's Wikipedia. Basically, gamification of community goodwill can create perverse incentives. Ask Reddit how well their karma system has worked out. - NovovTC08:38, 15 January 2021 (UTC)[reply]
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)[reply]
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)[reply]
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.
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)[reply]
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. EEng21:34, 29 January 2021 (UTC)[reply]
WP has a problem with hundreds of pages of non-notable fake nobility
Many nations in Europe have abolished their nobility. The people who would hold this titles, or claim they would, often have articles here calling them "Prince" and "Duke."
But they are not princes or dukes, because they are not children of sovereigns or the head of a dukedom.
I conservatively estimate there are more than 500 similar pages of people who are not notable, and only here because they claim to have royal or noble titles. It could four times this amount.
Of course a pretender could be notable because they have widespread political support for restoration. Or they could be notable as a scientist, author, etc. But rarely is this the case here.
My view is that (1) most of these articles should be deleted (2) the remaining ones the royal title like "prince" should be deleted from the article name.
Someone made a similar suggestion here in 2013:
RfC notice - proposed guideline in the Manual of Style with reference to applying "royal titles" to living members of deposed royal families
I have opened a RfC about a proposed guideline for the attribution of "royal titles and styles" to members of families whose ancestors were deposed as monarchs from various countries, often many years ago. At the moment many WP articles about these persons attribute "royal titles" to them in what seems to me a very misleading way. Please join in the discussion at Wikipedia talk:Manual of Style/Biographies "Use of royal "Titles and styles" and honorific prefixes in articles and templates referring to pretenders to abolished royal titles and their families" Smeat75 (talk) 04:45, 27 November 2013 (UTC)
@Declanscottp, usually, our notion of notability isn't closely related to political support or real-world value. It's focused on whether you get attention from the world at large. If you are a sufficiently interesting claimant, then you get written about in the media, and then Wikipedia editors are able to write an article about you. See, e.g., Emperor Norton, who claimed a non-existent throne. If you are not interesting, then nobody writes about you, and then Wikipedia editors aren't able to write a neutral encyclopedia article about you. We aren't trying to limit Wikipedia to legally recognizable royal people. We're trying to expand Wikipedia to whatever subjects the world has chosen to pay attention to, including fake royalty with absolutely no chance of ever being placed in a position of power. WhatamIdoing (talk) 02:42, 26 January 2021 (UTC)[reply]
@Declanscottp: I hope that you wouldn't be contesting notability with every self-titled Duke, King, Queen, Prince, Count, Lady, Sir, or even Chairman. In seriousness, I think it would be best to do individual AfDs for non-notable biogs (Princess Béatrice seems a ripe candidate for deletion), but whether or not their title is "real" probably isn't the argument to go for - I wouldn't personally say that any titles are more "real" or "fake" than any others, they're all equally made up - but WP:NOTINHERITED would be relevant in a lot of these cases. --Paul ❬talk❭ 11:55, 26 January 2021 (UTC)[reply]
@WhatamIdoing:@Paul Carpenter: Responding to both these points - A small number of these people are notable for reasons beyond their fake titles. Regarding media coverage, a lot of these articles do have a few random references. But they are generally of the "Princess Betty showed up to the charity ball in a stunning dress" or "Princess Betty married Duke John." I don't think that's enough to be notable. Tons of people are written about in wedding announcements. Second, even to the extent these people are notable, the decision to title an article "Princess Beatrice" when their own government does not recognize their title is highly political: it implies the decision to abolish the nobility taken by Italy, Austria, France, etc was not legitimate. As a matter of French Law, there are no longer any French princes, dukes, etc. They are all pretenders, and should be labeled as such, not given titles. It isn't a case like Emperor Norton, whose title is obviously a joke, or actual celebrities with chart topping songs. The people who are fake royals in Europe often believe as political matters believe their republican governments are illegitimate. Giving them noble titles in their articles and article titles, and using their claimed status as a factor for notability, is making a political statement against those republican governments. We would not disrespectfully name Prince Charles's article "Charles Mountbattan" because the UK is an actual monarchy. I see articles about various French "Dukes" and "Princes" like this as equally bad as this. France, again, simply has no dukes or princes. They are both disrespectful and misleading. https://en.wikipedia.org/wiki/Prince_Charles-Philippe,_Duke_of_AnjouDeclanscottp (talk) 00:42, 29 January 2021 (UTC)[reply]
On the point of names, per WP:COMMONNAME we use whatever name they would most easily be recognised by - regardless of the officialness of that title. Which is why we don't add sir to the page title for everyone who's technically been given a knighthood or whatnot.
On the point of notability i.e. whether they should have an article or not, you're quite right that "so and so wore a dress and married cousin whatshisface" does not qualify as WP:SIGCOV and if that's all the references an article has got: it should be deleted via WP:AfD. But as WhatamIdoing says, that's not much to do with the 'realness' or lack thereof of their 'title'.
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. --Paul ❬talk❭ 21:38, 30 January 2021 (UTC)[reply]
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)[reply]
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)[reply]
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}}talk17:19, 1 February 2021 (UTC)[reply]
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".) EEng15:32, 2 February 2021 (UTC)[reply]
We currently have bundled cites like #1 in QAnon. This is arguably not good for a couple reasons:
wrong citation count.
unnecessary complexity in a reference.
difficult to normalize and canonicalize for tools and data gathering.
difficult to cite one (or a few) from the bundle somewhere else in the article.
However, it's also not great to have "Foo bar baz.[1][2][3][4][5][6][7][8][9][10][11][12][13][14][15]". In some citation styles they use ranges on consecutive numbers above a certain threshold (e.g., [1-15]). The numbers might not always be completely consecutive, but for the one's that are they can be bundled. This would need to be done at the MediaWiki layer. Thoughts or other ideas? -- GreenC13:49, 4 February 2021 (UTC)[reply]
At the highest level this could be achieved (a) by having the citation software aggregate/serialize consecutive citations (i.e. [1][2][3] becomes [1-3]) and (b) from there, strongly encouraging editors to not bundle citations together in one <ref></ref> set. This would be a good idea for a community wishlist project (alas the 2021 cycle just passed). Harej (talk) 16:07, 4 February 2021 (UTC)[reply]
Harej, that's a really interesting idea! One question: what would we want to happen for reused citations alongside others, such as "Foo bar baz.[47][6][48][49]"? {{u|Sdkb}}talk20:24, 4 February 2021 (UTC)[reply]
We already have WP:OVERKILL for part b. Editors concerned with Lots of Citations in A Row should reduce reference groups at issue and then have the inevitable discussion. (And/or we should not cover contentious topics the way we do, which is almost always how OVERKILL situations arise.) --Izno (talk) 02:27, 5 February 2021 (UTC)[reply]
Because we are where the page author(s) feel they have no other option. You seek to change consensus on the point in some way... Another thing that is done is adding an explanatory footnote using {{efn}} which embeds regular reusable footnotes, usually with some explanation for each particular footnote; we might consider that as a preferable option to bundling. --Izno (talk) 06:48, 6 February 2021 (UTC)[reply]
There can be some valid uses for a bundled cite. For example, in Going steady, I bundled a cite to a paper with a cite to the errata for that paper; as a separate ref, readers might not notice that corrections had been made to the original paper. Schazjmd(talk)20:34, 4 February 2021 (UTC)[reply]
I know this has been discussed before. I do not see a Phab task. I do not understand where you think the anchor will lead when someone clicks on a 1-15 reference. Right now the blue highlighting that comes with a selected reference is also a feature that would necessarily be lost for the references which aren't whichever reference you select as being the desired target in such a case. --Izno (talk) 02:27, 5 February 2021 (UTC)[reply]
Presumably it would jump to the first cite in the list since they are consecutive. Even better highlight them all as a block. When clicking [1-15]. -- GreenC22:10, 5 February 2021 (UTC)[reply]
Even better highlight them all as a block. When clicking [1-15]. This is not possible. Only the targeted reference can be turned blue. Are you sure you want it to be the first? There was a big hullaballoo because AWB was reordering citations in a row (since removed). I imagine "going to the first" will have a similar issue. --Izno (talk) 06:48, 6 February 2021 (UTC)[reply]
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Respected Wikipedia Admins,
I would like to bring a new and essential feature to your notice which needs to be added in Wikipedia.
But before that, I would apologize for excessive trolling which I did on #wikipedia-en-help and #wikimedia-commons(Kiwi 🥝 IRC Channels). Now, I am myself exhausted after repeated trolling that I don't like to troll any more.
The feature is related to in-article search. You might have seen, when you open .pdf or .docx or .pptx file using certain apps, there is a feature through which you can search a particular word in the article.
For e.g., when you open a .pdf file using Chrome app, there is a search bar on top of the page where when you search a particular word and as you press enter, wherever the word it there in the article, it gets highlighted by a particular colour so you can refer it easily.
I am requesting to you to add this feature because I have seen there are certain users who edit articles without selecting "Watch this page" checkbox☑️. As a result, it becomes difficult to locate their edit if it is minor and the article is too big. And it might happen that those edits by the users might not be up to the marks and might need to be reverted. However, in such cases, the task becomes difficult. In such cases,we have to read entire article to locate it.
Thus, am requesting you to add a feature of word search in the article itself which will make location of a particular word easy. Secondly, it will be beneficial for readers who wish to find information on a particular topic.
It is my humble request to you to ask the respective Wikipedia developers to add this essential feature asap.
@Akshat2103: if I understand you correctly, you would like to find some text on a page, just as you can in other documents. Using your example, the ability to search the text of a PDF isn't coming from the pdf itself, but from the pdf viewer. Likewise, most modern browsers you would use to view articles already have this functionality. For example you mentioned the Chrome browser. Chrome offers "find in page" capability already, for desktop you can usually press CNTRL-F to pop open the control for it; on mobile Chrome it is usually in the "..." menu called "Find in page". Does that help? — xaosfluxTalk19:52, 4 February 2021 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Turning the sidebar into a horizontal navigation menu
Many websites such as W3Schools for example have a navigation menu at the top rather than on the left. I think Wikipedia would look a lot better if it had one on top above the links. I'm not a coder, but I could sketch out what exactly the new navigation menu would look like. I would like to hear from Sdkb for thoughts on this and would like to know if it has been discussed before. Thanks, Interstellarity (talk) 20:03, 4 February 2021 (UTC)[reply]
I don't know of this being discussed before. It would entail a full redesign of Vector, which would be a very big undertaking probably better handled by the WMF as professionals (in consultation with us) than by us as volunteers. {{u|Sdkb}}talk20:20, 4 February 2021 (UTC)[reply]
New Vector removes the sidebar in lieu of the "hamburger" icon, which makes the entire sidebar a dropdown. I presume that is preferable. (I certainly see it as so.) --Izno (talk) 02:29, 5 February 2021 (UTC)[reply]
Given the forthcoming redesign there's no benefit to this. The WMF is determined to enforce a maximum display width in the future which will mean that except on the narrowest of monitors such as using desktop view on a phone, the article text will already be surrounded by white space (see French Wikipedia for what it will look like). In that context, getting rid of the sidebar wouldn't have any benefit to readers, it would just mean even more of the page being taken up with useless white space. Bear in mind also that replacing the current always-displayed links with drop-down menus poses accessability issues both to people using screen readers or other navigation software, and to people who aren't necessarily going to be aware of how the menus work. (Wikipedia has a very broad readership of all different levels of technical knowledge and experience; you'd be surprised how many people are unaware that the hamburger icon leads to further options.) ‑ Iridescent05:13, 5 February 2021 (UTC)[reply]
You can see the new design at w:fr:Gâteau breton. Click the ☰ or ≪ at the top by the Wikipedia globe to see how the sidebar is handled. It might be worth checking that you have your web browser set to zero zoom, if you want to see the fixed-width aspect. If you tend to zoom in a bit on a normal laptop, then it might not be visible. Note that the width depends significantly upon your device and settings. This is about 25 cm on the main designer's screen, and about 18 cm on mine (with default zoom). Whatamidoing (WMF) (talk) 20:08, 5 February 2021 (UTC)[reply]
Require editors to acknowledge WP:POLICY before saving their first edit
There are a lot of editors who are WP:NOTHERE or don't know what WP:NOTHERE means. We can't do much about those who KNOW they are here for the wrong reason, but I have an idea that will help those who are ignorant or those who might be WP:PAID but who really want to "play by the rules" but don't even know there are rules they must play by:
For users who bypass that screen, add the check-box and link to the editing window but only for their first edit.
Do the same for non-logged-in editors, except for every edit or at least every edit in a single "editing session" (i.e. until cookies are flushed or they expire).
This would probably lose us more positive edits than reduce the negative ones we must deal with as a matter of course. A non-starter. --Izno (talk) 02:30, 5 February 2021 (UTC)[reply]
While I can understand what you are getting at IMO the statement By publishing changes, you agree to the Terms of Use below the edit summary box would seem to cover this. I'm also not sure what difference this would make in the case of IPs since the person using it can change. MarnetteD|Talk03:05, 5 February 2021 (UTC)[reply]
Have you ever installed a piece of software with an end-user license agreement? Do you remember what you agreed to when signing it? Did you even read it at all? Me neither. Even well intentioned people will probably just check "I agree" without reading. Gnomingstuff (talk) 00:40, 8 February 2021 (UTC)[reply]
I have to agree with the above. Without even thinking about what effect (positive or negative) this change would have, we need to realize that no one is actually going to read any warnings provided. HouseBlastertalk19:30, 8 February 2021 (UTC)[reply]
Should the COI edit request queue function more like RfCs?
Conflict of interest (COI) editing has long been a challenge for Wikipedia. While much of the controversy has centered on undisclosed paid editing (UPE), there also has developed an operating consensus, with support from Jimmy Wales, to encourage an "edit request" process consistent with the Conflict of interest guideline. In a nutshell, it is for responsible paid editors to suggest changes, and for volunteers to implement them if they make the encyclopedia better. This is described in more detail at WP:PSCOI and it has worked reasonably well over time, although like many request queues at Wikipedia, it often has a lengthy backlog.
As of this writing, there are more than 180 open requests, the oldest of which dates back to October. If not an all-time record, it's certainly close, especially following a period from 2018 to 2020 where the efforts of mostly a single editor kept the queue very manageable. Various suggestions have been made at the Village pump over the years to improve upon this process, including adding new parameters to the edit request template and promoting the recently-created Edit Request Wizard. I've given some thought about another way to potentially improve this system, which I've outlined below. My goal is to outline the issues as I see them here, gain some feedback, and hopefully even some support, before taking a more defined proposal to Village pump (proposals). Here's my analysis and initial suggestion:
Review of the current process
Template:Request edit has become the preferred tool for COI editors to submit requests for editor review. Currently, when an editor adds this template to a request posted on an article's Talk page, the request is added to a queue, displayed to editors in the form of a category and summary table. Reviewing volunteers who start from this queue may click on specific links to review individual requests and reply on the article's Talk page.
This template is helpful to the community by centralizing these requests, and to responsible COI editors because there's a much greater likelihood the request will be reviewed by at least one editor, eventually. It therefore provides a guideline-compliant alternative to UPE for those who are willing to take Wikipedia's rules seriously. When the process works, everyone benefits, including Wikipedia's readers.
Problems with the current process
However, the process has its shortcomings:
The current framework is not user friendly, for reviewers or COI contributors
No instructions are provided, so it is difficult for either volunteers or COI editors to learn how it is supposed to work
No information about the request is available prior to clicking through, other than the name of the article
Requests are not sorted in any way, preventing reviewers from selecting topics based on knowledge, interest, or type of request
Protection level and Last protection log entry information is rarely useful
As a result, requests can sit for weeks or even months before being reviewed
It is very unusual for an edit request to receive replies from more than one editor, limiting the potential for collaborative solutions
These shortcomings have the potential to negatively impact Wikipedia as a whole:
Readers do not benefit from the project clinging to incorrect information only because the person who pointed out the error has a COI
Poorly formatted requests waste volunteer time; if the queue was located on a page with a link to WP:PSCOI or the Edit Request Wizard it would be easier to triage these requests for revision
Some requests are rejected without substantive consideration, as the queue sometimes attracts editors who seem to have an aversion to COI editing. I understand and appreciate why Wikipedia editors are skeptical of COI editing. They should be! But at the same time, this process exists for a reason, and requests should be decided on the merits. Greater transparency would make these summary dismissals less common
A cumbersome submission process and very long wait times incentivizes undisclosed paid editing
Proposed solutions for improving the process
I have lately begun to think it might be better for the edit request process to more closely resemble the Requests for comment (RfC) process, especially the way it transcludes the initial Talk page requests, sorts them into differentiated noticeboards (i.e. /Biographies), and provides a centralized noticeboard consolidating all open requests.
Whatever faults one may identify with the RfC process, it's easier to review questions at a glance, more likely to generate greater participation, and thereby reduce the burden on any one volunteer. RfCs also include designated time limits on discussion, and include invitations delivered by bots to advertise discussions to uninvolved editors. What's more, RfC statements are meant to be brief and neutral, and a revised edit request process could encourage COI editors to take a similar approach.
In this way, the RfC framework could be applied to the edit request process, where submitted requests are hosted on a centralized noticeboard and editors are given a designated length of time to discuss proposed changes and form a consensus. In many cases, requests may still be rejected, and that's fine. If a few editors quickly agree a request is unreasonable, the discussion can be closed, but at least the request was reviewed by more than one person. If editors decide a request is generally appropriate, then the article can be updated based on consensus.
My goal is to allow opportunity for reasonable requests to receive adequate consideration and implementation by neutral editors, not to influence which types of requests are accepted or rejected, nor to dictate who should be allowed to participate in discussions. I do understand that reviewing edit requests takes a toll on the Wikipedia community, i.e. the WP:BOGO analysis. But this is also why I think that making the COI request process more user-friendly and reducing the friction inherent in the current design could make things less taxing on individual volunteers.
Invitations for feedback
In addition to editors watching this idea lab page, I'd like to invite editors to this discussion who may be at least somewhat familiar with the current process because they have responded to submitted requests. Back on January 4, I reviewed the 100 most recently answered COI edit requests, dating back to December 7. Below I've compiled a list of editors who replied to those requests, and I am pinging them in the hope of getting feedback about the changes I've proposed.
Editors who responded to COI edit requests during December 7, 2020 – January 4, 2021
This test was conducted at a good time because User:Spintendo generally stopped editing on October 26. He monitored the queue closely and responded to requests often, until recently. I would certainly welcome his thoughts as well, but by completing this assessment when I did we are able to see what the process looks like without him (much slower!).
So, here's where I solicit feedback from editors. What about the current COI request system is working? What about it is not? What thoughts and concerns do you have about making changes to the system, possibly one which looks more like the RfC process? What is valuable about the RfC process that could benefit COI edit requests? Which aspects of RfC would not be suitable for this purpose?
In closing, I'm hoping to get constructive feedback here before putting forth a more detailed proposal at another village pump page. I look forward to all responses, and I'll take them into consideration as I ponder next steps. Thanks in advance, WWB (talk) 22:55, 8 February 2021 (UTC)[reply]
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)[reply]
(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)[reply]
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)[reply]
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)[reply]
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)[reply]
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 ideaWikipedia: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.
@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)[reply]
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:
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.
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.
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.
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.
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.
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)[reply]
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)[reply]
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:
Taking on a request can be hard work if done properly. (@Z1720: hit on some of the reasons.)
There are insufficient rewards for taking on a request.
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).
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)[reply]
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)[reply]
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)[reply]
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]
Reply by OP: consolidated list of ideas
First of all, thanks to everyone who weighed in here with a comment. I didn't know if this would find much interest, but I'm glad to see that a number of others agree that the current process could be improved upon, with many different ideas suggested.
Having read through them all, I am persuaded that a straight "RfC but for COI" is not the right approach—but the COI process could stand to incorporate some things that other projects are doing. Here is a consolidated list of suggested ideas, a few of which were mentioned favorably by multiple respondents, with short explanations where helpful:
Clearer guidance for COI editors
List common mistakes and corrections—Some aspects of WP:PSCOI do this, but not clearly enough
Point COI editors to Edit Request Wizard (ERW)—From guidelines and advice pages, and perhaps elsewhere
Suggest improvements to ERW
Integrate with Template:Edit request—An obvious oversight that should be easy enough to correct, good catch by Izno
Build out ERW around common request scenarios—Building on a point made by FeldBum, the current template asks for the suggestion, rationale, and references, which is good but could be expanded, e.g. customized for situations where the COI contributor wants to suggest additions, removals, or modifications
Update to use fields more than talk pages—ERW currently sends users to multiple talk pages; if fields could be used like the Commons upload wizard, it would be easier to use still
Improved process for reviewers
Clearer instructions for review process—As noted by Z1720
Leaderboard to recognize active editors—Suggested by Sphilbrick
Improve Edit request template in a few ways
Add a TLDR summary parameter for possible transclusion—As noted by Schazjmd and Sdrqaz, edit requests are too long to transclude; this could be one solution
Make more like AfC with feedback and cure period—Suggested by more than one respondent, and I wonder if some templated responses might be helpful in saving reviewers' time
Organize under a WikiProject—First suggested by P,TO 19104 and seconded by others
Consolidate guidance for both parties—Improved instructions for both COI editors and reviewers available here
Centralized noticeboard—List all requests for reviewers, perhaps with transcluded TLDR summary
Prominent ERW access point—Explain ERW and make access prominent here for COIs
Incorporate article alerts—Fascinating suggestion by WhatamIdoing that I don't know enough about, which would require associating the edit request with topics, likely by WikiProject
I think that's a pretty good summary of various ideas that could all work together in some form. A few questions here, to suggest next steps:
If I left out an idea you think is important, by all means feel free to make the case for it in reply here. :)
Any points of clarification or additional information to add about specific ideas mentioned above?
Are there specific ideas in the above that editors weighing in here are experienced with or feel qualified to actively work on?
Any suggestions on how some or all of this could be effectively proposed on Village pump proper?
Adding "Suggested edits" from Wikimedia Apps to regular Wikipedia
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)[reply]
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.
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)[reply]
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}}talk21:45, 10 February 2021 (UTC)[reply]
Tyrone Madera -- Newcomer tasks feature in Czech WikipediaI'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 Mediawiki.org. ProcrastinatingReader, I would definitely be interested to hear what you think about structured tasks. -- MMiller (WMF) (talk) 23:57, 10 February 2021 (UTC)[reply]
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)[reply]
Duplicate references
For many large articles, I'll often quickly add a reference, only to discover after that it was already used elsewhere on the page, just with a difference retrieved date or other minor change, so it wasn't automatically merged. I also often come across instances where others have done this and not noticed afterwards. From WP:DUPCITES, it looks like there aren't any great tools for merging duplicate references. Should we work on creating such tools, or adding some sort of mild warning when someone tries to add a citation detected as likely a duplicate? {{u|Sdkb}}talk21:35, 10 February 2021 (UTC)[reply]
Sdrqaz, I'm not very familiar with ReFill 2. Does it do that? How good is it at identifying which references are duplicates? (Do they have to be exactly the same, or will it notice things like work=New York Times vs. work=[[The New York Times]]?) {{u|Sdkb}}talk22:41, 10 February 2021 (UTC)[reply]
@Sdkb: I thought it did, but apparently not. I just made ReFill run through my sandbox with a scenario I think you're talking about, but they weren't merged. I would say, however, that merging references with different access-dates may have unintended consequences: a piece of information may have been present in an earlier revision. However, that point about a cosmetic difference in work name is not great and should be covered by a tool. Sdrqaz (talk) 23:31, 10 February 2021 (UTC)[reply]
Help desk and teahouse volunteer, and ten+ year editor here. I just posted a mass typo fix request for "Insititute" on Wikipedia talk:Typo Team but noticed a request from July last year about a prevalence of its' (with trailing apostrophe) seems to have been unanswered. Wikipedia:Typo Team has a pledges page, but shouldn't there also be a requests page? This might also raise the profile of Typo Team - I'd never heard of the team until today. TimTempleton(talk)(cont)02:25, 12 February 2021 (UTC)[reply]
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)[reply]
