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.
Latest comment: 2 years ago35 comments16 people in discussion
NO CONSENSUS
This discussion is not going anywhere.
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 you are proposing an accessibility meter not a verifiability one? In order to verify wikitext one has to access the cited sources first. And then dig in diligently. But the proposal is excellent otherwise. The article you linked is good, but old news, and a bit depressing all these years later. 65.88.88.71 (talk) 15:53, 5 February 2022 (UTC)
I strongly disagree that paywalls or the need for an education sign in suggests something is not verifiable. And at least those can be verified if you can get access without leaving your computer, unlike old newspapers, books, etc. Doug Wellertalk15:42, 7 February 2022 (UTC)
To address the easy part first, WP:V doesn't require that the source be easily accessible. It can be behind a paywall, or not available on-line at all.
The deeper issue is that we are at an information crossroads. Humanity has spent the last several thousand years recording and cataloging information. It's only in the past 150 or so years that we've figured out how to transmit information without having to transport the physical object on which it is stored. And it's only in the past few decades that we've figured out how to let anybody on the planet remotely access information at a time and place that's convenient to them. This is so ubiquitous, convenient, and inexpensive that people are starting to think that "available for free on the web" is synonymous with "exists". While it's a good thing that much information is now available on-line, it's a bad thing that the historical information is fading into non-existence. Either somebody is willing to pay for the conversion to digital form, or the information will disappear. At some point, somebody will look at a building full of dead trees and decide they want to use the space for some other purpose, don't care about preserving the information, and it'll all just get tossed into a landfill.
The issue of scientific journals being behind paywalls is one my my long-term peeves. At least in the US, most scientific research is paid for by federal research grants. It's just plain wrong that having already paid for the research, I now have to pay again to see the result. In the old days, the journals provided the much-needed service of printing. The machinery to do this (i.e. printing presses) is expensive, and they controlled the flow of information by investing in that machinery. The journals also provided editorial oversight, but for the most part, that was delegated to outside reviewers who did the work for free because it was considered an integral part of academic research, and being appointed to an editorial board of a major journal was a gold star on your CV. It's taken the scientific world a long time to grasp that these were two entirely distinct functions. Yes, we still need the reviews and editorial oversight, but we no longer need the printing presses. Which means the journals are living on borrowed time.
But, to get back to where I started, it would be a bad thing if Wikipedia institutionalized a preference for on-line sources. All that will do is hasten the day when the vast store of historical information is lost. -- RoySmith(talk)16:31, 7 February 2022 (UTC)
Well I doubt that Wikipedia promoting easily accessible sources will hasten the day when the vast store of historical information is lost. After all great stores of historical information stored in physical media have been lost in the past, repeatedly. Granted that accessibility is not an explicit WP:V concern, is an accessibility-of-sources metric useful? I believe it is. Sources that cannot be easily accessed, or that can be accessed only by a minority of privileged users do not promote overall project usefulness. I am a random reader perusing a random Wikipedia article. I read something that I find striking; I need to know the particulars of this. Perhaps for the first time, I decide to click on that small symbol to be eventually guided to a hopefully relevant citation. If it points to an easily accessible and free source I will be able to continue my research of the subject. Wikipedia becomes a relevant link in the chain of this personal research. If not, it is a letdown and Wikipedia becomes a broken link (excuse the pun) and a block. Unless that is, one takes steps more familiar to those doing research as profession and requirement. More likely the example reader will browse away from Wikipedia in frustration. An accessibility-of-sources metric will signal concerned editors accordingly, and may promote overall article quality. It will also, and more importantly, signal readers the true state and status of the article, an overall project reputation/goodwill issue. 65.88.88.62 (talk) 20:07, 7 February 2022 (UTC)
Let's not have Wikipedia over emphasize accessible from the internet sources. Accessible doesn't mean good. A copyrighted book by a subject matter expert is almost certainly a better quality source than what is easily accessible. Research papers being behind a paywall is just a reality of the 21st century and again those peer-reviewed papers are almost certainly a better source than what's readily accessible.
I think we are discussing accessibility of sources (including print sources), not quality. In order for anyone, reader or editor, to determine the quality of a source, it must be accessible to them. 65.88.88.62 (talk) 20:48, 7 February 2022 (UTC)
But it does not have to be instantly accessible or even easily accessible.
And, in fact, it does it actually have to be accessible to everyone (since you can always ask someone else to access it FOR you, and report back on whether it is a quality source that verifies the information you are interested in). Blueboar (talk) 21:05, 7 February 2022 (UTC)
Yes, sources don't have to be easily accessible, but is the overall project more useful and relevant if they are? Is verifiablity also helped by more accessible sources? If the answers are yes, the metric proposed makes sense.
Asking someone else to access the information can happen regardless. It also creates another expert class that must be consulted. There are many such knowledge entities around. For instance Encyclopedia Britannica is one. Their contributors presumably have accessed all the sources. After all they are paid to do it, and have a reputation (and future commissions) to protect. They are also overseen by professional editors who answer to career managers. Taking the almost entirely dissimilar nature of this project into account, and if the objective is to make presumably valuable & relevant knowledge freely available to everyone, then the provenance of such knowledge must be transparent. 65.88.88.62 (talk) 21:27, 7 February 2022 (UTC)
This claim about the Britannica seems to be a big assumption. First, that somehow an article with no sources is better than one with sources, some of which may be difficult to access. Secondly that the editors are all experts in their fields. Having looked into this I can state that isn't the case. Third that the articles are all reliable in themselves. Yet I know a case where someone who failed to get their fringe (and unsourced) idea into Wikipedia managed to get it into the Britannica. Doug Wellertalk11:10, 8 February 2022 (UTC)
I don't know if all articles in that commercial property are up to par. I don't know how one manages to get their "fringe ideas" there. Keep in mind that there is a part of the Britannica Online that is crowdsourced just like Wikipedia is. And predictably, with similar overall quality. But I was not referring to the Wikipedia-like part.
So what is a big assumption? That (traditional) Britannica is part of an established knowledge provider that is run by professional managers? That their editorial & supervisory boards are staffed by other, known professionals? That they commission non-anonymous experts to write or contribute to articles? That they employ both proofing and fact-checking staff? That there is both explicit and implied liability regarding every aspect of the operation? Is it also understood that because of the above, articles in that encyclopedia can do without reader verification and the attendant citation system? Although they may as a convenience include a bibliography.
As an information consumer, one can purchase the traditional Britannica implying they pay to expect information that is concise, reliable, objective, correct and understandable. Wikipedia is free, and there are no such expectations, as is clearly stated in Wikipedia's own literature. As it is also clear from Wikipedia's own processes, otherwise we would not be discussing this. My own assumption as a Wikipedia reader is, if I can't verify it, it is useless. Garbage that just wasted my time. It doesn't matter how well presented, it still stinks. 74.64.150.19 (talk) 13:54, 8 February 2022 (UTC)
What is "traditional Britannica"? I know about Britannica online and what I said is true of it. I don't know about another Britannica. I have no idea what you mean about "liability" - you mean you can sue them? Of course they have professional managers, but so does almost every medium sized company. And you should not assume that because there are no citations that an article is correct. This is waste of time. Doug Wellertalk14:59, 8 February 2022 (UTC)
One of the small minority of articles in Wikipedia that are more or less adequate is the one on Encyclopædia Britannica. Maybe it is a starting point for information about it that you can't find. But this is getting off-topic. The OP asks if a metric present in every article regarding accessibility of sources is something that should be done. Are there any substantive points against it, technical or otherwise? It seems sensible, and an improvement. 65.88.88.47 (talk) 16:34, 8 February 2022 (UTC)
Yes, its a net negative to the project to present a false claim that accessible sources are preferred over inaccessible ones, which is what providing this metric would do.Slywriter (talk) 16:38, 8 February 2022 (UTC)
It doesn't follow. A wikitext claim may be verifiable by an accessible source or an inaccessible one. Why is it a "net negative" to state a preference for the accessible one? 65.88.88.57 (talk) 18:58, 8 February 2022 (UTC)
Because it might lead people to thinking that there is such a preference, when there isn't.
If we are to value free access over the Internet over reliability then what is the point of Wikipedia? People can just use a search engine. Phil Bridger (talk) 19:19, 8 February 2022 (UTC)
No, that is what Wikipedia is now ("free access over the Internet over reliability"), as a matter of fact. The proposed metric is about something else: measuring source accessibility as an aid to determine reliability and relevance in the process of verifying wikitext. I suggest we discuss the merits or demerits of it. 65.88.88.57 (talk) 19:43, 8 February 2022 (UTC)
And this is why a net negative. You are placing a value on accessible sources that is not in line with the project's mission. Accessibility plays no part in judging the reliability or relevance of a source and never should, otherwise we may as well close up shop and just be a re-direct to google.Slywriter (talk) 19:50, 8 February 2022 (UTC)
Go to the library. Very little is truly inaccessible. And this metric basically says well too bad Expert in your field that you want to copyright your hard work, we are going to downgrade any articles that use you as a source until 70 years after your death when the work enters the public domain. Its an absurd article written by the Atlantic catering to instant gratification society and does nothing to improve and in fact would actively harm Wikipedia.Slywriter (talk) 20:32, 8 February 2022 (UTC)
(after edit conflict) Why do you you keep repeating that sources that are not available without getting up off your arse and going to a library cannot be accessed? They can. The whole point of Wikipedia, that makes it better than a search engine, is that people with access to reliable sources can provide information to those who without. Phil Bridger (talk) 20:37, 8 February 2022 (UTC)
Do you realize that this is not about online sources but about grading all types of sources according to accessibility? And that among sources proven reliable & relevant after they are accessed, having a preference for the ones easier to find & use, wherever they may be located? 68.174.121.16 (talk) 22:34, 8 February 2022 (UTC)
So this would be a good article and this would not be according to the metric. ill leave you to figure out which one is a featured article and which is virtually useless.Slywriter (talk) 22:46, 8 February 2022 (UTC)
I think the IP means the one that was printed on paper until 2010, and any digital versions that might be considered substantially comparable in content and editorial practices. WhatamIdoing (talk) 21:56, 8 February 2022 (UTC)
You misunderstood. Nobody was urged to consult an obsolete version. The example was brought up to highlight the differences between a traditional pay encyclopedia and entities such as Wikipedia. In order to show why a citation system may not be necessary in one, but vital in the other. 71.247.146.98 (talk) 13:35, 9 February 2022 (UTC)
It's astonishing to read in a comment by 65.88.88.62, above, that Sources that cannot be easily accessed, or that can be accessed only by a minority of privileged users do not promote overall project usefulness. That's flat-out wrong. The vast majority of the world's knowledge falls into the "cannot be easily accessed" category, and no doubt will for decades to come. Why would an encyclopedia encourage or force editors to rely on only a tiny fraction of humanity's accumulated knowledge? That can only be detrimental unless one believes (I don't) that the purity of 100% online sourcing somehow trumps encyclopedic depth, accuracy and quality. As a reader, my main concern is not how easily I can read a source myself, but whether it has been read and accurately summarised by the drafting editor. If have have concerns, I can go to a library. I do that a lot. MichaelMaggs (talk) 22:12, 8 February 2022 (UTC)
Yes, anybody can go to the library and not use Wikipedia at all. But this is a discussion about Wikipedia users. This project declares that it wants to make the sum of human knowledge freely available. But is also a project that anyone can edit. Which leads to Wikipedia:General disclaimer. So a verifiability policy becomes a cornerstone. Just one of its requirements are references to sources judged reliable and relevant. References have to show these sources verify the related wikitext: it is no use to anyone that some random anonymous drafting editor say they do. Without restricting any valid source, it is proposed that sources have preferred ranking based on accessibility, as ones easier to find and use, in order to verify wikitext and make the project more useful to its users. 68.174.121.16 (talk) 23:05, 8 February 2022 (UTC)
Wikipedia must use reliable sources, and the best sources often are not on-line. The advice to go to the library is to find reliable sources to use in editing Wikipedia. And if a reliable source you are looking for is not on the shelves of your local library, in most libraries you can request an inter-library loan of such source from another library. I use on-line sources when they are suitable. I have a personal account for Jstor to help with that, but anybody can access a limited number of sources through Jstor every month without a paid account, and extended confirmed Wikipedia users in good standing can access the Wikipedia library, which gives access to many reliable sources. I also consult my personal library, when appropriate. I go my local library and check out books that qualify as reliable sources, or take notes from reference books that do not circulate. I have also requested sources as inter-library loans when I cannot access such sources locally. Reliability of sources is more important than accessibility, especially as most of what is on the Internet is unreliable. - Donald Albury00:13, 9 February 2022 (UTC)
Please take a minute to read what someone else is saying. How is one to determine a source is reliable if it cannot be accessed? This is not about online sources exclusively. Is a reader to be told that in order to verify anonymous scribblings on Wikipedia one has to retain the services of a professional librarian? Or subscribe to a bunch of other services? Or wait for some time in the future for a paywall to come down? What is the utility of Wikipedia then? This is not an argument against paywalls. It is an argument for preferring the more accessible source among reliable ones. Reliability having been proven because sources were accessible. 71.247.146.98 (talk) 13:11, 9 February 2022 (UTC)
You lost me at "Yes, anybody can go to the library and not use Wikipedia at all". There are billions of potential readers who because of country of birth, poverty, or for variety of other reasons don't have that privilege, and will sadly never be in a position to check those 'difficult to access sources' for themselves. They have no choice but to hope that Wikipedia's internal processes get things right. Now you might want to argue that 'difficult to access sources' shouldn't be permitted to exist and that all knowledge ought be free, but that's not the world we live in. One of Wikipedia's very greatest strengths is in releasing knowledge from such sources and making it freely available to those who have no other means of access. We should be celebrating that achievement, not creating metrics that prioritise the very limited sources that knowledge-poor readers already have access to. MichaelMaggs (talk) 10:21, 9 February 2022 (UTC)
I would rather not patronize poor readers or ask them to trust such lofty enlightened authority as Wikipedia's internal processes to ascertain facts. I would endeavor to give them the opportunity to do so themselves. 71.247.146.98 (talk) 13:19, 9 February 2022 (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.
French Bistro
Latest comment: 2 years ago9 comments6 people in discussion
I'm not at all sure what the point would even be. I would think that if you can't read and write in English the standard advice would be to contribute to a project in your native language? Beeblebrox (talk) 18:33, 8 February 2022 (UTC)
The purpose of the page is to make it easier for people to ask questions in their own language. Sometimes, if you see a problem in an English-language article (e.g., about your country or language), it's for you to explain the problem in your own language, even though the necessary editing needs to be done in English. WhatamIdoing (talk) 21:35, 8 February 2022 (UTC)
It's not clear to me how a differently-named page would alter the level of activity. The local embassy is cross linked from the French Wikipedia page you referred to, so French editors looking for an equivalent on English Wikipedia can find it that way. isaacl (talk) 03:08, 9 February 2022 (UTC)
I just don't think there just aren't enough people who fall into the category of "wants to edit in English but chat in French" to make such a forum sustainable, most people who want to talk in French will just use the French Wikipedia. We have a "discussion in languages other than English" forum (WP:Local Embassy) but it's essentially abandoned. There are a few places where you can chat in French about editing here, WT:WikiProject France is probably a good place to start, but by doing so you're massively limiting the number of editors that can participate since the only language we can count on everyone here speaking is English. Other language projects are probably in a slightly different position by virtue of the WMF being American and it's de-facto internal working language being English, so they will have to interact with messages in other languages on a semi-regular basis. 192.76.8.77 (talk) 21:15, 9 February 2022 (UTC)
I don't understand how the existence of a bookstore illustrates that renaming the local embassy will increase its level of activity. As with most initiatives in English Wikipedia, the first problem is finding interested people. The name of the page where they'll interact is secondary. isaacl (talk) 23:12, 9 February 2022 (UTC)
Hiding Images
Latest comment: 2 years ago2 comments2 people in discussion
Latest comment: 2 years ago21 comments5 people in discussion
Background
How the citation pop-up currently appears
This proposal concerns two instructional pop-ups that appear when a new user opens VisualEditor and clicks on blue pulsing dots in the toolbar. You can test it out for yourself by opening this link in a private/incognito browser window.
This one appears on clicking the cite button. It currently reads:
Improves your content by adding sources of information. You can cite from books, newspapers and websites.
This is borderline misleading, since WP:Reliable sources is a core guideline, so we don't just accept citations from any website. I propose we change the statement to:
Improves your content by adding reliable sources of information. You can cite from reputable books, newspapers, and websites.
This adds only two words, keeping the message concise, but emphasizes the importance of good sources. Similar to above, it also adds a wikilink to a newcomer-friendly help page with more information for anyone curious to learn more. {{u|Sdkb}}talk21:28, 8 February 2022 (UTC)Edited 22:58, 8 February 2022 (UTC)
As @Xaosfluxsaid last month, the goal is verifiable information, not "reliable information".
Also, I'd remove the word "reputable", because (a) not all reliable sources are actually reputable (see: every citation to the Twitter accounts of prominent but disreputable politicians), and (b) if you're getting your information from a poor source, we want you to WP:SAYWHEREYOUGOTIT so that it will be quicker for RecentChanges patrollers to notice how bad it is. WhatamIdoing (talk) 22:02, 8 February 2022 (UTC)
Oops, I forgot about the tweak that came about from the discussion here; I'll adjust the proposal to fix that. (I do think the original is correct, since the goal is information that is verifiable through a citation to a reliable source, i.e. a source that publishes reliable information. But that's a rather fine distinction, so better to just change to by adding reliable sources of information.)
On your second point, if someone realizes they shouldn't be adding information from an unreliable source, they have three options: not add it at all, add it unsourced, or find a better source for it. 1 and 3 are good, and 2 is easy for patrollers to spot. {{u|Sdkb}}talk22:57, 8 February 2022 (UTC)
My second point isn't about someone realizing they shouldn't be adding information from an unreliable source. I'm concerned about someone incorrectly thinking that they can't add a reliable source because the reliable source isn't a reputable source. WhatamIdoing (talk) 08:02, 9 February 2022 (UTC)
Think a few things may be getting overlapped? If the call out is solely about adding "a source" then yes, we want a 'reliable source'. If there is a call out about adding "information", we want 'verifiable information'. The prior discussion mentioned a conflation, "adding sources of reliable information." — xaosfluxTalk23:17, 8 February 2022 (UTC)
Would it not make more grammatical sense if the first word here was "Improve" rather than "Improves"? Also I think that a slightly more extensive rewrite would be better here, the current text seems to suggest that citations are an optional improvement, rather than something you 100% need to provide if you don't want your work to be reverted. I would suggest something like "Content in articles must be supported by sources. You can cite from books, newspapers and websites.". (The wording could use a lot of work). 192.76.8.77 (talk) 17:07, 9 February 2022 (UTC)
@Sdkb: Honestly? It sounds a bit too wordy and a bit too "Wiki-speak" like to be in an introductory popup. There's a few words I would trim, I don't think it's necessary to clarify that content is encyclopaedic and describing sources as both "reliable" and "reputable" is unnessasary duplication IMO. How about going for something mid-way, like Content must be supported by citations to reliable sources. You can cite from books, newspapers and websites.192.76.8.77 (talk) 21:35, 9 February 2022 (UTC)
Sounds reasonable to me, too. (Though, TBH, I'd have preferred the active tense, rather than a passive one, which would have occurred had 'Improves' been changed to 'Improve'. But on the other hand, this is a clear instruction to do something - so maybe not bad to have. But as I'll just throw this out there for consideration:
@Nick Moyes: The reason I didn't like the original wording is because I think it suggests that citations are an optional improvement, rather than a requirement. I think it would be a better user experience for newbies to be bluntly told "you must provide citations for content you add", as opposed to them being told they are an improvement, adding unsourced content then being reverted and warned over something that they didn't know. 192.76.8.77 (talk) 16:31, 10 February 2022 (UTC)
Fair comment, though that's not totally correct - it's only a 100% requirement for content that's liable to be challenged or linked to a BLP. But I'm happy to go with your suggestions, if others other. Nick Moyes (talk) 18:06, 10 February 2022 (UTC)
@Nick Moyes: You are of course 100% correct, but I don't think it would be possible to squeeze a description of what "likely to be challenged" means, the various places where citations are not needed at all (WP:LEADCITE) and the philosophical debate of WP:You don't need to cite that the sky is blue vs WP:You do need to cite that the sky is blue into a 20 word pop-up message. I think stating that you must provide citations is the more conservative approach here, I've seen plenty of newbies have their work reverted as uncited, I don't think I've ever seen someone have their first edit reverted purely for having too many citations. 192.76.8.77 (talk) 18:27, 10 February 2022 (UTC)
This aspect (applies to MOS:PLOTSOURCE as well) was a challenge we encountered at the universal editnotice discussion. There, the outcome was to use verifiable through rather than supported by (supportable by being another option). There's a tradeoff between straightforwardness and correctness, and I'm somewhat on the fence which is preferable. To lay them out, the options that'd ensure we're hewing precisely to PAG are Content must be verifiable through citations to reliable sources. You can cite from books, newspapers and websites. and Content must be supportable by citations to reliable sources. You can cite from books, newspapers and websites. Cheers, {{u|Sdkb}}talk18:37, 10 February 2022 (UTC)
@Nick Moyes, I like your version. Clear, direct, and simple. There's not really any need to tell newcomers about what does and doesn't fall under WP:MINREF.
(I think that the original says "improves", rather than "improve", because the message is supposed to describe what the button does, rather than what the editor should do. It's a bit awkward, and I'm not sure that the style needs to be preserved.) WhatamIdoing (talk) 00:20, 11 February 2022 (UTC)
Automatically generate a record of the contents of deleted categories at the time of deletion
Latest comment: 2 years ago33 comments14 people in discussion
When an article is deleted, a record of the contents of the article at the time of its deletion is maintained and is accessible to administrators. Moreover, when an article is merged or redirected, the contents of the article previously at that title typically remain visible to all editors. However, when a category is deleted and links to that category are removed from pages categorized therein, the central set of data of what articles were contained in the category prior to its deletion is lost forever.
There's also the question of when to preserve the snapshot of contents. Categories are typically emptied before being deleted when empty. Certes (talk) 12:43, 19 January 2022 (UTC)
Is this even possible? Is there a way to track what pages are listed in a category at any given time? Unlike other pages, additions and subtractions to categories are not made on the category page itself... so we can not simply hit the "view history" button to easily see the additions and subtractions (changes) made over time. Indeed, one of my pet peeves is that day to day changes to category pages don't show up on one's watchlist. Blueboar (talk) 13:58, 19 January 2022 (UTC)
Frankly, that is not as useful, since different editors may take up parts of the task, and hunting through pages of a bot's edit history is quite a bit harder than having a single accessible list. BD2412T16:29, 19 January 2022 (UTC)
I remember reading discussions over a decade ago where editors were counseling fellow editors to not bother with categorization matters. CFD is one more venue for editors who are off in their own little world, unconcerned with the health of the project as a whole. What is the purpose of someone picking low-hanging fruit by proclaiming "Oh, this should be a list" and the end result is no list? RadioKAOS / Talk to me, Billy / Transmissions 07:20, 20 January 2022 (UTC)
One of the drivers for this request is that I see CfD discussions where at least some participants propose that the category would be better as a list, but then the category gets deleted with no such list being made, and no easily accessible record remains of what was in the category prior to deletion for the creation of such a list. Perhaps "judges who died in office" would have been better as a list article, but the category was deleted and its hundreds of entries decategorizes, so the rather painstaking process of identifying all the judges who died in office would need to be started from scratch. BD2412T07:31, 20 January 2022 (UTC)
I've been concerned about this for a while, as it seems that WP:CfD has tightened up their interpretation of WP:DEFINING, which is a valid approach for categories but one that risks deleting information we might like to use elsewhere. The solution I'd like to see is a task force at Wikidata that takes to-be-deleted categories and ensures that the information in them is imported to Wikidata before they are deleted. For instance, the Eagle Scout categories were deleted as non-defining a while back, and it would've been nice if we'd ensured that everyone in them had e.g. award received (P166) = Distinguished Eagle Scout Award (Q5282987) added to their Wikidata item first. This would both make it easy to resurrect categories if we decide we want them in the future, and would allow them to continue to evolve, with contributions from other languages. Cheers, {{u|Sdkb}}talk03:11, 20 January 2022 (UTC)
I don't know that Wikidata will preserve all the variables that might go into a Wikipedia category that ends up deleted. For example, does Wikidata have a parameter for "died in office", or for "organizations formed by merger", or for "diseases characterized by inflammation"? BD2412T06:09, 20 January 2022 (UTC)
@BD2412, okay, so I'm by no means an expert in representing things on Wikidata, but I'll take up the challenge for those three:
That is indeed a surprising level of data refinement. I presume Wikidata has some functionality for generating lists of subjects with the specified characteristics? For example, if I want to find people who were judges, and who died in office? BD2412T06:38, 20 January 2022 (UTC)
The aforementioned property "Category:People who died in office" only collects category pages in other wikis equivalent to the deleted category on this wiki. The property "death in office" is different. You can go to "What links here" in the left menu and get a list. The only problem, it's the same hodge-podge of names cited as part of the CFD rationale. I'll leave it to Sdkb to explain how to refine that further, given the proficiency they've shown in navigating the site. RadioKAOS / Talk to me, Billy / Transmissions 07:34, 20 January 2022 (UTC)
For any information held in Wikidata, it is possible to form a database query that will retrieve it. As with all Wikimedia projects, Wikidata is a work in progress, so the data is constantly being populated, reviewed and refined. Depending on what you are wanting to find, we may have a lot of high quality data already available, or we may have a large amount of lower quality data that you will need to sift through. If you have additional parameters, you can narrow your search to make your sifting of the data easier. For example, you could look for entries with death in office (Q5247364) and date of death (P570) = 1836. I am not an expert on queries but there is a beginner query tool available at Wikidata Query builder. Users who are familiar with SPARQL will have a greater range of scope for their queries. From Hill To Shore (talk) 14:16, 20 January 2022 (UTC)
I would take issue with "tightened up their interpretation of WP:DEFINING". There's still next to zero interest in owning up to the problem of countless biographies which categorize the subject only according to their birthplace, when their birthplace has nothing to do with their notability while another place has everything to do with their notability. This POV also often manifests itself through WikiProject tagging on the talk page. RadioKAOS / Talk to me, Billy / Transmissions 07:20, 20 January 2022 (UTC)
Eventually, I hope all information in categories will be imported to Wikidata, and that we'll use Wikidata to construct the category system as Rhododendrites has envisioned. But in the meantime, with limited editor resources, I think it makes sense for Wikidata to focus on the information with a deadline, i.e. categories about to be deleted. {{u|Sdkb}}talk02:28, 21 January 2022 (UTC)
Refocus
Whether this is something Wikidata can take up in some form, or that can be tracked down in the edit history of a bot, I think that it would be a minimal technical burden and great benefit to preserve this data in an accessible list in Wikipedia project space. I am wondering whether there is any specific objection to this proposal. BD2412T22:42, 25 January 2022 (UTC)
Oppose, with alternative. If something has consensus to delete (rather than to reformat or rewrite in a different way), I object to keeping it not-deleted in perpetuity. I think it sounds like a Draft with no 6-month timer, but one that even nobody is actually stating they plan to work on (akin to user-space revival of deleted content). It sounds like the goal is to be able to revive or revisit it in the future, not specifically keep it visible to all readers and editors for all time. So how about making an edit that writes the list of the cat's contents into the cat page itself at the time of deletion? Then an admin can see it but others can't, and the empty+delete action can be undone in the future--all same as a deleted page from any other namespace. DMacks (talk) 08:19, 27 January 2022 (UTC)
That precludes anyone other than admins working on such a list, which is not desirable. I'm unsure what harm comes from having these pages listed in perpetuity in general (specific exceptions would of course be eligible for MfD), but a normal draftspace page would seem to resolve any issues that exist - e.g. if Category:People with honorary degrees from the University of East London were deleted in favour of a list, then the categorised pages would be written to a list at Draft:List of people with honorary degrees from the University of East London, which would give everybody the chance to work on it. If nothing was done for 6 months then it would be deleted per G13 as any other draft. No need for special procedures or new rules. Thryduulf (talk) 11:30, 27 January 2022 (UTC)
Those concerns are reasonable. It's true that there are different reasons categories might be deleted, but a common one and I think the one that's most salient here is just categories that are judged too trivial to be WP:DEFINING. I continue to think that porting information to Wikidata rather than to draftspace is the best option, since it can be preserved there in perpetuity and Wikidata doesn't generally care if more trivial information is added to an item. {{u|Sdkb}}talk17:55, 27 January 2022 (UTC)
Support the data often still exists, publicly available, somewhere in the world (e.g. Category:People who died in office - 07 March 2021); as long as it doesn’t show up in the default search, is there really that much harm in making it easier to access?
Perhaps a ‘last version prior to deletion’ link (even only if off-wiki) on the ‘page does not exist' page?
What about a ‘Deleted’ namespace, for … okay, there are potential name (and thus history) collision issues there … unless deleted content in that namespace had a unique identifier, such as the date deleted, appended to the name.
That might be able to preserve the edit history as well, which would solve for the “everything was removed from the category before it was deleted” issue. (We already have procedures for redacting articles / history that shouldn’t be seen by anyone.)Jim Grisham (talk) 13:16, 27 January 2022 (UTC)
Major problem is that often a category will be slowly deprecated - with things getting removed from it - or even more rapidly if they are in it via templates - the "moment of deletion" may not be the most relevant time. Strong oppose making a policy that places an administrative burden on admins to make such a export-paste list before any deletion can be carried out. — xaosfluxTalk13:21, 27 January 2022 (UTC)
I was actually thinking that a bot could do it, and could pick up the category as soon as the nomination was filed. BD2412T17:28, 27 January 2022 (UTC)
I like that idea. Even better, such a bot could be written and operated today, without need for approval or consensus, if the category lists were published in the bot's userspace or as text files on toolforge. I'd do it but I'm not exactly drowning in free time right now. I'll tag in BOTREQ, though. Enterprisey (talk!) 07:45, 30 January 2022 (UTC)
I believe that BrandonXLF's tool has many benefits.
It conveys a broader array of information than Jarry1250's tool, including link and redirect counts rather than just transclusions, and indirect and direct transclusion counts (indirect as in transcluding a redirect of the page).
It also uses an interface that is more similar to OOUI, which allows for less jarring differences between the external tool and the regular wiki interface, especially for newer users that might not know that it is an external tool.
BrandonXLF's tool also allows viewing counts for non-Wikipedia pages, which is better integrated with the Wikimedia family of wikis and allows users to easily switch to viewing counts of pages from other wikis.
The newer tool is also actively maintained, which can lead to implementation of feature requests, such as a better interfaced alternative to this tool. This has happened before with the tool; a suggestion for adding a grey background to the page was implemented after feedback.
This was proposed on MediaWiki talk:Linkshere before. The discussion eventually fizzled down to consensus to adding both links, and a reccomendation to Use both for maybe a month, and then revisit this discussion. It has been more than a month, and I believe that this is an appropriate time to seek feedback for this proposal. Thank you in advance for your comments and thoughts! 🐶 EpicPupper(he/him | talk)04:15, 13 February 2022 (UTC)
I am opposed to this; first, there is zero harm in having both. Second, sometimes all I want is a quick-and-dirty "how many transclusions" - I don't care about links or redirects, and Jarry's does exactly that. There is no maintenance burden to leaving it on, and only if it actually breaks should we be concerning ourselves about removing Jarry's link.For the record, I'm not saying that Brandon's tool doesn't have uses, but I find it easier and faster to find the same information with Jarry's tool, so why not keep both? Primefac (talk) 12:44, 13 February 2022 (UTC)
I fail to see what problem this change would solve unfortunately. I completely agree with Primefac that often what one wants is a quick "okay, how high-use/high-risk is this template". Lastly, for what it's worth I really do not think that a tool not mimicking OOUI has any bearing on its utility or 'worthiness' to be included in the interface. firefly ( t · c ) 13:01, 13 February 2022 (UTC)
What happens when Brandon's tool stops working? Do we have to have a new discussion about bringing Jarry1250's tool back? Just leave them both. They work. – Jonesey95 (talk) 15:24, 13 February 2022 (UTC)
I don't have a view on the relative merits of each tool, but I disagree with those above who see no cost to having both. Whenever we have redundant options in our interface, it increases complexity and makes it less user-friendly. And it does increase the maintenance burden vs. just retiring the old tool and focusing all our effort on the modern one. {{u|Sdkb}}talk17:33, 15 February 2022 (UTC)
RfC#2 : Removing links to portals from the Main Page's top banner
Latest comment: 2 years ago44 comments27 people in discussion
The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion.A summary of the conclusions reached follows.
This proposal was meant to assist in moving the process forward. After the objection of many participants, such as the one by Levivich (with which I do not agree but do not intend to enter into debates either), I'm withdrawing the proposal. The issue could be taken up by other interested parties. -The Gnome (talk) 09:05, 17 February 2022 (UTC)
Should the Main Page continue to display the portals right next to the "Welcome to Wikipedia" sign as they currently stand? Or should that display be changed in any way? (They are the links pointing to the arts, Biography, Geography, History, Mathematics, Science, Society, Technology, All portals.) A: We should leave the display as it currently stands. B: The display should be changed. Note that option "B" includes any of the following steps: removing the portals entirely from the Main Page; moving the portals somewhere else on the Main Page; any other change in the current display. If option "B" is chosen, then the specific change could be determined in a separate RfC. -The Gnome (talk) 10:16, 16 February 2022 (UTC)
Comment: Check out previous discussions here, here, and here. Disclosure: As it happens, I closed the previous RfC on this issue as "no consensus." Nothing should be implied by that closing and, naturally, I will not take part in this RfC, which I initiate to overcome, as the case might be, the stumble in the process. -The Gnome (talk) 10:16, 16 February 2022 (UTC)
Survey (portal links)
Option A. Other than some people disliking portals and/or their prominence nobody has yet managed to demonstrate that there is anything problematic about the status quo. Could improvements be possible? Maybe, but if so then propose that specific improvement with a mockup and a clear explanation of why it is an improvement. Thryduulf (talk) 11:52, 16 February 2022 (UTC)
Except these links are not unused. In the last rfc those supporting removal claimed this, but the data they presented in support of that argument actually showed the exact opposite - the portals and links to them are well used by readers of the encyclopaedia. Note I'm not saying what we have is perfect, I'm saying what we have is better than some hand-waving towards an unspecified alternative that may or may not feature links to portals. Thryduulf (talk) 20:10, 16 February 2022 (UTC)
Concept with portals link movedConcept with language switcher
Option B. In particular, per the prior discussion, I support replacing the portal links in the top banner with a line in the "Other areas of Wikipedia" section reading Content portals – A unique way to navigate the encyclopedia(pictured). Also, depending on how the Desktop Improvements Project resolves phab:T293470, where they're trying to figure out where to put the new language switcher on Main Pages, I may support using the newly freed space in the banner for the language dropdown menu, somewhat like the concept (pictured). My rationale is the same as last time: we shouldn't be devoting space on the Main Page to links that are barely ever used, that don't represent our best work, and that clutter its design. {{u|Sdkb}}talk17:51, 16 February 2022 (UTC)
Option A - Such a directory is necessary and that piece of prime real estate should not be left empty; altering it without a concrete plan for adequate replacement (and possibly even complete removal) is not something one should favor. — Godsy (TALKCONT)18:39, 16 February 2022 (UTC)
Option B - as per above, this space should instead be used for the language switcher. As shown by the above page view statistics and despite their place on the Main Page, portals simply aren't used much and a language switcher would likely be of much more use to readers. Remagoxer(talk)19:17, 16 February 2022 (UTC)
Option A, with the suggestion to work on improving those portals (if only we had more portals like Portal:Cheshire, we would not have this kind of discussion) instead of removing the links. If the portal links end up removed from the Main Page, I would suggest to put a link to portalspace into the Navigation sidebar, above or below "Contents". —Kusma (talk) 19:19, 16 February 2022 (UTC)
The portal folks have been on notice for years that if the space wasn't improved, things like this would happen. If they were going to be improved, they would've been improved. {{u|Sdkb}}talk19:53, 16 February 2022 (UTC)
It's tricky to spend time improving something when you have to spend most of your wikitime repeatedly rejustifying the things existence. The characterisation of people as "portal folks" shows that the completely inappropriate battleground attitude did not die with the arbcom case. Thryduulf (talk) 20:13, 16 February 2022 (UTC)
Repeated RfCs have failed to find consensus for destroying the portal namespace or for unlinking it to prevent anyone from finding it. Despite that, two thirds of portals have been deleted. What remains is the best of the portals, and many of those have improved significantly. Certes (talk) 20:42, 16 February 2022 (UTC)
Option B. Simply spreading the information on the left across the page, in a thinner row, would be an improvement. I am a member of the History Project and have just clicked on its portal for the first time. Nice stuff, not least the sample featured article which is one of "mine" , but I fail to see why or how portals justify a place on the main page, even less one at its head. Gog the Mild (talk) 19:20, 16 February 2022 (UTC)
I guess I'll have to go for option A given the format of this RfC, which is flawed. There are fundamentally three choices here: keep them where they are, remove them entirely, or move them somewhere else. If you have three options then an RfC should be about those three options. Consolidating two of the options into one inherently biases the process against the remaining option. These links get substantial numbers of clicks and represent the only way that the main page allows people to navigate Wikipedia's content. I would be happy to support moving them somewhere else, but there is no option to support that. Hut 8.519:23, 16 February 2022 (UTC)
Option A, not because I can't imagine an improvement but I can't bring myself to vote for an entirely unspecified change. For example, I oppose leaving a blank space to "slightly modernize the user interface" and I do not accept the weird notion that "A reader who would want to learn something new would just read an article at random". The links are useful and should only be displaced by something that is better. Thincat (talk) 20:10, 16 February 2022 (UTC)
Option B, remove Portal links for reasons described in previous RFC, but also procedural objection. This is a self-inflicted wound of needlessly closing a well-attended RFC as "no consensus" so that it can be re-run in violation of WP:NOTBURO. Editor time is valuable, don't make people vote on the same issues constantly. I also disapprove of someone who is not an advocate of changing the status quo starting such a discussion while only mentioning the affirmative case for the change indirectly via links to previous discussions, and creating such a vague "do something" Option B. I already see people complaining that they don't wish to vote for an unspecified change - which I can hardly fault them for! I wouldn't want to either! An actual advocate would have offered a concrete proposal so that people knew what they were voting on, so this is going to be scuffed. This is not a good way to run an RFC. (Nothing personal against the editor who created this RFC, I'm sure they're acting in good faith, but this is the equivalent of somebody trying to help you sell your house by painting it purple overnight.) SnowFire (talk) 20:51, 16 February 2022 (UTC)
Option A. Without any prejudice, I think this RFC is not well-formed. I have noted my reasons further in the discussion section, but, it currently is phrased as a "Remain as-is" vs "Change; but will not tell you what it will change to / do not know what the new one is going to look like". With the alternative remaining an unknown -- I would want to retain the current links as-is. Thanks. Ktin (talk) 21:10, 16 February 2022 (UTC)
Option A. Option B is to remove one sort of functionality from the main page and just leave the space... blank? If we're going to fart around in a main page redesign, let's do one. At the very least, we might have decided what the actual long-term outcome might be BEFORE creating this further (perhaps inadvertent) effort to expunge portals from the pedia. THE MAIN PAGE IS ITSELF A PORTAL. (sorry for shouting) Linking to other portals is one logical and coherent way to use the space. BusterD (talk) 21:35, 16 February 2022 (UTC)
Option A, regretfully, as the Language switcher does seem like a possibly good idea (plus French Wikipedia appears to be already doing it), but we need to know what the B-alternative actually is. Otherwise, 'B' seems too much like, "I just don't like 'A'." Mathglot (talk) 22:14, 16 February 2022 (UTC)
Option A. It feels like deja vu here... another RFC proposing removing the portals but with no clue as to what will go in their place. Like Thryduulf, and like my previous !vote, I might be amenable to the right proposal - perhaps one that reduces the vertical footprint of the banner altogether, but I'm not going to give a carte blanche to any change whatsoever. — Amakuru (talk) 22:16, 16 February 2022 (UTC)
Close this RFC, it's so out of process as to be disruptive. The closer of the last discussion should not be starting the next one. Where's the RFCBEFORE? Where's the neutral statement? Where are the meaningful options? This appears to me to be an attempt to manufacture consensus for the status quo by making the other option "something else", which is so vague, almost no one will vote for it. This is a complete waste of editor time, and if I hadn't voted in the last discussion, I would close this myself. Levivich22:54, 16 February 2022 (UTC)
Option B - As I stated in the previous RFC, I favor keeping the links, but moving them to a less prominent location on the page. Blueboar (talk) 22:21, 16 February 2022 (UTC)
Option B. Remove the nine portal links from the top frame, move them under the "Community portal" link under "Contribute" in the left frame. Possible replace "Community portal" with "Portals".
The nine portal links in the top frame consume far more prime real estate than they are worth. An old page view analysis showed that only 1 in 1000 main page views lead to a main page portal click, and for every main page portal click, only around 1 in 1000 go on to click a second tier portal link. This indicates that main page readers do not find the portal links useful or interesting. --SmokeyJoe (talk) 03:57, 17 February 2022 (UTC)
Option B, yet again, per all the cogent arguments made last time around. I've gone back and compared this RFC to the last one three times and I'm baffled as to how we ended up here, asking the same question again. The question we had last time was whether the portal links should remain as is or be removed from the top banner, with a note specifically including the possibility of them going elsewhere on the page if removed from the banner. At the close of that discussion we were told that this is an adulterated result and the decision seems clear: We have no consensus to move forward with altering the Main Page through this RfC because it did not offer clear-cut choices and thus did not manage to elicit clear-cut responses - and now the author of that closure gives us the same options yet again: leave the portal links alone or make an unspecified change. What am I missing here? Full support of the objections already raised by others, this particular dead horse has been beaten enough. Retswerb (talk) 09:12, 17 February 2022 (UTC)
Procedural objection – this is precisely the debate format we agreed to avoid in December's RfC. Picking off options such as the status quo one by one for not having an absolute majority over all other options combined will probably result in a less popular option being selected. Certes (talk) 13:51, 16 February 2022 (UTC)
The previous discussion had 30 votes in favor of removing the portals and 17 in favor of keeping them, so I'm not particularly worried about some silent majority that wants to preserve them. This isn't how I would've framed this RfC, as I think we could've directly !voted on alternative options here, but I think we're likely to get to the same result, just with an extra step. {{u|Sdkb}}talk17:31, 16 February 2022 (UTC)
No, the previous discussion had 47 votes for and against various different possibilities. Because of the nature of the RfC it is simply not possible to divide the comments into two clear groups - which is why we are here. And unfortuntely this RfC is again trying to divide people into two clear groups based on their support or opposition to three different options that are not mutually exclusive and so stands very little chance of achieving consensus for anything. Thryduulf (talk) 20:17, 16 February 2022 (UTC)
I agree that this stands little chance of achieving consensus as written, and that's because it didn't simply ask "Keep or Remove" and instead has this useless "do something!" vagueness in Option B. The original RFC was actually better on this offering two concrete proposals. I disagree though that there were too many various different possibilities actually supported in the previous RFC: a majority of editors favored the simple removal option. Now we'll probably require two full RFCs at best to figure out what this means, since if Option B wins, there'll have to be a pointless follow-up RFC. This is precisely how RFCs should not be run. SnowFire (talk) 20:58, 16 February 2022 (UTC)
a majority of editors favored the simple removal option except they didn't. The RFC was not a vote and there was a mixture of support for the options of "keep as is", "remove and replace with nothing", "remove and replace with something" (various somethings specified and not specified) and "move them elsewhere" (with various locations specified and unspecified). Thryduulf (talk) 21:55, 16 February 2022 (UTC)
I didn't mean to reopen the AN debate, but that isn't a rebuttal to what I wrote. All I said was that a majority of editors favored the simple removal option, which is true. That means throwing away any of the other options. (Maybe more obvious in a hypothetical case where 80 vote X, 15 vote Y, and 5 vote Z - the fact that there's a mixture doesn't matter.) SnowFire (talk) 23:53, 16 February 2022 (UTC)
Comment. This RFC (if it is that) is not well formed, imo. It is framed as a "Remain as-is" vs "Change; but will not tell you what it will change to". If there is a concrete option B, I would be willing to evaluate. Else, in the current phrasing -- I am not sure what we are signing up for. Ktin (talk) 21:10, 16 February 2022 (UTC)
I disagree with one option covering all possible changes to the main page: it could be "remove all links to portals", or "reinstate articles for improvement in that top space" for all anyone knows. It's not a good way to figure out how to change the main page: there are lots of people who want different changes, but that doesn't mean any one change must be found to have consensus support. isaacl (talk) 21:16, 16 February 2022 (UTC)
I advised two or three times over the last 12 or so months, to get rid of portals entirely. But does anybody agree with me? Nope. GoodDay (talk) 03:44, 17 February 2022 (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.
Trimming excessive notices at AFD
Latest comment: 2 years ago28 comments13 people in discussion
Take a look at Special:Permalink/1070790824, picked at random from today's nominations. Surely this is excessive? Unfortunately, it has become the norm at AFD. Is there some way that (a) this can be done in a single edit, rather than umpteen (Special:Diff/1070789018/1070790824); (b) that doesn't make it look as if there has actually been discussion, making it harder for AFD patrollers to find discussions that need some additional participation; and (c) isn't so inanely repetitive? Surely a single line with all of the lists in one sentence is better? How can the semi-automated scripts (User:Enterprisey's User:Enterprisey/delsort in this particular case but there are other tools) be improved to cut out the multiple edits and the repetition?
Uncle G (talk) 14:06, 9 February 2022 (UTC)
Well I don't think anyone would object to collapsing a long list of deletion sorting notices with a heading that clearly identified them as deletion sorting notices, but other than that I think the list length is not a significant issue. I have no opinion regarding the multiple edits. Thryduulf (talk) 16:00, 9 February 2022 (UTC)
My preference would be to collapse them all down to a single notice that just lists off the topics, something like
Much less clutter, especially for mobile users (since the mobile apps and website ignore small tags and display the text full size. 192.76.8.77 (talk) 19:52, 9 February 2022 (UTC)
I am not 100% sure that's a good idea. I think we need at least four more editors to comment on whether they like the IP's suggestion or not. User:力 (powera, π, ν) 01:13, 12 February 2022 (UTC)
This would actually be pretty easy to fix in the script (see here), so if someone wanted to update {{delsort}} to take multiple lists, I could sort it on my end pretty quickly. Enterprisey (talk!) 23:48, 17 February 2022 (UTC)
Nice. I would suggest we put the new template at a different page title because there are probably old workflows that use |2= for the signature. I think this is a fine opportunity for a little BOLDness, so I'll update the delsort script after your next response. Enterprisey (talk!) 21:05, 18 February 2022 (UTC)
To clarify, I only made it collapse multiple lists when my delsort script is used to add multiple lists in one edit. If multiple edits are made, then it won't work. Collapsing the list when multiple edits are made is possible, but it would be some more work, which I don't have the time for at the moment. Enterprisey (talk!) 09:14, 19 February 2022 (UTC)
On point (a), multiple edits occurred due to the way script was used. If multiple topics are selected before clicking save, the script indeed does a single edit to the AfD page. See this diff from this sequence for example. hemantha (brief) 07:01, 10 February 2022 (UTC)
Thanks for the mentioned me.I couldn't find any rules for multiple edit delsort tags.And Multiple delsort editing can't be my mistake, there are no restrictions. I feel compatible to delsort tag a multiple edit. I also tag delsort with mobile browser or app.Thanks.CAPTAIN RAJU(T)13:04, 12 February 2022 (UTC)
I agree with the point made in the OP, and would endorse some modification to the delsort message templates that allows them to be collapsible. I would like to take the opportunity to shill the Oracle for Deletion, which lets you sort recent AfDs by page size and !vote count (meaning it doesn't get quite as bamboozled by delsort notices). jp×g23:44, 13 February 2022 (UTC)
Is it the norm? I'm used to seeing around 2-3 notices per discussion, though admittedly I haven't closed any AfDs for a while. Looking at last week's log it does seem like there are more than usual, but that is basically all down to one person. So rather than talk about changing a template that has worked fine for years, we could just politely ask @CAPTAIN RAJU: can you please try to be more restrained in your tagging? – Joe (talk) 10:47, 19 February 2022 (UTC)
I believe CAPTAIN RAJU is doing an excellent job in making sure AfDs promptly hit the relevant delsort lists, and we should be grateful for it. Unless there is a consistent pattern of inappropriate listings, which I take is not the case here, I don't see a need for more restrained tagging. However, if CAPTAIN RAJU is able to combine the delsorts in a single edit, that would be helpful. – Uanfala (talk)20:39, 19 February 2022 (UTC)
Tagging is useful; having the tags take up so much space is not. And while this particular instance isn't that bad, I've seen AfDs with 20+ tags on them, which takes up an unreasonable amount of space. That new template posted above is excellent for remedying this, I would support making it the default way to tag deletion discussions. Mlb96 (talk) 07:42, 20 February 2022 (UTC)
No, because that would be the wrong focus. This isn't about the specific editor who happened to be the one who edited the randomly chosen AFD discussion, or even about the categorizations, but about improving the tools and making their end results better. Uncle G (talk) 21:38, 21 February 2022 (UTC)
Happy it was useful, then (@Uanfala). More broadly, AfD nominations created by Twinkle still seem to stack the tags; which Twinkle developer should be contacted to change this? I don't think the change would be too complicated - just switch from subst:delsort to subst:deletion sorting/multi. Enterprisey (talk!) 08:01, 21 February 2022 (UTC)
Result of previous discussion: Not consensus to make the pages orange.
New, modified proposal: Make disambiguation links highlighted with yellow background for all users when previewing the page (not just reading it). It can be done by adding:
Yellow backgrounds are easier to spot than orange font in a big and complex article
All such highlighting disappears when the changes are published
The highlighting may be limited to article space by adding body.ns-0
Note: A great part of the opposition to the previous proposal was concerns about the readers' experience. These drawbacks are eliminated in this new proposal. Utfor (talk) 17:39, 22 February 2022 (UTC)
Is this needed now that the editor informs you when typing that you've linked to a disambiguation page? If you're using VE to choose the link then it already tells you it's a disambiguation page, so it definitely isn't needed in that environment. Thryduulf (talk) 19:11, 22 February 2022 (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.
Currently, the time is set 8 hours ahead of my time zone (PST). I find this confusing, as an edit that was made at 5:33 PM on Feb 24 in my time zone would show up as being at 1:33 AM on Feb 25, and I'm sure other editors agree Not only this, but the featured article and other stuff on the main page updates 8 hours before it should. I think there should be an option for the user to select their time zone, using the current time zone Wikipedia uses by default, and/or use location services (this would be an option, off by default and using the current time zone Wikipedia uses) to determine the user's time zone. InterstateFive (talk) - just another roadgeek 01:38, 25 February 2022 (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.
RfC: Block reFill tool until fixed
Latest comment: 2 years ago44 comments18 people in discussion
WP:REFILL is a popular citation maintenance tool with great power, and likewise power to cause great harm. It has been largely abandoned for years, in terms of fixing bugs. The number of errors it creates is increasing with time. Its usage is increasing with time. The talk page is full of bug requests. The home page is full of warnings. The GitHub page is full of bug reports.
These are countless examples of bugs, here are two:
edit and fix required (note the user in this case has only ever edited Wikipedia in one article)
Many editors like reFill, when it works. However, many editors are also not fixing the problems it creates. The errors are increasingly complicated and difficult to determine. By letting the tool run rouge we are causing significant damage to the project. Blocking does not need to be permanent, restoration only requires someone to actively maintain and respond to bugs.
Alternatives to blocking are only for approved users, similar to AWB due to it's powerful ability to cause harm, only proven responsible editors should be allowed. How these things might be technically implemented (block, approved users) is unclear but I believe both are technically feasible with some investigation depending what the community wants to do if anything.
Option A - Do nothing.
Option B - Approved users only.
Option C - Block until most known bugs are fixed.
Option D - Something else.
Poll (block reFill)
Option C. Per nom. This is more a vote for more robust software than anything else really. Old enough to remember a time when no software with known bugs would ever be put, or continue to be, in production. It is true, such software policies did use to apply. 50.74.109.2 (talk) 01:27, 22 January 2022 (UTC)
A or B ReFill or Reflinks are helpful tools in getting at least some of the info filled in and reducing the repetitiveness of manually filling in references. I do go over the results because they often need fixing and none of these errors seem so major to me that we necessarily have to restrict access. If we do choose to, I think those of us who have proven conscientious enough in how we use the tools should still have access. – Muboshgu (talk) 17:18, 22 January 2022 (UTC)
A or D. ReFill is not perfect, and never will be. It has always come with a health warning. Its value outweighs its problems. To withdraw it, in any shape or form, will damage the project more than continuing to use it as-is. The 'D' would be to advertise for experienced developers, with the right technical knowledge and spare time to onwardly develop the tool. While there might be some quick fixes, the learning curve given little-to-no documentation and zero handover from the tool's author mean that making even the slightest change comes with too much responsibility for someone not already used to toolforge, and the whole developer stack. Curb Safe Charmer (talk) 23:13, 25 January 2022 (UTC)
Option A or D -- it's hard to get behind blocking the use of ReFill, since I often use it to write articles. While I've written software to generate full-featured proper citations from Newspapers.com, for everything else I use ReFill. It's an unimaginable pain in the ass to fill out citations manually, and I check all of my ReFill cites by hand -- I'd estimate about one out of every ten will have a couple fields that are erroneously filled in, but even then it saves me several minutes. For example, oftentimes the article's title, publisher and author are fine, but the date is messed up -- this only takes a couple seconds to fix, versus typing in all of this information or copying it from the webpage by hand, which takes forever. At the same time, I understand the importance of fixing the tool, and the possibility that doing something drastic could force some action to be taken; I certainly haven't been devoting any effort to it, despite the fact that I could probably make a couple fixes, because it works well enough for my purposes. Perhaps it would be a useful compromise to block ReFill from being used in articlespace, which wouldn't affect drafts or userspace pages (and if you really wanted to use it in a mainspace page you could copy the source into a userspace sandbox to use it there). jp×g07:33, 1 February 2022 (UTC)
Options B and D. I use ReFill almost daily. Being aware of the bugs, I adjust results accordingly. I think this is rather like a chainsaw—very effective for the job it does, but dangerous for the person using it without knowing how. Those who know how should not be restricted while work is undertaken to remove the bugs. BD2412T17:54, 6 February 2022 (UTC)
A or B. I use ReFill enough that I would miss it. Checking for errors is not a burden, although it would be nice if the bugs are fixed. - Donald Albury21:06, 6 February 2022 (UTC)
A or B/D, it's a tool for humans, not magic. Yes, it would be good if someone tried to fix it. Nonetheless, its results generally range from marginally improved, to improved, imo, and with care, better than that. As for process, it should not be removed from anyone, unless there is a showing of continued problems after discussion with the person. I suppose any "new" access could be restricted like a perm, were B adopted. -- Alanscottwalker (talk) 21:27, 6 February 2022 (UTC)
Discussion (block reFill)
Administrator note we could use the abusefilter to block or warn on these edits as they seem to have a consistent edit summary we could latch on to; we could also exempt certain usergroups (e.g. extendedconfirmed) or users with an editcount above something from such a filter. While possible, I expect there will be significant pushback about making a new local mediawiki usergroup just for this. If set to "warn" every use would require a reconfirmation after getting the "warning" which can say whatever we want. (Please note one of the sample "bad" edits is by a user with 3000000+ edits that is also a member of restricted groups including autopatrolled). We can not easily make an on-wiki discretionary access control list, as we do not control this software - it is hosted off-site. Traditional administrative options are also available - such as placing editing blocks on users that are making disruptive edits. — xaosfluxTalk22:55, 21 January 2022 (UTC)
The examples seem to disrespect {{cbignore}}, though one of them has the |bot=medic parameter, which presumably limits cbignore's scope to a different bot. Should a filter warn (or prevent) edits with reFill in the edit summary which remove cbignore (or cbignore without parameters)? Or is the problem more widespread, involving errors other than a failure to respect cbignore? Certes (talk) 23:49, 21 January 2022 (UTC)
@Certes: that template says it applies to "participating bots". This edit was not made by a bot it was made by a human editor. Is there a reason you think that this utility is otherwise a "participating bot"? It may be possible to code an abuse filter for that though. — xaosfluxTalk00:09, 22 January 2022 (UTC)
No, my mistake, though authors of tools which suggest edits might want to consider complying as if they were bots. Certes (talk) 00:56, 22 January 2022 (UTC)
On reflection, I may have expressed a good idea badly. Observations: Certain citations confuse bots. Editors kindly mark these with cbignore. The two examples above are also marked with cbignore. Hypothesis: the sorts of citation that get marked with cbignore also confuse ReFill (though as a non-bot it has no duty to observe cbignore). Suggestion: detect edits where ReFill amends lines containing cbignore, and tag/warn/prevent as appropriate. Certes (talk) 14:26, 22 January 2022 (UTC)
Comment I would love for some new developers to take over this tool (and Reflinks too), to fix the numerous issues it creates for author/first/last parameters and other parameters. Thanks! GoingBatty (talk) 01:28, 22 January 2022 (UTC)
The problem is getting a modified version live, I submitted a change to fix one of the errors caused by the tool a couple of years ago. If someone could solve this problem, then pogress could be made. Keith D (talk) 19:45, 22 January 2022 (UTC)
Also see Wikipedia:Bots/Requests_for_approval/BareRefBot. On hold due to ANI thread. It just fills in the bare refs for now, but the script can be upgraded to match the capabiltities of reFill or refLinks. I think a new tool rewritten from scratch is the future (I've looked at the source code of both tools, I didn't like working with it, but that just is me) Rlink2 (talk) 19:16, 22 January 2022 (UTC)
Yes agree, best redone from scratch. Hope your bot works out and can convert all those refs before editors feel the need to run reFill. A number of people have tried to adopt reFill with little success fixing the dozens of bugs; it was written by a college student and abandoned. -- GreenC20:07, 22 January 2022 (UTC)
To anyone writing a new tool: please plan ahead and get a few more people involved in its development and maintenance. It would be greatly appreciated! isaacl (talk) 20:55, 22 January 2022 (UTC)
Here is another bug (i think?) on the Chris Lattner article. The first and last names are obviously not "Apple" and "Inc.", doesn't make sense. But could be wrong Rlink2 (talk) 19:39, 22 January 2022 (UTC)
It is only one of perhaps 100s of reported bugs ignored for years. Is this bug even reported, and if it was, would it matter? -- GreenC20:27, 25 January 2022 (UTC)
Monitor for unusual strings by sorting by count and seeing which have high counts and manually skim off into a file the bot can reference. -- GreenC17:02, 26 January 2022 (UTC)
Note that CurbSafeCharmer is the maintainer of reFill2 on GitHub [1] . I see very little change in the code for 3 years. In the past 24hrs a few issues were closed as invalid, not due to code fixes.[2] It still leaves many open issues.[3] Plus the many talk page reports (including archived pages). There isn't much happening in the code itself. This is not blaming CSC, as they say, it is a steep learning curve and a difficult project which explains why even the "slightest change" is so difficult and never gets done. -- GreenC17:16, 26 January 2022 (UTC)
@GreenC: There were eight issues in the GitHub repo, most dating back to 2015-2017 that the author and previous maintainer of reFill should have closed - I have done so today as it makes it easier to 'see the wood for the trees'. Of the 27 open issues, almost all are enhancements requests, rather than bugs. It is a small but significant distinction. I do not see the issue raised by Rlink2 above as a bug, for instance, as it is a request for reFill to do something new that it was not designed to do - there's no existing code for that which needs fixing. Curb Safe Charmer (talk) 17:50, 26 January 2022 (UTC)
Thank you for taking a few minutes to close some years old open tickets that are no longer valid. See the talk page and example diffs for lots more (and Phab). The main thing is no one is actively coding, for years, and so this garbage data continues to get added into Wikipedia at scale. Trouble reports for tools like this should be constant, see Citation bot talk page, it's a process of continually fixing issues. The tool has been effectively abandoned by developers. -- GreenC18:22, 26 January 2022 (UTC)
I would be willing to try to work on some fixes for the most egregious misbehavior of the tool and submit pull requests -- is there a list of the biggest issues? The GitHub issues don't seem to be prioritized very well. I would also need some instructions for setting up and testing on a local instance. If I had these things, though, I could commit to at least taking a look (although a few have said the codebase is daunting, so it may not result in any progress, but it's at least worth a try). jp×g07:40, 1 February 2022 (UTC)
Yeah we've heard this in the past, people say they will adopt it then nothing much happens. Similar to Citation bot, tools like this require constant attention to adapt to changing conditions with CS1|2, MOS, best practices, etc... it's a lifestyle not a 1-time fix. The original programmer was a college student, whose code is apparently not easy to work with, who quit and moved on in life. New programmers frequently paint themselves into corners and realize they need to rewrite and find it easier to quit. Others have looked it said it would be best to start over. -- GreenC02:45, 7 February 2022 (UTC)
Well, I think JPxG is a skilled coder and programmer, and is also a very nice Wikipedia editor who is trusted and easy to get along with. I trust he is more than capable to handle whatever might come in his way. And besides, he never said he would take over maintence of the tool (at least that's not the message I got - I could be wrong though). He said he would fix the most pressing issues as of right now,which is important and could be helpful. Rlink2 (talk) 04:12, 7 February 2022 (UTC)
Oh sure JPxG is great agree. It's been frustrating to see one person after the next promise to help out keeping the tool alive in the process but no real progress is made. It has nothing to do with good intentions. Sometimes it's a lack of skill, sometimes it's a lack of time, or lack of interest. Going on for years. If it was harmless who cares but not harmless. If we do keep the tool alive, there needs to be a stop button of sorts so users can at least shut it down until certain bugs are fixed. Currently there isn't even that basic functionality which every bot or tool should have. -- GreenC05:58, 7 February 2022 (UTC)
A more tenable solution
Over the last few days, I've had the opportunity to download the repository for ReFill and take a look at it. It doesn't seem to be badly written by any definition (in fact it seems quite well-written), although it does seem like it'll be very hard to work with. However, the point made above by GreenC is good -- I foresee a particular problem occurring here, and I think we should come up with some way to preempt it.
So, okay, let's say me and CSC sit down and hash it out and... learn how Vue works, I guess -- we figure out how to implement a couple of the most urgent bugfixes, maybe even modify or extend a feature (like, something that fixes cites for some the websites on BHG's lists). This is great, right? Except now I know how Vue works, which means I get a job where they pay me $99999999999, and stop having time to fix bugs in ReFill. This is presumably what happened to Zhaofeng, the original writer -- you can see on his GitHub that he is still making commits on a daily basis, and presumably his life rules because some of this stuff is really cool. But he is not fixing stuff in ReFill. Now, if I spend a million years learning how the hell ReFill works, presumably some day I will go to NASA to be a front-end rocket scientist, or I will get hit in the head with a meteorite, or whatever, and then this knowledge will be of little benefit to anyone (except possibly my web developer colleagues at NASA).
Anyway, the idea I had is that we could build up a decently useful page somewhere - like Wikipedia:Refill/technical and Wikipedia talk:Refill/technical, and everyone who wants to try and dick around with the code can convene there, to a) figure out what the heck is going on and b) share notes on what the heck they think is going on. We manage to do this perfectly well for everything else -- people get into an argument about politics and we end up with an ArbCom casepage filled with thousands of diffs and tens of thousands of words. I think that if we set this up, and still ended up with no progress being made, I'd support blocking ReFill until it was resolved (if only to get people motivated to help out). Alternately, we could leave it unblocked and make it fill in publication titles with auto-generated controversial statements about American politics ("Apollo 11 was an inside job", "the 9/11 landings were fake", "Donald Trump was actually born in Svalbard", etc) because that seems to effectively get people's attention. But I think if some people can be gotten to that page, if they later become busy, or get hit in the head by a meteorite, at least there will be something useful there for others to go off. jp×g21:19, 7 February 2022 (UTC)
(in fact it seems quite well-written) Good to hear.
FWIW I do have a fix for the broken sites for ReFill specifically. I used it at the very very beginning of my journey of fixing bare refs until I decided to move on to my own stuff. But it might be helpful to you. Let me know if you want it.
Yes, a page like that would be great. Keep everything documented for future maintainers. But, I think the biggest issue is finding someone to work on it. You could have all the documentation in the world, but someone still needs to fix the bugs at the end of the day.
Thanks, JPxG. It is good to hear someone confirm that there's nothing inherently wrong with the reFill code. I would say there's nothing inherently wrong with the software architecture either. And I will stick my neck out and say that GreenC should evidence their claims that it is 'full' of bugs and warnings, or that 'one person after the next promise[s] to help out keeping the tool alive in the process' - who were they? "Others have looked [at] it said it would be best to start over" - who? Curb Safe Charmer (talk) 22:52, 7 February 2022 (UTC)
User:JPxG: I think that if we set this up, and still ended up with no progress being made, I'd support blocking ReFill until it was resolved . Good, agreed, let's do that. I won't be involved as I don't have the time. However, seeing as how hostile this tool has been to my own bot, literally undoing its edits for no reason, I have no choice but to continue monitoring the situation. I don't like being a squeaky wheel, but it's less work than monitoring reFill via Stream and having bot wars, or writing code to fix certain reFill errors which I already do (though not at scale). -- GreenC04:00, 9 February 2022 (UTC)
Decrease edit requirement for being extended confirmed
Latest comment: 2 years ago9 comments8 people in discussion
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.
500 edits is a lot, especially if you compare it to the other requirement for being extended confirmed (30 days). For example, I've been on Wikipedia 2 months and only have 89 edits. Sure, I've been inactive a bit, but if you were on, say, every 2 days, and made 3 edits per day, it would take a whole year to reach extended confirmed status. Plus, it's not about edit count, it's about quality of edits. I propose to decrease the edit requirement to 150-200. That way, it would only take 3-4 months rather than a whole year. Another requirement could be that you should not have more than 5-10 reverted edits (excluding self reverts), to encourage people to make quality edits rather than bad edits. InterstateFive (talk) - just another roadgeek 21:33, 29 January 2022 (UTC)
Any admin may grant any new user extended confirmed without them having to wait 30/500. So, if you're really doing good work and need to edit a WP:ECP page, all you need do is ask on WP:AN for somebody to grant you the right. -- RoySmith(talk)21:49, 29 January 2022 (UTC)
There's no minimum requirement for extended confirmed. Extended autoconfirmed has a minimum of 30/500, which is probably about right. Perhaps we should make WP:PERM more visible, so editors who need and can be trusted with extended confirmed don't need to wait for it to appear automatically. Certes (talk) 23:19, 29 January 2022 (UTC)
I think InterstateFive's idea is short-sighted, but well-intentioned. The problem is that we have so many dedicated sockmasters on this website, and lowering the standards for full editing privileges just makes their jobs easier, and ours harder. --Hunan201p (talk) 14:22, 31 January 2022 (UTC)
EC protection is rare, by design. There are about 3600 pages that require EC to edit, of over 55 million. The vast majority of these pages are so due to arbitration remedies, which is where the threshold came from. While the committee somewhat recently weakened the restriction to "ecp" instead of literally "500/30" (Wikipedia:Arbitration Committee/Procedures#Extended confirmed restriction) I think in general we should not be easily weakening this - mostly because I don't want arbcom to get "creative" an invent a new massive protection scheme again that we have to scramble to build technical controls for. Yes there are reasons to early promote someone, but so they can edit remedied pages is a weak one at best. — xaosfluxTalk19:11, 7 February 2022 (UTC)
I oppose lessening the requirements for extended confirmation. I'd be more inclined to support strengthening the requirements to 1,000/60 but accept leaving the requirements as they are.--John Cline (talk) 00:20, 17 February 2022 (UTC)
Oppose The current requirements for extended confirmed are reasonable, and the protection is supposed to only be used to enforce arbitration remedies, or be used on particularly contentious articles. Lowering the requirements would make the protection easier to game, and would also allow newer users to participate in these topic areas than before, which is not the point of extended confirmed protection. 2601:647:5800:1A1F:B59F:66D4:2C8D:EA30 (talk) 00:08, 26 February 2022 (UTC)
Request withdrawn I see your points. Also, this isn't going to benefit me any longer, as my edit count has boomed since I wrote this. InterstateFive (talk) - just another roadgeek 00:30, 26 February 2022 (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.
"User contributions for (user)"
Latest comment: 2 years ago6 comments3 people in discussion
I remember when you're at the user contributions page it would have "User contributions" as the only text, with "for (user)" and then a bunch of links. Why was the change to "User contributions for (user)" to the top text done when we still have the "for (user)" and links below it? The only way it could be useful is if the "for (user)" (smaller text) is removed. Nearly but not perfect (talk) 03:36, 1 March 2022 (UTC)
In either case, since we are VPR - are you proposing we make a local override, or are you just trying to figure out what developer did that? — xaosfluxTalk11:56, 1 March 2022 (UTC)
Latest comment: 2 years ago51 comments41 people in discussion
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.A summary of the conclusions reached follows.
(non-admin closure) It is clear this is heading towards a WP:SNOW. There is strong consensus against the proposal. The community believes changing the logo would be a form of political advocacy at odds with the neutral principles, goals, and operations of Wikipedia. However, the community is overwhelmingly sympathetic to the victims of the conflict and may support other, non-political initiatives on English Wikipedia. A. C. Santacruz ⁂ Please ping me!12:36, 2 March 2022 (UTC)
Georgian Wikipedia has adopted a logo in support of Ukraine. We on English Wikipedia should do the same, not only to show support for Ukrainian Wikipedians but in opposition to what is currently taking place. Not sure if this has been proposed already...
Support as proposal. The Russian state is likely to try to limit access to Wikipedia no matter what we do and I do not think worrying about that should effect our decision. The truth, obviously does not align with Putin's position. Doc James (talk · contribs · email) 23:17, 1 March 2022 (UTC)
Probably won't pass but I think the current situation is more fundamental than a 'political issue', and the proposal is not 'political activism' or a NPOV violation IMO. ProcrastinatingReader (talk) 01:19, 2 March 2022 (UTC)
I feel like its pretty hard to claim neutrality while openly supporting one side in a geopolitical conflict, no matter how despicable the other side may have acted. People will probably say that the articles have to be neutral but wikipedia does not in a meta sense - still an appearence of a conflict of interest is often just as bad as a real one, and changing the logo does nothing if not give the appearence of which side we support. Bawolff (talk) 23:41, 1 March 2022 (UTC)
Why give fodder to the trolls who constantly attack our coverage as having a 'western' and 'anti-Russian' bias? We claim to have a mission to chronicle events in a neutral fashion, based on reliable sources. It is quite hard to square that mission with outright support for one side in an ongoing war. As an aside, I find it quite amusing to see such a proposal now. Back when this conflict broke out, in 2014, we barely had any tools to control the swarm of Russian trolls that began inserting disinformation of all sorts into our articles. And most people, frankly, didn't care. Administrators, by and large, ignored Wikipedia articles on the conflict then, and it was left to individual editors, like myself, to ensure Wikipedia's mission and policies were implemented. We fought tooth and nail to preserve Wikipedia's neutral point of view in the face of that onslaught, and to make clear that we didn't accept propaganda from either side. Take an open side in the conflict now, and all that hard work goes out the window. All you'll do is validate their long-held feeling that we, the Wikipedia community, are part of some kind of western conspiracy against them. Why should we give these people that satisfaction? RGloucester — ☎23:50, 1 March 2022 (UTC)
The proposal is made in good faith, but in general, I don't support any changes to the Wikipedia logo (even temporary ones) unless the reason for the change has something to do directly with Wikipedia (e.g. Wikipedia's 20th anniversary). It's a slippery slope if we start allowing non-Wikipedia related changes to the logo. Some1 (talk) 00:08, 2 March 2022 (UTC)
Oppose as Wikipedia should always be NPOV. Whilst of course it is right to want to show support for Ukraine, Wikipedia is not the correct place for doing this. Joseph2302 (talk) 00:13, 2 March 2022 (UTC)
Definitely not. Our work here is to document notable information and make it freely available, not to take political stands. – Jonesey95 (talk) 01:39, 2 March 2022 (UTC)
Oppose, though I acknowledge (and deeply sympathize with) the good intentions. It is not our place to be taking sides in a conflict, only to report what RSes say. GeneralNotability (talk) 01:46, 2 March 2022 (UTC)
Oppose. I come at this from two angles. 1. Wikipedia is an encyclopædia, it is not a platform. It aims to be and is widely regarded as a serious and relatively neutral source of knowledge. The SOPA situation was entirely different as it directly impacted upon Wikipedia itself and the community and the foundation was right to take a stand. 2. I am very sympathetic to the Ukrainians, and especially the ones I was fortunate to meet at various Wikimedia events. I hope they win against the bullies attacking them, and I don't think there's any problem with saying that. But I am also sympathetic to many other people and causes be they humanitarian, social, political, technological or musical, and I would not expect Wikipedia to reflect my point of view or sincerely held beliefs on those issues. The Wikimedia movement, separate to Wikipedia, can take a stand and especially in support of our WMUA and WMRU brethren (for it is governments, not people, that start wars and there's plenty of evidence this one doesn't have much home support), but its main product is at its best when it can remain dispassionate about things which can divide or polarise people. Orderinchaos02:47, 2 March 2022 (UTC)
If it was a prerogative of community consensus to do this thing (to be clear: it is not) I am glad to see consensus emerging to oppose. And while I've no standing to formally speak: I, too, oppose this notion and say so for the record.--John Cline (talk) 06:25, 2 March 2022 (UTC)
Oppose due to violation of WP:NPOV. In this case, even though my sympathies are with Ukraine, I would not want to set a precedent that the Wikipedia logo should be changed for political causes. --Metropolitan90(talk)07:33, 2 March 2022 (UTC)
Would undermine our reputation for neutrality. Political activism which actually relates to or threatens Wikipedia is sometimes acceptable, but Ukraine isn't that. Hut 8.508:32, 2 March 2022 (UTC)
I do think there could be times when it would be appropriate for Wikipedia to take sides. In this case, the facts speak for themselves so loudly and clearly that it's not necessary ---- and if we did use a Ukraine flag, then we would be giving credence to the Russian authorities' line that everything written by a Westerner is a lie.—S MarshallT/C11:13, 2 March 2022 (UTC)
Putin, and his invasion, are both scum and on a personal level I encourage people to help Ukraine as best they can. However, in terms of human rights issues, this invasion is not different from others that have occurred and we've not acted. The tough bit about being neutral is, well, having to be neutral. We should only publicly state positions on direct threats to the movement. So I'm 100% in favour of showing banners to those who might be having access cut-off and being freer than normal with IPBE, and the Foundation can offer additional Tor support, and so forth. Nosebagbear (talk) 11:33, 2 March 2022 (UTC)
Oppose as above. Individuals can take political positions; the wider WMF should not. Although saying that wasn't there a black out a few years ago in protest of something? However, solidarity with Ukraine, always. GiantSnowman11:41, 2 March 2022 (UTC)
Oppose While my personal self may be horrified at what Putin is doing in his invasion of Ukraine, I don't believe that, at the organization level, English Wikipedia should be taking positions. This is not what we do here. Write good articles on the subject and let the truth be our political statement. But there's no need to take a symbolic gesture. --Jayron3211:42, 2 March 2022 (UTC)
Oppose I think that that is not necessary. Wikipedians are best in what they are doing right now: providing information to the world. This is also best serving to those we care for. Compare it to media outlets that don't have a blue-yellow ribbon on their sites either. Ziko (talk) 12:29, 2 March 2022 (UTC)
As a former board member, I can say that if we have a clear consensus from the community, they will support us in our decision from a technical perspective. Doc James (talk · contribs · email) 23:24, 1 March 2022 (UTC)
I think we absolutely should have involved the WMF and further believe that they will decline our request if or when we do. The Wikipedia logo is not subject to our consensus and it is not licensed for any modification or reuse. Per Wikipedia:Copyrights § Reusers' rights and obligations "The only Wikipedia content you should contact the Wikimedia Foundation about are the trademarked Wikipedia/Wikimedia logos, which are not freely usable without permission". Best regards.--John Cline (talk) 02:02, 2 March 2022 (UTC)
This seems like a good idea, however i can see a few issues with it, mainly making it seem like Wikipedia is picking sides. Wikipedia tries to remain neutral, however if it seems like we're supporting Ukraine and not remaining neutral, then that neutrality can seem questionable. So really, I'm on the fence about this. I think there's some policy or essay somewhere relating to this (besides WP:NPOV) but I can't find it at the moment. ― Blaze WolfTalkBlaze Wolf#654523:32, 1 March 2022 (UTC)
This is certainly intresting, but I'd like to know if anything of this order has been attempted before on the English Wikipedia (as in changing logo/main page for a cause). What was the outcome? I think there was some proposal back when Floyd died, but I am not sure. Rlink2 (talk) 23:34, 1 March 2022 (UTC)
I'm tempted to notify Jimbo about this since not only does this seem like something he should be involved in, but he also appeared to have something to do with that as well. ― Blaze WolfTalkBlaze Wolf#654523:42, 1 March 2022 (UTC)
The reason WP was active in the SOPA one was due to the direct threat to WP's livelihood. We have tried others where WP's fate was far from being in danger and more political (I recall something proposed around the Hong Kong protests), but the community has balked at such direct political messaging.--Masem (t) 23:45, 1 March 2022 (UTC)
Probably the most frequent ArbCom principle cited in its history: "The purpose of Wikipedia is to create a high-quality, free-content encyclopedia in an atmosphere of camaraderie and mutual respect among contributors. Use of the site for other purposes, such as advocacy or propaganda, furtherance of outside conflicts, and promotion of political or ideological struggle, is prohibited." Straight-up taking sides in a literal war is about as problematic as it gets, on par with propagandising in an election or religious dispute. --Yair rand (talk) 23:53, 1 March 2022 (UTC)
Would support, but I am concerned whether it would make wikipedia a target for partisan hackers. Rightly or wrongly, Wikipedia is a source hundreds of millions rely on each day and we should do what we can to protect the flow of information. Also of concern is dozens of less public tragedies occur every day affecting similar and larger population sizes without being given the benefit of the public awareness 300 million page views a day will bring.Slywriter (talk) 00:11, 2 March 2022 (UTC)
The Wikimedia Foundation, the political lobbying organization, should of course weigh in with their support for the Ukrainians. I don't know about the current executive director, the the former ED was all about tweeting her politics all the time. The encyclopedias themselves should stay out of politics and remain neutral. – wbm1058 (talk) 04:22, 2 March 2022 (UTC)
Hello everyone,
I want to briefly explain to you all why the Georgian Wikipedia modified the logo (in the color of the Ukrainian flag) and state the position of the Georgian community.
We are in full solidarity with our Ukrainian colleagues and the Ukrainian people in the struggle for freedom and independence, and we hope that the invasion and bloodshed will end as soon as possible. We pray for them. Due to solidarity with the Ukrainian people and our colleagues, who are now under fire and bombardment from the Russian army, we have temporarily changed the Wikipedia logo.
I myselfs, as well as all editors from Georgia and the absolute majority of editors in Georgian language ourselves 14 years ago (2008) became the target of Russian aggression, when Russia attacked Georgia and occupied our regions, so we know what our Ukrainian colleagues are feeling and experiencing now. This triggered our respective response.
The decision to change the logo was taken unanimously by the Georgian community, in full compliance with the principle of transparency. You can check this here.
The Georgian community remains completely neutral in its coverage of events in Ukraine. Unlike some larger Wikipedias, Georgian Wikipedia praises academic freedom and is adherent to the principle of neutrality in academic materials. Our policies, as well as checks, are well in place and all of our articles are almost identical in neutrality as in English Wikipedia. Accusations of non-neutrality are unfair, unbased and demonstrate the preexisting bias from the accuser. We recommend everyone to double-check and then blame. All accusations of lack of objectivity are unfounded.
Finally, every Wiki community is independent and decides on specific actions themselves, in adherence with the principles and values of our Movement. There is a huge difference between bias in articles and demonstration of solidarity - we are adherent to the principles of neutrality as I have already stated above, as much as the English Wikipedia, but nobody can deny us of our right to express solidarity in the way we deem it appropriate, in support of people who are part of our Movement, who are dear to us, and are currently suffering.
Hi Mehman - I would definitely concur that Georgian Wikipedia is within their bounds to demonstrate their support publicly - it's not like it's a wild, outre, judgement that couldn't reasonably be arrived at. Here, we have a "if we do this, logically we should be doing it for b-z issues, too, and thus the safe route is not to start" Nosebagbear (talk) 11:39, 2 March 2022 (UTC)
Hi Nosebagbear. My this message is just information about the position of the Georgian Wikipedia community, I wanted to explain our position to everyone and at the same time I don't call someone to something. Sure, each community has its own right to decide issues within its community. Thank you, --Mehman9711:47, 2 March 2022 (UTC)
@Mehman97: thank you to the users of Georgian Wikipedia for their support of the Ukrainian people! We in Russian Wikipedia, unfortunately, failed to place a banner in support of the peace: about 60% of users supported it, probably about 20% opposed it as political activism, and probably about 20% shamefully supported this gruesome invasion (see ru:Википедия:Голосования/Украина), while 66.7% of support for the banner were necessary. Wikisaurus (talk) 13:16, 2 March 2022 (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.
RfC: Growth features to all newcomers
Latest comment: 2 years ago51 comments25 people in discussion
The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion.A summary of the conclusions reached follows.
There is a clear consensus to go forward with the proposal of giving the growth team features to 100% of new accounts and a smaller portion of them receiving the mentorship feature. As this consensus is clear I am closing this now as per Wikipedia:Requests_for_comment#Duration. Barkeep49 (talk) 16:54, 2 March 2022 (UTC)
Hi everyone – I'm Marshall Miller, the product manager for the Growth team at WMF. I last posted here in September 2021 with an RfC about giving the Growth features to 25% of new accounts, which was an increase from trialling the features with 2% of new accounts in June 2021. That RfC passed, and the resulting data indicated that the features continue to help newcomers make valuable edits with low revert rates, as well as help them connect with experienced users to get questions answered. After discussing this trial period, community members who have been following closely have agreed that the next step would be this RfC to give the Growth features to all newcomers, making it the default onboarding experience on English Wikipedia. Thank you to the many community members who have participated in discussions about the features and helped put together this proposal!
Specifically, the proposal is to give the Growth features to 100% of new accounts going forward, with a smaller portion of them receiving the mentorship feature.
The reason that the mentorship portion of the features goes to a smaller portion is because of mentorship capacity. About 60 mentors are signed up now. Going forward, as we improve the mentorship tools and more mentors sign up, we'll continue to work with community members on whether to increase or decrease how many new accounts receive mentorship.
I tried to keep this RfC brief -- please see the sections below for additional details!
Background (Growth features)
Over the past four years, the Growth team has been developing a set of features meant to improve the experience for new editors. The goal of our work is to help newcomers make successful first edits, instead of them leaving from frustration or confusion. The Growth features are now on all Wikipedias, without substantial concerns from communities, and have been shown in multiple experiments to increase the engagement of newcomers.Newcomer homepage on English Wikipedia
The Growth features include the following:
Newcomer homepage: a special page with useful actions that newcomers are encouraged to visit immediately after account creation, which they can access by clicking their username at the top of the browser window.
Suggested edits: a feed of articles that have maintenance templates such as {{Advert}} and {{Underlinked}}. Newcomers can choose topics of interest to filter the feed, like "Fashion", "History", or "Physics".Help panel on English Wikipedia
Mentorship: newcomers are assigned a mentor from a list of experienced volunteers. A pop-up form helps them submit a question to their mentor's talk page using a simple interface. Whereas Adopt-a-user is meant to be an enduring connection for a newcomer, "mentorship" in the Growth features is meant for quick questions.
Help panel: when the newcomer is editing an article, the help panel is like a collapsible mini-homepage, providing relevant help links and the ability to ask mentor questions.
Results (Growth features)
Since September 2021, 25% of new accounts on English Wikipedia have received the Growth features by default, with 5% of them receiving the "mentorship" portion of the feature (because we did not want to overwhelm the limited numbers of mentors who signed up on this page.) In looking at the data from these past months, we see similar patterns as with the original 2% test (see a data analysis focused on January 2022 here):
If the Growth features become the default onboarding experience for all new accounts, it might be important for the community to think about updating the various other welcome templates, documentation, tutorials, and help content to incorporate the Growth features. For instance, a tutorial that currently says, "Find some simple edits to get started!" might be updated to, "To get started, visit your homepage by clicking on your username, where you will find some simple edits to do." I don't think that updates like these should block deployment, but could be something to discuss and adapt in an ongoing way.
There are many more details and background to this work, which can be discovered in the project page and talk page. Thank you all for weighing in. I'm looking forward to hearing everyone's opinions and answering any questions.
Discussion (Growth features)
Weak Support with the tiniest possible reservation that I'd prefer "100% of newly autoconfirmed accounts, upon autoconfirmation" (if so stipulated, my support would be unreserved). Thank you.--John Cline (talk) 00:03, 17 February 2022 (UTC)
Would that not rather defeat the whole point if, for four days, a new account user could neither seek the help they might need, nor be guided to make simple suggestions of edits to make via this feature? The RfC already states the evidence has shows that 50% fewer new user edits get reverted from those who have the Homepage enabled than who do not have it, so waiting to be autoconfirmed would be a lost opportunity for newcomers to engage constructively from day one. Nick Moyes (talk) 00:57, 17 February 2022 (UTC)
Strong support This is a well-thought out tested and proven feature, so anything that guides and helps a new user from the first moment they create their account is to be welcomed. (The Homepage can always be ignored or disabled in Special:Preferences if it's not wanted, too.) Nick Moyes (talk) 01:06, 17 February 2022 (UTC)
Support New editors who are not looking to vandalize or cause trouble have a daunting learning path. This can help address that. Schazjmd(talk)01:15, 17 February 2022 (UTC)
Support we need to help keep new editors since the implementation of Help:Introduction all over that has cause us to lose thousands of new editors. The more the help intro is linked the worst it gets...... hope this works and retains more editors.Moxy-
Support, however I think some things should be improved, for example I got a suggested edit for Luxor Evolved that said it was an easy edit that just required copy-editing. However when going to the actual article the issue is much larger than simply just a copy edit, so improvements need to be made to the rating of suggested edits that factor in the amount of tags on the article to determine the difficulty. ― Blaze WolfTalkBlaze Wolf#654517:56, 17 February 2022 (UTC)
Hello @Blaze Wolf -- thanks for thinking critically about the features. Yes, I agree that the way we're suggesting edits right now is rather blunt. Like you discovered, a given maintenance template may not really convey the full extent of the article's needs. In the guidance we give during the edit, we try to tell the newcomer that they don't need to fix the whole article, and even just one small change is valuable. But I agree that a newcomer could easily be intimidated by a weak article.
Another issue exists in the other direction: sometimes an article will have a maintenance template on it, but the problem has already been fixed without the template being removed. In those cases, the newcomer is confused because they don't see anything to change. We've thought a little about whether to encourage the newcomer to remove the template, or to encourage other more experienced users to review the edit and remove the template.
As an effort to address both these issues, the Growth team has been working on our newest initiative: structured tasks. The idea is that we could use algorithms to identify articles that have clear issues and then point those specific issues out to the newcomer so they know just what to do for their first edits. We've built two of these suggested edits so far: "add a link" (being tested on 10 Wikipedias) and "add an image" (being tested on 4 Wikipedias). These are going well so far, and I plan to discuss them more on this wiki once they're a little farther along. I would appreciate your thoughts on the talk pages for those projects! MMiller (WMF) (talk) 19:16, 17 February 2022 (UTC)
@MMiller (WMF): Hello Miller! Glad to see that these issues are indeed being addressed. I will certainly check out those projects and provide any feedback I may have on them. I remember one time I was just looking at the newcomers tasks for an edit to make and saw a copy-edit task that was easy, but when I looked at the article, the issue extended far beyond just copy-editing. ― Blaze WolfTalkBlaze Wolf#654519:29, 17 February 2022 (UTC)
Strong Support. These new features really make things much more friendlier and has proved to have benefits. While mentorship features need some additional kinks to be worked out, they will still work perfectly fine at a small fraction. Panini!🥪18:00, 17 February 2022 (UTC)
Support. Firstly, nice work on this one so far. What are the other implications of enabling for 100pc? There are a few templates that you mention that need to be updated. Are there any other pre-works that need to be thought through prior to enabling for 100pc? I see the mentor assignment feature as well. What is our mentor to mentee ratio? Would we be able to keep up with the 4x demand? Also, what are our measures of success? It seems like the revert rate is one measure. Are we adding any metrics around editor sustainability. i.e. how many of these new editors stay on versus dropping-off. Ktin (talk) 18:06, 17 February 2022 (UTC)
Hello @Ktin -- thank you for looking over the proposal. Regarding the other implications of enabling for 100%, I think we need the eyes of many community members on it so that we can think of everything. As an example, the left navigation menu on desktop has a "Learn to edit" link, which leads to Help:Introduction (I know @Sdkb has been heavily involved in that content), and we would want to think about whether that link should continue to be there, to say what it says, and to lead where it leads. Another aspect is for in-person/virtual events. Edit-a-thons frequently start with, "Okay, everyone create an account!" After this change, all those new account holders will be prompted to go to their homepage to edit, and event organizers will need to be aware of that prompt and decide how they want to address it.
Good questions regarding mentorship! We've talked about the scalability of mentorship this a lot on this page, but I did not include a lot of detail on it in the RfC so that it remained more focused. Right now, mentorship is only being given to 5% of new accounts because of the limited number of mentors. During the month of January, there were about 50 mentors and they each got about 5 questions per month, which is the load that people seem to feel comfortable with. To scale that up to 100% of newcomers, there would need to be 1,000 mentors, which might require more complex management systems from the community. So we decided that in taking the Growth features to 100% of newcomers, we would increase the share getting mentorship to 10%, and continue to increase (or decrease) as needed while more mentors are recruited and the features improve. Does that make sense?
Regarding measures of success, there are several things our team looks at. First is the edit count and revert rate, which helps us see whether newcomers are using the features and whether they seem to be making a positive or negative impact on the wikis. But more importantly, we look at "activation" and "retention". "Activation" refers to whether the features cause newcomers to make a first edit when they otherwise would not have. In multiple contexts, the Growth features have been shown to increase this number -- in our most recent experiment on several other Wikipedias, using the experimental "add a link" feature, it increased the chance that a newcomer would make an unreverted first article edit by 17%. And these experiments indicate that "retention" (which you referred to as "editor sustainability") is increased by a similar amount. We're continuing to analyze experiments like these to understand the impact of the features. And finally, a really important measure of success is community reception: do these features fit in with how communities work or are they disruptive? So far, this has gone very well: the features are on all other Wikipedias and none have requested that they be removed. Please let me know if you have any thoughts or ideas! MMiller (WMF) (talk) 19:26, 17 February 2022 (UTC)
We're on standby to update the tutorial series however is needed when this rolls out. The useful links page will need an added line, and we may want to suggest that users try out the suggested edits feature at the start rather than just toiling in a sandbox. Overall, I see separate roles for the tutorial series and Growth features: the Growth features help out newcomers as they're trying to do something, and hopefully do so well enough that there's no need for them to consult a manual. The tutorial, meanwhile, serves as a newcomer-friendly manual for the times when our interface still fails at making a task easy enough to do without aid, plus as a way for particularly eager newcomers willing to devote half an hour or so to learning the ropes to jumpstart their journey. Different people like to learn in different ways—some through experimenting, some through asking questions, and some through reading—and it's good we cater to each. Over time, I hope the amount of things we'll have to cover in the tutorial will shrink as the interface improves. For instance, the upcoming rollout of the Reply Tool will allow us to simplify the talk pages modules. {{u|Sdkb}}talk19:46, 17 February 2022 (UTC)
Support. And some questions for you MMiller (WMF) ;) It is very interesting to see the type of edits. Do you have any generalization or write up on the types of edits, and are there any enhancements based on the observations? Looking at the first couple dozen (not a useful sample) I noticed some changes of UK to non-UK spelling, adding an Oxford comma... exactly the kinds of things someone might revert (I didn't check if the page was UK spelling indicated or not) in a way that would turn off a new user... other thoughts on how to guide to a great start? And thanks for the work... Chris vLS (talk) 21:30, 17 February 2022 (UTC)
Hi @Chrisvls -- thanks for checking out some of the suggested edits! I just want to make sure -- hopefully you did some constructive and valuable edits in the sample you looked at, right? What did you notice about those?
One of the biggest challenges we've faced in the Growth team's work is this tension: On the one hand, it's important for newcomers to quickly make a valuable edit so that their "wow, I just edited Wikipedia" lightbulb lights up. If they can't make an edit quickly, many of them leave in confusion or frustration. But on the other hand, editing Wikipedia can be so subtle and tricky that they need to learn guidelines and rules before they can do it -- and requiring them to learn before doing turns a lot of people away. The approach we've taken in the past has been to make help materials available from the editing experience via the help panel, but we don't require newcomers to consume it before editing.
But the approach we're trying now is bolder, which is to guide newcomers step by step through doing a very specific edit. This is the "structured tasks" idea that I mentioned to Blaze in a comment above. We think that if we hold newcomers' hands through their first edits, they'll develop an understanding and respect of our rules and policies. We don't know yet if that hypothesis is being borne out -- we do now that people are doing a lot of these edits and that they're helping people edit who would not have otherwise. We're still trying to figure out if those edits lead to other edits and to learning. Definitely interested in your thoughts on this approach! MMiller (WMF) (talk) 02:53, 18 February 2022 (UTC)
Support: A suggestion: Maybe add some other tasks? For example, some maintenance tasks, like anti vandalism. Additionally, I think a link to the task center could be added to the "get help with editing" menu. Finally, could an easy way to turn off the homepage be added? – AssumeGoodWraith (talk | contribs) 04:56, 18 February 2022 (UTC)
Thanks, @Sungodtemple, that's right. @AssumeGoodWraith -- I agree, though, that there is not a clear way to turn off the homepage from the homepage. Which is the part that might cause one to want it turned off? I am thinking it's the part where clicking your username takes you to your homepage instead of to your userpage -- is that right? Because without that aspect, it's just a tab that appears (and is easily ignored) when you are on your userpage or user talk page.
Regarding the idea of adding different inks to the "get help with editing" menu, this is actually something that we've enabled communities to configure for themselves! Administrators can alter those links from Special:EditGrowthConfig in the "Help Panel Links" section at the bottom. The idea is that communities would discuss which links should go in there, and then make the change, which would affect all users. MMiller (WMF) (talk) 17:02, 18 February 2022 (UTC)
Support: well-tested, provably effective and few to no drawbacks. We have a much-too-steep learning curve for newcomers and desperately need more volunteers. — Bilorv (talk) 12:09, 18 February 2022 (UTC)
Support increase, certainly an effective feature to help newcomers. As a mentor I would not mind getting more questions from mentees. Pahunkat (talk) 12:30, 18 February 2022 (UTC)
Support As an event coordinator, I find it confusing when new editors' interfaces behave differently, depending on their experience, preferences and other choices. So, it would be best to get everyone on the same page. As for mentors, it might be better to have these assigned when requested so that the limited pool is not confused and burdened by accounts that are not really serious. The home page might have a button to request a mentor. Andrew🐉(talk) 13:14, 18 February 2022 (UTC)
Hi @Andrew Davidson -- it's valuable to hear the perspective of an event coordinator. Regarding mentors, you're mentioning an idea that we discussed in this section about how to lower the burden: we're already building a way for users to opt-out of mentorship in case they don't want to have a mentor, or don't like their mentor. What if we defaulted all newcomers to being "opted-out" of mentorship, and required them to click a button to opt-in and "get a mentor"? Here's a mockup of what that might look like. You can see in the conversation that people were divided on whether it would be harmful or helpful to increase the barrier to entry for mentorship. What do you think? MMiller (WMF) (talk) 17:06, 18 February 2022 (UTC)
The events I support typically have lots of new women editors. They are usually quite cautious and may scare easily. It therefore seems best to give them visible control over the mentor feature so that they don't feel that they are being rushed into a subordinate relationship with a stranger against their wishes. The opt-in button therefore seems appropriate to give a feeling of control and security. Andrew🐉(talk) 18:40, 18 February 2022 (UTC)
Seconding this - I think randomly being assigned a mentor can easily be confusing/alarming ("who is this person talking to me?! did I do something wrong?") or feel like an imposition ("I just wanted to make an account idly and now I feel pressured to edit because this mentor is watching me"). But you don't want new people to miss out on this, either, so an extremely obvious DO YOU WANT A MENTOR? CLICK HERE! DO YOU WANT TO LEARN MORE ABOUT MENTORSHIP? CLICK HERE! button on the homepage would be a good idea. -- asilvering (talk) 06:41, 23 February 2022 (UTC)
This is a good idea, however I feel that it might also cause some harm if the newcomer doesn't actually know what it might do or some other things. That said, this will definitely fix the issue of users signing up for accounts, and then never making a single edit with them. This clogs up the mentor dashboard with a lot of users who won't make a single edit. I feel a better solution might be if a user registers for an account, they're assigned a mentor. IF they don't make any edits after a certain amount of time they might get a notification that says something like, "Having trouble editing? Ask your mentor and they might be able to help you!" and then if they continue to not make any edits whatsoever or ask any questions, then they will automatically be unassigned a mentor and have to click the button again to assign themself a mentor (could possibly be the same one they had previously if that info could be stored somewhere or a new random one). ― Blaze WolfTalkBlaze Wolf#654518:59, 18 February 2022 (UTC)
Strong support I've seen firsthand that this really is a great asset to the encyclopedia, and it's probably the click we've needed after a bit of stagnation recently with regard to integrating new users (especially with a huge burst in new users due to the pandemic). I wish this was a feature when I was starting out! Curbon7 (talk) 09:03, 20 February 2022 (UTC)
Support: I was a guinea pig for the dashboard, and while I don't think it's perfect, it's certainly far better than nothing. It would have been cool to get a mentor too; from the perspective of a newbie editor, this looks like a great feature. Thanks to the growth team for your work on these features! (And for being friendly when I showed up with questions and comments.) -- asilvering (talk) 06:34, 23 February 2022 (UTC)
@xaosflux Er, are you sure? There is nothing about that on my newcomer homepage, I never asked for a mentor (indeed, I learned that mentors were even a thing at all by having googled to find the growth team talk page to leave the comments I mentioned in my vote), and I have no idea how you came to this conclusion. -- asilvering (talk) 02:17, 25 February 2022 (UTC)
@xaosflux No, it does not. The modules on that page are "suggested edits", "your impact", and "get help with editing". Where are you finding this database report? -- asilvering (talk) 17:45, 25 February 2022 (UTC)
@xaosflux Can you please answer my question about where you are finding this database report? I've described what my newcomer homepage looks like, obviously I have it enabled. -- asilvering (talk) 18:31, 25 February 2022 (UTC)
@Asilvering literally by invoking that #mentor parser function I quoted above, the "Elli" test up there is not text, it is the live output of that parser function. I believe you, but didn't know if you could go to homepage if following the link, while also not having it enabled in preferences. There are several "opt out" tasks open, but I didn't think any of them were live. So, I don't know why you can't see your mentor there. Think there was a typo above, I was trying to say "that's what the database reports", not that there was a 'database report' to read. — xaosfluxTalk18:37, 25 February 2022 (UTC)
@xaosflux Ok so it's not just randomly picking a mentor for funsies... weird. Well... it would have been neat to know I had one, I guess! But as I've said above I would definitely prefer for it to be an opt-in thing with a very obvious opt-in option. -- asilvering (talk) 18:45, 25 February 2022 (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.
@Yahya: Ah interesting. Not sure if there's much we can do here on enWiki since they haven't made any edits since this one and to my knowledge we can't use CU to connect IPs to accounts. ― Blaze WolfTalkBlaze Wolf#654523:22, 2 March 2022 (UTC)
Limit or call out citation clustering
Latest comment: 2 years ago2 comments2 people in discussion
Propose to limit or cluster citations from the same author, university department or research center.
Pages having different papers on the same research topic from the same author should be clustered or limited. RS consisting of the same conclusion or narrow variences of it from the same author should be treated as a single reference.
Why? Inflating the RS count prevent good faith discussion on changing an article. A conclusion repeated in three papers from three years is one conclusion that should not block changing a page based on one new RS. — Preceding unsigned comment added by 2600:1700:D591:5F10:9998:5F2A:1AD7:F946 (talk) 01:16, 3 March 2022 (UTC)
It is not a good idea to artificially limit citations that support wikitext claims just because they are from the same author or work. Assuming this is not about single-source (or almost-single-source) articles, but such can be tagged now. It is incumbent on editors to provide additional supporting sources if they exist, but this is not an obligation. It is also incumbent on editors to add contrary wikitext claims and the citations to support them.
The second paragraph is better. Authors may have an area of expertise and associated conclusions they reinforce in work after work. The final real-world source in all citations is the author, so one may see multiple such citations as coming from a single source. But this again is not a citation issue. Citations exist to support wikitext claims. That's all. What you propose falls under NPOV and balance which are wikitext, not citation issues. 71.247.146.98 (talk) 13:54, 3 March 2022 (UTC)
Restricting user page creation of new users
Latest comment: 2 years ago15 comments14 people in discussion
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 current speedy deletion criteria has criteria U5: blatant misuse of Wikipedia as a webhost and G11: unambiguous advertising or promotion. A lot of user pages created in user space by new users seem to be nothing more than self promotion attempts. And I have seen it all - people using Wikipedia like Facebook, Tumblr, or their own personal website. New users wanting to contribute an article seem to use WP:AFC to do so. On this page, of the 68 user pages that were deleted on that page, all of them were speedied, 36 were deleted under WP:U5, and the rest were deleted under WP:G11, WP:G5, and similar criteria. Only three user pages were deleted under U1. Given this, and the fact that new users often create user pages without thinking about whether they will actually contribute to Wikipedia, I think restricting new users from creating user pages may be necessary to help cut down on the unnecessary user pages that get deleted every day. Aasim - Herrscher of Wikis00:08, 28 January 2022 (UTC)
Poll (restricting user page creation for new users)
Agree - Is there any immediate need to have a userpage as soon as you register? I think this would cut down on the userpage spam. – AssumeGoodWraith (talk | contribs) 00:58, 28 January 2022 (UTC)Oppose 04:03, 28 January 2022 (UTC)
Whoa there some processes - such as enrolling in registered education courses via https://dashboard.wikiedu.org/ help you create your userpage, which you would be doing as a very new user. A quick query right now shows that 18 of the last 75 pages created in User space were base userpages of exactly this sort. Also, this doesn't specify "base userpages" and I certainly wouldn't want to stop sandboxes. — xaosfluxTalk01:38, 28 January 2022 (UTC)
Oppose. Sure, miscreants can abuse their user page, but if it's not happening in mainspace, I just can't get too worked up over it. WP:AGF, my friend. -- RoySmith(talk)03:11, 28 January 2022 (UTC)
Oppose In addition to the things this proposition would completely break (like Wikipedia Adventure and WikiEdu), this is a not-as-helpful-as-it-seems proposition because Special:NewPages already makes it very easy to find and tag bad-faith userpages if you know how to use it efficiently. Curbon7 (talk) 03:54, 28 January 2022 (UTC)
Oppose Having users create their own userpages is a great way to ensure user retention. It worked for me: my first edits were to create my user and talk pages. It was so effective that it ensured that like 4 years later when I actually became an active editor, I didn't just create a new account, I went and found the password to this account so that I could have that user and talk page. The rest is history. CaptainEekEdits Ho Cap'n!⚓04:39, 28 January 2022 (UTC)
Oppose This measure isn't necessary. I understand where the idea is coming from, but purely promotional accounts that are WP:NOTHERE make themselves known pretty quickly. If they aren't allowed to make userpages, they'll just make other pages, like pages in article space. They'll cause trouble however they want, and we'll root them out sooner or later. We can't really plug every hole in this dyke. The sad thing is that Wikipedia presents an irresistible lure to spammers and self-promoters; it's a website where they think they can host pages they don't have to pay for. There's really nothing we can do to stop that, short of completely shutting out new accounts from literally everything we would even use as a yard stick to even graduate them to trusted statuses like autoconfirmed users — and that obviously isn't going to work. Zeke, the Mad Horrorist(Speak quickly)(Follow my trail)05:44, 28 January 2022 (UTC)
Oppose A good-faith proposal with some advantages, but they are vastly outweighed by the many good points made by preceding opposers. WP:SNOW is forecast. Certes (talk) 12:39, 28 January 2022 (UTC)
Oppose. In addition to what everyone else has said, when training we strongly encourage users to start with their userpage as a safe introduction to editing. Editors with blue-linked userpages are also often treated better that those without in the event of any dispute about what they are doing so they are a positive for editor retention. The stats about speedy deletion, rather than showing a problem, seem to actually show the system is working. Thryduulf (talk) 19:24, 28 January 2022 (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.
Portal links on the Main Page: RfC workshop
Latest comment: 2 years ago1 comment1 person in discussion
Hi everyone, as you may remember there were two discussions in the past [5][6] about portal links on the main page which were inconclusive, mainly because of deficiencies in the proposals. To move this discussion forward, I thought that a workshop about how an adequate proposal should be drafted and formatted could be useful. I have created User:JBchrch/Portal links on the Main Page: RfC Workshop for this purpose. Anyone with an interest in this topic is more than welcome to contribute and comment. JBchrchtalk23:29, 12 March 2022 (UTC)
Book pages should treat dust jacket and industry commentary as biased, plus music and films
Latest comment: 2 years ago3 comments3 people in discussion
Numerous pages about individual books have quotes from the book’s dust jacket. These are biased and unreliable due to cross promotion of the commentator being a fellow author usually for the same publisher.
These promotional commentary should be removed from wikipedia.
Music pages, Devo Satisfaction song, should have these promotional comments removed also. Mick Jagger states thst Devo cover of the Rolling Stones Satisfaction is the best cover of that song. He would of course promote the cover since half of the sales of the cover go to the original artist, Mick Jagger.
Films such as Kirk Douglas quote praising his-son’s Falling Down film should be removed for the same reason.
Lastly, removing quotes from book introductions should be done since the introduction writer is paid to praise the book’s content. For anthologies, the introductory paragraph for a story is also promotional.
Although such quotes should not be used to support notability, not everything quoted from a book etc. jacket is promotional. Sometimes people involved in the book production are only credited on the cover. Music works credit personnel, and include tracklists. Even the promotional info (publisher annotations, liner notes etc.) may contain citable information if they are the explicit subject of wikitext. 71.247.146.98 (talk) 13:12, 3 March 2022 (UTC)
I agree with 71.247.146.98 on this one, I think it's really up to user discretion to decide whether a quote from a dust jacket is worth quoting or not. Maybe this could get some sort of tag or be added to something like WP:CrossPromotional like you said, but it shouldn't be outright banned in my opinion. Tolozen (talk) 06:19, 8 March 2022 (UTC)
Stale outdated sources
Latest comment: 2 years ago4 comments4 people in discussion
There needs a way to can mark a reference as stale needing an updated one.
Pages frequently have twenty year or older references in the first few paragraphs outdated omitting recent definitions of the page topic.
In the sciences and history pages this excludes recent research defining the topic by blocking new research from inclusion in the page top section.
It advantages the second generation of scholarly research to balance the first generation researchers work. For example, the first biography of a living president, one from just after death and onrpe from twenty years later when policy has run its course. — Preceding unsigned comment added by 2600:1700:D591:5F10:9998:5F2A:1AD7:F946 (talk) 01:01, 3 March 2022 (UTC)
You may have it backwards. If there is new material information about an article, the article can be edited and new citations should be added to support the edits. If this information necessitates the removal of older text, and that may depend on the way the article is structured, then the citations supporting the no-longer valid text should be removed. Sources are not "stale". The wikitext depending on them may be. 71.247.146.98 (talk) 13:02, 3 March 2022 (UTC)
If things have radically changed such that the old information is now incorrect then in many (probably most) cases there should be a history section that documents this and those old sources can be used to support that. If the old sources are not incorrect then why do you want to remove them? Thryduulf (talk) 16:41, 3 March 2022 (UTC)
There is a template that says "This article needs to be updated" that heads the article Diabetic diet. If you think the references in an article are out-dated, you could make a request to have this template heading the article. YTKJ (talk) 22:31, 8 March 2022 (UTC)
Latest comment: 2 years ago126 comments31 people in discussion
Note: This might not technically be a proposal, but I hope you'll excuse me posting here; I'm doing so in an attempt to make sure lots of people are aware of this upcoming change.
---
Hi y'all – the Editing Team is planning to offer the Reply Tool as an opt out feature to all people – logged in and out – at en.wiki this upcoming *Monday, 7 February 2022*.
The "Deployment Rationale" below is what's leading us to think now is a good time to move forward with this deployment. If this idea brings any concerns/questions to mind, we would value you sharing those thoughts so we can talk about them.
And for people curious about the work the Editing Team will continue doing to improve the Reply Tool, please see this update.
Note the 7 February deployment only pertains to the Reply Tool, NOT the New Discussion Tool (setting name: enable quick topic adding) or Topic Subscriptions (setting name: Enable topic subscription).
EDIT: to clarify, this deployment only impacts people (logged in and out) using talk pages on the desktop site. Said another way: this deployment would have NO IMPACT on people (logged in and out) using talk pages on the mobile site.PPelberg (WMF) (talk) 04:30, 3 February 2022 (UTC)
Deployment Rationale
The Editing Team has the impression that now is a good time to offer the Reply Tool as a default at en.wiki based on the following:
People do not seem to have any significant concerns about the Reply Tool being offered more broadly.[1]
The Reply Tool is reliable. Over the past 30 days, 99.9% of the 14,000+ comments 800+ people posted with the tool at en.wiki did not impact any other parts of the talk pages it was used on.[2]
Many people have confidence in the Reply Tool. At en.wiki, 2,800+ people have used the Reply Tool to post at least one comment since the tool was offered as a beta feature on 16 March 2021.[3] And of these 2,800+ people, 25% have used the Reply Tool to post 10 or more comments.
While there is additional functionality that could A) increase the range of comments people can use the Reply Tool to publish (e.g. votes[4] and unindented comments within existing discussions[5]) and B) expand how expressive the tool enables people to be (e.g. stronger template support[6] and signature customization[7]), we do not currently understand the implementation of these additional capabilities as needing to prevent people who are new from benefiting from being able to post comments more intuitively and for the comments they post being signed and indented in ways experienced volunteers expect and value.
Yes, the deployment planned for Monday, 7 February 2022only pertains to the Reply Tool, NOT the New Discussion Tool (setting name: enable quick topic adding) or Topic Subscriptions (setting name: Enable topic subscription).
Generally, I think this is the right direction to head—ever since Enterprisey developed his version of a "reply link" tool way back when, I have long been excited at the prospect of deploying this in a widespread format to help new editor engagement. With that being said, I would be mindful that this would be a relatively significant new feature in the editing interface, and some past rollouts of similarly significant new features have led to tension between the WMF and the English Wikipedia community (see e.g. Wikipedia:VisualEditor/RFC and Wikipedia:Arbitration/Requests/Case/Media Viewer RfC). I don't think the Reply tool is quite as invasive as VisualEditor and Media Viewer were, but because of those dark memories, I would be inclined to more broadly advertise to experienced editors that this change is going to occur—specifically, I'm thinking in MediaWiki:Watchlist-messages. Maybe this is overkill, but the English Wikipedia community can sometimes be really passionate against these software changes, particularly when they have the appearance of being performed without their consultation or consent. I've been using the Reply tool for a while now, and it is quite good—I just hope others see it the same way. Mz7 (talk) 09:43, 2 February 2022 (UTC)
Thanks for the shoutout! I agree with everything you said. I guess it may seem like a silly step (and I think it sort of is). But we should definitely hold an RfC of some sort if we've learned from the history of this sort of thing. It doesn't even have to be that long (a week?) or laborious.PPelberg (WMF) and the team, thank you so much for all your hard work on this! I've been waiting for this day for a long, long time. Would it be possible to get links to some of those "suspicious" edits (I'm assuming that's what "sus" means in that table)? I really appreciate the inclusion of the table in the first place. Enterprisey (talk!) 10:34, 2 February 2022 (UTC)
@PPelberg (WMF): we may at least post a note somewhere like our watchlist header when it goes live to help head off any "what's this" confusion posts. That being said, probably should have 2 targets ready: (a) the location any issues should be reported; (b) a description/help page of the new feature (which should include the opt-out directions). mw:Talk pages project/Replying isn't really a good landing page for either of those - it is more of a project tracking page. Are there better targets ready somewhere? — xaosfluxTalk11:14, 2 February 2022 (UTC)
@Xaosflux, there's mw:Help:DiscussionTools, which could be copied here. (Everything in Help: namespace at mw.org is public domain/CC-0, so you don't even have to worry about licensing attribution.) It might make more sense to put the section about the Reply tool in Help:Talk pages than to create another extension-specific page.
That said... it's already default-on for about half the editors in the movement. Across hundreds of wikis, I've seen about five requests for information on how to disable it and almost no bug reports. There have been some feature requests (e.g., support for voting-style discussions) and questions (e.g., why doesn't it recognize this editor's non-standard signature, or work on this page with a colored background?). Someone even wrote a quick user script (check the VPM archives; I copied it here) to change "[reply]" into the emoji or word of your choice. This experience suggests that we probably won't get that many questions, especially after the first day or two. Whatamidoing (WMF) (talk) 17:22, 2 February 2022 (UTC)
I'm thinking a watchlist notice would be good on launch day, something like:
{{Display/watchlist
|until= 10 DaysFromNowMonth 2022
|cookie=n
|text=The [[Wikipedia:Talk_pages_project#Reply_tool|'''Reply tool''']] from the talk pages project has been enabled for all editors. Should you have any issues or feedback, please [[Wikipedia talk:Talk pages project|let us know]].
}}
Making the reply tool opt-out is a big step for beginner friendliness. Wording should be this imo (with relevant links): "The talk page reply tool has been enabled for all editors. If you spot any issues or have any feedback for the Talk Pages project team, let us know at our talk page" ✨ Edtalk! ✨ 03:43, 3 February 2022 (UTC)
@Suffusion of Yellow good question. The deployment currently planned for this upcoming Monday will only impact people – logged in and out – who are accessing the desktop site.
hi @Suffusion of Yellow – the mw:Editing Team is planning to offer both the Reply and New Discussion Tools on mobile at an initial set of wikis within the next month or so (you can track progress on this work by following along with phab:T282638).
@GhostInTheMachine good question. This deployment does not include the Reply Tool being made available on mobile because we are still refining the user experience for it. We will have a prototype ready to share soon, would you be interested in trying it out and sharing what you think about it?
A tad short-notice for general awareness of rollout, but I've been using it on meta to get used to it, and it's significantly improved from even 3 months ago - especially in its tolerance to the most common thing I did to break it, which was adding ping templates as the first thing in the message. I think the first week will be a bit of a mess, but the general gain will be significant. Nosebagbear (talk) 09:50, 3 February 2022 (UTC)
As someone who is not at all tech savvy… please explain what this is and what it is attempting to accomplish - using non-tech language. Don’t assume people know what you are talking about. Blueboar (talk) 00:24, 4 February 2022 (UTC)
It adds a little reply link after talk page talk page posts that you can click on to reply to that particular message. It opens a small editing window below the message you're replying to, so you can reply without loading a new page. ScottishFinnishRadish (talk) 00:34, 4 February 2022 (UTC)
Alright y'all: it's been a couple of days since this discussion started and we thought it would be helpful to articulate the information that has surfaced in the discussion thus far. This way, we can collectively decide what happens next with this deployment with a shared set of ideas in our minds.
New Information
People are supportive: Everyone who has commented in the discussion thus far is supportive of the Reply Tool being offered as an opt-out feature, for all users (logged in + out), on desktop
Awareness is important: A significant number of volunteers who have commented in the discussion agree (and so do we!) that it would be wise to make as many people aware of this change as possible, ideally ahead of time. [1][2][3][4][5]
Announcement needs some more thought: There does not yet seem to be an agreement about what the most effective way(s) are of making people aware about the Reply Tool being made available as an opt-out feature on desktop.
*Please comment if you do NOT think aspects of the above are accurate. It's very possible I missed and/or misunderstood something someone said!
Next steps
With the "New Information" above in mind, I'm going to ping a few other folks who have been involved in testing and providing feedback about the Reply Tool[6][7] to hear what they have to say...
As people who are experienced using the Reply Tool at en.wiki[7], we wonder: what do you think might be effective ways for making the wider en.wiki community aware of this Reply Tool deployment?PPelberg (WMF) (talk) 03:06, 4 February 2022 (UTC)
A question and a couple of comments before as head into the weekend...
Question
@Ed6767, @Enterprisey, @GhostInTheMachine, @Mz7, @Xaosflux: as people who have said this deployment would benefit from many people being made aware of it ahead of time, how do you think this announcement or announcements ought to be made? Would an RfC be valuable? Would a MediaWiki:Watchlist message be effective? Might making more posts on pages experienced volunteers are likely to visit (e.g. a couple relevant noticeboards, Village pump (technical) as @Whatamidoing (WMF)has done) be the best approach? Some combination of these options?
Comments
A couple of thoughts about what the mw:Editing Team is thinking...
We agree with you in thinking that it's worthwhile to make as many people aware of the change before it happens as possible.
We think the deployment date ought to depend on people having enough awareness that it's happening. Said another way: we are committed to revising the deployment date to leave more time for making people aware, if that ends up being necessary.
Next step
At around 16:00 UTC this Monday, 7 February, I'll check back in with you all so we can decide whether we move forward with the deployment on Monday or push it back a few days to execute the plan y'all might've come up with over the weekend.
My only advice is “think in terms of next month rather than next week”. We here at enWP do not like surprises, and we tend to knee jerk reject things when surprised. So go very slowly with the role out. Announce the crap out of it - in as many different forums and formats as you can think of. Give people time to get used to the idea before you go live with it. Blueboar (talk) 02:53, 5 February 2022 (UTC)
Considering it is still not clear to me, and other members of the Editing Team, whether y'all (all of the volunteers who have participated in this discussion to date) think an RfC for this kind of change is necessary, in the immediate-term, we are delaying today's (7 February) planned deployment of the Reply Tool.
Next step(s)
You can expect to see another comment from me before 5:00 AM UTC (8 Feb) with a proposed next step or steps.
Of course, if any new thoughts/questions emerge between now and then, we would value you sharing them.
Alright y'all, people in this discussion seem to agree:
1) Some volunteers are bound to be surprised by this change, no matter how many announcements are made
2) "1)" notwithstanding, it's preferable the Reply Tool deployment be delayed until more announcements are posted
Next steps
With the above in mind, what do you think of doing the following?
@Enterprisey: are you able to take the lead on making sure this discussion is added to CENT?
@Xaosflux: are you able to finish the work required to ensure the Reply Tool opt-out deployment is included in the watchlist banner?
And then we can all come back together to talk about the deployment timing once we see what people say in response to the announcements Enterprisey and Xaosflux will have posted. PPelberg (WMF) (talk) 01:37, 8 February 2022 (UTC)
@Xaosflux ah, I see – thank you for sharing the link to the draft message. Although, what do you think about running the Watchlist message before the actual deployment?
...I ask the above thinking that people in this thread seemed to have agreed that making people aware of the deployment ahead of time is likely to be more impactful than waiting until after it's already happened. This way, people have an opportunity to raise any concerns.PPelberg (WMF) (talk) 20:22, 8 February 2022 (UTC)
@PPelberg (WMF): we certainly could do either or both, we generally only put something with a ready to go "call to action" in the watchlist, in that example it would be a "here is what this new thing is, tell us here of any issues". As far as a "before" goes, what is the call to action - if this is going to be a "proposal" that requires community consensus - then it seems big enough to advertise on WLN, a RFC section should be opened below that people can go to to participate in such a discussion. Has this evolved from a "the server owners are doing this thing" to a "should we do this thing" discussion? — xaosfluxTalk22:17, 8 February 2022 (UTC)
...we certainly could do either or both...
@Xaosflux: making announcements before and after the deployment sounds like a great idea to me.
Has this evolved from a "the server owners are doing this thing" to a "should we do this thing" discussion?
This discussion has made three points clear to me [i]:
All of the volunteers who have commented in this discussion thus far agree deploying the Reply Tool as an opt-out feature is a good idea
Many of the volunteers who have commented in this discussion agree there is value in announcing this deployment widely ahead of time
There does not seem to be a clear consensus among the volunteers who have commented in this discussion whether a formal RFC is necessary
Combining the three points above with the fact that we are not yet aware of any objections to the Reply Tool deployment plan, I see the objectives of the "pre-deployment" Watchlist announcement as being to ensure experienced volunteers are aware of: A) An upcoming change to the experience they have using talk pages on desktop and B) Where they can go to voice any question/concerns about said planned change.
So maybe the messages end up looking like this...
Before: "The talk page reply tool will soon be enabled for all desktop editors. Should you have any questions or concerns about this deployment, please join the discussion at Village pump (proposals)."
After: "The talk page reply tool has been enabled for all desktop editors. Should you have any issues or feedback for the Talk Pages project team, please join the discussion at the project talk page." [ii]
...what do you think?
---
i. Please comment if you see anything missing from, and/or inaccurate within, the three points I articulated above!
@PPelberg (WMF): seems fine, once a launch date is determined maybe we activate the WLNotice a week ahead of time, let it run for a week after - and include the launch date in the message. Is there a new target launch date? Banner blindness is a thing, so don't want to summon editors to a discussion where no decisions are going to be made. If this is going to be a traditional process, then sure we do one early. Traditionally we'd open a RFC, for about a month, get comments, determine the results, then proceed if there is established support; in general the "default" for changes is status-quo. — xaosfluxTalk10:28, 9 February 2022 (UTC)
I am going to say that I've only noticed one issue with the reply tool and i Have no clue what causes it or if it can still happen. For whatever reason, in the past some sections people created couldn't be found by the reply tool with no real reason as to why. I don't remember where this was happening or who the users were that were causing this to happen, however it appears to be very rare. ― Blaze WolfTalkBlaze Wolf#654503:10, 4 February 2022 (UTC)
Could you explain what "a bug in Parsoid causing it to render the page differently from the PHP parser" means in layman's terms? ― Blaze WolfTalkBlaze Wolf#654503:30, 4 February 2022 (UTC)
That's not relevant and is a distraction. You are being asked whether the explanation given at that link might match your experience. The explanation is saying that certain listed factors might cause "Could not find the comment..." and if those do not apply, the software might have a bug. If the latter, they would like a report including a permanent link to the page involved along with a description of exactly what you did and what you saw. The "file a task" is an overly optimistic request that you can ignore. Instead, post your findings here or at any noticeboard such as WP:VPT and someone will notify the appropriate people. Johnuniq (talk) 04:32, 4 February 2022 (UTC)
Geez dude. I was merely asking so I could try and understand what it means. If I can't ask questions here then I can go. ― Blaze WolfTalkBlaze Wolf#654513:51, 4 February 2022 (UTC)
Blaze, the core MediaWiki software that renders wikitext to HTML is written in the PHP programming language, but it's a one-way conversion. There is another component called Parsoid that can do two-way, and Reply Tool uses it because ... reasons. Visual Editor also uses the Parsoid service. (Apologies to all the technical peeps reading my mangled explanation.) ⁓ Pelagic ( messages ) 12:21, 6 February 2022 (UTC)
This is a visible change. The reply links positioned after every post aren't exactly an obscure UI element tucked away in a toolbar. Will this flip the setting for everyone who hasn't already turned it on then off again? People will notice and say "why weren't we asked?"
Any RFC or banner should run before changeover, not after. Even if it means we have to wait another fortnight or month. Putting it up after the fact would be a very bad look.
On the plus side, a lot of people are already familiar with Discussion Tools thanks to years of fantastic consultation and outreach from Peter and WAID. But enwiki is a big place and we might be surprised to discover how many people still didn't know.
No problem, @Pelagic. The exact date is not important to the Editing team, so if you all think we need to delay, then that's okay. Just please come to some agreement about what should be considered "enough".
To give some context, back in 2013, I personally posted announcements about the visual editor to more than 100 pages at the English Wikipedia, it had been discussed in the village pumps for months, the team ran CentralNotice banners in multiple languages for two straight weeks ...and many editors were still surprised. I remember one person saying that she had been on vacation for the exact 14 days that the banners ran. Most of us in this discussion have probably also seen CENT-listed RFCs that are claimed later to have not been well-advertised enough, because 99% of editors don't follow RFCs or CENT, and they sometimes regret that they missed important discussions. I have also seen an editor participate at length in a discussion about a proposed change, and later ask why there had never been any discussion about that change. All of which is to say: no amount of effort can completely prevent surprises. The English Wikipedia is too big for everyone to know about everything, and we have too much to keep track of to remember even the things we do talk about. I expect that most editors will consider the Reply tool to be a pleasant surprise, but I do expect its appearance to surprise a substantial number of editors no matter what we do or when we do it.
I feel your frustration, Whatamidoing. In my imaginary ideal world there would be a formal RFC that, for once, could come down clearly in favour of change, because of all the great community work you have already invested, and because this is a feature that I believe most people deem beneficial. There's a danger it could get bogged down in "no consensus", which would be a saddening demonstration that participatory decision-making doesn't scale, and that enwiki is something like Conway's Game of Life where interactions are localised to small scale but cause surprising ripples.
As to choice of channel, I almost wrote earlier something like "hey, why not go all out and run a mw:CentralNotice banner, rather than just a watchlist banner or a WP:Centralized discussion listing?" Not knowing that you had been through that before.
Personally, I'd be wouldn't mind if you turned it on tonight. Maybe there's nothing more you can do to influence the amount of pushback. As you say, how much is enough? ⁓ Pelagic ( messages ) 14:17, 7 February 2022 (UTC)
I'm sure that the product manager would be willing to wait for an RFC, but the number of times volunteer-me has had conversations along the lines of "There should've been an RFC! – There was an RFC last month; here's a link to it – But there should've been an RFC!" leaves me doubtful that even that would work.
For clarity, I really do want as little surprise as possible. I am just not certain that we can materially shift the needle on that with any non-disruptive means. Whatamidoing (WMF) (talk) 16:48, 7 February 2022 (UTC)
I think that makes a lot of sense. I agree that having a up-or-down vote on the matter is probably not productive. Maybe we should give it a week with a T:CENT banner plus a watchlist notice? Enterprisey (talk!) 22:22, 7 February 2022 (UTC)
I understand there are those who are suspicious of change, and can find it hard to adapt. Nonetheless, the visual change being proposed is a brief string of text added to the end of comments. Editors remain free to add comments the same way they always have and ignore the new link. I think it's overkill for there to be a large-scale RfC on the matter, absent any indication that there is in fact a significant proportion of editors who object. As an example: once upon a time, the section edit link was right justified. A number of editors raised complaints when it was changed. I could be wrong, but I don't get the sense that it continues to be a simmering irritant to this day. isaacl (talk) 22:40, 7 February 2022 (UTC)
Help:Talk pages has had a new section on the Reply tool inserted (see here) (Please don't alter the section heading until rollout has finished, as other pages are now being linked to it).
Hi everyone, I really don't want to see a foundation (or developers) vs community fight here on what seems to be a small feature.
This discussion has kind of gone sideways - let's get back on track. The way I see it there are only two good options:
(HARD BLOCK) This new software deployment should be blocked on community consensus; we hold a normal RFC to get there. (Let's not pretend only the "deployment date" is under discussion - as "never" could be the result). Noting that such an RFC could spin in to debates about opt-out vs opt-in, new editors vs existing editors, default option, ip editor option; carefully setting up the RFC may help guide it.
(Gamma Test period) This is an advisory announcement only. A target date with some lead time is advertised. Anyone with concerns is invited (by way of notices) to test the feature (which AFAIK is not 'easy' to test in isolation?) - however deployment will be delayed if there are open bugs (not feature requests) in phab (link to what parent task should be used).
If the external-to-the-communty groups are willing to push forward (as almost all other software improvements are processed), then I suggest #2 is the way to go. My only concern with #2 is that it seems "tricky" to get people to test this, because the directions are to use a beta option which enables an entire suite of tools, not just this one.(Let me know if I'm missing something?) Directions for how to see the results of the change can be provided.
@Xaosflux: You can enable each beta feature individually. Yes you will still be enabling all discussion tools, however I don't see that as being a big of an issue. ― Blaze WolfTalkBlaze Wolf#654515:58, 9 February 2022 (UTC)
Just so you know, I myself would prefer #2. #1 makes it seems like this entire process of notifying people ahead of time was a complete waste if the software deployment were to be blocked by the community with the option for it to never be deployed. ― Blaze WolfTalkBlaze Wolf#654518:36, 9 February 2022 (UTC)
Personally, I think #2 is OK in this use case, but having been around to see mediaviewer, visualeditor, and flow deployment problems respect that the community could be wary. — xaosfluxTalk19:03, 9 February 2022 (UTC)
I've updated the deployment ticket (T296645) with this new deployment date.
If/when you notice people reporting a significant issue with the Reply Tool, please ping me and I can add the issue as a sub-task of T296645. You're also welcome to boldly add any issues you believe would warrant the deployment being blocked. Although, I think it's important that the Editing Team review any issues of this kind.
Thanks for starting this. I'm for #2; as I said, I can't really imagine what could be controversial about this (that's jinxing it, heh) besides the possibility of interference elsewhere on the page, but since we have hard numbers for that I'm sure it'll be fine. Enterprisey (talk!) 22:20, 9 February 2022 (UTC)
(edit conflict) I'm for #2 as well. I think it's all about not surprising too many people, rather than seeking their permission for a rollout of an effective new tool. Either way, I'm still unclear if a Centralised Notice or Watchlist Notice is a) in the pipeline b) impossible to do c) deemed inappropriate/unnecessary. Personally, I'd prefer to read a banner that affects me, rather than all that fund-raising stuff. Even a non-editing IP visitor seeing such a banner notice would come away with a positive impression that they could participate in discussions should they ever wish to. What's not to like?...and a final thought, how about preparing a Reply Tool Rollout Information page? Aim it directly at en-wiki editors, and summarise all information together in one place. Here's a mock-up of its bare bones if folk think it's worth running with the idea. Nick Moyes (talk) 23:50, 9 February 2022 (UTC)
xaosflux I wasn't sure either. I only thought that if people were concerned about minimising community concerns or kickback, then it could be a sensible 'political' move to directly cater for them with a dedicated page or sub-page just for the rollout issue. I'm not trying to make work; it all depends on what level of concern you and others think there could be. Nick Moyes (talk) 00:17, 10 February 2022 (UTC)
Such a big/important change really does deserve a dedicated page. I think it would make sense to start by simply splitting the Reply tool section out of the Talk pages project page and then possibly extend it to cover any further issues related to the deployment. That would also help to segregate any future talk page feedback from the talk page feedback for the other parts of the overall project — GhostInTheMachinetalk to me12:19, 10 February 2022 (UTC)
Based on the experience of other wikis, I'm not sure this will feel like a big change, especially after the first two weeks.
I think it's an important change, for those who want to use it, but I think it's also a minor change for those uninterested in it, as it can easily be ignored. I think from a help documentation perspective, having the two ways of replying consolidated under Help:Talk pages § Replying to an existing thread is reasonable. isaacl (talk) 22:52, 10 February 2022 (UTC)
Enough community support here should be fine to plow forward with #2 as well. Maybe we pick a date, like March 7th and go with it. @Enterprisey: seems like phab:T296645 is the main ticket, so any possibly discovered bugs can reference it and block it. I'm going to block it with a community-consensus requirement right now, but that doesn't mean we need a "support RFC" - just that this section needs to get a direction. — xaosfluxTalk23:38, 9 February 2022 (UTC)
Basically, option 2 is a final Gamma Test period - with the pass criteria being "no unresolved blocking bugs" (so the assumption is that this is ready to go and is bug free - for example if no one actually tests or reports new issues). — xaosfluxTalk23:43, 9 February 2022 (UTC)
Number 2 seems like the best option out of the two. This change, although not minor, can be opted out of. Plus I see this change as only benefiting those who want to use the tool. I've been using this tool for a while, and it has saved me a fair amount of time. Dreamy Jazztalk to me | my contributions20:53, 10 February 2022 (UTC)
Hey PPelberg (WMF), hope all is well. Looks like we have at least a local consensus in favor of #2. Is there anything further you need from us? Does the Gamma Test option work for your team? Let us know if there's anything we can do to help you with the rollout or logistics. Best, KevinL (aka L235·t·c) 18:00, 20 February 2022 (UTC)
Looks like we have at least a local consensus in favor of #2... Does the Gamma Test option work for your team?
Wonderful. And yes, the "Gamma Test" option works well for the Editing Team. We are planning for the desktop Reply Tool opt-out deployment to happen on 7 March 2022, provided no issues we collectively see as "blocking" remain unresolved at that point in time. See phab:T296645#7699690.
Is there anything further you need from us?
The work y'all are doing to file tasks for issues people are raising (e.g. T302257, T268558, T302296)[i] and post announcements to ensure people are aware of and expecting this change (e.g. Watchlist message) is a big help and we are grateful for y'all leading this. I think continuing to do those two things will go long a way.
On our end, the Editing Team will be gathering later this week to review the issues volunteers at en.wiki have filed about the Reply Tool. We will use this meeting to identify which, if any, issues we see as needing to be addressed before the planned 7 March deployment. I will post the outcomes of this meeting before this week is over so that y'all can review it and if necessary, we can talk about it.
Please let me know if anything above prompts new thoughts/question.
Of the issues we reviewed, we did *not* identify any issues thus far that we thought ought to block the mw:Reply Tool deployment scheduled for 7 March 2022.
We would value any and all people here reading over the review we conducted and commenting here if you:
Think there are issues we did not consider and/or
Think there are issues that ought to be considered blockers that we determined not to be
@Isaacl I wouldn't call that blocking - since it is a garbage in garbage out problem, correct? High level summary: If someone creates a malformed page with unmatched tags, some of the page will not display right in this situation? — xaosfluxTalk12:16, 26 February 2022 (UTC)
As per request, I raised an issue that I think should have been considered and didn't appear on the list. I'm not convinced it should be a blocker, and perhaps its resolution timeframe makes it moot, which is why I asked about it. But it does introduce a change to existing behaviour, and hides the cause of an error which can make (to the outside viewer, a seemingly random amount of) text on the page disappear. I think it should be discussed. isaacl (talk) 16:36, 26 February 2022 (UTC)
@isaacl The fix for T301845 is actually already deployed to Wikipedia, since last Thursday! (For future reference, you can deduce this by looking for the orange tags with the version number like "1.38.0-wmf.23" on Phabricator, and comparing that to the version shown on Special:Version.) Matma Rextalk23:03, 26 February 2022 (UTC)
A non-blocking issue I reported elsewhere, but never got a response to is the annoyance of the Preview shortcut (Alt-Shift-P) being used out of habit (as one does all the time in Source Editor.) I don’t need it to actually work, but I am constantly frustrated by it taking me out of the reply window and opening the print window at the top of the page. So, finding one’s way back down on a long talk page to some point in the middle where the reply window is located is a frequent annoyance for me. Just deactivating this key combination would be welcome. Nick Moyes (talk) 10:03, 26 February 2022 (UTC)
Down for whatever gets this deployed to everyone the fastest. WMF has done excellent work on this tool, and I'm excited to see how it improves talk page dynamics. ProcrastinatingReader (talk) 17:00, 27 February 2022 (UTC)
Bugs
It is already implemented on the Dutch wiki for a while: nl:Overleg:Bijlmerramp (without asking me and without having it enabled in the preferences).
One bug I found in the editor was:
If I edit something and after that I copy something by a middle mouse click (on linux), it is pasted top left at the start of the edit. It does not happen with CTR-V. A more disturbing bug is that when I reply to an earlier post in a thread, the reply is inserted after the last edit in the thread. --Wickey (talk) 11:54, 11 February 2022 (UTC)
@Wickey: regarding the later, that sounds serious, but I haven't been able to replicate it yet. Could you set up a simple sandbox page (e.g. at User:Wickey/replytool) and document that steps that you are doing, what results you got, and what results you expected? — xaosfluxTalk20:56, 12 February 2022 (UTC)
Don't know how to do this and if there is a difference between en- en nl-wiki, but I replied to a comment early in a series of comments here and here. My reply appeared as a reply to the last one (or at least one lower in the thread) instead where I replied. I may be mistaken, may be it happens in the preview, but it happened already before. --Wickey (talk) 10:57, 13 February 2022 (UTC)
In light of not learning of any blocking issues, the Editing Team is taking this to mean we ought to move forward with deploying the Reply Tool as an opt-out feature this upcoming Monday, 7 March.
There is, according to the note at the top of my watchlist, a way to turn it off in our preferences tool. Not at all helpful help. Where in preferences is a better way to help? Anybody? My preferences are cobwebby obfuscatory dungeons designed to confuse a pensioner, and the "TURNITOFF" tool is hidden. Thanks. -Roxy the grumpy dog.wooF20:55, 7 March 2022 (UTC)
Is traffic that heavy on this page? I've tried 12 times, to correct my previous comment to say that I did it & it worked. Wowsers, 12 Edit conflicts in a row. GoodDay (talk) 21:13, 7 March 2022 (UTC)
That's correct: The Reply tool automagically and silently resolves nearly all edit conflicts, but it doesn't currently allow you to edit existing comments. (That idea is in phab:T245225, and I don't know whether it will get implemented any time soon.) If you want to edit your existing comments, then the similar volunteer-created user script Convenient Discussions has that ability. Whatamidoing (WMF) (talk) 21:57, 7 March 2022 (UTC)
The announcement at the top of the watchlist says the reply tool is now deployed for those editors who have not opted out. But I don't see any difference when I reply. How can I tell if the reply tool is in effect for me? Jc3s5h (talk) 22:13, 7 March 2022 (UTC)
You know an old Jewish joke: "If you feel uneasy at your home, just buy a goat, and then get rid of it". It surely applies to me, with my Opera Presto 12.18 (that I cannot update because of the hardware). I feel happy because I am at last allowed to get to the Preferences and change them! For a year or more, I haven't been able to do even this. So thank you, thank you, thank you that I can get rid of yet another useless deploy, instead of slowly crawling to a cemetery. (Slowly, because nobody wants my panic). — Mike Novikoff00:05, 9 March 2022 (UTC)
Date format for single digit dates in revision history
Latest comment: 2 years ago11 comments7 people in discussion
Currently date format for single digit dates is 5 March 2022 in the revision history. This format means it doesnt align well with previous or the next revisions in above and below lines, like with 22 March or 28th February. More alignment mismatch happens in case of months change too, like between February to March, and this date adds up. Visually the revision history doesn't look friendly.
I propose to change it to two digits date, as in 05 March 2022. This will fix alignments to some extent, not to full extent as the month name length are different. And user name lengths dont match, so it cant be aligned anyway. This new date format will improve alignment, and makes the revision history page more pleasing visually. This would look good in user contribution pages too. Crashed greek (talk) 04:42, 5 March 2022 (UTC)
You already said that. But forcing something on everyone that only one person wants isn't the best of proposals. Personally, I like March 6, 2022 or 3/6/2022. Amaury • 11:29, 6 March 2022 (UTC)
Date format is very much a personal preference, imposing one format on everyone is definitely not going to happen. Thryduulf (talk) 13:27, 6 March 2022 (UTC)
We are already imposing a date format on everyone, except some 1% people who create account and change preferences. Better alignment will help esp non logged in users. So the question is which is the best default settings for the imposed format. I am suggesting a very minor change to the existing imposition. Changing the order of month and date would be a much bigger change, also changing month text to number would be a much bigger change on top of that leading to confusion depending on location of the user. My proposal is a very minor change, that affects dates from 1 to 9 out of 30 days a month. Crashed greek (talk) 06:26, 7 March 2022 (UTC)
I don't think many of us want this change as the default. Perhaps you could ask for another option to be added to the preference screen. Alternatively, it should be easy to achieve in JavaScript. Certes (talk) 13:07, 7 March 2022 (UTC)
That is understandable, but I wanted to make clear that my proposal is not to change the default date format in a big way like other users suggested. Crashed greek (talk) 06:11, 9 March 2022 (UTC)
Creating an Irish language Wikipedia
Latest comment: 2 years ago5 comments5 people in discussion
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 dear Wikipedians!
I have a special proposal for Wikipedia. Is possible to create an Irish Wikipedia to have the Irish language (Éireannach) for Ireland. As for now is a Wikipedia which is confused with Irish language, the Galego Wikipedia: https://gl.m.wikipedia.org/wiki/ which in fact Galego language is the official language of Galicia, an autonomous community of Spain
You may also be interested in this list of Wikipedias. As you can see there are over 300 languages that have Wikipedias, which hopefully include all of those that are an official language in any country. For future reference meta (as linked there) is the place for such proposals. We have no jurisdiction here over anything outside the English-language Wikipedia. Phil Bridger (talk) 14:14, 9 March 2022 (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.
How to submit a draft for review on Hebrew Wikipedia
Latest comment: 2 years ago3 comments3 people in discussion
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 Wikipedia users and admins!
I have requested an article on Hebrew Wikipedia and I have edited it enough in order to move to articles list but I don't know what code to enter on the draft edit page to submit it for a review. Please can you provide me the code here?
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.
Autoconfirmed and reverted edits
Latest comment: 2 years ago7 comments5 people in discussion
Now that we have a reverted tag, would it be desirable and feasible to discount reverted edits when granting autoconfirmed status? A new editor has been making unhelpful subtle changes, such as removing random letters, and replied to a warning with I just wanted to get to ten edits really fast. Others may be less candid. Edits can be reverted wrongly, but if a new editor is consistently reverted then we may not want them creating pages yet. Certes (talk) 12:53, 12 March 2022 (UTC)
The following scenario would be an issue:
A user does 10 edits and has 4 days since account creation.
The user does an action restricted to autoconfirmed users
The editor would remain autoconfirmed in that case: withdrawing the privilege retrospectively would overcomplicate things. It won't cover all cases, but would catch anyone who makes ten bad edits soon enough to be reverted within four days of registering. Certes (talk) 19:01, 12 March 2022 (UTC)
I'm fairly sure that autoconfirmed isn't a "group" that's stored in the database like other user groups. Each time you click "edit" on a semi-protected page, the software checks your total edit count and tenure, and if it's enough, you're allowed to edit. (Note that extendedconfirmed and confirmed work differently.) So in the 93.172.238.76's scenario, the user would lose the ability to edit semi-protected pages, unless they've made a total of 10 non-reverted edits. But a here's a more concerning scenario:
Alice makes 9 edits
Bob reverts all 9 edits for the lulz
Carol quickly notices, and reverts all of Bob's edits.
@Certes from a technical perspective, this isn't feasible. "Autoconfirmed" is primarily supposed to be a check against vandalism bots, forcing editors without it to have to answer CAPTCHA's when adding links and preventing less accountable editing of minorly protected pages. We can't really change "what" is counted, however we can adjust the number of edits and/or days required. — xaosfluxTalk19:27, 12 March 2022 (UTC)
Thanks. I realise that this would require a software change, but perhaps doing an actual filtered count rather than just checking a running total is a step too far. We've debated the numbers of edits and days here before, and I agree with the consensus that 10/4 is reasonable. Certes (talk) 19:30, 12 March 2022 (UTC)
I think the edit count of 10 to become autoconfirmed is (rightly) so low as to be worth ignoring. The people we should be more concerned with are those serious POV pushers who game the system to become extended confirmed. Phil Bridger (talk) 19:49, 12 March 2022 (UTC)
, but I fail to see why or how portals justify a place on the main page, even less one at its head. Gog the Mild (talk) 19:20, 16 February 2022 (UTC)
21:53, 16 February 2022 (UTC)
Done --Ahecht (TALK
Administrator note we could use the abusefilter to block or warn on these edits as they seem to have a consistent edit summary we could latch on to; we could also exempt certain usergroups (e.g. extendedconfirmed) or users with an editcount above something from such a filter. While possible, I expect there will be significant pushback about making a new local mediawiki usergroup just for this. If set to "warn" every use would require a reconfirmation after getting the "warning" which can say whatever we want. (Please note one of the sample "bad" edits is by a user with 3000000+ edits that is also a member of restricted groups including autopatrolled). We can not easily make an on-wiki discretionary access control list, as we do not control this software - it is hosted off-site. Traditional administrative options are also available - such as placing editing blocks on users that are making disruptive edits. — xaosflux Talk 22:55, 21 January 2022 (UTC)
Request withdrawn I see your points. Also, this isn't going to benefit me any longer, as my edit count has boomed since I wrote this. InterstateFive (talk) - just another roadgeek 00:30, 26 February 2022 (UTC)
Support ― Qwerfjkltalk 21:46, 17 February 2022 (UTC)
Comment: This IP range (bn:Special:Contributions/103.230.104.0/22) is blocked in Bengali Wikipedia due to long term abuse (personal attack + sock of User:Lazy-restless). —Yahya (talk • contribs.) 21:42, 2 March 2022 (UTC)
