Wikipedia

Wikipedia:Village pump (idea lab)/Archive 58

< Wikipedia:Village pump (idea lab)
Village pump (idea lab) archive  

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

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

Dealing with forum bloat

Some high-activity fora (in particular WP:ANI and WP:RSN) are so clogged with activity they become difficult to navigate and can even start to glitch and slow down web browsers. I think it’s a reasonable idea to break these down somehow, probably with case-based subpages. thoughts? Dronebogus (talk) 09:32, 4 June 2024 (UTC)

The main issue with RSN at the moment is that the very large at the top was restored from the archives. It needs to be closed, but that could have happened without it being restored. Anyone interested in closing it? -- LCU ActivelyDisinterested «@» °∆t° 15:41, 4 June 2024 (UTC)
I still think it’s emblematic of a larger issue— i.e. major fora working more akin to XfDs (lots of discussion and sometimes voting, more than enough for separate pages) but being treated like a simple noticeboard with minimal user interaction (i.e. Wikipedia:AIV) Dronebogus (talk) 16:48, 4 June 2024 (UTC)
There was a discussion about similar issues here on Village Pump, see WT:VPR#Looking for some unofficial clerks and Wikipedia:Village pump (technical)/Archive 209#SIZESPLIT but for Village pumps. I could see the same idea working, opportunistically creating subpages for large topics, but doing it in anyway automatically could cause issues. Especially on RSN the vast majority of posts get few is any replies, pushing them to subpages would only give them less visibility. -- LCU ActivelyDisinterested «@» °∆t° 17:00, 4 June 2024 (UTC)
I think the main solution for RSN is to insist that RSP proposals happen somewhere else. WhatamIdoing (talk) 17:01, 4 June 2024 (UTC)
We also need to do better at emphasizing what RSP is for (or perhaps stress what it ISN’T for). It has turned into a general RFC page for sourcing questions, and that was NOT the original intent. It is supposed to be a list of perennial sources (ie sources that are repeatedly discussed), not a comprehensive list of reliable/unreliable sources. Blueboar (talk) 12:59, 5 June 2024 (UTC)
Rename it to “perennial sources noticeboard”? Dronebogus (talk) 13:00, 5 June 2024 (UTC)
WP:RSP is the list of perennial sources, which doesn't seem to be particularly bloated or diluted. WP:RSN is the noticeboard that deals with questions about reliable sources - both determining the general reliability of frequently-used sources and whether a source is reliable in a specific context - that is very long. We need a place to discuss both types of question the RSN currently deals with and while that doesn't necessarily have to be the same place, there is sometimes overlap between them. I can think of two ways of reorganising that might help:
  1. Leaving all discussions as they are currently until they get to beyond a certain size, at which point they are moved to a subpage that is linked/transcluded from the main page (similar to how some VP and AN/I discussions are treated)
  2. Leaving RSN as is for small, specific discussion with new RFCs being their own subpage. There would be a (bot-maintained?) list of open (and recent?) RFCs at the top of the noticeboard, possibly similar to the recent ECP protections report at the top of WP:AN (but not collapsed) showing the title of the RFC, the source(s) being discussed, date and time initiated, number of comments and timestamp (and author?) of the latest comment and whether it is open or closed (and if the latter when it was closed and who by).
Thryduulf (talk) 13:34, 5 June 2024 (UTC)
It's a common problem that editors open discussions/threads about getting sources added to RSP that have been regularly discussed, they all get closed down quite quickly. Very few source have recently been added to RSP.
RSN isn't usually very long, it only gets so when specific discussions are ongoing. Dealing with those discussions as they happen seems a lot less bureaucratic then setting up a mess of transcoded bot maintained pages.
Also transcluding all pages to one page is worse than having all discussions on one page, all the translcuded text has to be displayed but now with the overhead of transclusion. If the issue on any page is difficulties in display due to size then transclusion is the opposite of the solution. -- LCU ActivelyDisinterested «@» °∆t° 14:17, 5 June 2024 (UTC)
I've thought about splitting ANI. My current favorite idea is to imagine that we split it according to the day of the week (Wikipedia:Administrators' noticeboard/Incidents/Monday, Wikipedia:Administrators' noticeboard/Incidents/Tuesday, etc.). Everything can get archived together, but you could watch just the one page that "your" discussion is on. Because most are resolved and archived in about two days, the page should be nearly empty by the time it rolls around again. Admins could sign up to deal with a defined fraction of the week's load and not feel like the firehose never stops. We might have less feeling that it's just overwhelming because there are "too many" sections on the same page. And maybe we'd see less emotional spillover, in which I'm so mad about this discussion that I'm too harsh about everything else on the page. WhatamIdoing (talk) 17:00, 4 June 2024 (UTC)
I know this is a minor thing and a bit of a tangent, but ANI is not only frequently large (50+ sections some days, despite aggressive archiving) but it has an unusually high number of revisions, which means that various tools like https://xtools.wmcloud.org/ don't work on it. Sometimes I think it would be a good idea to do an archiving-esque Move procedure on that page at the start of each year (or at least for each decade). WhatamIdoing (talk) 17:07, 4 June 2024 (UTC)
I really like this idea. And the built-in reminder it provides when a discussion has been open for a week (and two weeks) could have a salutary effect. Newimpartial (talk) 17:08, 4 June 2024 (UTC)
What about going the whole way and turning it into dated subpages like TfD or MfD? Each subpage would be transcluded at WP:ANI until all the discussions on it have been closed. This could have the side benefit of making ANI more outcome-oriented, which seems to be a common characteristic of our more functional noticeboards. – Joe (talk) 09:09, 5 June 2024 (UTC)
Subpages make it much more difficult for people to watchlist the page and become aware of new discussions. Currently you can subscribe to and/or watchlist the page and be alerted to new discussions. With daily subpages you have to explicitly visit the main page and look for changes, watchlist/subscribe to 365 individual pages per year and/or use a workaround equivalent to user:Thryduulf/RfD watchlist. A forum like ANI needs visibility to work. Thryduulf (talk) 10:12, 5 June 2024 (UTC)
It needs visibility from admins, and I don't think that will stop. Maybe the peanut gallery watchlisting ANI and showing up for every discussion is actually a bad thing. Wilhelm Tell DCCXLVI (talk to me!/my edits) 11:19, 5 June 2024 (UTC)
Agreed. The problem with ANI is that it's too visible. A person with ANI on their watchlist is a person we don't want participating in ANI (I'm joking... kind of.) – Joe (talk) 12:04, 5 June 2024 (UTC)
As a non-admin, I occasionally watchlist ANI when there's a discussion of particular interest to me, such as unconstructive editing that I've recently helped to deal with. I try not to do so regularly, because it would flood my watchlist with edits which are important to someone but largely irrelevant to me. I would love to have my watchlist show only updates to a particular section. (I'm aware of subscriptions.) Certes (talk) 13:54, 5 June 2024 (UTC)
The issue with that is we need consensus from uninvolved editors for a lot of proposed actions at ANI. Making it more difficult to keep an eye out for something you may be able to contribute to isn't going to make it better. Also, this is another chance for me to bang the Administration noticeboard, not Administrators' noticeboard drum. AN and ANI are not for administrators, they're for site administration. ScottishFinnishRadish (talk) 13:59, 5 June 2024 (UTC)
We don't seem to struggle to get a consensus of uninvolved editors at other high-volume venues that use subpages, like AfD, TfD/MfD, or DRV. Conversely, it is rare for discussions at those venues to turn into lengthy pile-ons, boomerangs, or unclosable trainwrecks. When was the last time you heard somebody complain that ANI is awful because there are too few opinion-havers there? – Joe (talk) 14:31, 5 June 2024 (UTC)
I've also seen many threads there which start with a small group of editors pushing for something, that later uninvolved editors push back on. With less visibility comes less oversight. As a new editor the other high volumes venues you mention certainly felt more cliquey with the same editors turning up in discussion on a very regular basis, something the other noticeboards didn't seem to have. -- LCU ActivelyDisinterested «@» °∆t° 14:45, 5 June 2024 (UTC)
You think that the average AfD, MfD, or DRV would meet a reasonable quorum of uninvolved editors to indefinitely block, topic ban, ban, or otherwise sanction an editor? AfD is chronically underattended, for example, and articles are often deleted or kept on the word of two or three editors. ScottishFinnishRadish (talk) 14:51, 5 June 2024 (UTC)
Yes. When the outcome is obvious at XfD, a few editors will participate and others will not see the point in piling on: this is a feature, not a bug, and something that we could well try to emulate in our user conduct processes. When they're controversial (as an ANI sanctioning an established editor would be), 10-20 participants is not uncommon. – Joe (talk) 15:06, 5 June 2024 (UTC)
It's difficult to measure people not posting a comment, but I can confirm what @Joe Roe says: I avoid "piling on" at AFD, especially when the outcome is to delete, because it's unnecessary and might feel hurtful to the article's creator. WhatamIdoing (talk) 03:55, 6 June 2024 (UTC)
Subpages make it much more difficult for people to watchlist the page
That's why I thought that /Monday, /Tuesday would be better than each day. People can manually click on seven buttons more easily than 365 (times however many years you wanted to pre-load). However, I believe there is a script-y kind of way to watchlist all the pages for (say) a calendar year, if someone really wanted to do that. WhatamIdoing (talk) 03:54, 6 June 2024 (UTC)
I'm not sure formally closing all discussions at ANI is a good idea. Currently most of the uncontentious stuff is "closed" by bot archiving; explicit human closes of everything could easily lead to increased bickering about discussion closures for "no one cares"/"no longer interesting"/"nobody wants to act on this"/"no action needed" discussions (usually it is not worth determining which of these is the case). —Kusma (talk) 15:19, 5 June 2024 (UTC)

possible idea; entry compiling overviews of multiple novels, in a single series

hi all. i made the article below in my own userspace, to compile plot summaries for all novels in a series, namely the Aubrey-Maturin series, by Patrick O'Brian. what do folks here think of this, as a possible model for a type of article?

as far as I know, there is no rule currently against this type of article, but I wanted to get a little feedback here, just to see what reactions or comments on this type of article people might wish to express.

appreciate any feedback. thanks! Sm8900 (talk) 14:05, 7 June 2024 (UTC)

I like the idea, but I don't really think Wikipedia would be the best project for it, as this is mostly based on summarizing primary sources. However, it would be great to envision this as a separate Wikimedia project, if that can be possible! Chaotic Enby (talk · contribs) 14:17, 7 June 2024 (UTC)
WP:NOTPLOT seems like the relevant guideline here. While an encyclopedia article on a series of books can be appropriate (and indeed we do have Aubrey-Maturin series) an article which does nothing but summarise the series, as this seems to be, would not be. Caeciliusinhorto-public (talk) 14:20, 7 June 2024 (UTC)
TV Tropes has recap pages for series {example} Mach61 16:52, 8 June 2024 (UTC)
That is very long. Maybe incorporating condensed synopses of each entry just like List of Black Mirror episodes vs longer summaries on each individual article into Aubrey–Maturin series#Series would be more appropriate. Aaron Liu (talk) 14:20, 7 June 2024 (UTC)

Proposed revision of the COI guideline

Our current Conflict of Interest guideline is 6000 words - or 0.2 tomats - long, and often ambiguous and confusing. To address this we have recently been discussing at WP:COI a replacement, and I'm opening a discussion here to get further input on it now that it has gone through a few rounds of revisions.

It is considerably shorter than the current guideline, at just 1000 words, and is intended to be clearer about what restrictions apply to which editors. The intention is that it would replace the current COI guideline; the current text would be moved to an explanatory supplement where it could be edited and pruned as appropriate. BilledMammal (talk) 18:06, 23 May 2024 (UTC)

Draft of the proposed guideline

To preserve the integrity, neutrality, and public trust in Wikipedia, it is crucial to effectively manage conflicts of interest among editors. A conflict of interest arises when an editor's personal, professional, or financial connections might compromise the objectivity of their contributions. This guideline outlines the types of conflicts and specifies the conduct required for editors who may be affected by them.

Financial Conflict of Interest

An editor has a financial conflict of interest when they stand to gain, or can reasonably be expected to gain, financial benefits from the coverage of a topic on Wikipedia. This conflict arises in various forms:

  • Direct Financial Benefits: These include receiving direct payment for editing Wikipedia articles.
  • Indirect Financial Benefits: Such benefits are not as overt as direct payments but are significant. Examples include:
    • Business Exposure: Gaining from increased visibility when a product, service, or company is featured in an article. For example, an editor who is a major shareholder or partner in a business could materially benefit from increased sales due to enhanced visibility of their product on Wikipedia. Conversely, an individual who holds a inconsequential stake, such as a small fraction of a percent of shares in a publicly traded company, would not be positioned to experience noticeable financial gains from such coverage.
    • Reputation Enhancement: Benefiting indirectly from an enhanced reputation due to having a personal article on Wikipedia or being prominently featured as an expert. This can lead to increased professional opportunities, such as book sales, speaking engagements, or consultancy work.

Non-financial Conflict of Interest

An editor has a non-financial conflict of interest when their personal or professional connections may compromise their ability to present a subject objectively. This type of conflict arises in various forms:

  • Personal Relationships: Editing articles about friends, colleagues, family members, romantic partners, or personal adversaries can lead to biased content, whether overly favorable or unduly negative.
  • Professional Connections: Editing articles related to one's employer or competitors in the industry can introduce biases that may either unfairly promote one’s own organization or undermine others. Similarly, citing oneself or ones close acquaintances as sources can introduce bias, influencing the content to unduly favor personal or professional interests.
  • Significant Roles: Editing articles related to organizations in which an individual holds a significant role, or recently held a significant role, may introduce biases and a lack of objectivity in content related to the organization's interests. This is a spectrum, with whether an editor has a conflict of interest depending both on the level of authority or influence their role granted them, and the recency of the role. For example:
    • A general volunteer for the Democratic Party would have no conflict of interest.
    • A precinct captain for the Democratic Party would have a conflict of interest for a few years after they hold the role.
    • A presidential elector for the Democratic Party would permanently have a conflict of interest.

Managing Conflicts

  • Editors with a Financial Conflict: Must not directly edit affected articles. Instead, they should propose changes using the Edit COI template, disclosing the nature of their conflict on their user page and in any location they discuss the topic.
  • Editors with Non-financial Conflicts: While not strictly forbidden from directly editing affected articles, transparency is required; they must disclose their conflict in the edit summary and in any location they discuss the topic.

Exceptions

Aside from those explicitly listed here, no exceptions exist to this guideline; edits must abide by it regardless of their perceived harmlessness or quality. Editors who wish to avoid disclosing their conflict of interest may do so only be avoiding topics affected by it.

General exceptions

  1. Reverting obvious vandalism—edits that any well-intentioned user would agree constitute vandalism, such as page blanking and adding offensive language.
  2. Removal of clear copyright violations or content that unquestionably violates the non-free content policy (NFCC). What counts as exempt under NFCC can be controversial, and should be established as a violation first. Consider opening a deletion discussion at Wikipedia:Files for discussion instead of relying on this exemption.
  3. Removal of content that is clearly illegal under U.S. law, such as child pornography and links to pirated software.
  4. Removing contentious material that is libelous, biased, unsourced, or poorly sourced according to Wikipedia's biographies of living persons (BLP) policy. What counts as exempt under BLP can be controversial. Consider reporting to the BLP noticeboard instead of relying on this exemption.
  5. Reverting unambiguous spam, where the content would be eligible for page deletion under criterion G11 if it were a standalone page.

Wikipedians in residence

A Wikimedian in Residence (WIR) is a professional role in communications for an organization to share its knowledge within the Wikimedia platform, measure the impact of the same, and promote Wikipedia through training, education, and edit-a-thons. While WIRs can greatly benefit Wikipedia, there is a risk of edits that could unduly benefit their employers. To manage this risk, the following guidelines apply:

  • Scope of Editing: WIRs may edit articles related to but not directly involving their institution. They must not edit articles where their institution is the primary subject or could reasonably be seen as directly benefiting from the article's content; if they wish to make changes to such articles they must follow the instructions at #Managing Conflicts for Editors with a Financial Conflict.
  • Disclosure Requirements: WIRs must clearly disclose their role and association with their institution on their user page, as well as in any discussions or edits related to their role as a WIR

Reporting suspected violations

When violations of this policy are suspected or identified it is crucial to address them with transparency and caution, balancing protecting the encyclopedia with respect for the editors involved. Always adhere strictly to our no-outing policy; only post personal information if the editor has disclosed it on Wikipedia.

  • User talk page: Non-urgent issues can be raised on the editor's talk page, using the COI warning template as appropriate.
  • COI noticeboard: If issues remain unresolved after user talk page discussions, or if the user talk page is an unsuitable venue, escalate the matter to the Conflict of Interest Noticeboard. This noticeboard also provides guidance for editors dealing with their own conflicts.
  • Private communication: For issues requiring confidentiality, including where posting the information on Wikipedia would violate our policies on the posting of personal information, email evidence to the appropriate channels: for general COI issues, contact functionaries-en@lists.wikimedia.org, and for paid editing concerns, reach out to paid-en-wp@wikipedia.org. Always consult these channels for advice before sending private information.

Discussion

Any way to internationalise the bit under Significant roles? A "precinct captain for the Democratic Party" doesn't really map intuitively onto anything in my experience, and others may feel similarly. Folly Mox (talk) 20:41, 23 May 2024 (UTC)
I tried to think of a few as I didn't consider it ideal either, but I couldn't think of anything more recognizable. If you have any ideas I would be glad to change them. BilledMammal (talk) 00:08, 24 May 2024 (UTC)
  • I am really not liking the direction this proposal is taking us. This focuses on the editor and not the edits.
Having a conflict of interest should NOT bar anyone from editing as long as their edits are in accordance with our content policies and guidelines. Even a paid editor is not problematic UNLESS they are editing in a way that is contrary to our p&g.
I agree that it IS all too easy to (even unintentionally) edit in a way that is contrary to p&g when you have a tie to the topic… and so I agree with requiring disclosure. After all, when you disclose, others can better guide you when you unintentionally edit in a problematic way. BUT… those with a conflict CAN edit properly with such guidance.
The flaw isn’t in having a conflict of interest… the flaw is in allowing that conflict to impact one’s editing. And THAT is resolved by addressing the edits, not the editor. Blueboar (talk) 22:36, 23 May 2024 (UTC)
I agree that the flaw is in allowing the conflict to impact one's editing. However, I don't believe it's useful to focus on the edits within the conflict of interest guideline. All edits are held to the same standard: they are proper if they align with our content policies and guidelines, and improper if they don't.
Instead, we should recognize that editors with a conflict of interest can make significant positive contributions but also face an increased risk of making problematic edits - especially ones that are difficult to detect and address. Our goal should be to minimize this risk without hindering those positive contributions, and we can achieve this through two complementary processes: providing additional guidance to editors with a conflict of interest and subjecting their edits to greater scrutiny.
A conflict of interest guideline that focuses on the editor, promoting transparency and disclosure, supports these processes, and allows us to better manage the risk. BilledMammal (talk) 00:08, 24 May 2024 (UTC)
I agree with Blueboar, the only thing that matters is the edits. Everything that isn't directly supporting the inclusion of good edits and the exclusion of bad edits, regardless of source, is irrelevant. The significant majority of this proposal is focusing on completely the wrong thing. Thryduulf (talk) 21:34, 24 May 2024 (UTC)
@Blueboar and @Thryduulf, can't the same thing be said about the existing COI guideline? Is this really "taking us" somewhere new, or is it "keeping us exactly where we have been since 2012"?
Related to the comment from @Curbon7, I think the most recent major change was when Gigs and SlimVirgin largely re-wrote COI in 2012. If memory serves, the goal was to make COI focus on the editor instead of the edit, because real-world definitions (e.g., for corporate board malfeasance) focus on the individual actors instead of the actions. For example, if a non-profit board member owns an office building, and offers to rent badly needed office space to the non-profit at a massive discount, he can theoretically get in COI trouble for voting to accept his offer, even if that's clearly the best possible thing for the organization. WhatamIdoing (talk) 06:17, 25 May 2024 (UTC)
Wikipedia's COI policies don't ban those with a COI from editing. However, they do require you to:
  1. Disclose that COI
  2. Keep any bias in check
  3. Involve other editors to verify all edits are unbiased
  4. Avoid letting your voice "dominate" any articles on the topic.
The editor matters because we don't have perfect information. If a rando gives a citation for "Bob the scientist says X", it's reasonable to include this in an article, and I won't give it much thought. However, it's possible Bob's view falls outside the mainstream; to determine that, I'd need to learn all about X. I can't do this for every possible X, so I take a shortcut: if a COI editor who would benefit from X writes this edit, I make sure to be extra-careful when reviewing the edit. –Sincerely, A Lime 20:17, 9 June 2024 (UTC)
  • I think rather than re-writing the guidelines entirely it may be more wise to trim the guideline section-by-section. I'm not sure many editors have an appetite for a ground-up re-structuring which to some may seem to be the addition of new guidelines and removal of existing one; the issue with huge proposals like this is the risk of a controversial change in one spot derailing the entire thing. Curbon7 (talk) 22:59, 23 May 2024 (UTC)
    As a matter of practical politics, you're probably right. I don't remember a wholesale re-write ever being adopted in one go, though we have (10+ years ago) made really substantial changes to some policies through a series of edits. But it's also helpful to look at the potential goal. If it's going entirely the wrong way, then we might not want to propose any of the changes. WhatamIdoing (talk) 06:05, 25 May 2024 (UTC)
    I think an attempt at a ground-up restructuring is worth attempting; a lot of the changes only make sense in context, and I feel trying to run a dozen RfC's will quickly fatigue the community. BilledMammal (talk) 07:18, 2 June 2024 (UTC)

Worth the effort; there are many problems caused by the current guideline. North8000 (talk) 13:43, 4 June 2024 (UTC)

Make the edit request facility optional

An uncontroversial, "change X to Y" request can be done just as easily using a normal discussion thread. The edit request facility exists for low-activity protected articles where there is a need to summon an editor to handle the request; otherwise the request could sit unseen or ignored for years. In my experience, edit request is used far more often for changes that are not uncontroversial, and/or are not in the required "change X to Y" format. This is because users don't take the time to read the instructions presented to them in the request path.

It should be possible to turn off the edit request facility at articles where it isn't needed; i.e., articles that always have editors around. In such cases the edit request path could be replaced by instructions directing the user to the talk page (or saving them a step and presenting the same thing they would get by clicking "New section" at the talk page). ―Mandruss ☎ 22:31, 21 May 2024 (UTC)

Well it is already optional and editors do make requests in text only. The template makes it formal and encourages identifying the exact change, although often not used correctly. Graeme Bartlett (talk) 22:52, 21 May 2024 (UTC)
The use is optional; the facility is not. Again in my experience, editors are spending too much time rejecting "invalid" edit requests (which also wastes the requester's time).
The facility summons an outside editor by placing the article in a maintenance category for that purpose. In my 10+ years at normal-activity articles, I've yet to see a request handled by such an outside editor. Rather, the request is invariably changed to answered=y by a "local" editor, removing the article from the category, before an outside editor arrives to handle it. So, for a normal-activity article, what's the point of the category or the facility? ―Mandruss ☎ 23:26, 21 May 2024 (UTC)
Not every request-reviewer is that lazy. Quite a bit will engage in discussion. Aaron Liu (talk) 23:29, 21 May 2024 (UTC)
And they will do so improperly, all the more reason to turn off edit requests. The edit request instructions are quite clear: "What an edit request IS NOT for: [...] making a comment or starting a discussion: go to the talk page [...]". Again, if discussion is the goal, there is already a way to do that. ―Mandruss ☎ 23:55, 21 May 2024 (UTC)
Hmm. But should people new to a topic carry the burden of assessing whether a talk page is active? Aaron Liu (talk) 01:24, 22 May 2024 (UTC)
I don't understand the question. If you're referring to the requesters, they wouldn't have to make that assessment. It would have already been made by the article's editors (or not). For example, the editors at Donald Trump would turn off the edit request facility and any user clicking "View source" on the article page would be directed to the talk page (or, as I said, the box would be presented to start a discussion thread). More precisely, they would be presented the option to start a discussion thread, just as they're presented the option to submit an edit request today (big blue button).
And, again, if they don't seek discussion—if they have something clearly uncontroversial—a normal thread works equally well for that purpose. Heading: "Typo correction". Comment: "Please correct the spelling of 'envirmental' in the 'Climate change, environment, and energy' section. ~~~~". Done. The only material differences are (1) a more meaningful section heading, hopefully, (2) no need to change to answered=y, and (3) no maintenance category pointlessly involved. ―Mandruss ☎ 02:15, 22 May 2024 (UTC)
Then just add the edit notice for articles where all edits will be controversial. I don't see why we should remove the ER facility, which is still perfectly good for uncontroversial edits. I don't see why editors already being available is a problem. Aaron Liu (talk) 11:31, 22 May 2024 (UTC)
@Mandruss: The facility summons an outside editor by placing the article in a maintenance category for that purpose. In my 10+ years at normal-activity articles, I've yet to see a request handled by such an outside editor. Can you please clarify what you mean by this. Many volunteers watch CAT:ESP and related pages and handle requests. RudolfRed (talk) 02:45, 22 May 2024 (UTC)
@RudolfRed: I'm sure they do, but I've never seen them handle one at an article that always has editors around to handle it. Not once in 10+ years. They simply can't get there fast enough, presumably because they are processing a FIFO queue containing a number of older requests. Even if they could, why bother them when they aren't needed? They have many requests to handle where they are needed. ―Mandruss ☎ 02:56, 22 May 2024 (UTC)
There's a lot of high traffic articles here. In my experience handling well over 10,000 edit requests and patrolling all of the edit request queues, edit requests are often ignored by the regulars on well attended talk pages, and edit request patrollers handle requests on those articles very often. ScottishFinnishRadish (talk) 02:36, 25 May 2024 (UTC)
Great. Then those articles would not turn off the edit request facility. Hence "optional". ―Mandruss ☎ 04:30, 25 May 2024 (UTC)
Pages that are protected are normally of interest to many editors. So hopefully they are on watchlists. Also I expect that admins the protect, add the page to their watchlist so they can see any requests or edits. Graeme Bartlett (talk) 22:39, 23 May 2024 (UTC)
That reads like an argument for eliminating the edit request facility entirely, which would be a step too far in my opinion. It's certainly not an argument against making the facility optional at article level. ―Mandruss ☎ 01:10, 24 May 2024 (UTC)
And the argument is very wrong too. There are plenty of obscure protected pages. High-risk templates. MediaWiki-namespace pages. Gadgets like MediaWiki talk:Gadget-watchlist-notice-core.js, where even the edit request template itself has failed for two months. * Pppery * it has begun... 04:04, 24 May 2024 (UTC)
I implemented this a while ago per Wikipedia:Administrators' noticeboard/Archive334#Possible new tool/technique/procedure as {{Manual edit requests}}. It never got used then because the person who was advocating for it retired due to unrelated drama shortly after that discussion. * Pppery * it has begun... 04:04, 24 May 2024 (UTC)
I still don't see why editors being already available is a problem. Aaron Liu (talk) 11:29, 24 May 2024 (UTC)
You're choosing to frame this in a greatly oversimplified way that ignores points already made. I hate circular/repetitive discussion, and I suggest a re-read with more effort to see a different perspective. ―Mandruss ☎ 02:27, 25 May 2024 (UTC)
Bump. It's been said, not by me, that Idea Lab is where good ideas go to die. ―Mandruss ☎ 21:48, 5 June 2024 (UTC)
Even if that's true, I don't think the precondition is met for this one.
Suppressing the normal edit request mechanism IMO should only be done for pages where it makes it too easy for confused users to make completely misplaced edit requests (e.g. all the people who used to wind up at Template talk:Reflist trying to add references to some particular article, or Help talk:Edit summary trying to add a summary to their edit). If people are using it to make appropriate requests, even if malformed and even if the article always has editors around, then it's not a problem. Especially in the "always has editors around" case, those editors can handle it.
Above you complain about Rather, the request is invariably changed to answered=y by a "local" editor, removing the article from the category, before an outside editor arrives to handle it, which IMO is the mechanism working as intended: an editor answers the request and sets answered=y. Just because that happens to be an editor who'd have seen it anyway because they watch the page is not a "problem" that needs fixing. Anomie⚔ 11:22, 6 June 2024 (UTC)
The point is that, where there is no need to summon someone via the category, there is no need for the facility. That's it. In my nine years at the perpetually-protected Trump article, perhaps one in twenty edit requests have resulted in an edit to the article—and it could have been done using a normal thread. The other nineteen have been malformed, controversial, attempts to start discussion, or requests for permission to edit the article directly. That is a distracting waste of resources too easily avoided. ―Mandruss ☎ 12:12, 6 June 2024 (UTC)
It's not that I don't understand your point. It's that I disagree that removing the edit request pre-fill would make things better, outside of your own personal annoyance at seeing the edit request template. You or other editors on the page are free to retitle sections and mark the "bad" request as answered when you answer them. Anomie⚔ 12:46, 6 June 2024 (UTC)
Well, I think you do misunderstand my point, unless you're saying that the distracting waste of resources is acceptable. If that's the case, I invite you to come spend a few weeks at the Trump article; might change your perspective. We have more important things to do, and not enough time to do them. ―Mandruss ☎ 12:52, 6 June 2024 (UTC)
On second thought, it's not a good time for your visit. The article talk page has been temporarily semi-protected due to vandalism related to the conviction, and I think that's preventing edit requests. ―Mandruss ☎ 13:13, 6 June 2024 (UTC)
Sorry, I can't stand Trump. Anomie⚔ 00:49, 7 June 2024 (UTC)
I might be misunderstanding the proposal; currently I'm interpreting it as "disable the ability to create edit requests on controversial pages/pages with lots of watchers". If that's the case: last year, I made an edit request to the List of Conspiracy Theories article, which is unsurprisingly a controversial article and has over a thousand talk page watchers. By your criteria, I'm pretty sure edit requests would have been disabled. As it was, it took 23 days for anyone to bother to respond, during which time (if my memory's correct) it became the 12th-most-stale edit request on the entire site. ...had your proposal been in place, and had my request been forced to have been opened as a normal thread, it would have vanished into the void and would still be unanswered today. Because surprise surprise, the ultimate responder found it through the Edit Request Tool, not from watching the talk page. 2603:8001:4542:28FB:BC84:B937:5E69:2838 (talk) 14:42, 7 June 2024 (UTC) (Send talk messages here)
That's the general gist I saw when I was I patrolled edit requests. ScottishFinnishRadish (talk) 14:45, 7 June 2024 (UTC)
The proposal is to give an article's editors the power to turn off the edit request facility if they judge that it's doing more harm than good at that article. The test is not an arbitrary one based on # of watchers or anything else. Are you suggesting that decision would be made at List of conspiracy theories? Made on what basis?
Regardless, it's not like the decision is irreversible. If your normal thread sat unanswered for a long time, would that not be a clear reason to turn the facility back on? If your edit request went unanswered for 23 days, how is that an argument against this proposal? ―Mandruss ☎ 18:27, 7 June 2024 (UTC)
I'm just not seeing what it really does. The template attracts the patrollers. If they close an edit request it doesn't mean that the watchers of that particular article can't action or respond to the request in any way they see fit. ScottishFinnishRadish (talk) 18:30, 7 June 2024 (UTC)
If I've failed to make the point about "distracting waste of resources", I guess there's nothing else I can say. ―Mandruss ☎ 18:40, 7 June 2024 (UTC)
What you call waste, we call extremely effective redundancy. Aaron Liu (talk) 18:48, 7 June 2024 (UTC)
Perhaps I'm misreading, but it is unclear what resources are being wasted (server kittens?) or that anyone is distracted. One of two things is true. Either the request is answered by someone who is patrolling the categories for edit requests, in which case the system functioned as expected. Or the request is answered by a talk page watcher, in which case the proposed change would make no difference except perhaps cosmetically due to a different template. I suppose there is the tiniest chance that a patroller inspects a request at the precise instant a talk page watcher answers it and edit conflicts, but the benefit of eliminating an extremely rare occurrence is more than outweighed by the extra complications entailed by the proposed change. 184.152.68.190 (talk) 04:49, 10 June 2024 (UTC)
I doubt that new users would be able to know how to request turning the facility back on, nor if there were a facility because it was turned off. Aaron Liu (talk) 18:49, 7 June 2024 (UTC)
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(idea_lab)/Archive_58&oldid=1230447086"