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.
I recently came across List of people named David, which has over 2000 people (including disambiguation pages) linked. It seems to me that this might be easier created and maintained using Wikidata. Well, is it possible with Wikidata now, or do we need to wait for Abstract Wikipedia / Wikifunctions to be ready to do so? If it is possible, how concerning are the Wikidata accuracy issues for a list like this; references aren't really necessary to prove that the articles named "David so-and-so" are about people named David. power~enwiki (π, ν) 22:54, 22 December 2020 (UTC)
Generating a page can be done today out of mainspace using ListeriaBot, but there is at least one consensus on the books specifically banning the practice of automatic upkeep. --Izno (talk) 23:33, 22 December 2020 (UTC)
Regarding the specific example, why do we need a page for List of people named David at all? It seems the only purpose it'd serve would be as a navigational aid, but no one is actually going to use it for that. Looking at WP:LISTN, people who share nothing but the same first name aren't really discussed as a group. There are 26 pages in Category:Lists of people by given name, and I'd be interested to see what'd happen if they got AfDed as a group. {{u|Sdkb}}talk13:33, 23 December 2020 (UTC)
Regarding the more general point, yes, absolutely. I was recently wondering about building lists off of a combination of categories and Wikidata, but if the category system will eventually get migrated to Wikidata, as I've seen Rhododendrites predict, then it's better to just go directly there. There's a lot of editor effort wasted doing things that bots are perfectly capable of—the problem is that it's easier to get 10,000 people to spend a minute each to list a page they care about (=150+ hours) than it is to find someone with the requisite technical skill willing to spend a few hours to set up a system to automate everything. {{u|Sdkb}}talk13:33, 23 December 2020 (UTC)
This might be a bit if a stretch or currently already underway, but...
What if there was a way you could mix the camera on your phone (like how live cameras translation of another language operates) with wikipedia's vast database of information to help people identify things of the unknown should they stumble across it and think "I wonder what that is"?
Basically it would be like the Pokedex from pokemon which is used to identify a pokemon unknown to that person but would be of use with things on earth here today, plants, animals, items, the works! Everything!
If a user stumbled across something completely original with no information then they could somehow be involved on the information that would pop up,
I.E discovered by John Doe 11/11/2020 and it would bring up or update areas where they were found,
The camera would also have the geotagging function should users want to share the location of their findings,
Anything unknown would automatically send location information to the wiki/app who could send out someone capable of investigating/studying the unknown.
A reward of some kind for original discoveries would see increased use of the app and encourage others to share the app to explore and find other things.
The app itself would cost roughly $20 to download which would really be no huge cost considering the ease of identifying things you aren't familiar with, unless it's a new discovery which would put them first inline for the information discovered after examination and analysis.
Chemicals and probably a few other things would be tricky to identify considering it would rely on the camera talking to wiki to recognize what the user is seeing but 3d objects and most other things with distinct colors/patterns/shapes should work well,
With roughly 7 billion people on the planet and an ad on the site encouraging people to download the new app i reckon there would be at least 1 billion users in the first 5 years based on word of mouth and the constant daily searching from users who would see the ad encouraging them to download it.
What reason would there be for someone to pay for this, when anyone can just use Google Lens for free, which runs on servers that are orders of magnitude faster than anything we could hope to achieve, and which has the overwhelming advantage of being operated by a company that already has every image on the internet archived, tagged and sorted, and where anyone who for whatever reason objects to Google can use the (inferior, but still better than anything we could do) CamFind for free? ‑ Iridescent22:15, 29 December 2020 (UTC)
Aside from this being just generally redundant, 7 billion people doesn't mean 7 billion smart phone users, let alone that many people willing to drop $20 on any app no matter how good. --Paul ❬talk❭ 21:36, 30 December 2020 (UTC)
So dozens of articles are listed daily on the Portal:Current events. I am thinking about a proposal to make some format, similar to how the daily page view is tracked, to show the dates (or number of times) an article was listed on the Current Event Portal. Not every article would have it, only if people add the “track” will it display the information.
One problem I am thinking of with this is all the COVID articles. If this was proposed, that would be an entirely separate discussion of how to handle all of that messy formalities.
Does anyone else think this could be a good idea to propose? Please feel free to drop any insight (positive or negative) you have about this idea. Thank you (Lead coordinator of WikiProject of Current Events) Elijahandskip (talk) 17:58, 5 January 2021 (UTC)
Making disclaimers more prominent
Is there any way that the Disclaimers, which are now at the very bottom in small font, can be made more prominent, particularly on the main page? I think this is perhaps the most important information for readers to see about Wikipedia, particularly the Content disclaimer. Many readers and drive-by editors will complain about spoilers, blasphemy, obscene images, and similar things. They are often referred to the disclaimers as a reason this is okay, but few readers will ever see the disclaimers unless they are specifically directed to them. Readers should have the option to turn away from Wikipedia if, for some reason, there is content which they do not want to see. This is particularly important given that Wikipedia is a global encyclopedia; although many of us in the Western world are used to seeing such content and are not particularly disturbed by it, people from other cultures may have other reasons, such as religious obligations, to avoid such material. We need not just our content, but also its presentation to benefit all our readers. As for better placement of the disclaimers, I would suggest going as far as putting a link under "The free encyclopedia that anyone can edit". If not placed there, the disclaimers could go lower on the main page, or on the sidebar. —Naddruf (talk ~ contribs) 21:42, 30 December 2020 (UTC)
Hmmm, I think one could argue that "The free encyclopedia that anyone can edit" essentially is the disclaimer, whereas The Disclaimer merely elaborates on it. I don't know if making it more prominent will necessarily encourage that many more people to read it. Plus I think it's worth presenting Wikipedia "as is": we don't advertise, we don't look flashy, we don't really do anything to draw people in, any decision to use wikipedia is very freely made - I'd be concerned that any degree of dressing, even in the form of a reader's advisory would detract from our dry intentionally-boring vibe that makes us kind of unique. --Paul ❬talk❭ 21:59, 30 December 2020 (UTC)
I'm sceptical that many people bother with disclaimers (wherever we place them), but hopefully, some do, and we won't know because if so they don't complain about stuff in the disclaimers. Some obviously complain even if they've read the disclaimers, because higher truths. "The free encyclopedia that anyone can edit" (on the mainpage) is like Paul says something of a disclaimer in itself, but putting them under Other areas of Wikipedia wouldn't hurt I guess. As for sidebar, there's a "About Wikipedia" there. Gråbergs Gråa Sång (talk) 22:30, 30 December 2020 (UTC)
@Paul Carpenter and Gråbergs Gråa Sång: I am very specifically talking about the WP:Not censored aspect, which comes with the content disclaimer. The fact that there may be errors or misinformation is a given from "The free encyclopedia that anyone can edit". However, readers need to be aware that they may see images of naked people, they may see criticism of their religion, they may see things that children should not see; and that if they don't want to see this, they should avoid Wikipedia or be careful what they look at. It is common for certain types of material in public view to be censored in some way, and the fact that Wikipedia doesn't do this needs to be pointed out. For example, there are 1.8 billion Muslims worldwide, and a large number, if not a majority, believe that Muhammad should not be pictured. Nevertheless, there are pictures of him at our article Muhammad. Over the years, hundreds of people have commented asking that the pictures be removed, but they are still there. So if Wikipedia is going to do something that goes against the beliefs of 10% of the world population, it should make it more clear that this is allowed on Wikipedia by making the policy about this more visible. —Naddruf (talk ~ contribs) 22:44, 30 December 2020 (UTC)
The sort of math that starts with ", and a large number, if not a majority," of 1.8 billion, calculates that this number is a bit north of 900 million, divides by the world pop of 7.8 billion to get 11.5% and decises that 10% is an acceptable approximation of such an uncertain number. My personal guess is a little south of that. There are certainly some ignorant people who think the prohibition on pictures is found in the Koran (it isn't) and they tend to be vocal, so I think the actual proportion is in the 3 to 5% range.--S Philbrick(Talk)21:54, 2 January 2021 (UTC)
And I think the number of complaints will be about the same regardless of where we put the disclaimers. Presumably, in this day and age, many people are told about this by parents and teachers. Yes, WP has all kinds of stuff on it, it's like the rest of the internet in that way. Gråbergs Gråa Sång (talk) 23:17, 30 December 2020 (UTC)
Isn't that already covered by the fact that this is an encyclopedia? Encyclopedias cover the world: good, bad, and indifferent. They describe reality. If the reader can't handle reality, that is their problem, not ours. And, as far as things that go against religious beliefs, why would anyone think that anything that is not run by their religion would be constrained by it? --Khajidha (talk) 22:59, 31 December 2020 (UTC)
The people who are upset that we insulted their religion or that they see an obscene image aren't going to stop complaining just because a legalese disclaimer is shown more prominently. This will not solve the problem you mention, but what it will do is make the UI even more bloated and inaccessible. ProcrastinatingReader (talk) 23:19, 30 December 2020 (UTC)
@ProcrastinatingReader: If it is useful, it does not make the page more inaccessible. This would be more useful than the side links to "related changes" and "page information", and it could be easily added on the main page under "Other areas of Wikipedia" without making anything more bloated. —Naddruf (talk ~ contribs) 23:43, 30 December 2020 (UTC)
I click "page information" lots of times each day. I don't recall the last time I clicked disclaimers. I couldn't tell you from memory what they say. I have an idea of what it says, and I don't really care, it's functionally useless to me and it appears to exist just to cover legal's backside. ProcrastinatingReader (talk) 23:48, 30 December 2020 (UTC)
I cannot imagine why a casual (not-procrastinating) reader would ever click on Page Information, but that is a separate issue. Anyway, that side bar is already more than long enough without adding another thing that no-one is going to read. If this were going to solve any kind of problem, then you'd need a way to prompt them to read it, but for 99% of users that would just be getting in the way. And I honestly don't think that a few people occasionally complaining is representative of the almost 10,000 people a day who view the Muhammad article (of whom I would guess a sizeable portion are from a Muslim background). --Paul ❬talk❭ 09:01, 31 December 2020 (UTC)
I think it's worth discussing how to make the make the disclaimers a little more prominent. Putting it somewhere on the main page might get support if you come in with a well-articulated argument and a sandbox design in hand so people can see what it'd look like. However, asking for it to be added to the left sidebar or to the top of the main page just below the tagline is not likely to succeed. {{u|Sdkb}}talk19:03, 31 December 2020 (UTC)
Overall, I have sympathy with the idea of making disclaimers more prominent. This might be especially valuable for medical articles - there is a Wikipedia: Medical_disclaimer, but one does not see it on many articles on medical topics. Vorbee (talk) 11:52, 1 January 2021 (UTC)
Vorbee, I'm sympathetic to the goal but not persuaded that the solution will be effective. Just check out the wp:ANI page. It has a disclaimer that is:
big
bold
and in red, with underscores
Telling editors they must leave a notice on the editors talk page. This is ignored dozens of times every week. I don't think the solution is to make it bigger. S Philbrick(Talk)20:27, 7 January 2021 (UTC)
"The free encyclopedia that anyone can edit (tfetace)" is generally interpreted by unsophisticated users as "Oh good, if I don't like it, I can change it", or else as "Yay, wet cement! a dusty car window! a clean toilet wall!". To imagine that the average reader reads into tfetace that content is uncensored and may concern anyone, any idea, any practice, ever, regardless of the reader's own standards, may be a bit, umm, "unsophisticated".--Quisqualis (talk) 04:00, 6 January 2021 (UTC)
What could be stripped from the side bar?
In the spirit of having less stuff on every page, I think that the tools section of the sidebar could be stripped down. Especially for logged-out readers. This small change would then allow for a tiny bit more whitespace, but every little helps. I've marked in red below the items that I think we can do without from the 'Tools' section. --Paul ❬talk❭ 09:31, 31 December 2020 (UTC)
Me personally, or the reader being discussed? The latter doesn't have a preferences screen unless they make an account. Either way changing the skin doesn't change amount of items in the Sidebar. --Paul ❬talk❭ 09:48, 31 December 2020 (UTC)
It really doesn't! I just tried a couple of times to it to make sure. The contents of the side bar is the same with any choice of skin. --Paul ❬talk❭ 10:04, 31 December 2020 (UTC)
There was a large, recent RfC seeking to strip and reorganise the sidebar. I believe its results are the perfect example of how active editors' needs – a tiny minority of Wikipedia's users – tend to be disproportionately favoured over readers' needs, because active editors, almost by definition, are the only ones who contribute to these discussions. Thus links virtually useless to readers (Permanent link) were retained, mostly because experienced editors didn't want to lose a precious click, and links that might be of interest to readers (Featured content) were removed instead. However, as part of mw:Reading/Web/Desktop Improvements, the Tools section is proposed to be moved out of the sidebar into a dropdown tab, akin to View history, which I think would be a good compromise. – Teratix₵10:32, 31 December 2020 (UTC)
Yeah that does sound like a good compromise. And a very precise description of the issue at hand, the reader does get forgotten way too easily, see above. --Paul ❬talk❭ 10:36, 31 December 2020 (UTC)
Yep, I think the RfC moved us forward, but overall I very much agree with Teratix. Here's the specific section where I proposed collapsing the tools section by default, which failed.
Also, if we're on the topic, there were some consensuses reached at the RfC that haven't been implemented yet. The ordering of the tools section is one; it has long bugged me that "Page information" isn't the first link as would seem logical, and we agreed to change it here. There's also moving the "cite this page" to the print/export section, which I think got stuck when T255381 was incorrectly closed, the section ordering switch, and some other stopgap measures that need adjustment as they don't work on all pages. All of these things are just stuck somewhere in the backend, and getting them done would be at least a small plus. {{u|Sdkb}}talk19:19, 31 December 2020 (UTC)
@Sdkb: last I checked, the ordering of the items in the "tools" section is not customizable here without ugly javascript hacks (c.f. mw:Manual:Interface/Sidebar) so changes would be for everyone, not just enwiki - and an enwiki want to change something like this isn't usually enough to force a global change. An better option may be to request that the software be updated regarding MediaWiki:Sidebar, allowing the subsections of TOOLBOX to be configured locally. You could request something like that at phab (WP:BUG). — xaosfluxTalk16:45, 1 January 2021 (UTC)
In case this goes anywhere, it occurs to me that the binary choice between readers and editors is overly simplistic. I can think of a third category that is neither fish nor fowl — re-users of content. In addition to the people who are pure readers — they are reading Wikipedia articles to learn something about the subject matter but plan to do no editing or reuse of the material, there are many people who write articles or books and might wish to incorporate excerpts from or links to Wikipedia articles. This happens quite often, and these people are not editors, but they are more than just readers. In many cases they will simply provide a link to the article, but if they know what they're doing, they will also provide a permanent link. Some people do know enough to do this in the existence of the permanent link makes this easy. My point is this class of people are probably not editors in the sense that they never contribute content to Wikipedia, but they would find this sidebar functionality very useful.--S Philbrick(Talk)21:44, 2 January 2021 (UTC)
I'd imagine these users' purposes are most usefully served by the Cite this page link (which provides a permanent link in addition to other bibliographical information). – Teratix₵11:53, 5 January 2021 (UTC)
Teratix, Exactly, but as I understand the original proposal, it is to remove links that are useful only to editors but not to readers. The Cite this page and permanent link options are not explicitly on the proposed chopping block but potentially could be. My point is those functions are valuable to people who are not editors. S Philbrick(Talk)20:12, 7 January 2021 (UTC)
Teratix, After looking closer, I noticed something I had not noticed before, namely that the Cite this page does include Permalink, so if there really is a consensus that the sidebar is too busy, perhaps permanent link is redundant, but that only works if we are sure that people looking for permanent link will realize that Cite this page provides that option. That assumption isn't obvious to me. S Philbrick(Talk)20:16, 7 January 2021 (UTC)
Yeah personally Perm Link is on my keep list, it's a bit redundant but not as redundant as some of the others. --Paul ❬talk❭ 06:59, 11 January 2021 (UTC)
Tools/systems for better catching inappropriate external links within article bodies
I make fix edits like this fairly frequently, removing external links that have been inappropriately placed within an article body. Do we have any tools or filters that patrol for this sort of thing? If not, could we develop them? {{u|Sdkb}}talk20:20, 31 December 2020 (UTC)
I'm trying to figure out how to interpret the silence here. Do others agree that this is a problem? {{u|Sdkb}}talk11:23, 4 January 2021 (UTC)
@Sdkb:, I have also run across this, and I agree that it would be good to detect and flag this. Maybe you'd get better uptake on WP:BOTREQ. The only issue I can see is that it would be technically tricky, as I believe the only way to detect this would be to have a bot crawling every article. Vahurzpu (talk) 18:11, 4 January 2021 (UTC)
Thanks for the reply. Yeah, BOTREQ is probably where this is headed. I'm not sure if this should be a bot or a filter, though. (By "filter", I mean the tags like "possible COI" that I sometimes see next to edits; I'm not too sure how these work.) {{u|Sdkb}}talk18:49, 4 January 2021 (UTC)
Sdkb, I remove them from sentences, but the problem is that there are some cases where the community adopted reasons to have them included in sentences (links to bible texts are one example, links in tables are another). One could try to write an edit filter (I may have a stab at it) to at least flag them. Dirk BeetstraTC04:03, 5 January 2021 (UTC)
LightningComplexFire, that seems like it would be difficult to detect with a filter—what sorts of keywords or other criteria would you want to have? Additionally, there are context concerns: I don't really see anything wrong with, say, two editors running into each other on a very inactive talk page, and adding as part of a reply "hey, it was great to see you at Wikimania the other week". {{u|Sdkb}}talk19:23, 7 January 2021 (UTC)
The question remains: how do you propose that this filter could feasibly work? Filters can't just automatically detect what "socializing" is without it being defined. {{u|Sdkb}}talk19:55, 7 January 2021 (UTC)
It would be computationally difficult without something like an AI, which isn't currently available to us for customized filters, at least not as far as I know. Even with a "well-trained" AI, there will be false positives and false negatives. So, even if it were desirable, something like this is a few years away at best. davidwr/(talk)/(contribs) 21:04, 7 January 2021 (UTC)
Socializing on article talk pages happens for a variety of reasons. It is not a crime. It is important to remember WP:AGF. It is also worth noting WP:IAR. The post can be removed (I've done that many times over the years) with an appropriate edit summary. In my experience, often times, it is someone trying to find out or impart info. Editors can be pointed towards the appropriate ref desk or wikiproject talk page or a help page. IMO, in the grand scheme of things, this is not a huge problem. MarnetteD|Talk17:07, 9 January 2021 (UTC)
Defining socialising would have problems even if such an AI existed. The editors of wikipedia are mostly white US men, so the norms it'd be learning off of would be that of white US men. This could lead to disproportionate tagging of anyone else's posts as socialising because their norms for what isn't socialising may be different. For a very loosely related example, one of my parents is an immigrant. Where she is from, it is not considered a "friend" (or socialising) interaction to chat to a retail worker about each other's personal lives, whereas in our current country this is very much a friend interation.
Further, it is not necessarily bad to socialise - people are social. Therefore, we are more likely to remain in communities where we have social ties, we are better at collaboration when we have those ties, AND we find it difficult to not slip in small amounts of socialisation into any of our interactions. --Xurizuri (talk) 12:50, 12 January 2021 (UTC)
If someone gave a coherent reason why Wikipedia needs a new name then this might be the place to dicuss it, but your own personal need is irrelevant here. Phil Bridger (talk) 21:21, 11 January 2021 (UTC)
Tool for Designing Electric Circuits
Hello,
For the sake of standardizing and improving the quality of all electric schematics on Wikipedia, please add tool for designing electric circuits under the "Insert" tab. This QA website has a very cool tool for creating any kind of electric circuit while making up a question.
This current AN discussion had me thinking about a human-powered, not bot-powered, solution to the occasional case where an IP will hang out at a page for a while, repeatedly vandalizing, for the hour or so it takes an admin to show up. Add a group of editors who can add a template to a page that'll cause an adminbot to protect it for an hour; perhaps also require that the page has a high number of recent reverts. (Bonus: for a single IP hopping to multiple pages, another template that'll cause an adminbot to block them for an hour, requiring perhaps that every edit by that IP has been reverted.) I feel like similar proposals were discussed recently, but couldn't find any, hence this post. Enterprisey (talk!) 03:54, 7 December 2020 (UTC)
I feel like similar proposals were discussed recently I remember a recent proposal which was something along the lines of non-admins being able to protect a page for 24 hrs / block IPs for 4 hours, or something along those lines. Can't find it at a quick check of archives, but then again using Special:Search is too hard for me. That having been said, I think the AN thread can be mostly handled by the filter Suffusion of Yellow is working on. ProcrastinatingReader (talk) 11:14, 7 December 2020 (UTC)
I like this idea I guess, but should be increased to up to 48h for IPs and semi for a few days, to have it actually be useful. An hour is just insufficient. Blocks to IPs vandalising should be favoured over protecting a whole page probably. ProcrastinatingReader (talk) 10:18, 8 December 2020 (UTC)
One hour blocks get rid of the vandal whose just bored while sitting around in a computer lab or on the train. More intractable vandals should be dealt with by admins and CU anyway given the larger toolbox they have to shut down the vandals long term Slywriter (talk) 13:26, 8 December 2020 (UTC)
@Enterprisey: without relying on an enancting bot (and thus making the botop responsible for their actions) or software changes if we really wanted to some sort of fast-SPP we could possibly use the edit filter possibly like this: (a) define who can do this (perhaps all rollbackers) (b) set up an edit filter that only allows this group to add a special template to a page (possibly only to articles) (c) set an edit filter to not allow editing of pages with that template on them by non-confirmed users. (d) Now use a bot, that can run on in batch to go and clear out any of those templates that has been present for more than x time. (Of course any rollbacker/admin can manually remove it). — xaosfluxTalk15:07, 8 December 2020 (UTC)
I remember from an IP this morning that I rollbacked, often these people just move to another article (or roll you back) and rolling back is just clogging up the article history. I think the core element of this is to be able to temporarily block an IP address, otherwise some poor bloke is chasing an IP around adding {{cannotedit}} onto pages the IP hops onto until an admin finally comes around and dishes out a block. It kinda just wastes time for people chasing an IP around, I feel, and will create unnecessary protections.
BTW regarding the accountability point, you did explain accountability vs responsibility to me before in an elegant way, but I still feel something is off about this. That convention on botops, to the extent that it has any practical effects (given TFD/CFDW/patrol bots), is a social construct rather than a technical limitation, right? I don't see what the real difference is between having the MediaWiki software do it (through 2 filters + a bot) vs just one bot. Similarly, the person who wrote the patch in MediaWiki for the technical block functionality isn't responsible for someone, who the community gave sysop to, going on a blocking spree. Surely we can amend WP:BOTMULTIOP to say that bot operators are not responsible for the edit themselves, minus technical bugs, if the person who can trigger the bot is decided in a manner set and approved by community consensus in an RfC (which this feature would need anyway), rather than by a process chosen by the bot operator, and the triggering editor is disclosed and verified? Surely this kind of amendment makes sense anyway, if the community are the ones setting the criteria, and unrelated admins are the ones executing said criteria? ProcrastinatingReader (talk) 18:16, 8 December 2020 (UTC)
ProcrastinatingReader, Yup, you found it. I'm neutral on the details of the implementation (new core permission, adminbot, whatever) but ultimately I think some sort of process is necessary, akin to Citizen's arrest. The idea is that a (much) larger population of users is empowered to make temporary, scope-limited interventions to stop vandalism, faster than the much smaller admin corps can react. There are, of course, lots of details to worry about to prevent abuse: who's authorized to do it, how long they can protect/block for, reporting/review/accountability, etc. -- RoySmith(talk)19:10, 8 December 2020 (UTC)
So, let's talk strategy. This is a proposal that many people (including me) like, but we have to face the reality that similar proposals have been shot down in the past. Because of this, IMO any proposal should start very conservative -- ignoring all cries that it isn't enough -- and then after it shows itself to not cause problems, we can discuss possible modifications. I would propose:
Stop discussing how to do it until we have a consensus to do it. Early focus on implementation details destroys good ideas. First decide what you want to do assuming that you can do anything. Then decide what the closest thing that you actually can do is.
Six-month Three month limited trial, tool disabled and discussion started on whether to re-enable at the end of the trial.
Stop the trial early if there is a consensus that it was a bad idea.
Based upon a permissions list.
Editors must request permission. Only given to extended confirmed editors in good standing.
Limited to one hour of blocking for IPs only. No page protection.
Cannot be used more than 10 times in any rolling 7-day period.
Draconian punishment for abuse. I would suggest a six month block and a two-year revocation of permission to use the tool on the first strike.
If someone proposes the above and it gets shot down, we will pretty much know that any proposal that involves any unbundling will be a waste of effort. --Guy Macon (talk) 19:15, 8 December 2020 (UTC)
Maybe lower the trial to a 3 month period? Ideally after a successful trial we can ditch the Cannot be used more than 10 times in any rolling 7-day period.
We're also going to need a better criteria for Editors must request permission. Only given to extended confirmed editors in good standing. Ending up with a de-facto "I'll know it when I see it" is untenable imo. A good criteria for admins to assess grant requests by, and for users to assess their own suitability with, is required. Also, I think some technical aspects matter, to relax people. Granting the "block" perm may be different to granting a new "blockip" perm + bots logging actions by group, certainly may have an effect on the criteria. ProcrastinatingReader (talk) 19:40, 8 December 2020 (UTC)
@ProcrastinatingReader: making new core permissions will require development time (see phab:T128328 for the 2016 request that would need to be done for some of this) - for a trial you may want to use "administrative controls" (i.e. a policy / "rules") instead of hoping a developer delivers on that and that it gets incorporated to core. — xaosfluxTalk20:05, 8 December 2020 (UTC)
I'm not sure I agree. See, eg, this. The people we want having this tool may not be bold enough to ask if they feel the bar is too high, and granting admins may not know what to look for. A lack of granting criteria has caused broken permissions processes every time, and clear criteria (ie, most other perms) has created a somewhat functional system. IPBE is quite different in that people are forced to ask for it, or else they literally cannot edit. Nobody is forced to ask for the block button, they can keep painfully spamming !admin on IRC. Whether "I'll know it when I see it" is sufficient for a trial, well, perhaps? But I'm not sure it's very reassuring for people voting on the proposal; I have a picture of the bar in my mind, but I have no clue if that bar is the same, much higher, or much lower, as the picture in yours (also note EFH, TPEPMR all proposed criteria). But I see the point that drafting a clear criteria is just another point to debate on, which may be equally as tricky as the proposal itself, and should maybe wait till post-trial review. How about the granting process? Can any admin grant on request, or should it be like an EFH process where it's advertised on a noticeboard for 3 days of comments and closed by an uninvolved admin? ProcrastinatingReader (talk) 21:09, 8 December 2020 (UTC)
Alternative limit: at most 10 outstanding blocks at any time (blocks "taken over" by an admin don't count). Which raises the question of whether admins would even bother blocking an IP that's already under an hour-long block. Enterprisey (talk!) 11:17, 9 December 2020 (UTC)
Just noting, it is trivial to make an access group that can technically fully use the Block interface, and make a community rule that says that members of that group may only use the access in certain conditions and with certain parameters. (Protect is a bit of a messier situation, but such a group could be combined with the AFilter info above). — xaosfluxTalk19:19, 8 December 2020 (UTC)
For the more enwiki-focused here, I'll add Meta has the similar concept of "limited admins" - they have the full toolkit but are only allowed to use it within $scope_requested_at_rfa (could be time, specific tasks, things like that), straying out of those bounds is grounds for immediate desysop. So there is precedent for "here's $permission, you may only use it for $tasks" GeneralNotability (talk) 21:21, 8 December 2020 (UTC)
GeneralNotability, We have some of that on enwiki too. Don't election scrutinizers get temporary CU rights? Are don't we also have an "event organizer" role that gives people running edit-a-thons the ability to create accounts and grant them confirmed access? -- RoySmith(talk)21:30, 8 December 2020 (UTC)
@RoySmith: the scrutinizers must already be global stewards, so that's really no big deal; the event coordinator is closest - they are allowed by policy to confirm accounts - but only for up to 10 days (though the system does not technically enforce that).
@GeneralNotability: I doubt the m-w "limited admin" style itself would fly here, but the concept of only being allowed to use permissions for certain things may. There are some other projects that have a limited-admin-like group that has a subset of admin tools (like block and delete or other combos) - canonically this is usually called "eliminator" but can be styled locally however. Rules and control can be whatever is good for the community and so long as undelete/viewdelete are not involved it doesn't require an "election" system. — xaosfluxTalk02:50, 9 December 2020 (UTC)
ProcrastinatingReader, I was actually being facetious. It's a great name, but I think it will attract bad actors because they want that hat and the accompanying userbox. Sorry, I should have indicated I was being facetious. :) —valereee (talk) 13:22, 10 December 2020 (UTC)
In my opinion -- and I do have quite a bit of experience in the area of technical proposals -- "I think some technical aspects matter, to relax people" is a common mistake. Here is the right way to do things:
Step 1: decide what you would like to do without any thought of implementation details.
Step 2: look at the technical issues, figure out what is possible given the budget and deadline, and modify what you came up with in step 1.
Step 3: create a concrete proposal and see if it flies.
You don't need "to relax people" until step 3. Every time something like this comes up in discussion, some well meaning person gets into the weeds of what is and isn't easy to do before there is agreement as to what to do. I get it. I have the same tendency and did it that way before I learned a better way. Getting into implementation details too early kind of sort of works OK, but my way works far better. --Guy Macon (talk) 21:18, 8 December 2020 (UTC)
Guy Macon, What you're describing is certainly what goes on in the software development world. Product management comes up with what's often called a PRD (Product Requirements Document) which describes what they want the feature to do. Then they get together with the developers who, after they stop laughing, tell product management what's technically possible. Then, the two sides hopefully converge on something that's both useful to the user and possible to build. -- RoySmith(talk)21:35, 8 December 2020 (UTC)
I am guessing the answer to step 1 is currently "create a group which can place blocks on IPs for up to 1 hour". And we have your bullet-pointed list above as a start. So, what exactly comes next? ProcrastinatingReader (talk) 21:35, 8 December 2020 (UTC)
Stage one
Confirm that we have a local consensus (just us in this discussion) for 1 hour and not some other duration (does anyone object?)
Confirm that we have a local consensus for a three month trial (does anyone object?)
Decide who should be allowed to use the tool during the trial and who will grant permission.
Decide what happens if someone abuses the right. (I vote for very harsh penalties, with the penalty made clear to anyone who asks for the user right.)
Come up with a catchy name. (This is actually one of the main things that determines whether the proposal passes)
Stage two
Take the above and start discussing ways to accomplish this during the trial, modifying the requirements as needed.
Come to a consensus as to not only what we want to do but how we want to do it.
Stage three
Draft an RfC, giving everyone a chance to criticize/modify it before going live.
Post the RfC.
Populate the early !votes with !votes from those of us who have been working on this.
Get shot down in flames just like every previous unbundling proposal.
Gotcha. On harsh penalties, I feel like we go overboard here. We shouldn’t try to overly scare competent editors who offer to volunteer their time for free. To that end, maybe just say that it’s an admin-level permission and so WP:TOOLMISUSE applies? ProcrastinatingReader (talk) 23:52, 8 December 2020 (UTC)
ProcrastinatingReader, TOOLMISUSE seems like the right standard to apply. A good (if imperfect) analogy would be WP:NAC. We carved out a process previously reserved to admins and allowed non-admins to do it. There's limits on what discussions non-admins can close, questionable ones regularly get reviewed at WP:DRV, and every once in a while there's somebody doing NACs who is doing a poor job of it, and they're "encouraged" to not do them any more. I don't know of any cases that got as far as a formal NAC WP:TBAN being enacted, but I wouldn't be surprised if there have been some. Overall, it all seems to work.
The only difference is that with NAC, the "only admins can do it" was a convention, and with blocks and page protections, it's enforced by the software. But, that's a detail. The software exists to serve the needs of the community. If it's not doing what we want, we either change it or route around it. -- RoySmith(talk)03:09, 9 December 2020 (UTC)
For granting, two wild ideas: the usual PERM process, except require two admin approvals? Or the usual PERM process, except no self-noms? (So I guess candidates would have to ask someone else to nominate them.) I have done zero thinking through of the drawbacks of either. Enterprisey (talk!) 09:39, 10 December 2020 (UTC)
Why not both? Must be nominated by some other editor ('surprise nominations' are okay, encouraged even). Open for a minimum of 48 hours, if two admins agree and there's a consensus to promote (ie not 10 other admins saying "bad idea!") any admin can close the discussion and grant the permission?
For revocation, TOOLMISUSE standard: any admin who believes the permission has been abused (or used outside of its approved scope) may revoke it immediately, and should start a follow-up discussion at AN for the matter to be discussed. ProcrastinatingReader (talk) 09:44, 10 December 2020 (UTC)
Hm, I can see both sides. I think it's simpler and more consistent just to say no (admin nom doesn't count), so that by design at least 3 editors (1 admin/non-admin nom, plus 2 admins concurring) have agreed on each request.As an aside, the point of nomination-only in my eyes is: (a) grossly unqualified candidates won't end up nominating themselves and having to go through the rejection; (b) candidates too scared to nominate themselves won't be prevented from getting a right to help their workflow (and consequently, improving the encyclopaedia). I don't think this has any obvious downside: any competent person consistently reporting IPs at AIV will have gotten the attention of someone. ProcrastinatingReader (talk) 10:26, 10 December 2020 (UTC)
A draft
I think I have roughly summed up what we have above so far, and taken some considerations/concerns from the previous discussions on this. Rough draft at User:ProcrastinatingReader/draft. Thoughts?
Reading over past discussions (linked there, also pinging some previous proposers/commentors for advice @WereSpielChequers, Jackmcbarn, Oiyarbepsy, Hut 8.5, and Dank). Reading over the previous RfC, I can extract the following main concerns, with varying prominence:
Blocking anyone is a right that should be subject to full community approval. Or: Block should not be unbundled. (maybe the 48h hold and multiple admin requirement addresses this, somewhat?)
Unbundling proposals based on what might pass, not on what's actually needed.
Backlogs aren't that bad and admins can deal with the workload
This creates 'admin-lite'. Anyone who can be trusted with "block" can be trusted with "sysop" / "I'll support you at RfA if I trust you with this right"
Will lead to controversial blocks
Won't decrease the workload, because an actual admin has to come along and make the protection / lengthen the block anyway. 1 admin > 1 admin + 1 non-admin.
Scope so narrow that any benefits aren't worth the developer effort
Some of these maybe can't be defended against in the proposal (eg #4 is just idealism). And #6 I think misses the point, in that this intends to put a stop to ongoing vandalism when an admin can't respond fast enough, the time the admin would've spent blocking before is equal to the time they will spend blocking after the proposal. The difference is that a vandal-fighter, instead of chasing an IP around for half an hour, can just press block and submit a report to AIV and move onto the next person. We can maybe think up stuff to deal with the other concerns, though?
ProcrastinatingReader (talk) 11:19, 10 December 2020 (UTC)
Also, the original 100-person RfC, despite ~50 opposes, nobody raised concerns with the proposed 48 hour block duration / proposal that non-autoconfirmed can be blocked as well as IPs. So I think we can loosen those restrictions (1hr is probably too short, and will create more cases where a normal admin has to issue a follow-up block, given the normal blocking period is ~31 hours). ProcrastinatingReader (talk) 11:22, 10 December 2020 (UTC)
I'm not sure I agree with the concept and I don't like the name, maybe moderators or proctors? Given that many IP blocks are usefully 31 hours - excluding kids from that school day and the next, I think that if this proposal is going to be of any use it needs to be 31 hour blocks, or at least something more than an hour. It also needs to specifically exclude incidents that are disputes between people who could and could not be blocked by these admin lites. As for the 12 month tenure, you can pass RFA with not much more than that. How about must have edited in at least 8 different calendar months? ϢereSpielChequers12:29, 10 December 2020 (UTC)
WereSpielChequers, the concept behind one hour is that it gives an editor who is fully-busy with reverting the vandal time to report and get an admin there to reblock for 31 hours. I love eliminator but I think it's going to attract bad actors who want a superhero userbox. Even proctor sounds too "I'm in charge here" to me. Maybe something like "temp-protect"? —valereee (talk) 13:19, 10 December 2020 (UTC)
Fair. "Moderator" makes me think of censorship or something like reddit, in today's political climate, so eh. If eliminator etc is too much, maybe we can just be bland (eg indeed "tempprotect", or name it after the perm - "blocker", or "abuseblocker", etc). ProcrastinatingReader (talk) 13:34, 10 December 2020 (UTC)
FWIW I don't even like admin. :) Anything with "blocker" in it is probably too attractive, IMO. Moderator IMO has the same problem. And, yes, blandness in this case I think is much-to-be-sought-after. —valereee (talk) 13:45, 10 December 2020 (UTC)
Yeah, I really hate the "eliminator" name. Maybe "first responder"? The analogy is to an EMT who rushes in to provide immediate intervention, gets things stabilized, then hands off to a more experienced team (Emergency Room doctors) for follow-up treatment. Keep it positive. -- RoySmith(talk)14:04, 10 December 2020 (UTC)
WSC, this isn't so much an admin shortage problem. It's an "ACK! Emergency!" problem. I'll make an analogy: The fire department is five miles away, and it takes them ten minutes to respond to a fire. We may very well need more fire fighters, but that doesn't solve the problem. So maybe we should consider making sure we have smoke alarms & fire extinguisherscreating the position of fire warden and arming them with fire extinguishers.. —valereee (talk) 13:31, 10 December 2020 (UTC)
This is similar to things I proposed seven years ago, my views have since shifted. It is indeed an "ACK! Emergency!" problem, but that makes it a subset of our admin shortage problem. The Firefighter analogy is a good one, except that firestations cost money, as do fire-engines and usually firefighters. Since admins are unpaid, they are the equivalent of deploying smoke alarms and fire extinguishers and appointing and training people as fire wardens to evacuate office buildings when the fire alarms go off. Most of us don't want our admins to be paid, or even to be so busy being admins that we don't have time to do the non admin stuff that may be the main reason why we are here. The way to prevent that is to have lots more admins. ϢereSpielChequers13:54, 10 December 2020 (UTC)
WereSpielChequers, I agree that we need more admins, but that's a bigger and harder to solve problem. People don't want to subject themselves to the ritual hazing that goes on at WP:RfA, and honestly I can't blame them. -- RoySmith(talk)14:09, 10 December 2020 (UTC)
I agree that RFA can be a ritual hazing, but I believe its reputation is worse that the reality. It is afterall still capable of giving candidates 100% support as has happened twice in recent months. ϢereSpielChequers16:30, 15 December 2020 (UTC)
I stand corrected, As admins are unpaid we are more akin to firewardens than firefighters. There is no reason to limit the numbers of such volunteers. ϢereSpielChequers16:30, 15 December 2020 (UTC)
@WereSpielChequers: I think the point valereee was trying to make (or at least how I read it) is less the paid/volunteer distinction and more that people can still be useful in preventing fires (given the right training and tools) without having all the knowledge, qualifications and trust it takes to become a firefighter. The rebuttal is probably that we can just make people firefighters and trust that they're sensible enough to only respond to the fires they can handle and learn along the way and then tackle bigger fires. But then we'd have to introduce the Firefighter Appointments Board into this analogy. ProcrastinatingReader (talk) 12:26, 16 December 2020 (UTC)
Yes. But there are some differences between this proposal and say the unbundling of template editing. Firstly a lot of editors at RFA care deeply about who gets to block people, and that makes it unsuitable for unbundling. Template editor was a successful unbundling because it didn't involve either of the "third rails" that get most attention at RFA. This proposal involves blocking, one of the "third rail" issues at RFA. The proposed requirements are pretty close to an RFA minimum requirement - 12 months tenure, whilst template editor is available for people who can edit templates, a topic that rarely ever even arises at RFA. Unbundling template editor actually reduced the admin workload, as indeed would a 31 hour block for IPs. But a very short block doesn't reduce the admin workload, complicates IP's block logs because instead of a 31 hour block you will now sometimes get a one hour block upped to 31 hours by the reviewing admin. Unbundling the power to block newbies and IPs for the lengths of time that admins do would actually save admin time, so in that sense it becomes tempting. Though it would be better to recruit more admins. BTW, you've missed two of the arguments against such an unbundling. The mop is a toolset, and block is not always the right tool. unbundle just that hammer and you risk having it be used where page protection would be the better tool or where both block and revision delete should be used. Secondly there is the idealistic one that all editors should be equal, and this means that we would be more ready to block newbies than the regulars (I don't buy this last reason myself, but I believe others will). ϢereSpielChequers13:34, 16 December 2020 (UTC)
@WereSpielChequers: I think I get what you're saying overall. On some of the specifics: the stricter requirements and the 1 hour block I believe was intended to make the proposal more digestible (and then add on it with time as appropriate), but do you think in reality it actually does the opposite? Regarding toolset, I think the idea was that people with this group don't act when the necessary action is outside of their tools, and in those cases resort to doing what they do now (report/find an admin).
But I think the overarching idea is whether this functionality should be unbundled at all? Or if, to the extent that it should be unbundled, those terms will gain community consensus. Do you think there's a way to remedy this proposal in a way that makes it both more useful, and more acceptable to the community when it goes for RfC? If not, and if this is a doomed proposal, what else can be done about the real problem it tries to address? ProcrastinatingReader (talk) 17:29, 19 December 2020 (UTC)
Apologies for not getting back earlier. 31 hour blocks for IPs and indef blocks for editors who are not yet extended confirmed would be useful, even if it was limited to vandalism only accounts. I still think that I would oppose the measure as it ignores our real problem which is recruiting more admins. But this would usefully reduce the admin workload. ϢereSpielChequers21:32, 4 January 2021 (UTC)
@ProcrastinatingReader: thanks for failing to live up to your user name by writing this draft. In particular, thanks for doing the research to find all the earlier discussions. I can nitpick some details, but overall I think it's workable. It's certainly good enough for a trial; at the end of 3 months we'll know more and can evolve the concept based on our experience. My one question is the 1-hour block window with respect to WP:AIV response time. Do we have any statistics on how long requests usually sit in the AIV queue before being serviced? I'm looking at it now and see a couple (one bot, one user) that are 3-1/2 hours old. If that's typical, then maybe a 3-6-hour block would be more appropriate? -- RoySmith(talk)14:31, 10 December 2020 (UTC)
I've been intending to slap together some code to answer that and the related question of "how much time is actually wasted with these constant reverts", but I'm working on stuff for my wikiconference demo; maybe next week. I agree increasing the block length might be appropriate. The block length could be increased even further with additional restrictions on the blocks' usage, such as requiring every (90%?) edit by the user to have been reverted. Enterprisey (talk!) 02:36, 11 December 2020 (UTC)
That would be an interesting statistic to put into the background section! The latest RfA (from Hammersoft) also gave me an interesting one (saving me the digging): WP:AIV has been tagged as backlogged more than 40 times in the past week. It's worth noting a bot removes 'stale' AIV reports after 4-8 hours, but it's likely most of these are ones where no action was required. ProcrastinatingReader (talk) 11:02, 11 December 2020 (UTC)
@ProcrastinatingReader and Enterprisey: - a couple of bits from me. Was there a reason that unbundling block, rather than protect, was considered? I would have thought that objections to ultra-minimal semi-protecting (otherwise in line with the limits here) would be less controversial. A mis-targeted block is an ultra-aggressive action to happen to you, whereas protects don't risk losing the user permanently (at the tradeoff of being broader). Whatever route is taken, it should note that the same requirements of WP:ADMINACCT will apply to their use by first responders. I would actually suggest 3 hours - this is particularly key in the admin inactive bubble (0300-0800 UTC). Nosebagbear (talk) 12:12, 16 December 2020 (UTC)
I think whilst protect may be more acceptable to the community, I think it's a very bad idea and not in line with the protection policy. One vandal hops across many pages, and they all end up semi-protected for an hour (or few), repeat until an admin comes and blocks? Where do we draw the line? 100 pages semi-protected, rather than blocking the one IP causing trouble? What if they are causing havoc at AN? Protection stops everyone (not autoconfirmed) from editing, whereas blocks only stop the vandal from editing. I get the fear of mistargeted blocks, but blocking solely obvious vandalism is a much lower bar than what admins have to do (block for disruption / edit warring / content disputes, all that more discretionary stuff), and the kinds of people I am thinking in my head with this perm would not make this error in distinguishing. I honestly think the error rate here will be equal, or lower, than what the error rate by admins is. ProcrastinatingReader (talk) 12:20, 16 December 2020 (UTC)
ProcrastinatingReader, Blocks and protection are different shaped tools; the sets of problems they solve are different, but overlapping. Somebody with a dynamic IP can vandalize a single page from many different addresses (protect) One person can vandalize many pages (block). Ultimately, it would be useful to extend both of these tools (in a limited way) to non-admins. But for an initial proof-of-concept, we should pick one and see how it goes. At some point in the future, we can come (presumably) back and say, "This is working. We've figured out authorization, monitoring, corrective action for abuse, etc, and put processes into place which solve the problems we discovered as we went. Now, let's give them the other tool as well". With that in mind, I don't think it's critical which of the two we offer first. -- RoySmith (talk) 14:35, 16 December 2020 (UTC)
ime the scenario of one account/IP being a problem (on one or multiple pages) is more commonly seen than multiple IPs on one or more pages. But when I asked a few people offwiki for thoughts on this idea, I generally got the gist that people are more favourable towards protection than blocking, so it may well be that's more appropriate. That said, it would take more judgement to use and more incorrect usages (or, less usages in general, if used correctly) I fear. The protection of a page where just one IP is engaged in vandalism would (in most cases, at least) be contrary to the protection policy I'd think? ProcrastinatingReader (talk) 17:16, 16 December 2020 (UTC)
I originally envisioned it as actually unbundling both; probably just one would be easier to pass, and as per the above, both have their pros and cons. Protection, of course, would be the proper tool if a single article is seeing disruption from a variety of non-autoconfirmed editors, but intuitively this is rarer than the one editor/many articles case, so unbundling blocking would then have a higher impact. Enterprisey (talk!) 07:53, 17 December 2020 (UTC)
but intuitively this is rarer than the one editor/many articles case. This is my experience as well. The two most common cases I encounter are A) An single account vandalizing a whole bunch of pages and B) An single account continuously vandalizing an single page. In my personal experience the single article/many accounts is incredibly rare with the last one I can recount weeks ago. Merry Christmas!AsarteaTalkContribs!12:30, 17 December 2020 (UTC)
Navigating within long-winded discussions by way of a visual parsing cue
If this qualifies as a technical proposal, please let me know, and I will move this post to VPT.
My proposal is that some means of visually parsing a long, back-and-forth or round-robin, relatively free-ranging discussion on Wikipedia ought to be developed. I often have trouble visually parsing long discussions on the WP:Help desk, for example. Sometimes, a discussion will involve three or more people and/or have five or more posts. Spacing between posts is not standardized, nor are signatures, nor is indentation, nor is the length of posts. Sometimes, people become confused and respond as if one person is the author of what another user has written. My heuristic (and I hope, permanent) solution, which would work wherever posts are begun on a fresh line, would be to have a marker (anything from an asterisk to an arrow head) automatically appear in the left margin, next to the start of a new post. That way, posts will be harder to miss or misattribute.
Today, I met my match in the form of a visually unparseable Arbitration discussion. One post was in excess of 12,000 bytes. Finding that post's author took looking up the longest post in the page's History, then searching within the discussion until I found that post's author's signature. At that point, what the post said had lost its significance.
Alternatively, time stamps could have background coloration to identify the nearby presence of a signature, although this would not work where users don't sign their post and have not opted to have SineBot do it for them. On the Help desk, such people are frequently the original poster.
@Quisqualis you raising this is timely. As @Whatamidoing (WMF) alluded to (thank you for the ping!), in the coming months the Editing Team will begin work on a project that will, ideally, make it easier to parse conversations with many comments and speakers. In the meantime, I've added the issue you described in the original post in this section to the ticket where we are thinking about: phab: T249579.
I had a concept for a media channel project and wanted to hear some wikipedia community feedback before I get too far along.
Put simply, I'd like to record verbatim readings of wikipedia pages and post them to video sharing and social media sites. I would link to the source page, list references, and plug donations to the foundation at the end of videos.
I appreciate wikipedia so much, and especially the amazing work done behind the scenes to make content as coherent and reliable as possible.
At best, I feel this project will extend the reach of wikipedia to some people who either cannot or prefer not to read the English text themselves. At worst, I'll get some practice as a reader.
I know this kind of use is generally permitted, provided that licensing and attribution are observed. I'm posting here to gather ideas and (especially) concerns/objections. — Preceding unsigned comment added by Masterpiece Reader (talk • contribs) 02:05, 14 January 2021 (UTC)
The only benefit of those recordings that I have seen is for entertainment (e.g. the recording of Nigga). Other than that, it doesn't have much benefit over using a screen reader, which is customizable and always allows listening to the latest version of articles. Dullbananas (talk) 04:40, 15 January 2021 (UTC)
As long as you attribute it correctly, you're free to reuse the content of Wikipedia in any way you want—you don't need to ask permission. (See Hellingly Hospital Railway for an example of a spoken article at Featured Article level—note the discreet link at the top next to the FA star.) I can tell you now that the drawback to what you're proposing—and the reason WP:WikiProject Spoken Wikipedia never worked—is that the articles in which people tend to be most interested, are precisely those articles which change most often, and nobody wants to commit to re-recording a new version every few days. (Plus, the people who would most benefit from spoken-word Wikipedia—the visually impaired and those who have difficulty reading—generally would prefer to use screen-reader software where they can adjust their preferences to suit regarding the accent, the speed of the reading, how it handles images, and searching for a particular part of the text, rather than a set of spoken-word recordings.) ‑ Iridescent08:50, 14 January 2021 (UTC)
@Masterpiece Reader: as they said above, and you don't need to include donations links (though WMF won't mind donations!) see Wikipedia:Reusing Wikipedia content for guidelines on how to license and attribute the work. One thing you can do in any links is to specify the version that you dictated, on a page click on the "Permanent link" link on the left sidebar to have a link to a point-in-time version if it will help you. — xaosfluxTalk14:56, 14 January 2021 (UTC)
Thanks Xaosflux, Iridescent and Izno! I'll think about this. @Iridescent, thanks especially for that bit about reading software preference; I'll pivot to focus more on reach than accessibility.
Re-reading entire pages every time they update does sound tedious, but unless large swaths of text are removed or reordered regularly (?), I could just record the new text and patch it in with editing.
Also, I saw some things suggesting that volunteer hours are declining. Should I be concerned? Would it be potentially helpful to plug volunteering to my potential audience? User: Masterpiece Reader — Preceding undated comment added 21:05, 14 January 2021 (UTC)
Major revision of (important) articles - guidelines and practices?
Over at the Donald Trump article, we have discussed significant revisions to the article, particularly given its excessive size. The article, with an eye on its many many related articles, would seem to need a major revision, reorganization to downsize it. Happens all the time with writing, one starts over and recycles material already developed, as appropriate. I am unsure of quite how to do that in Wikipedia, how to tear apart and reassemble an article, particularly one as important as Donald Trump. Once such a process begins the article could remain in a terrible state of construction, perhaps for a long time, with no guarantee that the result would be better than the original. Does/should Wikipedia have a policy/guidelines for major article revision? Once a revision is started, should an old article have a tag warning away new revisions and redirecting editors to the revised version? On the Donald Trump talk page, I sketched a process of (1) agree on a revised outline and philosophy, (2) start (offline) subpages for article sections, (3) once a decent revised state has been achieved, replace the old article. Seems to me wikipedia ought to have some guidelines and tools, advice on avoiding dangers, etc. for a major revision of an article. (I once attempted a major revision of a different article...I got all the "spinning plates" up in my head, had the plan in mind, had undisputed agreement on the Talk page...but then some change watcher reverted me halfway through the revision...Arrrgggh!) Bdushaw (talk) 02:06, 11 January 2021 (UTC)
For articles edited more rarely, spinning off a sandbox article (and posting a link on the talk page) is a common method, but as indicated, not viable here (on its own). For something as major as Trump's article, you'd likely want consensus on the talk page prior to making what would be a huge string of major edits (remember, many of the inclusions actually had short RfCs about their inclusion on T's page), and gather buy-in for not just the change occurring but your proposed methodology. I'd be inclined to think that any guidelines we tried to create on how to handle a re-write of such a large article would end up honoured more in the breach than in the observance - local consensus and wildly different circumstances would make different methods suitable at different times. I'd personally be inclined to take an elephant approach and handle it one section at a time, because your change is going to impact not just the article you're trimming but potentially the various sub-pages (e.g. the presidency of Trump) that already exist. Trying to do that all at once would require an ability to make editing freeze for a couple of weeks while you did the work. Nosebagbear (talk) 11:42, 11 January 2021 (UTC)
Agreed that a piecemeal approach, to the extent it's possible, might yield better results. Regarding guidance, we don't need any new policies/guidelines as this is covered already by WP:Consensus and we want to avoid WP:CREEP, but there might be an essay on the topic out there somewhere, and if there's not it'd probably be fine to create it. {{u|Sdkb}}talk03:17, 19 January 2021 (UTC)
It's something technical, and I'm not in the weeds enough to know precisely what, but I agree that the current system is not optimal. Particularly, having them all be template-protected is a big impediment to their use, and we need them to be used/refined more on order to meet WP:ENDURE. {{u|Sdkb}}talk10:59, 14 January 2021 (UTC)
They're protected via the blacklist, not by page protection, so page movers (who have tboverride) can also edit them. I don't think anyone should be able to edit the editnotices. Talk page clutter is bad enough, and many mistakes have been propagated even by template editors making mistakes (eg {{COVID19 GS editnotice}}). If editing editnotices was common-place they'd quickly become littered with crap, and it's an uphill battle to remove stuff on here. Actually, it's an uphill battle to do many changes; people are more scared of what they can't see than the status quo of what they can. I imagine this phenomenom has a name, and indeed a Wikipedia article on it, but I don't know what it's called. ProcrastinatingReader (talk) 12:34, 14 January 2021 (UTC)
I wouldn't want to have yet another namespace just for this, would prefer they were attached to their page instead like we do with userpage editnotices (e.g. User:Xaosflux/Editnotice) - that being said if there was going to be a wholesale improvement attaching them more formally to the page (e.g. Example, Talk:Example, Notice:Example) maybe, and attach them all together more formally (those this breaks down for noticed FOR talk pages.... or notices FOR notices.... or notices for notices for notices .......) — xaosfluxTalk14:51, 14 January 2021 (UTC)
How could we get organized to draft a Nobel Peace Prize nomination for Jimbo? I've had colleagues in academia that have successfully nominated other colleagues, but I think a grass roots effort among fellow Wikipedians would be best. Also, has this idea come up before? Charles Juvon (talk) 03:45, 16 January 2021 (UTC)
Well if Bob Dylan can win the Nobel in Literature why not. Typically the Peace Prize is given to someone who did something notable in the prior year to help call attention to their message. -- GreenC04:28, 16 January 2021 (UTC)
That's true, but Wikipedia required decades and millions of people to develop. Perhaps we could do something analogous to IPPNW and Jimbo (plus up to two others) could accept the prize. Charles Juvon (talk) 08:48, 16 January 2021 (UTC)
The NPP is for whoever the Nobel committee considers shall have done the most or the best work for fraternity between nations, for the abolition or reduction of standing armies and for the holding and promotion of peace congresses. I find it hard to think of any conceivable way Jimmy Wales could possibly be considered to meet any of that by even the most flexible application of standards. (Also, given Wikipedia's history I doubt either Jimmy Wales or the WMF would welcome the press interest in Wikipedia's founding that this would generate. The recent 20th anniversary press releases have glossed over the fact that Nupedia and Wikipedia were originally intended to drive traffic to a highly questionable website—this is the first appearance of the public-facing "Wikipedia" link, neatly filed next to "Auto Guide" and "Babe Report".)
If you still want to press ahead, a grass roots effort can't nominate someone for the NPP. Only individuals who meet one of these narrow criteria (the most relevant being University professors, professors emeriti and associate professors of history, social sciences, law, philosophy, theology, and religion) can nominate someone—if you're a member of one of these groups just fill in the form, they only base their decisions on what's on the nomination form and not what any online campaign or lobbying says. ‑ Iridescent09:27, 16 January 2021 (UTC)
There is a precedent for Nobel Peace Prizes to granted to organisations or groups of people (actually about a fifth of the time) but I think Charles' is suggesting that Jimbo be the figurehead that receives it, with the understanding that he just 'got the ball rolling'. If you take a look at past recipients - pretty much all of them got it for founding/leading/negotiating the creation of something that was then maintained by multiple people. --Paul ❬talk❭ 10:29, 16 January 2021 (UTC)
If you really want to go down this route of pomposity, then please consider this comment to be the formal objection. I find the suggestion patronising and offensive, both in the implication that Jimmy Wales is somehow more important than the people who actually built Wikipedia, and that Jimmy Wales (who is at best irrelevant and at worst actively disruptive) is in any way representative of the people who actually built Wikipedia. ‑ Iridescent15:20, 16 January 2021 (UTC)
I think we've already concluded that a "formal nomination" involves filling in a form. Which as a completely off-wiki action is way out of scope for anything we could discuss here. --Paul ❬talk❭ 15:37, 16 January 2021 (UTC)
I've been through this process several times. It's usually a letter, but this will do. Just like Wikipedia, where anyone can edit, for the Nobel Prize, anyone can nominate. Charles Juvon (talk) 15:45, 16 January 2021 (UTC)
This is certainly one of the silliest ideas ever floated on the page, and there's some stiff competition there. Besides, everyone knows Trump's getting the prize every year from now on. EEng20:42, 16 January 2021 (UTC)
What's wrong with nominating 40,744,588 Wikipedians? If Jimbo isn't popular, then someone like Godwin can go pick it up. Although there is not enough room for all of us, dinner in the Golden Room Golden Room is quite an experience.Charles Juvon (talk) 01:25, 19 January 2021 (UTC)
Internal Quality of Wikipedia and syncing articles between different languages
Hey folks - I am not sure if I am on the right place to discuss this. If not please move it to where it
is appropriate; it is a bit difficult to google-search for the right page. :-)
Wikipedia has been around for many years and those who remember it from the early days may see
that it has improved a LOT. So, this is first a bit of praise.
There are of course a few minor annoyances; one pet peeve of mine is that some articles are WAY
too understand for average people. I understand that you want to add high quality content too
which is ok, but the FIRST entry point should be simplicity. Many scientific articles have
this problem; evidently they were written by an expert in the field, but many people don't
understand it easily, in particular in physics. But this is also an aside.
The thing I actually wanted to point out is ... well.
You have +6.2 million articles in english and 2.5 million articles in german.
I am a native german speaker (though not from germany), however had I tend to use
the english wikipedia almost exclusively. I just think english is more convenient
to use/write in. But the thing is that I am hardly the only one. I notice that
there is better content and more content in english available. Often we don't
have any sync-between articles, so that english articles often contain more stuff
than the german articles. I would like to suggest that wikipedia does a better
effort to cross-sync articles (and information therein). While I understand
that most of all this is hobby-ist work, perhaps it may be a useful idea to do
quality improvements and even do e. g. patreon assisted work and such. I don't
think this has to be paid a LOT, so it should not be too expensive. The goal
would be that it is synced between different languages. (German is just one
example; evidently there is a HUGE disparity in regards to chinese. So many
chinese people but fewer articles than in german with only 100 million
native german speaking people? So there has to be more content from chinese
contributors; this is also a problem with wikipedia. Wikipedia needs to
broaden and widen its scope rather than have a mostly US-centric view in
some articles, aka some agenda-drivers. I don't want to single out only
US contributors, folks in other countries do this too; it just provides some
context. Anyway, the MAIN point of this is to think about how syncing can
be improved. Right now for me personally, the english subpart is by far
more important than the german subpart or other parts.) 2A02:8388:1602:6D80:0:0:0:1 (talk) 20:16, 18 January 2021 (UTC)
Wikifunctions may one day do this, but probably not anytime soon (I would love to be proved wrong) Meanwhile, though the idea is nice, I don't see how it can be reasonably practicable for the volunteers who work on the Wikipedias to do this manually even for only the two biggest Wikipedias. Perhaps the original poster could explain in sufficient detail how they envisage this project to work, given the editorial independence of each Wikipedia and the differing policies? A rough estimate of hours of work would put it in better perspective. Bear in mind that it would be a requirement that quality is not degraded, so sufficient competence in the languages and topics would be needed. · · · Peter Southwood(talk): 05:28, 19 January 2021 (UTC)
You raise a lot of valid concerns, but unfortunately there are no easy solutions. As for technical articles, WP:JARGON should be avoided, but this can be difficult with a highly technical topic. For some topics we have non-technical introduction articles, like Introduction to general relativity. There is also the Simple English Wikipedia that places special focus on accessibility of language. I think it used to be more popular to "synch" articles by translating them. This remains an option, but people seem to prefer to write in their own words. Translating high quality articles is of course a better idea than translating dubious content. – Finnusertop (talk ⋅ contribs) 05:34, 19 January 2021 (UTC)
Thinking about a radical reduction of talk page banners
I recently noticed how few pageviews the WP:Dispute resolution requests page gets—less than 2000 per month, despite being linked from {{Talk header}}, which appears on more than 500,000 pages. My assumption is that this is yet more evidence of banner blindness, where we try to cram so much poorly-organized information onto the top of talk pages that no one (most of all newcomers) reads any of it.
If you go to a random high-traffic talk page for a reasonably controversial subject, like Talk:Karl Marx, there's just so much low-hanging fruit or obviously non-ideal design.
Going through various things I notice:
The way we present WikiProjects is not ideal, even when {{Banner holder}} is used to collapse them. Every project doesn't need to have its own banner repeating the same line about "a collaborative effort to improve Wikipedia's coverage of X" and giving the same quality rating. It'd be better to just have a single banner (perhaps we could usurp {{WikiProjects}}, which has only 6 transclusions) that'd list out each project and its importance rating, and to move the quality rating to {{Article history}} as something that each page has only one of.
The "this article is written in X English" notice is something that should appear in the editnotice rather than the talk page. We don't need to tell people to use British English in their discussions on the talk page; it's enough to have it when editing the page itself.
There are a bunch of "this is a hot topic" banners, such as {{Controversial}}, {{Be civil}}, {{Round in circles}} (which also typically duplicates the archive search box), {{Not a forum}}, the arbitration notice, etc. Each of these does technically have a distinct purpose, but the cumulative effect of them is just for there to be a bunch of banners all screaming at you. If I were designing from scratch the ideal top of a talk page for a controversial topic, I'd want there to be only one "this is a hot topic" banner that'd cover all of that stuff. It's also already part of {{Talk header}}, so the emphasis should only be needed in extreme cases.
There are some banners that, while providing useful information, shouldn't require a banner of their own. {{Vital article}} is one of these; the {{Auto archiving notice}} is another. I'm not quite sure where the vital article notice should go, but really all that's needed is for it to say Level-3 vital article in People; all the rest, including e.g. If you can improve it, please do is unneeded (there's no reason for reminding about boldness more at VAs than elsewhere). As for the auto archiving notice, that could be rolled into the talk header, looking something like this, which would communicate the same info but take up a fraction of the space.
And then there are the junk banners, such as {{OnThisDay}} or {{Top 25 report}}, which communicate something but not anything most people arriving at the talk page need to be aware of, especially years after the fact. IMO, they should always be collapsed within {{Banner holder}} anytime a talk page has more than a few other banners, but that rarely happens.
I realize I'm throwing out a bunch of different thoughts, some of which could be pursued in isolation, but the larger picture I see is that we ought to move away from our current modus operandi in which each piece of information gets its own banner and instead move to a system in which our core banners are able to incorporate lots of different information and display it in a format where there's appropriate visual weight and no duplication. {{Article history}} has done a great job of this for article quality/milestones, but we need that same effort for lots of different areas. I'd welcome thoughts about how to go about such an initiative, or anything else that might help us address the problem of talk page banner blindness. {{u|Sdkb}}talk04:09, 6 December 2020 (UTC)
WikiProject banners have some affect on a particular database that would need to be tested against before any movement of anything occurs, and some projects have intersecting categories (quality vs priority) that you would not be able to intersect directly any longer if one moved the banners. Many projects additionally put Other Stuff in their banners besides quality and priority and one might wish to investigate how widely used those are. --Izno (talk) 05:15, 6 December 2020 (UTC)
Izno, there are certainly some project banners that function in non-standard ways, but most of these are for non-content-related projects (which are the ones added to article talk pages). To be honest, what I'm proposing probably would require ironing out some idiosyncrasies (e.g. if a project wants to call their importance rating "priority" rather than "importance", that'd probably get lost), but I think on balance it'd be worth it. {{u|Sdkb}}talk05:22, 6 December 2020 (UTC)
What about task forces? Settings for "this page needs an infobox"? Transcluding current activities for GA and such? Etc. Yeah, you're going to iron that part of it out a lot better if that part is to stand a chance of success. --Izno (talk) 05:24, 6 December 2020 (UTC)
Izno, fair enough. I'm coming at this less from a "I've got all the details figured out and want this implemented" perspective and more from a "if I were designing talk pages from scratch, here's what would be different than they look today" perspective. {{u|Sdkb}}talk07:39, 6 December 2020 (UTC)
For Trump, and articles like it, taking a step back and trying to prioritize banners sanely and shoving the routine stuff elsewhere can lead to big improvements. See [4]. Not saying it's perfect, but this is a lot better than that IMO. Headbomb {t · c · p · b}02:03, 10 December 2020 (UTC)
Right, I don't disagree that banners are a mess. I just know WPBanners in specific will be hard to do something about. I think most of the other banners that show up on the talk page are fairly mundane and could all be merged into some equivalent of WP banner shell and not much at all would be lost. (Heck, we could stuff everything into one template, WP banners and all.) As for "are there too many banners on a specific page", if you see duplication in banner intent, or one more specific than another, I highly recommend shipping to TFD or removing the ones you find as being duplicate. --Izno (talk) 18:55, 6 December 2020 (UTC)
Izno, I could try doing a big TfD nom of {{Controversial}}, {{Be civil}}, {{Round in circles}}, {{Not a forum}}, etc., but I'm not sure it'd succeed. Looked at from the more narrow "are there meaningful differences between these or potential separate use cases" criteria we tend to use there, the answer is that there are. It's only zooming out to the larger picture where it becomes clearer that these are having a detrimental effect in the way they're applied 99% of the time. {{u|Sdkb}}talk00:48, 7 December 2020 (UTC)
could try doing a big TfD nom [...] but I'm not sure it'd succeed But why not? Anyway, whether it's successful or not, that's probably a quicker way than waxing over here on WPI. At least one of those banners duplicates (the current) {{talk page}}; I bet we could get the rest integrated into that one too. (And/or as options.) --Izno (talk) 15:24, 7 December 2020 (UTC)
Talk pages banners are a dog's dinner. I think we also have an issue with DS banners, eg Talk:Bill Gates, where people spam multiple DS alerts for the purpose of aiding with awareness, so some of this is complicated by broken underlying systems (something I've discussed with L235 - with any luck the next arb committee might finally fix this particular issue). Further, there's the issue of everyone thinking their banner is "the one" which is important, so it becomes hard to cut down on the blindness once a new banner gets created and over time spurted around everywhere. It's so bad the WMF decided to hide all banners under the small "About this page" text on the mobile version. TonyBallioni once gave me the advice that the idea lab is a breeding ground for dying ideas, though, so maybe collecting together a bunch of interested individuals and figuring out a clear set of strategies and bot operations to reduce this, then putting it forward as a proposal, may be a way to proceed if interest flutters here? ProcrastinatingReader (talk) 11:56, 6 December 2020 (UTC)
I'd love to reduce, or completely eliminate, the WikiEd banners, ("This article was the subject of a Wiki Education Foundation-supported course assignment, between [dates]. Further details are available on the course page") which are big, and tell you nothing. Half of them are on pages which have merely been reviewed by a student, and even those where the article is supposed to be edited are put on at an early stage of the course. A high proportion of the students make no edits, or just minor ones. Some articles have two or more of these. Once there, they never leave.Johnbod (talk) 02:52, 7 December 2020 (UTC)
That result looks workable. You proposed something, someone came up with something else a bit later, and some chunk of the keeps shifted to message rather than full keep. Now we just need someone to file the task to change the behavior in the dashboard... --Izno (talk) 13:35, 7 December 2020 (UTC)
See User_talk:Sage_(Wiki_Ed)#Alteration_of_the_student_editor_template. Let's see if we can work the feasibility out with Sage. This still leaves the issue of all the other assignment banners, though, which predated the current dashboard-inserted template. I guess we can BOTREQ to orphan, and (optionally) add a talk page message at the same time (although, for some courses that ended years ago that may be awkward, but still, serves as a record I guess?). ProcrastinatingReader (talk) 13:58, 7 December 2020 (UTC)
Damm - missed that. The argument editors need warning is a reasonable one. But it should be as a normal talk page section, not forever kept at the top of the page. Johnbod (talk) 16:42, 7 December 2020 (UTC)
For sanctions, you could have one banner with multiple sanctions (both ARBCOM and Community-sanctions) coded in , something a bit like {{Sanctions/talk notice|topic1=blp|topic2=ap|topic3=COVID}} giving something like
articles about living or recently deceased people, and edits relating to the subject (living or recently deceased) of such biographical articles (ARBCOM decision)
pages related to post-1932 politics of the United States and closely related people (ARCBOM decision)
pages related to coronavirus disease 2019 (COVID-19) (Community decision)
Would it be possible to somehow replace some of those templates with some sort of empty template so that pages that use them don't end up with red links but rather simply have the banner disappear?
Another idea: How about a limit on the number of words in all banners combined?
Alternative: How about some sort of bot that goes through every page and creates a list of all pages with more than X words, with pages with the wordiest template collections at the top? (what page does have the largest banner section?) --Guy Macon (talk) 01:09, 10 December 2020 (UTC)
What's the "redlink problem" exactly? The only banners that have redlinks in them, to my knowledge, is stuff like prompts to create a GA subpage when starting a GA review. Headbomb {t · c · p · b}01:37, 10 December 2020 (UTC)
So you are saying that we can just delete a banner and the pages that have that banner on them will not have redlinks? Let's try:
Again, instead of deleting those banner templates, would it be possible to somehow replace the templates with empty template so that pages that use them don't end up with red links but rather simply have the banner disappear? --Guy Macon (talk) 20:54, 12 December 2020 (UTC)
Again, I ask, what exactly is the "red link problem"? If there's a non-existent banner on a page, just remove it. Headbomb {t · c · p · b}03:42, 13 December 2020 (UTC)
And again I answer, deleting a banner is easy. Deleting a banner that is used on a lot of talk pages is an effective way to accomplish a "radical reduction of talk page banners". Some of these banners are used on 500,000 pages. That makes it a red-link problem if the banner is deleted. Saying "If there's a non-existent banner on a page, just remove it" is not a solution unless you, personally, are willing to make a commitment to "just remove" all 500,000 redlinks. Again I ask, (if you can please refrain from derailing my question by once again replying with claims that the problem does not exist when it obviously does), would it be possible to somehow replace the templates with empty template so that pages that use them don't end up with red links but rather simply have the banner disappear? Headbomb, please let someone else answer my question. We are all well aware that you think that the problem does not exist and that I think it does. --Guy Macon (talk) 18:54, 16 December 2020 (UTC)
And AGAIN, I ask, what exactly is the "red link problem". Where is it? Do you have examples? You still have to substantiate that there's a plague of redlinks on talk pages which are somehow problematic. Headbomb {t · c · p · b}21:23, 16 December 2020 (UTC)
I am going to stop replying to you now per WP:CIR. If you can't grasp the difference between saying that if certain templates are deleted this will cause a redlink problem and saying that the redlink problem already exists, I am afraid that I cannot help you. Feel free to get in the last word. I will not respond. --Guy Macon (talk) 23:39, 16 December 2020 (UTC)
So wait, your problem is that if hypothetically, you deleted a banner used 500,000 times, it'll have 500,000 links red left behind? The solution to that is to either to a) not delete a banner obviously in extensive use b) convince the community the banner shouldn't be used at WP:TFD and use bots to remove it or c) mark the banner as historical and simply have it display nothing. Headbomb {t · c · p · b}07:33, 17 December 2020 (UTC)
I don't see this as a problem. I find the banners play a role similar to that of my unabridged Webster's 2nd, my Columbia Encyclopedia, and my bilingual dictionaries: I don't pick up one of those tomes every day, or even every month sometimes; I walk by them all the time without even seeing them; but they are there whenever I need them, and it's extremely annoying if someone has misplaced one of them and I can't find it when I need it. Ditto many of the page banners; it's mightily annoying if they are not there when I want them. Slap a {{skip to bottom}} template at the top of the Talk page, and you're done. What exactly do you want to do on a Talk page, other than to view the ToC, go to the bottom of the page, or click a notification that takes you straight to the discussion in question, for which banners are an impediment to doing what you want? Mathglot (talk) 08:17, 12 December 2020 (UTC)
This is not a good analogy imo. Partially because the reference books aren’t impeding the entrance, but mostly because you’re vaguely familiar in your head where the books are and what they’re for. A new editor seeing this wall of banners doesn’t even know what they’re missing! Do they click skip, or do they read all the big alerts saying warning/caution/controversial etc, maybe in them some information they need? You and I have the knowledge that it’s all junk so we don’t read it, but they don’t even know yet. Hey, if you want to edit skip to talk with “All the below is junk. Just skip to talk.” In big bold letters and add it auto to pages, then I guess the solution is not so bad. ProcrastinatingReader (talk) 09:53, 12 December 2020 (UTC)
It's really great to see that this conversation is taking place. I strongly disagree with Mathglot because this is a problem that I think ruins the accessibility of a lot of talk pages, especially the ones where the talk page matters the most such as many of the examples given above. I agree with the shortening of the vital articles banner. The template for British vs American vs Hong Kong vs Indian etc English is utterly useless on the talk page, and has little to no effect on the vast majority of issues that arise here (random editors coming in to change a "misspelling"). This definitely needs to be as an edit notice and not the talk page. In fact, I wonder if this could be configured so that if it's placed in the talk page it doesn't show up there put shows up as an edit notice on the article page – so that we wouldn't have to go through and change/remove all of them, though I suppose a bot could do this. Aza24 (talk) 01:55, 14 December 2020 (UTC)
An ideal banner would a clear importance, audience, and process. Banners detract from an article; they are at the top, but are not crucial for the reader. Their purpose is to flag that work needs to be done, but for the majority of readers this is unimportant; only editors need to be warned about BLP. The process to do with each banner is unclear; there is not a clear call to action, sometimes "drive by" editors add them with no explanation on the talk page, no clear ownership of banenrs, banners suggest talk should take place on pages with no watchers, and the numbers do not appear on project pages. My preference would be that banners disappear for all except editors, that banners be clear and simple, and that bots are used to make them expire Wakelamp d[@-@]b (talk) 08:57, 14 December 2020 (UTC)
Wakelamp do correct me if I'm wrong, but I think you're confusing cleanup/maintenance templates (see WP:CLEANUPTAG) on the articles themselves with templates (banners) on the talk pages of articles (the topic of this discussion). Aza24 (talk) 09:06, 14 December 2020 (UTC)
Aza24 You are correct. I am confused. Excuse my rant about the article template :-) My suggestion for talk pages. I don't actually read them. Many are advertisements for projects, or about the status within a project. Wakelamp d[@-@]b (talk) 12:43, 14 December 2020 (UTC)
Talk:Karl Marx is fine now. Some of the areas causing problems have been missed in this discussion.
GA drops in templates instead of building articlehistory. DYK drops in templates without integrating them to the articlehistory template. OTD drops in templates rather than building articlehistory. ITN drops in templates rather than building articlehistory. Vital articles drops in templates rather than placing them in the WikiProject banner shell. I have approached the bot about Vital articles, and that is being addressed. The problem with the other templates being dropped in is that a prolific sockmaster hounded the editor off the project who used to run a bot that processed every single template on talk that related to the articlehistory in to that template, so I have been running around doing that work manually.
If those issues were addressed, and editors would simply clean up talk pages as I have been doing now for several months, we would see that the problem isn't as bad as it appears and not nearly as bad as it was before Gimmetrow and DrPda initiated the effort to tame talk clutter in 2007. Skip to talk is rarely needed, the duplicate archive boxes can often be deleted, and the useless templates like WikiEd and English variety can be rolled in to a banner. The real problem is the need for a bot to clean up articlehistory items, as I have been doing on FAs. (Karl Marx: Projects to banners, OTD to article history, banner holder for English variety and archive info, remove one that is essentially duplicated in talk header, and now skip to talk is no longer needed.)
The discretionary sanction banners can be dealt with by electing arbs who will deal with editors with behavioral problems rather than pushing problems off to other admins via DS. It is astounding that what one bot did over a decade ago to tame talk clutter is no longer being done; surely our coding ability has advanced since 2007 ? Apparently this work I have been doing for several months now is well received, as I am not aware of having been reverted even once. Surely some clever bot or script person can do this work; they once did. SandyGeorgia (Talk) 15:05, 15 December 2020 (UTC)
@SandyGeorgia: interesting, and thanks for your thorough comment above! Is there a bot proposed to take over the work of GimmeBot, or is anyone working on this atm that you know of? Have any of GimmeBot's functions been replaced by another bot, or has it created a void? Regarding Vital Articles, do you think we could get a consensus to scrap banners for level 4/5, leaving just levels 1/2/3 having talk page banners (1110 pages I think)? ProcrastinatingReader (talk) 04:18, 30 December 2020 (UTC)
Responding to ProcrastinatingReader's query above, with a broader summary of what I have found after several months of working to tame talk page clutter on Featured articles.
What I have done for several months now is to go through every current FAC, FAR, PR, TFA or OTD that relates to an FA, to clean up those talk pages. I am unsure if my observations will apply equally to non-FAs, for example GAs, as I have not attempted to clean those up. My guess is that talk pages of non-FAs are in much worse shape since we lost Gimmebot, because no one is building articlehistory at all on GAs (Gimmebot once did).
In terms of the specific questions asked, no, I don't believe that scrapping levels 4/5 will solve the Vital articles problem, because the problem is simply a failure of Vital articles to wrap their templates in the Banner shell, just like every other project does. Independent of the number of articles where they have done this, the issue of dropping the template anywhere, not reviewing the talk page for the mess made (see this talk page after Vital articles template added), and not using the WikiProject banner at all is the one that should be addressed, whether on hundreds of articles or thousands.
In terms of taking over the work that Gimmebot once did for every template on every article, I'll give an area by area summary of what I know below. What I don't know how to deal with is the problem that we need one bot to clean up after the messes now made by quite a few other bots, so some level of bot coordination will be needed here. I am unwilling to take that on, as I have found many of my interactions with bot operators to be highly frustrating and often unproductive. MOST of my cleanup work has involved putting Vital articles in the {{WPBS banner and merging OTD, DYK, GA and ITN templates (dropped in by different bots) to the consolidated Template:Article history, which was designed over a decade ago for this very purpose, but has fallen into neglect without Gimmetrow/Gimmebot.
WikiEd banners.
Yes they are a problem, but no where near the scope of the other problems I have seen. (It is possible that my sample is distorted, because students are discouraged from editing FAs, so I may be missing the extent of that problem.) WikiEd Banners provide an essential function wrt medical editing at least, and are easily dealt with. I left my feedback on that at the talk page of Sage (Wiki Ed).[5] Basically, I have (literally) never encountered medical editing from a student that did not have considerable errors, and we need to keep those templates on talk until someone has had the opportunity to check the work and remove the errors. When I encounter an old student editing template on talk, I check to see if they actually edited the article (most of the time, they didn't). If they didn't, I just remove the template. If they did, and the errors were later corrected by someone else, I just either archive the template as a talk page section, or move it into a banner. If the errors need attention, the banner needs to stay.
Skip to talk. Related to DS template.
In my experience with cleaning up, there are extremely few (a couple maybe?) instances where the Skip to talk template is needed post-cleanup. The few occasions where I have left it are typically when there are multiple discretionary notices on the talk page, resulting in considerable bloat and length. And yet ... it seems quite odd to me that we are encouraging possibly new readers to skip over a discretionary sanctions template, as it is so important that new editors understand them. On the other hand, in my own editing, I find that new editors rarely read the DS templates anyway, and have no idea what they mean. And, in my own editing area, an Arbcase resulted in sanctions being applied to an entire content area (drug prices), only because the Arbs were reluctant, for understandable reasons, to fully sanction only three editors who were not editing according to policy. An entire content area subjected to DS ... for three editors. So, solving the problem with Discretionary sanction templates involves addressing what measures the community believes are most effective in dealing with disruptive users, and how that is reflected in their ArbCom voting. In terms of the talk page templating, this is beyond my pay scale, but DS sanctions add considerable bulk to talk pages, that can't be rolled in to a banner, and may be lost in the clutter, or missed because of skip to talk.
Why are these there at all?
There is a whole list of useless banners whose purpose escapes me. Variety of English is flagged in articles, why also on talk? Pageviews are available on articlehistory tag, yet result in some of the most unsightly templates ever on talk. Who is adding this stuff ? I roll them in to
Other talk page banners
so that if they are serving some purpose (categorization?), they are still there. Separately, Calm, Not A Forum, etc are often no longer even applicable; that requires manually checking that the talk page has calmed down and removing those templates-- not something we can assign to a bot.
Talk header and duplicates
The talk header template now includes searchable archive by default, and how to find sources. So, unless they are highly customized, I delete duplicate archive boxes and duplicate find sources templates. And I move the talk header template to the top of the page.
Projects
Not only Vital articles, but some other projects have rarely been rolling their templates in to the WPBS shell and can be ... for example, Spoken Wikipedia and the old WP Version 1 templates and Some Portals. A bot should be able to go back and get all these things and stick them in a WPBS shell, and by the way, collapse that shell, since WikiProjects simply don't have the prominence they once did, and talk pages need room for more significant templates (like DS). Here is where things stand with Cewbot run by Kanashimi. The Vital articles project is so decentralized that there appears to be no there there. To such an extent that right now I am unable to even locate the conversation I had with User:Sdkb somewhere recently about how to get this problem addressed. Apparently there is not even a centralized talk page, because I can't find where we had the conversation. If this can be addressed, it will probably need to be part of the whole problem of getting all of these bots on the same page.
Forgot to add that GOCE almost NEVER rolls their banners in to the WPBS shell, and I also have to do a lot of those. They also tend to drop them in anywhere, similar to Vital articles, with little regard to the layout of the talk page. SandyGeorgia (Talk) 21:04, 1 January 2021 (UTC)
The number of problems requiring a new and centralized bot effort, akin to what Gimmebot did, get worse when we got in to GA, DYK, ITN and OTD, as I will lay out next.
FAs
In general, FAs are in a bit better shape than others probably, because Hawkeye7's bot, FACBot, does convert FAC and FAR templates to articlehistory. But, best I can tell, there was a time period when that bot did not convert all other templates, and it still doesn't convert all other process templates, so miscellaneous cleanup is often needed. Gimmebot rolled ALL content review processes, AFDs, ITNs, OTDs, etcetera in to one template. That is what we are missing today.
ITN
I don't have enough samples to go by there; I just roll their templates in to articlehistory when I find them. If we somehow replace Gimmebot, they can all be addressed.
OTD
Is The Worst. Best I can tell, the bot procedures have changed over time, so one finds all kinds of inconsistencies in terms of what is added to the articlehistory template and what is not, and fixing these is hugely time consuming and no fun, partly because of the infuriatingly frustrating disconnect between how Template:Article history handles multiple entries, and how the OTD bot adds them. Article history uses the parameters ... otd1date, otd1oldid, otd2date, otd2oldid, and so on, while OTD uses otddate1, otdoldid1, otddate2, otdoldid2, etc. Imagine the work to convert those to articlehistory manually! WHY can't we use the same convention on the number x? Again, lack of centralization in how we handle content processes that were once routinely handled by Gimmebot. In attempting to figure out to whom one speaks to get this addressed, I've discovered there is also no overall OTD process or page, rather one goes to Howcheng on this.
DYK
The second worst. Why oh why do they use the parameter nompage= for their talk page template link to the nomination page, while Article history uses dyknom= ?? This means the DYK nomination page has been lost in many article history templates, and I am having to go back and recover them-- usually by manually looking them up. Could we all get on the same page? A whole separate bot is needed now to go back and replace lost DYK nomination pages in article history. I have found and fixed scores of them already.
GA
Not rolled in to article history at all, best I can tell. GimmeBot once did. This can be hard work because not all GA reviewers know how to use the subst template correctly when closing, and fixing a malformed GA pass means a whole ton of digging in to history to find the missing information.
PR
Exactly the same as GA.
FAC, FAR
While FAC and FAR templates are converted by daily bot runs to articlehistory, the formatting is inconsistent and confusing. I clean up every one of them every day; my hope is that if we make the articlehistory entries consistent, clear and less confusing to the average editor, others will begin to understand how to use that template to do their own cleanup. So, just as Gimmebot did, I make sure the events are in order, there is a space between each event, and the current status is listed at the head of a section at the bottom which is then followed by dates (maindates, OTDs, ITNs, etc). I believe that consistency will make the article history more understandable to more editors. Also, FACbot for some reason is not adding |currentstatus= FFAC .
So, to get ALL of this cleaned up will require someone to get all the bot operators to talk to each other, and for someone to write a bot that does what Gimmebot was doing more than a decade ago ... rolling every process in to the articlehistory template, while also rolling projects into collapsible banners. SandyGeorgia (Talk) 20:50, 1 January 2021 (UTC)
Thanks, this is a very helpful rundown! It makes it clear that what we have is really two separate problems, each of which is significant: (1) figuring out what design would be optimal for talk pages, and (2) getting everything working on the technical/bot side so that pages end up looking the way we want them to. {{u|Sdkb}}talk01:15, 2 January 2021 (UTC)
FWIW, I'm about to start a TfD discussion on collapsing the WPBS by default. Slightly unconventional, but these widely advertised discussions generate more accurate gauging of "consensus" wrt templates imo. Even the "After" image is too much imo, the WikiProject banners take up over half of the image! ProcrastinatingReader (talk) 12:13, 8 January 2021 (UTC)
Initial questions: first I'd like to know where we're currently at with this:
From the BOTREQ, and on GitHub, I see Enterprisey has been working on something related. @Enterprisey: are you still working on this, and if so how much of the stuff above do you intend to cover with your bot?
What bots are active in this area? It doesn't help that we have no organised collection of what bots do what recurring tasks. It'd be helpful to know exactly which existing bots are doing things which may overlap with a 'super-bot' to take over GimmeBot's tasks. Which of FACBot's tasks is editing article history? What's the name of the bot doing the OTD stuff?
Some design questions:
If a talk page only has a single DYK/GA/etc template (eg 1 DYK nom, nothing else), can we still convert that into {{Article history}}, or do we need multiple templates to do this? eg could this page (only one template - OTD) be converted to {{Article history}}?
Can vital article status be indicated in {{Article history}}? e.g. add a sentence "This article is a level 2 vital article in People, Sports." and then delete {{vital article}}?
No one has suggested lumping Vital articles in to articlehistory; this discussion is about talk page clutter, which comprises many different issues, of which Vital articles is one, articlehistory events is another. SandyGeorgia (Talk) 20:54, 1 January 2021 (UTC)
Oops, sorry, I see PR did suggest that. Bad idea. Vital article status has nothing to do with anything ... at all. It's a passing fad. It doesn't belong in article milestones; it is exactly like any other WikiProject, and belongs in the WikiProject banner shell. SandyGeorgia (Talk) 21:00, 1 January 2021 (UTC)
I agree vital articles should not be taking up an entire banner by itself, but I wouldn't say it's "exactly like any other WikiProject", and I don't think the project banner holder is really a great place for it either. An article having vital status is a useful indication of its importance, which is different than just saying "this page relates to this content topic". The top-to-bottom overhaul of talk page banners I envision would find some better way to note which non-content projects relate to a page and how they have interacted with it. {{u|Sdkb}}talk00:58, 2 January 2021 (UTC)
PR, I am not entirely sure what Bot does what, as they seem to change over time. Cewbot does Vital articles, FACbot does FACs and FARs. Yes, we certainly need a list of who does what, and who does one talk to about what. I struck out with finding any centralized place to pull in either OTD or Vital articles. SandyGeorgia (Talk) 21:00, 1 January 2021 (UTC)
Yes, one DYK can be converted to articlehistory, but it's not very useful to do (in terms of talk page clutter). I am fairly certain, although I could be wrong, that by hitting all GAs, you get the bulk of the cleanup needed. BUT ... I left out the fact that GImmeBot also processed in AFDs, which are not being done now. SandyGeorgia (Talk) 21:00, 1 January 2021 (UTC)
I was working on it quite a bit in October, but shinier things distracted me. At the moment, the code looks like it just supports DYK, ITN, OTD, and XFD (i.e. merging them into {{Article history}}). The rest of the templates are totally doable, it's just tedious figuring out precisely how the other templates fit into the {{Article history}} format. I think the remaining templates are DYK, GA, FAC, FAR, PR, and everything else that both has its own template and is supported in {{Article history}}. If an expert on those templates wrote a little guide on how to convert each into the {{Article history}} format, or just linked some diffs showing the conversions being done, that would help. Enterprisey (talk!) 00:20, 2 January 2021 (UTC)
Enterprisey I do dozens a day. Where do you want me to put samples? Give me a workspace, let me know exactly what you want and where to put it, and take note that I don't get along with the pingie thingie at all. Also, it's not only a matter of samples, because there are boatloads of issues created by all the different bots that will need to be sorted. Gimmebot had gotten things to a point that there weren't so many exceptions to be dealt with, but if you get something going, you are going to initially find a lot of errors kicking out, so we need a place to work together, as I used to have with Gimmetrow. Please post to my talk page. Best, SandyGeorgia (Talk) 00:25, 2 January 2021 (UTC)
A whole 'nother separate but related issue is that GOCE needs to be removed from Template:Article history. That, too, is a WikiProject, and their template goes in banners. GOCE hitting an article doesn't really belong in articlemilestones. That an editor who happens to be part of one WikiProject goes through and copyedits an article is no different than any non-GOCE editor copyediting an article, and is not a community milestone. SandyGeorgia (Talk) 21:05, 1 January 2021 (UTC)
Though I suspect most people adding {{skip to talk}} aren't thinking about editors using screen readers, it's an accessibility aid for them. Once they've listened to the headers once, it's helpful to be able to skip to the main content of the page. isaacl (talk) 21:52, 1 January 2021 (UTC)
I dislike the {{Article history}} template. It seems quite fiddly and unfriendly to use and it hides information which editors are supposed to look for in some circumstances, such as previous AfDs per WP:BEFORE. It badly needs an option to display the history with one line per entry, as is commonly done with {{WPBS}}. More generally, the idea that talk page structure should be made uniform seems quixotic. The WMF have technical plans of their own for discussions and talk, as I suppose they still consider it too unfriendly for the general public. And getting editors to agree across six million articles seems unlikely. Andrew🐉(talk) 16:55, 10 January 2021 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
I mentioned this above, but am still baffled by it. Is there any reason that the English variety appears on talk pages? I don't know how this could ever be effective, since I'm sure those who are disregarding this the most aren't going to see it on the talk page. Surely these could be converted to an edit notice; which would be significantly more effective? Aza24 (talk) 23:54, 6 January 2021 (UTC)
Editnotice-only would be the best approach imo. We need to know that information when editing the article, people don't go onto the talk page for it. I usually just infer from the presence of {{use dmy dates}} or something, myself. I note that these cannot be seen on mobiles, but then again talk page banners are hidden too. ProcrastinatingReader (talk) 09:03, 7 January 2021 (UTC)
I am equally baffled by these on talk. Mostly, it is experienced editors who use talk pages (relative to IPs or drive-by editors, who may not even go to talk or know what it is), and experienced editors know where to find English variety in article templates, so I do not see what purpose these are serving on talk. (That is, I agree with Aza24 that "those who are disregarding this the most areen't going to see it on the talk page".) Especially when they get lost among the clutter. Similar to the proliferating pageviews templates. Similar to the "this article appeared at such-and-such portal". And so many others ... SandyGeorgia (Talk) 16:13, 8 January 2021 (UTC)
I suspect this simply predates edit notices. Agreed this would be useful as an edit notice, having it on the talkpage is about as much use as a chocolate teapot. ϢereSpielChequers21:57, 8 January 2021 (UTC)
I was just thinking this. It seems pretty clear that they are in the wrong place. Aside from the technicalities of implementing this, I can't imagine why anyone would object to shifting this over. --Paul ❬talk❭ 11:54, 9 January 2021 (UTC)
The way to test this would be to TfD all the talk page notice templates, stating that a bot will add the equivalent editnotice before deletion if not already existing. We do have a tendency to support the status quo, though. ProcrastinatingReader (talk) 12:45, 9 January 2021 (UTC)
Couldn't the bot just move every instance of the template (assuming consensus to do so), so that was nothing is "getting deleted"? {{British English}} already says may be included on talk pages or editnotices - so the only change being suggested here is a change to how we use the same template. --Paul ❬talk❭ 16:38, 9 January 2021 (UTC)
It appears, Paul, that these matters are not as simple to resolve as those following this discussion would hope; to wit, ProcrastinatingReader's observation about the "tendency to support the status quo", relative to ongoing discussions about template clutter on talk. When discussions about changing, improving, deleting templates to address the talk page clutter problem have come up, status quo is being supported. ProcrastinatingReader, perhaps a bigger-picture approach to educating more editors about the issues would help? I am thinking of something like Wikipedia:Wikipedia Signpost/2008-03-24/Dispatches. Perhaps the growing clutter is just not something most editors are aware of. SandyGeorgia (Talk) 16:48, 9 January 2021 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Signpost
Responding to SG's Signpost idea, I think that's a great idea. The 2008 piece is very well written and evidence based. I think we can deal with article history with a bot - no need for additional consensus, really, as it's in line with the docs and precedent, and we already have an existant authorised bot (GimmeBot) for this purpose. But I imagine talk page clutter has gotten more disparate and worse since 2008 as well, with a lot more templates being spammed around (just one example: the controversial, round in circles, etc., templates), so there's probably different things to talk about now. Overall I think that's a great idea to raise awareness on all issues relating to this, especially the newer ones, and also get our heads down and think long term and more broadly on this. ProcrastinatingReader (talk) 11:21, 11 January 2021 (UTC)
The credit for the “very well written” 2008 piece goes to the efforts of one of Wikipedia’s finest writers, User:Tony1. If you want to communicate something well to a broad audience, he is key. The Signpost is not so widely read anymore, so more thought could go in to how to get this message out, but getting something written up first would be a good start. Prose is not my strength, and brevity is not the soul of my wit. With the series I used to run in the Signpost (Template:FCDW), I would lay down facts, and Tony1 would smooth the writing. Or someone else would write them, and then Tony1 and I would go through ... SandyGeorgia (Talk) 14:35, 11 January 2021 (UTC)
Also, ProcrastinatingReader, I don’t speak bot, but my understanding—since Gimmetrow was chased off by a prolific sockmaster and another habitually rude and ill-tempered FA writer—is that we do not have the code for Gimmebot, and no one has yet replicated it fully, ten years later. SandyGeorgia (Talk) 15:19, 11 January 2021 (UTC)
Yeah, it appears we do not have the code. It seems based on this someone emailed to ask about it, but didn't get it / Gimme is inactive now unfortunately. This doesn't matter too much, as it seems Enterprisey is working on rewriting it, but the previous approval of Gimmebot helps as a show of consensus for the bot when it goes through BRFA, since GimmeBot is still authorised for the task (its BRFA is not revoked). Prose is not my strength also, but data collection I can do if needed. As for Tony1, I recently stumbled across their essay User:Tony1/How to improve your writing. Looks like they have some other gems in their userspace, too. I wonder if they may be interested in rewriting the DS templates in English :D -- they seem to be in desperate need of simplification and rewriting (one such discussion here) ProcrastinatingReader (talk) 15:42, 11 January 2021 (UTC)
I don't feel that wordsmithing is dependent on any one editor; I know there are plenty of editors who can polish a draft. The bigger issue is that it's hard to get editors to stop doing something they really like to do, particularly in a tragedy of the commons situation. isaacl (talk) 00:04, 14 January 2021 (UTC)
You could, or you can suggest it run and decide later if you want to update it; the point of that column is to rerun them as they were, and since it's topically if not exactly relevant... --Izno (talk) 18:57, 11 January 2021 (UTC)
Auto expiry
What do you think of having certain talk page banners expire after a long period automatically? For current event, not a forum, calm, controversial etc. Additional fields could be added for when an editor doesn't think that it should expire for whatever reason. --Paul ❬talk❭ 06:55, 11 January 2021 (UTC)
Paul Carpenter, that's an interesting thought! Something similar came up recently at a recent TfD discussion about the Wiki education banners. Ultimately, the view we came to was that often, when the desired behavior is for a notice to be posted to talk but not to stick around indefinitely, the best solution is to convert it to a talk page message rather than a banner. {{u|Sdkb}}talk11:14, 11 January 2021 (UTC)
I like it; as I am cleaning up talk pages on FACs and FARs, those are the ones that require time to investigate as to whether they are still needed. And I find they are still hanging around on pages that have had no posts for months or years. But not WikiEd banners, for the reasons I have laid out elsewhere. Until someone has been able to check for student errors and remove inaccurate medical text, those provide an essential alert, and can then be manually archived. SandyGeorgia (Talk) 14:29, 11 January 2021 (UTC)
There's a hint of irony here, actually. Banner blindness so bad that the solution for "important" notices is to repeat the message 5x in an aim to get the point across. And thus propagating the clutter even more. ProcrastinatingReader (talk) 21:45, 15 January 2021 (UTC)
I like that when there are so many important banners that no one will want to bother with them, they add a handy button at the top to let you skip past them, they being so important and all. EEng07:11, 17 January 2021 (UTC)
I'll do you one better, ProcrastinatingReader, your point is made embarrassingly true on this page – it's hideous, and perhaps the closest to insanity I've felt looking at a WP page... I tried to clean it up a bit but have no idea which banners are actually needed (though I just asked a user who edits there a lot to take a look). SandyGeorgia, that revision can perhaps be your new example of how bad awful talk pages can be... :) Aza24 (talk) 06:17, 17 January 2021 (UTC)
From the Templates for discussion about collapsing WikiProject Banners, it is clear that many editors simply do not understand how bad the problem is. We need an article, Signpost or otherwise, that can be widely circulated to educate, and we have now two good examples upon which to base the article. I am too far behind in my routine work to be able to start that article, and have too many typing/bad back issues to be able to write the whole thing, but the mold is right there in the old article. SandyGeorgia (Talk) 12:58, 17 January 2021 (UTC)
How are our conduct dispute resolution systems working for us? How can they be improved? (This is an opinion-soliciting discussion, not a proposal to vote on.)
I think the answer to the first question is "not very well", and I'm not sure of the answer to the second question, but I think it would be useful to gather opinions about and discuss what the community can do to improve conduct dispute resolution. Is there a problem, and if so, where? Levivichharass/hound21:34, 10 December 2020 (UTC)
As I have written previously, there are challenges with collaborative, online decision-making:
A small number of voices can dominate conversation, drowning out others.
Circular arguments, repetition of the same points, and irrelevant information, including overly-emotional appeals and personal criticisms, cause people to lose attention.
Agreeing upon appropriate criteria to bring the discussion to a conclusion can be difficult.
English Wikipedia's unmoderated discussions have additional challenges:
Participants can write unduly long responses that in a face-to-face conversation would be controlled through appropriate interruptions.
At any given time, immediate responses are only possible by those in neighbouring time zones. This reduces the efficacy of dialogue.
Also the voices heard are only a small, self-selected sampling of the entire community. Even amongst those who are aware of the conversation and are motivated to participate initially, there is a large percentage who do not have sufficient interest to maintain engagement throughout the entire discussion.
I've also written about the problems with using consensus as a decision-making approach in a large group. When an entire group is strongly aligned in its goals, consensus decision-making can be effective in maintaining a unity of purpose. Unfortunately, as a group increases in size, it also becomes increasingly unlikely that all members will be strongly aligned. Consensus decision-making favours those who are less accommodating over those who are more accommodating, and so Wikipedia's discussion environment selects for less collegial editors over more collegial ones. Asking for proof with on-wiki diffs that it is the more collegial editors who are leaving is a catch-22: first, it would not be collegial to discuss someone else's lack of social graces; second, most people who stop posting to a web site just do so, without bothering to tell anyone about it.
Wikipedia's group-discussion process gives additional weight to the most outspoken editors and gives incentive for uncollaborative behaviour. As I've discussed at User:Isaacl/Community/Fostering collaborative behaviour and User:Isaacl/Community/Content dispute resolution toolbox, we should be trying to craft our processes and procedures so they reward desired behaviour, and make undesirable behaviour a losing strategy. For example, providing mechanisms to resolve content disputes in a semi-binding way (perhaps with a revisit respite) would encourage everyone to work towards a best-compromise solution, as opposed to trying to win through repetition and participant attrition. Improving content dispute resolution so it is more effective and doesn't reward poor behaviour will reduce the need for conduct dispute resolution. isaacl (talk) 22:22, 10 December 2020 (UTC)
I think "not very well" is a fair summary. I've been looking at two difficult situations recently. I don't feel like we have a system that handles either.
Situation one: Two editors disagree with each other. Both have been blocked for edit warring; one has gotten in trouble for socking. The main pattern seems to be that Editor 1 tries to add content and/or a source to an article, and Editor 2 shows up to revert it and to say that everything Editor 1 does is wrong. For example, Editor 2 will declare that Editor 1's source is wrong because a different source holds a different POV, or that Editor 1 misrepresents the source by writing in his own words instead of posting a copyvio from the cited source. In one recent dispute, a book was quoted that said something like "<subject> has four parts, namely 1, 2, 3, and 4", and Editor 2 went on at very great length about how the source does not say that either 3 or 4 have any connection whatsoever to <subject>. If he weren't so loud and angry about it, multiple times over, you'd have laughed over that, because the alternative is to cry and then earnestly recommend that he talk to his doctors soon. I've started wondering this week whether there is some real-world professional bad blood between these two people. There doesn't seem to be a way to make them stop.
Situation two: An editor tries very, very, very, very hard. He is also very, very, very, very literal-minded. He really, truly, absolutely does not understand why people are upset with his editing, which mostly seems to involve blanking verifiABLE, already-cited, and otherwise suitable and appropriate encyclopedic content on the grounds that the sources are, in his opinion, "unreliable" for anything at all. His idea of "unreliable" sources includes more than one source that is listed at Wikipedia:Reliable sources/Perennial sources as being generally reliable. I think it may be a case of black-and-white thinking: if scholarly sources and mainstream news media are generally reliable for most/general purposes, then that means that almost all other sources (e.g., primary sources, government reports, commercial websites, sources speaking about themselves, etc.) must be unreliable, right? He genuinely does not seem to understand why people yell at him. He also seems to expect that if you tell him to stop doing ____, then you will list absolutely every single possible reason why ____ is bad and against policy. If he understood and agreed with the reasons, then I think he'd stop, but I haven't actually seen that yet. I've only seen him tell everyone that they are bad and wrong and that Policy Says™ that he should keep blanking already-cited content left, right, and center, and that anyone who wants to restore it needs to cough up sources that meet his idea of reliability. Also, If you only tell him the top three reasons, and he doesn't agree with one or more of them, then he'll continue screwing up articles and will be upset when you point out that there are 97 other reasons why he should stop it. You're supposed to present all hundred arguments the first time and repeat all of them each round, as if it were a Lincoln–Douglas debate format, or they don't count.
In the first situation, I don't know how to stop it. In this specific case, there's a chance that the two editors know each other, so they might be able to settle this themselves, off wiki. What we need, however, is something that changes the incentives.
In the second situation, we may be dealing with the limits of Wikipedia:Competence is required, and maybe we just need a somewhat less sympathetic or optimistic admin corps. OTOH, it's never any fun to play the heavy in these situations. Nobody relishes telling an editor that we know he doesn't understand why people are upset, we know he has not received an explanation that will ever WP:SATISFY him, we believe that he'd be willing to change if only he could understand – but he can't, so we're showing him the door.
These situations with recalcitrant editors are why I don't like to edit articles that don't have a lot of watchers or an active associated wiki project. Every edit has the sword of Damocles hanging over it: without warning it can turn into a protracted, seemingly endless discussion, no matter how trivial the edit. And even when there is an active associated wiki project, if you can't draw their interest in responding to the discussion, the conflict will remain unresolved. Both of these cases could bebefit from a revisit respite to reach a semi-binding resolution. This would free up the other editors, while unfortunately imposing an added burden to the closing administrator. I know no one like to tell someone a difficult truth; I don't like to do it either. But uncooperative editors is one of the key reasons I have difficulty getting motivated for editing articles, and I'm sure I'm not the only one. If we can't deal with editors unsuitable for collaborative projects, then we continue to provide incentives for poor behaviour rather than desired behaviour. isaacl (talk) 20:51, 16 December 2020 (UTC)
Isaacl, I tend to agree with you, although I'm often surprised by which articles are difficult. Closely watched articles might blow up over nothing, but editors can also provide a moderating influence. I think that having more watchers would make the first situation better, as it wouldn't always be the same couple of people.
I don't know if the second can be resolved without a Wikipedia:Competence is required-type ban. There's no single article or subject. We also send mixed signals to people who believe that they are defending the encyclopedia from garbage. If you post something like "you don't know what you're talking about and I bet you're a paid shill for that company", then you can expect an equal amount of bouquets and brickbats. WhatamIdoing (talk) 03:25, 5 January 2021 (UTC)
Yes, I prefer editing pages with lots of watchers because there's a better chance of issues getting resolved, one way or another. I have raised the desirability of sorting out uncollaborative editors more rapidly (as have many other editors, such as TonyBallioni). I wrote down one way to do this in my list of ideas to foster collaborative behaviour—active mentorship for new editors who are not adopting community behavioural standards—but I haven't done any further follow up, as I'm not able to construct a plan that would surmount the sizeable challenges. (Due to the large time investment required, multiplied by the rate of new proteges, I think it will require hired staff, which I imagine won't happen without some level of consensus, and that is a showstopper for any significant change, and anything requiring paying people.) Another way would be to empower some group to make decisions about the promise shown by new editors, but I don't see a lot of support for that at present, either. isaacl (talk) 05:24, 5 January 2021 (UTC)
I think that ANI could benefit from more structure. Rules like those used at DRN and AE would make it easy to clamp down on unproductive cross-talk and mudslinging, as well as making discussions easier to parse at a glance and thus reducing the amount of discussions that go stale without resolution. It can sometimes be unclear whether an admin is a party to a conflict or offering opinions as a neutral arbiter: a more formal demarcation of roles in a given discussion would help clarify the process for editors with grievances and save potential closers from potential flak. signed, Rosguilltalk05:58, 17 December 2020 (UTC)
@Rosguill: I like this idea. Do you think just simple involved/uninvolved sections, or more specific (like one per user, as in arb pages), or depends on the thread? Who would decide which threads should be sectioned and how—obvi admins would have final say, but can the filer? the responder? any uninvolved editor? Levivichharass/hound03:43, 15 January 2021 (UTC)
Levivich, in my experience in conduct boards, nothing good ever comes from the parties to the dispute interact with each other. I think that opening an ANI discussion like a DRN may be a good reform: A filing editor should write a dispute statement (with a section for providing diffs clearly marked like at 3RR), at which point other editors party to the grievance can weigh in with a right of single reply. Nobody should comment more than once (filer included) until an admin or clerk checks in and either takes action, makes a proposal, or queries someone for further input. Additional neutral parties would be free to weigh in in a 3rd party discussion section (similar to the general discussion section of an RfA). signed, Rosguilltalk05:03, 15 January 2021 (UTC)
I like this idea. It’s something raised on my talk with regards to GS’s ineffectiveness due to lack of structure compared to AE. I wouldn’t say full ARCA mode, but AE mode is good. Involved editors make separate statements and uninvolved editors discuss in one section between them, maybe? I’m not sure about 1 comment only - sometimes these discussions are a discussion and replies build on each other, rather than act as standalone statements. It is worth noting many ANI cases are ordinary/simple stuff, so any change shouldn’t make that much more difficult. ProcrastinatingReader (talk) 06:47, 15 January 2021 (UTC)
My idea for "1 comment" was that it should be one comment until an uninvolved editor weighs in and requests further comment. After which uninvolved editors can moderate as they see fit. But the entire idea behind bringing a dispute to ANI is that discussion has not proven fruitful elsewhere, so there's really no reason for involved editors to be responding to each other's statements. signed, Rosguilltalk07:18, 15 January 2021 (UTC)
Levivich, how were you thinking of testing it out? Given that the suggested reform changes the filing process in particular, I'm not sure what the best way to get participation would be, as by the time a report has been filed it's effectively too late. signed, Rosguilltalk17:15, 15 January 2021 (UTC)
@Rosguill: Why, with the dictatorial imposition of an admin, of course! :-) I'm not sure that filers would opt for the sectioned formatting. (We could make a template to allow people to file in a sectioned manner, but I'm not sure it would be used.) Maybe some would, but any filer who has the wherewithal to go this route would not be bludgeoning the discussion in any case. Sectioning seems like it would only be productive in those cases where it was imposed upon, not chosen by, the parties (I could be wrong about that). So I think we try it out by (an admin or other experienced editor, not me) boldly refactoring an appropriate thread and basically requiring the participants to abide by the sectioning, and then seeing if that makes processing the report easier. I realize this requires somebody to be in the right place at the right time... you have to catch the thread early enough. So, like, if there were a periodic-table-related report, that would be one that could be sectioned straight-away. Perhaps a discussion at WT:AN to raise awareness/seek consensus for a pilot would be a good idea? Levivichharass/hound17:37, 15 January 2021 (UTC)
Levivich, I think raising this at WT:AN is a good next step. One additional way to do a trial run would be to modify the ANI page filing instructions to advertise WP:ANI/B, and test out this new method there at editors' discretion for a trial period. signed, Rosguilltalk17:42, 15 January 2021 (UTC)
Ah, okay Rosguill. I'd misunderstood; I thought you meant uninvolved editors could only have 1 comment. I agree about the involved editors restriction. I think the whole Chemistry periodic table dispute is one that would've benefitted from such structure. The community is probably able to solve most problems, I think, at least as long as the dispute isn't too unwieldy to follow. Better presentation, and good clerking being considered a bit more acceptable, would perhaps help in that direction. ProcrastinatingReader (talk) 08:08, 15 January 2021 (UTC)
I'd like to point out that, believe it or not, all of those processes work notably better now than they have in the past. (Especially during the Stone Age of Wikipedia, when there was no WP:AN, WP:AN/I, or ArbCom. I don't know why that is -- except to deny I had anything to do with it. Maybe the community has grown more confident about what Wikipedia is about, what determines an editor who is a net positive, figured out more ways to constructively interact with others, established an unwritten community norm for behavior (by setting examples), & maybe we know where more of the landmines lie that lead to endless bickering.That said, there is no easy way to deal with some people. And few of us have the inclination to deal with those people -- either to mentor, or to somehow coerce them to behave.Sometimes I think we need to resort to solutions that are not natural for Wikipedia culture. For instance, have an active project director for en.wikipedia who actually leads by herding us cats: directs people to working on higher-priority articles, recruits people to watch flashpoint articles, settles content disputes, & so forth. This would be a short-term position (say a year -- longer would lead to burn out), with no special powers (except status & persuasion), & would refer difficult problems that merit sanctions to the ArbCom. Another idea I had would use the T&S group at the Foundation as paid mentors who would have the time to deal with that second situation WhatamIdoing described -- & other cases where we have productive editors who need special attention to properly interact with other editors. And alternative to blocking or banning people. I doubt any of these suggestions would be acceptable, but figure any durable solution requires thinking outside the box. -- llywrch (talk) 23:16, 4 January 2021 (UTC)
Llywrch, this reminds me a bit of a parable on User talk:Iridescent in 2018. I have wondered for years whether a bit of deliberate scheduling at, e.g., ANI would be helpful. (Imagine, e.g., that every sysop had to sign up to be the primary contact for all problem reports that appear at ANI during a four-hour span of your choice once a year, and to patrol four hours' worth of new articles on a different day, and to close CSD or XFD discussions on a third day of your choice each year.)
On the one hand, rotating duties around reduces burnout, keeps everyone in touch with the everyday problems, and makes sure that decisions, on average, are made according to broadly held standards, because the process won't be dominated by one self-appointed person and his like-minded buddies. On the other hand, we have perverse incentives, and they will still apply. For example, out of one side of our mouths, we all agree that we want to address systemic bias, gender gap, etc., and out of the other side of our mouths, we praise the guy who removes information about, (e.g.,) universities in non-English-speaking countries, because he's Upholding High Standards and Defending the Wiki, when we probably should be telling him to enroll in a class on how to use a web search engine to find information (Step 1: Don't limit your search results to websites that are in English). Even if the admins intentionally rotated into different duty areas, they would still be subject to those incentives. WhatamIdoing (talk) 03:51, 5 January 2021 (UTC)
Clay Shirky's talk "A Group is its own Worst Enemy" discussed problems with online communities. Attempts to make them non-hierarchical by replacing human judgement exercised by administrators with rules interpreted by everyone eventually fail as the rules become overly complex. Yes, there are advantages to the mostly flat decision-making framework used by the English Wikipedia community, but they come at a price. The community will one day have to face the question if having all significant changes stalemated, non-stop revisiting of disputes, and an environment that provides incentives for poor behaviour is worth it. isaacl (talk) 05:45, 5 January 2021 (UTC)
@WhatamIdoing:, your idea of scheduling time at ANI/CSD/XFD makes good sense. In fact, I'd go one step further: anyone who wanted to be an Admin would need to volunteer first to be a primary contact at one or more of those locations -- which would give everyone at WP:RfA objective data about what kind of job that person would do with the bit. And we all need to broaden our areas of exposure on Wikipedia. (I'll pass on the suggestion about a class about how to find information, since that touches on one of my hobby horses -- no general school system in any country does a satisfactory job of teaching how to perform research -- which few probably want to hear me pontificate about.)@Isaacl:, it's been a while since I read Shirky's essay. I could talk about different points he raises in it (e.g. what killed Usenet wasn't that "anyone could join" but that it's flood algorithm failed to scale), but I think the most important point that needs to be remembered is that practically everyone who has been active on Wikipedia for 5-10 years has about as much hands-on experience with Internet communities as he had when he wrote that essay. I don't know if that means we might know as much or more than he on the subject, but it's a datum worth remembering. -- llywrch (talk) 17:00, 5 January 2021 (UTC)
Part of the key points was that online communities are like communities in general and so our experience with them carries over. The fundamental problems of scale remain true. isaacl (talk) 18:05, 5 January 2021 (UTC)
I think the value is in "more of those locations". We don't need the Wikipedia:External links/Noticeboard to be dominated by two editors (I'm one); we need different voices to show up, so that the advice given there will easily and automatically reflect the actual current views of the whole community. You need 'my' voice at other noticeboards (where I'm not a regular participant) and I need 'your' voices at ELN. WhatamIdoing (talk) 20:02, 5 January 2021 (UTC)
Discussion about the format of this discussion
Er, surely the purpose of VPI is to formulate a proposal by throwing ideas around? Once you've got your proposal beyond the draft stage, you can transfer it to WP:VPR (or similar) for the actual RfC. Therefore, an RfC shouldn't be held yet, and when it is, it won't occur here. --Redrose64 🌹 (talk) 08:43, 11 December 2020 (UTC)
An RFC doesn't have to be a proposal; it can be just a request for comments. I thought this was the best place to have this discussion. If you want to remove the RFC tag or move this elsewhere, I don't mind. Levivichharass/hound21:23, 11 December 2020 (UTC)
I didn't say that an RfC couldn't be just a request for comments. But under #Questions to consider you ask two questions, and the purpose of VPI is to discuss what questions should be asked, and how they should best be worded - but these have all the appearance of being the actual finalised questions for the RfC; if they are, it's a VPR matter. Also, WP:RFCBEFORE advises that a preliminary discussion be held before the RfC tag is placed, since it may be resolvable without making it formal. I can't find where that preliminary discussion took place. --Redrose64 🌹 (talk) 00:09, 12 December 2020 (UTC)
I'm saying that if you have already decided what the questions should be, this is the wrong place to invite answers to those questions; but if you are still formulating the questions, it's too early for an RfC. --Redrose64 🌹 (talk) 08:07, 12 December 2020 (UTC)
Personally, I think the idea lab is a reasonable place for brainstorming,(*) and seeding brainstorming with some open-ended questions is a commonly-used approach. As to whether or not using the RfC notification process is desirable for brainstorming discussions: well, it might become unwieldy if there were too many of these types of discussions.
(*) I appreciate why some feel that other venues such as user space pages are more suitable for collating people's thoughts and focusing them into more concrete proposals, and that even initial brainstorming could be done that way. But it's also hard to keep discussions going in more obscure locations, so I wouldn't want to insist that all brainstorming must take place elsewhere. isaacl (talk) 20:38, 12 December 2020 (UTC)
One solution: An WP:AE-like format (as suggested above by Rosguill) but slightly differently. I think a nuanced discussion can probably be split up into categories. For example, comments by involved editors (often lengthy), analysis by uninvolved editors (sometimes lengthy), comments by uninvolved editors usually on the basis of available comments. Some of these should perhaps be in their own sub-sections (e.g. the first two categories). The third (shorter comments) are probably fine as normal threaded discussions. Some mixture of the more organised sectioning format, but not going too far as to become as cumbersome as AE/RFAR, would probably be an improvement.
Perhaps having a round-robin discussion phase, where each participant can make one comment per round and a moderator decides when to move to the next round or exit the round-robin phase, could be helpful for some situations. isaacl (talk) 20:21, 23 January 2021 (UTC)
Creating a separate "Template part"
Hi, according to "The principle of separation of concerns", Wikipedia articles should be separated into two parts 1-"Article text part" 2-"Template part", and "Article text part" should have only text of articles plus pointers to the "Template part", and "Template part" should only have all of the templates. I think this separation is very helpful, because 1- Reduces complexity of creation and read of articles, and 2-Process of articles both by machines and human becomes more easier and effective. (Semantic queries in the Semantic web that is the proposal of Tim Berners Lee). I think one of its benefits is improving its maintenance: Changing and replacing the template without changing the article text in a quiet way. What are pros and cons about respecting separation of concerns and making a separate "Template part"? Thanks, Hooman Mallahzadeh (talk) 15:46, 18 January 2021 (UTC)
Hooman Mallahzadeh, I do not understand what you are proposing, please try to put it in plain English. Particularly how separation of concerns is relevant to encyclopedia articles in general, as they are not programs and the markup is mostly for formatting purposes. Cheers, · · · Peter Southwood(talk): 16:06, 18 January 2021 (UTC)
I think you're misunderstanding what we mean by "template" on Wikipedia. A template isn't the style sheet for the page, but an instruction to insert a specific wikitext element at a given point - e.g., the {{ping}} you've used immediately above is an example of a template. Having the templates anywhere other than the point within the wikitext at which they're invoked would make no sense since it would render the wikitext incomprehensible, even if it were technically possible (which it isn't). ‑ Iridescent16:36, 18 January 2021 (UTC)
@Pbsouthwood: Regardless of benefits of good maintenance and semantic queries, editing becomes more convenient, you write articles in WYSIWYG manner, because you only mention the pointer and in the Template part editor, you do changing and in the text part, you see only final article. So one of the advantages is editing in WYSIWYG. Nowadays editing is not WYSIWYG, and you should enter "Show preview" or "Publish change" to see the final results. Hooman Mallahzadeh (talk) 16:41, 18 January 2021 (UTC)
[ec] Hooman Mallahzadeh, I still have no idea what you are proposing. Does this relate to the Wikitext source we edit? How would this be implemented? Where do we separate text and template in each article? Could you illustrate using an example? · · · Peter Southwood(talk): 16:44, 18 January 2021 (UTC)
@Iridescent: Yes you are right. Template is a way to do Transclusion. But Transclusion also could be separated from text. What problem do you see? Reading becomes better. A pointer does point to the template, and becomes WYSIWYG.
These templates extremely reduces the readability? When you write the text you should not engage in Infobox for example. You place a pointer to the "Template part" and "Infobox section" and do the rest of editing. For editing the Infobox, you trace the pointer and edit the Infobox separatly. Is that clear?
Hooman Mallahzadeh, The templates you list are already required to be in a group outside of the body text, largely to make the text more readable, but also in some cases because the transclusion is made at the point where the template stands in the text. There is even a specific order in which they should be arranged listed in the Manual of Style. There are a group of templates used above the body text, and others for use below the text. Others must be placed in the text where they function. Some, such as CS1 templates for reference definition formatting may be placed in the text or in a list in the references section, which makes the text more legible, but it is not compulsory. · · · Peter Southwood(talk): 17:14, 18 January 2021 (UTC)
Pbsouthwood See, for "separation of concerns", articles text should only have "text" and "pointer", nothing else should be placed there. The name of template can be a type of pointer, but its arguments "must not be placed there", because you should not engage in creating "templates" such as an Infobox between writing the article text. Hooman Mallahzadeh (talk) 17:25, 18 January 2021 (UTC)
@Hooman Mallahzadeh: you are wrong to think that separation of concerns is a useful concept for a wiki that allows editing by anybody. Creating a modular structure in programs is a high-level skill that programmers acquire over time, and we simply cannot expect casual editors to deviate from the principle of putting the template at the point where it is rendered. It is not feasible to expect occasional editors to insert a pointer in the wiki-text to another location where they then add the template content. On the other hand, we have the ability to edit using the Visual editor, which is WYSIWYG and inserts templates by pop-up forms, which removes the need of casual editors to read wiki-text. Your proposal would require extensive reorganisation of how MediaWiki software works and would offer no benefit over the current systems. --RexxS (talk) 18:24, 18 January 2021 (UTC)
I agree, except that having templates at all is a separation of concerns. The often complicated template code is left in the templates. The syntax for calling templates is fairly simple. The challenge is to make the right parameters. Moving the calls to another part would not help with that, except for editors who don't edit template calls at all and would have less to skip over. For everybody who does edit the calls, it would complicate matters if they were hidden away and you had to both keep pointers in the right place and go somewhere else to make changes to what they do. PrimeHunter (talk) 18:52, 18 January 2021 (UTC)
I think this idea uses template quite literally, not WP:Template. It’s not the worst idea, and shouldn’t be dismissed so easily imo, although probably likely best implemented in some kind of “article metadata” system, or as part of better template integration in VisualEditor, whenever they get around to that. It would require changes in the software; not much that can be done from a community standpoint. ProcrastinatingReader (talk) 19:01, 18 January 2021 (UTC)
It's a bad idea and completely impractical in its current form. This becomes apparent when one realises that it would entail a further complication for anyone learning to edit, and a change to MediaWiki software that would affect editing on 300+ other language wikis. --RexxS (talk) 19:52, 18 January 2021 (UTC)
Some things would be possible with the current MediaWiki, for example defining all references where they are displayed, or in another page like Template:References/Articlename which could be transcluded with {{reflist}}. We could also start all articles with {{begin}} and automatically pull any lead maintenance templates, hatnotes and infobox from somewhere like Template:Begin/articlename. Same with {{end}} pulling stuff like navboxes and categories. I don't actually support any of this, and it wouldn't prevent editors from breaking the rules or the template calls. PrimeHunter (talk) 21:36, 18 January 2021 (UTC)
@RexxS, PrimeHunter, ProcrastinatingReader, and Pbsouthwood: Benefits of this idea (Maintenance, Semantic Query, Readability, Better Editing) is clear. But about the problem of ""Backward compatibility"": I think backward compatibility is also preserved, old articles still work properly and new articles is split into two parts: 1- Text and pointer 2- Templates, and both of them is placed in a single "Article page", I mean all of the previous convections are respected. But If we want to respect "Separation of concerns" (that we possibly do not want to respect it) we simply only split the previous articles and place some pointers in the place of templates and in the "Template Part" all of the templates are mentioned (I mean in the same article page). Also with respecting all previous editors and conventions, a new "Edit Capability" (WYSIWYG) could be created. Hooman Mallahzadeh (talk) 04:55, 19 January 2021 (UTC)
@Pbsouthwood: Imagine we want to write an article in Wikipedia
-- Tempate part --
pointer1={{getFirstName}}
pointer2={{getLastName}}
-- Text and pointer part --
Hello pointer1 pointer2
Here pointer1 and pointer2 are pointers to "Template part" in the plain text and the output is:
Hello Hooman Mallahzadeh
Maintenance is good: We can change the getFirstName to getFirstNameFirstLetter to get "Hello H. Mallahzadeh" without changing the original text.
Semantic Query is done via checking the Template part only (not to check the text part, check it only when required).
It is very readable, because when reading the "Text and pointer" part you do not see redundant templates that distract your attention to other thing except text.
An other important benefit is ""Reusability"". Pointer1 can be used several times in the text and by only a single change in the template part, all of the usage of pointer1 is modified. Hooman Mallahzadeh (talk) 06:03, 19 January 2021 (UTC)
How is Hello pointer1 pointer2 "very readable"??? What is the use case for a facility offering a convenient way to switch from first name to first initial, article wide? I'm going to save you and everyone else a lot of time by suggesting that you put this idea on the shelf and dust it off again when your edit count, which right now is 700, reaches 10K. EEng06:59, 19 January 2021 (UTC)
@EEng: See, about Readability: We can change "pointer1" to "pointerFirstName" to make it more readable. About the total idea: You should read carefully the separation of concerns principle. If you do not see any benefit for it, I think your knowledge about modern programming is low. You probably say "Why HTML separates style and text? It still works fine and good. It is waste of time and a silly thing to make two parts style and text". Or probably you believe "The principle is only about "style" and totally silly about any other things", I think you are making a mistake and you are wrong about that.
I think your knowledge about modern programming is low – I'll spare you embarrassment by not setting you straight on that. The problem here, to be blunt, is not my knowledge of programming, but your knowledge of writing Wikipedia articles. Hint: it's not an exercise in programming. EEng07:37, 19 January 2021 (UTC)
Hooman Mallahzadeh, That does indeed sound more like Abstract wikipedia. If you have the appropriate skills and interest, your input there may be appreciated. Here on Wikipedia we expect to continue producing encyclopedic text content for the foreseeable future, which you are also welcome to do within the scope of the project. Cheers, · · · Peter Southwood(talk): 11:41, 19 January 2021 (UTC)
I'm really struggling to see what problem this is intended to solve. Sure, you can write articles like this:
-- Tempate part --
pointer1=Winston
pointer2=Churchill
-- Text and pointer part --
pointer1 pointer2 was a British statesman, army officer, and writer...
Then, if Sir Winston rises from the grave and decides he wants to retrospectively change his name to John Smith, we can change the article really easily (once enough reliable sources have reported Churchill's ghost's appearance down the Deed poll office). But is that something that is likely to happen? Your system makes it easy to do something we rarely need to do, whilst making it more difficult to do something we do all the time - write good articles. That kind of abstraction is great in programming (within reason), but less useful in prose. Since it seems you may come from a programming background, I refer you to this classic account of abstraction gone wrong, which your idea reminds me of: https://www.red-gate.com/simple-talk/opinion/opinion-pieces/bad-carma/
Even if this were a good idea, which imo it isn't, it's too late. There are over six million articles written by god knows how many editors over twenty years, and that's just English wikipedia. None of them use your system. You're proposing retraining all those editors and (presumably) rewriting all those articles in order to achieve, well, nothing very much. It's just not going to happen. Chuntuk (talk) 21:35, 19 January 2021 (UTC)
@Chuntuk: I've decided to cut off this discussion, but because you asked, I answer you.
See, your example is wrong. We should separate "Templates" from "Text" (as a principle), I mean in the top of page("Template part"), pointers equals Templates and in the "Text part" only text and pointer is mentioned. Not
pointer1=Winston(Plain text)
I mean
pointer1={{getFirstName}}(Template)
. I have explained completely about its benefits at the top and I think rewriting them here is redundant. About huge existing articles: No, as I mention above Backward compatibility is completely preserved, additionally a simple bot can change old articles to new articles with a few processing, simply bot replaces templates with pointers and templates itself is mentioned in "Template part". Thanks, Hooman Mallahzadeh (talk) 06:08, 20 January 2021 (UTC)
My primary goal of the design was to establish a clean interface by removing the closely-separated old-fashioned borders around each of the content boxes:
However after doing this, I noticed that there was little space between the primary green and blue boxes and I seeked to seperate them. Along with separating them, I also established a common separation between all boxes on the page of 8px, making the interface even more uniform and pretty.
I would like to know the community's input on what they think about the design.
Here are some possible related design questions to consider in addition to your general feedback:
Should the margins between the content boxes be increased further?
Should the shade/color of the two main boxes be changed/darkened to stand out? Without the borders they almost blend into the page.
Should the borders of the content boxes be rounded to be even more easy-on-the-eyes/user friendly?
Should the portal links to the right of the "Welcome to Wikipedia" be removed? I personally have never used them before. A search box could possibly replace it.
I'm honestly not a fan of this at all. I think the layout we have now is excellent, and that 'modernizing' it is completely unnecessary and only serves to make the Main Page look soullessly generic. At absolute best it's an unnoticable and unnecessary change, and anywhere below that it just decreases contrast (important for many people!) and makes the site look unappealingly bland and blurred. Vaticidalprophet (talk) 05:26, 21 January 2021 (UTC)
I think both this and the current page are hideous, get rid of the colors. Not to mention the poor design of having two columns continually causes us to have to make adjustments for "balance". Which everybody complains about, but nobody wants to admit that it is a problem we force on ourselves. --Khajidha (talk) 16:25, 21 January 2021 (UTC)
Is this at least a better alternative than the current version? There have been redesign proposals in the past but have failed, mostly because multiple design/page contents were changed at once instead of small improvements like this aims to do. This caused community conflict and they failed. Also, from editing the css of the page myself, I agree that there there are some weird design choices (such as using a table for the green and blue content boxes) and poorly coded responsive layout properties. I could of course try fixing these as part of the proposal, leaving the content layout the same to avoid conflict. Lectrician1 (talk) 17:18, 21 January 2021 (UTC)
"Is this at least a better alternative than the current version?" As I said, they are both hideous. Your question is rather like "well, would you prefer to have your left eye gouged out or your right one?" --Khajidha (talk) 17:41, 21 January 2021 (UTC)
I don't think it'd be worth the effort trying to put this forward; it'd be a marginal improvement at best. I'm largely with Khajidha that a more fundamental redesign is needed; I've seen plenty of other language editions that have figured out something better. It'll always be an uphill battle because people become attached to the designs they're familiar with, but hopefully at some point someone will put forward something that's a clear enough improvement and argue for it smartly enough that it'll pass. {{u|Sdkb}}talk18:59, 22 January 2021 (UTC)
Possibly best to work with key Main Page stakeholders (active admins, particularly) behind the scenes to come up with something and float the idea around to get people warm to the proposal, then present the idea in an RfC. ProcrastinatingReader (talk) 15:42, 23 January 2021 (UTC)
@LocalPunk: Thanks for your suggestion. When you believe an article needs improvement, please feel free to change it. We encourage you to be bold in updating pages, since wikis like ours develop faster when everybody edits. Don't worry too much about making honest mistakes—they're likely to be found and corrected quickly. You can always preview your edits before you publish them or test them out in the sandbox. If you need additional help, check out our getting started page or ask the friendly folks at the Teahouse. — xaosfluxTalk15:55, 25 January 2021 (UTC)
Hyperlink color is too light blue and it's visually distracting
Bright Blue Hyperlink color makes reading disruptive
That is just what always strikes me when I visit. WIKI is so busy with links that the continuity of reading is broken up. A darker blue, closer to black, is more readable. I hear wiki uses darker blue for visited, or previously edited sites. Maybe that distinction could be changed and given to all-links-in-general to enhance encyclopedia readability in such a busily linked site.
Just a thought. I know when I copy and paste material, I sometimes take the time to darken the links to a darker blue so reading isn't so distracting.
Personally I find the shade fine but I can understand why it may not for some people. Is there an option to change the colours of text and background client-side? Or are you suggesting a server-side change? Would the server-side change be configurable client-side? I worry that a server-side change that makes links an almost-black blue may make it more difficult to distinguish from regular text, which by default is black. LocalPunk (talk) 11:11, 25 January 2021 (UTC)
Where #000000 is replaced with a color of your choice. You can use this color picker to choose which color you prefer. If you want to modify the color of already-visited links, you can additionally add
Yes, I know it's a perennial proposal, and yes I've read over quite a few discussions in the past and yes I do feel times are different now. Mergers often stay open exorbitantly long times . This is not practical, and the system of proposed mergers is clearly struggling with low participation and interest (not to suggest that other areas aren't). It is more effective and efficient to nominate an article for deletion if you want it to be merged. Like it or not, that would seem to be a fact at this point based on my highly unscientific day-to-day life. See, for instance, 1 and 2, where unanimous consensuses were reached in a week-- this would usually take months to a year or more if you followed the 'correct' way of proposing a merge. Currently, some users will !vote "keep: a merger should be discussed elsewhere" and I'd argue that more often than not no discussion happens elsewhere.
I'm not suggesting completely folding PROPMERGE into AfD and I'm not suggesting necessarily renaming AfD to articles for discussion, I just think it past time that we seriously consider making 'merge' a valid option to start an AfD for. Is AfD exactly booming with participants? no, but I'd argue it's higher visibility than proposing a merger, the format works just as well better, and I highly doubt the number of new merges would overwhelm the system. We could always do a trial for X months and reassess... Cheers, Eddie891TalkWork23:22, 25 January 2021 (UTC)
To clarify I'm suggesting that we make merge an acceptable proposal to suggest when opening an AfD, but leave Proposed mergers as a functional place where people can still file proposals if they either feel that system would work better (perhaps for a sufficiently high traffic article) or if the AfD is closed as no consensus (but, of course, not 'keep' or 'delete). This would allow most merger suggestions to get more discussion (because of higher visibility) and closed faster (time limit of AfD) and may also have the benefit of more controversial Proposed mergers getting more attention because there are more manageable amounts. Eddie891TalkWork23:38, 25 January 2021 (UTC)
Eddie891, I agree (as I hope everyone does) that the merge proposal system is clearly broken and needs some sort of reform. I'll leave it to others more familiar to decide whether folding it into AfD is the best approach, but I'm down to try something, and worst case scenario it fails and we return to the status quo.
Since this is a developed, actionable proposal, you might want to move it to WP:VPR, as the idea lab isn't a place for !voting. {{u|Sdkb}}talk03:18, 26 January 2021 (UTC)
I think re-implementing WikiMoney and the related services could be cool. What if you could use WikiMoney to buy some cool things like a "Golden Barnstar" to give to exceptional work. — Preceding unsigned comment added by Education-over-easy (talk • contribs) 14:25, 11 January 2021 (UTC)
I feel like the introduction of WikiMoney would be followed by WikiCorruption, WikiLobbying, and WikiBribery in today's Wikipedia. Basically, gamification of community goodwill can create perverse incentives. Ask Reddit how well their karma system has worked out. - NovovTC08:38, 15 January 2021 (UTC)
WP has a problem with hundreds of pages of non-notable fake nobility
Many nations in Europe have abolished their nobility. The people who would hold this titles, or claim they would, often have articles here calling them "Prince" and "Duke."
But they are not princes or dukes, because they are not children of sovereigns or the head of a dukedom.
I conservatively estimate there are more than 500 similar pages of people who are not notable, and only here because they claim to have royal or noble titles. It could four times this amount.
Of course a pretender could be notable because they have widespread political support for restoration. Or they could be notable as a scientist, author, etc. But rarely is this the case here.
My view is that (1) most of these articles should be deleted (2) the remaining ones the royal title like "prince" should be deleted from the article name.
Someone made a similar suggestion here in 2013:
RfC notice - proposed guideline in the Manual of Style with reference to applying "royal titles" to living members of deposed royal families
I have opened a RfC about a proposed guideline for the attribution of "royal titles and styles" to members of families whose ancestors were deposed as monarchs from various countries, often many years ago. At the moment many WP articles about these persons attribute "royal titles" to them in what seems to me a very misleading way. Please join in the discussion at Wikipedia talk:Manual of Style/Biographies "Use of royal "Titles and styles" and honorific prefixes in articles and templates referring to pretenders to abolished royal titles and their families" Smeat75 (talk) 04:45, 27 November 2013 (UTC)
@Declanscottp, usually, our notion of notability isn't closely related to political support or real-world value. It's focused on whether you get attention from the world at large. If you are a sufficiently interesting claimant, then you get written about in the media, and then Wikipedia editors are able to write an article about you. See, e.g., Emperor Norton, who claimed a non-existent throne. If you are not interesting, then nobody writes about you, and then Wikipedia editors aren't able to write a neutral encyclopedia article about you. We aren't trying to limit Wikipedia to legally recognizable royal people. We're trying to expand Wikipedia to whatever subjects the world has chosen to pay attention to, including fake royalty with absolutely no chance of ever being placed in a position of power. WhatamIdoing (talk) 02:42, 26 January 2021 (UTC)
@Declanscottp: I hope that you wouldn't be contesting notability with every self-titled Duke, King, Queen, Prince, Count, Lady, Sir, or even Chairman. In seriousness, I think it would be best to do individual AfDs for non-notable biogs (Princess Béatrice seems a ripe candidate for deletion), but whether or not their title is "real" probably isn't the argument to go for - I wouldn't personally say that any titles are more "real" or "fake" than any others, they're all equally made up - but WP:NOTINHERITED would be relevant in a lot of these cases. --Paul ❬talk❭ 11:55, 26 January 2021 (UTC)
@WhatamIdoing:@Paul Carpenter: Responding to both these points - A small number of these people are notable for reasons beyond their fake titles. Regarding media coverage, a lot of these articles do have a few random references. But they are generally of the "Princess Betty showed up to the charity ball in a stunning dress" or "Princess Betty married Duke John." I don't think that's enough to be notable. Tons of people are written about in wedding announcements. Second, even to the extent these people are notable, the decision to title an article "Princess Beatrice" when their own government does not recognize their title is highly political: it implies the decision to abolish the nobility taken by Italy, Austria, France, etc was not legitimate. As a matter of French Law, there are no longer any French princes, dukes, etc. They are all pretenders, and should be labeled as such, not given titles. It isn't a case like Emperor Norton, whose title is obviously a joke, or actual celebrities with chart topping songs. The people who are fake royals in Europe often believe as political matters believe their republican governments are illegitimate. Giving them noble titles in their articles and article titles, and using their claimed status as a factor for notability, is making a political statement against those republican governments. We would not disrespectfully name Prince Charles's article "Charles Mountbattan" because the UK is an actual monarchy. I see articles about various French "Dukes" and "Princes" like this as equally bad as this. France, again, simply has no dukes or princes. They are both disrespectful and misleading. https://en.wikipedia.org/wiki/Prince_Charles-Philippe,_Duke_of_AnjouDeclanscottp (talk) 00:42, 29 January 2021 (UTC)
On the point of names, per WP:COMMONNAME we use whatever name they would most easily be recognised by - regardless of the officialness of that title. Which is why we don't add sir to the page title for everyone who's technically been given a knighthood or whatnot.
On the point of notability i.e. whether they should have an article or not, you're quite right that "so and so wore a dress and married cousin whatshisface" does not qualify as WP:SIGCOV and if that's all the references an article has got: it should be deleted via WP:AfD. But as WhatamIdoing says, that's not much to do with the 'realness' or lack thereof of their 'title'.
We currently have bundled cites like #1 in QAnon. This is arguably not good for a couple reasons:
wrong citation count.
unnecessary complexity in a reference.
difficult to normalize and canonicalize for tools and data gathering.
difficult to cite one (or a few) from the bundle somewhere else in the article.
However, it's also not great to have "Foo bar baz.[1][2][3][4][5][6][7][8][9][10][11][12][13][14][15]". In some citation styles they use ranges on consecutive numbers above a certain threshold (e.g., [1-15]). The numbers might not always be completely consecutive, but for the one's that are they can be bundled. This would need to be done at the MediaWiki layer. Thoughts or other ideas? -- GreenC13:49, 4 February 2021 (UTC)
At the highest level this could be achieved (a) by having the citation software aggregate/serialize consecutive citations (i.e. [1][2][3] becomes [1-3]) and (b) from there, strongly encouraging editors to not bundle citations together in one <ref></ref> set. This would be a good idea for a community wishlist project (alas the 2021 cycle just passed). Harej (talk) 16:07, 4 February 2021 (UTC)
Harej, that's a really interesting idea! One question: what would we want to happen for reused citations alongside others, such as "Foo bar baz.[47][6][48][49]"? {{u|Sdkb}}talk20:24, 4 February 2021 (UTC)
We already have WP:OVERKILL for part b. Editors concerned with Lots of Citations in A Row should reduce reference groups at issue and then have the inevitable discussion. (And/or we should not cover contentious topics the way we do, which is almost always how OVERKILL situations arise.) --Izno (talk) 02:27, 5 February 2021 (UTC)
Because we are where the page author(s) feel they have no other option. You seek to change consensus on the point in some way... Another thing that is done is adding an explanatory footnote using {{efn}} which embeds regular reusable footnotes, usually with some explanation for each particular footnote; we might consider that as a preferable option to bundling. --Izno (talk) 06:48, 6 February 2021 (UTC)
There can be some valid uses for a bundled cite. For example, in Going steady, I bundled a cite to a paper with a cite to the errata for that paper; as a separate ref, readers might not notice that corrections had been made to the original paper. Schazjmd(talk)20:34, 4 February 2021 (UTC)
I know this has been discussed before. I do not see a Phab task. I do not understand where you think the anchor will lead when someone clicks on a 1-15 reference. Right now the blue highlighting that comes with a selected reference is also a feature that would necessarily be lost for the references which aren't whichever reference you select as being the desired target in such a case. --Izno (talk) 02:27, 5 February 2021 (UTC)
Presumably it would jump to the first cite in the list since they are consecutive. Even better highlight them all as a block. When clicking [1-15]. -- GreenC22:10, 5 February 2021 (UTC)
Even better highlight them all as a block. When clicking [1-15]. This is not possible. Only the targeted reference can be turned blue. Are you sure you want it to be the first? There was a big hullaballoo because AWB was reordering citations in a row (since removed). I imagine "going to the first" will have a similar issue. --Izno (talk) 06:48, 6 February 2021 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Respected Wikipedia Admins,
I would like to bring a new and essential feature to your notice which needs to be added in Wikipedia.
But before that, I would apologize for excessive trolling which I did on #wikipedia-en-help and #wikimedia-commons(Kiwi 🥝 IRC Channels). Now, I am myself exhausted after repeated trolling that I don't like to troll any more.
The feature is related to in-article search. You might have seen, when you open .pdf or .docx or .pptx file using certain apps, there is a feature through which you can search a particular word in the article.
For e.g., when you open a .pdf file using Chrome app, there is a search bar on top of the page where when you search a particular word and as you press enter, wherever the word it there in the article, it gets highlighted by a particular colour so you can refer it easily.
I am requesting to you to add this feature because I have seen there are certain users who edit articles without selecting "Watch this page" checkbox☑️. As a result, it becomes difficult to locate their edit if it is minor and the article is too big. And it might happen that those edits by the users might not be up to the marks and might need to be reverted. However, in such cases, the task becomes difficult. In such cases,we have to read entire article to locate it.
Thus, am requesting you to add a feature of word search in the article itself which will make location of a particular word easy. Secondly, it will be beneficial for readers who wish to find information on a particular topic.
It is my humble request to you to ask the respective Wikipedia developers to add this essential feature asap.
@Akshat2103: if I understand you correctly, you would like to find some text on a page, just as you can in other documents. Using your example, the ability to search the text of a PDF isn't coming from the pdf itself, but from the pdf viewer. Likewise, most modern browsers you would use to view articles already have this functionality. For example you mentioned the Chrome browser. Chrome offers "find in page" capability already, for desktop you can usually press CNTRL-F to pop open the control for it; on mobile Chrome it is usually in the "..." menu called "Find in page". Does that help? — xaosfluxTalk19:52, 4 February 2021 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Turning the sidebar into a horizontal navigation menu
Many websites such as W3Schools for example have a navigation menu at the top rather than on the left. I think Wikipedia would look a lot better if it had one on top above the links. I'm not a coder, but I could sketch out what exactly the new navigation menu would look like. I would like to hear from Sdkb for thoughts on this and would like to know if it has been discussed before. Thanks, Interstellarity (talk) 20:03, 4 February 2021 (UTC)
I don't know of this being discussed before. It would entail a full redesign of Vector, which would be a very big undertaking probably better handled by the WMF as professionals (in consultation with us) than by us as volunteers. {{u|Sdkb}}talk20:20, 4 February 2021 (UTC)
New Vector removes the sidebar in lieu of the "hamburger" icon, which makes the entire sidebar a dropdown. I presume that is preferable. (I certainly see it as so.) --Izno (talk) 02:29, 5 February 2021 (UTC)
Given the forthcoming redesign there's no benefit to this. The WMF is determined to enforce a maximum display width in the future which will mean that except on the narrowest of monitors such as using desktop view on a phone, the article text will already be surrounded by white space (see French Wikipedia for what it will look like). In that context, getting rid of the sidebar wouldn't have any benefit to readers, it would just mean even more of the page being taken up with useless white space. Bear in mind also that replacing the current always-displayed links with drop-down menus poses accessability issues both to people using screen readers or other navigation software, and to people who aren't necessarily going to be aware of how the menus work. (Wikipedia has a very broad readership of all different levels of technical knowledge and experience; you'd be surprised how many people are unaware that the hamburger icon leads to further options.) ‑ Iridescent05:13, 5 February 2021 (UTC)
You can see the new design at w:fr:Gâteau breton. Click the ☰ or ≪ at the top by the Wikipedia globe to see how the sidebar is handled. It might be worth checking that you have your web browser set to zero zoom, if you want to see the fixed-width aspect. If you tend to zoom in a bit on a normal laptop, then it might not be visible. Note that the width depends significantly upon your device and settings. This is about 25 cm on the main designer's screen, and about 18 cm on mine (with default zoom). Whatamidoing (WMF) (talk) 20:08, 5 February 2021 (UTC)
Require editors to acknowledge WP:POLICY before saving their first edit
There are a lot of editors who are WP:NOTHERE or don't know what WP:NOTHERE means. We can't do much about those who KNOW they are here for the wrong reason, but I have an idea that will help those who are ignorant or those who might be WP:PAID but who really want to "play by the rules" but don't even know there are rules they must play by:
For users who bypass that screen, add the check-box and link to the editing window but only for their first edit.
Do the same for non-logged-in editors, except for every edit or at least every edit in a single "editing session" (i.e. until cookies are flushed or they expire).
This would probably lose us more positive edits than reduce the negative ones we must deal with as a matter of course. A non-starter. --Izno (talk) 02:30, 5 February 2021 (UTC)
While I can understand what you are getting at IMO the statement By publishing changes, you agree to the Terms of Use below the edit summary box would seem to cover this. I'm also not sure what difference this would make in the case of IPs since the person using it can change. MarnetteD|Talk03:05, 5 February 2021 (UTC)
Have you ever installed a piece of software with an end-user license agreement? Do you remember what you agreed to when signing it? Did you even read it at all? Me neither. Even well intentioned people will probably just check "I agree" without reading. Gnomingstuff (talk) 00:40, 8 February 2021 (UTC)
I have to agree with the above. Without even thinking about what effect (positive or negative) this change would have, we need to realize that no one is actually going to read any warnings provided. HouseBlastertalk19:30, 8 February 2021 (UTC)
Duplicate references
For many large articles, I'll often quickly add a reference, only to discover after that it was already used elsewhere on the page, just with a difference retrieved date or other minor change, so it wasn't automatically merged. I also often come across instances where others have done this and not noticed afterwards. From WP:DUPCITES, it looks like there aren't any great tools for merging duplicate references. Should we work on creating such tools, or adding some sort of mild warning when someone tries to add a citation detected as likely a duplicate? {{u|Sdkb}}talk21:35, 10 February 2021 (UTC)
Sdrqaz, I'm not very familiar with ReFill 2. Does it do that? How good is it at identifying which references are duplicates? (Do they have to be exactly the same, or will it notice things like work=New York Times vs. work=[[The New York Times]]?) {{u|Sdkb}}talk22:41, 10 February 2021 (UTC)
@Sdkb: I thought it did, but apparently not. I just made ReFill run through my sandbox with a scenario I think you're talking about, but they weren't merged. I would say, however, that merging references with different access-dates may have unintended consequences: a piece of information may have been present in an earlier revision. However, that point about a cosmetic difference in work name is not great and should be covered by a tool. Sdrqaz (talk) 23:31, 10 February 2021 (UTC)
Sdrqaz, I just added a few further tests. Merely changing the URL from https to http throws off the bot, so it's not super smart. {{u|Sdkb}}talk23:44, 10 February 2021 (UTC)
Ah what a shame, Sdkb. To be fair to the tool, I think it's mainly aimed for resolving bare URLs and that's what I usually use it for too. Sdrqaz (talk) 23:47, 10 February 2021 (UTC)
Help desk and teahouse volunteer, and ten+ year editor here. I just posted a mass typo fix request for "Insititute" on Wikipedia talk:Typo Team but noticed a request from July last year about a prevalence of its' (with trailing apostrophe) seems to have been unanswered. Wikipedia:Typo Team has a pledges page, but shouldn't there also be a requests page? This might also raise the profile of Typo Team - I'd never heard of the team until today. TimTempleton(talk)(cont)02:25, 12 February 2021 (UTC)
Hi. I have seen quite a few ads for smaller public transport providers in Britain recently and wondered if we should have an SNG specifically for Public Transport. I base this idea that unless a public transport provider is a national concern, they rarely get the level of coverage to meet gng, even if they are an important player in society and are what people on the street would say is notable. I have looked and could not see any current wikiproject looking at this. Davidstewartharvey (talk) 15:26, 15 February 2021 (UTC)
Can you give an example of something you have in mind? I find it hard to imagine an operator of passenger rail or bus services that wouldn't be the subject of significant coverage in the specialist press and usually the broader press, particularly in the UK where even the most minor local service connecting a couple of villages is invariably the subject of both competitive tendering to operate the route, and regular commentary from the area's politicians regarding service levels and any perceived problems. In my experience, if anything we ought to be making the notability rules on UK public transport stricter as at the moment we have a plethora of no-conceivable-interest-to-anyone-but-technically-notable-so-undeletable articles like London Buses route 453. ‑ Iridescent15:47, 15 February 2021 (UTC)
I have the unfair advantage of being able to see deleted content, and thus can see that the issue with Stotts Tours (Oldham) isn't that it was cited to the specialist press (it had no citations whatsoever to the specialist press); it's that aside from three sentences it was cited to nothing. (If I restored the Stotts Tours article but removed every statement that was uncited or cited only to an inappropriate source, it would read in full In 2018, the Traffic Commissioner for the North West of England, Simon Evans, cut Stotts transport licence from 40 to 31 vehicles after failing to auto enrol staff onto a pension scheme. In November 2017, Brighton Magistrates Court found Stotts Tours and its managing director guilty of failing to auto enrol employees onto a work based pension. The company was fined £60,000 and became the first UK company to be found guilty under the 2015 pension laws.) Assuming it was covered in-depth by Buses Magazine at some point—and I'd be surprised if there's any operator of scheduled bus services that hasn't been—then it can be re-created with decent sourcing, but the participants at AfD discussions can only work with what they have in front of them. With an absence of sourcing like that, no admin could have done anything other than delete it.
I think you're under a misapprehension as to what special notability guidelines are; they're not a declaration that some topics are automatically notable, but summaries of the situation regarding the existence of sources for particular classes of topic. Usually they're an indicator that there are certain topics (e.g. Olympic athletes, towns and cities, members of national legislatures) for which it's always reasonable to assume that sufficient sources exist even if they're not findable on Google; on some rare occasions where there's a lot of low-value coverage (e.g. pornographic actors) they work the other way and indicate that even if sources exist the topic isn't notable unless specific criteria are met, to prevent Wikipedia being swamped. While I would support (and have supported) a formal ruling that rail stations are inherently notable since we can always assume they received significant coverage when they opened, it probably wouldn't be appropriate to extend such a thing to bus operators; not because they're not almost always going to be theoretically notable, but that without adequate sourcing they would be impossible to write. (TL;DR summary; it's not enough for something to be notable, there need to be enough sources to say something about it.) ‑ Iridescent20:14, 15 February 2021 (UTC)
I am not about not having no references to show Notability, but sng shows what is deemed notable and needs ref to prove it. At the current AFD the nominator has stated "No significant coverage of this defunct company in multiple reliable sources (that are not local or of limited interest) - fails WP:NCORP.". If we had a public transport sng, we could cover all aspects, from bus operators to railway stations, instead of relying on ncorp or nbuild. We have sport sng why not something that is important to daily life? Davidstewartharvey (talk) 20:50, 15 February 2021 (UTC)
Linking cited papers to Connected Papers graphs
I thought it might be useful for wikipedia to add a link in the Works Cited section to the Connected Papers graph of each journal article. Connected Papers finds and visualizes similar papers to the one in question. I think this would make it easier to use Wikipedia as a resource in an academic research setting. They have recently integrated with arXiv and seem likely to support FOSS projects like wikipedia, or at least support us linking to them. TripleShortOfACycle (talk - contribs) - (she/her/hers) 05:49, 12 February 2021 (UTC)
@Elliot321: Yes, the idea would be to link to a graph for any paper that has a DOI included in its citation. I'm not entirely sure about how to go about setting something like that up though. TripleShortOfACycle (talk - contribs) - (she/her/hers) 07:44, 18 February 2021 (UTC)
(This might have been proposed before. Also, if this idea is in the wrong place, please tell me where I should put it.)
In each year article from 1900 to 1989*, the events section links to detailed monthly articles for each month, each of which in turn lists several events for each day therein (as well as the corresponding day of the week). Meanwhile, for all the year articles from 1990 to 2021*, the events section is merely a sparse listing of various occurrences, with no monthly articles at all (each monthly title is a redirect to the appropriate subsection of the events section). However, the period since 1990 has been hardly lacking in historically important events. To fix this discrepancy, I propose that, for each year since 1990 to the present, monthly articles should be created for each month, with content for each day. This would greatly improve our historical understanding of recent & important events.
*At least I think so. I haven't bothered to check every article, but this seems to hold for every one I've visited.
You don't need to ask permission to create articles. If you think you have enough material to write a stand-alone September 1997 (or whatever) article, you can just go ahead and do it. ‑ Iridescent20:18, 15 February 2021 (UTC)
Thank you for the reply! I'm going to shelve this idea because it's already been discussed to death, and consensus seems to indicate that yearly articles are enough. (My dad tells me that these monthly articles have questionable historical significance anyways.) Duckmather (talk) 20:36, 19 February 2021 (UTC)
Democracy of wikipedia
I wondered if, even if it is possible, that discussions that occur, like changes to Notability, that editors are notified to make Wikipedia more democratic? At the moment it seems that when policy changes are being discussed and made, it seems to be the same small band of editors, and in most cases most editors don't know it is actually happening.
My idea is that when policy is being discussed all editors get a discussion notification, and at the end of the discussion all editors get a notification to vote. Once the vote has been completed then the notification is sent to all editors to let them know of the change, if any, to policy.Davidstewartharvey (talk) 06:59, 16 February 2021 (UTC)
Any proposed major change already gets listed on {{Centralized discussion}} which in turn appears at the top of over 5000 noticeboards and policy pages (including this one); it's not as if we're hiding discussions to keep them the preserve of a clique of insiders. At any given time, we have a lot of Requests for Comment ongoing (these are just the currently-open ones, and posting notifications of all of them to all 48,298,173 editor talk pages would totally flood Wikipedia; there isn't a practical way to only notify of the major ones, since no two editors will agree on what constitutes "major". If you want to increase the likelihood of your being notified about proposals in particular areas, add your name to the relevant sections at Wikipedia:Feedback request service. (For what it's worth, Wikipedia's definition of "notability"—significant coverage in reliable sources that are independent of the subject—has been unchanged since May 2007, and is one of the few things on Wikipedia which is never seriously challenged; changing it to even a minor degree would have such a huge knock-on effect on Wikipedia's existing content as to be unworkable.) ‑ Iridescent07:45, 16 February 2021 (UTC)
We could advertise T:CENT discussions on watchlists, like RfAs? In a streamlined columns way (eg 3 items per row), so it's not too crowded. Usually not more than 5 enwiki CENT discussions running at a time. Not saying it's a good idea, but just a thought. Btw, surely we don't have 5000 noticeboards and policy pages? ProcrastinatingReader (talk) 14:13, 16 February 2021 (UTC)
A lot of that 5000 that have T:CENT transcluded are archives rather than active noticeboards, but if anything we probably have more like 10,000 active noticeboards. There are thousands of de facto "anyone who's interested in the topic is going to have this watchlisted" noticeboards like WikiProject talk pages and high-traffic article talk pages like Talk:Joe Biden. If there were a way to restrict who it was shown to, I think putting T:CENT at the top of everyone's watchlist would be a good idea, but if and only if we could restrict it so it wasn't shown to everyone (maybe the 500 edits and 30 days threshold we already use elsewhere?). One lesson the watchlist notice for RFAs has taught is that it can be counterproductive to invite brand new editors to participate in discussions on complex issues, as they make good-faith comments, get slapped down for failing to understand the issues, and in turn get demoralised and quit, and a lot of the issues that come up at T:CENT are quite inside-baseball. ‑ Iridescent15:43, 16 February 2021 (UTC)
Technically speaking, at least, I think it might actually be possible to limit it to showing for ECP only. Usually you can add a class “sysop-show” or “autoconfirmed-show” to things to hide them from everything but that group. There’s probably one for ECP too. ProcrastinatingReader (talk) 16:31, 16 February 2021 (UTC)
I'd support only showing it to ECP users. We probably don't want too many newbies stumbling into these discussions, but it's better for more people to find out about them. Elliot321 (talk | contribs) 01:09, 18 February 2021 (UTC)
There's definitely room for improvement in this. Yes, super major changes might make it to centralized discussion, but let's not pretend that all discussions get the amount of discussion they deserve. There's definitely some RfCs and changes that set precedent that are done in backwater places with an element of "gaming the system" at play. One thing that we need to improve upon is reprimanding editors that appear to be doing this. Jason Quinn (talk) 12:55, 16 February 2021 (UTC)
I'm not sure how you plan to determine which editors are gaming the system and which are just raising it on the most applicable (but less viewed) pages. There isn't a clear marker on which discussions belong on the central hub and which on their relevant policy/guideline talk pages. Nosebagbear (talk) 00:50, 18 February 2021 (UTC)
Very impacting RFC's are also added to the watchlist notice, generally related to major changes that affect large numbers of editors. Inclusion criteria is subjective, but in general WLN's about RFC's are more stringent then for T:CENT. (e.g. Special:PermaLink/975679275 from a few months ago. — xaosfluxTalk20:19, 18 February 2021 (UTC)
Wikivoyage Mobile App
Wikivoyage is one of the best projects of Wikimedia. In last days, I'm so concentrated to develop the new opened Turkish Wikivoyage page. And I think, an official mobile app for Wikivoyage is a good idea. It can be perfect for the travelers around the world. The people mostly use their smart phones during traveling. This project will not make much sense if there is no app of WV.UcuncuUlus (talk) 13:27, 20 February 2021 (UTC)
That is a separate project from Wikipedia, and so it should be discussed there instead. According to Wikivoyage Community Portal [6], feature requests go into phabricator [7]. There is also the "Traveler's Pub", which looks to be like the Wikipedia Help Desk, so maybe try there first [8]RudolfRed (talk) 21:11, 20 February 2021 (UTC)
Idea for new possible skin
Since I started using Ubuntu, it has seemed like an interesting idea to have a skin on Wikipedia that makes Wikipedia look like a command prompt or a terminal. I know it probably won't get implemented, and even if it gets implemented, very few people will use it, but it seems like an interesting idea. 4D4850 (talk) 01:27, 24 February 2021 (UTC)
What do you mean by "look like a terminal"? If you just want fixed-width fonts and no graphics, just install Lynx; you don't need to mess around reskinning websites. ‑ Iridescent05:33, 24 February 2021 (UTC)
Curious if anyone has considered writing a bot to automatically handle many WP:U1 speedy deletions? To prevent abuse, it should make sure that the page was either created in the user's userspace, or never edited by anyone other than the user (so someone couldn't move a page to their userspace to get it deleted, or U1 an article they created but others had built). This could significantly speed up U1 and leave admins to do things more useful. Elliot321 (talk | contribs) 02:31, 25 February 2021 (UTC)
everything we do here is written down since writing things down is like, the only thing we can do - so I'm not sure how the bus factor could possibly apply. --Paul ❬talk❭ 21:38, 30 January 2021 (UTC)
There are various areas of wiki which would stop functioning properly, or be notably reduced in quality, if one editor left. Of course, the wiki keeps going in any case. ProcrastinatingReader (talk) 21:50, 30 January 2021 (UTC)
It is worth noting, however, that I’m not sure this test helps. The only solution to these areas is to recruit more people to take that spot, which are functions of both our general editor recruitment efforts (from non-editors), and our ability to give existing editors permissions needed to elevate their roles. For example, there was a point last year when Primefac took a short break and BRFA grinded to a halt (and TFDH). There’s no solution to that other than more BAG (which, currently, I guess myself and Earwig are quite active), and more competent template editors with general TfD authorisations. Unblock request patrolling tends to be Yamla and another whose username escapes me. Edit filter requests pretty much rest on SoY, as most edit filter managers don’t interact with that venue, and even SoY can only do so much, so that venue is half useless. L235 was responsible for much of the ArbCom clerking I think, and still is somewhat even after election (updating templates and such). Endless list of examples like this, some of these (and others) more effected than others. No real solution to them other than train new editors, but that’s a problem in itself due to general skepticism. Most areas are documented so someone could pick them up with time, but some more obscure areas rely on unwritten conventions (TFDH work for example, and some of TFD in general). ProcrastinatingReader (talk) 00:51, 31 January 2021 (UTC)
Enterprisey, that's an interesting thought! I don't think people would go for it, but I do think there are things we could do better to help make sure Wikipedia doesn't become overly reliant on any one editor.
There are several different realms in which this applies. With regard to maintaining articles/templates/other pages, I wrote the essay Wikipedia:Build content to endure (WP:ENDURE) with my thoughts.
And then there's bots, which I think are by far our weakest link in this area. There are lots of instances where a bot operator retires, and their bot subsequently stops working, oftentimes leading to substantial damage before anyone notices. I've brought this up before and suggested some ideas, but either they aren't workable or no one has bothered to fully implement them. {{u|Sdkb}}talk17:19, 1 February 2021 (UTC)
And yet somehow we lumber forward. Once solution would be that as soon as a given editor manifests themself as high-performing and knowledgeable, we block them. Then we don't become dependent and future surprises are avoided. (Not sure themself is a word but seems to me it should go with "singular they".) EEng15:32, 2 February 2021 (UTC)
Or we should just pre-emptively block anyone who tries to edit. If we also deleted all of our articles we would then have a nice tidy encyclopedia. Phil Bridger (talk) 17:18, 26 February 2021 (UTC)
the problem with this is that if an editor has a regular area of editing, then they may lose some credibility if they suddenly stop editing for a long period of time. --Sm8900 (talk) 19:22, 15 February 2021 (UTC)
I thought a more common reason for mandatory vacations was to guard against fraud. It is more likely to come to light that an employee is doing something untoward if such employee can't access an employer's systems for a couple of weeks and someone else performs their (I've been trying to avoid using the singular "they" but can't really be arsed any more here) functions. In any case, it's a nice idea that would be completely impractical in an environment where most workers are anonymous. Phil Bridger (talk) 17:14, 26 February 2021 (UTC)
Adding "Suggested edits" from Wikimedia Apps to regular Wikipedia
There is a useful feature in Wikimedia apps that suggests edits for users automatically. Wikimedia Apps/Suggested edits allows people to casually edit Wikipedia doing all sorts of recommended tasks and community related help, and its ease of use brings me to the conclusion that it would be a very good idea to implement something equivalent on the main site. I recognize that we have features for improving articles according with very different needs, but the automatic nature of Suggested Edits leads me to believe that it would be a convenient tool for those who want to take advantage of it.Tyrone Madera (talk) 07:39, 10 February 2021 (UTC)
Not sure about this one. Adding captions and short descriptions are helpful tasks, but the main type of suggested edits should probably be prose additions. If people on desktop Wikipedia are looking for little tasks to do, there's tons of backlog categories for little tasks. They're not as pretty looking as the mobile suggested edits, but have the same purpose.
Sdkb, I see no intention on the part of the WMF to do so in the article you sent. I have only seen mention of mobile and non-English languages, and none about mainstream Wikipedia. Tyrone Madera (talk) 21:42, 10 February 2021 (UTC)
Tyrone Madera, it's very typical for new features to be rolled out to small wikis first to beta test. They're then brought here once they're more fully developed. The WMF folks have communicated that this is their plan on talk pages, which you'll find if you poke around MediaWiki a bit. {{u|Sdkb}}talk21:45, 10 February 2021 (UTC)
Tyrone Madera -- Newcomer tasks feature in Czech WikipediaI'm Marshall Miller; I'm the product manager for the WMF Growth team. As Sdkb said, we're thinking along the same lines as you are: that Wikipedians on the web could benefit from a feed of simple tasks to do. It's helpful to hear that other people have that idea, because it reinforces that we might be on the right track with our work. What we've built so far is "newcomer tasks": a feed of articles that have maintenance templates saying that they need things like copyediting, wikilinks, or references. One way to think about it is that it takes the sort of articles that ProcrastinatingReader is talking about, and puts them in a feed that can filtered by topic of interest (see image. We've run experiments in smaller wikis showing that having this feed increases the engagement of newcomers, and so we're quickly spreading it to more wikis so they can benefit.
Going forward, we're adding a new kind of task. Instead of relying on maintenance templates, we're introducing algorithms that can identify articles that might need attention, and make suggestions for changes. The first one is for adding wikilinks, which we're building now (see image). We're also doing the beginning planning around one for adding images.Plans for "add a link" structured task
And like Sdkb said, we do build our features to work on both desktop and mobile web browsers. It's just that we talk about mobile more because it is a bigger design challenge, to get the same functionality on the smaller device. And eventually we want our team's features to be available on all wikis -- but we learn first on smaller wikis. Right now, they're on 18 Wikipedias, including some big ones like French and Russian. I've actually started a project page and discussion here on English Wikipedia, so that this community can start thinking ahead to having the Growth features (that page is due for some updates from me).
Anyway, I hope that anyone watching this page can join in the discussion either here on English Wikipedia or on Mediawiki.org. ProcrastinatingReader, I would definitely be interested to hear what you think about structured tasks. -- MMiller (WMF) (talk) 23:57, 10 February 2021 (UTC)
Sdkb, I apologize for being brusque in my response. Thank you for bearing with me, and thank you MMiller (WMF) for adding explanation, answering all of my questions, and responding so politely. I can't wait for this new feature! Tyrone Madera (talk) 02:14, 11 February 2021 (UTC)
@MMiller (WMF): Apologies for the delayed response. I think structured tasks, as a concept, is a great idea. I think starting out with a blank page is intimidating. I also think adding sourced content, when one has no idea about the MOS or all the other complex policies we have around here, can sometimes be difficult. Some editors will just revert something that looks ugly (ie, violates MOS) from a new editor, rather than clean it up and make it decent. That's just one example. I suspect a lot of people have knowledge to add but not the time or interest to get deep into Wikipedia to get it in the right format, so don't bother adding at all. Anyhow, if you guys can somehow lower the barrier for editing by using structured tasks I think that may be a big + for editor recruitment.
However, the screenshots on the right are not that. Tasks like adding links etc are not well done without context of the bigger picture. See WP:LINKRELEVANT / MOS:OVERLINK etc. People could just be adding links which, yes link to the right article, but shouldn't be linked. And some MOS style suggests only the first link should be linked, and the rest not. The challenge here is that the 'bigger tasks' (adding sourced content, copyediting, etc) seem to be difficult to create into structured tasks. But I admit I haven't spent much time thinking about how they could be. If you could figure it out, that would be a great feature. There's probably some more content-focused editors compared to me who may have better ideas on how this can be achieved. ProcrastinatingReader (talk) 12:11, 23 February 2021 (UTC)
Hi ProcrastinatingReader -- thanks for thinking critically about these ideas. I'm glad you think that structured tasks are generally on the right track -- that's the first step! I agree that there are lots of potential pitfalls around users having sufficient context and understanding policies. Many community members have been pointing those issues out as we go along, and we're doing our best to build in the appropriate guardrails to make a safe and productive experience for newcomers. For example, you mentioned that the algorithm could suggest links that shouldn't be made. The algorithm is built to incorporate that concern in that it is trained on existing wikilinks, so that it has a sense of which sorts of words and phrases tend to be linked. And for when it's incorrect, the full workflow has guidance and onboarding for the newcomer so they can evaluate the suggestions with some guidelines. With the example about only linking for the first occurrence of a word in an article, that's also built into the algorithm. I know we won't solve for everything, but we want to take a good first stab, get a sense of how newcomers do with this task, and start learning how to improve. We'll be piloting this on just a few wikis first (Arabic, Vietnamese, Czech, and Bengali), and so this will manage the risk. At the same time, though, I would like to start the discussion about bringing these sorts of features to English Wikipedia eventually. I'm starting that here, and I hope that you can watch or join in! -- MMiller (WMF) (talk) 21:13, 26 February 2021 (UTC)
Idea: discussion callout templates
Basically, templates that can go inline to call out a comment or particular groups of comments.
Discourse forums have something where an admin can post a message about a comment to everyone.
Suppose Alice opens a deletion nomination for article "Foo" and Bob writes something like "I like foo". A callout can provide a gentle reminder to remain on topic/stay civil. Of course, if it happens multiple times, then we can just use the uw series.
I think this would be a good option before page protection if a discussion gets derailed or off topic fast. Sometimes, even a great proportion good faith contributors make mistakes and may get off topic or uncivil, so giving a gentle reminder when the discussion gets heated can cool these discussions back down. Aasim (talk) 22:11, 12 February 2021 (UTC)
No thanks. These templates would be cold, patronising and impersonal – editors should compose these messages in their own words. This essay gives a further overview of the problems with these sorts of templated messages. – Teratix₵02:00, 13 February 2021 (UTC)
The goal is to give gentle reminders which is difficult to do if the discussion becomes heated. The goal of callout templates is not to bite or assume bad faith but to remind all editors about general wiki and forum ettiquette, especially if the discussion is, well, heated and derailed. These callouts would even be useful to remind a large group of new editors our purpose.
I think we should add information about how good the service is to this article. Spammer (talk) 00:25 2 January 1970 (UTC)
Putting a box around these makes them sound far stronger and more aggressive. It would be better to have just written a custom comment, if indeed it was worth making. In most cases above, making the callout was undue, and should have waited for more off topic/scope first — Preceding unsigned comment added by Graeme Bartlett (talk • contribs) 00:24, 15 February 2021 (UTC)
I don't feel like the admins would like this much, either. I'm thinking that there might become a backlog of "Stuff the admins must put callouts on." We already have quite enough backlogs. 🐔ChicdatBawk to me!11:30, 27 February 2021 (UTC)
Second Opinion Symbol Concept
Over at WP:GA they have support symbols (), oppose symbols (), and on-hold symbols () to represent the various results of a good article review. However, one neglected result is asking for a second opinion, which currently is represented with a neutral vote () which I believe does not make much sense and doesn't convey much. I propose an icon similar to one like this; forgive the terrible art, I made this on Chrome Canvass with a mousepad. Panini🥪14:17, 16 February 2021 (UTC)
To clarify for folks, if I understand correctly, this would only affect the Wikipedia:Good_article_nominations queue. You can see how it currently looks by going to that page and searching for the words "Second opinion" (there's one at the top of the World history queue now, but who knows if it'll be resolved by the time you read this). I think it's a nice idea. Ajpolino (talk) 20:34, 16 February 2021 (UTC)
Panini! I like the idea of a question mark too, though obviously it should be drawn with a bit more, uhm, accuracy than what you did. Elliot321 (talk | contribs) 01:07, 18 February 2021
DYK uses {{DYK?again}} to request another review(er). The symbol is .
There are also lots of symbols on Commons such as File:SegundaOpinión-Artículo bueno.svg which was intended for this purpose. It doesn't work so well at the size of the other icons – 16px:
I'm not sure how helpful such a symbol would actually be, but repurposing the DYK icon that Andrew pointed out seems like a good solution. The issue I have with the Panini's proposed image is that—when used at the same px size as support and oppose symbols—the 2 and ? would probably be too hard to see. Aza24 (talk) 02:46, 22 February 2021 (UTC)
I tried looking through the archives and couldn't find something like this, so I'm posting here.
In my opinion, the whole talk page format needs to be radically redesigned. It is just plain difficult to use. For one, an editor needs to use source code to be able to participate in a talk page, which is a high barrier in terms of time (inputting the proper syntax correctly) and knowledge (source editing is not intuitive).
Four big issues I see:
There is no easy way to input a comment and add it. Most other platforms you can type something in, click submit, and voila- you commented. On Wikipedia, you need to wade through the text and find where to write something, how to indent it, etc.
No nesting of comments. There is no way to easily find who said what in a talk page discussion, and this is especially problematic for long comments, improperly indented comments, etc. It also makes reading through a long page quite cumbersome.
No automatic signatures or notifications. If I make a comment, I would expect it to say that I wrote it and also to notify anyone else. Right now both those functions require someone to know how to do so and to take the time to add a ping, signature, etc.
Source editing. As mentioned above, it's a high barrier in time and knowledge.
In an ideal world, I'd see the talk pages look more like Reddit or any other platform with discussion boards. A short-term solution would be to enable Visual Editor, which is currently not enabled on Talk pages.
I know I can't be the only one who has noticed shortcomings with the Talk page format. What are your thoughts on Talk Pages and how they could be improved?
davidwr/(talk)/(contribs) 🎄 00:06, 24 December 2020 (UTC)
Please remember to assume good faith and stay civil. Admin (talk) 00:20 1 January 1970 (UTC)
), oppose symbols (
), and on-hold symbols (
) to represent the various results of a good article review. However, one neglected result is asking for a second opinion, which currently is represented with a neutral vote (
) which I believe does not make much sense and doesn't convey much. I propose an icon similar to one like this; forgive the terrible art, I made this on Chrome Canvass with a mousepad. Panini🥪 14:17, 16 February 2021 (UTC)
