This page contains discussions that have been archived from Village pump (proposals). 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.
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
The page would be more accurate because contributions imply that a person has a positive effect on Wikipedia. Using the term edits is more neutral. It is also a more accurate description of the page. Interstellarity (talk) 17:31, 14 March 2020 (UTC)
As usual, we would need some evidence that a problem actually exists, and that the problem is significant enough to warrant the change. It's fairly obvious that we apply the word "contributions" to all edits, so I don't see how many people could be misled or confused about its true meaning. Note that we would also have to deprecate the word "contributor", for the same reason. ―Mandruss☎20:20, 14 March 2020 (UTC)
Not worth the effort. If we were building Wikipedia from scratch, I would agree that "edits" might be better than "contributions", but per Mandruss above, there doesn't seem to be enough of a problem here for this to be worth the effort/cleanup to change. Sdkb (talk) 20:53, 14 March 2020 (UTC)
I agree that this would be too much effort for little or no benefit. The word "contributions" can include negative contributions as well as positive. Phil Bridger (talk) 21:17, 14 March 2020 (UTC)
@Interstellarity: If you are looking for a bullet point that says you can't remove withdrawn proposals that have replies, there isn't one. The guideline lists things you can remove, not things you cannot remove."The basic rule, with exceptions outlined below, is to not edit or delete others' posts without their permission." The "exceptions outlined below" for removal include prohibited material, harmful posts, comments by blocked sockpuppets (under certain conditions), and empty edit requests. They do not include other editors' comments in withdrawn proposals. ―Mandruss☎11:06, 15 March 2020 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Stop marking WikiProjects as inactive (but keep the defunct status)
Most of the WikiProjects on English Wikipedia have a low level of activity. Those that have a very low level often get marked as "inactive" via the {{WikiProject status}} template. This generally has the effect of driving off potential contributors and making sure that the WikiProject remains inactive forever. I would contend, however, that even WikiProjects with very low levels of activity (for example, WikiProjects about small countries) are still useful and often have lots of "lurkers" even if there are few active conversations going on. We shouldn't be discouraging people from using these collaborative resources by putting a big "closed" sign at the top of the page. I do think, however, that we should retain the "defunct" status for WikiProjects that are no longer relevant, for example WikiProjects connected to specific events. Kaldari (talk) 22:18, 6 March 2020 (UTC)
I wonder if some other metric could be used instead, like new articles in the project, number of talk page + subpage edits, improvements to article class for the articles within its scope, or similar. And instead of active/semi-active/inactive/defunct, we'd have highly-active/active/lowly-active + defunct as a separate category when the project is closed/merged elsewhere. Or perhaps simply just present the numbers in a "Recent Activity levels" table and do-away with classification entirely (save for defunct). Headbomb {t · c · p · b}22:55, 6 March 2020 (UTC)
WhatamIdoing's idea of response time on the project talk page is I think a good one: a community continues to exist if it can engage into discussion when required. I would suggest also looking at number of editors who engage, although in a low activity project it may be hard to gauge. I think page views of key pages such as style guidelines would help highlight ongoing relevance of the project. isaacl (talk) 23:06, 6 March 2020 (UTC)
I think that's a good point. I think pageviews is not necessarily helpful here; plenty of these projects might be rarely used (and not, for example, have style guidelines) but still get useful responses if used. The Drover's Wife (talk) 00:35, 7 March 2020 (UTC)
I would even be happy with just changing "inactive" to "low activity level". "Inactive" sounds to most people like the project is closed. Kaldari (talk) 01:16, 7 March 2020 (UTC)
I'd support a switch to "low activity level" or otherwise ceasing to use "inactive", which drives people away when the WikiProject may still bring some coherence to readers. -- econterms (talk) 01:24, 7 March 2020 (UTC)
This bit of basic logic/understanding keeps getting lost:
A WikiProject is a group of people (NB: not pages).
If nobody's actually there, then the WikiProject ceases to exist (even though the pages still exist).
A non-existent group of people cannot do anything for anyone.
I disagree. If a WikiProject was just a set of people, then as long as those people were still active, the WikiProject would be considered active. A WikiProject is basically 3 things: a set of people, a talk page, and a set of resources (categories, templates, WikiProject pages, etc.). Right now we judge whether a WikiProject is "active" or "inactive" solely based on whether the talk page has been recently used or not, regardless of whether the members of the WikiProject are still editing related articles, regardless of whether people are still using the resources of the WikiProject, and regardless of whether people are actively adding or updating those resources. The main reason I actually want people to stop marking WikiProjects as "inactive" is because people then mark the WikiProject templates as "inactive" which de-activates all the WikiProject categories and hides all the assessments. For most of the WikiProjects that I'm a member of, I don't actively post on the WikiProject talk pages, but I do heavily utilize the resources of the projects, especially the categories, assessment templates, hot article lists, etc. It's frustrating when these projects essentially get shut down and all of those things stop working just because no one is using the talk page. Kaldari (talk) 04:17, 8 March 2020 (UTC)
I can see both sides of this, but I do agree with WhatamIdoing that there's some point at which driving people away becomes the right choice. That's true with regard to resources, too, since those resources take effort to keep up to date. Sdkb (talk) 06:55, 8 March 2020 (UTC)
And that's what the state of Defunct is for. When people agree that the project is no longer useful, or is superseded by another. Headbomb {t · c · p · b}04:23, 16 March 2020 (UTC)
I am a novice editor and recently encountered the subject of inactive projects. Because of the page assessment system, the draw to revive the project was strong. So I am working on that. I was not dissuaded from working within an inactive project. The subject of the project matched my editorial interest. However; since it was inactive and was not set up to use the page assessment system, it was a lot to learn for a novice. Too much except for the social distancing of the COVID-19 and the resulting time I had available. I am too new to have formed an opinion about what to do here. What was frustrating were the number of tools and pages about the project system that are old, wrong, incomplete, or broken. I still haven't groked how to get the project watchers or cleanup reports working. For this editor inactive wasn't daunting. It served to alert me that if I wanted the project to serve its editorial purpose I would have to revive it. —¿philoserf? (talk) 16:03, 16 March 2020 (UTC)
RfC notice: proposal to delete all of MOS:JOBTITLES
Please see Wikipedia talk:Manual of Style/Biography#RfC on removal of MOS:JOBTITLES. This is a proposal to delete an entire section of MoS rather than continue trying to come to consensus about some unrelated disputes/confusions involving it. This could have an impact on at least hundreds of thousands of articles (resulting in reintroduction of capitalization of all job titles at any occurrences). — SMcCandlish☏¢ 😼 19:20, 13 March 2020 (UTC)
This is a completely inappropriate and misleading canvassing attempt. There is a proposal, after widespread unhappiness with the present guideline and neverending disputes caused entirely by its flaws, as well as no progress towards any kind of consensus replacement, to acknowledge that the current text doesn't have (and/or arguably never had) consensus and to wipe the slate clean before working on a replacement from scratch. SMcCandlish claiming that this is happening "rather than continue trying to some sort of consensus" is interesting from someone who has adamantly personally opposed even the concept of trying to amend the guideline to try to resolve some of the years of conflict it has caused. The Drover's Wife (talk) 19:45, 13 March 2020 (UTC)
Considering that OP is very quick and prolific in attacking other editors for canvassing, even for benign and properly neutral messages... not a great look. Herostratus (talk) 04:19, 17 March 2020 (UTC)
This was neither benign nor neutral, and predictably resulted in a bunch of !keep votes from numerous people who saw the entirely misleading summary of "This is a proposal to delete an entire section of MoS rather than continue trying to come to consensus about some unrelated disputes/confusions involving it", were alarmed, and didn't engage with the RfC or any other discussion whatsoever before !voting and passing on their way. Legitimate RfC advertising doesn't attempt to canvass for your own position and doesn't mislead people in an attempt to win !votes for your side. The Drover's Wife (talk) 04:42, 17 March 2020 (UTC)
Wikipedia Meetups postponed because of coronavirus?
Being a recent changes patroller is a good thing to stop vandalism. Not having enough RCPs will let a lot of vandalism slide though unnoticed, and it will stay on Wikipedia for quite a while. However, too much RCPS may lead multiple people going to the same diff in concern and if reverted, only one person would've been needed. Other diffs with problems, resolved, the RCPs that didn't do anything were essentially not needed. Everything needs to be in moderation.
Template:Vandalism information being displayed primarily on the recent changes page, and secondarily. at the top of the screen as a gadget or forced on.
The reason for this is because the two proposals will be proportional to each other. The 1st proposal will and should be proportional to the 2nd proposal. This is intended to make sure we don't get too much RCPs doing things they weren't needed to do at the moment when there are other RCPs, and could be doing things that are higher in demand.
So when the vandalism information is low (5), and there are high or sufficient enough RCPs, then it should mean there are enough and you should be doing something else that is higher in demand. When the vandalism information is high (1), and there are low RCPs, then it should mean more RCPs are needed at the moment and you really are needed.
When I've gone RCPing sometimes, when I see a problematic diff and try to revert, someone else has done it. {{SUBST:replyto|Can I Log In}}Copy and paste the code to reply(Talk)05:50, 16 March 2020 (UTC)
I disagree, for a couple of reasons. One is that it's already self-correcting - if you are still finding you are getting to fix edits, you might as well keep doing it as you are serving some purpose. If you are getting blocked too much then that would naturally push you elsewhere already. Additionally, RCP is a good maintenance activity as it is enjoyed by both experienced and "new to the backscenes" editors. I think this step would discourage the latter from picking up some helpful experience. I believe this overstates the problem, and would cause various negatives. I also am less than sure that everyone who decided there were enough RCP would naturally go on to do another backlog. Nosebagbear (talk) 19:57, 17 March 2020 (UTC)
What would be far more useful is if RCP went back to opening a new Tab on clicking any diff link there, rather than pointlessly taking one away from the Recent Changes page each time (- makes antivandalism on a mobile not worth trying). But, to address your suggestion, whenever you get revert conflicts, why not simply scroll down the RCP page and look for missed issues, rather than staying at the top to monitor just the five or ten most recent edits? It's amazing what gets missed and if you enable ' Navigation popups' at Preferences>Gadgets, you can mouseover any diff and very swiftly preview and assess each edit without ever having to leave the Recent Changes page. You can also preview the number and style of user contrubutions that way too. Nick Moyes (talk) 10:05, 18 March 2020 (UTC)
You say we should be checking all X (let's say 50 for example since that is the lowest # without going to your preferences) recent edits in recent changes, and then refresh the recent changes and check the newest X recent edits. Now what filters should be used? The default, none, or custom {{SUBST:replyto|Can I Log In}}PLEASE copy and paste the code to reply(Talk)18:44, 22 March 2020 (UTC)
Let's update all our COVID-19 data by bot instead of manually [crosspost]
Dear Wikipedia team,
Let me tell you I love the work you do. However, I do not understand why in every article about an important personality, artist or a celebrity there is a section called personal life. Some people edit this section as a gossip magazine. Why don't we focus on what people achieve and not edit personal information? This section should not exist.
Regards, — Preceding unsigned comment added by 139.47.103.237 (talk) 20:07, 26 March 2020 (UTC)
The above is correct (especially Vorbee's), but there are also quite a few individuals whose personal life is extremely tied to what makes them notable. Kim Kardashian immediately springs to mind as an exemplar. Nosebagbear (talk) 14:13, 27 March 2020 (UTC)
Starting tomorrow I've decided to launch this long term to try to bring our stub count down. Aiming for 50,000 expanded stubs over the decade, covering every country and topic. We need a mass of editors to make it work. If you support the idea please sign up and if you have any suggestions or want to discuss it please do so here. Cheers.† Encyclopædius08:42, 31 March 2020 (UTC)
Improve the Wikicode Tutorial.
I started my wikipedia account on around 2013 and it is now 2020 and I still face a lot of difficulty handling Wikicodes. I routinely visit many help articles, often copy-paste codes, often get anxious or frustrated to format.
I have systemised the difficulties I faced.
I tend to forget the commands and syntax.
There are too many detailed help pages but there isnt a brief list of necessary commands and examples.
The WP, help-pages, etc are too difficult to quickly scan and find the necessary codes.
I cannot yet handle big codes such as table, gallery, references (especially when same paper to link with multiple source such as DOI, PubMed, Wayback machine, etc), templates, etc.
Forgetting the source codes cause distraction and frustration.
Still, I am dependent on source code formatting. visual editors are fast but it does not give me the comfort to rectify existing minor errors. The source code editing is more dependable, customisable and explanatory.
In this circumstances; my solutions are:
1. Create a such a page where a single page will contain a list of Wikipedia features and the source code to do them.
Curently I am doing a sample in my sandbox . Please feel free to improve this article.
2. Wikipedia has a certain "do not scream" policy that makes many articles very unreadable. But It is necessary for me to use very large texts, highlights, very big headings, bold texts, combination of large and normal fonts within single sentence; to make necessary informations more accessible. So the "Do not scream" policy should be partly retracted from that help page.
3. To develop some excercise or sample lessons.
Assumingly it would be of great usage to many people worldwide, and will increase activity and will make wikipedia editing a less-distracting task.
I agree with your desire for a quick and simple guide to markup – there's the markup cheatsheet, which seems to accomplish the purpose of your draft page. I am firmly opposed to retracting the policies against excessive text modifications such as bolding, size changes and highlighting, as these ensure Wikipedia retains its clean look, avoids tackiness, and reduces the possibility of NPOV violations caused by editors' personal decisions to highlight a particular point. – Teratix₵10:47, 1 April 2020 (UTC)
Proposal: Wikipedia's April Fools 2020 cancelled due to coronavirus
Considering April Fools' is almost done in UTC in less than a couple of hours and it's already April 2nd in much of the world, this proposal is now moot. If next year there's going to be a proposal to ban or regulate AFD jokes, make sure to propose it long before the actual day. Narutolovehinata5tccsdnew 22:51, 1 April 2020 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
I think it might be a bit late for that, given that it's scheduled to start in 15 minutes. I also wouldn't trust that Google isn't just trying to fool us with a fake cancellation. And there's something to be said for allowing some levity in a bleak time. That said, we should be watching 2019–20 coronavirus pandemic and related pages like a hawk, and prepared to raise its protection level if needed (currently semi-protected). I know we don't normally do pre-emptive protections, but I worry that some vandal who changes the page for 30 seconds before being reverted is going to lead to a spate of "you can't trust the internet" articles in the media. Sdkb (talk) 23:47, 31 March 2020 (UTC)
Support. Despite it being April 1st UTC, the middle of a pandemic is not the time for jokes. Find some serious DYKs, G3 all the joke XFDs, and continue with the jerryfoolery on 4/1/2021. Catgirllover4ever (talk) 00:13, 1 April 2020 (UTC)
Strong Support. I was considering such a proposal earlier, and given the background and the disaster that struck this year's April Fools, it might be wise to cancel the event and sysop-protect the 2020 Fools page. --JavaHurricane04:59, 1 April 2020 (UTC)
Oppose - It's the one day of the year that the usually-serious Wikipedia gets to have some fun. As long as the jokes don't go beyond limit or be in bad taste (like joking about anything coronavirus-related) having some fun should still be allowed. It's just one day, we will go back to our regular scheduled boring and serious programming soon anyway. Narutolovehinata5tccsdnew05:02, 1 April 2020 (UTC)
Oppose (edit conflict) Hate to say this, but April 1st is going to happen whether or not the community consensus sanctions it. New editors have already caught wind of it. Also, older editors like myself recall conflicts about April 1 in less conscientious times; consensus to cancel April Fools proved impossible then, and it could very well prove impossible now. We need to set boundaries in place, and we need to be willing to delete pages and block people to enforce those boundaries, which people are. Also, everyone can use a good laugh, and stress relief during these difficult times.
Support- The time for making jokes finished four hours ago. What's that? American time is the only one that matters? In a global encyclopaedia? Too many time zones. Too many cultures. They aren't funny anyway. This is one of our more stupid customs. HiLo48 (talk) 05:20, 1 April 2020 (UTC)
Whatever time zone is used, it will still be out of synch with most of the world. This simply isn't a sensible place to play those silly games. HiLo48 (talk) 05:40, 1 April 2020 (UTC)
Because in one of the several threads about this matter (can't be bothered checking which one), one editor had said that the time for jokes was just about to start. It was 4 pm where I am. That editor had to be speaking from a time zone in the Americas. I know we are supposed to use UTC. My impression is that lots of others don't. And my basic point about time still stands. Whatever time zone is used, it will still be out of synch with most of the world. HiLo48 (talk) 21:36, 1 April 2020 (UTC)
That is definitely true. I started seeing the April Fools jokes at 5pm on March 31 my time, because I live on the Pacific Coast of the U.S. – Muboshgu (talk) 22:04, 1 April 2020 (UTC)
Also, I am aware this proposal is serious. I don't think it should be treated that way, since starting a "Cancel April Fool's" proposal 15 minutes before April Fool's is pretty laughable. Should have done that well beforehand. epicgenius (talk) 14:17, 1 April 2020 (UTC)
While I find myself in opposition to this proposal, I'll refrain from casting a formal !vote since I don't think we should seriously entertain a proposal that was filed 20 minutes before April Fools Day began according to Wikipedia time. And you can count me among those who don't see the logic in arguing that we can't have fun because of the pandemic. LEPRICAVARK (talk) 14:38, 1 April 2020 (UTC)
Neutral. I don't have a strong opinion on this proposal; I neither support nor oppose it. What I am concerned about is, well, plankton. That's right: plankton. A lot of people don't realize this, but if all the world's plankton (about 500 billion tonnes of biomass) were to be suddenly transported to North America -- AND WHO'S TO SAY IT WON'T BE? -- it would cover the entire continental United States to a depth of 20 metres, killing millions of people, destroying hundreds of dollars of property, and snuffing out most plant and animal life. Yet nobody talks about this. This is what we should be worrying about instead of some boo-foo twerps having or not having a joke day at some encyclopedia website. Yet the last time I tried to bring this up, all I got was the same old brushoff: "Oh Jesus this guy again" and "Excuse me, but why aren't you wearing pants" and "Sir, this is a Wendy's, you'll have to leave" and so forth. Nobody's willing to engage on the issue. So go have your joke day or not, I don't care. Herostratus (talk) 22:47, 1 April 2020 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Delete naturally stale Draftspace Redirects
If a Redirect exists on a Draftspace article, then it should be subject to the same rules as G13. As in, if the draft hasn't been edited for 6 months past the approval to Mainspace, then it shouldn't be exempt from G13 Speedy-delete.
I have been tagging pages with G6 instead, though when an admin comes along to delete it it will get deleted under G13. I feel that although this will increase initial workload on admins, the workload going forward will match the amount of articles that successfully make their way to the Mainspace. Thepenguin9 (talk)13:09, 31 March 2020 (UTC)
If the target article is moved again (causing a double redirect) then it means bots waste time fixing a double redirect which has no reason to be there anymore. It also helps clean up the space in general. Thepenguin9 (talk)15:26, 31 March 2020 (UTC)
I'm finding it a bit difficult to understand what you are getting at here (some concrete examples might help). Are you saying that humans should do more work to relieve those poor hard-working bots of drudgery? If so this seems to be getting the roles of humans and bots the wrong way round. Phil Bridger (talk) 15:36, 31 March 2020 (UTC)
Suppose Article X was originally a draft, and it was made back in 2014. It was accepted that same year, and the draft served as a redirect should there be any links to it (talk pages for example). That draft is then sitting unused, unaccessed, except for the times Article X gets renamed to Article Y, then Article Y#Topic, and so on and so forth.
By allowing Draftspace redirects to be eligible for deletion through G13, it would also allow said bots to compare the last edit (or creation date) against the current date, and if it is a redirect to automatically delete (or tag if not privileged) Thepenguin9 (talk)16:03, 31 March 2020 (UTC)
But we still need to consider links from outside Wikipedia to draft space. This is just one more piece of evidence as to why the experiment with draft space has failed. If we just kept doing things the wiki way, in which articles are created in main space and speedily deleted if hopeless, then this wouldn't be an issue. Phil Bridger (talk) 16:15, 31 March 2020 (UTC)
@Phil Bridger I can think of a few cases where someone would link to a draft from off-wiki, however wouldn't it be the same as Mainspace articles that were speedily deleted for some reason. Thepenguin9 (talk)16:29, 31 March 2020 (UTC)
I don't think it's the same at all. If the article exists, then the redirect will point to the article. BD2412T18:37, 31 March 2020 (UTC)
Oppose the proposal that I think is being made here. Redirects from Draftspace to the same target in the mainspace have perpetual value, to show someone who comes back to the draftspece in order to work on the draft that it is now located in the mainspace. Within-draftspace redirects are almost always useless (within draftspace pagemoves should be performed by admins/pagemovers, to allow the option of suppression of redirect creation), and in such cases I have no problem with tagging them as G6 and would strongly oppose the adding of (presumably hundreds each day of) them to the G13 process that is already quite strained just from non-redirect draft pages. FWIW, no one, and I mean no one, links to the Draftspace from outside WP. UnitedStatesian (talk) 06:30, 1 April 2020 (UTC)
Wouldn't the use of the redirect go down over time? So either 6 months or maybe longer after the redirect was made should the article be deleted? Thepenguin9 (talk)21:03, 1 April 2020 (UTC)
Science Photo Competition 2020 Russia targeting CentralNotice banner
Dear colleagues, this is a notification about a request to display the following CentralNotice banner to enWP visitors from Russia (IP targeting) @ 5 impressions per week max. It is made by Wikimedia Russia for the traditional annual contest running April 2-May 31.
I am about to go through the history of discussions on philosophy so that I can note the more significant discussions. In most cases I can point to particular sections with a link, such as Wikipedia:Village pump (proposals)#Itemising the history of discussion on Wikipedia pointing directly to this section. But in older discussions, sections were created by simply adding a line ----. The contents do not pick these lines up. To make it possible to point to these discussions individually, I can go through an archive page and replace each line with a section header. I could number them, 1, 2, 3, etc, rather than attempt to name them. I am proposing to make this a standard and acceptable thing to do. I am proposing to request a bot to do this for all archives. ~ R.T.G18:59, 5 April 2020 (UTC)
When a section is untitled I simply just add a header and something like "Untitled section YYYY"; you can do similar in your case. I see no reason to make this a standard thing, but I don't see a reason why it would be unacceptable. --Izno (talk) 19:18, 5 April 2020 (UTC)
I went ahead and just did it but AFAIR it is against the letter of the guides to alter an archive. ~ R.T.G01:53, 6 April 2020 (UTC)
Three TimedText files have been nominated for deletion at MFD. However, two of the regular editors there, User:SmokeyJoe and I, think that TimedText pages are a special type of files, and that the expertise to discuss them is more likely to be at Files for Deletion than at Miscellany for Deletion. User:Snaevar, who is the nominator, may also want to comment. SmokeyJoe and I think that the procedure for considering deletion should be revised to send the deletion discussions to FFD. Robert McClenon (talk) 01:37, 3 April 2020 (UTC)
Based upon just the name it would seem obvious, but it shouldn’t matter where the discussion takes place as long as there’s sufficient participation of knowledgeable editors. So, moving such discussions to FFD does not necessarily mean there will be better discussions. FFD discussions tend to involve copyright related matters for the most part; so, if that’s why those particular files ended up at MFD, then moving them to FFD might work out fine. If there are other concerns (as seems to be the case with those files), then moving the discussion to FFD might not lead to any better discussion, and the file’s may simply end up deleted by default after the FFD has run its course if nobody challenges the deletion. Unchallenged FFD nominations for deletion typically end up deleted by default. — Marchjuly (talk) 15:19, 4 April 2020 (UTC)
I think this type of nomination should remain at MfD. They are nominated so infrequently that we should be able to bring the relevant editors into the discussion every time. It is alos possible that MfD participants will become more knowledegable as a result. UnitedStatesian (talk) 17:32, 4 April 2020 (UTC)
Could someone please tell me what the hell "TimedText files" are? A link or a diff maybe? I'm sure I'm not the only one who would have to go searching to find this out. Phil Bridger (talk) 18:00, 4 April 2020 (UTC)
Well, if the files were vandalism, then what matters is that someone recognizes that they were vandalism rather than requiring a real discussion. Robert McClenon (talk) 02:35, 5 April 2020 (UTC)
"Uncle, what did you do during those weeks?"
"Myself? I spent the time criticizing people debating the proper forum to debate the proper process to get rid of that same low grade innuendo about mutual oral sex."
First, I would like to say that I think this is an awesome feature that Wikipedia is providing. Using Google to search, you type in a particular animal and if you're lucky it is offered in 3D where you have the option to view it up close. I can't wait until you have a Canada Goose available. They have a special meaning to me (long story).
However, I was thinking that you might want to get with the Sherwin Williams paint company as they have some pretty awesome 3D items/scenes/creatures that they've created utilizing their paint sample cards and animating them.
Here's the link to one of their commercials on YouTube.
Watch "Safari Animated TV Commercial - Sherwin-Williams" on YouTubehttps://youtu.be/jVfF-Ut9kdY
Rsargent7677, this is Wikipedia, not Google. We have no connection to Google, nor do we have any control over what appears in the search results on Google or any other search engine. While we could potentially host such images at our file-hosting sister project Wikimedia Commons, it's very unlikely that a commercial company would donate the images used in their advertising. Images hosted on Commons need to be legally released such that in future anyone can re-use them for any purpose, and very few commercial companies which have spent a lot of money developing their brand are going to donate that material such that it can be used by any competitor. ‑ Iridescent07:39, 14 April 2020 (UTC)
Because GFDL makes photos, videos and audio unusable for re-users Commons no longer allow GFDL alone. I see no reason to use GFDL on en.wiki. Not alone. Not together with other licenses. It only makes things more complicated.
I therefore suggest that GFDL is removed from all upload forms and any other relevant pages. I searched for GFDL in the MediaWiki namespace and found these as example:
A similar proposal was made 2 years ago but it was to forbid GFDL. Some supported it and some opposed it so it was not approved.
My suggestion is that we remove the licenses from the list of licenses so we do not encourage uploaders to choose GFDL. But GFDL will still be allowed if it is really needed. Should there be a few cases where GFDL is needed it can always be added manually using the code “{{GFDL}}”. For example if an important photo is found on a website and the only license there is GFDL. --MGA73 (talk) 19:49, 14 April 2020 (UTC)
@MGA73:For example if an important photo is found on a website and the only license there is GFDL.
A photo that was licensed with GFDL after 2018 and doesn't have a CC-BY(-SA) license.. Show me one. (that wasn't uploaded for the sole purpose of defeating this argument) - Alexis Jazz20:57, 14 April 2020 (UTC)
@Alexis Jazz: I can't. I would support a ban of GFDL but since some users voted against the proposal 2 years ago I would rather keep a backdoor open than to make the same suggestion again and risk that it is voted down again. I hope if we remove GFDL from the list of licenses then it will no longer be used. --MGA73 (talk) 21:19, 14 April 2020 (UTC)
I know, I was just mentioning it in case anyone would think that there actually are GFDL-licensed photos outside Wikimedia. I support your proposal, but to a degree it already happened. Currently Special:Upload doesn't seem to have GFDL in the drop-down list (besides CC BY-SA 4.0 + GFDL) and FileUploadWizard only allows it for works from a third party. (or again combined with BY-SA 4.0, that option is actually the default)
There is no advantage to GFDL, so I would support also removing that dual license from the list. There is a theoretical disadvantage: a re-user could jump through the hoops of GFDL, create a derivative work and that derivative work couldn't be imported back into Wikimedia nor could it reasonably be re-used by others because of the problems with GFDL. I'm not sure about removing the option for GFDL-only from third parties in FileUploadWizard: it could be a legitimate option for, say, a logo from a software manual. - Alexis Jazz23:42, 14 April 2020 (UTC)
I would support discouraging the use of the GFDL-only for media wherever possible, and that includes removing it from the license pickers. Of course, I would also support banning own-work GFDL-only files like Commons has done. In my view, use of only the GFDL for new images is an attempt to prevent the reuse of freely licensed works through overly burdensome license terms and is inconsistent with the goals of this project. --AntiCompositeNumber (talk) 21:20, 14 April 2020 (UTC)
Since we already have taxa in correct order with Template:Automatic taxobox, can we use this info to create something like {{Automatic cladogram}}? The idea is you put two parameters, name and depth and it would automatically draw a cladogram for you.
For example: {{Automatic cladogram|Dinosauria|2}} would create a cladogram with Dinosaur as parent and two taxon ranks below. Dinosaur(talk)🌴🦕🦖-- 20:34, 15 April 2020 (UTC)
Option 2 has already been implemented in a past RFC. The proposal does not seem to be made in mind of the past discussion and justify why a rejudging of consensus is needed. And since option 2 is currently favored (as it was essentially what the past RfC came to consensus on), there is no point in letting this discussion continue. (non-admin closure) Kirbanzo(userpage - talk - contribs)23:16, 15 April 2020 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
How should Wikipedia cover endorsements of political candidates during elections?
Wikipedia should exclude endorsements of poltiical candidates during elections.
Certainly not option 3, which relies on non-reliable sources, but I would support option 2 as long as inclusion meets WP:WEIGHT. This is Wikipedia policy for any article, and I don't see why it should be any different for articles about political candidates. Phil Bridger (talk) 19:09, 15 April 2020 (UTC)
In articles on political candidates, races and elections, editors commonly include long lists of endorsements, often sourced to primary sources such as Tweets. What do we learn in 2017 United States Senate special election in Alabama when we read that the Republican candidate was endorsed by Steve Bannon, Roger Stone and others? This is not knowledge, it is merely information. I strongly believe that this is not encyclopaedic. It's also not neutral, and potentially a BLP issue as we have no context for the endorsements (a problem if endorsing a controversial candidate, for example). In the current polarized political climate, endorsements add practically nothing anyway, they are remarkable only if they go against strict tribal lines. I think we should leave this to the campaign websites and focus non the issues, not the peanut gallery. Guy (help!) 17:59, 15 April 2020 (UTC)
I see that you have avoided saying that this is particularly about American political candidates, but I have only seen these endless lists of endorsements in articles about Americans. Given that WP:ARBAP2 is in force we should have less of this policy-defying content in this area than in others, so something is not working as it should. Phil Bridger (talk) 19:09, 15 April 2020 (UTC)
Rhododendrites, do you think there's any chance of enforcing an RfC with a dozen or so participants over more than a thousand articles in what is likely to be the most contentious election cycle in history? Guy (help!) 22:01, 15 April 2020 (UTC)
I think that for lists of endorsements, we have a clear RfC outcome. It was not only at the village pump, but listed at CENT. That's about as solid as we're going to get. If someone doesn't want to abide by that outcome, they can start a new one to see if consensus has changed. — Rhododendritestalk \\ 22:16, 15 April 2020 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Proposals to redirect WP:Introduction/WP:Tutorial and the Welcoming Committee welcome
You are invited to join the following discussions:
The Wikipedia logo on the top left of each page displays the slogan The Free Encyclopedia in title case (i.e. with each word capitalized). This is at odds with the English Wikipedia's guideline of sentence case, and differs from the logos of most other Wikipedias (especially the other major languages), which overwhelmingly use sentence case for the slogan (see Wikipedia:Slogans). It also seems incongruous with the subtitle that appears under the page title, which reads From Wikipedia, the free encyclopedia in proper sentence case. To that end, should we modify the logo image such that the slogan reads "The free encyclopedia", in keeping with the standard convention used across enwiki? — RAVENPVFF·talk·10:34, 16 April 2020 (UTC)
You'd need to take any proposed change to the unified mark (the combined death star logo and "The Free Encyclopedia") up with the WMF. It's a legally registered official mark, and as such even the smallest change to it has significant legal implications and would be decided at a pay grade well above that of anyone here. ‑ Iridescent12:24, 16 April 2020 (UTC)
Whats the status on the font? If (and I do mean if, I have no strong feelings on it) we wanted 'The free encyclopedia' could we not just use the resized globe trademark and print underneath? Only in death does duty end (talk) 19:09, 16 April 2020 (UTC)
I'm going to have to query what problem we're really trying to fix - are significant amounts of people of people actually viewing it as incongruous? Nor am I inclined to think that consistency is obligatory either with other projects on it or a need for it to match other titles in Wikipedia - the wording under the logo is substantively different to a content title, if nothing else. Nosebagbear (talk) 20:53, 16 April 2020 (UTC)
Checkuser notification
Hi everyone,
A lot of editors in Wikipedia live in regions where free speech is considered illegal. Many editors don't want their private information to be exposed. It has come to my attention that certain users who have 'checkuser' permission are able to see our private information like our location, type of the device that we are using, IP addresses, etc. Some of those 'checkusers' could be working for governments.
To stop misusing the checkuser tool, I am proposing that editors get a notification that includes the username of the checkuser everytime or most of the time they are checked. The notification will appear on the notification button. I don't mind if instead of automatic notification, the notification will be a message on the talk page (possibly using a standard notification template).
Why this is helpful
This will limit the misuse of the tool.
I think we are all concerned about our privacy, we don't want unknown users in Wiki to see our private information.
A lot of editors live in areas where saying stuff can put you in jail or even kill you, checkusers are not known people and could be government agents.--SharʿabSalam▼ (talk) 13:10, 13 April 2020 (UTC)
Not a good idea IMO - a lot of checkusered people engage in harassment when they are called out, and we already have processes (such as the Arbitration Committee and the meta:Ombudsman commission) that monitor the use of the checkuser tool. I don't see how such a notification would work better than these, and it would invite retaliatory behaviours. Jo-Jo Eumerus (talk) 13:18, 13 April 2020 (UTC)
Agree that this isn't a good idea. CU's also have to sign a confidentiality agreement that is legally binding upon being granted the privileges. CU's are subject to Stewards and, as seen by the recent Bbb23 case, Arbcom, whose members are generally known to WMF and are also CU's themselves. Given there are legal ramifications involved in these rights, I don't think any sort of guideline that is developed locally will have anywhere near the same sort of teeth. Blackmane (talk) 13:24, 13 April 2020 (UTC)
I don't see how checkuser notification would invite "retaliatory behaviours" more than a 24 hours block for editwarring etc. I think editors should get a notification every time their private information gets exposed. By the time this would become normal and editors won't be angry if they got a notification. They would be angry if it was unreasonable which is why I want this notification so that unreasonable checks stop.--SharʿabSalam▼ (talk) 17:00, 13 April 2020 (UTC)
This seems like a solution in search of a problem - there are simpler ways for a government to figure out your identity than the long process of creating a persona which becomes sufficiently trusted to gain checkuser. Also, keep in mind that the data available to a checkuser is exactly the same as the data which any website operator can pull out of their access logs. creffett (talk) 17:11, 13 April 2020 (UTC)
@Creffett: There are certainly governments which are playing the long game when it comes to things like this. I'm not supporting this particular proposal, but a healthy dose of paranoia when it comes to government surveillance is a good thing. We have had long-time admins exposed for socking. I would be surprised if we didn't currently have admins today who are agents of governments. Getting CU approval is a much higher bar than passing an RfA, and they are subject to greater ongoing scrutiny, but it's also a more valuable target so reasonable to believe more effort would be put into obtaining it. A 10-year project is not beyond major governments. -- RoySmith(talk)17:54, 13 April 2020 (UTC)
RoySmith, yeah, I'm not disputing that governments play the long game. I guess my cynicism about government involvement here comes from experience working with decentralized web of trust cryptography stuff (like SKS) - you see a lot of tinfoil hattery about "what if the spooky G-men subverted such-and-such" (many of which were very contrived scenarios). To the best of the collective knowledge there, there never really were government attempts to subvert the network. Instead, the design decisions they made (focused almost exclusively on keeping governments from subverting the system) left the keyserver networks wide open to spam, to the point that the main keyserver networks are basically dead. Point being, I tend to be very skeptical when someone thinks their open-source, free-knowledge project might be targeted by a government for infiltration or whatever. Yes, I recognize I'm speaking from a Western perspective, and that other countries do have strict speech laws (and enforcement thereof), which is probably also part of the disconnect. creffett (talk) 18:07, 13 April 2020 (UTC)
If we're going down the bribery route, why not bribe a sysadmin? Pulling logs that way wouldn't be tracked by the software, and you might be able to get some kind of monitoring software onto the backend servers. We could go down the rabbit hole all day on this, of course, my point is that I think there are other threat vectors which are more likely than a government-controlled/subverted CU. creffett (talk) 17:41, 13 April 2020 (UTC)
This is claptrap. The point is to limit, not to completely stop governments from taking our data because that's unrealistic. This is like if Facebook said, we aren't going to take measures to protect your data from governments, organisations, etc. They can steal your data by paying money to Facebook employees.--SharʿabSalam▼ (talk) 18:01, 13 April 2020 (UTC)
(edit conflict) Any website can pull your data but they can't identify who is the editor. For example, an editor who writes stuff about the Saudi government which the Saudi government doesn't like, the Saudi government won't be able to pull the data of the editor unless they have someone who is a checkuser in Wikipedia, who works for them and gets money from them. There is no other way to know for sure that the data belongs to the editor except if they have a checkuser in Wikipedia.--SharʿabSalam▼ (talk) 17:22, 13 April 2020 (UTC)
If you think the Saudi government or the likes of Saudi government won't bother do that then see the case of this Twitter user Turki bin Abdulaziz al-Jasser, he was tortured to death by the Saudis and the Twitter office in Dubai was the one that leaked his data.[1]. This is a Twitter poster, not Wikipedia editor. I assume that Wikipedia is more powerful than Twitter.--SharʿabSalam▼ (talk) 17:36, 13 April 2020 (UTC)
They literally had employees in Twitter company.[2] Do you really think there is no chance they have checkusers in Wikipedia? They probably have.--SharʿabSalam▼ (talk) 17:40, 13 April 2020 (UTC)
Example CU log
There seems to be a lot of misunderstanding here about what Checkuser does. It's not some magic tool that allows elite superusers to pry into editors' souls; it gives a small handful of vetted and monitored users—all of whom are bound by legally-binding agreements regarding how it's used—to see some very limited information in very limited circumstances. Just to put things in perspective, this is what CU results actually look like. The most any hypothetical hostile intelligence agency could find out about you is which browser you're using and (assuming you're not using a VPN) what your IP address is; yes, if someone edits from work it theoretically could reveal their employer, but if someone is editing something so sensitive that a hostile government is taking an interest, they almost certainly shouldn't be doing so from work in the first place (and the system administrators at their workplace are more likely than Wikipedia checkusers, by a factor of about a million, to be the ones to call them out on any problematic edits). "Checkuser is not magic" isn't just some mantra we say to reassure people; it's the straightforward truth. ‑ Iridescent19:00, 13 April 2020 (UTC)
I know what checkusers can see. I am saying that every time or most of the time an editor gets checked he/she should be notified. Checkusers should send a notification to the editor who got checked.--SharʿabSalam▼ (talk) 19:18, 13 April 2020 (UTC)
I appreciate this has been closed, but I'm going to comment regardless to explain why "notifying averyone who's been the subject of a checkuser" not only won't happen but can't happen. Every time the Checkuser tool is used, it generates at least two checks; firstly the check on the account to determine which IP address(es) they're using, and secondly the check on the IP(s) to see if other accounts have also been using it. Were we to post talk page notifications, we'd essentially be publishing both the IP address, and a list of every other editor editing on a similar IP range, for every editor who's ever been accused of sockpuppetry (e.g., were someone to see a "you have been checkusered" notification pop up on my talk, all they would need to do is look at the contribution history of whoever posted the notification to see which other notifications were posted at the same time, and they'd immediately have a full list of all IP addresses I'd used in the past three months and every other editor to use any of those addresses). The legal and ethical implications of this would be severe, to the extent that even if we somehow did get community consensus to start doing this, WMF Legal would immediately veto it. ‑ Iridescent09:14, 14 April 2020 (UTC)
This is why I said it should be a notification in the notification button. I don't mind if it was a notification in the talk page but I wouldn't support posting it in the IP talk page.--SharʿabSalam▼ (talk) 09:33, 14 April 2020 (UTC)
Currently we have checkusers who could be government agents. The WMF should take measures in assuring the privacy of editors in this site. I believe if users are notified every time their data gets exposed, this would make it less likely that their privacy would be exposed without any valid reason (like in the recent case of Bbb23).--SharʿabSalam▼ (talk) 09:39, 14 April 2020 (UTC)
I'm not terribly opposed to the proposal, though I suspect (and am starting to imagine) there are disadvantages, and possible privacy problems, somewhere along the line. However I think you should drop the government agent part of your proposal. There is no way you can tell whether anyone, anywhere, is being run by a government agency, even if you were to be in possession of their supposed full name address and profile photo. For the record, I am not one. But let's assume you received a notification that you were checkusered by 'one of the team'. What would you do with this information? -- zzuuzz(talk)10:02, 14 April 2020 (UTC)
For the record, I am not one....sounds like the type of thing a government agent would say - burn the witch! Nosebagbear (talk)
I'm inclined to concur with zzuuzz - what do you do with this information? Either the information is already public (if you keep an eye on SPI, at least), or there is a significant chance they won't be able to tell you because, post-check, it turns out you aren't involved and they can't explain without bleeding private information of others. Nosebagbear (talk) 20:59, 16 April 2020 (UTC)
Phone number and verification
discussed in at least two other venues: higher on this page and at ANI, closing per the principle that two venues (one on the content of the thing, and one on the behaviour) seems more than enough. --Francis Schonken (talk) 12:27, 17 April 2020 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Hi, I believe that one of the most annoying problems in Wikipedia is sockpuppeting. Sockpuppets use IPs and accounts. I wonder if we asked for verified phone number when creating an account, would that limit the number of sockpuppets who use accounts?. Twitter, Facebook and YouTube do it, why not Wikipedia?
I know this isn't the right place to propose this but I want to see if this is a good idea or not so that I can propose it in another venue.--SharʿabSalam▼ (talk) 01:25, 17 April 2020 (UTC)
SharabSalam, restore my comment, and please don’t refactor/remove my comments again. That wasn’t a personal attack; in fact it falls far short of the definition. Your template warning and threat in the edit summary was also inappropriate. Other editors are allowed to raise possible CIR concerns. Symmachus Auxiliarus (talk) 11:32, 17 April 2020 (UTC)
You think I am incompetent because I suggested verified phone number when creating an account? No wonder that you have got a NPA warning from the founder of Wikipedia.--SharʿabSalam▼ (talk) 12:04, 17 April 2020 (UTC)
For the record, despite the numerous contributions, especially in copy editing, that IP users make... I’m one of those that would prefer everyone register an account, if only to have true anonymity and not a readily identifiable IP address. However, as Phil said, this proposal would violate WP:BEANS. It would make them more readily identifiable to hostile parties, especially if there were a hacking incident. We can’t in good conscience allow such a thing. Anonymity is one of Wikipedia’s strengths. It allows people to edit in politically sensitive climates, and contribute without a reasonable fear of retribution. Tying a mobile phone number to an account, and allowing that to be the only option, is absurd. Anyone who commits to an identity, identifies with WMF, or ties personal information to an account is welcome to do so, but it should be voluntary. Symmachus Auxiliarus (talk) 12:25, 17 April 2020 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Proposal to create a "random page" button for pages that need editing
There has been a need for a "random page" button for the pages that need expansion, grammar or spelling checks, photos, etc. A "random page to edit" button should be made on the community portal, where the pages that need editing are. This should also been instated on the lists of pages for more specific edits, such as the list of pages for pages that need photos, spelling checks, etc.
Technically every article on Wikipedia needs editing, an article is almost never "complete". We already have a random page button. 331dot (talk) 20:34, 14 April 2020 (UTC)
I have checked Perennial Proposals and Wikipedia:FAQ but cannot see that has there ever been a proposal for, or plans in future for, a Wikipedia version of Encyclopaedia Britannica's Propaedia volume. Effectively, what I mean is the creation of a page or set of pages providing a large-scale structure or hierarchy of Wikipedia articles (and thus, effectively, human knowledge) arranged in a consistent, logical way so that people get even more out of Wikipedia and it can direct in-depth study/research on a single large topic area. I'm imagining a completed version would look something like a much larger, more complex, more detailed version of Table 1 in the Propaedia article. For those not familiar with the Propaedia itself, a PDF of its 1970s/1980s edition is downloadable here: http://www.markklingman.com/docs/britannica_propaedia.pdf. Clearly, the closest equivalent that currently exists on Wikipedia is Wikipedia:Contents/Portals but I may not be alone in finding this hard to navigate, not consistent across all topics, and incomplete. Another possibility for developing a Propaedia-type resource for Wikipedia would be to extend the excellent sidebars available against some articles (e.g. Finance) which give a mini-hierarchy of articles on a specific topic, into a single mega-structure setting out a hierarchy for all or most articles. Not sure if this idea is insane or not, it just feels to me that although the 6 million plus articles of English language Wikipedia is an incredibly successful and exciting experiment- indeed, one of humanity's greatest achievements- it does seem to be a pretty 'flat'/horizontal structure, with nothing to distinguish between the relative importance of articles (e.g. a 'random article' search would be as likely to return an article on a tiny village with a population of 20 people as it would the main 'geography' article), and that some kind of more vertical hierarchy could add an important new dimension. Looking forward to the responses of other Wikipedians. JH1977 (talk) 12:42, 18 April 2020 (UTC)
The category structure, with Category:Articles as its root, puts a largely hierachical structure on top of our encyclopedic content. It is a rather tree-like graph, ideally a directed acyclic graph but, I expect, with the occasional cycle. Not all nodes in that graph are relevant for the purpose, but I think it can serve as the basis for a navigation tool. If we tag the nodes that are not relevant for the purpose (e.g. Category:Wikipedia pages referenced by the press) and add snappy one-line descriptions for each relevant node, we are already halfway. --Lambiam15:46, 18 April 2020 (UTC)
Is Wikipedia:Contents/Outlines what you're looking for? A vertical hierarchy such as you describe wouldn't be appropriate for Wikipedia; the most important article is the article on the topic you're looking for, and efforts to declare which articles are "important" rarely end well. (To stick with your example, I can find out about Geography anywhere and don't need Wikipedia for that, and consequently the top-level article isn't particularly important, but if Wikipedia ceased to exist I'd have great difficulty finding detailed information about Chat Moss or Calabozos.) ‑ Iridescent17:32, 18 April 2020 (UTC)
Strict hierarchies are inappropriate for Wikipedia's work; there was a categorization scheme on the Main Page in 2001-2002ish but this has since been removed, as have subpages in the mainspace. Wikipedia:Contents/Outlines is a survivor, as are portals, but overall there are no plans to have a large-scale categorization scheme (nor should there be IMO). – John M Wolfson (talk • contribs) 18:05, 18 April 2020 (UTC)
Thanks, interesting context. I would point out in defence of structured hierarchy, though, that those for smaller 'families' of articles (like the Finance side panel example I gave above) seem to be popular/work well- or are they more controversial than I imagined? If there is no consensus/appetite for a Propaedia-scale mega-structure or hierarchy, is there an argument for improving consistency/coverage of these smaller side panels and/or is there anywhere on WP with a list or collection of all side panels across the site for those who nevertheless crave some degree of categorisation? Thanks.JH1977 (talk) 18:14, 18 April 2020 (UTC)
Re your earlier "nothing to distinguish between the relative importance of articles" - there's WP:VITAL and assessment of importance by wikiprojects. I don't think we need another scheme of importance ratings of articles. Re "all side panels" see Category:Navigational boxes. DexDor(talk)20:28, 18 April 2020 (UTC)
Some of the arguments above basically state that something along the lines of Propædia is useless for Wikipedia. It appears to me that for the same reasons it should then be useless for the Encyclopædia Britannica. I don't know if it is; I haven't used it. I do know, though, that it may be hard to find information on a topic if you don't know the appropriate terminology, and therefore also no plausible article name. It may also be hard to get a broad overview of a topic; sometimes the main article on a topic omits to mention important subtopics. Finally, no one has suggested to make use of an importance rating of articles. But when using categories as the basis for a navigation tool for structured access to topics, some categories are really irrelevant and unhelpful to the user. --Lambiam21:02, 18 April 2020 (UTC)
There is a Wikipedia-wide assessment of importance of certain articles at WP:VITAL, and a search engine (either Wikipedia's or Google's) could help to conjure up a given term based on a description, which is where I've learned many terms on my own. – John M Wolfson (talk • contribs) 22:44, 18 April 2020 (UTC)
How to emphasize important articles
Thanks DexDor, being a novice, I wasn't aware previously of WP:VITAL, which I think is even closer to what I was getting at and addresses many of the issues I had with the portals, outlines etc. In which case, might it therefore be possible or desirable to make WP:VITAL easier to find and/or navigate to a) from the en.wikipedia.org homepage and b) from the articles themselves (e.g. a header at the top of Earth stating 'This is a WP:VITAL Level 1 article, or similar?) Thanks also for the link to the Navigational Boxes categoryJH1977 (talk) 06:01, 19 April 2020 (UTC)
@JH1977: That's a great question. I'm going to turn this into a new sub-section to try to focus attention on it.
I've thought about this a bit recently with regard to the left sidebar redesign. For one thing, Wikipedia:Contents badly needs a redesign. That may include merging it with Wikipedia:Featured content, but it could also involve better emphasizing the vital articles there. The random article tool could also be involved. I do kinda like how it gives you a sense of e.g. just how many Wikipedia articles are about tiny towns, but it'd also be nice to have random article buttons that sampled only from vital articles (or only from featured content). {{u|Sdkb}}talk07:21, 19 April 2020 (UTC)
@DexDor: yeah, I've been trying that, but I can't get it to play nice with Village pump (proposals)/Archive 167, which is needed to switch to the page link itself. Will ask at the VPT, and add a button to WP:Contents once I get it working. {{u|Sdkb}}talk00:32, 20 April 2020 (UTC)
@John M Wolfson: Level 1 is so small it's not super useful; if linking to that level, better to just list out the full 10. Levels 3, 4, and 5 could each have their usefulness. In my ideal vision, there's an option for each of them at the contents page, along with options for good articles, featured articles, and truly all articles. There can only be one link on the sidebar, though (unless we get advanced enough to be able to have a sub-menu that opens when one hovers over the random article link, which would be amazing but seems beyond our current capacity). And the nice thing about the sidebar link is that you can click it as many times as you want in rapid succession, whereas a link at the contents page takes you away from the button every time you click it. {{u|Sdkb}}talk00:32, 20 April 2020 (UTC)
Reconsidering the 7-day waiting period for requested moves
There's a practice that I like to engage in which I think would make a good guideline for the community as a whole, which I call paying actions forward. The basic idea is that if an editor takes an action that will require the work of others to resolve, that editor should undertake some of the work that helps resolve similar actions taken by others. For example:
If you open a deletion discussion in some XfD space, find another deletion discussion in that space and take some action towards resolving another discussion.
If you are an administrator or an XfD closer, find a pending discussion to close.
If you are not someone who can close a discussion, find a pending discussion to which you can contribute an opinion which will help form a consensus (or solidify the absence of consensus).
Similarly, if you open a move request, find another move request and take some action towards resolving the request.
I believe that adopting a guideline supporting this practice, even if it is merely advisory rather than a mandate, would help prevent backlogs from growing in these areas, because editors who were generating a larger share of the work would then feel more of an obligation to generate a larger share of the resolutions. BD2412T23:56, 16 April 2020 (UTC)
That's how WP:DYK works. You get a few freebies, but after that, for every nomination you make, you're required to review somebody else's. Seems to work well. -- RoySmith(talk)00:44, 17 April 2020 (UTC)
I like the spirit of it, and think an essay would do the trick. My worry with giving it the force of guideline or policy is that it would disincentivize nominations which we really don't want. — Wug·a·po·des01:04, 17 April 2020 (UTC)
If that's effective at DYK, it's because it's required. Relatively few editors will do more than required merely because of some non-binding "advisory", particularly when they see few others doing it. Anyway, you would have to define which areas are to be covered by the advisory, and that's a subject for WP:VPI. ―Mandruss☎01:07, 17 April 2020 (UTC)
I'd like to find some middle ground there, such that those who make a lot of XfD or RM-type nominations get nudged with increasing firmness towards helping out on the other end. BD2412T19:10, 19 April 2020 (UTC)
Sounds good to me. The editors who engage in drive-by behaviors - as in only doing XFD/RM noms without weighing in on other noms or throwing up droves of maintenance template tags without actually doing any of the fixing-up, etc. - to me they're a drag on the project. Yeah. Nudged with increasing firmness sounds good to me. Shearonink (talk) 19:40, 19 April 2020 (UTC)
That exactly the reason why I have my doubts about this. Editors who make unresearched drive-by nominations will also make unresearched drive-by comments in other discussions if they are encouraged to do so. Phil Bridger (talk) 19:51, 19 April 2020 (UTC)
As an outside perspective, I quite strongly approve of the RM system and other similar processes, because I am (and I imagine many others are) simply not WP:BOLD enough. —烏Γ(kaw)│21:21, 19 April 2020 (UTC)
Absolutely terrible idea - articles get nominated for deletion because people feel they don't belong - including articles that are copyvios or breaches of our BLP policy - this proposal would keep these damaging articles here for longer and it would strengthen the idea that Wikipedia's decision making processes are just for the privileged elite.Nigel Ish (talk) 19:58, 19 April 2020 (UTC)
@Nigel Ish: Can you explain how speeding up the resolution of discussions and reducing backlogs would "keep these damaging articles here for longer"? BD2412T20:00, 19 April 2020 (UTC)
I would have thought that was pretty obvious. It would discourage people from nominating pages for deletion if they don't have the time or the wish to participate in other discussions. Phil Bridger (talk) 20:03, 19 April 2020 (UTC)
The proposal discourages people who are not regulars from getting involved as it effectively discounts their opinion and encourages the system to be gamed to dismiss new people getting involved and attack them - giving the way people behave, it will be gamed and abused, just as things like WP:BEFORE are gamed and abused. This will merely make AfD and the like to be closed shops - what we want is to make it easier for more editors to get involved and not get attacked.Nigel Ish (talk) 20:13, 19 April 2020 (UTC)
Suppose the proposal was reworked to avoid discouraging anyone from getting involved, and only encouraging people who are already involved to a certain degree to become more involved? BD2412T20:21, 19 April 2020 (UTC)
Oppose - if people are making good XFD/RM noms then that's good (regardless of what other wp edits they make); if people are (repeatedly) making bad XFD/RM noms then they should be encouraged to stop doing that. Division of labour works well in wp (different editors specialise in doing different tasks). In the real world we don't generally say that someone can only do one voluntary activity (e.g. being a special constable) if they also do another voluntary activity (e.g. being a prison visitor). Also, if something like this was put into practice it'd spawn a whole bueurocracy of monitoring, warnings, appeals etc. DexDor(talk)20:16, 19 April 2020 (UTC)
Interesting. Suppose the proposal was reworked to expressly avoid any mention of monitoring, warnings, or appeals, and to merely focus on encouragement? BD2412T20:19, 19 April 2020 (UTC)
Then that would be very different to the "those who make a lot of ... nominations get nudged with increasing firmness towards ..." idea proposed above. DexDor(talk)20:46, 19 April 2020 (UTC)
Write an essay, not a guideline. I'd also suggest a softly, softly, written one, as I feel that would be vastly more effective than any alternate mechanism. We don't need AfD etc with DYK mechanisms (the only other place that might benefit could be something like GAN, though the drive is working well recently) Nosebagbear (talk) 08:14, 20 April 2020 (UTC)
Part of the problem here is that RFA has become such a constipated process. It used to be that prolific deletion taggers would eventually run for adminship, if their deletion tagging was OK they would then usually get the deletion button if there were problems with their deletion tagging they would be reminded of that. If we could persuade a few more prolific deletion taggers to run at RFA we wouldn't need to talk about reciprocity. But if we are talking about it, then it is worth gently encouraging those who start AFD and MFD discussions to take part in a few that others have started, if only to maintain their calibration - the process of taking part in AFDs that others have started, checking for sources and !voting keep or delete accordingly is a good way to set your AFD tagging threshold in line with community norms. As for template bombers, I'm sure somewhere we have a userbox or something for editors who aim to remove as many article maintenance templates as we add, it would be good if such an essay encouraged taggers to aim for the situation where their Wikipedia editing skills had grown to the point that they resolved more such problems than they added. ϢereSpielChequers08:40, 20 April 2020 (UTC)
Oppose any kind of compulsion or "nudging with increasing firmness". We want to encourage newer editors (or editors unsure of the nuances of our labyrinthine deletion policies) to start XfD discussions when they're unsure, rather than start slapping inappropriate CSD/PROD tags around or wade into deletion debates without understanding the relevant policy. Unless I'm seriously misunderstanding the proposal, this would have completely the opposite effect in that we'd be de facto ordering people who aren't familiar with how deletion works to take part in deletion debates regardless. This would likely result in a flood of "keep, it exists" and "delete, I've never heard of it" comments, which would both make more work (not less) for the closing admins, and lead to increased bad feeling when people are told to comment on deletion debates, comment in good faith, and are then told their opinions aren't valid. With the exception of a couple of serial deletion-taggers—who can be and are dealt with at ANI as straightforward disruptive editors—"people who nominate things for deletion without participating in deletion debates" are somewhere around number one million on "List of current issues affecting Wikipedia". (I assume none of the people saying that the quid-pro-quo system at DYK is some kind of model have actually looked at DYK lately? It's a straightforward trainwreck of people promoting obvious errors without bothering to fact-check it for themselves, in the rush to get that all important QPQ checkmark. I don't know if he still does, but The Rambling Man used to keep some data.) ‑ Iridescent08:57, 20 April 2020 (UTC)
I did indeed used to keep tabs on the error rates, there was typically something wrong with around 20% of material promoted. I'm not allowed to discuss this specifically at all thanks to restrictions but I can assure people that QPQ is just about the worst idea ever implemented around some parts. The Rambling Man (Stay indoors, stay safe!!!!) 09:07, 20 April 2020 (UTC)
Comment – I think there's a compromise to be had by broadening the encouragement to include "repayment" in any appropriate area, even if it's a different area than the one the "request" is made in. I think the common thread between nominating an article for AFD, starting an RFC, or tagging an article, is that each of those is a solicitation for volunteers to spend their time addressing some issue, e.g. by !voting, closing, or clearing a tag. As I understand it, the principle behind WP:PAYITFORWARD is that if an editor solicits other editors' time, then the editor should also respond to other editors' solicitation of editor time. But, I think that response doesn't have to be in the same area as the solicitation–it's better if it's in whatever area the editor is competent and interested in. So, an editor might nominate an article for AFD, then PAYITFORWARD by uploading a requested image, copyediting a tagged section of an article, or providing a source for a {{cn}} tag–whatever the editor feels comfortable doing. It can be in the same topic area or a different topic area, but the point is, if you add to "the queue" in one area, help clear "the queue" somewhere else–wherever you can. Levivich[dubious – discuss]05:29, 22 April 2020 (UTC)
No edit should be made to wp just to "respond to other editors' solicitation of editor time". Every edit should be to improve wp - either directly (e.g. by adding information to an article) or indirectly (e.g. by making a useful contribution to a discussion). DexDor(talk)11:30, 22 April 2020 (UTC)
Thankfully, they're not in any way mutually exclusive. Your edit above this one, for example, both responded to an editor's solicitation of editor time, and improved the encyclopedia. Responding to editors' requests for editor time is improving the encyclopedia. It's the basis of collaborative editing. Levivich[dubious – discuss]12:51, 22 April 2020 (UTC)
Proposal for a standard for archiving bots to make MonthlyArchive better
After having had to update the MonthlyArchive template so it works into 2020, I've proposed some changes to it that would hopefully reduce Wikipedia server load, stop someone having to edit MonthlyArchive every year to add the new year into the template wikitext, and make the entire process a whole lot prettier. However, these changes would require that archiving bots be modified to be compatible. If you're interested, please do take a look at my proposal and let me know your thoughts.
Concern was raised at Template talk:COVID19 GS editnotice about the current version of the editnotice potentially scaring off good faith new editors who want to contribute. On this, I am in agreement with Daniel Mietchen on the editnotice talk - seeing a huge red warning talking about discretionary sanctions, a phrase a new user has almost certainly never heard before but sounds very legal and scary, I imagine would be very offputting to a new user. However, I also recognise that it's incredibly important that the seriousness and gravity of the discretionary sanctions that are imposed is conveyed, even (and perhaps especially) to new users who aren't extensively familiar with policy.
As such, I have written a new proposal for what the editnotice might look like, which you can see at Template:COVID19 GS editnotice/Proposed. I believe it still conveys the gravity of the situation - and, indeed, still uses the red warning template and large red warning text - but offers friendlier wording in the body, along with a link to the user's talk page to add on the helpmepreload under a COVID-19 sanctions-specific header.
I'd love to hear people's thoughts on this, and for anyone who can to improve further on my work! Hopefully this should encourage people to contribute, but to contribute positively. | Naypta✉opened his mouth at21:36, 23 April 2020 (UTC)
I actually like this quite a bit; thanks for the work Naypta! I'll give more thorough feedback later, but in general I think this accomplishes the goal of clearly warning editors while helping them learn how to not accidentally cause problems. — Wug·a·po·des21:58, 23 April 2020 (UTC)
Thanks for the ping Wugapodes, this is certainly up my alley. I definitely agree that there's room to make the notice more welcoming. Here is my sense of how a good faith new user might interact with the current notice: "Okay, this is a strong warning, it looks like bad things will happen to me if I don't comply with the right rules. But what are these rules? *clicks on "Wikipedia policy and editorial norm" link, which goes to the WP:List of policies directory* Yikes! There's no way I'm going to learn all these policies. I'll just give up and hope someone else makes the change."
The fundamental thing we're trying to convey is "do not disrupt this page or you will be blocked", so that's what I think should go after the colon. Everything else is details/disclaimers. For being more welcoming, I could see us including a link to WP:COMMONSENSE somewhere to say that good edits are welcome, and perhaps a quick "if you're reverted, take it to talk" to explain WP:BRD, which is probably the most pertinent norm.
And I like the idea of including a link to talk for editors who aren't confident enough after reading the message to make an edit directly. It should probably go to the article's talk page rather than the user's talk page. {{u|Sdkb}}talk00:12, 24 April 2020 (UTC)
I think WP:RECKLESS might be a better target than WP:COMMONSENSE. My worry with pointing new editors to IAR-related stuff is that they'll not understand the spirit of it, and that in this case we actually really do want them to follow the rules. WP:RECKLESS makes clear that we want them to edit, but to be careful while doing it, which is the point of (especially COVID) discretionary sanctions. — Wug·a·po·des00:19, 24 April 2020 (UTC)
Yeah, WP:RECKLESS (aka WP:CAREFUL) might be a good link, although I think the need to be careful is already communicated clearly by the warning icon. And I forgot that WP:COMMONSENSE goes to a subsection of the what IAR means page, so maybe not. We don't need a link to explain common sense (it's an intuitive concept), so maybe just write something like "constructive edits are welcomed". {{u|Sdkb}}talk00:56, 24 April 2020 (UTC)
Hi Sdkb and Wugapodes, this is all some great thinking. I've updated Proposal 1 with some of these ideas - could you take a look? Cheers! | Naypta✉opened his mouth at08:05, 24 April 2020 (UTC)
I think it does a better job explaining the restrictions. I don't think it's less scary, if that's the main intent, though. "You may be blocked if you do not." in big, red letters is more intimidating that the previous message, which has no red letters and smaller text. (Plus combined with the previous sentence, it is saying you may be blocked for not reading the notice carefully.) Personally, though, I don't mind a more scary introduction, in order to draw attention. I suggest rewording it to something like "You must read this notice carefully before editing. You may be blocked if you fail to comply." (I also don't like "click here" as it is contrary to best practices for web pages, but I appreciate it can be useful when dealing with less technically-inclined editors.) isaacl (talk) 23:46, 23 April 2020 (UTC)
Agree. The red text looks more alarming to me than the previous version. It has a better overall explanation though. --Gtoffoletto (talk) 00:07, 24 April 2020 (UTC)
@Isaacl and Gtoffoletto: I made some changes to address these concerns, do you have any further feedback? I tried to make it less alarming but still firm. The "click here" bit is still in there, only because I do think it's more obvious for new editors who may just skim it. — Wug·a·po·des00:33, 24 April 2020 (UTC)
Personally, I don't like It is very important that edits on this page and similar pages strictly comply with Wikipedia policy. because it's important for all pages. I still think it's more scary, but that's OK to me.isaacl (talk) 03:34, 24 April 2020 (UTC)
@Isaacl: That's entirely fair, I was thinking that when writing it initially, but couldn't see any other way of getting it across! I've taken some new ideas from Proposal 2 and this discussion into Proposal 1 - could you take another look? Cheers :) | Naypta✉opened his mouth at08:05, 24 April 2020 (UTC)
Strong Oppose: There isn't much of a difference. The problem I see is about a "huge red warning talking about discretionary sanctions, a phrase a new user has almost certainly never heard before but sounds very legal and scary, I imagine would be very offputting to a new user." and to get rid of it. All your proposal does is literally that. I don't know what new user {{replyto}} Can I Log In's(talk) page would react to either one of those two, but this proposal only renforces the "huge red warning" that you say you want to get rid of. 00:53, 24 April 2020 (UTC)
@Can I Log In: Hi, thanks for your contribution! I added that text to try and encourage people to read the notice, but I can see why that might seem to have the opposite impact to what I've written :) Sdkb had some great ideas in proposal 2 to refine that text, replacing it with "You will be blocked if you disrupt this page" rather than the more generic form - what do you think? | Naypta✉opened his mouth at08:05, 24 April 2020 (UTC)
The goal I see is to try to get something like Uw-disruptive1. But all I see in proposal 2 is Uw-vandalism4im. SO if you really want the cool big red blocking scary discretionary sanction notice, I made a new proposal to target disruptive editors. Good-faifth editors aren't intended to disrupt, so then target the ones who do. {{replyto}} Can I Log In's(talk) page15:31, 24 April 2020 (UTC)
I just added a proposed version of the notice (proposal 2) which iterates on some of the things we've been discussing here. As I suggested above, it replaces the "please read this" plea with a direct "You will be blocked if you disrupt this page". I assume most good faith editors will go "okay, I'm not here to disrupt, so this doesn't apply to me" and won't read beyond that, and that's okay — the purpose of the notice isn't to teach people how to edit, but to ward off disruptive editing. For general advice on editing COVID-19 articles, I think we should create a separate notice to go right below it that'll be friendlier and link to the WikiProject, WP:MEDRS, etc. {{u|Sdkb}}talk02:09, 24 April 2020 (UTC)
I like directly warning that disrupters may be blocked. I prefer the phrasing in the first proposal that starts with listing the problematic behaviours by editors. This puts the focus on the editors reading the edit notice, which I think makes it easier for them to relate to the message, rather than reading about what administrators ("whoever they are", a neophyte may think) may do. isaacl (talk) 03:39, 24 April 2020 (UTC)
@Isaacl: Good point. I switched the ordering so that proposal 2 also now lists behaviors first. I didn't take quite as many liberties as in proposal 1 with the way I listed them, since the remedies use specific language to spell out what's considered disruptive, and I don't want anyone to be able to try wikilawyer their way out of a violation. {{u|Sdkb}}talk07:01, 24 April 2020 (UTC)
I've pinged you both earlier replying to things in this thread, but I've updated Proposal 1 with some of these ideas. I think proposal 2 looks great, the only things which I thought it was missing which were present in proposal 1 was the slightly greater level of guidance for new users, who are likely to be editing COVID-related pages, and also a link to WP:MEDRS which I strongly think should be in there. Take a look and let me know what you think! | Naypta✉opened his mouth at08:05, 24 April 2020 (UTC)
Also, since we're at the Village Pump where we can/should discuss more than just COVID-19, the general template for discretionary sanction edit notices is at Template:Ds/editnotice (I think), and our discussion here should probably result in changes to it. {{u|Sdkb}}talk02:13, 24 April 2020 (UTC)
Agreed - personally, I think whatever changes are made here, similar changes should be made over there. I do think we need to be slightly careful with that though, as there may be some circumstances where the harsher and less friendly wording really is apt, for very persistent vandalism etcetera. Perhaps two or more different versions of the DS editnotice ought to exist. | Naypta✉opened his mouth at08:05, 24 April 2020 (UTC)
I can see cases where you would want two versions to work with, but very persistant vandalism would already have led to their being booted. But use of 1 after GF or at least not wilfully damaging versions, and the other after an instance of vandalism (or similar) would make sense. Nosebagbear (talk) 09:35, 24 April 2020 (UTC)
@Sdkb:, ah apologies on my behalf. That makes somewhat more sense. I suppose you'd get some edge cases (across the excessively growing hoard of COVID articles/GS articles) where both are applying, but that might be an unavoidable issue. I realise implementation isn't dictated by you, but would you suggest usage be considered by the most common issue or the aggressive one (i.e. if at least 20% of the issue is persistant vandalism, put that)? Nosebagbear (talk) 18:58, 24 April 2020 (UTC)
@Nosebagbear: My preference is to have two notices, one for each use case. That's what I've done in proposal 2 — the general notice (top) is targeted at good faith editors seeking advice, whereas the GS notice (bottom) is targeted as disruptors. {{u|Sdkb}}talk19:04, 24 April 2020 (UTC)
Okay I've criticized Proposal 1 and 2 for having a "huge red warning talking about discretionary sanctions, a phrase a new user has almost certainly never heard before but sounds very legal and scary, I imagine would be very offputting to a new user." and being like Uw-vandalism4im. If the purpose here is to target the disruptive editors and not the new good-fafth editors, why are we having these? So I made proposal 3 to do exactly what we all wanted to do. Go after the disruptive editors. {{replyto}} Can I Log In's(talk) page15:31, 24 April 2020 (UTC)
I agree that the purpose of this notice is to be the "bad cop" in a sense. I'm not sure proposal 3 does that better than the other two, though. And that's why I moved WP:MEDRS to the general proposed notice in version 2, rather than leaving it in the discretionary sanctions notice. WP:MEDRS is absolutely good advice that we should be plugging to editors of COVID-19 pages, but my sense is that it's not what people are getting blocked for. Counterintuitively, I think moving it to the less flashy notice will actually cause more people to read it, since as noted above, most good faith editors (who know that they are good faith) are going to disregard the general sanctions notice after they read the first line and realize it's not targeted at them. {{u|Sdkb}}talk18:30, 24 April 2020 (UTC)
Sorry, the nested bulleted and unbulleted items above have skipped some levels and there isn't an obvious way to fix that without changing the order of some posts, so I'm starting afresh. Intentionally disruptive editors already know they're flouting norms of behaviour and can be sanctioned for that (depending on their familiarity with Wikipedia, they may not be aware that the authorization of general or discretionary sanctions enables a more rapid response to occur). So I don't believe the initial sentence in proposal 3 will help, nor the repeated exhortation at the end. And it still has red letters, whereas the current notice has none (that doesn't bother me, but supposedly it's one of the criticisms that proposal 3 is addressing). isaacl (talk) 19:15, 25 April 2020 (UTC)
Proposal: Allow wikilinks and other wikimarkup from tooltip text to be displayed on WP image pages
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 think the vital articles project should be abolished. Firstly, the project is not very active so there aren't many people watching over it. Secondly, we already have a list of articles tailored to all languages: meta:List of articles every Wikipedia should have. I don't think it makes much sense to have articles important in each particular language anymore. I think we should just rely on one list going forward. Interstellarity (talk) 20:42, 25 April 2020 (UTC)
Oppose on this sole reasoning as the basis. I've just gone through Wikipedia:WikiProject Vital Articles/Right/Participants, and more than 20 of the users there have recently (within the last few months, many of them within the last week) contributed to Wikipedia, so the editors making up the project are fairly active. I can understand the consternation over the perceived duplication of effort at meta:List of articles every Wikipedia should have, but I'd raise several points in regards to that: a) articles that are considered vital on the English Wikipedia may not be considered vital elsewhere, and vice versa - especially true for wikis with much lower activity - and b) some articles may, in fact, be significantly more vital in different linguistic contexts. For instance, under WP:VA#Language (28 articles), we can see that the vital articles project has made the determination that Indo-European languages are a focal point at level 3 of vital importance, with only 3 non-Indo-European languages appearing - whereas this clearly would not be the case on, for instance, Chinese, Japanese or Arabic Wikipedia; for good reason, as on those wikis Indo-European languages are not likely to be as important a research interest as they are on Indo-European language wikis. In short, I'm not sure the project is inactive enough to merit its killing off, and as languages are inherently a point of cultural difference, what's "vital" will vary across the different wikis, so I'm not sure replacing it with a metawiki alternative is the right approach even were there to be insufficient numbers of people. Naypta ☺ | ✉ talk page | 21:20, 25 April 2020 (UTC)
Oppose. The English Wikipedia's Vital Articles list/project is actually much more active than the Meta-Wiki list is, so that seems like a rather silly reason to abolish it. And the two lists serve different purposes. The Meta list is a list of articles that every language version of Wikipedia should have, while the English list is a list of the articles that are the most vital for the English Wikipedia to improve the quality of. Rreagan007 (talk) 23:57, 25 April 2020 (UTC)
Oppose. As a member of WP:VA, I can give moral support to the idea that we should be consolidating "top articles"-type lists and better collaborating between them and integrating with things like importance ratings. (This proposal calls to mind the discussion at Wikipedia talk:WikiProject Biography/Core biographies#RFC: Subpage of Vital Article project?, which it looks like everyone just forgot about.) But my sense is that WP:VA is the most active such list, so it should be the one leading the others, not abolished. I also have some qualms about how useful it is for Wikipedia as a project to debate whether we ought to consider society, culture, or language more important, and discussions like that seem to be a lot of what happens there. But there are moments when the project shows its usefulness (for instance, going through the list recently allowed me to make several nominations at Wikipedia:Today's articles for improvement/Nominations). Much of that usefulness is conditional on bots working properly to add talk page boxes, update article ratings, etc., and although there's been some activity on that lately, I think some features may still be broken. There are also ways we could make better use of the lists, such as by improving the random page tool to have an option to link to Vital Articles at a given level (currently stalled here), and automated tools we could develop to help us catch missing articles. Overall, what I think is needed is just a bit of innovation and a little less focus on the debates, but we don't need to get rid of it. {{u|Sdkb}}talk05:29, 26 April 2020 (UTC)
Oppose. Outlines of core knowledge are useful for readers and editors. Language-specific lists are needed especially outside the natural sciences and mathematics. The project is not inactive. --Thi (talk) 07:16, 26 April 2020 (UTC)
Oppose pointless closure of an active project, which (for editors) helps identify Wikipedia-wide articles that need attention and (for readers) which articles one ought to read to gain knowledge about the world and specific topics. Headbomb {t · c · p · b}14:41, 26 April 2020 (UTC)
Oppose - it is a useful (and long term) project. Maybe in the future Vital Articles, WP 1.0 and WikiProject importance assessment are all superseded by a superior alternative. Until then, I see no reason to kill Vital Articles. --MarioGom (talk) 17:04, 26 April 2020 (UTC)
Moral support I think that VA tries really hard but in the end I've found it to be a pointless and subjective criterion. buidhe22:17, 26 April 2020 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Topic Questions as Content Suggestions
I have a suggestion I think folks might find useful. Sometimes I find an article that covers the area of my question, but it does not answer my specific question. I wish that I could post a question/missing information post to a topic to help those maintain the content make it a more complete article.
Along with the (Read, Edit, View History) tabs there could be another tab where logged in readers could leave comments or questions. It should be made clear that this is not a discussion forum where quick responses would be expected. When contributors make changes in the Edit tab, they could subscribe to posts on the comments tab.
I write a fair amount of documentation for my company. I do get those “what about this?” questions. I am happy to get those questions, and I say “thank you, I’ll add that.”
This article is twice the size any article ought to be. It furthermore harps on excessively on ecclesiastical Gothic - misleadingly titled "cathedrals" - to the exclusion of other types and uses of this type of architecture. This discussion deserves a new page, under Gothic Churches, which would also discuss those Gothic churches that are deemed cathedrals. I have requested the split, but the article also has numerous other issues and faults. It is primarily the doing of two editors, whose edits and additions dwarf the content added by anyone else, and the article, which is a popular one, and its talk page, require attention from other editors for balance and objectivity. — Preceding unsigned comment added by GPinkerton (talk • contribs)
Can we discuss (again) allowing subtitles on Wikipedia pages?
Hello,
I've been editing pages for bee species in both enwiki and frwiki and I noticed that frwiki allows you to add subtitles. This is handy for species since both the common name and the scientific name can be captured at the top of the page (e.g., Blatte germanique and Andrène à deux taches).
Subtitles on frwiki can be added using the (template:Sous-titre/Taxon). I was wondering if the enwiki community was interested in developing a similar template for this site? I know that adding subtitles to pages has been discussed in the past (Archive_79#Subtitles_on_Wikipedia) but I'm just wondering if there's interest in continuing this discussion.
More generally, thinking about this, I have some reservations. The purpose of a title is to convey the topic of the page, and in almost all cases that's possible to do fine without a subtitle. In the ones where a disambiguation is necessary (e.g. Turkey (bird)), I don't think there's any major usability barrier, and for species names, the one missing from the title is incorporated in the first line/infobox anyways, so it's not hard to find. Overall, this would be a major undertaking, and I'm not sure I see a clear benefit to make it worthwhile. I do appreciate the suggestion, though — it's good to keep brainstorming ideas like this! {{u|Sdkb}}talk20:33, 28 April 2020 (UTC)
Frwiki isn't really a software component, it is just a template javascript hack to put text up above the normal window, so it isn't great for accessibility. — xaosfluxTalk19:03, 28 April 2020 (UTC)
It strikes me that the amount of time and effort that it would take to build in a feature properly into MediaWiki to produce these kind of subtitles would be better used in making infobox templates better such that the information that would be conveyed by the subtitle, and more, would be better displayed to the end user. I'd be very interested in hearing any scenario in which subtitles do something a good infobox can't - it might well be there are loads, but they don't immediately come to me. Naypta ☺ | ✉ talk page | 21:36, 28 April 2020 (UTC)
I don't know if it's just my device, but it seems there could be a problem with how the template works in the mobile view. As mentioned, there is already a "subtitle" provided by Mediawiki: the Wikidata short description. In the desktop view the template subtitle is right below the article title fr:Blatte germanique, but in the mobile view Blatte germanique that spot is occupied by the short description, and the template subtitle is much lower and below a tool box. In the Android mobile app the template subtitle is shown awkwardly below the first paragraph of the lead. -kyykaarme (talk) 09:30, 1 May 2020 (UTC)
A bot to remove stub templates from non stub articles and to update the talk page tags
Discussing this with Rosiestep yesterday, there's literally thousands of wrongly assessed articles inflating our stub count. A lot of editors don't remove the stub templates or update the talk pages once expanded. I propose that a bot scans our entire list of 3.3 million odd stubs and removes stub tags from all articles with over 1.5 kb of readable prose and updates the talk page tags to start class. I also propose a permanent bot which will automatically update the talk pages to start class once an established editor removes a stub tag from the article and vice versa, when somebody updates the talk page project parameters to start class it removes the stub tag from the articles. I think it's important to be consistent, the current situation is a mess and it needs sorting out asap, particuarly with the Wikipedia:The 50,000 Destubbing Challenge running now.† Encyclopædius10:05, 29 April 2020 (UTC)
Support automation, however I doubt that a specific threshold is going to fly. It would be possible, and only slightly more complicated, to use a moving threshold: for instance, remove the stub tag if the article has grown by over 100 % and over 1000 characters since being tagged. Nemo11:00, 29 April 2020 (UTC)
Comment The problem that immediately strikes me with this is that this would require us to have a much stricter version of WP:STUBDEF - because effectively, this bot would be setting one. To do that, I think, requires very strong community consensus - because it has quite broad-ranging implications for what we describe as a stub. Not that that's inherently not a reason to do it - and I have a great deal of sympathy with the issue you take with the current approach, which basically boils down to "you know it's a stub when you see it" - but it does need a lot of thinking about, I think. What makes a stub a stub may be greatly different across articles, and I'm not sure that a pure measurement of text length is a good way of dealing with it. Naypta ☺ | ✉ talk page | 11:03, 29 April 2020 (UTC)
Yes, every article is different. But if an established editor removes a stub tag after an expansion I think it would be easy to get a bot to recognise that it is no longer a stub and update the talk page. Of course it could have been expanded to B class and wrongly assessed as start, but you know what I mean, we need something at least to sort much of this mess out and the false listings. I think pretty much universally 1.5 kb of prose is accepted as no longer a stub, if there was a bot to measure readable prose and remove stub tags from them all and update the talk pages to start class that would solve a lot even if there might be some questionable individual cases.† Encyclopædius11:58, 29 April 2020 (UTC)
To start with, a bot which scans all of the articles in the subcategories of Category:Stub-Class articles and removes stub tags and updates talk page tags for all entries which are more than 1.5 kb of readable prose. That would be very helpful.† Encyclopædius12:02, 29 April 2020 (UTC)
@Encyclopædius: you would have to specify how the bot would determine what is "readable prose". Those of us who regularly edit articles about genera, families, etc. of organisms often have to re-add stub templates to articles that consist of almost nothing but a list of subtaxa (e.g. a list of species in a genus article). The list can be long, but this doesn't stop the article being a stub. Length alone is not a deciding factor. Peter coxhead (talk) 13:39, 29 April 2020 (UTC)
Comment Can we break down the problem. It is a good idea to let a bot remove the stub tag from substantial articles. What it does next is contentious. Possibly the simplest solution is to tag it with Lengthy article automatically destubbed.
It does not become a Start Class article if it has no independent references- or if the reference does not support the text. I have been destubbing UK schools. Using the length criteria, repeating the content of the lead in the new section 'Description' I can change a length of 600 to 1500- and its still a stub, and conversely I can reduce a 'Start' to a stub. But I also see substantial, referenced articles that have incrementally built up that are still catted as stubs. (Teachers genetically won't self-assess articles they have improved without firm criteria- I am sure that applies to other professionals) That is where the bot could be helpful.
It is certainly 'picking the low hanging fruit' to use English place names as examples, and unfair not include tables in the length criteria- encyclopedias do need lists of elected councillors. Look at Pratt's Bottom that is padded with unsourced material to qualify- but the bulk of the info is in the table- so is not counted. Still a lengthy article detector bot is a good idea- the question is what does it do next?
If it is going to run- I am sure it could add some useful analysis to the talk page. You guys are the experts- but my favorites are, missing infobox, missing image, missing source- relies solely on primary related sources, sources possibly too dated to be of use. Editors ploughing though the new backlog lists we have created will at least have a clue to the issues before committing them selves.ClemRutter (talk) 15:44, 29 April 2020 (UTC)
Lengthy book articles with no references are considered Stubs by WikiProject Novels and WikiProject Children's Literature; and if they are written by a woman, then WikiProject Women Writers also considers them to be Stubs (e.g. for purposes of the WPWW talkpage template classification). In this case, adding an infobox or a photo won't change the class, but adding four non-bare references will. For more context, Encyclopædius and I have been discussing destubbing here, User talk:Rosiestep#Using ORES for destubbing. cc: EpochFail. --Rosiestep (talk) 16:36, 29 April 2020 (UTC)
@ClemRutter, I can tell you now that using a bot to tag missing infobox, missing image would backfire massively (and have a decent chance of getting someone blocked). As Encyclopædius can testify, we have a serious ongoing issue with people turning up on articles where there's a broad consensus that the topic is too complicated to summarise in infobox format, trying to "fix" them by adding infoboxes, and getting aggressive or upset when they're promptly reverted; having some kind of bot-added "this article needs an infobox" flag would make matters much worse because editors would reasonably assume that by adding an infobox they were addressing an error. The same issue holds (albeit to a lesser extent) with images; for many articles, particularly historical biographies, there literally is no appropriate image, but a "this article needs an image" flag would encourage people to think they were being helpful in "no image exists of this 13th-century nun or of anything connected with her, but we know she was born in Barnsley so I've added a photo of Barnsley Town Hall" edits, which again would lead to new editors who are genuinely trying to be helpful being reverted en masse and getting confused and annoyed. ‑ Iridescent19:03, 29 April 2020 (UTC)
I have a bold counter-proposal. Why not use ORES predictions directly? ORES can predict what quality level an article currently is and it's pretty accurate. We could use the predictions directly to track status and progress. For when ORES makes a mistake, I'd like it to be simple to override ORES' prediction. E.g. if the talk page assessment is greater than ORES' prediction or it matches some criteria for freshness, use the talk page assessment. What do you think? --EpochFail (talk • contribs) 17:45, 29 April 2020 (UTC)
@Iridescent: Too right! :-) No "needs infobox" parameters please. Generally I'm not a fan of automated assessing but there's tens of thousands of articles which are really not sorted out here, I can understand drawbacks to doing things enmasse but there must be a way to improve the situation.† Encyclopædius19:20, 29 April 2020 (UTC).
EpochFail, nice! (a) Recommendation #1: Can this table be presented with links; and if I click the link for 1846 Stubs, it'll give me another table which has links for each of the 1,846 stub articles? (b) Here User:WP 1.0 bot/Tables/Project/Women writers we see that there are 36,865 talkpages with the WPWW talkpage template, but the above table totals 22,448. Do you know why that is? --Rosiestep (talk) 20:44, 29 April 2020 (UTC)
Rosiestep It could definitely be formatted more clearly. I think we'll need a bot to produce it. I wonder if WP 1.0 bot might be extended for this. I think the reason for the difference in count is likely that many of the articles in the set haven't been edited in a long time. We started storing article quality predictions in the database about a year ago. Any article that hasn't been updated in the last year won't have a prediction. We could back-propagate the quality predictions to get full coverage. That part I can certainly help with if we get interest from a bot dev. --EpochFail (talk • contribs) 20:09, 30 April 2020 (UTC)
EpochFail, IMO, back-propagating for full coverage makes sense. Let's see if a dev comes along who's interested in taking this on... maybe at this month's Hackathon? --Rosiestep (talk) 20:34, 30 April 2020 (UTC)
Leaning oppose, as I do not think that "not-a-stub" is a call that a bot can make, but I would support generating a list of stub-tagged articles that have grown substantially since being tagged for quick human review. We had a project like that before once, where we listed several thousand articles that had gone the longest without human attention, sorted by factors such as article length and number of human editors. I believe we sorted through that list pretty quickly. BD2412T21:03, 29 April 2020 (UTC)
Oppose I like stub templates and always add them when I start an article. Their good points include:
they are attractive to the eye, typically having an appropriate icon and a simple easy-to-read message
they encourage readers to pitch and help expand the article without being too preachy or pushy
they go at the foot of the article so they don't get in the way
they help classify the article
These features make them better than the obnoxious banner tags which you find at the head of many articles. Rather than removing them perhaps we could enhance them. If an article has grown past stub stage then maybe the template could auto-detect this and adjust its message accordingly? We still want readers to help develop articles until they are perfect. The classifications which get buried in the project templates on the talk pages could be echoed so that the reader can see and understand the level of the article. Andrew🐉(talk) 22:50, 29 April 2020 (UTC)
@Andrew Davidson: Did you not read the proposal? This has nothing to do with obnoxious tags at the head of artiles nor expanding stubs. "Rather than removing them perhaps we could enhance them". There's thousands of articles which are start class or higher which are wrongly tagged as stubs. Of course we want to see articles improved but I'm basically trying to do something to bring the stub count down which includes both destubbing/improvement work and identifying wrongly classified stubs. Your oppose and "liking of stub tags" disrupts my overall effort on this.† Encyclopædius16:10, 3 May 2020 (UTC)
Oppose. This idea engineers the editor out of Wikipedia. Stub assessment is probably one of the most important tasks for early-to-middle Wikipedians. It is subjective, it involves topic assessment, many will be better AfD-ed or merged than reclassified, and doing these things is a learning process for editors. Instead, have a bot identify probable cases for reclassification, but leave it for a human to make the decision. —SmokeyJoe (talk) 23:02, 29 April 2020 (UTC)
The important thing SmokeyJoe is that the articles are at least identified or guessed to be in a list by a bot and then people can assess them. We need something automated to help.† Encyclopædius11:13, 30 April 2020 (UTC)
Support ORES isn't perfect, but it's pretty good for this specific task. Unsourced articles should be deleted on sight in my opinion. buidhe09:31, 30 April 2020 (UTC)
Support We already do this at MilHist. The Bot can easily determine whether an article is a stub or not; this is purely objective. The hard part is the determination of B class, which generally requires human input. Hawkeye7(discuss)11:46, 30 April 2020 (UTC)
Recommendation #2: Using the Rater feature, if I rate all the talkpage templates of an article to better than Stub-class, and if the article is tagged as a Stub, I get a pop-up message that says:
Ratings saved successfully.
Note that the article appears to be
tagged as a stub.
But currently, the converse isn't happening so it's my recommendation for someone to create a pop-up message for that: if I rate all the talkpage templates of an article to Stub-class, and if the article is not tagged as a Stub, give me a pop-up message that says:
Ratings saved successfully.
Note that the article appears to not be
tagged as a stub.
Plus, it would be nice if these pop-ups weren't limited to appearing only if an editor is using the Rater feature, e.g. if the pop-ups also appeared when an editor manually edits the talkpage templates. --Rosiestep (talk) 15:01, 30 April 2020 (UTC)
Weak support There's a lot of stubs and not enough people doing stub sorting. Early-to-middle tenure editors can still benefit from checking the bot's work, and it will help them prioritize the other aspects of page patrol like AfD and cleanup tagging. — Wug·a·po·des19:26, 30 April 2020 (UTC)
Recommendation #3 A bot assesses and make changes which are clearly not stub articles (i. e. more than 2,500 prose characters) and the bot creates a page/list for human review (like orphaned free files, or STiki). When you get a thousand of pages at one place, which may not be stub, it becomes easier. --Titodutta (talk) 16:35, 3 May 2020 (UTC)
If, after three days, the discussion has remained focused on the proposer rather than the proposal, consensus will not form; there is nothing substantive for it to form from. ——SN5412905:42, 4 May 2020 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
I would like to propose some changes to various components of the top portion of Wikipedia:Community portal. I posted this for discussion at the talk page there, but I was not able to get any discussion going there, at all.
Below is my draft for changes to the top portion of the page. this draft includes the portion of the page from the top of the page, down to the large pictorial navbar
Please note, I also have some ideas for the small navbox at the top; namely, to add just some more links, e.g. to Wikipedia:Goings-on,etc, as described below. Below is a separate draft, for the small navbox.
I appreciate any feedback. I would like to move ahead with this, if possible. I am open to any and all ideas, feedback, comments, etc on this. thanks!!! -- Sm8900 🌎 17:27, 30 April 2020 (UTC)
If you haven't garnered any support from your previous four post about the same thing last week and the week before .....perhaps best to assume support is simply lacking. Very hard to move forward when suggestions are suggested and ignored.--Moxy🍁20:41, 30 April 2020 (UTC)
Hi Moxy. it is good to have your response here. just to clarify, I did sincerely follow your suggestion; I removed the duplicate links, to WP:Goings-on, and to WP:News. so this proposal was meant to directly accord with your points on that. If you prefer, I will restore WP:Goings-on to its original place, and remove the new links that I added to WP:Goings-on, and to Wikipedia:About. Would that make this proposal more amenable? I did ask for your input on the ideas tab, as to which you prefer. I would be glad to follow your suggestions in either respect. I will be glad to modify my draft. I appreciate your response; your reply was truly helpful in helping me to perceive some of the points needing to be addressed. thanks!! --Sm8900 🌎 00:21, 1 May 2020 (UTC)
Sorry, I don't see most of these as positive changes. You'll have a better chance if you propose them individually as pieces than in one giant chunk. To address a few specifically: There's no need for the top to be bulleted (it's already short). Adding WP:About isn't appropriate since that page is for readers, not editors. News is already covered on the portal further down, and the Signpost is really the main item, so if there's a link it should just be there (WP:Goings-on is certainly not very active). {{u|Sdkb}}talk05:35, 2 May 2020 (UTC)
@Sdkb: I agree with you. Based on your helpful suggestion, I have narrowed my proposal to the two items below. does this sound okay? I appreciate your help.
Readers will expect to find the nav box at the bottom of the page per MOS:LAYOUT, and RfCs are already linked to from the "Discussions and collaborations" section. {{u|Sdkb}}talk02:50, 3 May 2020 (UTC)
I would appreciate if you would please refrain from making personal comments here. I did not make any personal comments to you. To answer your inquiry above, I agreed only to cease presenting a proposal in any venue other than the central venue for discussing such proposals. . I did not agree to just to stick to content creation and normal editing for a while … and to cease with the 'grand ideas' and problem-solving for a bit". the specific issue raised in that colloquy was posting a proposal at several pages for wikiprojects. I agreed to not do so in the future. your characterization here of my approach here is not accurate. I appreciate your attention to my response. thanks. ---Sm8900★ 🌎 22:55, 3 May 2020 (UTC)
Just for the record, I would like to note that I have posted a reply to Iridiscent at their talk page. I am copying and pasting a portion of that reply below, in order to publicly respond, and to hopefully provide a response that will be helpful, constructive, and substantive in a manner to enable future discussions here to proceed in a positive, constructive, civil and helpful manner. I appreciate the help and understanding of all participants here. thanks.
Hi. I appreciate your note to me at Village Pump. I understood that you were posing a question to me, and I provided a response, which I hope was responsive and helpful. also, you stated that I "feel this constant need to propose grand redesigns of Wikipedia and constantly act like the only opinions of any value are those of people who agree with you." I am not aware of any area or venue that I am acting in that manner in any way at the present time, or at any time in any edit over recent weeks. In any future interactions, I would appreciate if we could please address each other in a positive and constructive manner, and avoid any personal comments, or any comments on individual actions that are tangential to the current topic, and obviously seek to observe WP:Civil in every respect. I do sincerely appreciate and respect your desire to make Wikipedia a better place.
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.
Is there a way that a thank tag can be added to the Recent Changes page?
Proposal for a bot to update backlinks when pages are moved, merged or otherwise become redirects
In a discussion earlier over at the talk page for the ongoing RfA, we came across a scenario where, partially as a result of backlinks not being updated after a page move, content was kept in a way that was incorrect in an article for a fair while. I'm more than sure this isn't the only similar case like that, or even the most severe case, and it set me thinking what we could do to help fix that.
Don't get me wrong, inevitably a bot will never fully replace human backlink reviewers. I'm explicitly not suggesting that this should replace the indication for people who move pages to check Special:WhatLinksHere and to go through and update the links manually. However, inevitably, people will sometimes forget to do so - I bet I probably have in the past, as did the user moving the page in the scenario that I mentioned above. As a result, I'd like to propose a bot that can clean up whatever falls through the cracks.
I know this is technically possible because I've already written the code, but I wanted to make sure there was consensus that this was a good idea before it goes to WP:BRFA. Questions of technical implementation (which I think are best left over there, if and when we get there) aside, the basic process of what the bot would do is as below:
Query a list of recent new redirects in mainspace where a page has been edited to turn it into a redirect (as opposed to pages that are created as redirects from the beginning).
I'm currently planning for the bot to start an hour in the past, to make sure that it doesn't step on anyone's toes if they are going through redirects manually. Thoughts on this would be appreciated, as to whether the time period ought to be longer, shorter, or some other mechanism altogether.
For each of these pages, find other mainspace pages that currently exist that link to the newly-redirected page.
leave a message on the article talk page explaining that the article has been moved, and that someone may wish to review the page to check if the link name should be updated
If the link is a plain no-pipe link [[like this one here]]
If the newly-redirected page is a redirect to a section of another page, turn the previously plain link into a piped link, keeping the previous link name: [[like this#Section|like this one here]]
Otherwise, keep the link as a no-pipe link, just replace it with the new page name [[like this]] (keeping the previous capitalisation, whether the first letter was a capital or lowercase)
If the link is a piped link [[like this|like this link is]], replace the target, but not the link text - [[page like this redirects to|like this link is]]
It may be a good idea to have a limit on the number of backlinks the bot automatically updates for a single article, in order to prevent some kind of apocalypse situation in which half a million pages are updated from a single page move, but I also have in mind the fact that it's arguably even more important to get this right for large articles. Opinions on this would be greatly appreciated.
I'd also like to hear people's thoughts on whether it would be a good idea to leave a talk page message for the person who made the newly-redirected page into a redirect - something like this:
Hello, username! I saw you made WP:Example into a redirect. I noticed there are some pages on the wiki that still link to the redirect. You can see a list of these pages below:
It'd be fantastic if you could take a look at these and see if the links require updating. Thank you very much!
Good idea? Bad idea? Am I missing something humongous that would make this not work at all? Your !votes are very much appreciated :) Naypta ☺ | ✉ talk page | 22:13, 5 May 2020 (UTC)
I don't agree that it violates them. NOTBROKEN is talking about replacing links to redirects with piped links to the destination just because they're redirects, which isn't what I'm proposing. I can see you could argue that it could be cosmetic, but I think there is a good argument it's not - as we've seen in the example I linked, there is a clear case for this being a means of propagating consensus on naming across different pages. But even if it was the case that it were in violation of either of those two, I think there'd be a WP:IAR argument for it - precisely because of the consensus-propagating effect, and because (I think) it's demonstrably beneficial. Naypta ☺ | ✉ talk page | 22:54, 5 May 2020 (UTC)
If I am understanding you correctly, a page is moved and the old title remains a redirect to the new, then your bot will bypass that redirect, changing the old title to the new title (if it was not piped)? If so then, in the majority of cases, that is very much a violation of WP:NOTBROKEN, in cases where it it's changing [[Foo|Bar]] to [[Foo2]Bar]] (or similar) it is also violating WP:COSMETICBOT.
In some cases it will also be introducing errors into articles, either directly through grammatical (e.g. verb → noun, common noun → proper noun), context changes (e.g. brand name → generic name), scope changes (e.g. Joe Bloggs → Death of Joe Bloggs), political changes (e.g. Derry / Londonderry, East Sea / Sea of Japan etc.), incorrectly making changes retrospective (e.g. Macedonia → North Macedonia) etc. or through later changes, e.g. where a redirect is later converted to an article. There is also the issue of page move vandalism (although your an hour time delay will significantly mitigate against this, the shorter any delay the greater the issue will be).
Ultimately, while COSMETICBOT and NOTBROKEN might be arguable in some cases it will never be the majority, the other issues mean this is a task that an unsupervised bot could never do. Read the Wikipedia:Naming conventions (Macedonia)/2019 RFC to see examples of how context matters, e.g. before the name change "Macedonia" was correct in both cultural and (some) political contexts, afterwords it is correct in cultural contexts but only in historical political ones, North Macedonia is correct in contemporary political contexts (but not historic ones) but not in cultural ones. Without knowing the context a bot would get this wrong far more often than it got right, and in some cases (not just Macedonia) this would introduce potentially serious NPOV and/or BLP errors. Thryduulf (talk) 23:43, 5 May 2020 (UTC)
@Thryduulf: Hrm, the points about context, political and retrospective changes are definitely good. I had foreseen that there might in theory be some grammatical errors, but I had thought that this would probably be self-limiting by virtue of the fact that moves from a verb to a noun are probably pretty rare - I hadn't thought of things like Macedonia → North Macedonia which I can see might well be actively harmful to update in that way.
I do think the propagating consensus function is still useful. I've been thinking about how this might be done in a way which wouldn't cause those sorts of issues, and I can see two ways to do it whilst keeping a human in the loop (and have updated the proposal above as such): either leaving a message on the article talk, or leaving a Fix template inline to prompt someone to check the link. This could even be limited further to only pages where either source, target or both contain a preposition, e.g. changes from "Test in Testlandia" to "New in Testlandia", or as in the original case, "Killing of Jo Cox" to "Murder of Jo Cox". What do you reckon about this way of going about it? Naypta ☺ | ✉ talk page | 08:34, 6 May 2020 (UTC)
Most page moves do not result in a consensus to "propagate the change" as you put it because there is simply no need. In cases where there is such a need there are only two ways it can done reliably: fully manually or a fully supervised AWB (or similar) run. A bot could leave a message on the talk page letting editors know a page the article links to has been moved, but this will be useless clutter in most cases because WP:NOTBROKEN means there is no need to update the link, and in most of the few cases where change is needed editors will already be doing it manually. Thryduulf (talk) 10:09, 6 May 2020 (UTC)
@Thryduulf: I can see that in many cases it wouldn't be something needed, but for non-piped links to articles where the link contains a preposition, I'm struggling to think of any where this wouldn't be needed - that's not to say that there aren't scenarios which fit into that category, but I think the majority of the time it would be a good idea so to do. Another example would be changing "coronavirus pandemic in Country" to "COVID-19 pandemic in country" or w/e happened to be the similar change along those lines - in those cases, it is worth propagating that consensus across, as there is a meaningful difference which would likely not be mirrored in other similar articles, as the same level of thinking and understanding hasn't gone into it at those locations. Naypta ☺ | ✉ talk page | 10:22, 6 May 2020 (UTC)
As I said, there will be a few cases where propagating a change will be beneficial but (a) these will be the minority, (b) much of it will be done manually already, and (c) in some cases an explicit consensus will be required first. The correct way to handle those cases that need doing but aren't done manually is with a fully supervised AWB run so that exceptions can be detected, incorrect links fixed, etc. There is no role for a bot here. Thryduulf (talk) 10:41, 6 May 2020 (UTC)
@Thryduulf: That's fair. I'm not hugely familiar with the way AWB is managed - is there somewhere to suggest these kinds of AWB tasks? I know about WP:AWBTASKS but I had understood that those were more for one-off tasks that need doing, rather than for suggesting things that would need doing regularly. Advice appreciated Naypta ☺ | ✉ talk page | 10:49, 6 May 2020 (UTC)
Your understanding of AWBTASKS matches mine, but you are missing the point that these would be one-off tasks. At most you'd be looking at a single figure number of moves per month where a propagation would be beneficial, it hasn't been done manually and there is consensus for a mass change. Such consensus would need to be demonstrated for each task, as each will be done for different reasons, have different exceptions and cultural/political/grammatical considerations - all of which the person doing the change will need to understand. Thryduulf (talk) 11:24, 6 May 2020 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
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.
Content reviewer-protected
Content reviewers are auto confirmed users, but they have 2 restrictions: they can block users or protect pages, but they can't move it, and can't edit Wikimedia Commons files.
A user with content reviewer must have at least 99 edits, but no limit of days (if the user did more than 99 edits but it was active for more or less than 30 days then it will auto-content reviewer).
Also, in Wikipedia:RfA and Wikipedia:Age and adminship, a RfA candidate sayed he was 8 years old...
We do not know the maturity. Maturity for me is a humorous essay, and anything that does not make sense.
The logo for content reviewer protected is a + (plus) in red, just like the Flag of Switzerland.
--190.245.116.175 (talk) 03:26, 7 May 2020 (UTC)
Grant Template Editors and Mass Message Senders the editcontentmodel right
Involved but the outcome is obvious. There is consensus to include editcontentmodel with the Template Editor group. There is consensus against including that right with the Mass Message Sender group with many preferring the solution at phab:T92795. — Wug·a·po·des23:54, 18 May 2020 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Pages on the wiki can contain different kinds of content such as wikitext, JavaScript, and CSS. The software handles these different kinds of content using content models which allow technical pages to look and be edited differently than our articles and talk pages. It also includes the ability to create mailing lists for mass messages and newsletters. Changing a page's content model is currently restricted to administrators. There was some debate about this in a 2016 VPProp discussion.
Rationale
Mass message senders use mailing lists which are implemented as a special content model in the software. Creating these lists requires editcontentmodel. Granting this right to mass message senders by default will make their job easier and reduce the (admittedly small) administrative overhead.
Template editors work with CSS pages as part of template styles. editcontentmodel will allow them to fix the occasional error where the software misrecognizes the page content.
The level of trust and technical ability required to edit template protected pages is similar to the trust and technical ability required to change content models. Many template editors have other technical projects that utilize content models such as CSS, JSON, and JavaScript, and the ability to change content models may be useful as they go about editing.
This is an intentionally limited proposal. The risk of disruption is not trivial, but imo not much worse than the disruption a rogue page mover would cause with that permission. The 2016 discussion touched on how liberally we should grant this user right, and while there was some support for groups like extendedconfirmed, such a wide grant is likely to be controversial. The two groups, mass message sender and template editor, strike me as the groups most likely to actually find the permission useful and so the most viable place to start from.
Question IIRC, some pages with a JS or CSS content model are in some way "protected" (in order to prevent users without Interface Admin from creating CSS or JS code that would be served to other users, a security vulnerability). Would the "editcontentmodel" right allow these users to "protect" pages by changing the content model to CSS/JS, or to "unprotect" CSS or JS pages in other users' userspace? ST47 (talk) 02:41, 21 April 2020 (UTC)
@ST47: w/r/t the security concerns, I tested this out and it seems that taking those actions requires interface administrator privileges. At User:Wugapodes/editcontentmodeltest I was able to change the content model, but when logged out I was not able to edit it. Logged into this account, I was unable to change a page in WugBot's userspace to JavaScript and it returned an error that this action required interface admin privileges. W/r/t being able to protect pages, it seems that this is not possible. At Wikipedia:Sandbox/Wugapodes/editcontentmodeltest I was able to successfully change the content model to JavaScript and I could edit the page while logged out despite the change in content model. My best conclusion is that changing content models respects the "edituserjs" and "editusercss" permission levels which are restricted to interface admins, but Xaosflux may know more. — Wug·a·po·des03:35, 21 April 2020 (UTC)
I've done some research, and it seems that:
You can't change the content model of a page that you can't edit, so you can't "unprotect" someone else's user JS and then modify it.
Even if you change the content model of a "normal" page to something like JS or CSS, it doesn't gain any protection unless it's either a subpage in User: namespace, or any page in MediaWiki: namespace.
So, I don't have any security concerns, though obviously a dev should confirm that this is "okay". We have 60 Mass Message Senders and 175 Template Editors, they seem to be relatively well controlled permissions (though I see one fellow who is checkuser-blocked on the list of Template Editors...). Since it's low risk, I'm willing to say Support, if only because the current process of Xaosflux creating empty lists at titles like Wikipedia talk:Mass message senders/Shell-0057 so that non-admin mass message senders can move them to a real title is a silly workflow that makes me sad. ST47 (talk) 05:15, 21 April 2020 (UTC)
@ST47: empty lists would still be useful, because anyone can use a list - and we normally expect that someone has experience managing a list and making good requests for messages before we let them do the sending part themselves first. — xaosfluxTalk16:13, 21 April 2020 (UTC)
Oppose for MMS, in favor of fixing the workflow instead as requested at phab:T92795 (basically, they should be allowed to create the lists because they are a MMS - not as a side affect of ECM) and the bar for entry for this is not really about using this technical ability. Weak support for TE as that group is normally vetted fairly well and people that are trusted to update modules are generally trustworthy and competent enough to not break things with ECM. — xaosfluxTalk11:17, 21 April 2020 (UTC)
Support for template editors. Sane, sensible proposal. Template editors are trusted and as the OP says, many of them deal with other technical stuff on Wikipedia such as JS/JSON where the ability to switch content models would also be useful. Neutral for MMS. SD0001 (talk) 15:54, 21 April 2020 (UTC)
Support for template editors. As explained above, they may need it when working with templatestyles, and they are trusted enough for having this tool. I'm not sure about Mass Message Senders. Perhaps it should be granted to them until phab:T92795 is resolved? Ahmadtalk05:29, 22 April 2020 (UTC)
Support for template editors: it's a no-brainer for that group. For mass message senders, I'm on the fence; fixing the workflow is a better solution, but temporarily adding the privilege might be a good compromise—the catch of course being that removing it later might be awkward. {{Nihiltres |talk |edits}}16:05, 22 April 2020 (UTC)
Support ish... for content models, but there's a few security concerns with content models that I'm loath to get into for WP:BEANS reasons. Oppose MMS.Headbomb {t · c · p · b}16:13, 22 April 2020 (UTC)
Support permanently for template editors and temporarily for mass message senders (until phab:T248294 is completed). Both have a viable use-case for it and the risk of misuse that would damage the project (ie serious and not easily reversed) is reasonably low in my opinion. If and when phab:T248294 is completed, the right should be removed from mass message senders (which can be part of the close here). Callanecc (talk • contribs • logs) 06:01, 26 April 2020 (UTC)
Oppose for MMS: for those who don't know, we have had a well-functioning workaround for a while, where MMSers (and others) who want to create new mailing lists can move a "mailing list shell" from Wikipedia_talk:Mass_message_senders#Mass-mail_subscription_list_shells to wherever they need. To date, 64 have been used (since the content model was created on enwiki four years ago), so I'm not sure that we need to grant this permission to the MMS group. 64 is around one per current MMS group member, so I really don't think this is much of a problem for them. I'm ambivalent towards this for TEs, but consensus seems to be leaning that way. Best, Kevin (aka L235·t·c) 00:49, 30 April 2020 (UTC)
Support for Template Editors, per above, there is an obvious need. Neutral/no opinion with regards to the mass message flag. -FASTILY04:55, 30 April 2020 (UTC)
Support for template editors, oppose for MMS - Template editors are essentially required to know how to code, which means they are more prepared to go into and edit these content models. However, mass message senders don't need 'wikicoding' experience to get their role, which means they could be given a responsibility they are not prepared for (and I'm not going to list potential consequences of that due to reverse psychology). Kirbanzo(userpage - talk - contribs)18:08, 1 May 2020 (UTC)
Support both, we can always remove for mass message senders if/when the underlying technical issues are fixed. the wub"?!"15:58, 7 May 2020 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Proposal for edit notice on articles related to COVID-19
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.
@Sivakumar1605: it would be useful, but this is not currently technically possible. There is an open phabricator task (phab:T238309) to add it, but it hasn't seen much discussion there and the only technical respondent so far was unconvinced of the need. It has remained prioritised since November 2019. If you or anyone else knows of any previous discussion about this idea on-wiki it would be useful to link to it. Thryduulf (talk) 10:03, 12 May 2020 (UTC)
Writing a gadget that would do this sounds like a good challenge for anyone who wants to practice their Javascript. Maybe you could find someone to write it by posting at Wikipedia:Village pump (technical), which I would guess is where people who are into that sort of thing hang out. Phil Bridger (talk) 11:43, 12 May 2020 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Main Page on mobile
There is a discussion on Talk:Main Page to finally unbreak the mobile view of the Main Page since it is planned that the extension will stop special-casing it (see phab:T32404). For context, this is what current mobile users see now and this is the view that is proposed. --qedk (t愛c)09:33, 9 May 2020 (UTC)
As someone who is 0.0091 furlongs tall, I'm closing this discussion as individuals have summarised the reasons that we will need to remain with a number of imperial-first units until the status quo changes. Nosebagbear (talk) 08:03, 13 May 2020 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
I am a monthly donator and I use Wikipedia every day. It is incredibly helpful to me.
I'm just so happy that Wikipedia is using more and more metric units in its pages. Keep it up!
I really hope that eventually Wikipedia goes 100% hard metric so that no one ever has to put those antiquated Imperial units in parenthesis.
I'm a 65 year young American, born in Pueblo, Colorado to white parents who didn't know a thing about metric. I just think it's time we join the rest of the world in a system that is so easy to use. I'm 82 kilos in weight and 180 cm in height. Thank you. — Preceding unsigned comment added by Japurahei (talk • contribs) 12:13, 11 May 2020 (UTC)
You can see our manual of style bit on it at WP:UNIT. In a nutshell, it depends on the article, and is intended to provide for the reader the most relevant content first, while also providing a conversion, typically. If the United States were to legally change it's measurement system, there would need to be a long discussion about if or when it would be switched over onwiki. For the record as it seems we're doing this, I weigh 28 large trout and am 6.5 squirrels in height. Thank you, Vermont (talk) 16:25, 11 May 2020 (UTC)
Wikipedia describes the world as it is, not as we think it should be. Very many measurements in the US, and fewer but still many in the UK, are made in non-metric units, so they come first when relevant. I have worked this out very quickly so may have missed some orders of magnitude, but I think my age is about 1960 megaseconds. Phil Bridger (talk) 18:00, 11 May 2020 (UTC)
If that's the case then I think I got the calculation about right, although a pedant might prefer me to say 1.960 gigaseconds or Phil Bridger (talk) 11:54, 12 May 2020 (UTC)
Even if the whole world started using metric for everything tomorrow, we would still need to note the measurements of things constructed or defined in previous units, for example the Brunel gauge was 7 ft ¼ in wide and the UK's Weights and Measures Act 1963 defined the permitted measures for dispensing alcoholic spirits as ¼, ⅕ or ⅙ gill (see Alcoholic spirits measure#United Kingdom. I weigh about 0.5 average reticulated pythons and 5.4% as high as the longest span of the Ponte Vecchio is long. Thryduulf (talk) 19:19, 11 May 2020 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Note: For anyone just jumping into the conversation, some of the proposals look to me to be ready to close, with SNOW in some cases. If you are an experienced editor and feel confident assessing consensus (not just counting !votes), please feel free to make some closes. {{u|Sdkb}}talk23:58, 20 April 2020 (UTC)
Page movers
Reasoning explained - move protection can be at each protection level, and standard SP wouldn't prevent a move Nosebagbear (talk)
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.
Hello, I perform moves for WP:RM. Sometimes though, when an RM is successful, the page I want to perform the move is semi-protected. I can't perform the move. Instead, I have to ask an administrator to do it which can be quite slow depending on how fast the admin responds. To avoid this inconvenience, I'm proposing that Page movers can perform moves to semi-protected pages. Jerm (talk) 01:11, 15 May 2020 (UTC)
Yeah, the protection was done when the article was named Michael J Lindell (two moves ago). Unfortunately the protection logs don't move with the page, but you can see it in the logs on the redirect page. bibliomaniac1503:13, 15 May 2020 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Protect user pages so only the owner and administrators can edit
There is an edit filter that prevents IPs from editing user pages, but I think one might request that only the account's owner can edit their user page someday. (Of course admins should be allowed as well.) I also say the same for user sandboxes and similar pages. There are some pages such as Twinkle preferences that only the owner can edit. I'm not perfect but I'm almost (talk) 18:29, 10 May 2020 (UTC)
The protection policy allows for users to request the protection of pages within their userspace if there is a need, but prohibits routine or preemptive protection, see Wikipedia:Protection policy#User pages. Doing what you propose would first require a change to that policy, but absent any demonstrated need I would oppose a proposal to do so. Thryduulf (talk) 19:02, 10 May 2020 (UTC)
I was reviewing the history of this policy, and I'd like to point out that it isn't clear whether the discussion leading to this policy was properly closed. Specifically, in 2013, "this discussion is closed with a consensus that users be allowed to preemptively protect pages in their user and user talk namespaces, but not their actual user talk page." However, in 2015, almost two years later, there was a closure review request that only three users participated in, and the same 2013 discussion was then re-closed with a different conclusion: "consensus seems to be the protection policy as a whole covers this situation - pre-emptive or automatic protection goes against our general principles, but if a point to protection is highlighted, then it can be used for any length needed." It is very confusing that two closers, two years apart, summarized the same discussion with two very different results. It is not clear to me that the current "policy", created by these changes, actually reflects the consensus. Tony Tan·talk04:59, 13 May 2020 (UTC)
No, this is a wiki and no one owns any page. If user pages were owned, they would be overrun with spam and Facebook imitations. This is an encyclopedia, not a social site. Johnuniq (talk) 23:46, 10 May 2020 (UTC)
One obvious problem with this proposal is that it would prevent people from posting mandatory ANI notifications to the user that they are reporting.--69.157.252.96 (talk) 17:51, 11 May 2020 (UTC)
Oppose Per User:Jimbo_Wales#You_can_edit_this_page! (I am not a big fan of quoting things or commenting "per someone", however here he explained it beautifully). A problem I can see, non-sysops not having the ability to edit a user page possibly means they can not tag the page (or sandbox) for deletion under U5, G12 or any criteria, or make any change such as hiding categories from user drafts etc. And finally if a user page is repeatedly vandalised, WP:RFPP should help . --Titodutta (talk) 21:34, 12 May 2020 (UTC)
Strong Oppose. That said, 18 months ago I concluded that it could be helpful if a user were able to semi-protect their own page (just once) for a maximum period of 24 hours in a 7 day period. I still think that could help reduce aggression and give an editor chance to seek admin involvement against personal attacks. (see here). Nick Moyes (talk) 23:34, 12 May 2020 (UTC)
I support this but let only user edit theri page except in some cases when admin went to tasks not edit.Tbiw (talk) 08:28, 19 May 2020 (UTC)
Automatically remove protection from a page when it is moved
When a protected page is moved, the old title stays protected and the protection settings are duplicated to the new page, so we've now got two indefinitely protected pages when we should only have one. Here's an example. This, in essence, is preemptively protecting the redirect against something it hasn't yet experienced, and there are hundreds of improperly protected redirects like this. I think it's important to recognise that these old titles rarely ever see edits ever again, unless of course they themselves get turned into articles (in which case the preemptive protection is even more of an issue).
We're wasting resources having double the amount of required pages protected and tracking categories are full of pages that shouldn't be there. A page like "Guns" has a reason to be indefinitely semi-protected but First Emperor of Qin doesn't, and yet they were both present in the database report and might have been in Category:Semi-protected redirects.
Additionally, and might be of concern, this software feature has an exploit in which a page can be protected without an admin. Here's an example:
Someone who wants protection moves User:Anarchyte/protected to User:Anarchyte/protected3 and now we've got three indefinitely protected pages all because one page was protected. Note that protected3 was never directly related to protected2 (the original article).
I suggest the way protection works be modified so that the protection is automatically removed from the old page and given to the new page when it's moved, or at least there be an option to leave protection like there is to leave a redirect. If that were the case, the only protected page (in the example above) would be protected2. I'm not sure if this should be here or at technical, so let me know if this is the wrong avenue. Anarchyte (talk • work) 07:19, 7 May 2020 (UTC) Majorly edited (see original): 16:20, 7 May 2020 (UTC)
I think this would require a change in the software to implement, but the devs will reject that unless there is a consensus that the community wants the change. This seems a good place to discuss whether there is a desire for this.
Personally, I'm on the fence about this as there are times where leaving the redirect protected is desirable - page move vandalism, title disputes, and competing versions spring to mind as examples, but equally there are times when it probably isn't necessary. For temporarily protected pages - the protection expires at the same time on both new and old titles, so it's only an issue for pages that are moved while indefinitely protected - how often does that happen? My initial gut feeling is that if you find an indefinitely protected redirect that is protected only due to the move of a fully protected page and there is no obvious need for it to be protected, then just request unprotection. Thryduulf (talk) 09:01, 7 May 2020 (UTC)
Note that this was added in phab:T12527 after suggestions that the protection be preserved. There could be another alternative too like adding checkbox to specify whether you want the protection to remain or not. Not sure, but in some cases/or on some wikis, preservation of the protection might be needed or even required. – Ammarpad (talk) 09:20, 7 May 2020 (UTC)
I'm not sure this is a good idea. I'm unconvinced that the number of people scheming to gain protection on pages in the way that you're describing here is anywhere near the scale where this might be an issue - and why would it be, apart from anything else? Protection isn't some badge of quality to a page, au contraire it's a badge indicating that the page might be in danger of vandalism or other disruption. Meanwhile, although a small risk usually, there is sometimes a real and present risk that redirects to protected pages might end up being vandalised, especially if the vandalism to the protected page is so severe that it warrants permanent protection. As Thryduulf says quite rightly above, this issue seems to solve itself quite neatly by simply requesting unprotection where protection genuinely isn't needed. Naypta ☺ | ✉ talk page | 10:32, 7 May 2020 (UTC)
I'm struggling to think of any plausible example where the way this currently works is likely to cause a problem. Protection is applied to pages because there has been some disruptive editing, and surely that could continue at the old title as well as at the new title? Anarchyte, do you have any real-life example where there has been a problem? Was there any reason for anyone who couldn't edit the coronavirus page that you mentioned to be able to edit the redirect left behind by the move? Phil Bridger (talk) 11:47, 7 May 2020 (UTC)
Like Phil, I'm struggling to think of a problem that this addresses. It seems to be working the way we expect it to. However, the proposed change would create an odd situation. As a non-admin, I cannot protect or remove protection from pages; but as a page mover, I can move pages. Therefore, the effect of this would be to allow me to remove protection from pages. Hawkeye7(discuss)12:40, 7 May 2020 (UTC)
Sorry, I wasn't very clear in my opening message. I was somewhat rushed and didn't fully flesh out what I wanted to say. I'll make an edit to that above so that newcomers to the discussion understand what I'm actually trying to accomplish.
@Phil Bridger and Naypta: As we're now discussing the problem I've brought up, I think it's important to also discuss the protection policy. Protecting a page should be done to prevent vandalism or other disruption to the page at hand. When an admin, or at least myself, protects a page, they're protecting that one page. If it gets moved to a new title, the protection on the old title remains, meaning we've technically preemptively protected the page because there has been no harm done to the redirect yet. Redirects get a lot less page views than main articles and are often, or at least in comparison with their article counterparts, left alone by vandals because their work isn't going to be seen. There is no reason why in my example anything should be protected except protected2. The only page that has been "vandalised" is that, and User:Anarchyte/protected wasn't even considered when the protecting admin protected the page.
@Thryduulf: I definitely agree -- this is only going to be relevant for the edge case that an article is indefinitely protected and then moved. However, I've been running through all the semi-protected redirects as of late and I fail to see how retaining the protection on any of these (1, 2, 3, 4, 5, 6, 7, 8) is benefiting the encyclopedia (obviously it could be argued that leaving them protected also doesn't do any harm). If an article is experiencing page move vandalism, the article can get given sysop move protection. If that happens, we can't get any more moves anyway and so the issue is moot. Similarly, if there's a title dispute we can do the same thing (and perhaps fully protect the redirects temporarily so that they can't get overwritten by page movers).
@Hawkeye7: Yes, you could in essence move User:Anarchyte/protected elsewhere and then vandalise that page, but you need to be autoconfirmed before you can move a page so semi-protection is already irrelevant.
I wasn't thinking of someone like myself vandalising a page (which wouldn't happen), but of accidentally removing protection, which I wouldn't be warned had happened. I'm uncertain as to whether your proposed method of adding protection would work. You can't move a page over a redirect, so it would require non-existant pages to retain their protection. Hawkeye7(discuss)20:47, 7 May 2020 (UTC)
@Anarchyte: I understand the argument you're making, for sure; I just think it's an argument based on "policy says this might be a problem" rather than "this is actually a problem in reality", if that makes sense. I don't mean that as a slight against you in any way - it's certainly an interesting point, and I'd not thought about it before!
The point you raise about creating new articles over redirects that are accidentally protected is an especially good that I hadn't considered before at all - although, at the same time, I can't think off the top of my head of any examples where a protected page is moved from a prior location, and then at that prior location a new article is created. That's not to say it couldn't happen (or that it hasn't!), just that I can't think of what the circumstances might be.
I'd certainly not be opposed in any way to the introduction of a checkbox when moving for page movers allowing them the option of transferring the protection to the new redirect or not; however, I certainly don't think this ought to be a priority, and I do think it needs some further thought. For instance, if only page movers have the right, then what happens when a normal autoconfirmed user moves a page? Likewise, if not only they have the right, don't we still have the same issue?
The only way to get around this issue as a whole might end up being to restrict all protected page moves to page movers or administrators. I feel this might be one of those cases where yes, the current behaviour is weird, but alternative behaviour might potentially be even weirder without significant thought. Naypta ☺ | ✉ talk page | 16:32, 7 May 2020 (UTC)
I tend to agree with Naypta. If after a decade of the current behaviour there are less than 20 examples where the protection might not be appropriate this really isn't a high priority issue. A checkbox (that defaults to the current behaviour) wouldn't be a bad idea, just not a terribly urgent one. In the absence of that, it seems that the best thing to do would be to get a bot to maintain a list of all redirects created by moves of pages that are protected for longer than X time (1 week? 1 month? 3 months?), people can then look through that list and unprotect/request unprotection of any that don't need to be protected as they desire. It's not likely to be a very long list. Thryduulf (talk) 17:19, 7 May 2020 (UTC)
@Naypta: Late response but a database report of such pages would be greatly appreciated. @Thryduulf: There are hundreds of "improperly" protected pages. I'm running through the database report and most of the indef protected redirects in the last 5 years are because of moves. I'm working my way through the list. Anarchyte (talk • work) 06:55, 15 May 2020 (UTC)
@Anarchyte: Database report sorted for you! Returns any redirects in mainspace that were created after a page move which have any sort of indefinite protection. You can find the query here on Quarry, so feel free to run it again yourself every so often if you like. For convenience, though, I've put the list on a page in my userspace, too, with the relevant wikilinks in it. You can find that over here. Hope it helps - let me know if you need anything else! Naypta ☺ | ✉ talk page | 15:01, 16 May 2020 (UTC)
@Naypta: Thank you! I've forked the query and modified it so that the pages don't redirect. I've uploaded this new version to your userpage, but feel free to undo it if you'd prefer your version remain there. Anarchyte (talk • work) 15:38, 16 May 2020 (UTC)
@Anarchyte and Naypta: a link to the protection and move logs would be useful too. Knowing why the protection was originally applied gives a clue for what to look for to see if it is still needed, while the move log can also be useful to see whether the reason for moving is relevant to the protection. Thryduulf (talk) 22:43, 17 May 2020 (UTC)
As with some others here, I'm less concerned about cluttering database reports than the potential for vandalism on redirects. Yes, redirects do seem to retain watchers (just checked at 2019–20 coronavirus pandemic), but still, there's some potential for subtler vandalism that could be disruptive. On the other side of the coin, I don't see us losing all that many positive contributions from this — redirects have some complexity to them, so I can't think of all that many scenarios in which I'd want to see an unconfirmed editor making changes to a redirect for a page that was protected at some point. I hope the database report that came out of this discussion is useful, but with regard to making potential changes, I just don't see the WP:BROKEN criterion being met. {{u|Sdkb}}talk04:24, 21 May 2020 (UTC)
Template: Current etc
Yeah, I think I agree that this should be closed at this point. From what I can see, the consensus is that this template is useful. The relevant bot also has a bot request hanging out for resurrection. --Izno (talk) 20:23, 21 May 2020 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
those extraordinary occasions that many editors (perhaps a hundred or more) edit an article on the same day, for example, in the case of natural disasters or other breaking news; cases where many editors (perhaps dozens or more) are editing the article on the same day.
The latest updates to this article may not reflect the most current information.
These two rationales are contradictory: the more edits that are being made, the more likely the article is to be current, generally speaking. And why warn readers that an article is being heavily edited? Anyone who gets into an edit conflict will know they are in an edit conflict. It would be more logical to tag pages that are inactive.--Jack Upland (talk) 01:01, 17 May 2020 (UTC)
As a reader, I always took it as a signal that the article is undergoing rapid churn. If I wait 30 seconds and refresh, it is likely to have changed. I like knowing that. Schazjmd(talk)01:05, 17 May 2020 (UTC)
It lets the reader know how stable an article is. Most people don't expect pages to change rapidly, so it's important that they may not be viewing the same version as their friends. — Wug·a·po·des01:46, 17 May 2020 (UTC)
No, it doesn't. If there was an automated function that told you the page was experiencing a high number of edits, that would be true. But if you go to a page that is subject to a breaking news story, then you should know that anyway. In any case, WP:NOTNEWS. No, this tag is placed on a page by an editor and remains there until another editor removes it (and may be subsequently reinserted). It does not tell you how "unstable" an page is at all. In any case, the template says nothing about instability.--Jack Upland (talk) 06:31, 17 May 2020 (UTC)
WP:NOTNEWS is for disqualifying content that is breaking/primarily sourced WP:OR and for disqualifying articles on routine events, especially recent routine events. It doesn't mean notable information on an already notable person/event/thing can't be updated quickly after it happens using reliable secondary sources. These templates simply guide readers to let them the information on the page may not be correct or updated - i.e., the topic is "unstable," not that the page itself is receiving lots of edits. It's also not impossible Wikipedia could inadvertently "break" the news to someone, for instance in a case of a recent death. It functions similarly to how other warning templates tell readers the article is unsourced, unverified, overly promotional, et cetera. SportingFlyerT·C08:02, 18 May 2020 (UTC)
When it comes to issues like this, I'm firmly on the side of WP:READER. We should be using {{Current}} and the like only when it's necessary to convey something about the quality or character of information in the article, not as a general "hey, this is a recent event" tag. You all may want to check out Template talk:Current, where I've recently been speaking into the void about issues in this general realm (the only real discussion lately has been COVID-related, where a bunch of inappropriate uses have been approved). But did you all know, for instance, that there used to be a CurrentPruneBot that automatically removed the template whenever an article went unedited for more than two hours? {{u|Sdkb}}talk11:04, 17 May 2020 (UTC)
Used according to the guidelines in the template doc, it serves the purpose it was designed for. The fact that so many editors use it incorrectly is insufficient reason to get rid of it. When I remove one, I always link directly to Template:Current#Guidelines in my editsum, which serves two purposes. It decreases the likelihood of a revert, and it increases awareness of correct usage, to whatever extent editors who are interested in learning click the link and read the clear and concise information written there. I don't recall having a removal disputed when I've done that. ―Mandruss☎11:41, 17 May 2020 (UTC)
The latest updates to this article may not reflect the most current information. — several times a news is out, but it take several hours to get a clear idea about the background. It may be a celebrity's mysterious death. It might be an ongoing problematic calamity. For a short span of time, newspapers and other sources also contradict. There are 2 options, a) put all information you get on an article, b) wait a little, judge, assess reliability, and then add. Also more importantly, Wikipedia is not a primary source. We don't have journalists on the ground chasing a cyclone. We can write about something only when a other secondary/primary reliable sources right about it. So, in comparison to those sources and the most current information, we are a bit late. Now, you might ask why don't we put the template in other/news-type articles? Well, that is in the guidelines and Mandruss and others have explained that part. About Recent death also, if it is a normal (non-mysterious death) and details are already clear we don't need a notice on an article. Concluding: the template is a) for readers firstly and informs some content may rapidly change as we get more reliable information, b) for editors as well, suggesting to be more-swift/vigilant while editing (updating article, article history, talk page, watchlist and so on), --Titodutta (talk) 02:52, 18 May 2020 (UTC)
No, no one has explained it. No one has dealt with the contradiction I pointed out in my original post. With regard to your other points, mysteries are not confined to current events. We still don't know what happened to Lord Lucan. And contradictions in sources are not confined to current events either. We have contradictory sources about the birth year of Kim Jong-un. These are just things we have to live with. We don't need a template. The fuss about celebrity deaths is just silly. It is a near certainty they are dead. In some cases the cause of death will be debated for some time, as with Elvis Presley.--Jack Upland (talk) 03:12, 18 May 2020 (UTC)
@Jack Upland: You seem to be the only person who doesn't understand this, as those questions have been answered. But to try again, celebrity deaths are nothing special - any death of a person or any other event where the news is breaking and things are rapidly changing are within scope - information can become outdated very quickly as the real-world situation changes, or there might be important omissions or discrepancies as the article takes time to edit. As just one example, if someone who has a long biography dies unexpectedly it can take quite a while for the tense to be updated, expectations for ongoing projects revised - and those details will often not be known by anyone, let alone reported in a reliable source. The template alerts readers that the article is not stable and that what it says right now may or may not be correct because things in the real world have changed and are continuing to change. Rightly or wrongly people look at Wikipedia for information about breaking news events, these templates inform the reader that the article may change rapidly. This is very different to situations like Kim Jong-Un or Lord Lucan where, although there are contradictions and unknowns they are stable, long term contradictions and unknowns that can be (and are) discussed in the prose with reference to reliable sources about these contradictions and unknowns. Compare the editing history of a biography around the time of an unexpected sudden death with the editing history of Kim Jong-Un - if you cannot see the immediately see the difference then I don't think you will ever be able to understand the purpose or utility of these templates. Thryduulf (talk) 07:46, 18 May 2020 (UTC)
What an illogical response! We have established that many people don't understand the point of the templates. Read the discussion above! If you are concerned about pages being "unstable" - whatever that means - then change the template to say: THIS PAGE IS UNSTABLE. There is no need for anything else.--Jack Upland (talk) 09:44, 18 May 2020 (UTC)
As far as I can see, everybody except you is saying the exact same thing - they're just using different words to try and help you understand. Not everybody uses the template appropriately, true, but that's very much not the same thing as not understanding what it means, and mostly it's just differences of opinion about the threshold. Thryduulf (talk) 09:59, 18 May 2020 (UTC)
As compared to merely THIS PAGE IS UNSTABLE, it would be more informative to say "Information may change rapidly as the event progresses, and initial news reports may be unreliable. The latest updates to this article may not reflect the most current information." As it happens, that's what it says. Sorry if that's an illogical response, it's the best my muddled mind can produce. ―Mandruss☎10:34, 18 May 2020 (UTC)
The reality seems to be that this template is a sacred cow with no practical use. Its worshippers provide inconsistent explanations for it use because they worship it.--Jack Upland (talk) 18:39, 18 May 2020 (UTC)
I'm starting to wonder whether you're actually unable to understand what people are saying or whether you are just trolling? I hope it's the former. Thryduulf (talk) 20:16, 18 May 2020 (UTC)
An example of why this template is a good thing: Once, I killed Gabrielle Giffords. I stand by that edit - sources were reporting it. But the template is useful to show that, hey, what you're getting here is being changed every second, and what you're looking at may be already out of date or even outright wrong. Having the template does zero harm to readers and to editors; omitting it can give the impression to those less familiar with Wikipedia that they're viewing an authoritative snapshot of fact. --Golbez (talk) 20:35, 18 May 2020 (UTC)
@Golbez: That incident will forever remind me of this scene from The Newsroom. Genuinely beautiful, and a reminder of just how important those calls are. (Not in any way meant as criticism towards you - it just reminded me of the scene!) Naypta ☺ | ✉ talk page | 21:16, 18 May 2020 (UTC)
Think the template is a good idea but this should be standardized....we have a few examples of badly used current templates like {{Current COVID-19 Project Consensus}} that lists non consensus and talks involving a few editors about non-contentious points.--Moxy🍁20:49, 18 May 2020 (UTC)
Notably the false information about Giffords only remained on the page for 11 minutes. We were wrong about Pluto for years. Is the fact that it is a "current event" really relevant?--Jack Upland (talk) 06:28, 21 May 2020 (UTC)
I don't see were WP was wrong on Pluto: this old revision from 2006 (and that's just an arbitrary one) clearly has it as a dwarf planet... Regarding WP:NODISCLAIMERS, the template here discussed is listed explicitly as "an exception", and I agree with that because I think that there are plenty of cases where it's use would be justified (as described by others). Simply because some people misuse it is not a good reason to... do something about them? It's not even clear what User:Jack Upland wants, anyways. RandomCanadian (talk / contribs) 16:54, 21 May 2020 (UTC)
I think it is clear the current template and the associated templates should be scrapped. The Disclaimer clearly covers it. Obviously the current template is a sacred cow with many acolytes who will die in a ditch to defend its bovine holiness. That is a pity.--Jack Upland (talk) 18:01, 21 May 2020 (UTC)
Well, "Obviously the current template is a sacred cow with many acolytes who will die in a ditch to defend its bovine holiness" sounds a lot like you have some form of grudge with it – and so far I see no evidence of a silly situation of the WP:BATTLEFIELD type... Are you sure that's really what meant to say? As I mentioned, entirely scrapping it simply because some editors use it excessively/inappropriately seems to be a very literal example of using a sledgehammer to crack a nut... RandomCanadian (talk / contribs) 18:24, 21 May 2020 (UTC)
I never said it should be scrapped because people misuse it. I think it should be scrapped because it's pointless. (And, by the way, Wikipedia was wrong about Pluto: its page originally called it a planet, not a dwarf planet!)--Jack Upland (talk) 19:23, 21 May 2020 (UTC)
Now you have confirmed, if it wasn't obvious before, that you are just making stuff up rather than trying to hold a rational discussion. Pluto was classed as a planet until 2006, so Wikipedia correctly described it as such, and was then downgraded to a dwarf planet, when Wikipedia correctly changed its description. I would suggest that you get your head around such simple things before offering your opinion on more complicated matters. Someone please close this as a case of either WP:CIR or trolling. Phil Bridger (talk) 19:35, 21 May 2020 (UTC)
False. If Pluto is a dwarf planet, it always was a dwarf planet. Was Gabrielle Giffords really dead because CNN said she was? I fear you are trapped in a logical fallacy.--Jack Upland (talk) 19:41, 21 May 2020 (UTC)
Fair point. According to the rules of Wikipedia, she was clearly dead and the assertion she was alive would be OR. Therefore the template is wrong, because Wikipedia can't be wrong, any more than the scientific consensus can be wrong. Like Schrodinger's Cat, she was alive or dead depending on the editor.--Jack Upland (talk) 20:20, 21 May 2020 (UTC)
Depending on the edit. Until I was reverted, she was dead. Then she wasn't. Easy to understand. --Golbez (talk) 20:21, 21 May 2020 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
"Gentler" versions of CSD notices
Dear all, I believe that some CSD notices are a bit all-too-hostile towards new editors, and seeing a good faith creation with a big red deletion notice just puts off new users. There are some CSDs that could be used n good-faith edits:
This makes perfect sense, and I'd be happy to take a look further on, but make more sense for VPI (with a line dropped to CSD) in the interim Nosebagbear (talk) 14:49, 19 May 2020 (UTC)
I hate to be a killjoy, but I don't think that the notices are the problem; it's our practice of speedy deletion that "deters" newbies. I don't think making the notices happy and friendly will have a material impact on newbies; rather, if we want to improve things here, we might encourage, say, replacing some speedy deletions with moves to the draft or user namespaces. A scary notice for a scary process is appropriate. {{Nihiltres |talk |edits}}17:40, 20 May 2020 (UTC)
I don't think deleting per G7 or A10 should be particularly scary. The big red notices are what worries me the most. When I was a newbie, I got slightly intimidated by these notices, less so by the deletion process. Eumat114 formerly TLOM (Message) 04:04, 21 May 2020 (UTC)
When I was an IP, someone tagged an article I was creating to CSD G2 (test page), and I was freaked out! because I was working hard on the article! It was not a test page! I remember thinking that that article... how could it be deleted before being published? The article, List of nicknamed tropical cyclones, is proof that we need to give these IPs/newbies a chance to make their draft better. Guide them to the Teahouse, some Wikipedia policies on sourcing, notability, etc. This is one of the worst cases of WP:BITE there is. Please do not bite the newcomers, 🐔ChicdatChickenDatabase10:15, 22 May 2020 (UTC)
Auto-linking titles in citations of works with free-to-read DOIs
I propose to change the behaviour of the CS1/2 citation templates: the auto-linking mechanism (which provides a default value for |url= when |pmc= is available) would also cover |doi= with |doi-access=free.
In short: if |url=, |chapter-url= and |pmc= are not set, but |doi= and |doi-access=free are set, the title of the citation would be linked using the DOI.
Example
With the following code:
{{cite journal |author1= Hoffman S.J. |author2=Lavis J.N. |author3=Bennett S. | year = 2009 | title = The Use of Research Evidence in Two International Organizations' Recommendations about Health Systems | journal = Healthcare Policy | volume = 5 | issue = 1| pages = 66–86 | doi = 10.12927/hcpol.2009.21005 | doi-access = free }}
As a reader, it is natural to click on the title of a citation to access it. Clicking on identifiers is less intuitive, even when they are marked as free with . In fact, editors often fill the |url= field with the URL the DOI resolves to, to obtain this linked title (see statistics below).
When an article is free to read from the publisher, it is generally preferable to point readers to the publishers' version. Not only is it the version of record, but this is also the place where any errata or retraction will be published, and the DOI link is less likely to rot. If for some reason another version is preferred (because it is the one the editor read when citing the work, or because it is more directly accessible than via the publishers' website), it would still be possible to override the link with |url=, just like for |pmc=.
Since |pmc= is already used for auto-linking, I propose that |pmc= has priority over |doi=+|doi-access=free to generate the title link. This will ensure that all titles currently linked will not be changed by this move. PubMedCentral also stores versions of record, in a clean and readable way, so I do not think there is a need to override them.
Statistics
Here are some figures extracted from the enwiki dump of 2020-04-20. At this point, 189,097 citations had a |doi= and |doi-access=free set.
1,773 (1%) of these also had a |pmc=
28,012 (15%) did not have a |pmc= but had a |url= or |chapter-url=
159,312 (84%) had none of |pmc=, |url= or |chapter-url=, so their title was not linked, but would be linked using the DOI with this proposal.
Among the templates with both a free-to-read DOI and a manually-specified URL, 66% of these are equivalent to the DOI link (they eventually redirect to the same website) or the URL points to the publishers' website but no longer works (404 error). This
figure was obtained by randomly sampling 100 pairs of DOI/URL from the dataset and comparing the links manually. This shows that editors are keen to link the title of their citations. This encourages link rot since they rarely use |url=https://doi.org/... but rather the URL the DOI redirects to.
Survey
I am closing this because discussion seems to be petering out. There is consensus to implement the proposal. Sandstein 15:53, 22 May 2020 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Oppose. There are too many different ids to link (jstor, doi, bibcode, pmid, hdl, citeseerx, arxiv, etc) for auto-linking an arbitrary choice among them to work well. Better to just list them as links. I am also opposed to autolinking pmc, for the same reason. —David Eppstein (talk) 19:11, 23 April 2020 (UTC)
It's rather trivial to make work well. Is it identifier of record (e.g. doi, jstor, pmc, etc...) that links to a full free version of the text? If yes, autolink. If it's not an identifier of record (citeseerx, arxiv, etc...), or does not link to a free full version, do not autolink. Headbomb {t · c · p · b}22:04, 23 April 2020 (UTC)
That doesn't actually respond to the issue I raised. There may be multiple conflicting identifiers of record. On what basis should we make an arbitrary choice to front one of them? —David Eppstein (talk) 19:54, 26 April 2020 (UTC)
If multiple identifiers link to a free full version of record, it doesn't matter which is used, since they all link to the same version. What's important is that the reader is given one. Editors could always override the default if there's a specific need for it (e.g. using the bibcode links instead of the doi links on an astronomy article). Headbomb {t · c · p · b}20:07, 26 April 2020 (UTC)
Support, and hallelujah for this proposal, as this issue has been causing me grief for years. In all of our articles, readers generally know that a blue-linked title takes them to free full text. We cannot expect our readers to understand (in medical content) what PMC, PMID, DOI or anything else stands for. We also should not expect them to have to scroll through all of these to determine if they can locate free full text (as opposed to just an abstract). We can standardize the experience for our readers by giving them a blue link in the title when free full text is available, as that is what they find on other articles. This is a service to our readers who may not know what any of those other codes stand for, but will recognize a blue-linked title. SandyGeorgia (Talk) 19:40, 23 April 2020 (UTC)
Why would url override PMC, when PMC might be more enduring? SandyGeorgia (Talk) 20:05, 23 April 2020 (UTC) That is, I provide a url only when there is not a PMC, but my preference is PMC. SandyGeorgia (Talk) 20:11, 23 April 2020 (UTC)
URL, if provided, means someone thought to overrule the PMC (or the DOI if this passes). If PMC/DOI is desired to take precedence over URLs, that could be enforced by bots or by the template depending on consensus. Headbomb {t · c · p · b}21:55, 23 April 2020 (UTC)
Support the simplest thing for a reader to learn is that clicking on a title link takes them to the freest available online source. This proposal helps that happen. No citation with a free online source should have an unlinked title. --RexxS (talk) 20:08, 23 April 2020 (UTC)
Oppose. The DOI link is already present in the citation, and it is helpfully marked as free. Clicking on it is as natural as clicking on an ISBN link. Duplicating the link adds nothing but more blue text and more complexity. If a reader sees a linked title, is it an explicit |url= or a copy from one of the identifiers? If there is more than one identifier, which URL was copied? We're already seeing confusion with just two extra URL sources, but after this there will be a push to copy URLs from other free identifiers as well. And then editors will be worrying about the priority order and asking for additional knobs to tweak it, adding more complexity. Let's avoid all that, by not duplicating the link. Kanguole20:52, 23 April 2020 (UTC)
"is it an explicit |url= or a copy from one of the identifiers" this does not matter to a reader. But if consensus is that which identifier is used is important, |via= could reflect this too, e.g.
Support all advantages, no negatives. This very reader friendly and greatly improves accessibility on mobile and other platforms. We already do this for PMCs, it's time to extend the behaviour to free DOIs too. Headbomb {t · c · p · b}21:53, 23 April 2020 (UTC)
Support As some have pointed out, this is a trivial change if you already know what to expect from dois and the symbol for free access. However, this can significantly improve usability for those whose first instinct will be to click on the title. Forbes72 | Talk00:21, 24 April 2020 (UTC)
Support. This is common sense, as it leads the reader more easily and intuitively towards the full text. It serves the purpose of practical verifiability, deeper research, and expected user experience. Objections that this makes the citation more "complex" vastly misunderstand the background knowledge of the average encyclopedia reader (or human), who has no idea what an identifier means. Best practice in usability is to reduce the distance between user knowledge and interface behavior: it's overwhelmingly obvious that a linked title is closer to user expectation than a linked [insert weird number/abbreviation most have never heard of]. Verifiability has an internal policy purpose, and also an outward mission-function of actually sharing knowledge by building the web through linking to it. To the extent that Wikipedia aspires to capture the sum of all human knowledge, we must as a responsible node in the ecosystem of reliable sources facilitate access for our readers to those sources. This proposal is a simple, minimal, concrete, and reasonable step towards that. --Founder of The Wikipedia Library, Jake Ocaasit | c00:27, 24 April 2020 (UTC)
Support lots of stuff has a doi, and its main benefit is its stability. If we know there is a stable, gratis version out there, we should link to it since it's pretty much the single most useful link for readers and reusers. Common sense proposal. — Wug·a·po·des00:38, 24 April 2020 (UTC)
Example of references with DOI green locks: Zika feverExample of references with PMC green locks (already auto-linked): List of sequenced bacterial genomesExample of references with DOI and PMC green locks, a link to another repository and a toll access DOI: 2019 in paleobotanySupport as a useful step in the daunting task of improving our citations to follow guidelines on verifiability. Open access works need to be easy to identify in the jungle of references which the bigger articles often have, especially in a period when many cannot visit a library any more to benefit from "walk in" access. Others have addressed concerns above already, I'll just note that the users who know the difference between identifiers, and have preferences about them, don't need to know which one is used for the URL, because they can just continue clicking their preferred identifier. The automatic linking mostly changes the experience of the vast majority of users who have no idea what the various identifiers are (although we may hope to educate them gradually). Nemo07:03, 24 April 2020 (UTC)
P.s: I've added some screenshots for those who may not be familiar with the DOIs and access-level locks we're talking about. Nemo07:11, 24 April 2020 (UTC)
Oppose per David Eppstein and Kanguole above. This proposal is fixing a problem that does not exist. It is adding unnecessary complexity without a benefit in functionality, flexibility or maintainability of citations, now or in the future.
The link to the identifier already exists and it is obvious and trivially easy to use ("click on it"), so this change would just add to the "sea of blue". Providing the same link twice may even cause confusion for readers (and therefore be against the principle of least surprise) because nobody would know any more if a blue title means that it points to some |url= or not. Also, there are often several identifiers to choose from (and there will likely be even more in the future), so we would have to define arbitrary priorities which identifier would take precedence over another. I can already see endless discussions about why one identifier is more important than another, and it will be impossible to make everyone happy with a decision. Worst, over time, different identifiers may be declared to take precedence causing a citation's title to link to resources which could not be predicted by the editor who added a citation in the first place. This borders on falsification of an original editor's contribution. In the readers' perception, the title link will no longer link to some conscientiously selected url, but just to some pseudo-random resource somehow related to the citation - this is degrading the quality of citations and is weakening our network of trust rather than improving it. For the same reasons, I'm also against autolinking |pmc=.
Several decades into the future, many urls will be broken, but likewise many dois will be broken as well. Even some web archivers may have stopped working by then. The solution to this problem of link rot is to provide as many independent backups as reasonably possible, but not to provide links to identical resources twice under different names.
Somewhat related, if a url points to the exact same target as a doi, the url can be safely removed, but often enough I see editors removing urls which point to the same (or only similar) content on a different target page as well. Removing |url= they also remove |access-date= and |archive-url=. While this is not the topic of this RFC, it is driven by the same misguided idea that dois were somehow superior to urls, and that urls (and related framework parameters) can be removed if a similar doi exists. These editors are weakening our citations rather than improving them. Therefore - and this is topic of this RFC - I see this attempt to let dois look like kind of urls in disguise as potentially harmful to the long-term integrity of our citations.
Viewed at it from a rather different angle, but partially related to the problem of having to define and maintain arbitrary priorities for multiple potential identifiers which might be used as a source for auto-linking: Help_talk:Citation_Style_1#Google_books_example
Support for the same reasons as Forbes72 above, and as DOIs are an international standard designed for persistence,[1] the idea makes good sense to me of using a DOI as a first-class title-linking source with optional pmc or url overrides. ― Shnizzedy (talk) 14:12, 24 April 2020 (UTC)
Support It would be a slight change in any given instance, but it would move the project as a whole in the direction of easier use. It's a sensible default that can be overridden when doing so would be beneficial. Overall, a good idea. XOR'easter (talk) 15:45, 24 April 2020 (UTC)
Support - The less-informed reader (who doesn't know what means) will end up at a site where he/she/they can read the full article, and more-informed wonky folks will click on the doi link because it has the next to it. Everyone's happy ... which means we should all "... get up and dance to a song, that was a hit before your mother was born, though she was born a long long time ago, your mother should know ...." ♫ - Mark D Worthen PsyD(talk) (I'm a man—traditional male pronouns are fine.) 08:21, 25 April 2020 (UTC)
Weak Oppose: I'm afraid I'm with matthiaspaul on this proposal; adding to the "sea of blue" might confuse readers, and that's not what we should be trying to do. Still, I see the benefits; but I wonder how this might affect, say, ProveIt, which I use... — Javert2113 (Siarad.|¤)18:26, 26 April 2020 (UTC)
I do not see how this could affect ProveIt in any way: it does not change the meaning of any template parameter, it does not add any new parameter, any syntax currently valid remains valid. − Pintoch (talk) 19:07, 26 April 2020 (UTC)
Maybe Josve05a can provide an opinion, as I've seen him active with all of ProveIt, OAbot, citation bot and a plethora of other gadgets. Nemo19:12, 26 April 2020 (UTC)
@Javert2113: Tools which uses the source (wikitext) to edit an article (such as ProveIt) would in no way be affected by this. This proposal is only regarding the layout/display of the cite template, not how the parameters should be added/work on a basic level. Jonatan Svensson Glad (talk) 19:25, 26 April 2020 (UTC)
Support We want open-sourced references as much as possible, as to allow our readers to be able to verify as much information as possible for themselves if they wish. That's why we add references in the first place. Currently, we auto-link the title if a PMC is added since all such links are openly sourced. I don't see a reason why another identifier if marked as being open/freely accessible already, should not also auto-link the title. A sea of blue links might be a problem, but having all identifiers listed at the end is still a list of blue links and if we wish to give one of them more prominence, it should be a link which is open. Therefore, I can't see any issues with this proposal. Jonatan Svensson Glad (talk) 19:19, 26 April 2020 (UTC)
Support I cross posted notice of this discussion to WikiProject Medicine. Wikipedia citations have already developed beyond anything in conventional academia so we are far beyond looking to anyone else's standards to do what we think is best. Our objective in Wikipedia is to provide readers with stable legal access to free versions of articles. This change helps us to accomplish that. Blue Rasberry (talk)21:43, 26 April 2020 (UTC)
Support This is my default way to indicate that links are free. Right now there are hacky ways around it, and citation bot will automatically remove a url that is identical to the doi-link to my annoyance. Not a big fan of {{oa}} and similar because they're ugly and distracting. buidhe22:13, 26 April 2020 (UTC)
Note: If this proposal is implemented, the free access green hook should also be eliminated as redundant. buidhe10:20, 20 May 2020 (UTC)
Support this is the best indicator that more information is available.....no run around links is best.--Moxy🍁22:19, 26 April 2020 (UTC)
Support Even among relatively sophisticated/educated readers, unless you spend time dealing with journal articles you probably don't know what doi/pmc/acronym soup means. In the absence of another blue link to click on you may try those links out, but standard web formatting is that the linked title takes you to the actual article being referenced. That in this case there's some arcane doi linkages happening doesn't change that for the average reader interested in checking a source article, the only thing the want or care about is a clear link to the article being cited, and the article title linking to that fully-readable journal article is the normal expectation, not having to guess what "doi" means. --PresN03:25, 27 April 2020 (UTC)
of an out-of-copyright paper the DOI points to a protected copy but a free access URL is legitimately available. Now, I understand this proposal would leave this reference alone but some of the remarks above suggest DOIs are inherently better than URLs and this is not always the case. We should be careful to avoid a BOT-like approach. Thincat (talk) 09:16, 27 April 2020 (UTC)
Yes, that's why it's proposed that the URL override be possible. PubMed Central also has a lot of public domain content, another reason to let PMC take precedence over the DOI. For instance an article contains this citation:
This wouldn't replace any manually provided alternatives like the above. If the DOI doesn't link to a free-copy, no automatic link would be given. And if a free copy is "manually" provided, it would take precedence over the automatic links. Headbomb {t · c · p · b}16:05, 27 April 2020 (UTC)
Support per others above. It will help readers to have access to free sources, and is also helpful for more professional editors. Ahmadtalk06:07, 28 April 2020 (UTC)
Support. As someone who has made over a thousand edits to a scientific/medical article (deep vein thrombosis), I would like readers to have the simple benefit of clickable titles whenever there is a free and legal full-text version available for them to access. The reasoning of this proposal is straightforward and beneficial to readers, in my opinion. On the other hand, I am confused by some of the comments from the opposers. One says "as natural as clicking on an ISBN link". I, for one, as an editor and reader of Wikipedia, have no idea what one is to gain from clicking on ISBN links. I don't do that. I do, however, understand the simple logic that (at least on scientific articles) blue-linked titles = always free full text. One opposer claims "This proposal is fixing a problem that does not exist." But in my opinion, there is a simple problem that this proposal fixes. We do readers a favor by linking the free full-text on the title for PMCs. We should do the same for DOIs. Biosthmors (talk) 17:47, 30 April 2020 (UTC)
Support. I have personally observed readers not realize that they needed to click on the DOI numbers because they have no idea what a DOI is (nor should they have to know). Clicking on a linked source title is the intuitive interaction. (not watching, please {{ping}}) czar07:11, 3 May 2020 (UTC)
Oppose early closure. Instead, I would counter-suggest that presence of any autolinked url should be accompanied by removal of the lock icon, as redundant clutter. 98.0.246.242 (talk) 01:51, 6 May 2020 (UTC)
Support: readers are used to clicking on titles. The "sea of blue" argument is invalid, as there's quite often a second blue link for the publisher, author, or whatever, so having a blue doi will not harm the reader. PamD11:45, 9 May 2020 (UTC)
Support: one commentor above argues Clicking on it is as natural as clicking on an ISBN link. I quite agree. Like with ISBNs, clicking on DOIs is unnatural to layfolks and second practice to Wikipedians, who really struggle to internalise just how complex our website is to readers. To be fair, in academic contexts we can maybe assume more of our readers' knowledge, but it's still best to keep it as simple as possible. I support that proposal because it adjusts the templates to fit a general rule that almost all Wikipedia article citations follow: if the source is available online then it's linked through its title. — Bilorv (talk) 09:47, 10 May 2020 (UTC)
Strong suppport that free links should be highlighted. Encouraging access to free material is part of our basic purpose. DOI has the advantage of working across all fields, unlike PMC. The only significant question is how to deal with things if thee are multiple free links. In principle the publishers doi, not pmc is the version of record and should be theone presented in almost all cases, if it does indeed link to the full free text and not an abstract, , and also preferred to other repositories. But,f rom the librarians point of view, all possible links should be entered, as the way to handle disappearing links, but they need nor necessarily all be displayed. DGG ( talk ) 16:41, 13 May 2020 (UTC)
Support, but there needs to be a careful additional discussion of the priority order when multiple identifiers are present. For academic journal articles, there are many cases where doi's link to the publisher's website which has a restricted access version, but the author(s) have placed free-to-read copies at JSTOR, etc., because of their institution's policy on access to publications. At present, if you include a url that goes to JSTOR, it's usually removed in favour of using |jstor=, so over-riding via the URL doesn't work, unless this change is forbidden. The proposal seems to require that when there are multiple links, they must be marked as free access or not when access differs in order to choose the best. This information is far from universally present right now. Peter coxhead (talk) 09:30, 14 May 2020 (UTC)
Oppose, redundant, adds to the "sea of blue", and insults the intelligence of our readers. Stop making assumptions about which link a reader would most likely follow. Boghog (talk) 09:55, 15 May 2020 (UTC)
An interesting analysis, but it answers a different question. The analysis concerns reader preferences for different types sources (scientific article, newspaper article, company webpage, blog, social media, etc.) I was referring to alternative links to the same underlying source (doi: the original source: pmid: an abstract of the source + related sources, pmc: an alternative full text source, etc.). Boghog (talk) 14:07, 15 May 2020 (UTC)
There is no mention anywhere in the analysis about different links to the same underlying citation. There are extensive "between source" comparisons on the same Wikipedia page in the preprint (i.e., RQ2 and RQ3), but no "within source" comparison where the click frequency of links within the same citation are compared. What is needed is a finer grain analysis on a per reference and not per page basis. Boghog (talk) 16:39, 15 May 2020 (UTC)
The authors claim they found statistically significant correlations sufficient to conclude that certain kinds of links in references produce clicks more than others. For instance, ISBN appears to be clearly less clicked than average, other things equal. I still have some nitpicks myself about the data (more on the talk page over there) but we can no longer say we're in the blind about certain things. Nemo17:14, 15 May 2020 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Adding images to all created article
Images should be added to all articles inorder to put more beauty into it. We all know the images gotten from Wikimedia Commons is the one added to Wikipedia. The should be a linker between both and any images seen in Wikimedia Commons after been confirmed not violating the policy should be immediately added to Wikipedia. Images mean a lot it can describe what the article is talking about,it add to beauty,it give more meaning to article and other beneficial uses. Article standard can be completed using images. Images are powerful than seen. Let images be in all articles to give it more standard. Tbiw (talk) 11:16, 13 May 2020 (UTC)
There are several sets of articles that do not have images:
Those for which a suitable image is available but nobody has added yet. Please add these images to the article.
Those for which a suitable image is (potentially) available but is not on Commons (yet). Most articles about living people that do not have an image are in this set for example.
Those for which an image would be suitable but no such image is known to exist. For example most articles people that lived before the invention of photography.
Those articles for which an image does exist, but due to legal or policy reasons cannot be included on Wikipedia. For example images of copyrighted buildings in countries without freedom of panorama.
There are a small subset of articles where the restriction is not copyright but something else, for example we cannot legally include a freely licensed image of child pornography (assuming such an image exists, for obvious reasons I've not investigated).
Those articles for which no suitable image can exist. For example articles about abstract concepts such as Hermitian matrix or Li (Confucianism).
Thryduulf, Freely licensed images of copyrighted buildings in non-FOP countries can (and should) be locally uploaded to Wikipedia as the copyright is not recognized in the US. buidhe03:44, 10 June 2020 (UTC)
despite this idea is going badly due to negative response. But let me further tell you about history during the olden days ways of communication were imagery and image gives expression,image tell us about history. Phil Bridger saying that there was no good response in idealab is no true one supported but told me about the problem that it may have and I am thinking of a way to solve. I won't stop this until the deal is done so i am still hearing the response I waiting for a strong positive response. Tbiw (talk) 20:15, 14 May 2020 (UTC)
That's not how Wikipedia works. Decisions on Wikipedia are based on consensus, if you refuse to listen to consensus you will end up getting blocked for disruption (this is not a threat, it is a statement of the facts of life). We all agree that images are important, and that articles that can be illustrated generally should be. However there are articles that cannot be meaningfully illustrated, as explained above and at the idea lab. Thryduulf (talk) 20:41, 14 May 2020 (UTC)
Please I don't want to get block due to this matter if you find a way to help quit this I will appreciate. Wikipedia is only may chance of getting engaged during the lockdown please don't block me Tbiw (talk) 21:06, 14 May 2020 (UTC)
It seems this idea as it stands is not supported. Why not spend your time changing your idea based on the feedback you've gotten instead of WP:IDHT? Limit the scope of articles based on subject or other criteria? Limit the scope of images considered? Think about and then explain very clearly how your idea will overcome the concerns others have raised? Or recognize that this idea just isn't viable right now, and spend your time directly finding images and adding them to articles yourself. DMacks (talk) 02:34, 21 May 2020 (UTC)
Okay DMacks thanks you have given me the courage again thanks. I will try my best again. Thank you
I have another plan like now one is creating an article one should have prepare the images ready and fix it. Even images suppose to be a strong element. I agree that in some times images are not the answer but inost cases images are the answer image is communication. In classes we do have chart and we used it to give more idea and sense to the topic. In some places many story we heard from them we there we saying we only see the images of computer but they don't see it in real. In image you do not need to really see those things now if we had image to an article in india and you are in USA you might not have the chance to visit the place,person but you have an idea. Image support an idea. Image is strong beauty I'd image. Commons should be only viewing of images it should also be very adequate use. Can someone just give me the ratio or percentage of image. So that I can know how to do more on that. Tbiw (talk) 11:42, 23 May 2020 (UTC)
It's possible that this could be turned into a semi-automated process...eventually. So... ideally every article on Wikipedia should be linked to a Wikidata item, linked with the same article in every language, and eventually a large share of images on Commons should be identified with a depicts. So it is possible in theory to create a semi-automated tool to:
Identify articles that have no images
Identify which of those articles have matching depicts on Commons and/or
Identify which of those articles have corresponding articles in a different language that have images
The user can then be presented with a list of options for images based on these criteria. If the image is presented is selected from criteria #3, they can be also presented with the option to add the appropriate depicts on Commons if missing. However, depicts is fairly new, less than a year old IIRC. So it probably needs filled out more before such a tool could be truly useful, and it would probably be more useful for non-English projects using the English Wikipedia to mine images rather than visa versa, since en.wiki has the largest share of articles missing on other projects, just through sheer volume.
But the process still has to be human operated by someone with a thorough knowledge of image use policy and copyright. Have to keep in mind that there is a non-negligible amount of images on Commons that have been retained not because they have been thoroughly vetted for licensing, but because they have just been dropped into a pit of tens of millions of images and no one has vetted it at all. GMGtalk11:59, 23 May 2020 (UTC)
@Thryduulf: Ah I see. Great minds think alike (though likely poor minds thing alike also :P). It would be helpful to have an idea of what the reach here would be. I honestly couldn't tell what the "saturation rate" (for lack of a better term) would be for either method. It's also possible that current reach of depicts could be nearly useless once you have data in your hands, even if the raw numbers are high. So, for example, how many depicts are going to be for things like "hammer", "house", or "Harry Truman"... instances of very common subjects where there is no need for additional images.
All ideas are great. I would encourage the use of a tool or bot for this job by telling it what to do like what greenmeansgo said about it . If we assign it to editors were might end up blaming ourselves. Inorder for that I really like greenmeansgo idea. It won't make us say we want to improve article and later cause disaster . All ideas are great . Tbiw (talk) 15:34, 23 May 2020 (UTC)
Resolved
Done ...simply quoted ....see Wikipedia:Meetup.--Moxy 🍁 03:36, 19 March 2020 (UTC)
Comment: User:JJMC89 just removed GFDL from some of MGA73's links to sync the pages with MediaWiki:Licenses. - Alexis Jazz 23:42, 14 April 2020 (UTC)
You are invited to join the following discussions:
Like King of ♥ ♦ ♣ ♠ 06:16, 19 April 2020 (UTC)
Hello, username! I saw you made WP:Example into a redirect. I noticed there are some pages on the wiki that still link to the redirect. You can see a list of these pages below:
Naypta ☺ | ✉ talk page | 10:49, 6 May 2020 (UTC)
. In fact, editors often fill the 
means) will end up at a site where he/she/they can read the full article, and more-informed wonky folks will click on the doi link because it has the