Jump to content

Wikipedia:Village pump (idea lab)/Archive 31

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

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

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

ISSN ISBN info panel inclusion

Was recommended to post somewhere here, apologies if in the wrong spot. I came across this page - Building (magazine) and there is an info panel on the side. For magazines it would be useful if it included the ISSN number. For books the ISBN, etc. There are other posts about the importance of citation but it is not always easy to locate older titles. For example try and locate the ISSN for Building magazine on https://portal.issn.org/ it would be much easier if this was included in the dedicated page info panel of magazines. ISBNs for books are more complicated because of the many editions they have but possibly this could be part of a separate wiki. Sites such as https://www.worldcat.org/ are quite ungainly. ImagHistrix (talk) 11:07, 10 February 2020 (UTC)

{{infobox book}} already supports ISBN; {{infobox magazine}} already supports ISSN, as does {{infobox journal}}. All that needs to be done is someone needs to add the value to the infobox, which you can do. --Izno (talk) 15:21, 10 February 2020 (UTC)

Attract attention of pages needing serious maintenance

Sometimes a template or module change causes other pages to "break" and wind up in one of the "I'm a broken page" categories such as this one, this one, or some of the others tracked at Special:TrackingCategories.

Currently, editors who want to take on the project of fixing pages broken by template or module changes can add the categories on Special:TrackingCategories to their watchlist and check their watchlist filters to make sure "Category changes" is NOT checked.

To get visibility from people who actually know the topics, I would like a bot to check these tracking categories and put a note on the article's talk page after a few days if the problem hasn't been fixed. This will get the attention of editors who are watching those articles.

I'm looking for feedback before I take this to Wikipedia:User scripts/Requests and ask someone to code it up. davidwr/(talk)/(contribs) 21:31, 11 February 2020 (UTC)

idea for collaborative page

Hi. I have an idea to create some kind of collaborative workspace where coordinators or members of various WikiProjects would gather and provide updates and information on what is going on at each wikiproject, i.e. regarding their latest efforts, projects, and where interested editors can get involved. I posted this at Wikipedia:Village pump (proposals). however, if anyone has any ideas for this that they would like to post here, then please feel free to discuss here if you wish. thanks!!! --Sm8900 (talk) 12:34, 9 February 2020 (UTC)

In the past there have been some very good Signpost articles about particular Wikiprojects and the sorts of issues they have dealt with. I suggest you look there. A regular feature on Wikiprojects should be possible. ϢereSpielChequers 11:39, 13 February 2020 (UTC)

new resource created

I have personally set up the following new page , populated it, structured it, and formatted it for the use of the Wikipedia community at large. This is meant as a place to list any drafts left by deceased Wikipedians, to enable and to encourage others to continue work on these cherished and valued writings, and drafts as they may wish.

All of us are resolved to highly value, to cherish and to admire the heartfelt work and efforts by those who are no longer with us, and wish up to set up this resource to commemorate their efforts. by doing so, this is one good way to make sure as a community that their work shall be cherished, and that the work of our encyclopedia shall go forward, and that our work will continue to grow, and to flourish, on behalf of future generations who will benefit from the work done here. I appreciate the help, thoughts and insights of everyone involved here. thanks! --Sm8900 (talk) 17:41, 13 February 2020 (UTC)

Previously Deleted Article search tool.

Hi there, I just discovered a sock operator who was trying to re-build some previously deleted articles using disambiguations to thwart scrutiny. Example: He had previously created Jamai 2.0. It was deleted a couple of times, so he tried to recreate it as Jamai 2.0 (web series). There could be other ways to try to avoid scrutiny this way, like by using "(webseries)" instead of "(web series)". Sometimes they'll even do it through the Draft system so that they can have someone move the finished article. It would be super-helpful if there was a tool that could check for previously deleted articles that had similar names. Impossible? I haven't quite thought through how best that could be implemented, but maybe one of you braniacs could figure it out. Maybe even if I, as an admin, could tick a box in the basic article search tool that looks through deleted articles and maybe allows wildcard searches for partial matches. Thoughts? Cyphoidbomb (talk) 19:16, 14 February 2020 (UTC)

You mean like Special:Undelete? (example) —Cryptic 19:36, 14 February 2020 (UTC)

English Wikipedia's Featured Pictures - soliciting feedback on its purpose and whether it should be closed

I've written an essay of sorts about our Featured Pictures process and its purpose, and would like some feedback. Depending on the response, it may or may not lead to a proposal: User:Rhododendrites/Reconsidering FPC on the English Wikipedia.

The basic argument: We started a FP process some months before Commons was launched. The only purpose, as far as I can tell, for us having a wholly separate and parallel system at this point is to create a pool for POTD. But it doesn't do a very good job of that, with persistently low participation resulting in less than one image promoted per day (last month it was 12, with 8 failing to reach a quorum despite having no opposition).

By contrast, the Commons system promotes about three per day, including most of those promoted through our system. We've explored lowering our standards/threshold for support (it's already lower than Commons) without much success.

My thinking is that it would be far easier for us to close our FPC process and select from the huge pool of FPs on Commons for our POTD (which includes most of those we promote anyway, plus a lot more, nominated/voted upon by a much larger group). Beyond this, there's a question of purpose. One of the few differences between our processes is connected to how Wikipedia's purpose is not to highlight good images but to use the best images in our articles. So FPs here must be used in articles -- something which, of course, is affected by normal editing and so should result in regular delisting discussions on top of the already struggling promotion process.

Thanks. — Rhododendrites talk \\ 16:25, 16 February 2020 (UTC)

Note: This has been posted in multiple locations. To avoid parallel/redundant discussions, I'd like to encourage people to consolidate comments on the essay's talk page. — Rhododendrites talk \\ 16:48, 16 February 2020 (UTC)

Improving new article edit notice

In a discussion at the welcoming committee on streamlining the new user message, we've been doing a little brainstorming on how best to handle new users who seem to be trying to create an article. The edit notice that appears when you start creating a new page is one place to encounter those users, so I want to open up a discussion about ways to potentially improve it. Currently, it reads as this (for normal mainspace articles):

(It's located here, but that's not a good place for discussion, thus why I'm posting at this page.)

The main change I think needs to get made is to make the article wizard more prominent. My reasoning is that, while in an ideal world everyone would indeed read WP:Your first article before creating their first article as instructed, in practicality I'm guessing most newbies chomping at the bit to get a page for their garage band won't bother. A wizard that makes the process easier, on the other hand, might be quite attractive, and will have the added benefit of diverting users who aren't quite ready for mainspace, etc.

As for the other elements, I think some streamlining could be useful — if we want people to actually read it, it needs to be short. Genuine questions: Is newbies creating articles for pages that already exist a frequent problem? If not, the search line can go. Are articles often created as test edits? If not, no need for the sandbox link. The reminder to include references, while important, is covered if the user switches to the wizard, and the suggestion to create in your userspace becomes moot.

Finally, a perhaps slightly bolder proposal: why is it that we show the same notice to everyone? We know when a user is creating their first article, so when that happens, we could make the notice extra prominent (add a stop sign, perhaps, or even turn it into a pop-up message) with extra encouragement to use the wizard, whereas for experienced users we could tailor the notice or just remove it.

What are everyone's thoughts on all this? Sdkb (talk) 04:47, 30 January 2020 (UTC)

  • I think the referencing line needs change. This process will send them to AfC, and any draft without references will automatically fail the review process. Beyond that, any BLP draft needs inline referencing (presumably with a link to the appropriate bit of REFBEGIN). While the increase simplicity is beneficial, these are core to the editor being able to pass AfC. Nosebagbear (talk) 09:47, 30 January 2020 (UTC)
    As a follow-up to that, to clarify, I realise you say this is for mainstream articles, but the wizard goes through AfC unless you use it to create the content, then deliberately choose to bypass it. Nosebagbear (talk)
  • I like your approach to streamlining, Sdkb. And I agree that sending newbies through the Article Wizard is desirable, especially because it also sends them through AfC (which has many benefits, as Nosebagbear notes). So, what about something like this:

My reasoning about how I'm tweaking each element: In this case, I think the suggestion of a redirect is useful to non-newbies who encounter this message, since everyone who clicks a redlink will encounter this message, and often a redirect can be a useful response to a redlink. Similarly, I think the "Special:Mypage" link is a useful convenience. I agree that the mention of the sandbox is redundant unless a lot of newbies make articles to experiment. In case a new user clicks none of these links, I think it's still important and valuable to make sure they've seen that references are important, and to introduce the idea that the article might be deleted if it doesn't meet wikipedia standards. In general, I think the first and last items have the most "prominence" for someone who doesn't want to read a whole list. I think just moving the mention of the Wizard into a more prominent position, and identifying it as an explicit recommendation rather than a weak "see also", would go a long way.

It looks like the talk page for this template suggests having discussions at Wikipedia:Village pump (technical) -- should a note be placed there too? (I am new to the Village pump!) ~ oulfis 🌸(talk) 00:10, 31 January 2020 (UTC)

That's unequivocally better than what's currently being used; I requested for it to be implemented.
As I think about it, investing the effort to tailor separate messages for newbies vs. experienced users is really something that ought to be worthwhile — after all, this is a message nearly every new user will encounter at some point, not some obscure small fry in a hidden corner. The onboarding process that Google or Apple have when a user tries something new puts us to shame, and while their developers are being paid, we should at least aspire to something decent.
Regarding your question about the Village Pump, my understanding is that the technical page is more for identifying bugs. The suggestion to post there was with the assumption that changes to the page that hosts the notice would be technical, whereas we're talking mainly about content. That said, I do hope there are enough technically-minded Wikipedians here that someone will be able to speak to the feasibility of tailoring the notice as I described above. Any takers? Sdkb (talk) 09:38, 2 February 2020 (UTC)
Update: Oufis's version has been implemented. Are any editors here knowledgeable enough to be able to chime in on the possibility of tailoring? Sdkb (talk) 22:41, 7 February 2020 (UTC)
No response here, so I just asked at the technical tab. Sdkb (talk) 20:40, 13 February 2020 (UTC)

Guideline for new disease outbreaks

Hello. I would like other's thoughts, particularly after the COVID-19 outbreak has subsided, on how Wikipedia could develop a policy on creating and developing articles around new disease outbreaks.

Multiple reasons, but particularly apparent right now:
1. The names of novel infectious diseases is not entirely standardised and I don't believe the WP:COMMONNAME policy covers this in specific detail.
2. Reliable sources often detail conflicting, and rapidly developing information.

I could give several other reasons, but this post is simply to gauge the community's initial thoughts around the idea.

I would be happy to commit quite a bit of time to this. Thanks! --Almaty (talk) 02:17, 15 February 2020 (UTC)

As for (2), WP:NOTNEWS and WP:DEADLINE apply. Despite "heatseekers" who love adding stuff to Wikipedia as soon as it pops up in the first barely-RS primary news source they can find, we can afford to wait until reliable secondary sources have covered something, because secondary sources are what Wikipedia is to be built on, not mainstream media news outlets reporting eyewitness news, reporting on social media, and reporting on police blotters as they are obtained. A little restraint goes a long way, especially in the face of multiple conflicting and rapidly developing details. Elizium23 (talk) 02:34, 15 February 2020 (UTC)
Exactly @Elizium23: this is one of the things I would suggest putting in that guideline. --Almaty (talk) 02:40, 15 February 2020 (UTC)
Almaty, I think disease reporting comes with a hefty "fog of war" as state agencies attempt various levels of covering themselves and trying not to run tourism and free trade. Especially as we have seen with the Wuhan outbreak, communist China state controls all media with an iron fist, unlike democratic free presses, where more conflicting details may actually arise, but it may be easier to identify accurate info. I think it behooves us to consider the motives and objectives of state-owned media outlets especially in the case of epidemic-level outbreaks. And not only those type, but the Western "fake news" phenomenon is equally triggered here and we can't simply trust news because it's capitalist or "free press" which is sometimes a bit too free! I think WP:RS/P is quite informative for most questions here. Elizium23 (talk) 02:44, 15 February 2020 (UTC)
Yes agreed that there are pre-existing policies that give guidance on some of the questions. This new guideline would defer to those policies, and simply give examples and links to those policies. Specific examples would be along the lines of what is considered a secondary source - WHO for instance. This could be a subset of WP:MEDMOS--Almaty (talk) 02:49, 15 February 2020 (UTC)
Full disclosure, one of the policies I would suggest for consensus would be to attempt where possible to avoid geographical names in titles. This would be a huge change from the WP:COMMONNAME policy, and potentially cause ambiguity, however given this is the intention of the WHO for current and future diseases I would suggest it for consideration of consensus. --Almaty (talk) 03:01, 15 February 2020 (UTC)
But this would also need to be balanced with the ability of Wikipedia to be an uptodate, reliable source of information. --Almaty (talk) 02:42, 15 February 2020 (UTC)
WHO is biased by the desires of its member organisations. So for a neutral point of view we should not blindly follow WHO categories, names or information. Instead it must be considered along with other reliable and possibly less biased sources. Graeme Bartlett (talk) 07:17, 17 February 2020 (UTC)
@Graeme Bartlett: yes of course, I'm not suggesting in any shape or form that wiki should emulate the WHO. That's what the WHO's website is for. I'm just suggesting that we can make a policy around outbreaks, each point will need to achieve policy consensus, and then numerous discussions like we had to (arguably unnecessarily) have had in the Coronavirus disease 2019 outbreak would defer to the policy. Do you know what I mean? Basically just a policy page that reiterates preexisting polices but also, particularly focuses on things like
1. naming
2. statistics
And then gives very clear examples of how to defer to preexisting policy. Because we all know that outbreaks attract new editors, lets give them clear guidance! --Almaty (talk) 09:44, 17 February 2020 (UTC)
  • If you want this to go anywhere at all, you need to do it on the med project talk, not here. Johnbod (talk) 19:07, 20 February 2020 (UTC)
  • This is yet another example of the very idiosyncratic treatment on Wikipedia of news reports as secondary sources, rather than the primary sources that are are considered to be everywhere else. While we rely on editors' interpretations of news reports rather than proper coverage in secondary sources we will continue to get such problems, and there seems to be little that we can do about it. Phil Bridger (talk) 19:24, 20 February 2020 (UTC)

Rethinking a BLPPROD for Draft namespace

Recently, at MfD, there have been a number of drafts that were wholly or mostly uncited and, thus, constituted BLP issues had they been in Main: namespace. Several editors have mentioned the idea of supporting BLPPROD for Draft: namespace. So, since this is the "idea lab" section of the village pump, please do not merely say "support" or "oppose". Rather, let's discuss. What are the advantages? What are the disadvantages?

Off the top of my head, WP:REFUND would apply, provided that an editor is prepared to provide reliable sources which substantiate the claims. As such, there would be no need to go to deletion review. I can't really think of any downsides, but let's discuss.

Should we make WP:BLPPROD apply to Draft: namespace, or does it need special considerations?

Cheers,
Doug Mehus T·C 21:46, 17 February 2020 (UTC)

  • So, let's play devil's advocate then. The obvious reasoning against, is that the potential BLP damage of an uncited draft (that isn't libellous etc) is almost always going to be lower than of an indexed article. It also is far more likely to have only 1 editor, who is likely to be unexperienced, who often only edit infrequently and may well miss the warning. So in comparison to a regular BLPPROD, the benefits are reduced (as there is less damage to mitigate) and the risks (of a deleted piece of content), as well as potential lost editors, are greater. Nosebagbear (talk) 13:52, 18 February 2020 (UTC)
  • Unindexed doesn't mean invisible - there's a number of indexed mirrors that, not content to plaster ads on our real articles, copy draftspace too. (At least they're not quite as contemptible as the ones that preferentially mirror CAT:CSD.) —Cryptic 14:26, 18 February 2020 (UTC)

Expansion of info at Community bulletin board

Hi everyone. I am writing to let everyone know that the Wikipedia:Community bulletin board has been greatly expanded, with the addition of a brand-new section called Wikiproject group activities and efforts, providing an extensive list by month of current community activities, including group editing projects at WikiProjects, as well as any types of contests, editing drives, general improvement drives, and really any kind of community efforts and activities whatsoever. we hope to expand and update this section in the months ahead.

Please feel free to add any items there that you might wish. I would like to explore some different possibilities for exploring this and for expanding this as a resource. Please feel free to go there, take a look, and to let me know what you think. thanks. --Sm8900 (talk) 14:09, 6 March 2020 (UTC)

Bot proposal (from Teahouse)

Hi, I've thought of this idea of a bot that can do uncontroversial cleanup on articles. The original discussion at the WP:Teahouse is as follows:

Previous comments folded for readability

Hi, I'm thinking of a bot concept that allows the automatic, non-controversial tagging and cleanup of certain articles. It can, for example, add tags like {{lead too long}} or {{Uncategorized}}, but not, for example, {{copy edit}}. It can also potentially tag articles unsourced for an extended period of time for PRODding. What would be your opinions on this potential bot? Thanks. tLoM (The Lord of Math) (Message) 13:14, 5 March 2020 (UTC)

Hello, I like your proposal, but WP:Bot requests is probably the better place to post this. PorkchopGMX (talk with me - what i've done) 13:32, 5 March 2020 (UTC)
The Lord of Math, you might also want to open a discussion at either Wikipedia:Village pump (idea lab) or Wikipedia:Village pump (proposals), as this would likely have more impacts than a typical bot. ~~ Alex Noble - talk 13:34, 5 March 2020 (UTC)
@Alex Noble and PorkchopGMX: Thanks. BRFA required a "consensus" for bot tasks and I'm looking for one. So is Wikipedia:Village pump (proposals) the preferred location for obtaining it?Thanks. tLoM (The Lord of Math) (Message) 13:50, 5 March 2020 (UTC)
The Lord of Math, Proposals would be the where consensus is made; the idea lab is for developing the details before it goes to proposals. ~~ Alex Noble - talk 13:58, 5 March 2020 (UTC)

Would you please give your opinions on this? tLoM (The Lord of Math) (Message) 14:16, 5 March 2020 (UTC)

​I don't think this task is well suited for a bot, pages are usually categorized fairly well with only 30 results shown on Special:UncategorizedPages. {{Lead too long}} is context-sensitive and for most transclusions of that template that I've come across the lead is actually just fine. Automatic PRODing would not be good since you'd need to read the article yourself anyway to check if it really needs deletion, would flood the PROD system since there are currently 180,000 unsourced pages. – Thjarkur (talk) 17:28, 5 March 2020 (UTC)
Sorry for all the confusion about forums, but I think you'd probably get the best response from Wikipedians most knowledgeable about bots at WP:BOTREQ. Be prepared, though, I expect Þjarkur may be right. It's harder to find tasks suitable for bots than one might expect since there are so many exceptions to take into account, and many of the most obvious bot tasks already have a bit doing them. Sdkb (talk) 17:34, 5 March 2020 (UTC)
We need to distinguish between policy changes and bot requests. For anyone, whether a bot or not, to automatically propose an article for deletion for being unsourced (unless it is a WP:BLP) would require a change to policy before it could be considered as a bot task. I have no opinion as yet on the other proposals, but have my doubts about whether a bot could decide on {{lead too long}}. There are certainly cases where the bright line of four paragraphs given in that template is not appropriate for a particular article, so this needs something cleverer than that. Phil Bridger (talk) 19:04, 5 March 2020 (UTC)
These seem like good ideas in theory (save for the unref = PROD idea, which is outright bad) until you sit down and think about the details. The issue here is that most cleanup tasks are textbook cases of WP:CONTEXTBOT. Specific tasks, like tagging with {{Uncategorized}}, would probably be OK, because there is a clear, well-defined criteria for tagging, but things like {{Lead too long}} are simply too arbitrary to botify. Headbomb {t · c · p · b} 20:19, 5 March 2020 (UTC)
Tagging is not cleanup. It is just pushing the problem into the future and drawing attention. Too many tags is a disservice to our readers as adding clutter. Particularly with "lead too long", it just adds to the length! Certainly automated proding is just destructive. It would be much better if your proposed bot finds sources for an unsourced page. Graeme Bartlett (talk) 22:35, 5 March 2020 (UTC)
Thanks for all your opinions. I just went over all the tags, and believe that these tags may be added by bots:
Possible tasks
  1. {{All plot}}: almost entirely a plot summary
  2. {{BLP sources}}: BLP that needs additional sources for verification
  3. {{BLP unsourced}}: BLP that has no sources at all (use BLP PROD instead for new articles)
  4. {{Cleanup bare URLs}}: uses bare URLs for references, which are prone to link rot
  5. {{Condense}}: too many section headers dividing up content
  6. {{Dead end}}: article has no links to other articles
  7. {{In use}}: undergoing a major edit for a short while
  8. {{Lead missing}}: no lead section
  9. {{Lead too short}}: lead section is too short and should be expanded to summarize key points
  10. {{No footnotes}}: has references, but lacks inline citations
  11. {{No plot}}: needs a plot summary
  12. {{Not English}}: written in a language other than English and needs translation
  13. {{One source}}: relies largely or entirely on a single source
  14. {{Orphan}}: linked to from no other articles
  15. {{Overlinked}}: too many duplicate and/or irrelevant links to other articles
  16. {{Overly detailed}}: excessive amount of intricate detail
  17. {{Over-quotation}}: too many or too-lengthy quotations for an encyclopedic entry
  18. {{Sections}}: needs to be divided into sections by topic
  19. {{Uncategorized}}: not added to any categories
  20. {{Underlinked}}: needs more wikilinks to other arti/* Bot proposal (from Teahouse) */ cles
  21. {{Unreferenced}}: does not cite any sources at all
  22. {{Update}}: needs additional up-to-date information added

Those with an @ indicate that the bot may fix the problem itself.

I hope the bot could be able to complete the above tasks! If you believe that the bot can do something more, please tell me!; thanks! tLoM (The Lord of Math) (Message) 01:13, 6 March 2020 (UTC)

For the PROD part I meant BLPPROD. The guidelines said that unsourced articles may be nominated for BLPPROD. Would it be better now? tLoM (The Lord of Math) (Message) 01:23, 6 March 2020 (UTC)
tLoM, how will your bot detect articles that contain only Wikipedia:General references or manual Wikipedia:Parenthetical referencing?
Also, what makes you believe that the general maintenance tags actually do anything useful? Very few editors are just hanging around and waiting for a tag to appear on a favorite article.
As for the specific tags you've highlighted, {{In use}} is completely inappropriate (how would a bot know whether I'm still working on it, or if I've gone to bed?), {{orphan}} is one step away from being deprecated (it doesn't even display on the article unless there are multiple issues), and except in extreme cases (like just one outgoing link), {{underlinked}} is a matter of judgment and therefore not suitable for a bot. I think this is generally a bad idea (tagging articles is not a useful activity in general), and I specifically think that half of the ones you're considering are inappropriate for any bot, and I would think that even if I thought that WP:OVERTAGGING weren't a serious problem. WhatamIdoing (talk) 04:43, 6 March 2020 (UTC)
@WhatamIdoing: Yep, but after all this long list can always be changed! There are so many articles that goes forgotten after creation (one of my first articles took over 1 month for a review), so I believe that it may, for instance, highlight some more egregious problems. Some of these aren't that well thought out, but I believe that a bot can at least deal with certain tagging (e.g. lack of sources) and BLPPRODding problems. (Someone recommended adding sources by the bot, but I believe it leads to a lot of false positive. Besides, it's my first bot and I'm not an advanced programmer.) Thanks! tLoM (The Lord of Math) (Message) 04:53, 6 March 2020 (UTC)
Have you considered writing a bot to remove tags, rather than to add them? For example, if there is any URL in the wikitext source and any ref tag, then remove {{unsourced}}. Or if there is an incoming link, then remove {{orphan}}. Things like that should be less controversial. WhatamIdoing (talk) 06:02, 6 March 2020 (UTC)

Of the above, the vast majority are WP:CONTEXTBOT snow fails. Only #4 {{Cleanup bare URLs}}, #6 {{Dead end}}, #14 {{Orphan}} (when zero articles link to the page), #19 {{Uncategorized}} and #20 {{Underlinked}} (when there is zero links) possibly #7 {{Lead missing}} would make possibly good bot tasks. Everything else has too many cornercases, exceptions, or lack consensus to do by bots. Headbomb {t · c · p · b} 05:44, 6 March 2020 (UTC)

@The Lord of Math: If you're interested in bot tasks, you may find it helpful to browse through some of the examples at WP:BOTREQ to get a sense of what kinds of things bots are and are not capable of doing. Your proposal reminds me very much of myself a while back, when I came to BOTREQ arguing for the creation of a bot to perform what I thought was a pretty simple and straightforward task. After looking around a bit more and receiving some gentle socratic prodding from more experienced editors, I came to realize how big of an issue WP:CONTEXTBOT is and scaled back my request. Sdkb (talk) 06:31, 6 March 2020 (UTC)
@Sdkb: This is exactly why I decided to come here. But while some of the tasks may prove controversial, I believe that there are several uncontroversial tasks that a bot may be capable of doing:
  1. auto WP:PRODding of BLPs after, say, a week;
  2. Tagging articles as "Unreferenced" or "One source";
  3. Tagging articles as "No lead section".

Would you please give some review and improve the detail before I go to WP:VP/PR. Thanks! tLoM (The Lord of Math) (Message) 06:42, 6 March 2020 (UTC)

@The Lord of Math: Several editors here have already given you generous feedback on why most of your proposals are inappropriate. Please internalize their feedback, even if it's not what you're hoping to hear, before proceeding further. In my view, it would be inappropriate to go to WP:VP/PR, as that is a centralized forum for project-wide concerns, whereas a centralized forum for bot tasks already exists at WP:BOTREQ. Sdkb (talk) 06:49, 6 March 2020 (UTC)
@WhatamIdoing and Sdkb: (edit conflict) Removing tags is definitely a great idea that I've never thought of before. Removal of many tags is definitely less controversial. So let me sum up what we've got:
Possible tasks
  • Adding of these tags:
  1. {{Dead end}}
  2. {{Orphan}}
  3. {{Uncategorized}}
  4. {{Underlinked}} (only when very few links are present and article is sufficiently long)
  5. {{Lead missing}}
  6. {{Unsourced}} and its BLP variants;
  • Removal of these tags: (list not yet cleaned up)
  1. {{BLP sources}}: BLP that needs additional sources for verification
  2. {{BLP unsourced}}: BLP that has no sources at all (use BLP PROD instead for new articles)
  3. {{Cleanup bare URLs}}: uses bare URLs for references, which are prone to link rot
  4. {{Dead end}}: article has no links to other articles
  5. {{In use}}: undergoing a major edit for a short while
  6. {{Lead missing}}: no lead section
  7. {{No footnotes}}: has references, but lacks inline citations
  8. {{Not English}}: written in a language other than English and needs translation
  9. {{One source}}: relies largely or entirely on a single source
  10. {{Orphan}}: linked to from no other articles
  11. {{Overlinked}}: too many duplicate and/or irrelevant links to other articles
  12. {{Overly detailed}}: excessive amount of intricate detail
  13. {{Uncategorized}}: not added to any categories
  14. {{Underlinked}}: needs more wikilinks to other articles
  15. {{Unreferenced}}: does not cite any sources at all
  • BLP PRODding unsourced BLPs created recently

If you could improve or restrict this list, please do so. Thanks! tLoM (The Lord of Math) (Message) 06:54, 6 March 2020 (UTC)

Just to reiterate, I'm definitely not going to take it to WP:VP/PR just yet. I'd still need to perfect it so that everyone finds the plan acceptable. Thanks! tLoM (The Lord of Math) (Message) 06:55, 6 March 2020 (UTC)
  • Please do not hide comments that you don't like by collapsing them. People have spent time and effort telling you what thay think of your idea, so it is discourteous to hide their comments in this way. I would not trust anyone who thought that was a good idea with writing a bot. And secondly, you have things the wrong way round here. The thought process should not be "I want to write a bot, so what should it do?", but "I can see a problem, and a bot is the best way to solve it". Phil Bridger (talk) 08:53, 6 March 2020 (UTC)
@Phil Bridger: Okay, seriously I didn't intend to do that. Thanks for teaching me. But anyway if you're here, could you help me? My questions haven't been completely answered. Sorry about that, but thanks! tLoM (The Lord of Math) (Message) 08:56, 6 March 2020 (UTC)
Oops. But adding to the previous post, I had a basic framework for what a bot could do (tag/untag a page), and then the reason why I'm here is to ask for what should the bot specifically do, not whether doing something is okay for a bot. That's why I've came up with the list above and am asking for opinion on the list. I hope I've made myself clear. Thanks! tLoM (The Lord of Math) (Message) 09:03, 6 March 2020 (UTC)
The specific reason is that bots are not that smart, and unless you can come up with clear criteria for tagging, and gain consensus for those tasks, they will simply not happen. Consider what you probably thing is a simple straightforward case {{Unreferenced}}. How does a bot determine that an article is unreferenced? The lack of <ref></ref>? That forgets inline citations like "According to Hoyle (1944), ...". The absence of a ==References== section? They might be disguised as external links or further reading sections. Etc. Headbomb {t · c · p · b} 09:26, 6 March 2020 (UTC)
@Headbomb: Yep, some can't be done by bots, so perhaps a bot can put them in a tracking category like "Category:Articles possibly lacking sources" and leave it to a human for review? tLoM (The Lord of Math) (Message) 10:34, 6 March 2020 (UTC)
@Headbomb, Sdkb, Phil Bridger, and WhatamIdoing: pinging everyone -- let me reorganize what might the bot be capable of doing:
Possible bot tasks, transcluded from User:The Lord of Math/bot tasks planning
  • Adding of these tags:
  1. {{Dead end}}
  2. {{Orphan}}
  3. {{Underlinked}} (only when very few links are present and article is sufficiently long)
  4. {{Lead missing}}
  • Removal of these tags: (list not yet cleaned up)
  1. {{BLP sources}}: BLP that needs additional sources for verification
    • criteria: source found
      • <ref></ref> tags found
      • nonempty == Further reading == section found
  2. {{BLP unsourced}}: BLP that has no sources at all (use BLP PROD instead for new articles)
    • criteria: same as above
  3. {{Cleanup bare URLs}}: uses bare URLs for references, which are prone to link rot
  4. {{Dead end}}: article has no links to other articles
    • criteria: link ([[...]]) found (plain link preferred; infobox not counted)
  5. {{In use}}: undergoing a major edit for a short while
    • criteria: unedited for over 2 hours
  6. {{Lead missing}}: no lead section
    • criteria: lead found
  7. {{No footnotes}}: has references, but lacks inline citations
    • criteria: <ref></ref> tags found
  8. {{Orphan}}: linked to from no other articles
    • criteria: deorphaned (linked to from over 2 articles)
  9. {{Uncategorized}}: not added to any categories
    • criteria: has at least 2 categories
  10. {{Unreferenced}}: does not cite any sources at all
  • BLP PRODding unsourced BLPs created recently
    • criteria: created in past 7 days and still unsourced
If you'd like to change the page, please feel free to improve it at User:The Lord of Math/bot tasks planning! Thanks! tLoM (The Lord of Math) (Message) 13:09, 6 March 2020 (UTC)
@The Lord of Math: Replying to the original message that started all of this:
Consider doing this in a semi-automated fashion.
Write a page-scanning script that will identify pages that might benefit from things like having templates added or removed, then saving the output to someplace like User:The Lord of Math/PagesNeedingAttention/todaysdatehere broken down by sections with what is wrong, like User:The Lord of Math/PagesNeedingAttention/todaysdatehere § Possibly no sources. Then write user-scripts we as editors can install that will add tags manually with a click of a button AND mark the item in the list as reviewed. This way, I as an editor can click on a link in your list, review it, then use a user-script you write to click one of two buttons: "False alarm" or "bag and tag." If I click "false alarm" it adds the page to a whitelist so the page is ignored the next time you run the page-scanning script. If I click "bag and tag" it applies the template or does whatever other changes is needed. In either case, it removes the page from the list since that page is "done" as far as the page-scanning script is concerned.
If you don't have the skills to write scripts, find people who do.
You do not need approval to write tools that are semi-automated as long as they don't make "suprise edits," as the users of the tools will be held responsible for all edits made by the tools, same as any other edit. See Wikipedia:User scripts for details on user scripts and links to lists of existing scripts. davidwr/(talk)/(contribs) 17:00, 6 March 2020 (UTC)
In terms of the list, {{Uncategorized}} is a waste of time. We don't need a bot to duplicate Special:UncategorizedPages, especially since many of these articles need someone to click 'Undo' on the edit that removed the cats. Also, at any given point in time, there are just a couple of uncat'd articles (out of 6,027,489 articles). WhatamIdoing (talk) 17:39, 6 March 2020 (UTC)
But if you said of "putting the output in userspace", then why can't I write a bot that reads articles and pipes the output to userspace? As per WP:BOTUSERSPACE, I don't think it needs prior approval. Thanks! tLoM (The Lord of Math) (Message) 02:47, 7 March 2020 (UTC)
This discussion really is starting to feel like the real goal is to just have a bot, no matter how pointless it actually is. WhatamIdoing (talk) 19:58, 7 March 2020 (UTC)
Yes, exactly, and it hasn't just started to feel like that. This was the point of the second half of my post here. I have tried to refrain from quoting a cliché, but I don't think I can do any better than say that this is a textbook case of a solution in search of a problem. Phil Bridger (talk) 21:25, 7 March 2020 (UTC)

Some thought from a bot maker..

  • We have a bot for {{Cleanup bare URLs}}. Anyone can run it. The control page is Template:Cleanup_bare_URLs/bot. It requires users to clean up the links or it won't keep running to keep the number of tagged pages from going critical.
  • I wrote a bot to add {{unsourced}}. It added about 10,000. It was non-trivial taking months of testing due to endless edge case exceptions and community pressure about not making mistakes.
  • Bots like this are hard, more then they appear ie. how hard can it be to find articles without a reference? The answer is damned hard, if you want 99% accuracy. As someone else already mentioned, the low hanging fruit of bot work is mostly done, what is left is probably because it is hard, not because it's a new idea. We need creative new approaches to old problems, like the Cleanup bare URLs system. Very few people use the Cleanup bare URLs system. Like, one person. They have fixed about 0.001 of the articles with bare links. -- GreenC 20:25, 7 March 2020 (UTC)
Okay, thanks for your opinion. As mentioned about, it emerged that instead of editing the actual pages, it might be better to save everything to my userspace and let a person sort that out. I guess the safest things to do are:
  1. write a userspace bot that logs these pages, or
  2. refraining to write a bot altogether.
I guess it can (kind of) solve the problem, and besides, it's not hard to write such a userspace bot. So is there anything wrong with this idea, bring everything all under userspace? Thanks. tLoM (The Lord of Math) (Message) 11:28, 8 March 2020 (UTC)
An addendum: if it is not okay then I may as well make it a semi- or non-automated process. tLoM (The Lord of Math) (Message) 11:40, 8 March 2020 (UTC)
Before you spend too much time on this you should check to see whether what you want to do has been done before. I don't use any semi-automated tools myself but understand that AWB can suggest many potential tags to put on articles. Phil Bridger (talk) 11:50, 8 March 2020 (UTC)

Straw poll: Disincentivize spam by reducing Search Engine impact

If Wikipedia told search engines not to index articles until it is either patrolled or it has been an artricle page for 10 consecutive days, that would cut down on spammers, since spam would likely be deleted during those 10 days.

While this could be implimented today with some "clever/hackish" use of existing tools, doing it right requires software changes, so don't expect it this year even if there is a huge demand.

If there is support I will make a more formal proposal on Wikipedia:Village pump (proposals). davidwr/(talk)/(contribs) 17:41, 7 March 2020 (UTC)

davidwr, this already happens, except that we do it for 90 days. WhatamIdoing (talk) 19:56, 7 March 2020 (UTC)
Explained a little bit further on the page WP:NOINDEX. Most spammers probably aren't even aware of this limitation. – Thjarkur (talk) 18:51, 8 March 2020 (UTC)
Thanks, I'll make a new straw poll about modifying the text that appears when a new page is created AND extending the rule to include pages moved TO article space (albeit for a shorter period of time), to make it much harder to game the system with user-space or other drafts. davidwr/(talk)/(contribs) 16:34, 9 March 2020 (UTC)
@Davidwr: - if you move a draft to mainspace, it still needs patrolling before it is indexable (unless you are autopatrolled) Nosebagbear (talk) 11:23, 10 March 2020 (UTC)

Dark/Night Mode and Color Themes

Hello everybody!

This is my first post on Wikipedia but this looks like the best place to make a suggestion. Would it be possible for us to create a dark/night mode for Wikipedia, so that instead of the classic white and grey background, it could perhaps be black and dark grey? It could not only look really cool, but also be easier on people's eyes if they were viewing at night. Also, maybe users could toggle it on and off so it could be their default way of seeing Wikipedia articles if they so chose. I'd love to help but don't know how to code--does anybody have any ideas/suggestions on how to make this happen?

One other idea would be to offer color themes that people could choose from or create their own. I wonder if it would be a way to help people personalize Wikipedia a bit more for themselves--or do y'all think that would detract from the purpose of the site?

Best, Caleb

We should do this the same way it already exists in the mobile app. El Millo (talk) 19:41, 11 March 2020 (UTC)
Dark Mode toggle.--Moxy 🍁 00:33, 12 March 2020 (UTC)

Discussing how to write an FAQ that addresses a talk page topic

I think it would be useful to know how and when a talk page subject should become an FAQ section.

What would be the best way of discussing this with people that have done it? --ProbablyAndrewKuznetsov (talk) 05:50, 26 February 2020 (UTC)

This editor asked a very similar question at Wikipedia:Village pump (miscellaneous)/Archive 64#Learning how to write a good FAQ section for a talk page. Let's centralize any discussion there. WhatamIdoing (talk) 04:35, 6 March 2020 (UTC)

Idea for a new community navigation template

I have a new idea for a community navigation template, which I have created at the page below. what do you think of this? I created this by using code from the Wikipedia: Community portal, and then adding some further links. feel free to let me know what you think. is this useful? thanks.

thanks. --Sm8900 (talk) 01:40, 12 March 2020 (UTC)

At the recent ANI you said you'd follow the advice you were being given (basically, do normal editing rather than coming up with new ideas). DexDor (talk) 12:30, 12 March 2020 (UTC)
hi DexDor. just to reply to your note above, I am indeed following the advice I was given. the advice was to seek consensus, to act deliberatively. to use the established channels to obtain consensus before proceeding with any changes. and to not post notice in multiple locations, but rather to use one single forum that is most appropriate for discussing the idea with the community, rather than multiple locations. that is precisely what I am doing here. so I am accepting that advice completely.
In the future, I would appreciate if we could please not debate about whether I can or cannot edit in any particular areas of the project. I do think you absolutely mean well, and I think you are a highly valuable, conscientious, diligent and knowledgeable editor who acts purely out of concern for the best interests of Wikipedia. so I highly, highly respect your insights. however, I would like to dispense with the topic of whether I can or cannot edit any particular area, especially in this case, where I am using a thoroughly appropriate forum. as I noted, I will absolutely glad to be much more aware of the discursive and deliberative processes here, and to respect them more deeply, and more thoughtfully.
I absolutely think that your great experience and wisdom is a major asset to the project and to the community, and I am glad to express that here. I would simply, gently point out, that in our communications, we should both strive to adhere to WP:AGF, and WP:Civility. I think you are a very conscientious editor, so I feel very confident that this note will be sufficient to address any such issue.
In closing, let me just note that I do hope to comment at various intervals on various items which may come up here. Obviously, you are free to comment on any such items, as a highly-respected, experienced, and knowledgeable editor. I would appreciate it if we could please dispense with the issue of whether I can or cannot edit in regards to any particular topics, items or areas here. Let me just reiterate, I think that all of your work here is extremely valuable, insightful, and of great benefit. I look forward to benefiting from your considerable insight and expertise in the future. I appreciate you taking the time to write. thanks. --Sm8900 (talk) 14:05, 12 March 2020 (UTC)
You're taking on too much, again. Recommend you try gnome editing. GoodDay (talk) 20:27, 12 March 2020 (UTC)
The idea that this is "too much" seems... rather overblown. We're talking about a minor revamp to the top part of WP:COM: to use a bullet point form of the intro, and the addition of two links boxes (CP, RFC). I'm generally indifferent to it, but I'll say that adding a CP link to the CP header is pointless because you're already there. Also the intro should not assume that users are new. First state what the page is about, because thats' relevant to everyone. Then give advice to newbies. Headbomb {t · c · p · b} 20:42, 12 March 2020 (UTC)
thank you, Headbomb. GoodDay, I do appreciate your input. I know that you definitely mean well. I'd appreciate if we could please try to avoid personal comments. the topic of this section is simply this proposal. Headbomb, those are good points. however, my reason for proposing this nav box was to suggest it for use in other locations, in addition to its current use on WP:COM. One group of potential locations might be the other places linked to from this nav box itself. so therefore, for example, another place that we might put this nav box might be Dispute Resolution, or Requests for Comment, or Reference Desk, or in other words, any of the other sites featured as links within this nav box. I appreciate your input. Open to any comments on this. thanks. --Sm8900 (talk) 21:37, 12 March 2020 (UTC)
If the idea is to put this on other pages than WP:COM, then I'm against that. Headbomb {t · c · p · b} 21:40, 12 March 2020 (UTC)
Headbomb okay, fair enough. based on your comments above, I have edited the draft. I appreciate your taking the time to look at this draft and provide the input above. If you have a chance, could you please let me know your opinion of the current version? thanks. --Sm8900 (talk) 22:02, 12 March 2020 (UTC)
My opinion is general unchanged. The 'intro' bit is now better/closer to the current version. Still against this being put on other pages. Headbomb {t · c · p · b} 22:08, 12 March 2020 (UTC)
I understand. by the way, thank you for the edits that you made to this draft document. those edits look totally fine, and much improved. thanks!!! Thumbs up icon --Sm8900 (talk) 13:25, 13 March 2020 (UTC)

Corona Prevention Video

Here's a hand sanitization related video that is claiming to be in C.C license. Can it be used in any corona related articles ?

And secondly, can any wiki community create a prevention/ awareness related video in English language so that it can be used in corona related articles ?

And please put some thoughts about "wiki community & corona" in here . THANKS .--Masum The Great (talk) 09:26, 22 March 2020 (UTC)

Standard format to squeeze IABot sections on talk pages

InternetArchiveBot (IABot) is wonderful. It automatically fixes some dead links by linking to historic versions of the same pages on Internet Archive. Then it leaves substantial messages on talk pages. Those message get old or out of date, sometimes because a human editor confirms the edit was good. I would like to squeeze those messages down, because they take space and more importantly they put a cognitive load on readers, especially new editors.

Here's an experiment with an approach I like. See Talk:Vera Berdich.

By pasting in a block of wikicode above and below the IABot message, we put it into a show/hide box. Thus the message is not forgotten but a visitor to the page doesn't have to parse it. We can put multiple IABot messages into such a box. I copied the box from the magnificently formatted Clausius–Duhem inequality. I propose to do this by hand, ad hoc. If it goes well for a while then perhaps a bot can do this.

Is that a good practice? Or is there another way to accomplish this sort of cleanup? I could just delete the IABot sections. I have also posted the question to the IRC for IABot. -- econterms (talk) 20:42, 13 March 2020 (UTC)

My understanding is that these messages are no longer left on the talk page by the bot. Which is good. Others must have agreed that the messages were close to inactionable, and placed too much low-value text on many many talk pages. (I delete them when I happen to be otherwise editing a talk page.) Outriggr (talk) 10:18, 14 March 2020 (UTC)
There was indeed such a discussion, although I believe we concluded that nobody was acting on them, rather than it being impossible to act upon them. I also blank those old messages on occasion. WhatamIdoing (talk) 04:34, 17 March 2020 (UTC)
Thank you folks. I'll proceed to use the new template. It may be smarter to delete the messages instead but I prefer the template. -- econterms (talk) 19:06, 23 March 2020 (UTC)

RFC: Video for Deletion

April Fool. Robert McClenon (talk) 02:51, 3 April 2020 (UTC)

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

The purpose of this paper is to propose an additional deletion forum, which will be Videos for Review for clips in the Timed Text namespace. (This will of course also include audio clips in the Timed Text namespace, but AFD would not be unambiguous.) There have been three clips nominated for deletion at MFD, and that implies that there may be a substantial number of these clips for deletion coming in, and a separate forum for their discussion is in order. Video and audio that are in the MediaWiki namespace can also be nominated for deletion here.

Shortcut

Enter your support or opposition in the Survey. Provide detailed ideas for how this will be implemented, such as whether each clip will have a separate discussion page or whether there will be a daily structure, in the Detailed Proposals. Threaded discussion may be in the Threaded Discussion section. It should be restated that the second pillar of Wikipedia still does apply to stupid comments in the Threaded Discussion, although many of the comments in any Threaded Discussion are stupid. — Preceding unsigned comment added by Robert McClenon (talk • contribs) 00:13, 1 April 2020 (UTC)

Survey

Threaded Discussion

  • oppose. Premature RfC. Please discuss issues and form some collaborative ideas before launching heavy weight RfCs.
Why would FfD not suffice? More forums do not usually make for better forums. —SmokeyJoe (talk) 00:24, 1 April 2020 (UTC)

Detailed Proposals

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.

Want Quiz for every article

At past it was discussed in the page https://meta.wikimedia.org/wiki/Grants:IdeaLab/Wikimuseum,_Wikiquiz_and_Wiki-interative however I dont have enough programming knowledge. I request other users to take up the project and build a flashcard type quize for every article.

RIT RAJARSHI (talk) 07:08, 2 April 2020 (UTC)

A quiz for every article is extremely ambitious. To create quizzes for some of our articles using free flashcard software shouldn't need any programming knowledge, but I'm not sure where the best place to host such quizzes would be. Phil Bridger (talk) 07:36, 2 April 2020 (UTC)
@Phil Bridger:Thank you I did not meant it to be created immediately. But this feature could be greatly helpful and engaging.
I am submitting an image to express what I am thinking about.
Wiki Quiz Sample
Wiki Quiz Sample
@RIT RAJARSHI: Per WP:NOT, I think there would be some objection that quizzes aren't encyclopedic and not where we should be focusing our attention. But you might have luck at one of our sister projects, Wikiversity. {{u|Sdkb}} talk 13:17, 2 April 2020 (UTC)

@Sdkb: One way could be Wikiversity can host the quiz but it will be linked to Wikipedia pages. In cases of Wikipedia page merge the associated quizes may be merged by some bot. RIT RAJARSHI (talk) 15:23, 2 April 2020 (UTC)

@all I have created a discussion in Wikiversity https://en.wikiversity.org/wiki/Wikiversity:Colloquium#Requesting_flashcard_stule_quiz_for_all_Wikipedia_pages. RIT RAJARSHI (talk) 15:26, 2 April 2020 (UTC)

Related pages (but I cannot put anything at their talk page idk why): https://en.wikiversity.org/wiki/Quiz

Thank you all 2409:4060:2105:5F69:8859:8BF9:BF08:D3AE (talk) 20:02, 2 April 2020 (UTC) https://en.wikiversity.org/wiki/Test_and_Quiz https://en.wikiversity.org/wiki/Quizbank

RIT RAJARSHI (talk) 15:32, 2 April 2020 (UTC)

This would be a good addition to Wikiversity, to be honest. Take it up on their version of the Village Pump. Catgirllover4ever (talk) 17:54, 2 April 2020 (UTC)


Thank to you all RIT RAJARSHI (talk) 20:06, 2 April 2020 (UTC) (I was logged out somehow so the signature was weird, IP).

Updating the left sidebar

I am closing this discussion as the RfC will be launched momentarily at Wikipedia:Requests for comment/2020 left sidebar update. Further comments should go there. {{u|Sdkb}} talk 21:37, 10 April 2020 (UTC)

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

So, given all the free time we have, I'm thinking about taking on a fairly big task: trying to build a consensus to revamp the links in the sidebar that appears at the left of every page to improve usability and ease of navigation. This issue was last raised, as far as I can tell, in 2013 by Steven Walling (now retired) in an RfC that has a subpage here. The close (by Keithbob) noted that All participants seemed to agree that the sidebar's content, design and appearance could be improved but that there was a wide variety of suggested changes none of which appeared to have universal support, so no changes were implemented. I would've supported most of them had I been around in 2013. The design of the sidebar appears not to have changed noticeably since then. I'm hoping to kick off a more formalized proposal at some point, but for testing the waters at the idea lab here, some questions:

  1. Have there been any big changes to or discussions about the left sidebar since 2013 that I've missed and should review?
  2. Which WikiProjects or other venues on Wikipedia might be interested in this and able to help me craft a solid proposal?
  3. How would you suggest bringing up the proposal/organizing the discussion to avoid the pitfalls that seem to have foiled the last update attempt?
  4. Any other advice you'd give going into an initiative like this?

Cheers, Sdkb (talk) 21:02, 26 March 2020 (UTC)

(Seems to be a thing going around, people thinking about new design proposals. I've been writing up a proposal for redesigning the preferences page. :) )
Sidebar changes since 2013: The "In other projects" section was added when Wikidata became capable of supporting it, and the "Create a book" link was removed by consensus in a few months ago after this discussion.
My recommendations: Any parts of the proposal that can be divided should be divided. Smaller/simpler proposals are easier to get done. For larger changes, figure out the details before launching the actual RfC. --Yair rand (talk) 22:03, 26 March 2020 (UTC)
  • @Sdkb:, Can't really help on the first two questions. I'd suggest a more informal discussion amongst those particularly interested, to filter the process down to, say, 3 good possibilities (plus no change). Then encourage, in the intro, people to give ranked choices. You can't demand such, but those who would like some change, any change, might specify, reducing the chances of "yes change, no to any specific change". Nosebagbear (talk) 14:18, 27 March 2020 (UTC)
@Sdkb: You should check out the desktop improvements project at the WMF, which is going to explore some potential improvements to the sidebar. Sam Walton (talk) 14:52, 27 March 2020 (UTC)
@Sdkb: Don't forget that the appearance and location of links can vary based on which skin you are using (more so for Timeless than other skins). It's not necessarily a single sidebar that appears at the left of every page. - Evad37 [talk] 15:34, 27 March 2020 (UTC)
@Yair rand, Nosebagbear, Samwalton9, and Evad37: Thank you all — those comments are super helpful! Mulling it over, I think the first change I'd want to pursue would just be the re-ordering, to better separate the links for readers and the links for contributors (move "about", "help", and "contact" up) and to separate the page-specific tools in the toolbox from the more general contributing pages (move "special pages" and "upload file" up to the latter section). It seems like a pretty intuitive fix, but for an area that visible, I'm guessing it may not be as easy to enact as I'd wish. Is that your sense of things, too? I reached out to WP:WikiProject Usability, but it seems very inactive, so not sure there's anyone there to help. Sdkb (talk) 07:31, 30 March 2020 (UTC)
@Sdkb: I like the idea of redesigning the sidebar. I created a move discussion here regarding if we should title the Main Page into sentence case. As of right now, the consensus seems to be against it. If the move discussion closes with a consensus not to move the page, then I think we should capitalize the "p" in the sidebar. If we decide to revise the sidebar, then I think editors should throw ideas into what links should be removed from the sidebar and what links should be added. These are just my thoughts. Interstellarity (talk) 19:28, 1 April 2020 (UTC)
@Interstellarity: Where do you think would be the most appropriate place to start developing a draft proposal/proposals? Sdkb (talk) 19:35, 1 April 2020 (UTC)
@Sdkb: Maybe an RFC. Interstellarity (talk) 20:01, 1 April 2020 (UTC)
@Interstellarity: I'm thinking more a space that'd allow the proposals to be drafted rather than !voted on. I'd prefer to not be alone in formulating the proposal that'd be then be brought in front of a wider audience for something like an RfC that could lead to consensus for adoption. Sdkb (talk) 20:04, 1 April 2020 (UTC)
@Sdkb: I thought about this and I think the links to WP:Featured content and Portal:Current events should be removed. I also think WP:Community portal should be replaced with WP:Dashboard while I think WP:FAQ and WP:Maintenance should be added. You are welcome to disagree with me on this. What are your thoughts? Interstellarity (talk) 20:16, 1 April 2020 (UTC)
@Interstellarity: Woah, my main thought is that those proposals would be a massive restructuring and would generate a massive amount of opposition (e.g. considering the recent portal drama, I doubt they'd take kindly to the idea to remove Current events). Given the previous difficulties reaching consensus in 2013 and the advice above, I'm inclined to start with a much more modest proposal that sticks to reordering without adding/removing anything.
Since you brought up some specific ideas, though, briefly: I'm not inclined to remove Portal:Current events given its massive pageview stats compared even to the other sidebar links. I'd be fine taking out WP:Featured content, since it's just not how people tend to browse. Make it a sidebar or something at the WP:Contents page and keep just that one. I'd oppose replacing the Community portal with the Dashboard — the community portal is explicitly designed to be the landing spot, and it's evolved to fill that role. Anything else would be inappropriate. I'd oppose adding WP:Maintenance — there's only room for one editor landing page on the sidebar, and that's the community portal (plus I prefer the Task Center for newcomers, and sidebar links need to be newcomer-friendly). I'd similarly oppose adding WP:FAQ, since there's only room for one help page and one about page, and those are Help:Contents and Wikipedia:About, respectively (I'm also not convinced that FAQs are a useful format for those with questions, and the FAQ system needs a massive revamp anyways).
As I said above, the main proposal I'm considering launching is just to re-order a few things, to give better weight to more/less important items, and to make them categorized more intuitively. Right now, I'm hugely bugged by the mixing of pages for readers and pages for editors — I think WP needs to do a much better job preventing those from bleeding into each other. Sdkb (talk) 20:47, 1 April 2020 (UTC)
@Sdkb: I started an RFC here by proposing that we capitalize the "p" in Main Page and removing WP:Featured content. I did say that I am open to reorganizing the links, removing some, and adding some. As always, you are welcome to comment on it. Interstellarity (talk) 21:17, 1 April 2020 (UTC)
@Interstellarity: If it's alright, I'm going to move your proposal to draft space for now. Modifying the sidebar is a huge impactful change that will be seen by every English-language visitor to one of the world's biggest websites. If there's going to be a single RfC page for it, it needs to be fully fleshed out, listing precedents, starting principles, etc. that reflect thorough consideration. See the 2013 example for an idea of what that looks like. The few sentences you wrote, while fine, are nowhere near that, and you are not incorporating the advice of others above to separate out separate proposals. I'd love to have your help with this, but it'll be useful to do a little more research before jumping in. Sdkb (talk) 21:36, 1 April 2020 (UTC)
@Sdkb: I originally moved the RFC somewhere and an admin deleted it, but I removed it because a user suggested not starting it yet. Maybe we can get some ideas on how we can restructure the sidebar before proposing anything. Interstellarity (talk) 22:19, 1 April 2020 (UTC)

Draft set of proposals

@Yair rand, Nosebagbear, Samwalton9, Evad37, and Interstellarity: Okay, I wrote out a draft set of proposals! Here it is: Draft:Wikipedia:Requests for comment/2020 left sidebar update. Your feedback would be much appreciated! One question I have: where would it be most appropriate for the RfC to reside — on VPPR or as its own page? (I plan to link to it from WP:CENT either way.) It'd also be helpful to know if there is any background regarding collapsing that I should read up on. Cheers, {{u|Sdkb}} talk 08:18, 4 April 2020 (UTC)

@Sdkb: I recommend having this on its own page. I think if this were at WP:VPPR, then it would probably be moved to its own page due to the length of the discussion. This is my thought. Interstellarity (talk) 11:26, 4 April 2020 (UTC)
Agree that it's own page makes sense. I do think we should consider closer how this work might overlap with the planned desktop refresh work linked above, particularly with regards to things like auto-collapsing sections. I've pinged the team responsible to make them aware of this RfC and see if they have anything to add :) Sam Walton (talk) 11:37, 4 April 2020 (UTC)
@Samwalton9: Thanks! I posted previously at the project discussion page, but not sure if everyone involved follows that. {{u|Sdkb}} talk 15:29, 4 April 2020 (UTC)
Hey Sdkb. Of course we do follow that page :) We're working on our reply. Please stay tuned! And thanks Samwalton9 for mentioning us here. SGrabarczuk (WMF) (talk) 20:30, 4 April 2020 (UTC)
@Sdkb: In your proposal, can you include a proposal to capitalize the 'P' in Main page? Interstellarity (talk) 18:19, 5 April 2020 (UTC)
@Interstellarity: Sure, feel free to add it yourself in the renamings section, and be sure to link to the recent RM. {{u|Sdkb}} talk 19:12, 5 April 2020 (UTC)
@Sdkb: I added it. Interstellarity (talk) 20:16, 5 April 2020 (UTC)
  • @Sdkb: In the 2013 proposal, the "Donate" option was placed in the "Contribute" section, which makes sense to me. --Yair rand (talk) 20:59, 5 April 2020 (UTC)
    • @Yair rand: Yes, I went back and forth about that before deciding to keep it in the main section in my proposal. My rationale are that (a) donating is something that casual readers can/should do, so it's better to have the link in the section targeted at them, not editors, (b) moving it down could negatively affect the number of donations the WMF gets, and (c) the donate and merchandise links should be grouped together and it wouldn't make sense to put merchandise in the contributing section. That said, there's room for discussion on that, so feel free to comment once the RfC begins. {{u|Sdkb}} talk 21:41, 5 April 2020 (UTC)
      • I should also probably mention the other proposed change from 2013 I don't support, adding a "Create an Article" button. Creating an article is the worst task for a new editor to take on given its difficulty, so I think it's a bad idea to encourage it by including it in the sidebar. Again, though, if someone else feels differently there's room in the RfC as currently structured for that to be brought up and discussed. {{u|Sdkb}} talk 21:41, 5 April 2020 (UTC)
    • Regarding the languages collapsing, thank you for catching that. I had that setting turned off, but I don't remember turning it off, so maybe I was grandfathered in or maybe I just forgot I changed it. I just checked when logged out and it's indeed on by default. {{u|Sdkb}} talk 21:44, 5 April 2020 (UTC)
      @Sdkb: Do you think the RFC is ready to be moved yet? If not, what needs to be done in order to have it moved? Interstellarity (talk) 12:15, 6 April 2020 (UTC)
@Interstellarity: I'm waiting for the reply SGrabarczuk (WMF) said was forthcoming. Once we get that, assuming it doesn't contain any major wrenches, I think the RfC will be ready to launch. {{u|Sdkb}} talk 16:03, 6 April 2020 (UTC)
  • @Sdkb: again, thank you for taking our perspective into account. We really appreciate that. The Web team is going to make adjustments evolutionally, by small steps, with the guide of the gadgets existing locally on wikis, and on the basis of communities' feedback. As my friend says: How to eat an elephant? One bite at a time! Currently, the team is focusing on making the sidebar collapsible, and isn't going to work on changes to the selection or sequence of links or on the wording used in the sidebar, so its plans regarding the adjustments are parallel to, and not conflicting with your initiative.
    We believe this user research report might be helpful for you. In particular, I'd recommend you to take a look at the complete results where users claimed they didn't understand some links.
    Additionally, let's take a look at the interface screen to the right. Article tools are distinct from the links above them. Their function and target group are different. The report confirms that (I'd be surprised if it didn't!). In a more distant future, I believe it'd be beneficial to... strengthen their separation, i.e. remove them and put them somewhere else. But as I wrote, it's too early for the team to take a position on how, where or when exactly this should be done.
    I hope we would be in touch. Please watch our pages on MediaWiki wiki and don't hesitate to write directly on my talk page! SGrabarczuk (WMF) (talk) 12:48, 10 April 2020 (UTC)
    @SGrabarczuk (WMF): thanks for sharing that! I just read through the user research report, and it was helpful for providing more concrete evidence of phenomena. @Yair rand, Nosebagbear, Samwalton9, Evad37, and Interstellarity: I will be launching the RfC momentarily. Feel free to participate there. Cheers, {{u|Sdkb}} talk 21:36, 10 April 2020 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

New algorithm for unanswered peer reviews?

Side note: the following (except from the signature) is copied from a previous discussion at WT:PR. I was told to try and post it here.

Instead of the algorithm detecting the next edit after the page's creation, could we make it so that the algorithm detects when a user other than the person who created the page edits it? That way we wouldn't need the small box on the WP:PR/UA page. I'm not necessarily a tech person, so this might not be possible, but let me know if there are any other suggestions or queries. Thanks, Thatoneweirdwikier Say hi 05:37, 11 April 2020 (UTC)

As creator of the current approach, I directed Thatoneweirdwikier question here following their question at PR. I created the current code as an automatic way to give some idea of which PRs are and aren't unanswered, as I feel this is useful for people who want to contribute. However I just use a simple Wikicode check: if the page revision is unchanged from creation, then the review is marked as unanswered. I have used Wikicode, because we have had many problems with bots that periodically don't run every so often, which requires constant vigilance, and this is not an approach I am fond of. The approach Thatoneweirdwikier would request will require a check that only a single editor has editor the page, regardless of how many edits they have made. I'm not sure this can be done in Wikicode. --Tom (LT) (talk) 00:05, 21 April 2020 (UTC)

Redesigning some pages, WP:ABOUT WP:FAQ/Main WP:START WP:FC

I think the FAQ needs a makeover. Sdkb gave some great ideas on what a redesigned FAQ would look like. Here is a discussion with him. I started off by collapsing the questions diff. Not sure if this is a good change or not. I'd appreciate any thoughts regarding revamping the page. I also would like ideas on how we can redesign the About page, the WP:Contents page, or the WP:Featured content page? I can't really think of ideas at the moment. Interstellarity (talk) 23:32, 20 April 2020 (UTC)

Pls don't collapse sections and take away a TOC....basic accessibility should be your primary concern over how it looks. You have created an accessibility and mobile view nightmare. MOS:COLLAPSE.--Moxy 🍁 00:51, 21 April 2020 (UTC)
Along with the TOC accessibility problems seven of the sections on that page are small paragraphs and 4 are a sentence long. Now I wouldn't advocate for collapsing if they were bigger but it is totally unnecessary there. The links to other guideline articles are also hidden and editors should not have to click to open those sections to find them. MarnetteD|Talk 01:07, 21 April 2020 (UTC)
Did not get a chance to see.... but do the shortcut still working collapsible sections?..... this would also be a concern as many of the shortcuts are linked all over.--Moxy 🍁 01:24, 21 April 2020 (UTC)
They still work Moxy it is just that you can't see them with the sections collapsed and you have to take the extra step of opening each one to find them. MarnetteD|Talk 01:36, 21 April 2020 (UTC)
Good to hear.... just noticed a few other pages have this.. thus now wondering if anchors were needed... good to hear they're not....I also just tried and they work for me to.--Moxy 🍁 01:41, 21 April 2020 (UTC)
I'm not persuaded that MOS:COLLAPSE concerns should prevent us from doing so. Most other websites use an autocollapsed accordion design for the FAQs, and that's since it works well, allowing the questions themselves to turn into a TOC. That said, this isn't something I feel strongly enough about to go into battle over, given how rarely used the FAQ pages currently are. {{u|Sdkb}} talk 10:15, 21 April 2020 (UTC)
I hate when FAQs do this. An FAQ is a quick reference and collapsing questions causes anything but quick referencing. --Izno (talk) 18:32, 21 April 2020 (UTC)

Sockpuppets

I have an idea. What if we reuse sockpuppets. Not to disrupt Wikipedia, but for helping it. Here's how: 1. We rename the sock puppet to something like this: 284738sjdj2 2. We reuse the username for New accounts. Why? We are wasting good names that others might want to use. New3400 (talk) 01:02, 21 April 2020 (UTC)

Usurpation is occasionally done. Eman235/talk 02:54, 21 April 2020 (UTC)

Beyond that, if names started appearing people could easily react assuming they were a sock. I could also see appeals & unblock requests (which certainly are only rarely successful for an account blocked as a sock, but do occasionally) pass becoming more problematic. What if a name was changed, and given to a new user. The editor then successfully appeals and show's the block was unwarranted - but is now missing their name? But most importantly, it's very rare for a desired name to be unavailable due to a sock account blocking it, and we do have usurpation that slightly narrows that group. Nosebagbear (talk) 09:39, 21 April 2020 (UTC)

  • This isn't a decision we could make unilaterally. Renames are global and just because someone is blocked as a sock here, doesn't automatically mean they're not still in good standing on another project. For anything like this to work you'd need both to get cross-wiki agreement at Meta, and get the Stewards on board. ‑ Iridescent 20:45, 21 April 2020 (UTC)

Stewards? Ok. Can someone give me an list? Thanks. New3400 (talk) 14:19, 22 April 2020 (UTC)

Exactly where you'd expect such a list to be. My comment above is not a recommendation that you go and pester the stewards individually, and my mention of the Stewards is owing to the fact that they're the ones who'd have to do the actual renaming work on this, unless they're willing to participate there's no point even trying. The important part is you'd need to get cross-wiki agreement at Meta, as you're proposing a change that would impact every one of these 944 websites (most of whom have no love at all for English Wikipedia), and we can't just impose such a thing without their agreement. ‑ Iridescent 14:30, 22 April 2020 (UTC)
  • Oppose Other than if specifically requested via WP:USURP, I can't come up with how obfuscating patterns in sockfarms makes it easier for admins and checkusers to do their job.s --Jayron32 16:03, 23 April 2020 (UTC)

A technical question: (moved from the tea house)

How difficult would it be to have some function that suggests autocorrection for Templates and other markup? I noticed an minor edit by an experienced user correcting a template divider from a colon to a vertical line recently, so perhaps it isn’t only demiluddites like me who’d benefit from this.Qwirkle (talk) 21:18, 23 April 2020 (UTC)

I posted a similar suggestion at template talk:Non-free use rationale back in February but haven't gotten any responses. So we currently have close to one million non-free files hosted on the English Wikipedia. Ideally we want as many of those files as possible to be free and available on Wikimedia Commons. It wouldn't surprise me if the copyrights on some of those files have already expired.

Therefore, I'm thinking we should mark eligible items (excluding works by individual authors who are still alive) with the year the copyright is set to expire. Thoughts?

I've been starting to add {{out of copyright in}} to pages where applicable, but it's a lot of work to tag several hundred thousand pages! Ixfd64 (talk) 23:15, 27 April 2020 (UTC)

I think this is more a question of the amount of work needed (you need to be certain that the copyright expires at a certain date) than one about whether this is a good idea. Jo-Jo Eumerus (talk) 09:20, 28 April 2020 (UTC)
If they are close to expiry, then it may be useful. Often there will not be enough info supplied with the image to tell. Graeme Bartlett (talk) 12:03, 28 April 2020 (UTC)
Agreed, we should focus on files whose copyrights are close to expiration. A lot can change in 95 years. Ixfd64 (talk) 15:45, 28 April 2020 (UTC)

Some good articles and featured articles have issues to fix (meaning has a cleanup templates) as a part of Wikipedia maintenance. Most of good articles and featured articles are free from issues, but some are not, so it should make the distinction more clear. --Ijoe2003 (talk) 10:03, 29 April 2020 (UTC) (Minor additions --Ijoe2003 (talk) 11:07, 29 April 2020 (UTC))

Create a Covid-19 information tree

Never in the history of mankind has there ever been a place, virtual or physical, where governments of all levels in the entire world can come together to collaborate and share vital information to accomplish a common goal.

Wikipedia can be a very effective but simple and no cost weapon in combating the coronavirus. Here is a sample I created: http://covid19.wiki-site.com/index.php/Main_Page

This collaboration tool allows anyone in the world to get vital information about the Covid-19 pandemic in his/her local community, organization, village/baranggay, city, province/state, country and the world all in one central location. Each community, village/baranggay, city, province/state and country is responsible for creating and maintaining their own Covid-19 information page (wiki page). This allows leaders at various levels to give timely updates or changes on statistics and quarantine orders and instructions to their constituents. This also allows leaders to monitor the latest news and status of other jurisdictions near them, below them or above them so they can make better decisions and collaborate with other leaders. The leaders can give instructions to their citizens on the best way to contact them for questions and concerns. This allows anyone to monitor or get up to date status of their hometown if they happen to be far away so they can make better decisions in helping their love ones.

Based on my observations, many people are clamoring for a single go to place to seek vital information about the Covid-19 pandemic. People are worried sick about their love ones due to lack of information.

The great thing about this idea is that it can be used for future pandemics, epidemics or other calamities or natural disasters. I do not wish or expect any credit or acknowledgment on this idea. I simply want to help.

Wikipedia can deploy this weapon to the entire world by simply inserting an announcement in all the Wikipedia pages to ask the user to create a covid-19 Wikipedia page and pressure the media and their administrative head of government (mayor, governor, president/prime minister) to inform the public about it. Here's a sample message:

sample message --------------------------------

Dear fellow citizens of the world,

Anyone in the mood for making history? Never in the history of mankind has there ever been a place, virtual or physical, where all levels of government in the entire world comes together to collaborate and share vital information to accomplish a common goal.

A very effective but simple and no cost weapon in combating the coronavirus is in your hands at this very moment: Wikipedia can be used as a collaboration tool that allows anyone in the world to get vital information about the covid-19 pandemic in his/her local community, organization, village/baranggay, city, province/state, country and the world ALL IN ONE CENTRAL LOCATION. Each community, village/baranggay, city, province/state and country is responsible for creating and maintaining their own covid-19 information page (wiki page). this allows leaders at various levels to give timely updates or changes on statistics and quarantine orders and instructions to their constituents. This also allows leaders to monitor the latest news and status of other jurisdictions near them, below them or above them so they can make better decisions and collaborate with other leaders. The leaders can give instructions to their citizens on the best way to contact them for questions and concerns. This allows anyone to monitor or get up to date status of their hometown if they happen to be far away so they can make better decisions in helping their love ones.

It only takes 15 minutes for an entry level web developer to learn the basic syntax of this powerful tool. An administrative head of government (president/prime minister, governor, mayor, village/baranggay captain) simply has to assign anyone with at least entry level web developing skills to read the main page of the covid-19 Wikipedia site. It only takes 30 minutes to create.

The staff at Wikipediai humbly and sincerely asks you to do your part in deploying this weapon. Create a Covid-19 wikipage for your town, city, province/state or country or ask someone you know with basic web developing skills to do it for you. Then go to the facebook pages of your local media and administrative heads of governments to pressure them to inform the public about the Covid-19 wiki site.

Together, we can stop this virus.

Sincerely, Wikipedia — Preceding unsigned comment added by IanCJCrystal (talk • contribs) 04:00, 6 April 2020 (UTC)

Perhaps we could have an outline of COVID-19 article that could link to each page we have in context. Your proposed page is more of a how-to, and not quite fitting as an encyclopedia page. Graeme Bartlett (talk) 01:19, 20 April 2020 (UTC)
Note: there is a Draft:Outline of the 2019–20 coronavirus pandemic—Naddruf (talk ~ contribs) 14:06, 30 April 2020 (UTC)
a COVID-19 portal? --AntiCompositeNumber (talk) 03:02, 20 April 2020 (UTC)
You can find the portal at Portal:Coronavirus disease 2019. MarkZusab (talk) 20:56, 21 April 2020 (UTC)
I agree with this idea. we can usse a WikiProject for the how-to portion of this, and then use that as a foundation for editing actual Wikipedia entries. --Sm8900 (talk) 19:02, 23 April 2020 (UTC)

Renewal or re-waking of Wikipedia Contribution Team

I decided to bring out this when i site this group and I saw their aims and I decided to join but when and I also try to invite other users due to their is permission to call others but when I now go through it a saw that the group is not currently active seen then I realised the mistake I made. The team has a great aim of moving wikipedia further than before due to the awesome activities done on it. If this group doesn't qualify any longer due some reasons than notify all users to get out of it due to their is no more chance to contribute. But this group really can take wikipedia up and some cool thing can be added to brush it up again.Tbiw (talk) 01:11, 27 April 2020 (UTC)

Tbiw, It is not clear what you are trying to say. Please clarify. · · · Peter Southwood (talk): 10:20, 29 April 2020 (UTC)
What am trying to say is that we have to re-establish that group I mention due to it has a lot of things to contribute I growth of Wikipedia due to it fullness. We could add some cool stuff to it other than it former duty. We can add some things like educating users on how wikipedia can be developed and how strongly they can contribute and advising them on how to be safe from vandalism and also tell those coming on cool things we have here. I think it is now clear to you. Tbiw (talk) 17:54, 29 April 2020 (UTC)
@Peter Southwood, I believe this is a request to revive Wikipedia:Contribution Team, an initiative of the Wikimedia Foundation in the very old days when they had a plan that the WMF would issue instructions as to how outreach and recruitment was to be conducted, and volunteers would just carry out the instructions. @Tbiw, as per the tag on the page that's a long-dead proposal that isn't going to come back; the relationship between the Wikimedia Foundation and Wikipedia is completely different nowadays, and any attempt to diminish the community-led initiatives to engage and train new editors (such as WP:Teahouse) and replace them with processes dictated by the WMF in San Francisco is likely to meet with massive resistance. ‑ Iridescent 19:14, 29 April 2020 (UTC)
Thanks for letting me know about this and I redraw my proposal. Thank you. Tbiw (talk) 19:50, 29 April 2020 (UTC)
Thanks for the explanation Iridescent, I was not aware of the project. · · · Peter Southwood (talk): 06:51, 30 April 2020 (UTC)

Have an introductory summary section for longer articles

Having used Wikipedia for years, it's an invaluable source of knowledge. However, in recent years, many articles have got longer and longer. That's great as more people make their contribution, however, it can mean that there's a lot to read when one only wants a brief summary of the topic. Would it be possible to have some guideline which recommends that if the main article is more than "x" words, than a summary of less than "y" words is desirable? — Preceding unsigned comment added by Rogerjbromley (talk • contribs)

That's exactly what we do have (and have had for as long as I can remember) at WP:LEAD. I know that only our best articles follow this guideline perfectly, but that is a result of this being a wiki where we work towards perfection, rather then demanding it immediately. Phil Bridger (talk) 15:47, 18 April 2020 (UTC)
A very few articles also have something like Introduction to viruses. Gråbergs Gråa Sång (talk) 15:04, 19 April 2020 (UTC)

Rogerjbromley (talk) 11:08, 25 April 2020 (UTC) Thanks for your comments. The introduction section is good but I'm suggesting something a bit longer that the introduction but shorter than the full article. I'm very new to putting ideas forward but is there some way that users can be polled?

I doubt there is much appetite to have a fourth level of detail - more than a lede or an infobox but less than an article. Remember that it would substantially increase our need for article maintenance (we used to have a fourth level on hundreds of thousands of articles called "persondata" and eventually we got consensus to delete it). If you do want to make a case for such a large additional amount of work, I suggest you read Wikipedia:Manual of Style/Lead section and make your case on its talkpage either as to what specifically you would like to see in the Lede beyond a "concise overview of the subject", or give some examples of things that would not belong in a "concise overview of the subject" but would belong in the sort of extended summary that you would like to see. ϢereSpielChequers 14:09, 25 April 2020 (UTC)
Rogerjbromley, I still think that a lead section that follows the WP:LEAD guideline is what you are looking for. Take a look at some of our featured articles for examples. The problem is that many of our articles do not reach these standards, but the good news is that anyone, including you, can edit articles to improve them. Phil Bridger (talk) 15:03, 25 April 2020 (UTC)

2A00:23C1:2F03:E001:B478:F74F:999F:7B76 (talk) 17:28, 2 May 2020 (UTC) Hi All. Thanks for your comments which I fully appreciated. Let's wrap up and best wishes. Rogerp

Refs in templates (and in images/files)

I probably ought to have broached this here, but I've started out with an idea about this by thinking out loud elsewhere. There's a discussion in slow progress at Wikipedia talk:Templates#Refs in templates. My latest comment there in the Alternative which preserves WP:V subsection brought up files/images. Perhaps that discussion ought to be moved here. Wtmitchell (talk) (earlier Boracay Bill) 16:58, 3 May 2020 (UTC)

Ideas for changes to Wikipedia:Community portal

Was moved to the proposals tab and closed there. {{u|Sdkb}} talk 02:44, 5 May 2020 (UTC)

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

main proposal

I would like to propose some changes to various components of the top portion of Wikipedia:Community portal. I posted this for discussion at the talk page there, but I was not able to get any discussion going there, at all.

Below is my draft for changes to the top portion of the page. this draft includes the portion of the page from the top of the page, down to the large pictorial navbar

Please note, I also have some ideas for the small navbox at the top; namely, to add just some more links, e.g. to Wikipedia:Goings-on,etc, as described below. Below is a separate draft, for the small navbox.

I appreciate any feedback. I would like to move ahead with this, if possible. I am open to any and all ideas, feedback, comments, etc on this. thanks!!! --Sm8900 (talk) 19:17, 21 April 2020 (UTC)

Wikipedia:Goings-on information is on the page already....as is Wikipedia:News so not sure why link them ... WP:About is not an interactive page and is already linked on every page. As for bullet points I've always been a fan of paragraphs.... never been a fan of the high school resume look.--Moxy 🍁 03:12, 22 April 2020 (UTC)
Hi Moxy. good to see you. okay, you are making some excellent points, as usual. I would like to respond point by point, in order. I will number them below, just for readability.
  1. Re goings-on and News; you are absolutely 100% correct. thanks!! I hadn't noticed that nav box at the bottom of the page, i.e. tthe one that is currently below the Community Bulletin Board section. based on your point, I have added that nav box to my draft; in other words, I would like to move it upwards, to be much more visible by being right below the main pictorial nav bar. so that is now part of my draft. is that okay?
  2. Re the WP:News page link specifically; I would still like to modify the WP:COM page as I originally suggested, and add the pictorial link. the reason for this is simply to increase the visibility of this link, and to draw more traffic to it. that is the whole point of the Community Portal page, anyway. and this seems like one good choice to magnify this way. I am not trying to do so for all the links there. so what do you say? do you think you might be open to a change of that manner? I was hoping perhaps we could reach some accord on this. I'm willing to modify in any way you may wish.
  3. If you feel that way about the WP:About page; then I guess it will remain off this draft, unless we get any other comments supporting its inclusion. I do recognize that it is on every page, via the sidebar, as you note. however, I thought it might be beneficial to increase its prominence in this way. however, right now, your response is the main one on this point. if we get any other comments or input, we can address them at that point.
  4. okay. as far as the bullet points; I hear you. but my goal was to increase the visibility of those individual pages. I think this is one good way to do so. I hope you will consider that. unless and until we get any further opinions in support of this, for now, your response is the main set of constraints that I need to work with. so I am open to your views on this. if you wish to further consider at all, feel free.
  5. hm, okay, one more point, I notice that you did not mention my link to WP:RFC in your reply above; so is that one revision that you would be okay with supporting? I hope so, perhaps?
Okay those are all my points in response. I really appreciate your time and insights here. as usual, you have provided me with some great input and information on some important details. I hope you'll look over my reply, and write back when you get a chance. I welcome your input. I always benefit from your knowledgeable insights into how to get things done around here. truly, thanks! cheers! --Sm8900 (talk) 15:19, 23 April 2020 (UTC)
Please note, once this item at the WP:Village pump (idea lab) has been archived, I plan to present this proposal in its current draft at WP:Village pump (proposals). that will be the definitive discussion for this proposal, since that is the correct venue to get a proposal voted either up or down. Please feel free to leave any comments or feedback here, while this item is still visible here. thanks. --Sm8900 (talk) 20:51, 26 April 2020 (UTC)

Remove barnstars from the "Interact more" section?

This section was copied from WT:COM at the suggestion of User:Andrybak.

With the other links in the "Interact more" table (being the Help Desk, Teahouse, Reference Desk, WikiProjects, Dispute Resolution, and the Village Pump), the information page about Barnstars jumps out to me as not necessary to have in this table. With all of the other aforementioned links, there is a place for editors to branch out and get the help they need. However, WP:BARN is just an information page that editors can't interact with. This brings me to the question of "Why are Barnstars particularly featured here?". If a link was necessary to have in this position that advocates for the concept of the Wikipedia Community, I would instead of use WP:WIKILOVE or WP:AWARDS, which are much broader in scope and contain more information. While I'm sure that Barnstars are featured here to advocate for the spread of such, as even a new editor can give a barnstar, I don't think that it warrants placement with our feedback pages and services. To this point, I would probably argue against the presence of WikiLove and Awards in this table as well. But while I still believe that Barnstars should be removed from the "Interact more" table, I would compromise with adding WP:WIKILOVE in its place. Utopes (talk / cont) 22:50, 14 April 2020 (UTC)

It kind of goes alongside the topic of improving the community portal as suggested by User:Sm8900, but I am suggesting less content in the upper portion of the page rather than adding more. I don't have any opinions about what happens with the navbox. Utopes (talk / cont) 20:36, 21 April 2020 (UTC)

Comments

@Utopes:, I totally agree with your idea above. that makes sense to me. but my feeling on this is, why not remove the item you mention above, and then replace it with something much more substantive and helpful to the community in general, i.e. a shortcut that links to Wikipedia: Requests for comment? thanks. --Sm8900 (talk) 01:47, 22 April 2020 (UTC)
Agree ....less is best... it could be removed. The above copy pasted? Thought this was talked about before.--Moxy 🍁 03:12, 22 April 2020 (UTC)
(This was my proposal to make the table at the top of smaller by removing WP:BARN, while considering replacement. This was completely separate from Sm8900's proposal, but I was told to copy it here anyway.) Utopes (talk / cont) 15:47, 22 April 2020 (UTC)

Item above moved to new tab

Based on the lack of further activity in the section above, I have now submitted this as a proposal on the tab for Proposals. you can view this in the section Wikipedia:Village_pump_(proposals)#Propose_changes_to_WP:Community_portal. Please feel free to comment. thanks. --Sm8900 (talk) 17:26, 30 April 2020 (UTC)

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

New better-thought-out bot idea

Hi, after some time since my last bot idea I realised came up with a better idea for a bot. It would update talk page banners when the status of a page was changed (from article to redirect or draft to disambig). I've seen quite a few "Redirect-class" or "Draft-class" articles, and I think a bot would suit this task. But one thing: has this been done before? I'd like to seek input before moving on to proposals Village Pump. Thanks! Eumat114 formerly TLOM (Message) 01:45, 6 May 2020 (UTC)

I run a similar task that updates banners when an article becomes a redirect. I suppose a bot task going the other way could be useful, if one doesn't exist already. Enterprisey (talk!) 01:41, 7 May 2020 (UTC)

Languages

In my opinion there should to be some additions in language terms because some people can't find the proper answer in their own language and I am one of them — Preceding unsigned comment added by 37.110.210.178 (talk) 12:28, 7 May 2020 (UTC)

Can you explain this a bit more? Do you mean that other language projects should create more articles? — xaosflux Talk 11:26, 8 May 2020 (UTC)

'Village Pump' on the sidebar

New idea springing up...

Hi everybody!

I use the village pump in Wikipedia regularly so I would like somebody to add a link for the village pump in the sidebar, I won't have to search for it instead. --Red-back spider (talk) 10:38, 8 May 2020 (UTC)

Wikipedia:Requests for comment/2020 left sidebar update may interest you. — xaosflux Talk 11:25, 8 May 2020 (UTC)
I also use the Village Pump somewhat regularly and I don't find typing "wp:vpp" (e.g., for Wikipedia:Village pump (policy)) to be overly difficult or burdensome. Certainly not enough to justify a line in the sidebar. It's seven keystrokes, including the Enter. That's why we have shortcuts. ―Mandruss ☎ 19:11, 8 May 2020 (UTC)
Or you can click "Community portal" on the sidebar and get links to the village pumps near the top of the page. Phil Bridger (talk) 19:36, 8 May 2020 (UTC)

Welcome template

Operation Sound

Can you start having something like a sound of the day that lets you hear a bit of audio from a file that is found inside of an article. I know this sounds silly, but if this works, I will really appreciated. It would be good for Wikipedia so people could enjoy the word of sound. I think that the sound should not be named (or named, I won't mind) and with a little bit of description, people will have to read the article to find out more about it. I think this can be a fun way to be people interested into more articles. I think that sound is a great way to get people to read more because they have more that they can hear. I may also suggest an audio file for certain long or wordy article so people who are photosensitive or do not like to read big articles can listen along with the article. this can also help younger people who have trouble with reading. All I want you to do is read this because it would mean a lot. Yours truly: Clockworkv p.s . I am a big fan of this website, I just love it when I get emails from it because it is very interesting. — Preceding unsigned comment added by Clockworkv (talk • contribs) 14:44, 1 May 2020 (UTC)

Interesting tell me more about it. Tbiw (talk) 10:07, 5 May 2020 (UTC)
Hello, there is Commons:Media of the day. --NaBUru38 (talk) 20:35, 10 May 2020 (UTC)

Content reviewer protected

OP was check-user blocked. If anyone else would like to propose the same or similar idea, go ahead, but this discussion is no longer needed. --DannyS712 (talk) 07:10, 11 May 2020 (UTC)

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


Moved from Wikipedia:Village pump (policy)

Content reviewers means 30 days and 99 edits. It also means that they can block users or protect pages but CAN NOT MOVE IT, AND CAN NOT EDIT WIKIMEDIA COMMONS FILES. Content reviewer protected means that users 29- and 98- (or the two) can't edit it. Extended content reviewer is 1 year and 1000 edits, and they can also be admin, because they are firstly extended confirmed. Extended content reviewer logo is a Q in a purple background while 30/99 is the + (plus sign) with red background as the flag of Switzerland. --SiSwati Swazi (talk) 16:52, 8 May 2020 (UTC)

@SiSwati Swazi: I've moved this discussion here to Idea Lab, as it would need much more fleshing out before having a policy discussion on it. — xaosflux Talk 18:25, 8 May 2020 (UTC)
Thanks, but this idea needs to be administrated by Jimbo Wales or the Wikimedia Foundation, or anything else. How they will make it? --SiSwati Swazi (talk) 18:26, 8 May 2020 (UTC) Support.
Jimbo Wales has no power over any Wikimedia project and the Wikimedia Foundation only exercises its power in very limited circumstances. Your proposal is very difficult to understand, but if it is that any editor with 30 days editing and 99 edits should have the power to block and protect then it is an obvious non-starter. That's what we appoint admins to do, and they have to go through the WP:RFA procedure where they can show that they have the trust of the community to exercise such powers responsibly. Phil Bridger (talk) 18:46, 8 May 2020 (UTC)
Phil thanks you but this is a very important request and feature for Wikimedia Foundation. We wanna get a beta tester. SiSwati Swazi (talk) 19:04, 8 May 2020 (UTC) Support.
Can you please at least clarify what you mean. Do you mean, as I assumed above, that anyone with 30 days editing and 99 edits should be able to block users and protect pages here on the English Wikipedia (we have no power over Commons)? Phil Bridger (talk) 19:21, 8 May 2020 (UTC)
This blocked user means that he wants anyone to make content reviewer protected, and was blocked indefinitely and JPGORDON -an administrator- sayed that he declined ethe requeste. --190.245.116.175 (talk) 20:06, 8 May 2020 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Provide option to filter on tables based on the values like a spreadsheet

If there was an option to filter on tables based on the values like a spreadsheet, It will be useful in many scenarios to easily consume only data that is needed.

Eg: from a list of games published by a publisher can filter games available in a particular platform from a list of movies by an actor filter movies in a particular language.

There will be other practical uses too. — Preceding unsigned comment added by Sivakumar1605 (talk • contribs) 09:00, 12 May 2020 (UTC)

Adding images to all created article

Was moved to the proposals tab. tbiw (talk) 11:14, 13 May 2020 (UTC)

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

Images should be added to all articles inorder to put more beauty into it. We all know the images gotten from Wikimedia Commons is the one added to Wikipedia. The should be a linker between both and any images seen in Wikimedia Commons after been confirmed not violating the policy should be immediately added to Wikipedia. Images mean a lot it can describe what the article is talking about,it add to beauty,it give more meaning to article and other beneficial uses. Article standard can be completed using images. Images are powerful than seen. Let images be in all articles to give it more standard. Tbiw (talk) 10:06, 5 May 2020 (UTC)

That is a good idea when there are good images available for use in articles, but the problem with mandating images is that people may add inappropriate or misleading images when no good image is available, just for the sake of following such a rule. Phil Bridger (talk) 10:26, 5 May 2020 (UTC)
If a bot handle will it not be fine or give it to a particularly trusted group of editors or appoint some trusted editors. We all know in good there's always a bad so that is one of the problem despite the idea my sound pretty interesting disadvantages will follow so we have to conquer it. Thanks for telling us ahead some problems that may follow it to know how to resolve and remove them.
Tbiw (talk) 18:54, 5 May 2020 (UTC)
Nice suggestion but I doubt we have good editors with spare time to do it. Doug Weller talk 14:50, 10 May 2020 (UTC)
There are a lot of topics for which it wouldn't make much sense to add an image, and adding something inappropriate would probably be worse than having nothing at all. And there are topics for which an image would make sense, but there are simply none available on Commons. The {{Image requested}} can be added to an article's talk page, but some things are just difficult to get picture of. –Deacon Vorbis (carbon • videos) 14:56, 10 May 2020 (UTC)
problem is solved then the what next them to round up this proposal Tbiw (talk) 02:17, 13 May 2020 (UTC)

I moving this to proposal. Tbiw (talk) 11:11, 13 May 2020 (UTC)

Item above moved to new tab

Based on this topic need fast action on nay or yea I have moved it to Wikipedia:Village_pump_(proposals). Please feel free to comment. thanks. --tbiw (talk) 11:14, 13 May 2020 (UTC)

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

Teleconference schedule

Many Wikimedians have moved their usual being-there conferences and discussions to live video. Some are by invitation only, others for Wikimedians in general or for the general public, still others are a panel discussion or symposium that let the public see and hear but not be seen or heard, or type into a parallel online chat. Some are on internal matters such as databases or Movement strategy, or on article subject areas; others seek to introduce newbies. I haven't seen a schdule for these sessions, and some of them have come to my notice only after the fact. If a general schedule does not exist, it should. Jim.henderson (talk) 10:03, 14 May 2020 (UTC)

IPv6 user identification

Tracked in Phabricator
Task T112325

I don't know a lot about IPv6, but in my experience two different IPv6 addresses refer to the same user when they are the same in the first four colon-separated "words". If that's the case, would it not make an enormous amount of sense to look at only those first four words for the purposes of user identification; i.e. user and user-talk pages, contributions history, etc.? ―Mandruss ☎ 12:32, 15 May 2020 (UTC)

You're referring to the /64 range. While in many cases a single user is allocated a /64, some ISPs may have multiple users in the /64. phab:T112325 is about having an aggregated talk page for the /64, and there are other related tasks linked there. IP masking (see m:IP Editing: Privacy Enhancement and Abuse Mitigation) will change all of this. — JJMC89 (T·C) 18:38, 15 May 2020 (UTC)
@JJMC89: Unless the 87–4, 95% opposition is meaningless, IP masking is a dead horse. ―Mandruss ☎ 18:45, 15 May 2020 (UTC)
You would think, but phab:T248241 indicates otherwise. — JJMC89 (T·C) 18:51, 15 May 2020 (UTC)

Use a different color for the talk page link of editors whose talk pages contain only vandalism?

Throwing out a pie-in-the-sky idea here:

Many editors use the blue/red distinction in revision histories to help identify very new and potentially problematic editors. But for the most problematic editors who quickly accrue a warning message or more, their talk page turns blue, which sends the opposite of the signal we'd want it to. I think it'd be nice if there was a different color used for editors whose only talk page edits consist of warnings from other editors. I'm not sure how technically feasible this would be, which would probably be the main challenge. Other potential hurdles:

  • It'd mess up a bit the standardization of link coloring on Wikipedia, and I'm not sure what the appropriate color to use would be. Another formatting option could also be employed rather than a link color change. (But I think experienced editors would get used to it fairly quickly and ultimately find it helpful)
  • It'd presumably be easy to circumnavigate by an LTA vandal who knows what they're doing. (But that's not really the target here so much as your run-of-the-mill problematic editor, and it'd be an improvement over the status quo)

Thoughts, everyone? {{u|Sdkb}} talk 02:38, 20 May 2020 (UTC)

You might be able to implement this with a user script, but it would have to, I think, essentially download the first talk page link, assess whether it's only warning templates (??? not sure how that would work), and then do that same thing for every other talk page link on the page—which would probably end up being pretty slow, given that history pages can have dozens of different talk pages linked on them. Still, it would be pretty useful if it could be made to work. Eman235/talk 02:53, 20 May 2020 (UTC)
A lighter-weight solution could be like popups, where when you point at a talkpage link it loads/parses and displays an indicator rather than loading and parsing all linked talkpages during page-load. Popups is already useful in this way because it includes the first image the target contains. Most vandals have one of the standard warning-template icons, or occasionally the teahouse icon. DMacks (talk) 03:05, 20 May 2020 (UTC)

Some good articles and featured articles have a cleanup banners. On good articles, the issue falls into number 4 of Immediate failures in the good article criteria. As maintaining the good articles and featured articles to keep their state, the maintenance category to list good articles and featured articles with cleanup banners should be necessary. --Ijoe2003 (talk) 11:19, 22 May 2020 (UTC)

It might be better to use category intersection (e.g. WP:Petscan) of existing categories to find pages that are in e.g. Category:Good articles and in particular maintenance categories (and in a particular topic). DexDor (talk) 11:39, 22 May 2020 (UTC)
Do we know how many GAs/FAs there are with maintenance banners that have stayed around for some extended period? Any such pages should at the least get some scrutiny/review. This seems like something that anyone who wants to create it can go ahead and do; I'm not a category expert but I don't see such a category being deleted. {{u|Sdkb}} talk 18:30, 22 May 2020 (UTC)
There are over 3000 from 2018 (query). If such a category (or categories) is maintained manually there's a risk that the effort spent maintaining the category (as articles change their maintenance or GA status) is effort that could be better spent elsewhere. DexDor (talk) 20:54, 22 May 2020 (UTC)

Add teahouse and village pump to sidebar or made a shortcut

With the current system, you have to go to Community portal--->Teahouse/village pump. What me is that they are two of the most important features, For new users the teahouse is vital yet there is no shortcut. The village pump is an important tool that is vital to the growth of wikipedia. We need to fix this.--HISTORIAN (talk) 21:40, 18 May 2020 (UTC)

See Wikipedia:Requests for comment/2020 left sidebar update.--Moxy 🍁 21:45, 18 May 2020 (UTC)
@Andrewhistory: That discussion is in the process of being closed and has a message up top asking for it not to be modified, so it's unfortunately too late for that particular venue. Once that discussion is closed, you could try bringing it up at WP:VPR, but I think you'd encounter some resistance, since the Community portal is supposed to be the sole landing spot for experienced editors, and Help:Contents the sole landing spot for editors who are looking for help. We did just make the Village pumps more prominent at the Community portal, though, if that's any consolation. Cheers, {{u|Sdkb}} talk 23:19, 18 May 2020 (UTC)
If you say you are user it is just easy look at my user page all important links that I need and work on are there I just press it and see what going and i respond to all things. Create the links on your page. Page is personal click when needed. Tbiw (talk) 08:27, 26 May 2020 (UTC)

Create a Disable Account option

How it would work 1. Place the Retired template on the user's User page 2. Go to a new " Disable Account " page 3. Click a button on the bottom of the new page. 4. Wait 30 days ( ~ 1 month ) 5. Done

What it would do

Delete your user page Block logging in with that account Unsub from everything Arcive your talk page and block creating of a new one Make a guestbook redirecting from your talk page — Preceding unsigned comment added by Another Wiki User the 2nd (talk • contribs) 15:52, 26 May 2020 (UTC)

"Delete your talk page" is against WP:DELTALK guideline. Guestbooks are outside the scope of WP, and especially is a user is gone there is no need for that sort of vanity by default. DMacks (talk) 16:18, 26 May 2020 (UTC)
  • How about, instead, you place the retired template on your user page and/or talk page yourself, you ask for your user page (but not your talk page!) to be deleted under WP:U1, and then you just go away? If you don't trust yourself to go away, there are plenty of admins who will apply a self-requested block for you. Oh, and I don't think there's any realistic way of automatically unsubscribing an account from everything, as everything that gets subscribed to is done a different way and there isn't any central control over what subscriptions even exist. Boing! said Zebedee (talk) 19:14, 26 May 2020 (UTC)
  • Some users find useful to change their password to a string they will not remember. Others request a permanent block, some admins accept to (see here). Also see Wikipedia:Courtesy vanishing. —PaleoNeonate – 21:42, 26 May 2020 (UTC)

In a file's edit history, being able to delete some (not all) of the edits?

  • In my admin work, in a file's edit history, how long will it be before I will be able to directly delete some (not all) of that file's edits? Currently, to do this, I must delete all the edits, then undelete some of the edits, thus wasting my time and Wikipedia's server's time and the internet's time; and it is impossible if the file has more than 5000 edits. I have chased this up in Maniphest, but nothing has happened. Anthony Appleyard (talk) 04:21, 17 May 2020 (UTC)
That would be dependent on phab:T20493, which is currently a Phase 2 RfC. The RfC is currently waiting for a developer (or, more likely, a development team) to commit to working on the proposal and push it through the RfC process. That hasn't happened yet. The COVID-19 pandemic has affected development workflows somewhat, but it doesn't account for the fact that the RfC hasn't been picked up by a development team. The Core Platform and Community Tech teams are the most likely to work on this eventually, but it's not on the roadmap for either. Bringing this issue up in the 2021 Community Wishlist survey could help, if it hasn't gained momentum by that point. If getting the WMF to do it isn't your style, you could also try convincing volunteer developers that the issue is important and that they should spend time on it. How long will any of this take? Well, if the task picked up a code steward and software engineer today, it would still take at least a month to move through the RfC process, with that time increasing depending on the feedback that comes in. Assuming it passes, then someone has to build the thing. Depending on how many developers get assigned, how often they work on it, how many unforeseen issues they encounter, I'd expect development, testing, and deployment to take 4-6 months but wouldn't be surprised if it went a full year. --AntiCompositeNumber (talk) 05:23, 17 May 2020 (UTC)
AntiCompositeNumber, if your time estimate is in the right ballpark, then CommTech will decline the task as being too big for the wishlist. Wishlist tasks should be closer to one month's work for that team (otherwise, they wouldn't be able to address 10 wishes per year). Whatamidoing (WMF) (talk) 05:01, 29 May 2020 (UTC)

Editors day

Wikipedia are been edited by editors which give time spending it to make wikipedia great and progressive relentless work should be awarded by just a day. Barnstars and other are given hardworking and other good editors. This is general one editors day there should be a lot of fun that day. Let use this to appreciate people's effort and dedication to wikipedia. That day should a colourful by doing a lot of cool stuff. Editor day should be a day to appreciate tireless work.Tbiw (talk) 16:50, 18 May 2020 (UTC)

I don't need a special day. I'd just settle for a pay raise. --Jayron32 18:11, 18 May 2020 (UTC)
People imagine that they are having a lot of fun and doing a lot of cool stuff on April Fools' Day, when for the most part they are simply playing tired old unfunny pranks. We don't need another day like that. Phil Bridger (talk) 18:19, 18 May 2020 (UTC)

@ Phil Bridger tell me all what you do on April fool's day. — Preceding unsigned comment added by Tbiw (talk • contribs) 19:48, 18 May 2020 (UTC)

I'd rather not. Phil Bridger (talk) 06:24, 19 May 2020 (UTC)
Okay April fool's day is a day every one know but this proposed day will be a day for only we. Let's appreciate the hard work by this day. Tbiw (talk) 08:17, 19 May 2020 (UTC)
request satisfied Tbiw (talk) 20:21, 31 May 2020 (UTC)
User:Tbiw, I wonder whether you've heard about Wikipedia:Wikipedia Day. Perhaps that would meet your goal? Whatamidoing (WMF) (talk) 05:03, 29 May 2020 (UTC)

Distinguishing references from text in the edit box

When the edit box is open, often it is difficult to hunt and peck for the beginning and end of the text you want to edit when there's a lot of long references in between. Is there anyway, or has it been proposed before, to alter the text between <ref> </ref>, so that when saved, it then appears as a different color or font or something that distinguishes the reference mark-up from the actual article text? Ditch ∝ 02:57, 20 May 2020 (UTC)

Sounds like the Syntax highlighter gadget in Special:Preferences#mw-prefsection-gadgets. DMacks (talk) 03:08, 20 May 2020 (UTC)
@DMacks and Ditch Fisher: Woah, I didn't know about that gadget — it seems super useful, so I'm going to try it out. If it works as well as I hope, the proposal we might want to have is whether to turn it on by default. {{u|Sdkb}} talk 23:40, 20 May 2020 (UTC)
Doesn't work for me at all. Probably an issue with Chrome, which is a deal-breaker for me. Hope it works better for you. :( Ditch ∝ 23:46, 20 May 2020 (UTC)
@Ditch Fisher: There's also the CodeMirror highlighter, enabled by clicking the pen icon above the edit box. Maybe it should be better advertised, somehow, since it seems no one ever knows about it. Suffusion of Yellow (talk) 00:33, 21 May 2020 (UTC)
@Ditch Fisher and Suffusion of Yellow: Woah, I like that even better! Are there any major bugs or flaws with it? If not, I think we should create a proposal to turn it on by default. {{u|Sdkb}} talk 02:22, 21 May 2020 (UTC)
@Sdkb: It seems to require almost 300kb of Javascript. That may be a problem on older machines. It's literally one click away from the edit form, for those who want it. Problem is, there's no reason to think that clicking a pen icon (nearly identical to the VisualEditor icon) is going to cause syntax highlighting. Maybe replace the icon with the official logo, File:Baboon.svg? No, there's no reason to think "baboon == syntax highlighting" either, but at least people will wonder "WTF is this baboon doing here?" and click on it to find out. Plus, that would give the author of this feature the credit they deserve. Or perhaps someone can design a new logo that suggests highlighting. Suffusion of Yellow (talk) 03:38, 21 May 2020 (UTC)
@Suffusion of Yellow: I'm not sure what 300kb means in practical terms, but it seems like a feature that ought to be possible to use without slowing down one's machine too much; is there an improvement we could apply to make that the case? And I don't object to changing the icon, so long as it stays consistent with the style of the other icons in the bar. But my main thought here (after the shock that I've made it through 10k edits, including a bunch of syntax-y ones, without knowing about this) is that this could be a great tool for helping newer editors transition to using WikiMarkup. And from their perspective, a baboon is no more likely to get clicked on than a puzzle piece; they're both unfamiliar icons among a slew of unfamiliar icons. The only way we could get a portion of them to try the highlighting would be to have a popup message the first time they open the wikitext editor asking if they want to use it. {{u|Sdkb}} talk 04:06, 21 May 2020 (UTC)
The icon is technically a "highlighter" not a pen. So if you know that, it makes sense, sort-of. Without seeing other pen-types side-by-side (and maybe still even in that case), one cannot tell it's anything other than "some sort of writing thing". DMacks (talk) 05:26, 21 May 2020 (UTC)
See also phab:T174145 if anyone happens to have any good ideas for the icon. Sdkb, there are some bugs in the CodeMirror syntax highlighter, but if they appear, just click the confusing icon/button and turn it off again. It seems to work well for some people and not so well for other people (often including me, especially in Firefox). Whatamidoing (WMF) (talk) 05:08, 29 May 2020 (UTC)
The limitation that all icons be monochromatic makes it very difficult to wordlessly communicate a concept like "syntax highlighting" in a 20-pixel square. I did propose something like over at phabricator. --Ahecht (TALK
PAGE) 17:49, 7 June 2020 (UTC)
I just let my browser find what I'm looking for, using Ctrl+F. That's even less work for my eyes than using a syntax highlighter. I'm not certain that all platforms have such a capability, but certainly all PC-based browsers do. ―Mandruss ☎ 15:16, 21 May 2020 (UTC)
I almost always use list-defined references in articles I create, for this exact reason. CJK09 (talk) 01:52, 23 May 2020 (UTC)

Stack Exhange?

Would amyone join a Wikipedia stack exchange proposal? 72.74.131.76 (talk) 14:06, 23 May 2020 (UTC)

I don't think you are likely to get any useful responses unless you give some indication of what your proposal might be. Do you propose having a section at Stack Exchange about the technicalities of MediaWiki markup? If so, then I think that that is something that needs to be proposed there rather than here. If your proposal is more connected specifically with the English Wikipedia then I would suggest that it would be better to have questions asked at our own venues such as WP:Teahouse or Wikipedia:Village pump (technical). We already have enough problems caused by editors egging each other into bad habits at venues such as WP:IRC without adding to the off-Wikipedia sites where this happens. Phil Bridger (talk) 19:14, 28 May 2020 (UTC)

Article Subpages

These subpages would be great for series, songs, semi-viral videos, and semi-notables

For example

A LOT of Minecraft

Non-famous pepole that are still notable. — Preceding unsigned comment added by Another Wiki User the 2nd (talk • contribs) 13:33, 27 May 2020 (UTC)

Subpages are disabled in the Mainspace for a reason. I don't think that they are gonna be enabled anytime soon.
Non-famous people that are still notable A topic is either notable or it's not. If it's notable, then it can have a normal article; if it's not, then it shouldn't have an article.
A LOT of Minecraft Not many Minecraft topics are notable, and we need to stay away from gamecruft. Exstended information works well on the Minecraft Wiki.
How would these subpages work exactly? Examples? >>BEANS X2t 13:41, 4 June 2020 (UTC)

Amazon Alexa integration: backend pronunciation button for Wikipedia pages

Hi, my name is MitzvahCode, and this is my first Village pump submission! I have not found any instances of the this idea in 'Perennial proposals' or in the archives:

Often, when making verbal requests of Amazon Alexa devices for specific Wikipedia pages, I end up listening to something slightly off or even totally random. For instance, "Alexa," I will say, "Wikipedia," and in response to Alexa's reply I will say, "Bosc pear". Alexa often starts reading the "Pear" article (for the general fruit) instead of the one for the Bosc pear (sometimes I get responses that are wildly off topic!). While this is likely and realistically a challenge external to Wikipedia itself (i.e. Alexa’s programming), is there a Wikipedia page feature like a backend-readable 'pronunciation button’ that when added to a page could help Alexa (Google, Siri, and the like) find the correct page for a given verbal input? Or, if the search field for such requests on these types of devices is currently limited to a Wikipedia article's title, might Wikipedia developers create such a button?

Please consider your own experiences with Alexa, Hey Google, Siri, etc.––wouldn't it be a nice, helpful, and even productive tool to add to Wikipedia pages even if there was only a chance that it would make articles more readily distinguishable? Thank you for your time and consideration.

PS While I aspire to be a developer (I'm learning the basics of Python at present), I am not yet knowledgeable enough to know if the ASK Sound Library or the Speech Synthesis Markup Language (SSML) Reference (as mentioned on Amazon's developer website) could be leveraged to generate the kind of Wikipedia backend pronunciation buttons I hope to see (and hear!) easily integrated in the near future.

Thanks, MitzvahCode (talk) 03:24, 28 May 2020 (UTC)MitzvahCode

Alexa, Google and Siri are products of Amazon, Alphabet and Apple respectively; we have no control over what they do or don't include in their search results. When the pronunciation of a term is non-intuitive or varies regionally, we already have the facility to include the IPA pronunciation in the lead using the {{IPAc-en}} template—see Achilles or Chuck Yeager for example. Whether or not the programmers of external search engines choose to use those pronunciation guides when searching is purely a matter of them, and something over which we have no influence. To take your Bosc pear example, at a rough guess I'd say Amazon has concluded that the majority of people searching for "something pear" are actually looking for the primary Pear article, and as such they will have fewer false positives—and consequently fewer unhappy customers—then if they try to direct people to individual subpages, particularly because our subpages are generally of poorer quality than the broader parent articles. (Indeed, the quality of Bosc pear is so poor, they may be intentially excluding it from search results on the grounds that it's unlikely to be useful.) ‑ Iridescent 20:34, 28 May 2020 (UTC)

Idea for adding to watchlist ONLY "Talk:" page

I like the watchlist feature a lot, and my idea to improve it would be to separate the functionality of adding a "article" page vs. adding a "talk:". It would be nice to see ONLY the changes made to a "talk:" page, not the changes made to the article itself. Adamilo (talk) 17:20, 28 May 2020 (UTC)

In your watchlist, select Namespace > Talk. Headbomb {t · c · p · b} 18:36, 28 May 2020 (UTC)
Not sure if this is what the original poster was getting at, but I would like the ability to make this selection for each page added to the talk list rather than as a filter for the complete list. This would mean that edits to the article itself would not show up on the watchlist but edits to the talk page would. As it is, if I am interested in watchlisting the the talk page, changes to the article (which I may not care about) can overwhelm the watchlist. --Khajidha (talk) 17:17, 5 June 2020 (UTC)

This seems like a good idea. If you're having a discussion on the talk page of a popular article, it's unlikely that you need to get notifications every time someone makes an edit on the main article. I think I'd get a lot of use out of it. { } 05:11, 9 June 2020 (UTC)

Draftifier - User Right

If you've spent some time doing New Page Reviews or just came across a substandard article, you'll know that unless you have the Page Mover right or better (Admin, Bureaucrat, etc.) you'll be forced to create a redirect from mainspace that you'll only have to tag for speedy deletion. Some tools take this into account and automatically tag your automatically-generated redirect for deletion. In my opinion, this is a waste of time for admins, and a waste of resources (I know, WP:PERFORMANCE), and there has to be a better way to do it. Which is why I propose a new flag, "draftify", which is like "suppressredirect" except it only concerns moves to draftspace. I'd propose just granting "suppressredirect" much more widely, possibly as part of some user group besides Page Mover, but I think that's a nonstarter. Thoughts? PrussianOwl (talk) 00:49, 30 May 2020 (UTC)

  • I think it could be useful. This reminds me of another similar situation where users without the autopatrol right but who review new pages and patrol tend to create many talk pages to tag articles and to welcome and/or warn new users. Those pages end up on the unpatrolled pages queue. I've not done research about it so it's unclear of a filter could potentially detect these common use cases (i.e. use of standard templates only) and autopatrol such pages, or if the new page reviewer right could be improved to also do that without being as powerful as autopatrol, if the general system could autopatrol such simple tag-pages automatically for extended-confirmed users, etc... Since these topics concern NPR I posted an invitation at the noticeboard for more input. —PaleoNeonate – 11:06, 31 May 2020 (UTC)
  • I'd rather just give "suppressredirect" with "patroller", or be more proactive with encouraging NPPers to request "extendedmover" when they meet the criteria. The page mover criteria are more stringent mostly because of "tboveride" and "move-subpages" which can cause a lot of problems if you don't know what you're doing or editing in bad faith. "suppressredirect" is pretty low powered on its own, and the damage of misuse isn't much worse than the regular page move disruption that any autoconfirmed user can cause. — Wug·a·po·des​ 03:02, 2 June 2020 (UTC)
'podes' idea of adding supressredirect to NPP sounds a good one (Prussian's original idea is fine, I just think that it's probably easier to add a userright to a current permission) Nosebagbear (talk) 13:45, 2 June 2020 (UTC)

Article subpages

Moved from Wikipedia:Village pump (proposals)

Make subpages for articles. It would help a WikiProject on Minecraft ( wich I will propose ) and Wikipedia — Preceding unsigned comment added by Another Wiki User the 2nd (talk • contribs) 2020-06-02T19:10:37 (UTC)

@Another Wiki User the 2nd: Wikipedia:Subpages is a good place to start reading about subpages, how they work, and the current guidelines for use. — xaosflux Talk 19:38, 2 June 2020 (UTC)

Increase default thumb size of images?

Wikipedia's default size for images has been 220px since forever. Most of the rest of the internet, meanwhile, has started using larger images for desktop displays as screen resolutions have increased and design standards have evolved. Readers also very much appreciate images as counterpoints to large blocks of text, and it would be helpful for many images to be a little larger so that there would be less need to click on them. Is this sentiment something other editors share? If I were to make a formal proposal to increase the size of images, what technical or editorial considerations would I want to have in mind? Are there any precedents or prior discussions I should read up on? {{u|Sdkb}} talk 22:03, 2 June 2020 (UTC)

@Sdkb: can you be a bit more specific? The "default size" for images on desktop is actual size, see below: (Giant image removed) — xaosflux Talk 00:58, 3 June 2020 (UTC)
— xaosflux Talk 00:22, 3 June 2020 (UTC)
@Xaosflux: I meant default thumb size; thanks for catching that. I'll refactor the header. {{u|Sdkb}} talk 00:24, 3 June 2020 (UTC)

@Sdkb:, for reference, here is the configuration part about thumbnails: 

'wgThumbLimits' => [
	'default' => [ 120, 150, 180, 200, 220, 250, 300, 400 ],
	'+itwikiquote' => [ 360 ],
	'svwiki' => [ 120, 200, 250, 300, 360 ],
	# nlwiki uses 260 instead of 250 (T215106)
	'nlwiki' => [ 120, 150, 180, 200, 220, 260, 300, 400 ],
],
'wmgThumbsizeIndex' => [
	'default' => 4,
	'fiwiki' => 5, // T162376
	'nowiki' => 5, // T155892
	'svwiki' => 2, // T18739
	'nlwiki' => 5, // T215106
]
So yes, we use the WMF default of "220", several other projects use 250. Do you have a specific size from this list you would propose? Another proposal is to let users pick (this would not impact logged out readers) - and that can be followed at phab:T106640 and/or phab:T71973. — xaosflux Talk 01:05, 3 June 2020 (UTC)
@Xaosflux: I don't have a specific size in mind, other than "larger"; would you have a preference? Allowing users to specify a custom size is fine, but I'm much more interested in changing the default, since only a tiny fraction of readers are logged in. {{u|Sdkb}} talk 01:31, 3 June 2020 (UTC)
We can't go much larger than 220 for many non-free images at this point due to our limits on pixel count (based on typical aspect ratios of 4x3 and 16x9), and going larger in thumbnail size also begs the question "but that means can have larger NFC, right?" which is NOT true. --Masem (t) 02:02, 3 June 2020 (UTC)
@Masem: ah, that complicates things a bunch if we'd have to adjust our standards on non-free content as a prerequisite. I'm not a copyright expert, but I do think that part of Wikipedia's mission of making knowledge accessible ought to include standing up for less stringent fair use restrictions, and my uneducated guess is that our standard is probably too conservative. To what extent is raising the pixel count limit a non-starter? {{u|Sdkb}} talk 02:24, 3 June 2020 (UTC)
We have adopted a standard of 0.1 megapixels (100,000 pixels) as a generally max size. For an older 4x3 screen, this gets a max size of about 365 x 275px; for 16:9, 420 x 237, and for 16:10 , 400 x 250. Other common aspect ratios are album art, 1:1 which max out at 0.1 megapixels or 316x316. Yes, we could inch the thumbnail size higher, and I believe what happens if that if the default thumb went to 300px, but you had an image that only had 200px available the image only comes out 200px with thumb, but I know people would size their nonfree to that default size. That 0.1 megapixels is sorta fixed in policy and respect fair use concepts, so its really non-negotiable from that aspect. --Masem (t) 03:41, 3 June 2020 (UTC)
Ah, oh well. If someone with copyright expertise wants to weigh in about what considerations led to the 0.1 megapixel limit and whether it's reasonable, I'd be curious to hear it, but so long as that limit remains in place it seems this is dead on arrival. Cheers, {{u|Sdkb}} talk 07:49, 3 June 2020 (UTC)
Of course our default now looks absurdly and embarassingly small. Are there actually that many non-free images used now? Far fewer than there used to be, I think, and many of them could and should be swopped for Commons images. Is there an automated way to limit the remaining ones to an acceptable size? Johnbod (talk) 21:10, 3 June 2020 (UTC)
Based on previous discussions, the Technology folks are going to ask you to pick one of the existing sizes from that list (so probably 250 or 300), they will expect some evidence of community consensus (unless you can get the mw:Desktop improvements team to 'own' that decision – User:SGrabarczuk (WMF), is there any chance of that?), and the change will not happen instantly (because performance requires preparation). They may also ask you to manually size up the images on high-traffic pages in advance.
Whatamidoing (WMF), I'll share this idea with the team, and we'll discuss this. At first glance, I suspect we'll not 'own' the decision in the upcoming months. I might be mistaken, though. Thank you for the ping! SGrabarczuk (WMF) (talk) 21:30, 7 June 2020 (UTC)
Also, no matter what you change, it's going to mess up someone's carefully calibrated arrangement that works for their browser/font/size/zoom, so you should expect at least a few complaints. Whatamidoing (WMF) (talk) 03:03, 7 June 2020 (UTC)
Category:All non-free media has at least 700,000 files in it. Most of that are logos (150k), album covers (180k), film posters (83k), video release covers (17k), television screenshots (16k), and so on. this is only going off the category count page, so if things aren't categorized right, there will be more. --Masem (t) 03:19, 7 June 2020 (UTC)

Addition of Police Killings of Black US Citizens to Wikipedia as a category

Moved to Wikipedia talk:WikiProject Black Lives Matter § Addition of Police Killings of Black US Citizens to Wikipedia as a category

{{u|Sdkb}} talk 23:41, 6 June 2020 (UTC)

User ranking/point system

There should be a rank, karma or a trophy system for users like Reddit in order to further encourage Wikipedia users to make contributions. — Preceding unsigned comment added by Erenchu1 (talk • contribs) 13:02, 7 June 2020 (UTC)

We have WP:BARNSTARS for those who feel the need to award them. Headbomb {t · c · p · b} 13:45, 7 June 2020 (UTC)
...and any more formal ranking system would lead to some editors gaming the system by trying to get high rankings rather than doing what they think makes for the best encyclopedia. Phil Bridger (talk) 15:13, 7 June 2020 (UTC)
WP:SERVICEAWARDS. --Ahecht (TALK
PAGE) 20:38, 7 June 2020 (UTC)
Reddit's karma system isn't great; Stack Exchange's Reputation system is better. For Trophies, we already have the 'Thanks' system. And for ranks, we have Service Badges. >>BEANS X2t 08:30, 8 June 2020 (UTC)
Yes you are right due to if paid editing is stopped we can encourage more again by something more than money thanks,barnstar are a wish from other editors but what did wiki offer to it's editor is the mean point which i am focused on. If we just start something new we could complete many undone thing to boost a working energy we need encouragement Tbiw (talk) 13:40, 8 June 2020 (UTC)

I certainly wouldn't complain if people went around giving out a bunch of barnstars whenever they saw good edits. { } 05:12, 9 June 2020 (UTC)

That is also cool.But is there any policy backing it. Tbiw (talk) 11:07, 9 June 2020 (UTC)
Barnstars are simply informal tokens of appreciation handed out in user talk space. There is no need for any policy to back them. Phil Bridger (talk) 11:15, 9 June 2020 (UTC)
Okay. Tbiw (talk) 11:40, 9 June 2020 (UTC)

Barnstar idea?

Hello,

With all the ongoing events, it feels there there is always a breaking news story. While I don't edit these (yet), I do tend to monitor them, and I noticed that there are a number of individuals who are really good at preventing WP:RECENT and making sure that throughout the early stages of the article, (I mean when there is the breaking news template), that there is minimal bias, no vandalism, nothing on WP:NOT and generally keeping the article clean. I think this qualifies for a separate barnstar as a lot of people will use Wikipedia as one of their first point of reference and it is super important that we can be relied on to maintain our high standards for them.

Not only that, but often these people get either standard or minor barnstars, when there is really a place for a 'WikiReporter Barnstar' or something like that...

I dunno, I could be totally crazy but to me it seems like a good idea

Regards, Giraffer (talk) 09:58, 8 June 2020 (UTC)

@Giraffer: Does The Current Events Barnstar fit your description? Sam Walton (talk) 10:03, 8 June 2020 (UTC)
@Samwalton Sort of... I mean it more or less covers it, although I would say my idea is more 'breaking news' style. For instance, the Norilsk oil spill is in the current events portal, but is a week old.
Now that I see that I guess that it is too similar to my idea for the latter to be created, but I would suggest moving it from Topical Barnstars to General Barnstars. -Giraffer (talk) 10:26, 8 June 2020 (UTC)

Articles should not include adjectives such as false and incorrect without irrefutable proof (facts of science).

I don't think that general consensus is enough to say this. We should restrict these judgments exclusively to facts that can be 100% confirmed (i.e. temperature at a time, the amount of people at a place when photo evidence is in place etc). This stems from what I saw on the GamerGate article, it strikes me as quite biased to state whether an accusation was false or not. I think it would be more acceptable to write "these accusations were dismissed by many as false". Wikipedia should contain only the events that happened and allow its readers to gather whether the claims were false or not. — Preceding unsigned comment added by Zdrowa koza (talk • contribs) 11:22, 7 June 2020 (UTC)

We describe things in the way that they are described by independent reliable secondary sources, with regard to weight. Gamergate controversy (which is presumable the article you are concerned about above) has been discussed extensively (see the 59 archives linked from Talk:Gamergate controversy) and consensus has been the the current state of the article reflects such sources correctly, but if you can add anything that hasn't been said before then that talk page is the place. Phil Bridger (talk) 15:48, 7 June 2020 (UTC)
The place to discuss this would indeed be at the article's talk page (where you should present reliable sources that contradict the others), or at a policy-related page such as WP:VPP, WT:RS, WT:NPOV, etc. —PaleoNeonate – 12:18, 11 June 2020 (UTC)

Solution to the portal system

In Wikipedia:Village pump (proposals)/RfC: Ending the system of portals, there was a proposal to end the system of portals. Even though there was a consensus against it, portals still have many problems:

  1. Many portals are neglected or abandoned. Even though some have editor(s) maintaining them, they are not being actively developed.
  2. Portals often receive extremely low pageviews. For example, New York City gets around 20,000 pageviews a day, Portal:New York City gets between 50 and 250 pageviews a day. this is very low for such a popular topic. Some, such as Portal:Scottish islands, only get 5 pageviews per day, and on some days, none at all.

The cause of this is mostly because portals aren't linked enough from main articles. My solution to this is to add {{Portal banner}} to the top of pages to guide users to the portal. If these banners are put at the top of articles, more users will be guided to portals, and they will help users easily find what they need. CrazyBoy826 22:19, 2 June 2020 (UTC)

The question I've always had about portals is, at a fundamental/philosophical level, what differentiates them from pages? Why would a reader want to go to the NYC portal rather than just the NYC article? Until that question is answered, I don't see there being support to make portals more prominent. As far as maintenance goes, my preferred solution would be to make sure everything about them is even more fully automated. {{u|Sdkb}} talk 23:37, 2 June 2020 (UTC)
@Sdkb:, the main page is just an overview, and the portal contains a larger set of articles which contain more information. Each page links to the portal, but is just a very small box at the bottom of the article. If someone was doing research on NYC, they would have found a lot more information on other articles linked to from the portal. CrazyBoy826 00:38, 3 June 2020 (UTC)
The NYC article has a lot of wikilinks, so I'm not sure I find that persuasive. If you hope to convince other editors that we should be linking prominently to a space that nearly got deleted, you're going to need to provide a plan for an overhaul with a compelling explanation for why it will succeed, not just explain the rationale for the space that was given when it was created. {{u|Sdkb}} talk 00:47, 3 June 2020 (UTC)
@Sdkb: The links are in the body of the article, and you only see them when you read to that section. The portal gathers all the links together and lets the user easily navigate them. Also, I partially agree with you - portals will need a huge redesign before this is going to be implemented. CrazyBoy826 15:56, 3 June 2020 (UTC)
Also, it wasn't "nearly delete" - there was an overwhelming consensus to keep. CrazyBoy826 16:06, 3 June 2020 (UTC)
That's not the words the closer used either. DexDor (talk) 18:22, 3 June 2020 (UTC)
  • Having a prominent link that directs readers from articles to pages many of which are (in the OPs words) neglected or abandoned probably isn't improving the reader experience. Something targeted just at editors (although I'm not sure how) might be more appropriate. DexDor (talk) 18:22, 3 June 2020 (UTC)
I think that having a permanent banner/{{abox}} at the top of an article is a big no-no, and goes against what is the current convention (talk page, footer, etc). >>BEANS X2t 13:47, 4 June 2020 (UTC)
  • Then we can make an exception for that if needed. For the question of "linking prominently to a space that nearly got deleted", we need to revisit portals and clean them up. We can also restore deleted portals at MfD (partial list here) because this will cause much more people to visit the portals. CrazyBoy826 01:08, 5 June 2020 (UTC)
@Sdkb: @BEANS X2: @DexDor: CrazyBoy826 01:09, 5 June 2020 (UTC)
I don't understand your comment (which links to an empty list). DexDor (talk) 06:04, 5 June 2020 (UTC)
@DexDor: @BEANS X2: @Sdkb: I have fixed the url - it should work now. CrazyBoy826 23:16, 6 June 2020 (UTC)

We already have infoboxes and templates that link to related articles on a topic. I think that if we were to link to portals on pages then there would need to be a justification that this offers something more than what infoboxes do. Pi (Talk to me!) 00:01, 12 June 2020 (UTC)

Changing default signature

Currently, the default signature is Example (talk). However, this does not include contributions, which is more important than the user page. Also, the user page is nice to have but frankly unnecessary. Using another design for the default, such as Example (talk | contribs) would be much more useful. Another possible one (although it excludes the user page) would be Example (talk), with the contribs taking the place of the user page. There are other proposals, such as the one used by ClueBot NG - Example (u) (t). I would also personally suggest the parentheses being in the link for the two-part design and ClueBot NG design - Example (talk) Any suggestions? CrazyBoy826 22:23, 9 June 2020 (UTC)

  • With very few exceptions, the linktext "Example" always links to User:Example. It would be a bad idea to deviate from that, particularly in something so ubiquitous as the default signature.
  • By my accounting, adding a contribs link would add (28 + length of username + length of linktext) bytes to the wikitext for every default signature.
  • To include a contribs link (usually) saves only two clicks – one to access the UP or UTP, another to access its history. New editors might find this cumbersome, but it soon becomes automatic, like driving a car. But I can speak only for myself on that point.
  • In my opinion, costs exceed benefits. ―Mandruss ☎ 21:47, 10 June 2020 (UTC)
I think having the user page (to see what a user thinks of themselves) and the talk page (to see what other users think of them) is sufficient and complete. "Contributions" can certainly be useful, but it shouldn't appear as a main way to interact with a user. Adding it as a default link for any signature has the possibility to present something akin to stalking as an accepted behavior, at least to newer users. For any experienced editor (as just noted) it's just another click. There's no real benefit, and at least a bit of harm, in making contributions a default link in signatures. Perhaps we can substitute contributions for users lacking a talk page (like we typically do for IPs), but that's it. --A D Monroe III(talk) 22:44, 10 June 2020 (UTC)
CrazyBoy826, have you found the WP:NAVPOPS gadget in your preferences? You might find it more useful than a signature change. WhatamIdoing (talk) 22:45, 10 June 2020 (UTC)
@WhatamIdoing: But the page history shows the signature above, and all templates (like unsigned) use the same version except replacing the pipe with a bull. CrazyBoy826 17:15, 11 June 2020 (UTC)
So? If you want quick access to someone's contributions, then I recommend turning on NAVPOPS. That is an immediate way to get the access that you want. If your goal is that everyone else have quick access, then it sounds like other people don't actually want that. WhatamIdoing (talk) 19:13, 11 June 2020 (UTC)
What A D Monroe III said. The number of times a typical reader or casual editor would have reason to view a given editor's contribution history is as close to zero as makes no difference. Anyone who's versed enough in Wikipedia to actually have a legitimate reason to read an editor's contribution history is also going to be aware of how to turn on popups, and of what the "contributions" link does. Including a link to it in every signature would add non-negligible bloat to the edit window in every discussion, potentially confuse readers who won't necessarily understand the significance of a string of names and numbers, and send the signal that "looking through someone else's contribution history" is a normal and acceptable course of conduct. This is the Idea Lab and you're obviously free to disregard any advice you receive here, but I'm fairly confident that were you to make any proposal of this nature it would be overwhelmingly opposed. ‑ Iridescent 09:34, 12 June 2020 (UTC)

Improving references on script level

Hello, what do you think about adding a function of suggesting sources to references and adding display of the date of the newest source? This way a reader can easily see whether the article may or may not contain outdated information. One more thing is to add some sort of reliability indicator to every reference, which can be done by evaluation of not every single site but the publisher or author. —DonGuess (talk) 12:20, 17 June 2020 (UTC)

"Reliability" is very subjective and depends on what the source is being used for; while it's possible to blanket-declare a source as inherently unreliable (take a bow, Daily Mail), there's no such thing as an inherently reliable source. Branch Lines around Witham and Kelvedon would be an absolutely cast-iron source to use on Kelvedon and Tollesbury Light Railway, but wouldn't necessarily be reliable as a source for River Brain in any context other than railway bridges over the river, since even though it doubtless mentions the river it's not the authors' area of expertise. Each source would need to be exaluated manually in the context of each individual article, which when you're talking 6,929,279, some of which have upwards of 200 references apiece, is no simple task. The Cite Unseen script will (theoretically, anyway) highlight references from tabloids, blogs, and user-generated sites, if that's what you're looking for. ‑ Iridescent 14:13, 17 June 2020 (UTC)

Create a new template for articles that have limited available sources yet are still notable

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.

What if we create a hatnote template that would tell readers that a subject (that is notable) has a limited amount of sources. A good example is Francisco Malespin, who was a Central American Military Leader, but has limited coverage because of the time period he comes from and limited surviving sources which still give quality coverage of him. Any ideas?

Somthing like this could do, no?

This article is notable, but contains a limited amount of reliable and surviving sources. Please DO NOT mark it in need of more citations or delete it.

P,TO 19104 (talk) (contributions) 15:57, 19 June 2020 (UTC)

Technically as long as there are enough sources to show that the WP:GNG is met or one of the subject-specific notability guidelines is met, there is no need for a template. If you are creating an article and don't feel that you have enough sources like that, then you can always create it in draft or user space until you get enough sources to support it. --Masem (t) 16:09, 19 June 2020 (UTC)
And I would add that, in this particular instance, there is plenty of coverage of Malespin in academic books and papers. Phil Bridger (talk) 16:13, 19 June 2020 (UTC)
Ok. Thank you. P,TO 19104 (talk) (contributions) 16:48, 19 June 2020 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Workshopping an esports section for WP:Notability (sports)

Since this discussion in 2011, esports have been excluded from Wikipedia:Notability (sports) ("At this time there is no consensus that electronic sports participants are covered by the criteria of this guideline."). In the past decade, there has been a marked increase in the coverage of esports in reliable, third party sources, corresponding with a boom in the industry itself.

Almost all of the articles on esports and esports players on Wikipedia have been written since then, relying on the WP:GNG, and I believe that having a baseline for notability in esports athlete articles would be useful, and may encourage more content to be created in the area. To that end, I'd like to propose an ammendment to Wikipedia:Notability (sports) to remove the line in parenthesis above, and add the section below.

===Esports=== {{shortcut|WP:NESPORTS}}

Athletes who compete in esports are presumed notable if they meet any of the criteria below
  1. Have won a major tournament or league in a significant solo-competition esport
  2. Have won a major tournament or league in a significant team-based esport, and played in at least one match during that event

Coaches are presumed notable if they are the head coach for a team when it wins a major tournament or league in a significant team-based esport

For the purpose of this guideline, a tournament or league is considered "major" if it meets any of the criteria below
  1. It is designated as such by the primary governing body for that esport (such as those in the Dota Pro Circuit)
  2. It is designated as such by a third-pary rankings body that is considered by reliable sources to be the primary benchmark for that esport (such as the Panda Global Rankings Ultimate)
  3. It is considered by reliable sources to be one of the largest events ever held in that esport in either number of overall competitors, number of top-ranked competitors, or prize pool
For the purpose of this guideline, an esport is considered "significant" if it meets any of the criteria below
  1. There is enough significant coverage in reliable sources about the esport itself to create an "... in esports" article (League of Legends in esports, Hearthstone in esports, etc.)
  2. There is enough significant coverage in reliable sources about the esports' largest tournaments or top level league to create an article (Overwatch League, Rocket League Championship Series, etc.)

I tried to make something that would cover top players in major events, while not opening the floodgates for players without sufficient coverage, but I wanted to workshop this before proposing it, mainly because I'm only familiar with Smash and Overwatch and want to make sure it works well across the entire industry. Any feedback would be appreciated. The Squirrel Conspiracy (talk) 22:57, 20 June 2020 (UTC)

  • Is there a particular reason you did not reference the more-recent Wikipedia:Village pump (policy)/Archive 130#Notability guidelines and policy for eSports? You will need to deal with the discussion there. --Izno (talk) 23:16, 20 June 2020 (UTC)
  • As I've said before, I think supporters of having eSports notability guidelines would be better off sidestepping the question of whether or not eSports falls under the scope of the sports notability guideline. Just get consensus support to adopt your proposal as a guideline, and keep it as a separate page. isaacl (talk) 23:57, 20 June 2020 (UTC)
    • Yes, I've noticed in the 2016 thread that Izno linked me and the 2011 thread that there's a disappointing number of people that never got past "esports isn't sports". It might be better to keep it separate. But how does the proposed content look? The Squirrel Conspiracy (talk) 01:04, 21 June 2020 (UTC)
      • I think the proposal should be a lot more specific and it would be very helpful if you demonstrate how adept the criteria are at distinguishing between subjects that have significant, independent, non-routine, non-promotional secondary coverage from multiple reliable sources, and those that don't. For example, make a list of a wide sampling of those meeting the criteria, and demonstrate that appropriate coverage exists for them. The discussion from 2016 raised a lot of good considerations regarding the quality of sources, namely their degree of non-promotional, independent coverage. Providing additional guidance on sorting through sources in order to determine if the general notability guideline is met could be useful. isaacl (talk) 02:04, 21 June 2020 (UTC)

Anti-vandalism steps

Wikipedia is platform with vital information meant to be protected and added . While some want to destroy it. Inorder to protect that we must take some steps. All articles of such(historical events and highly vital) should be protected for only extended confirmed user to edit . And to curb user from harming wikipedia we should given taken some steps.

1.give new user our ,guidelance and how to edit.

2. Ensure that they is a thing monitoring them we have to improve defcon who tells people warning about vandalism rate.

3. When this defcon is really improve when user is blocked he/she will know it is true.

With all these few steps vandalism should be stopped. Let give them the policy warn them and block (determined by admin). Wikipedia vandalism can be reduced or eradicated by this step. And let everyone pledge on there talkpage. I am a contributor not a vandal. Tbiw (talk) 20:25, 28 May 2020 (UTC)

No, we're not going to do that. Protection is a last resort, not a blunt instrument to be applied to everything; The ability of almost anyone to edit (most) articles without registration is one of the non-negotiable founding principles with which all Wikimedia projects have to comply. (Besides, who decides which articles are "highly vital"? You? The most important article is the article on whatever topic you happen to want to know more about. Indeed, there's a good case to be made that the high-traffic "big topics" are our least important articles, since they're the topics on which readers can most easily find information elsewhere should our article not be adequate; if Wikipedia's article on Paris were poor quality I could easily find what I wanted to know elsewhere, but the same isn't the case with Neilston.) ‑ Iridescent 20:43, 28 May 2020 (UTC)
Man I am only saying the vital and I have explained it. Okay know if a history is vandalised it will cause a huge thing when reader are unable to read .I know all articles are vital and bot all will be protected due to free online use in which anyone can edit .So we can't do that. Just call those information am saying delicate. Tbiw (talk) 13:15, 29 May 2020 (UTC)
You absolutely haven't explained vital. Indeed we have an ever growing "vital article" list that gets ever more non-vital vital articles over time. 1 & 2 are already in place, and I'm not sure what 3 is really saying. Beyond that, Iridescent is completely right. As another point, the higher entry points become, the fewer editors we get reaching that point. If they can't edit what they view is important, many fewer will stick around. Nosebagbear (talk) 14:49, 29 May 2020 (UTC)
My vital doesn't means no information on Wikipedia isn't useful but does strong ones such historical events if vandalised and reader at the moment just click onto it and want to read and it blank he will feel bad . That's my vital Tbiw (talk) 16:46, 29 May 2020 (UTC).
OK, since you're clearly either refusing to listen to us or being intentionally WP:IDHT, let me ask a few questions:
  1. Give two examples of articles you consider so "vital" that we should suspend one of our most fundamental principles and lock them into a "preferred version". Explain in both cases just why you think this would be helpful and how they differ from the other 6,929,279 articles on Wikipedia;
  2. Since we know that permanent protection causes serious problems with accuracy—in current event topics because they're no longer updated with recent developments, and for historical topics because they're not longer updated to reflect recent research—how would you address this? The number has risen slightly owing to coronavirus lockdowns but it's reasonable to assume that as people return to work, we'll fall back to our baseline of roughly 3500 active editors; it's not practical to expect them each to keep 1700 articles apiece updated and current, and we rely on IPs and very occasional logged-in editors for much of our content;
  3. "Big" topics are precisely those topics which are most likely to attract new editors to Wikipedia. Since existing editors resign, die, or just get bored all the time, we need a constant influx of new recruits, who are unlikely to persist with a project that automatically rejects their initial attempts to contribute; what would you propose to replace this?
  4. As per my earlier reply, The ability of almost anyone to edit (most) articles without registration is a non-negotiatiable principle. (While we do have around 2000 pages that are subject to extended semi-protection, they're almost all linked to a couple of very specific topics on the expectation that should the edit-warring on those topics die down the protection will immediately be lifted.) Since your proposal is fundamentally incompatiable with the Wikimedia Foundation's mission, are you proposing that we somehow persuade the Wikimedia Foundation to rewrite their principles, or that English Wikipedia disaffiliate from the Wikimedia Foundation? In either case, how would you propose to go about it and how would you mitigate the massive financial and reputational damage that would stem from having to renegotiate all of our donor agreements?
I'm sorry to be so blunt, and I'm aware that the Idea Lab is supposed to be for blue-sky thinking, but unless and until you can give concrete answers to all these questions, this is a complete non-starter. You're basically proposing that we turn Wikipedia back into Nupedia or Citizendium, which quite aside from the fact that we know what happened in both those cases and why, goes totally against our "the free encyclopedia that anyone can edit" ethos. ‑ Iridescent 17:20, 29 May 2020 (UTC)
Getting me or taking me wrong is what resolve to all this question. Let me answer you first question . Your first question is give example of vital . My vital is just a emphasing of point. Two are historical and biographies. If they are vandalised that is not good. I get your point you are trying to say if an information that will boost up the articles is not in the hands those allowed infornation won't be place and article won't get stronger. Yes if that did not work get another solution . And I not trying to ignore answer to questions nor I want to destroy wikipedia goal . I am only trying to help to prevent vandalism that all.not to go against wiki policy.Tbiw (talk)
Ok, now you've clarified that your definition of "vital" is "historical and biographies", this is definitely not going to happen. There are 2,043,913 biographical articles and 8,424 biographical lists on Wikipedia, and a similar number of historical articles (the exact figure will depend on how you define "historical"). What you're actually proposing is a de facto closure of Wikipedia, since no new editor is going to bother hanging around chatting on talk-pages for 30 days and 500 edits so as to reach extendedconfirmed status. Please, drop this. ‑ Iridescent 07:35, 30 May 2020 (UTC)
Okay that doesn't work I have dropped it. Tbiw (talk) 10:36, 30 May 2020 (UTC)
The following discussion is closed and will soon be archived.

If you don't know how to search something like you dont know just type it into this group editors will respond to it and you will go and search it in details. To boost what am saying. E.g You don't know lion. Just type as user/reader like this hmmm.What the name of the animal that has air on it head brown in colour and not and it kid now it as the king of the jungle after few times reply will come with link. Lion. Tbiw (talk) 10:48, 16 June 2020 (UTC)

This feature already exists, and is called "Google". The WMF did once consider creating a search engine of its own, but the proposal was a disastrous fiasco which led directly to the resignation of our executive director, and has long-since been abandoned. ‑ Iridescent 14:03, 17 June 2020 (UTC)
Or WP:REFDESK Headbomb {t · c · p · b} 14:09, 17 June 2020 (UTC)
The following discussion is closed and will soon be archived.

Wikimed

Wikimed is a plan planned by me it is a place whereby we can interview you Larry sanger ,Jimmy wales and other users and we will be gisting about what you have in mind. E.g Hey when is the championship go to start? and those things like that. You can question a user about some things you know people could also declare what they want for wiki. This idea might sound stupid but please just try to review it. You can also add want you want and you can also remove. Tbiw (talk) 07:33, 19 June 2020 (UTC)

The following discussion is closed and will soon be archived.

Toggle switch to hide/show references

Hi, to make Wikipedia nicer to read, wouldn't it be a good option to have a Toggle switch button to hide and show the references (superscript numbers between brackets)? Warning like "Reference needed" could remain in both case. Gfombell (talk) 12:18, 21 June 2020 (UTC)

References are the most important part of any article, so I would not support any such proposal. They are the only way that articles in the encyclopedia that anyone can edit can be seen to be reliable. In some cases, usually in reponse to demands that content should be fully sourced, we see superscript numbers in the middle of sentences and many superscripts where one would do (both things that I have been guilty of) but I would certainly not support any way of hiding them. I'm sure this has been suggested several times before and rejected. Maybe someone could find those discussions and link them, because I'm sure there are other reasons supporting or rejecting such an idea. Phil Bridger (talk) 16:48, 21 June 2020 (UTC)
Indeed this one has been suggested before. The suggestion is in the realm of the possible, and I'm fairly certain a user script popped up for the enterprising reader, but I think it has zero likelihood of being implemented for everyone. --Izno (talk) 17:40, 21 June 2020 (UTC)
Encyclopedias are tertiary sources which are designed to introduce readers to a topic and lead them to more comprehensive information.--Moxy 🍁 18:49, 21 June 2020 (UTC)
Agreed with the others that readers' information literacy is bad enough already without allowing them to hide the most essential thing allowing them to verify what they're reading. However, there is one change in this realm that I'd like to see implemented (if it can be done in a way that's usability-savvy, mobile friendly, accessibility-compliant, etc.) — the reference sections on some pages are gigantic, and it'd be better if they were autocollapsed by default. (See this conversation for some concerns that would have to be worked through.) {{u|Sdkb}} talk 20:32, 21 June 2020 (UTC)

ok, I understand the rationale, thanks for responding. Gfombell (talk) 16:21, 22 June 2020 (UTC)

For the sake of discussion, I'd love to have that feature as a toggle so that I can copy prose into FfD/DYKN discussions without having copy the numbers/brackets. I agree cites should be visible by default, but there are useful reasons to hide them from time to time. The Squirrel Conspiracy (talk) 17:19, 22 June 2020 (UTC)
You can now use User:Majavah/ToggleReferences which adds an entry to the "More" menu on top of pages to toggle footnotes on/off. – Majavah talk · edits 17:34, 22 June 2020 (UTC)

Bot idea

AntiSockpuppetBot

Would: Close SPI's Find disruptive IP's with two or more accounts and report them to SPI Hopefully be a CheckUser — Preceding unsigned comment added by Another Wiki User the 2nd (talk • contribs) 14:35, 22 June 2020 (UTC)

The impression that I get is that most sockpuppets are detected on the basis of behavioural rather than technical evidence, so until we get much better AI it would be difficult for a bot to identify them. And the privacy implications of a bot having checkuser powers are, let's say, interesting. And the targeting of IPs needs to be thought through. It is quite common for the same person to edit from multiple IP addresses perfectly within policy. Indeed most people are not even aware of the IP address they are using. Sock puppetry is only really an issue when at least one account is registered. Phil Bridger (talk) 16:41, 22 June 2020 (UTC)
A bot would also need a mechanism to detect valid uses of multiple accounts. For example, yesterday I edited with my main account, then an hour later made an edit with my mobile account, then an hour later made an edit on my main account. There's a very big difference between "I have a secondary account so I can edit from the bathroom on the go without being signed into my main account" and "I have a network of undeclared accounts to win edit wars". Would a bot be able to recognize that difference if it's just looking at IP addresses or even IPs and say, writing style? The Squirrel Conspiracy (talk) 17:17, 22 June 2020 (UTC)

Database website screenscrapers

There are 5,570 Brazilian municipalities, all notable based on WP:NGEO, but most are trivial stubs like Araguaiana. This is not for lack of information. The Brazilian Institute of Geography and Statistics (IBGE) maintains a database with extensive information on the geography, population, economy etc. of each of them. See Cocalinho and Brasil / Mato Grosso / Cocalinho for a sample IBGE entry. Using this information, and information from sources like GeoNames and Mindat.org, we can upgrade a stub into a more useful article like Cruzeiro do Sul, Paraná. There are about 750 municipalities in Nepal. For these, NepalArchives is an excellent source of information, with pages like Kanepokhari Rural Municipality Profile : Facts & Statistics Presumably there are many classes of article like this: mostly stubs, that could be upgraded with standard data from a database-type website.

The work would be tedious and error-prone. It would be easier using screenscrapers. These would be web-based tools where the user would enter identifier(s) associated with the stub article, and the tool would extract standard information on the subject from one or more database-type websites and return results, perhaps in template format like: 

|pop_year=2011 |pop=1,457 |male=713 |female=744 ...

That could be pasted into a template that would format the data for an editor to copy-and-paste into the stub article. There should be no copyright issues if the tool only extracts numbers, dates, identifiers etc. Apart from the effort of developing them, are there any concerns about an approach like this? Aymatth2 (talk) 23:21, 23 June 2020 (UTC)

This seems like a job that is perfect for Wikidata. Those articles could use an updated, functional version of {{Infobox settlement/Wikidata}}. – Jonesey95 (talk) 01:50, 24 June 2020 (UTC)
I would always suggest uploading the data into Wikidata first. Once that job is done, the data is then available for 300+ Wikipedias in different languages and we have the tools to create at least a comprehensive infobox for any article that could then be fleshed out as editors wanted. The site actually offers to export the data in xl, ods or csv format, so there should be no problem with getting that imported into Wikidata. --RexxS (talk) 01:59, 24 June 2020 (UTC)
There's actually a project working on almost exactly that issue. If you're interested, you might want to take a look at GlobalFactSyncRE. Vahurzpu (talk) 04:12, 24 June 2020 (UTC)
Oh. Ah! And in fact the GlobalFactSyncRE project is even looking at using Brazilian data from the national statistical office. So really there are two parts:
  • Develop a process to extract from a source like the IBGE and load it into Wikidata
  • Adapt the stubs to pull in the data from Wikidata.
I am not sure that all the data should be pulled into an infobox. Some types of data could be inserted into text, e.g. in the intro something like:
'''{{PAGENAMEBASE}}''' is a {{#property:P31}} in [[{{#property:P131}}]], {{#property:P17}}. It has an area of {{#property:P2046}} and as of {{#property:P585}} had a population of {{#property:P1082}}.
which renders in Cruzeiro do Sul, Paraná as:
Cruzeiro do Sul, Paraná is a municipality in Paraná, Brazil. It has an area of 259.103 square kilometres (100.040 sq mi) and as of had a population of 4,469.
(Some glitches to fix). Other data may be better in table/graph format, such as climate data. All that mark-up could be a bit forbidding to the regular editor, but could be hidden in a template like
{{Brazil Muncipality Intro}}
Interesting. Aymatth2 (talk) 15:45, 24 June 2020 (UTC)
@Aymatth2: I'm afraid that there is consensus against inserting Wikidata into article text: Wikipedia:Requests for comment/Wikidata Phase 2 concludes It is, on the other hand, not appropriate to use Wikidata in article text on English Wikipedia at this time ... There is a valid point raised that while running text is clearly not suitable for Wikidata use, it might be worth discussing use in tables specifically – but no consensus regarding this has been reached in this discussion. That well-attended RfC established the consensus in 2013, and there has been no change to that since. Using an infobox has consensus, and creating a table of information (inside a template) is a grey area. --RexxS (talk) 16:06, 24 June 2020 (UTC)
The 2013 RfC has been superseded by Wikipedia:Wikidata/2018 Infobox RfC which was done according to this Arbcom Motion. You can do Wikidata but it needs discussion/consensus. -- GreenC 16:31, 24 June 2020 (UTC)
That seems unfortunate to me. A source like IBGE is as reliable as they get, a mechanical transfer from IBGE into Wikidata would be error-free, and then the data could be presented consistently on thousands of pages on each of the different Wikipedias through standardized templates with names like {{Brazil Muncipality Intro}}. In effect, Wikipedia would be mirroring information from the reliable source, supplementing this data with other text from other sources. But even if we could get away with it for the infobox, there seems no point since the infobox is meant to be a summary of the text, and the data would have to be manually entered and maintained in the text. Aymatth2 (talk) 18:07, 24 June 2020 (UTC)
@GreenC: You are misinformed. The Wikipedia:Wikidata/2018 Infobox RfC was an RfC on the use of Wikidata in infoboxes. It certainly did not affect the consensus against using Wikidata in running prose. If you claim differently, then please supply a quote from the RfC close that supports your assertion. --RexxS (talk) 20:12, 24 June 2020 (UTC)

Assuming Wikidata is out of the picture, how about the original proposal? As an experiment, I created {{Brazil municipality}} to take data from mindat, geonames, the Swedish wiki (NASA data) and IBGE and format it as a combination of text/infobox. I tried it out for a sample of municipalities, manually taking the data from the sources and pasting it into {{Brazil municipality}}, then substituting the result into the stub and cleaning up. See Cocalinho, Cacaulândia, Saudade do Iguaçu, Cruzeiro do Sul, Paraná, Sulina, Paraná, Cacoal. (Some of these include additional data added later.) Would there be a concern with scraping the IBGE etc. websites to get the values for the {{Brazil municipality}} parameters for a municipality, then substituting the result into the existing stub for that municipality and tidying up? Aymatth2 (talk) 18:07, 24 June 2020 (UTC)

I'm not clear why you say Wikidata is out of the picture, the 2018 RfC does not prevent usage, but I think your original idea is fine too. There is also Commons Tabular data for use with template: User:GreenC/software/tabular -- GreenC 19:26, 24 June 2020 (UTC)
The 2018 Infobox RfC on the use of Wikidata in infoboxes changed nothing, except showing a single consensus: that "if Wikipedia wants to use data from Wikidata, there needs to be clear assurances on the reliability of this data." That's it. There was no other consensus that came out of the whole, huge exercise. You can't use Wikidata in article text. Period. --RexxS (talk) 20:12, 24 June 2020 (UTC)
Maybe I am misreading the conversation above discussing populating Wikidata for use in infoboxes. -- GreenC 20:41, 24 June 2020 (UTC)
Oh I see, Aymatth2 suggested "data could be inserted into text", yeah that wouldn't work.-- GreenC 20:46, 24 June 2020 (UTC)
Showing Wikidata values in text is obviously hugely controversial. Showing the Wikidata values only in an infobox does not work, because the infobox should summarize the text. We would have the potential for one value in the infobox and a different outdated value in the text. I want to go back to the original idea of having a screen-scraping tool that makes it easier to pick data off a source website and put it into text. Are there objections to that? Aymatth2 (talk) 21:54, 24 June 2020 (UTC)
That would be user-tool there are no limits, the final edit is done by an end-user who is responsible. It doesn't even require BRFA. -- GreenC 22:35, 24 June 2020 (UTC)
I came here because User:Hasteur said at Wikipedia:Bot requests#A bot to develop a mass of short stubs and poorly built articles for Brazilian municipalities that "Not a good task for a bot. Absolutely NOT. FULL STOP. Get a broadly endorsed consensus at Village Pump as there have been several cases (NRHP, Betacommand, etc) automated database dumps that have gotten editors drummed out either in part (restrictions on creation) or full on community/Arbitration banned. While you may think this is uncontraversial, this is requires a well attended RFC to confirm the sense of the community." I am confused. Is it "no problem", or "I try it, I get kicked off Wikipedia"? Aymatth2 (talk) 23:46, 24 June 2020 (UTC)
The proposal above, in your first post here, is for a tool to generate data that users then manually paste into an article. This is not a bot. It is a tool. We have lots of tools on Wikipedia. User:Hasteur's comment, he was assuming a fully automated bot to edit articles. There are no restrictions on creating tools you don't need to ask permission, so long as the final edit is done by human; this is what "tool" means distinct from "bot". -- GreenC 06:11, 25 June 2020 (UTC)
I guess User:Hasteur got stuck on the word "bot" in the request by User:Encyclopædius and did not see that it was about a screen scraping tool. Aymatth2 (talk) 11:49, 25 June 2020 (UTC)

Database website screenscrapers (break)

To go back to the original description from User talk:Aymatth2/Archive 14#Brazil municipalities:

I see it as a web page where

  • The user opens the web page, and enters the identifiers (the first parameters in the {{Brazil municipality}} template) and the Swedish Wikipedia page name,
  • The web server uses the identifiers to form the source urls,
  • The web server gets the source pages, scrapes the data, and then displays the text of the template with the parameters all filled out (or the full wikitext of the target page)
  • The user copies and pastes this into the target page, saves, and then cleans up.

I think it has to be user-driven, municipality by municipality, because there may be irregularities in the identifiers of the source pages, and will often be some data in the existing stub that should be preserved. But the screen-scraping should work because all the source pages are machine-generated from databases, so all have identical format. We may also want to go back over the pages in the future to get updates to some of the data. Possibly the user could give the web page a list of municipalities, and then click through them.

There are probably many other areas of Wikipedia that could use a similar approach, cloning data on stars, ships or species from authoritative databases.

Forget about bots and forget about Wikidata. The question here is whether there are any comments, objections, suggestions about a screen scraper tool like that, and whether some generic software could make it easier to develop tools of this nature. Aymatth2 (talk) 11:49, 25 June 2020 (UTC)

Discussion of Autobiography guideline - a proposal to change from "strongly discouraged" to "prohibited"

The guideline Wikipedia:Autobiography currently opens with the following sentence:

Writing an autobiography on Wikipedia is an example of conflict of interest editing and is strongly discouraged.

While the word "strongly" is italicized for emphasis, "strongly discouraged" is not the same as "prohibited".

In a nutshell, my proposal is that we change "strongly discourage" to" prohibited". (I am fine with the following sentence which permits editing of an existing biography by the subject in relatively rare situations.)

I recognize that this may not be viewed as a trivial change, and probably ought to go through a formal RFC, but as one of the original supporters of the idea lab, I've always felt that the right sequence of events is to talk through issues in the idea lab, then make a proposal. It may still require further modifications, but there's no point in going through the baggage of an RFC if this is a nonstarter, and I've seen RFC's derailed because the original idea needed to be more fully thought out before starting the RFC.

My concern is that I can easily imagining journalists saying something like the following: "Wikipedia claims to strive for a neutral point of view and claims that Wikipedia is not a vanity press, but the reality is very different. Yes, if you propose to write an article about yourself someone will point out the guideline that says it's discouraged, but then go on to tell you how to go about doing it. If you ever thought Wikipedia was an unbiased source of information this alone should convince you that it is not."

The problem is, if a journalist wrote this, Wikipedia would not be in a position to ask for a correction because it's quite true. I'd like to change that. I can't change the fact that we've permitted autobiographies in the past, and probably still have some, but I'd like to be in a position of saying that going forward, creation of a biography by the subject themselves is prohibited.

Someone may point out that we have no foolproof way of enforcing it, but I'd much rather say that the action is prohibited then to simply say that it is strongly discouraged.

On the off chance that some subject actually writes an acceptable article about themselves, we can remove it, and send it to the requested articles pile, where an independent editor can go ahead and create it and take responsibility for it, so the rare example of an acceptable article will not be lost.--S Philbrick(Talk) 22:23, 13 June 2020 (UTC)

  • I don't think that it makes sense to prohibit autobiographies unless we were going to prohibit them from participating on their own article in any sense, which obviously we don't do. Instead, it should be prohibited to create autobiographies except through AfC - much like a PaidCOI creation. Obviously we already push that as a "if you must", but I'd support that being a nutshell summary, rather than buried in the bottom paragraph as a preference. Nosebagbear (talk) 10:29, 15 June 2020 (UTC)
  • The broader guideline on COI does not ban participation by users with a COI and I would prefer our guideline on pages to be the same. --Izno (talk) 16:12, 15 June 2020 (UTC)
  • The guideline/policy for creating an article does not have to be the same as that for editing it. If article subjects spot libel or other unsourced disparaging content in articles then they should have the right to remove it immediately, but there is no equivalent reason for creating an article. Phil Bridger (talk) 17:01, 15 June 2020 (UTC)
    Phil Bridger, I agree. This is a good rationale for different treatment. S Philbrick(Talk) 17:24, 15 June 2020 (UTC)
    +1 signed, Rosguill talk 17:32, 15 June 2020 (UTC)
  • I'm kind of confused - are we saying that autobiographies are appreciably more problematic (in COI terms) than paid editors? While they always have significantly more unconscious bias than they think, I've generally found them (on average) more willing to listen to feedback and at least attempt to make genuine changes than paid COIs. While PCOIs can create articles (through AfC) then I feel autobiographies should be permitted (but also only through AfC). Nosebagbear (talk) 18:43, 15 June 2020 (UTC)
  • Yes this a very good thing strongly discourage is weak prohibited is strong .Tbiw (talk) 07:37, 19 June 2020 (UTC)
  • I agree that autobiographies must not be directly created in mainspace. AFC is fine, that's what it is there for. MER-C 15:37, 21 June 2020 (UTC)
  • I'd rather have no conflict of interest edits at all. --NaBUru38 (talk) 21:03, 27 June 2020 (UTC)

Colour text options

I have a suggestion that we should attempt to build a feature into Wikipedia where users can change the colour of the text for an article. This could either be for the entire page or selected words. This could be highly advantageous for people with sight and/or reading difficulties and could make Wikipedia far more accessible and user friendly. I'm not proposing any policy change or the way Wikipedia currently uses colour, but for a new built in optional feature. This option could be located under the 'tools' section on the left-hand side of the page, or there could be a new section titled 'accessibility' or 'accessibility options’. I understand some people may say those with sight difficulties may already have this software but for the sake of those that don't and to make Wikipedia as user friendly as possible without having to resort to outside software I think this could be really helpful. Helper201 (talk) 00:17, 24 June 2020 (UTC)

@Helper201:, by no means a bad idea at all, to encourage the WMF to provide more accessibility options for the projects. Unfortunately, we can only really ask (with a decent chance of receiving) for discretionary improvements like that in the "Community Wishlists" that come round once a year - usually in November. The slowness of them implementing a nightmode makes me concerned that this is harder than we might think/desire, but I can't speak for that. Nosebagbear (talk) 13:39, 24 June 2020 (UTC)
While it would do no harm, I'd imagine that this would be absolute bottom in terms of priority at the developer end, and would probably be vetoed by the WMF as a waste of money were it to somehow make it onto the Community Wishlist. It's a part of the WAI guidelines and standard web browsers already have the option to set the default text colour and zoom in preferences; any reader with a disability (or just poor eyesight) who wanted to change the default text appearance would almost certainly prefer to change it across the board in their browser preferences, rather than have Wikpedia text appear in their preferred style but have every other website appear unchanged. ‑ Iridescent 14:16, 24 June 2020 (UTC)
In my opinion, it would make Wikipedia look like an eyesore. I think it should be only applied to user pages if the devs go with it. KeyboardThatsInverted (talk) 19:22, 24 June 2020 (UTC)
KeyboardThatsInverted, I think you're misreading the question; this isn't about how to change the display font of Wikipedia articles (which is already different for every user, as it's whatever the reader has set as their default sans serif font in browser preferences); it's asking whether it's possible for a reader to change the font Wikipedia appears in to them and only them, without changing their browser display font and thus changing the appearance of every website they visit. ‑ Iridescent 19:28, 25 June 2020 (UTC)
Oh, okay then. KeyboardThatsInverted (talk) 21:09, 25 June 2020 (UTC)

Hello, Helper201! You can change your user style options at User:Helper201/common.css. See instructions at Help:User style. Have fun! --NaBUru38 (talk) 21:08, 27 June 2020 (UTC)

Hi, NaBUru38, thank you, I didn't know that. My suggestion however is not just for the benefit of registered users or registered editors of Wikipedia, but an optional tool that anyone using the site would be able to use. Helper201 (talk) 01:11, 28 June 2020 (UTC)

Making it an official behavioral guideline to not rely completely on edit count

I suggest that we make it an official behavioral guideline to not completely base an idea of a user on their edit count. The page “Edit count” on Wikipedia is an essay, but I think it should, maybe with some modifications, become an official behavioral guideline. It should be a violation to tell a user “You only have X number of edits, so your opinion doesn’t count” or “No, we aren’t going to give you that user right because we think someone with that user right should have X number of edits”. I agree that edit count is an important tool in determining experience on Wikipedia, and along with other reasons, it can be used in arguments for or against a user. But we shouldn’t allow users to discriminate solely based on the number of edits one has. This has a negative effect and leads to editcountitis. What do you think? MrSwagger21 (talk) 23:21, 25 June 2020 (UTC)

@MrSwagger21: Are you proposing to remove the autoconfirmed and extended autoconfirmed rights? Or is this only about administrator nominations? Which rights specifically are you trying to get but have been disallowed due to edit counts? RudolfRed (talk) 22:15, 26 June 2020 (UTC)
@RudolfRed: No. I’m not really talking about concrete limits that are set that automatically grant a user rights once they reach an edit count. What I’m saying is that things that are manually decided or approved by other Wikipedians, like RfA, pending changes reviewer, new page reviewer, rollbacker, and others, should not be decided solely based on the edit count of a user. We must require that those who decide who gets those permissions must also rely on factors other than edit count in making their decision. And this isn’t really for me or for my benefit, I’m just talking about making this a behavioral guideline in general to improve Wikipedia. MrSwagger21 (talk) 22:35, 26 June 2020 (UTC)
A strong no. The edit count is a minimum requirement, at least generally, if not always. It will be nearly impossible to show anyone is fit for any of these tools if they don't have the minimum edit requirement. SportingFlyer T·C 23:29, 26 June 2020 (UTC)
@SportingFlyer: As I said in my original post, I understand and agree that edit count can be a factor in making the decision to grant permissions. What I was proposing is that we require that it not be the only factor considered (except in obvious cases, like a very new editor). MrSwagger21 (talk) 00:38, 27 June 2020 (UTC)
At AfD, we typically flag users who have not edited outside the topic or have made very few edits. It does not mean their opinion does not count, but often these users do not understand established guidelines or have been canvassed to the discussion. User rights are granted via edit counts for autoconfirmed or extended confirmed only. If someone is asking for an additional privilege, edit counts may actually be an issue if they're very low as being demonstrable of a lack of experience, and users asking for privileges typically have to make some showing that they need them regardless. Not sure this does anything at all except loosen some restrictions. SportingFlyer T·C 01:15, 27 June 2020 (UTC)
For granting extra permissions, the criteria are always more than just edit count. Some of them require an edit count for a certain type of page using non-automated methods - hoping to mean that the user has put some thought into what they do, but there are also other requirements, such as not being blocked or causing lost of problems. Graeme Bartlett (talk) 01:28, 27 June 2020 (UTC)
Agree with the OP. Many Wikipedians see Wikipedia as their own fiefdom. That was not the mission of this project. The barriers to entry into the Wikipedia club are many, with all sorts of gateways and a special language (acronyms). Lightburst (talk) 02:16, 27 June 2020 (UTC)
Yes. The proposed behavioral guideline would be very flexible and adaptive to all situations. The only thing that it would strictly prohibit is obviously and blatantly basing an editor’s merit solely on their edit count (with an exception for very new users and the autoconfirmed/confirmed/extended confirmed rights). To repeat, there would be an exception for edit counts that are very low as being demonstrable of a lack of experience. This is more to protect editors with edit counts in the low-to-upper hundreds and above. And if the criteria is always more than just edit count, then why don’t we codify that with a behavioral guideline? We can’t always trust that Wikipedians will be fair and take other factors into consideration besides edit count. This will set into stone that users will only receive rights based on edit count for autoconfirmed/extended confirmed, and that other Wikipedians won’t carry on this practice to manually-granted user rights. MrSwagger21 (talk) 04:07, 27 June 2020 (UTC)
When do you think this situation would apply? SportingFlyer T·C 04:08, 27 June 2020 (UTC)
Let’s say a user is requesting adminship at RfA. They are an experienced editor with thousands of helpful, constructive contributions and qualified to be an admin. A user says “Well I would support this, but you don’t have X number of edits, which I expect from an admin, so I’m going to oppose.” (I’m aware that some users partially base their approval on edit count, but not fully). Or, a more common and important situation: There is a dispute on a talk page. A fairly new editor gives a valid, reasonable opinion. A more experienced editor with an opposing view responds with something along the lines of “Wow, this is coming from someone with grand total of X edits” and continues disregarding their opinion or maybe even ignores them in the first place. Note that none of these have happened to me personally, I’m just trying to explain how it would be useful. We should not weigh the value of an editor to Wikipedia only based on the number of edits they made. We must have a behavioral guideline to cite whenever a user faces one of these types of responses. Bottom line: There’s too much confusion between what is fair to completely use an edit count for and what is not fair to completely use an edit count for, and not enough in place to protect against needless edit-count favoritism. MrSwagger21 (talk) 07:35, 27 June 2020 (UTC)
Regarding the RfA scenario, I think that's a non-issue. RfA !votes that are purely based on edit count are rare, and consistently get mocked relentlessly when they do occur. Regarding other discussions, I think there's a misconception about what drawing attention to someone's edit count does in practice. An editor calling out someone else as having few edits isn't something that automatically invalidates their opinion; it does call that editor's contributions into scrutiny, and it's ultimately up to everyone else reading the discussion to decide whether this is actually a cause for concern. In cases where the call-out seems totally unwarranted, people will step in and admonish the editor for casting aspersions. In cases where the new editor is clearly a sockpuppet or meatpuppet, calling them out is a service to the encyclopedia. In murky cases where it's not clear, people will generally take note, assess for themselves and then move on with the discussion. All told, I think that the proposed change is largely redundant with WP:CIVIL and our general approach to the casting of aspersions. A change along the lines of what's proposed here would create more opportunities for rules lawyering without improving our ability to address the cases of editcountitis which are actually problematic that can already be properly addressed as breaches of CIVIL. signed, Rosguill talk 18:46, 27 June 2020 (UTC)

Appeals Committee

I'd rather revive the Supreme Court of Wikipedia proposal- Another Wiki User the 2nd (talk) 13:05, 29 June 2020 (UTC)

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

I am thinking of a committee for handling ArbCom appeals.

Who: 9 users, per the following,

Jimbo, permanently. 4 Brueaucrats, selected by vote, for 2 years. 2 CheckUsers\Oversighters, appointed by Jimbo, for 1 year. 2 users with 100,000 edits and 5 years experience, chosen by admin vote, for 6 months.

Chief: Jimbo

Associate Chief: 1 of the bureaucrats, appointed by Jimbo — Preceding unsigned comment added by Another Wiki User the 2nd (talk • contribs) 16:14, June 28, 2020 (UTC)

We already have an elected committee for handling appeals. How would handing it over to a a committee drawn from a tiny group of people, some of whom haven't been active for years, and presided over by someone who has a decent claim to be one of the least trusted people on Wikipedia (if it weren't for his unique position, Jimbo would almost certainly have been sitebanned years ago), be an improvement? ‑ Iridescent 18:09, 28 June 2020 (UTC)
We already have an appeals comitee. It's called the English Wikipedia Arbitration Comittee, AKA the Supreme Court of the English Wikipedia. And why bureaucrat? To be a bureacrat, you don't have to sign an agreement for access to non-public information. {{reply to|Can I Log In}}'s talk page! 19:04, 28 June 2020 (UTC)
An unnecessary level of bureaucracy, considering we already have ArbCom. Not even sure what you mean by appeals either? Unblock requests? Those are handled by admins. CaptainEek Edits Ho Cap'n!⚓ 22:27, 28 June 2020 (UTC)
Also, talk about encouraging experienced editors to try and artificially bump up edit counts! But yeah, we have no fewer than seven active groups already that handle appeals already: mostly individual admins handling on-wiki appeals; UTRS (also individual admins, but offwiki); groups of admins at AE; oversighters for OS blocks; Checkusers for CU blocks; the Community for anything referred to AN (including community bans); and ARBCOM for certain tough cases.
And there is also WP:DRV and WP:REFUND for deletions. Graeme Bartlett (talk) 10:18, 29 June 2020 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

New Usergroup

I'm stupid

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.

I call it Wikipedians-in-residence.

Requirements

5 years and 100,000 edits.

Also, being a bureaucrat automatically gives you this group.

They can edit fully protected pages, can RevDel, (non-bureaucrats from here) semi-protect pages, and can delete Stubs and pages with 1000 or fewer revisions — Preceding unsigned comment added by Another Wiki User the 2nd (talk • contribs)

What do you think?

For one, we already have Wikipedia:Wikipedian in Residence, but it's something else. For the other, see WP:PERENNIAL, particularly the "Deletion" and "Adminship" sections. Ivanvector (Talk/Edits) 17:39, 29 June 2020 (UTC)
Please stop making proposals about how Wikipedia should be run differently and get on with editing some articles. Anyone with the qualifications you describe can apply for adminship and get those rights if the community trusts them. If the community doesn't trust someone then no amount of time served or edits made can counteract that. Phil Bridger (talk) 17:44, 29 June 2020 (UTC)
Yes, User:Another Wiki User the 2nd, you currently seem to have about 12 edits to articlespace, but far more pushing unsuccessful proposals. Johnbod (talk) 21:21, 29 June 2020 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Accessible maths

I'm very nervous of writing this suggestion. Background: I am a professional scientist in the biological/biochemical area. Like many bio-scientists, I use maths, but my maths is weak. Some of Wikipedia's maths articles are accessible, but most are extremely hard work for a general reader; one sometimes gets the feeling that they're written for people who already knew what the article was trying to say. Question: For whom is Wikipedia intended? Should articles be accessible to a casual audience (and if so, how casual?)? What level of prior knowledge do we expect? Is it possible to make an article useful both to professional readers in search of an accurate summary of a difficult topic, and also interesting to an ordinary intelligent member of the public with a general high-school education? Idea for incubation: would there be any interest in setting up a working-group/inviting editors to look at some of the maths articles, and add accessible sections, explaining the basic concepts and relevance in less formal terms? This wouldn't substitute for the "proper" text; it might be a sandwich section between the top paragraph/heading and the "meat" of the article. I would imagine that writing sections like this would appeal to those who excel in teaching maths, rather than necessarily those who specialise in the maths itself (I appreciate probably many of the current editors are academics working in maths who will also be lecturing, but I don't get the impression they're teaching at high-school level). The task would ultimately be huge, but it'd be a good start just to work on some of the most core subjects. I am sorry if this is an inappropriate suggestion; it is intended honestly, based on a feeling that Wikipedia has become a tremendous resource for maths, and it'd be lovely if more readers felt able to benefit from it. (I'm not currently a registered user so I'll just add tildes, but if this catches on, I'll sign up properly!) 62.64.182.133 (talk) 23:09, 29 June 2020 (UTC)

It's not an inappropriate suggestion at all! I'm an accountant with some background in engineering and I also find much of our information on mathematics to be written for an audience already pretty familiar with that particular branch of knowledge. That's somewhat to be expected: Wikipedia is intended to be read by a very general audience, but it's unlikely an article on, say, algebraic combinatorics, could be written to be both accessible to a person with very general high school math and also useful to readers with more knowledge of abstract algebra. I suppose that's the challenge. A good rule of thumb is to summarize such a topic in fairly general terms in the lede while addressing the finer details more for specialists in the body. Another approach is to create generally accessible articles on broad topics like calculus for the "layperson" and more academically complete articles on niche topics like Radon–Nikodym theorem. You might want to pose this suggestion at WikiProject Mathematics where you are more likely to find educators and specialists in these topics. Ivanvector (Talk/Edits) 23:23, 29 June 2020 (UTC)
FYI, for actual discussion, you'll want the project talk page, WT:WPM. –Deacon Vorbis (carbon • videos) 23:31, 29 June 2020 (UTC)
This is a known issue since a long time for mathematics and sciences articles. We even now have a guideline on it at WP:TECHNICAL. If you identify particular articles that need help, you can visit the talk page that Deacon points to. --Izno (talk) 23:33, 29 June 2020 (UTC)

Thank you! WP:TECHNICAL is really useful. Yes, I will have a look at the Project maths talk page and see if I can get a discussion going there, particularly identifying pages that would benefit from being made accessible, and ways in which it can be done without sacrificing the value to the technically aware. I particularly like the idea of using the lede/lead, and if more space is required, adding some sort of background/context section that summarises the concepts on which something is built, why it is of interest, and to whom (this is something that expert writers may easily forget to do; the context is very obvious to them). I will try to feel less bashful about getting involved in maths articles; it's scary, because quite rightly the articles are written by people with vastly more knowledge than me, but I think we non-experts need to be prepared to make concrete suggestions about improvements, and not merely flag our frustration when we don't understand. We need to try to meet the technical authors half-way. 62.64.182.133 (talk) 09:52, 30 June 2020 (UTC)

If it makes you feel any better, I am a post-graduate student of mathematics and also find many of our articles on the subject impenetrable. Phil Bridger (talk) 11:13, 30 June 2020 (UTC)

Wikipedia's handling of user disputes must be overhauled

(Context: originally posted here [1]) I think Wikipedia's handling of sanctions is completely off whack. The current process is unfair and suffers from huge biases and conflicts of interest. This is a major problem for Wikipedia that should be addressed. This way of handling problems is not a fair process and can be easily manipulated. We are discussing here of banning indefinitely an editor that has contributed with the "dirty" work for over 15 years. This is how we want to handle such matters? With no clear voting and goal posts that move every 10 minutes? This is the level of superficiality with which he will be judged?

No wonder the accused lashed out. It must feel as a huge betrayal after all the time volunteered to the project. I only recently discovered this "dark side of Wikipedia". But no wonder Wikipedia's editor count keeps declining. This process is a case study in how not to handle justice. Those problems have been solved by the Roman judicial system over 2500 years ago. Currently Wikipedia is at the "public stoning" level of justice. It's time for Wikipedia to make a big evolutionary step forward here. This is wholly inadeguate.

I propose a discussion should be opened to propose big changes on how disputes are handled.

I would first like to gauge the community's sentiment over this. Is this something only I think is needed given my recent shocking experiences with AN/I?

Example of what I mean here (some quick general ideas off the top of my head): Disputes should be presented in a clear and fixed format. The sanction requested should be clear beforehand. The accused should be allowed to present a defence. Additional comments should be allowed for a short period by other users. Voting should then proceed in an orderly manner with no new information/facts being presented and with a minimum number of uninvolved participants voting. Conflicts of interest should be clearly disclosed. Etc. -- {{u|Gtoffoletto}}  talk 12:42, 25 May 2020 (UTC)

This survey from 2017 is a fairly accurate reflection of the varied community feelings on ANI. – Teratix ₵ 14:35, 25 May 2020 (UTC)
Discussions in Wikipedia are not courts of law. Nobody can fine you or imprison you or sentence you to death. All that can happen is that you can be told not to edit one particular web site, so there is no need for the same level of safeguards as in a law court. Phil Bridger (talk) 14:59, 25 May 2020 (UTC)
And the system doesn't even need to know who you are. Also, please note that ANI is ideally to quickly handle issues. While still not a court system, WP:ARBCOM is a bit closer to one than administrator noticeboards. WP:ARBPS is a good precedent, for instance. Here again, the most dramatic outcome is time loss and a ban from editing a website (usually appealable). —PaleoNeonate – 15:40, 25 May 2020 (UTC)
+1 --qedk (t 愛 c) 06:39, 26 May 2020 (UTC)
@Teratix: Wow that's exactly what I would have liked here that's great. Some key highlights:
  • Only 27% of respondents indicated they were satisfied with the way that AN/I cases are handled.
  • 52.99% have specifically avoided making a report on ANI because they were afraid it would not be handled appropriately.
  • More than six in ten participants reported "sometimes" or "frequently" disagreeing with the outcomes of cases at AN/I.
  • Respondent indicated that "Straightforward" or "Serious vandalism" cane types were the ones AN/I handled best. None of the other categories got an approval from more than 10% of the respondents.
  • "Interpersonal disputes"/"Conflicts with a certain type of editor"/"Complex conflicts"/"Conflicts with long history" have all been indicated as problematic areas
  • Most voted proposals for improvements were " Clerking and moderators (21.82%)"/ "Fairness / Merit-based process" / "More structure in general" / "Separate or ban uninvolved editors / non-admins" / "Punish incivility"
  • "Almost half of respondents said that discussions on AN/I are "almost never" or "rarely" focused and neutral. ."
  • Conclusions: The instructions, form and process is too unstructured to be effective, reporters need the free time to keep responding, experienced users know how to manipulate the process in their favor, and administrators do not seem to have the time to be involved to investigate.
I mean...this report says it all. The numbers are abysmal. It is clear we need to fix this urgently. Was there any follow up from that report? The discussion linked at the bottom is empty (!!!) [2]
I guess legal isn't considered very sexy around here... but I'll post the latin inscription on the courthouse of Milan just outside my window: "Sumus ad iustitiam nati neque opinione / sed natura constitutum est ius" "We are called to justice since birth, and law is based on nature, not on opinion."
Anyone wants to support this initiative? I'll volunteer to propose some kind of initial proposal but I am no expert in Wikipedia's AN/I process (I've just been exposed to it in several forms (reporter/subject/commentator) in the last several months and have been left with a foul taste in my mouth every single time). Maybe some admin with some legal background?
I'll finish with another pompous latin citation to get in the legal mood of things:

"Cedant arma togae, concedant laurea linguae."/"Weapons shall make way to togas, military might shall be replaced by eloquence" Cicero 60 a.C.

-- {{u|Gtoffoletto}}  talk 15:48, 25 May 2020 (UTC)
  • Just a few thoughts (also off the top of my head)...
    1. Disputes should be presented in a clear and fixed format.
      Unless we can think of a format in advance that can cover all possible disputes, that's not possible. Disputes often involve newcomers, and disputants need the flexibility to present their disputes with the minimum of bureaucratic red tape.
    2. The sanction requested should be clear beforehand.
      Obviously not possible, as the sanction (if any) depends on evidence, investigation, judgment.
    3. The accused should be allowed to present a defence.
      The accused already has as much right to take part in the discussion as anybody else.
    4. Additional comments should be allowed for a short period by other users.
      Anybody can comment, but there can't be a fixed minimum period as some disputes require immediate action.
    5. Voting should then proceed in an orderly manner with no new information/facts being presented and with a minimum number of uninvolved participants voting.
      It's not a vote - consensus, not voting, is a core part of Wikipedia's foundation (see WP:NOTAVOTE)
Replacing the current flexible ad-hoc system with a formalized legalistic system, in a volunteer project with no paid or appointed lawyers, advocates, clerks, judge, jury, etc, is simply not realistic. Saying all that, what you suggest is close to how Arbitration Committee cases work, but that's a last-resort thing, which does have appointed arbitrators. But it's a huge timesink, and only works because there are so few cases each year. A similar approach to the dozens of disputes that show up daily at WP:AN, WP:ANI etc is simply not feasible. Boing! said Zebedee (talk) 18:08, 25 May 2020 (UTC)
PS: I think you'd get a better response from the community if you didn't show up with the arrogance of telling us that our established practices must be reformed. Boing! said Zebedee (talk) 18:09, 25 May 2020 (UTC)
  • I think it's no secret that ANI sucks sometimes—see WP:CESSPIT—with that being said, it is not immediately obvious just how it should be reformed. My impression is that there have been multiple attempts in the past to make the noticeboard more structured, but most proposals related to this get complicated by the issues that Boing mentioned above. I think the best description of ANI is that it works pretty well for minor disputes, such as reports of legal threats, gross harassment (of the kind any reasonable person would agree is harassment), and other kinds of issues where a single administrator can look at the report and identify what the best action should be. However, in more protracted issues where there is an established editor or group of editors at the center of the dispute, the community can quickly become closely divided, and it can oftentimes be difficult to identify what the evidence is and what the proper response should be. Note that if you want a more structured dispute resolution system for conduct issues than ANI (where the accused has a section for responding, where there is a place where involved editors can present evidence, and where the final decision is made only by a group of trusted editors who are vetted annually for their judgment), we have one: see Wikipedia:Arbitration/Requests. Mz7 (talk) 18:30, 25 May 2020 (UTC)
@Mz7: You mention there were previous efforts to make the ANI boards more structured. One issue I notice is that some requests generate long comment threads, which may make it difficult to follow and render decisions. Have there been thoughts to add at top 2 summaries, where each party could summarize their arguments, e.g. in 200 words or less. There’d still be a separate, free-form Comment section, and the 2 parties in dispute would be free to revise their summaries, based on comments and other facts, until commenting is closed. This could help somewhat with the ganging up, and working-the-system issues, mentioned by others, since right at top both would have equal opportunity to make their best case. This is also similar to courtroom closing/opening arguments, and in some cases participants could vote just by reading the summaries, thus easing their burden Thhhommmasss (talk) 01:44, 26 May 2020 (UTC)
  • In theory, if you are objective yes, but some people (which I think is a big issue) blatantly take their own view of what is clear harassment/incivility etc and hold different users to different standards and take unreasonable measures/actions in situations which don't warrant it. There needs to be a very clear rules of what is and what is not clearly unacceptable. Games of the world (talk) 21:24, 25 May 2020 (UTC)
    This reminds me that even WP:AN3 is annoying to use because of the structure. Convenient to read, I admit. —PaleoNeonate – 19:03, 25 May 2020 (UTC)
    @Mz7: That seems like a good last level in a judiciary system. However, if 60% of disputes are incorrect then the system will just never work. It means it is more wrong than right. An overwhelming percentage of disputes would need to be escalated to the "final level" and most editors won't do so. You will just turn them away. We need to ensure a lower error/unfair rate is present at the lower levels by treating properly serious cases where the issue is not obvious to all and urgent (e.g. vandalism, sockpuppetry, legal threats, etc. are fine in AN/I at the moment, indefinite bans for complex problems with users with 15 years of editing are not) -- {{u|Gtoffoletto}}  talk 19:08, 25 May 2020 (UTC)
    Gtoffoletto, well hold on now—I do not think that is a fair representation of the facts. I would reject the view that because "more the six in ten participants" in that survey indicated they have, at some point in time, "sometimes or frequently" disagreed with an ANI result implies that "60% of disputes" are handled incorrectly. All discussions that occur on ANI are archived, and I would challenge you to prove more conclusively that ANI is "more wrong than right". Mz7 (talk) 19:17, 25 May 2020 (UTC)
    @Mz7: That percentage was made up (not very clear from the message sorry for the confusion). I was not referring to that statistic directly as it doesn't say that (it just says there is a very low satisfaction rate). It was just an hypothetical example. What I mean is: if a high percentage of cases requires full escalation then the system is broken. The report clearly states that most simple problems are resolved. The complex ones are the ones AN/I is failing with. Only those need to be addressed. -- {{u|Gtoffoletto}}  talk 19:55, 25 May 2020 (UTC)
  • I think the data above proves the system is not working. More than six in ten participants reported "sometimes" or "frequently" disagreeing with the outcomes of cases at AN/I. That's a pretty big red flag right there. The rest of the report is damning. Let's try to think together if there is a solution to this. We can certainly do better than "60%" dissatisfaction rate. The first step here is to admit we have a problem. :-)
Also: this is a complex problem. There is no clear cut and simple solution. It requires a lot of thinking and a lot of work to find a solution. Also, this should not be a solution to "everything" but just the cases where AN/I does not work well (which ones? the survey covers this also). The rest can continue to be handled like today as it clearly works. So no flexibility would be lost.
I've made a quick recap and super preliminary/brainstorm/pre-alpha kind of proposal here in the last hour. It uses the survey as guidance to touch as many main pain points as possible. I've put in it everything I would like to see from a more modern and fair system for complex disputes (like the case above: an indefinite ban against a user with 15 years of experience. That's not something to be handled lightly. We must think: "What if it happened tomorrow to me?". We all care deeply about Wikipedia. Would an AN/I report be enough if you were banned indefinitely?). I tried to ensure the proposal would result in flexibility, efficiency and that it may work even with unpaid voluntary editors.
It might be too ambitious but we can always trim it back. I've gone as far as I think it is feasible here to get the ball rolling, so some changes might be too much all at once.
Here it is: https://wiki.riteme.site/wiki/User:Gtoffoletto/WIKILegal comments encouraged. My experience is limited with Wiki drama thankfully so I'm just going with the info I have seen and experienced first hand.
In particular the comment above regarding WP:NOTAVOTE is important. Almost crucial. Are there any examples of any kind of modern judiciary system that works by consensus? I think it may just not be a proper and fair way of deciding those matters. And the reason why this is failing right now. But this merits more discussion for sure. As you'll see, my proposal separates clearly the discussion from the voting aspect of the judgment. Most trials require that the accuser "makes the case" against the accused. And that he may defend himself. Not that the mass establishes a consensus on what to do with a victim. Otherwise the result is a court of public opinion that may be easily influenced and manipulated by more experienced users (as reported in the survey). -- {{u|Gtoffoletto}}  talk 18:57, 25 May 2020 (UTC)

There will always be interpersonal disputes, of course, because that's what happens in a group. What would go a long way to diffusing them, though, would be better content-dispute resolution. If content-related disagreements could be resolved more effectively, then there would be a lot less incentive and tolerance for poor collaborative behaviour. So far, amongst the portion of the community who likes to discuss these matters in these venues, there is no consensus to move to other forms of content dispute resolution. The price paid is a morass of longstanding, drawn out arguments on content and personal conduct. isaacl (talk) 19:02, 25 May 2020 (UTC)

  • Re: "More than six in ten participants reported "sometimes" or "frequently" disagreeing with the outcomes of cases at AN/I": Considering so many people at AN/ANI are miscreants who end up blocked or otherwise sanctioned, that's hardly surprising, is it? It's a bit like saying that criminals convicted by a court are dissatisfied with the result. Boing! said Zebedee (talk) 19:03, 25 May 2020 (UTC)
    Who said Wiki should be comprised of believers? And believers in what exactly? :-) Joking aside. The report is based on 136 participants. The methodology is posted. But those were not "miscreants" (73.53% had over 5 years of experience on Wiki). I suggest a thorough review of the report. It is very well done. -- {{u|Gtoffoletto}}  talk 19:11, 25 May 2020 (UTC)
    • I have "sometimes" disagreed with the outcome at ANI. That doesn't mean the outcomes from ANI is, on the whole, the wrong outcomes, or outcomes without consensus. If you don't occasionally disagree with the outcome of anything on Wikipedia, whether it's at ANI, RFA, ARBCOM, AFD, RFD, RFC, etc... you have no brain. Headbomb {t · c · p · b} 19:21, 25 May 2020 (UTC)
      +1. Disagreement with the outcome of an incident does not indicate anything about how people (IIRC I actually filled out the survey cited and may very well have put that I disagree with the outcome sometimes but that doesn't mean I think ANI is broken. Galobtter (pingó mió) 23:06, 25 May 2020 (UTC)
  • The title of this thread may be misleading. ANI is not content dispute resolution, which can be done using WP:DR processes. In this case, a topic ban was applied after an ANI report. This user claims that Wikipedia suffers as a result. —PaleoNeonate – 19:43, 25 May 2020 (UTC)
  • I think that ANI could potentially benefit from taking a page out of DRN's book and having a more formal turn-taking process for discussions. Editors chiming in to either adjudicate the case, raise more grievances, or provide a defense for the accused should clearly identify themselves and their role in the conversation, and limits on interaction between disputing parties within the ANI proceeding should be enforced. This delineation of participants would also make it easier for admins to close discussions that they had participated in without risking coming off as too INVOLVED, reducing the overhead for each discussion. DRN has its own problems, but in my experience those mostly stem from not having the actual authority to hand down judgments about content, not due to a failure of editors to comply with the process; editors bringing disputes to DRN tend to shape up their behavior and cooperate, even when they were previously being belligerent. signed, Rosguill talk 19:47, 25 May 2020 (UTC)
  • So, for more historical context: about six years ago, we had an intermediary venue that was more structured than ANI but not quite as formal as ArbCom: Wikipedia:Requests for comment/User conduct. The venue was shut down because it was deemed ineffectual—see the discussion. The system was abolished about when I started getting more active on Wikipedia, so I do not claim to know much about it or why it failed as a process, but if we are thinking about creating an ANI/ArbCom intermediary, it may be helpful to examine why the previous version of that idea failed. Mz7 (talk) 20:08, 25 May 2020 (UTC)
    Very interesting! I've had a look. The process seems too "complex" though. I like the structure and I think it took a lot of steps in the right direction. But this needs to be as straightforward as possible. Report->defence->vote with little exceptions different paths etc. That previous system seemed to suffer a lot from this. My proposal might suffer from the same problems and might need to be "trimmed back" but what do you think? Editor Dispute Resolution -- {{u|Gtoffoletto}}  talk 07:10, 26 May 2020 (UTC)
    The request for comment on user conduct process did not allow for sanctions to be imposed, in an attempt to provide an environment where the user could participate without fear of punishment. Unfortunately, this also meant the user had no reason to engage. Providing constructive feedback is one of the most difficult interpersonal relationship tasks to do, so it was easy for feedback to be taken personally and to feel that the subject's positive characteristics were being ignored. Figuring out the best way to present comments to maximize the chance of their being heeded is hard. isaacl (talk) 21:30, 26 May 2020 (UTC)
  • There have been blessedly few times when I've had to interact with ANI, but with the times I have, I have definitely not been impressed with the way it functions. (using third person since these are generalized points) In one case, the ANI thread just became a more convoluted overflow of an argument editors were having at an article. The lack of any separation between involved and uninvolved parties (as Boing! said Zebedee and Rosguill suggested above) made it look like the issue was being handled when it was not, and the lack of separation between discussion of the content issue and the conduct issue clearly detracted as well; these need to be split. In another particularly egregious case, a filer made a highly misleading report, and an involved admin closed the thread less than two hours later (despite the situation not being an emergency), sanctioning the editor the thread was about. By the time people started to figure out what was going on, the situation was so convoluted that no one new was commenting, and the archiving instinct took hold, causing the initial bad close to unduly stick. Had Boing!'s third point about the right to present a defense been a firm rule for non-emergency cases, that would have massively helped. {{u|Sdkb}} talk 20:12, 25 May 2020 (UTC)

On a related note, I recently posted an RfC on how to improve the RfC process based on negative experiences with the RfC for removing Croatian wiki Admins. Among other issues, it’s been now almost 5 months since most of the comments were completed, yet there’s been zero word from the decisionmakers as to what they’re thinking, or when a decision will be made. Perhaps there are valid reasons for doing it this way, but at least I’d like to see a discussion, since one way to interpret this is as disrespect toward other Wikipedians – i.e. we owe you no information, until we feel like it. I hope I’m very wrong about this last point, but I’d like to learn more as to why things are done this way, as well as see a broader discussion on how to improve things. Otherwise people may just get discouraged and not even bother with the process. Thhhommmasss (talk) 20:32, 25 May 2020 (UTC)

  • My radical ideas, if this is becoming a general ANI reform discussion:
    • Do not discuss content issues at ANI.
    • Do not excuse Editor B's bad behavior because Editor A also behaved badly. Obviously that practice makes Editor B feel free to behave badly if Editor A is behaving badly. The result is far more escalation than we would have if Editor B controlled their behavior, or withdrew and let someone else handle Editor A, or, when appropriate, opened an ANI complaint against Editor A. Ultimately, the current approach encourages fighting, and a lot of fighting is what we have always had.
    • Related to the above, do not address two editors' behavior in the same complaint. If A and B both behaved badly, open two complaints and consider them independently. We would often see A and B filing cross-complaints, and there's nothing wrong with that assuming both would be subject to boomerang sanctions.
    • Abandon "preventative not punitive", which (mostly) deters bad behavior for the duration of the ANI discussion and for a short time thereafter. Punitive is preventative by virtue of its deterrent value, for the sanctioned editor and everybody else as well. Human society has recognized this for many centuries, and I honestly don't get why Wikipedia thinks it can ignore that. Besides, much of ANI action is punitive-not-preventative anyway – we are inconsistent in application of the principle – and for those cases this change would just make us more honest about what we're doing. ―Mandruss ☎ 22:09, 25 May 2020 (UTC)
  • Of course, the chances of real ANI reform closely approach zero, but it's fun to talk about from time to time as a stimulating intellectual exercise. ―Mandruss ☎ 20:55, 25 May 2020 (UTC)
    @Mandruss: I think you raise good points. This "preventative not punitive" WP:NOTPUNISHMENT principle is just an essay or a widely accepted guideline? I don't think it is a good idea at all. We now expect admins to see n the future and read people's minds? The risk of abuse becomes even higher obviously. Doesn't make any sense.
    @Thhhommmasss: Otherwise people may just get discouraged and not even bother with the process. I totally agree. This is the major issue here that some editors seem to underestimate. Unfair processes have the immediate effect of discouraging editors and of pushing them away from the project. Why should one waste his time with voluntary work if he is then treated unfairly and with substantial bias? It is not enough to have appeals possible. Not all will bother with an appeal. This is voluntary work and we should strive for fairness and include appeals only as a last resort. Fairness should be the crucial element we guarantee in all user disputes. -- {{u|Gtoffoletto}}  talk 07:26, 29 May 2020 (UTC)

The other issue with ANI is it seems to be a ganging up process with users and admins (I know that there are good ones of both users and admins but you know....) trying to claim that things are not controversial or are urgent particularly around conduct. Unless someone is making off wiki threats for example or legal threats. Nothing else should be hurried nor a quick close either as one party will only show what another does without showing their provocation. (I agree with Mandruss it takes two to tango and very rarely is a filer in a conduct case innocent, yet they escape and carry on with their behaviour) Therefore all admins and users must be objective and not use what someone said to me "they've been on wiki longer than you therefore they can say what they like and you're clearly the issue." And when presented with clear COI allegations, "I don't think they said anything rude". The biggest problem with ANI apart from that attitude, is the mob mentality. Mean we all know the one that is on board that is being referred to, probably within about 10 edits of it being filed we had gone to a site ban vote with no objectivity or view to want to listen to the accused. So I have to ask what is the point of ANI if there is no reasonable objectivity, no listening to people or wanting to work it out. Just because it ends up there doesn't mean that there needs to be a block. More experienced editors answer this. What percentage of stuff that you have seen on the board ended up with a block that had no discussion with the accused (kind of there fault/maybe scared of going there), or the accused dismissed if they posted and yet a bit more objectivity/communication did not warrant a block being handed out? Games of the world (talk) 21:12, 25 May 2020 (UTC)

@Yair rand: Interesting! Could be a solution to conflicts of interest and other similar problems... -- {{u|Gtoffoletto}}  talk 07:04, 26 May 2020 (UTC)
The logic behind this appears to be:
  • something must be done to improve ANI;
  • this is something;
therefore
  • this must be done.
Even if we accept the first premise as true, which is not proven by a survey of self-selecting participants, this is bad logic. Phil Bridger (talk) 08:11, 26 May 2020 (UTC)
  • This seems to be an over-dramatic reaction to your block and topic ban. It would be more worth your time to focus on resolving those issues instead of trying to blame the process behind them. Nihlus 13:22, 26 May 2020 (UTC)
  • While I agree that we could and should handle some internal disputes better than we do; You undermine your argument with "But no wonder Wikipedia's editor count keeps declining." Firstly because it is so easily rebutted, editing levels are consistently and significantly higher now than during the 2013/2014 minima and the biggest thing that limits editing in recent years is our mobile interface and the difficulty of editing Wikipedia on a smartphone. More importantly, the past wasn't some golden age of harmony that we should aspire to return to. There are some real problems in how we run this site, but most of those problems have roots that go back more than a decade, in some cases to the era of exponential growth that was the first third of Wikipedia's era, and during which the first fifth of the edits to Wikipedia took place. In the last decade some things have actually improved, getting rid of user RFC's for starters. As for AN/I, and administrators not having the time to investigate, we have known for years that our number of admins is falling and that we need to persuade more candidates to run at RFA. ϢereSpielChequers 17:09, 26 May 2020 (UTC)
    @WereSpielChequers: Not really the topic here but: [3] Compare that to the number of people with access to the internet. I think poor handling of user disputes might be one of the reasons we are turning away old and new editors. The discussion linked at the beginning of this thread was about to ban indefinitely an editor with 15 years of editing under his belt. Obviously this is just a hunch and is unsupported by data. Still: a problem worth fixing I think. I've tried moving in that direction with the proposal below if you want to have a look. -- {{u|Gtoffoletto}}  talk 18:40, 26 May 2020 (UTC)
    Those show stasis or a slight increase since 2014, I'm wary of those stats as at times they have only looked at live edits in mainspace (missing things such as draftspace and deleted), but still they don't show a decline between 2014 and now. I'd agree that if all things were equal you'd expect our number of editors to be growing in line with our readership or the population of English speakers on the internet, and clearly it isn't. But all things are not equal, much of the growth, along with the young, is of smartphone users who as I have said can't edit, whilst the post 2007 change to requiring inline citation has made Wikipedia editing more academically demanding than it once was. As for the current proposal to ban a longstanding editor, it isn't great, but I have seen far worse in the past, particularly in the era of Requests For Comment on Users. ϢereSpielChequers 20:20, 26 May 2020 (UTC)

Proposal to get the ball running

I've tried to sketch out a couple of ideas here: Editor Dispute Resolution Key points:

  • this is ONLY for behavioural editor disputes. Not content
  • this is only for complex problems that AN/I doesn't currently handle well. Everything else (egregious vandalism, urgent threats etc.) will remain on AN/I as it clearly works well in those cases.
  • this is super preliminary just to get the ball moving. I've included some radical ideas just to stimulate discussion. We can and should trim is back as much as possible to keep it as simple as possible.
  • it is based on the discussion above + feedback form the 2017 AN/I survey [4] + precedent failure of the RfC/U system [5]

Thoughts? -- {{u|Gtoffoletto}}  talk 07:32, 26 May 2020 (UTC)

  • My first thoughts are to oppose something with so much bureaucratic palaver and legalistic detail, as such things tend to be unworkable in practice. AN and ANI certainly have their problems, but they're the least bad approaches we've managed so far, and this proposed new approach is not less bad. Boing! said Zebedee (talk) 10:12, 26 May 2020 (UTC)
    @Boing! said Zebedee: I understand the concern. I think reducing the overhead is the most crucial design aspect here. Some structure is needed but it must be light and effective to actually reduce the overall loss of time. In my proposal the structure would be mostly automated/fixed so that no manual intervention is needed at all and the process proceeds with little overhead. A clear example of a current failure in the system that generates a huge time sink for all due to poor processes: look at [6]. How long is that discussion? There is no end in sight. How ineffective and what a huge time sink by dozens of editors. Following at this point is basically impossible. How will the matter be decided in the end? Could you try to point out what is bad in the proposal so we may work on it with specific critiques? We are not here to vote for/against a proposal but to try to formulate a proposal so constructive criticism is needed to move on the process. Thanks -- {{u|Gtoffoletto}}  talk 10:27, 26 May 2020 (UTC)
    I mean no offence and you are clearly well motivated here. But I think your enthusiasm is naive, and I don't think any proposed structured approach has any chance of success. I've just seen so many people trying to propose improvements in the past, and so many structured procedural practices grinding to a halt and ending up abandoned. I'd hate to see you wasting a lot of your time here (and others wasting theirs), and that's all my comments are really based on. Sorry to be so negative, but I'm out. Boing! said Zebedee (talk) 12:15, 26 May 2020 (UTC)
    No problem. It's a long shot but I think it is a sufficiently big problem here that it requires fixing. As I've said in my user page: I've lost faith in the whole project after my last experience on AN/I. I think this needs to be fixed or the project is in trouble so all my Wiki activity will be on this issue. I think we can for sure do better than the current abysmal system. The bar is really low so with some work we can improve it for sure. P.s. I work in legal tech in the real world so it's a fun little side project -- {{u|Gtoffoletto}}  talk 15:05, 26 May 2020 (UTC)
  • Not sure what problem exactly is being targetted here. Sure, ANI can be clunky, hostile and ineffective at times, but more often than not its outcomes are approximately right, especially for clear-cut cases. But we are being told "The current process is unfair and suffers from huge biases and conflicts of interest." Is there any evidence of these "huge biases and conflicts of interest" affecting outcomes. That would imply a problem with the admin corps, rather than ANI specifically. Alexbrn (talk) 16:49, 26 May 2020 (UTC)
    @Alexbrn: See the sections of the proposal labelled: "The problem" and "Scope" for the answers Editor Dispute Resolution -- {{u|Gtoffoletto}}  talk 18:31, 26 May 2020 (UTC)
    I see no evidence of "huge biases and conflicts of interest" there. Alexbrn (talk) 18:39, 26 May 2020 (UTC)
    It's indeed more a common accusation... —PaleoNeonate – 21:37, 26 May 2020 (UTC)
    See for example the answer to "If you did not select "no" above, why did you think those incidents would not be handled appropriately?" in the 2017 survey. Of course that's the perception. It may not reflect reality. -- {{u|Gtoffoletto}}  talk 22:35, 26 May 2020 (UTC)
    So when you yourself asserted "The current process is unfair and suffers from huge biases and conflicts of interest" before the survey was even introduced, that's just your view? Based on what? Ironically, I think the "conflict of interest" and "bias" issue would apply more to miscreants who had been sanctioned at ANI trying to form a disinterested view of ANI. Although (as I said) ANI is from from perfect, mostly its outcomes are roughly right. Alexbrn (talk) 05:09, 27 May 2020 (UTC)
    @Alexbrn: Absolutely. I think (for complex cases as stated in the scope section of my proposal) the processes at AN/I are the epitome of unfairness and bias. As I have stated, they do not follow any of the basic principles of fairness that characterise legal systems since the beginning of law and therefore they are intrinsically and inevitably unfair and subject to manipulation. AN/I could be studied as a very clear example of many of the problems that legal systems have solved thousands of years ago. It can be compared to stoning/court of public opinion in terms of legal process. The fact you say that "mostly its outcomes are roughly right" is not much of an endorsement. As the survey proves: the vast majority of editors thinks that AN/I is very dissatisfactory. We can do much much better. -- {{u|Gtoffoletto}}  talk 07:30, 27 May 2020 (UTC)
    WP:NOTBURO applies in spades. We are volunteers and time for dealing with (mostly obvious) problems is limited. For complex cases there is arbcom (which is "structured") and for users who feel hard done by at ANI there are appeals processes. The survey just shows that moaners are gonna moan. Alexbrn (talk) 07:37, 27 May 2020 (UTC)
    WP:NOTBURO is being discussed in the proposal talk page and has been included in the proposal. It is the reason the proposal includes vote by peers and not by admins/judges etc. At the moment AN/I is a huge time sink for the volunteers because it has no structure. This proposal is to reduce time waste not to increase it. Also: I'm sorry but I don't get the impression you have read the survey. We each reach this topic with our own bias obviously but the data in the survey cannot be dismissed. It is unequivocal. The problem is obvious given that data. We are discussing potential solutions here. -- {{u|Gtoffoletto}}  talk 07:57, 27 May 2020 (UTC)
  • I think I agree with the pessimistic views above: the proposal is too legalistic and bureaucratic to have much of a hope for adoption. I think that proposing minor reforms that tamp down on key problematic behaviors at ANI would be more fruitful (to my mind, back-and-forth accusations between the complainant and accused and other editors jumping into the discussion without a clear delineation of who is actually acting as a neutral moderator stand out as the most pressing), although I'm not terribly optimistic about the ability for those proposals to overcome the inertia of the status quo either. signed, Rosguill talk 23:10, 26 May 2020 (UTC)
    @Rosguill: I think we should try to trim down this proposal and certainly try to think of the simplest form of system that achieves the design goals. At the moment this proposal isn't very different in terms of complexity to WP:DRN. If that works why not something like this? We are discussing also in the proposal talk page if interested. -- {{u|Gtoffoletto}}  talk 23:49, 26 May 2020 (UTC)

En:Wiki does a bad job on these things so WMF wants to step in and do an even worse job. There one way to 90% fix all of this and also solve fix the RFA and lack of admin process. Create a subset of admins that meet a meet a very stringent set of criteria for expertise, thoroughness, personality, self-control, kindness coupled with toughness, . (In my mind I call them Yodas's :-)) and they become the cadre for handling for the tougher discipline cases and a place of recourse for admin mis-handlings or inaction without the rare event of an arbcom case. Including handling problems with Admins, which rarely happens now. Coupled with adding an outline for (basic) RFA discusions, this will also fix basic RFA because basic RFA will really be "no big deal". North8000 (talk) 15:25, 28 May 2020 (UTC)

"Create a subset of admins that meet a very stringent set of criteria for expertise, thoroughness, personality, self-control, kindness coupled with toughness": The trouble with that is, I just wouldn't have time to do everything single-handedly :-) Boing! said Zebedee (talk) 15:29, 28 May 2020 (UTC)
@North8000: I disagree. The solution is to diffuse power not to concentrate it in the hands of a few bureaucrats. That could turn out to be very dangerous if the Yodas turn to "the dark side" :-) That's why my proposal above is based on judgement by peers (normal users, admins, anyone) but within a fixed process with "clerks" guiding the process and maintaining order (but not deciding). -- {{u|Gtoffoletto}}  talk 17:58, 28 May 2020 (UTC)
Sound like a replica of arbcom; difficult problems go there already and have a structured process policed by clerks. Run-of-the-mill problems are adequately dealt with at ANI. Anybody dissatisfied can appeal (even to arbcom). Alexbrn (talk) 18:16, 28 May 2020 (UTC)
@Alexbrn: not at all. Arbcom is the "final level" of appeal. It is a resource expensive and complex process that should not handle most user disputes but only disputes that have gone through the "normal" channels. Most users will never reach it but will abandon the project well before. Remember AN/I handles many different users including new ones with no experience and with no time for lengthy "battles" especially in the face of a system that is perceived as unfair. If you "get it wrong" you might be silencing a user forever and shutting him out of Wikipedia. The survey discussed above and linked in the proposal shows that there is significant dissatisfaction with the way the "normal" AN/I process works for complex matters and many concerns over it's fairness and bias. AN/I basically only works for straightforward cases (e.g. vandalism). This proposal would introduce a way of handling complex cases in a way that creates less time waste for all and results in a more fair process. Arbcom would remain as a final safeguard (a "supreme court" if you will). -- {{u|Gtoffoletto}}  talk 19:35, 28 May 2020 (UTC)
Even "indefinite" isn't forever on Wikipedia, unless the user really never returns. Topic bans are also appealable. If an obvious error was made, usually it'll get noticed. In the case of a topic ban, it's the user's responsibility to demonstrate that they're ready for another chance to edit the topic. For obvious vandalism, WP:AIV is the proper venue. —PaleoNeonate – 22:00, 28 May 2020 (UTC)
Appeals are not the solution. My argument is that most editors will never appeal. They will abandon the project. If you are treated unfairly during the first process why should they expect a different treatment in an appeal? They will just consider it an additional waste of time. We are talking about volunteers here. The most probable result will be that you have lost an editor. How many AN/I processes end with the accused "rage quitting in disgust"? In my experience (I reacted in that way myself) a significant amount. The abysmal levels of satisfaction reported by the AN/I survey and the discussion above reveal most people feel that way. The most perseverant editors might "survive". But most users will just give up altogether. And every editor lost in my mind is a grave loss for the entire project and an existential problem for Wiki. In 10 years what are the chances that someone makes a mistake or just gets dragged somehow on AN/I? We are loosing editors due to inadequate processes. The result may not even change (the editors might still receive the same punishment after this process). But the perception will be of order and fairness instead of chaos and arbitrary decisions. Once again: appeals are not the solution here, we need to "get it right" at the first try and ensure people are treated fairly and that they perceive that the system is fair and just. -- {{u|Gtoffoletto}}  talk 07:39, 29 May 2020 (UTC)
Editors generally aren't treated unfairly, but plenty of miscreants protest about how their treatment is "unfair". I've seen some terrible toxic editors protesting their innocence at ANI right up to the point they were banned/blocked. What is (or is not) "fair" on Wikipedia is driven by consensus, so what happens at ANI is ipso facto "fair". As Alexander Pope wrote, "whatever is, is right". Appeals are a way to widen the consensus so in a consensus-driven system are pretty much the only possible solution. Alexbrn (talk) 07:50, 29 May 2020 (UTC)
Right. However, the consensus is that AN/I is gravely dissatisfactory (Average satisfaction 2.6/5. 25% of editors rate AN/I 1/5. Compard to only 27% that rate 4 or 5 combined). And most editors disagree with the outcomes it produces (Users disagree: Never (6.62%) Rarely (29.41%) Sometimes (46.32%) Frequently (16.18%)).source. We should really move on form the discussion of "nothing to see here" to "how do we fix this" -- {{u|Gtoffoletto}}  talk 08:22, 29 May 2020 (UTC)
the consensus is that AN/I is gravely dissatisfactory ← no, a self-selecting group of respondents to a small survey (all of whom, who knows, might be sanctioned miscreants) don't rate ANI. As pretty much everyone has said responding to this, ANI is imperfect but generally works okay. Alexbrn (talk) 09:00, 29 May 2020 (UTC)
Indeed. That survey does not constitute a Wikipedia community consensus. Boing! said Zebedee (talk) 09:04, 29 May 2020 (UTC)
(edit conflict) Your figures are't demonstrating consensus is that AN/I is gravely dissatisfactory, they're demonstrating that "sometimes people disagree with the result of discussions", which is exactly as it should be. If everyone agrees on an issue, there's no dispute to resolve; as long as there's a dispute, then somebody is by definition going to be dissatisfied with the outcome. Even if every dispute were resolved by a 90% supermajority in favour of a given outcome, that still leaves 10% of participants unhappy; statistically, someone participating in ten such 90%-supermajority discussions would have a 68% likelihood of being in the 10% on at least one occasion. If people regularly disagree with the outcome of a process—whether that process be a Wikipedia debate, a court case, a refereeing decision at a football game or a Presidential election—then it's a sign that the process is working. I'm sorry to sound negative, but all this thread looks like to me is a very extended riff upon "everyone else disagrees with me so everybody else must be wrong". ‑ Iridescent 09:08, 29 May 2020 (UTC)
Thinking about that survey a little more (and generalising wildly)... ANI reports concern alleged bad behaviour. A lot of those are unambiguous and the offender is sanctioned - and the offender is almost certain to disagree with the outcome. Often it's a behavioural dispute between two editors, and whichever one is sanctioned or warned is going to disagree with the outcome. And judgment is often against both parties, meaning they'll both disagree with the outcome. The very nature of a complaints process like ANI means there's likely to be a majority who disagree with its outcomes. That doesn't mean it's wrong. Boing! said Zebedee (talk) 09:25, 29 May 2020 (UTC)
My argument is that most editors will never appeal. They will abandon the project. They may, if they only wanted to do the activity for which they were sanctioned. Should Wikipedia fix that for them, or oblige them to edit (WP:OBLIGATION)? Hmm I'm not sure it was mentioned before so perhaps also relevant would be WP:STANDARDOFFER. —PaleoNeonate – 17:57, 29 May 2020 (UTC)

Gtoffoletto, I'm addressing this to you but it's a general comment. I like some of your proposal, but in general I find it far too legalistic. It implies that Wikipedia is run on legal principles (which in the real world vary enormously from place to place), but the fact is that Wikipedia, in its essence, was never meant to have any rules at all. I would love to see the end of ANI, because whenever I go there and try to deal with an issue fairly, I end up with flak like this, and people complaining from both sides of the same dispute, like this, this and this, because they think I should have favoured their particular point of view. It's upsetting for the person who's trying to see both sides of the argument. Unfortunately, the more structured the process gets, the more complicated and difficult it is to use, and contributors don't want to go there. Deb (talk) 09:12, 29 May 2020 (UTC)

@Deb: I see your point and you raise some of the issues that have pushed me to propose this system. When you say Wiki "was never meant to have any rules at all" that's why this proposal is for "trial by peers". The structure is just to give everybody the same information and a clear, fixed decision "should user X be sanctioned with Y? Here is the evidence against him and his defence. You decide." so that discussion doesn't become messy, unfocused and useless. The consensus of the peers will then decide if the user deserves that sanction or not. He will not be judged based on specific fixed rules (WP:NOTBUREAUCRACY applies). The editor's actions will be judged by his peers that will decide if the "accuser" has brought forth a convincing case and if the accused's defence is not sufficient to exonerate him.
To avoid complication I'm proposing the simplest system I can think of: one user writes the complaint and proposes a sanction, one user can defend himself. Some witnesses can (optionally) be called to leave a comment. Then the case is "locked" and anybody can vote YES or NO. Quick, simple, fair. A minimum of structure is there just to keep it ordered and focused.
Extras: I'm proposing some "clerks" to keep everything going smoothly but they are optional. And temporary edit bans while voting is in process for both accused and accuser to make sure nobody abuses the system and the process is taken seriously (also optional). -- {{u|Gtoffoletto}}  talk 17:13, 29 May 2020 (UTC)
  • @Gtoffoletto:, to give a fair few more specific thoughts here, though I agree entirely with the "too-detailed/legalistic" comments. Your evidence setup seems odd - have a read of some of the more detailed ANI cases. You will find any number of instances where a huge amount of evidence turned up from later participants. Would you have us not include it? That evidence has led to many who would probably have just been warned being IBANNed or Indeffed. It has also led to likely indef cases avoiding that fate. You also say that a specific sanction must be proposed (and either that, or a not guilty, verdict occurring). But as a case can't be retried, that means participants are stuck with accepting the accuser's suggestion or acquitting. That easily risks leading to both over and under-punishment. I might acquit someone I felt warranted a narrow TBAN if an indef was all that was on the table. It also gives a major plus to "first-mover" advantage.
Your "optional" edit ban makes no sense. The thing taking most of the time is not the accuser or, in almost all cases, the accused's having enough time to be on wiki, but not enough to reply to a pending case. Or if it's to minimise frivolous case requests, those of us who think we might add more to Wikipedia lose any ability to raise difficult cases. You literally are forcing victims to choose between seeking justice and receiving the equivalent of, say, a 2-week block, or continuing to edit, potentially with ongoing disruption. Are those active in the sphere only able to have one case they started open at a time? Cases are already not decided by bureaucrats (nor are real cases, for that matter). Nor have you really demonstrated that the aspects that make long ANIs so difficult are avoided here - were people saying they were having difficulty pulling out the diffs from the general discussion? Were they saying there was too much discussion? Logically either the discussion should be the same, just in the evidence discussion area, or it shrinks, in which case how do you explain that some degree of thinking has been removed? There is only one absolute area where voting does not have to be justified - voting for Stewards/Arbs. But you unilaterally propose adding another, with anyone able to case a vote, with no reasoning provided - how do you intend to prove they've read anything at all on the case? Or actually work to demonstrate a reasoned consensus?
While I commend an attempt to improve ANI, if you are going to use a new method you need to specifically demonstrate how it avoids listed issues of ANI and how no single new procedure adds any new problems. Nosebagbear (talk) 14:20, 2 June 2020 (UTC)
@Nosebagbear: Great points thanks for the input.
  • Your evidence setup seems odd - have a read of some of the more detailed ANI cases. You will find any number of instances where a huge amount of evidence turned up from later participants. Would you have us not include it? to me the actual process is too chaotic and ineffective (the survey supports this feeling with points such as "Use of structured reports (e.g. form-based submission) (59.06%)" being the most supported improvement to AN/I). My "alternative" to random open discussion is to have a structured report for the accuser, include witnesses (optional - MAX 5?) for each side, and allow a chance for the accused to defend himself. Witnesses should generally be users that had a direct involvement in the dispute and that may be aware of additional information. It is useless to have any user review what may be a very complex dispute from 0. Involved users know the case better and can provide that evidence more efficiently (on a voluntary basis).
  • You also say that a specific sanction must be proposed (and either that, or a not guilty, verdict occurring). But as a case can't be retried, that means participants are stuck with accepting the accuser's suggestion or acquitting. That easily risks leading to both over and under-punishment. this one is tricky but a fair point. Possible solutions/improvements: 1. voters may express a yes/no vote + a different sanction (no reasoning, just the sanction). That way if consensus emerges for a lighter or stricter sentence it will be applied. 2. any kind of vote is allowed but they are hidden and visible only to the "clerk" (more complex than the first solution though). What do you think?
  • Your "optional" edit ban makes no sense. this is one of the most "exotic" options. My point is to minimise frivolous case requests (like you state) and to ensure this is a "last resort" for editors. This process should not substitute attempts at resolving conflict through other means. It is for sure a harsh solution. But the bilateral ban is exactly to avoid "first mover advantage". The accused is allowed to "counter-sue" and there is no limit to the number of cases (however they must be complete with evidence and accepted). Do you still feel this introduces more problems than it solves? An option in line with the ones above would be to allow voters to vote for "boomerang" and not just yes/no to avoid the proliferation of counter suing. The defendant may even request it in his defence.
  • Logically either the discussion should be the same, just in the evidence discussion area, or it shrinks, in which case how do you explain that some degree of thinking has been removed? this is a last resort. Discussion should be before not during this case. The limits on discussion are to ensure fairness, minimise manipulation and maximise efficiency.
  • how do you intend to prove they've read anything at all on the case? Or actually work to demonstrate a reasoned consensus? If we assume good faith I don't see why they shouldn't. The strength will be in numbers. Some may not review the case accurately. But the majority will I think.
Demonstrate how it avoids listed issues of ANI and how no single new procedure adds any new problems I agree. Let's talk about it and improve it together! Thanks for the great feedback. -- {{u|Gtoffoletto}}  talk 14:50, 2 June 2020 (UTC)
It's a humorous essay, but you also mentioned it, WP:BOOMERANG can occur when filing cases that are considered frivolous or in bad faith (for frivolous cases, it can also just result in no response/action, it depends). So in a way this already implies the equivalent of "counter-sue" in the current process, allowing the accused to reply and provide evidence as diffs or links to previous discussions. As for "last-resort", that would again more be WP:ARBCOM, presently... —PaleoNeonate – 15:38, 3 June 2020 (UTC)

Wikimedia Foundation Board announement

Looks like the the board of trustees has acknowledged this problem and has proposed to: Work with community functionaries to create and refine a retroactive review process for cases brought by involved parties, excluding those cases which pose legal or other severe risks; [7] this is exactly what I am proposing here. This is very good news in my mind. Does anybody know how that process will work? Where will that discussion be held? -- {{u|Gtoffoletto}}  talk 08:18, 28 May 2020 (UTC)

Based on precedent, what will happen is that users deemed beyond the pale will be sanctioned from on high by fiat, and the community will be excluded from the process. This is not about ANI. Alexbrn (talk) 12:56, 28 May 2020 (UTC)
Yeah, this is awful and something the community should work towards rejecting. The Board has repeatedly shown that they are incapable of understanding local projects and how they operate. Nihlus 13:35, 28 May 2020 (UTC)
The fear here is that they will attempt to step in and supersede the community? I think this is even more of an incentive to work on fixing those problems ourselves. -- {{u|Gtoffoletto}}  talk 17:55, 28 May 2020 (UTC)

V2 Proposal Summary

With the input of some editors we have continued working on this and now have a Editor Dispute Resolution V2 proposal with the following summary:

A fair system to allow any user to report a grievance towards another user with supporting evidence and to propose/request a remedy against that user (§ 1. Report with evidence and sanction request). The report is then reviewed, accepted only if complete (§ 2. Request acceptance) and published with the accused and the accuser both temporarily blocked from editing (§ 3. Request published and temporary block). The accused will be given the right to defend himself (§ 4. Defence). The case is then "locked" and other editors will decide with a direct and clear vote if the accuser's case justifies the sanction proposed (§ 5. Judgement by peers). The case is then closed with an appeal possible through the same process or WP:ARBCOM (§ 6. Closure and appeal).

Additional comments here or on the proposal talk page are appreciated. -- {{u|Gtoffoletto}}  talk 14:21, 2 June 2020 (UTC)

  • Personally, I don't think any element of your proposed system is a good idea. Broadly, I agree with all editors above who state this proposed system is too legalistic and therefore has no chance of being accepted by the community. Requiring the initial editor to state the requested sanction at the same time they initiate the process is problematic because crafting the proper sanction often requires much thought and discussion from uninvolved editors, not just the editor bringing a complaint. Additionally, newcomers to Wikipedia will not be familiar with how sanctions work, so many elements of your proposal will also introduce an unacceptable level of technical overhead (see also WP:CREEP).
    Requiring both the "accuser" and the "accused" to be placed under blocks is the most alarming part of your proposal, as it stands in stark contrast with how blocks are normally used on Wikipedia. Why must an editor bringing a conduct dispute be forced to spend their entire energy on Wikipedia litigating the dispute? We do not require editors involved in conduct disputes to stop working on their articles, and I see no reason to. I suspect that if this process is enacted, it will never be used because no one wants to be blocked from editing for just bringing a complaint against another editor.
    The distinction between "witnesses" and "judges" is also problematic because, unlike in the real world, on Wikipedia the entire record of facts is available unambiguously and publicly: just click the "View history" button on any page. For this reason, any uninvolved editor can simply look into the history of a dispute and become a "witness" themselves—and through this process they may gain a sufficient understanding of the situation from the outside that they become capable of mediating the dispute, i.e. becoming a "judge".
    As far as ANI reform goes, I think this is the wrong way to go about it. The Wikipedia community is generally conservative about its processes, so we will almost never switch to a completely untested, radically different process with just one proposal. Instead, reform takes place over incremental proposals: e.g. proposing to add slightly more structure to ANI reports, proposing to add slightly more structure to ANI admin discussion. Baby steps first, essentially. Mz7 (talk) 19:38, 3 June 2020 (UTC)
@Mz7: thanks for the feedback. Those problems you mention relate to some of the more "exotic"/"extreme" parts of the proposal and other editors have expressed similar concerns. We are discussing some lighter alternatives in the proposal talk page to solve some of the issues you pointed out (e.g. sanctions determined by the community, boomerang effect instead of temporary blocks etc.). I agree we should stick to a more incremental solution initially. The simplest system that may solve the underlying issues without anything extra. You are welcome to participate and I will post a V3 when we get there! -- {{u|Gtoffoletto}}  talk 10:03, 22 June 2020 (UTC)
Retrieved from "https://wiki.riteme.site/w/index.php?title=Wikipedia:Village_pump_(idea_lab)/Archive_31&oldid=1110547247"