# Wikipedia:Village pump (proposals)

Jump to navigation Jump to search
 Policy Technical Proposals Idea lab WMF Miscellaneous
 .mw-parser-output .module-shortcutboxplain{float:right;border:1px solid #aaa;background:#fff;margin:0 0 0 1em;padding:0.3em 0.6em 0.2em 0.6em;text-align:center;font-size:85%;font-weight:bold}.mw-parser-output .module-shortcutlist{display:inline-block;border-bottom:1px solid #aaa;margin-bottom:0.2em;font-weight:normal}.mw-parser-output .module-shortcutanchordiv{position:relative;top:-3em}.mw-parser-output li .module-shortcutanchordiv{float:right} New proposals are discussed here. Before submitting: Check to see whether your proposal is already described at Perennial proposals. You may also wish to search the FAQ. Consider developing your proposal at Village pump (idea lab). Proposed policy changes belong at Village pump (policy). Proposed WikiProjects or task forces may be submitted at Wikipedia:WikiProject Council/Proposals. Proposed new wikis belong at meta:Proposals for new projects. Proposed new articles belong at Wikipedia:Requested articles. Discussions or proposals which warrant the attention or involvement of the Wikimedia Foundation belong at Wikipedia:Village pump (WMF). Software changes which have consensus should be filed at Phabricator. « Archives, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167

## Proposal: New Village Pump Page

There is clear consensus for a communication page with WMF to be created along the lines suggested by Alsee. I hope that the WMF will understand the thinking behind the page, and engage with it. Attempts I made last year to get WMF to engage with the idea that communication between en.wiki and WMF should happen here on en.wiki not in room 13 down in the basement of WMF's outpost in Timbuktu met with an enthusiastic response of how they are thinking of putting a light bulb in room 13 in order to assist the folks in en.wiki to read the notices they post there. If this proposal gets off the ground, and WMF does engage with it, and it's still going in 12 months time I will send Alsee a bottle of their favourite drink. SilkTork (talk) 14:28, 8 April 2020 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

There has been a long recognized need for improved communication and coordination between the community and the Wikimedia Foundation. Too often Foundation plans have come as an unexpected and unwelcome surprise to the community. Too often community concerns or objections have come as an unexpected surprise to staff members. Better communication and collaboration would reduce the rate of conflict and failed projects. Staff members are generally enthusiastic about our public service mission, have good intentions, and want to help us. However to be frank, most of them know about as much about what goes on over here as most of us know about what goes on inside the Foundation. They are employees in a conventional top-down authority structure. Most of them have no experience in the community, and our consensus system is alien concept. Sometimes they struggle to understand how we work, what we want, what we need, and even how to talk with us effectively. There is a communication and culture gap.

I have seen positive efforts from the Foundation over the last few years. However I believe both sides need to work to bridge the communication gap. I have some ideas, and it begins with this proposal to create a new village pump page. The current Draft Village Pump Page header reads as follows:

The WMF section of the village pump is a community managed page. Editors or Foundation staff may post and discuss any information, proposals, feedback requests, or any other issues of significance to both the community and the Wikimedia Foundation. It is intended to aid communication, understanding, and coordination between the community and the Foundation.


There is currently a Pump Proposal open above, asking WMF Legal to enforce the Terms of Use against an abusive company. That is a prime example of kind of topics I envision for the new page. The Central Notice template also currently lists an RFC for the Foundation's rebranding strategy to rename itself from Wikimedia to Wikipedia. As part of that project they evaluated the level of community support and produced a report, which I believe has been delivered to the Board of Trustees. The report states Measure community appetite for change: ✓ 0.6% of informed oppose. The 0.6% oppose figure is in rather stark contrast to the over 92% oppose on the RFC. I have several other examples of confirmation bias in Foundation's gathering or handling of data. I believe bad data has contributed to some of the tensions between the Foundation and Community. The RFC page also has a Statement by the Foundation. Given how the RFC is going, I believe it is clear that the staff handling the project do not grasp the significance of the RFC.

I have long been following Foundation projects, plans, and strategy. I have a small pile of similarly significant topics for the new page, including matters of past and future Foundation strategy. As some of you may be aware the Foundation has finally given up on the Flow project, and a Consultation resulted in a decision to keep and enhance existing Talk pages. I am concerned that the enhancement project is going off course. For example, like Flow, the project has a design flaw that can result in wikitext content corruption. The manager has indicated that he considers it an insignificant matter, not worth fixing. One of my priorities for the new Pump page will be to provide more detailed information on the new Talk Page Project. I hope to bring that team helpful information on our needs, concerns, and expectations for any major changes to Talk pages.

Over the years I have had discussions with several top managers, with the previous Executive Director, and with the current Executive Director. I believe the Executive Director would be receptive if we produce some consensus message regarding Foundation strategy and engagement. That is beyond the scope of the immediate proposal.

Proposed: Install Draft Village Pump Page. The page may of course evolve based on comments here or later. Alsee (talk) 12:04, 29 January 2020 (UTC)

### Responses (NEW VP)

• Support as proposer, per the rationale above. Alsee (talk) 12:04, 29 January 2020 (UTC)
• Support Additional communication is a good thing! This makes hella sense! GenQuest "Talk to Me" 12:53, 29 January 2020 (UTC)
• So another village pump page that most people won't watch? Much less WMF? Nah. --Izno (talk) 15:08, 29 January 2020 (UTC)
Izno... Can you come up with a better suggestion? We do need SOME way to facilitate more communication with the WMF. Blueboar (talk) 15:20, 29 January 2020 (UTC)
• Comment Previous discussion: Wikipedia:Village pump (proposals)/Archive 130#New Village Pump page?. Anomie 15:23, 29 January 2020 (UTC)
• Support concept, but in practice, this will need buy-in from the WMF - if they don't use it, then there's no point. creffpublic a creffett franchise (talk to the boss) 15:32, 29 January 2020 (UTC)
• In my opinion, such a thing is better placed on the Meta wiki; that's where the WMF does most of its work and it would make this venue usable for non-enwiki projects as well. Jo-Jo Eumerus (talk) 15:47, 29 January 2020 (UTC)
• Support as beneficial, even a less active Village PUmp page would be seen more then the current set-up which is basically "meta pages only seen by a couple of keen souls. They panic and dump on CENT after a significant delay". The only other action that could provide a substantial assistance would be something akin to Tech News "WMF Newsletter". The issues with this are threefold: you'd need about 200 sign-ups to get reasonable awareness; you'd need several active people to run it reliably; some major WMF discussion areas would need much quicker response times than (a max) 30 days to give a chance for proper discussion. Nosebagbear (talk) 15:53, 29 January 2020 (UTC)
Summoning ... — xaosflux Talk 16:13, 29 January 2020 (UTC)
User:Nosebagbear, rather than creating Yet Another Newsletter that nobody reads, the English Wikipedia would probably find it easier to promote the WP:Wikipedia Signpost, which already has the subscribers, and which could be a reliable source of information that mattered to this particular community. Whatamidoing (WMF) (talk) 23:45, 30 January 2020 (UTC)
• Support concept per Creffpublic's similar comment above, but Jo-Jo Eumerus has a good point too. Ivanvector (Talk/Edits) 16:57, 29 January 2020 (UTC)
• Strong support Regarding Jo-Jo Emerus's comment; Meta is where the WMF does most of its work, but the problem with discussions on Meta is that members of the individual communities rarely go there and can easily miss important discussions. Having a page here to discuss things with the WMF makes it easier on the community. Such a page can house links to important discussions that are taking place on Meta, thereby driving traffic there. ~ ONUnicorn(Talk|Contribs)problem solving 17:05, 29 January 2020 (UTC)
• ONUnicorn, have you heard about User:DannyS712's work on a global watchlist? Flow/Structured Discussions, which is widely used at MediaWiki.org, will ping people with every new discussion thread on a watched page. That's great for cross-wiki notifications, but at Meta, your options are either changing your prefs to email you for every change to your Meta watchlist, or hoping that we get a global watchlist. Whatamidoing (WMF) (talk) 23:48, 30 January 2020 (UTC)
I'm glad you find it useful. Useful enough to support the grant request / incorporate it as an extension? See m:Grants:Project/Create a global watchlist extension DannyS712 (talk) 23:58, 30 January 2020 (UTC)
• Yes, I'm aware of the global watchlist project. I also have no idea why it's relevant to this discussion. ~ ONUnicorn(Talk|Contribs)problem solving 01:13, 31 January 2020 (UTC)
• Being able to see, while you're still "here", that a discussion page has changed "there", seems like a way to improve the problem you identified, that "members of the individual communities rarely go there and can easily miss important discussions". Whatamidoing (WMF) (talk) 20:10, 31 January 2020 (UTC)
• Yes, but in order to add a discussion "there" to your global watchlist, you need to first be aware that it exists "there". ~ ONUnicorn(Talk|Contribs)problem solving 20:42, 31 January 2020 (UTC)
• I agree with you that it's not a complete solution, but it could improve the situation, especially if you put Meta's central announcement pages, such as m:Template:Main Page/WM News, on your watchlist. Whatamidoing (WMF) (talk) 21:50, 31 January 2020 (UTC)
• Support Having a dedicated page for communication with the WMF seems like a no-lose proposition. I think it needs to be two-way; people should be able to post questions for, and expect answers from, Foundation personnel, and the Foundation should also be expected to make announcements for the community, using the page. I can't think of a downside to this proposal. --Jayron32 17:08, 29 January 2020 (UTC)
• Support A direct way to see WMF related proposals, and for clear, one on one communication with them? Yes please! This would, hopefully, greatly help with places where the WMF clearly didn't get proper consensus, and would allow for us to bring proposals their way in a place everyone would see. --moonythedwarf (Braden N.) 17:24, 29 January 2020 (UTC)
• Support in principle per Creffett. I would love to see this happen. Our best chances for greater two-way communication with the Foundation may be by raising it as an issue in the Board of Trustees election. EllenCT (talk) 19:13, 29 January 2020 (UTC)
• Support - Having a centralized enwiki discussion forum for interacting with WMF would be beneficial. I hope that WMF agrees. - MrX 🖋 13:06, 30 January 2020 (UTC)
• Oppose. On issues for which the WMF is completely non-responsive, I don't think having a dedicated board would make them willing to respond. On issues where they are willing to respond, they're frequently willing to participate anywhere, unless it's a cross-project issue, in which case they'll sometimes only interact on Meta. The WMF has given no indication that they'd be more willing to use a dedicated forum. The task of dragging the WMF into areas where we can have some level of mutual awareness is going to take a long time. The WMF has the ability to communicate things well, they even use a wiki internally to host things like every team's weekly report (which they won't let us see, or comment on), but as far as I can tell, they just don't want to allow that much WMF-community interaction, for reasons unknown to me. --Yair rand (talk) 01:08, 31 January 2020 (UTC) seems fine, but
• Oppose, I wonder, why the enWP, who already is the center of the anglocentric WMF, is complaining, just go to Meta, unfortunately for the non-anglophone projects they seem to speak only english over there. This sounds to me more like a venue, whre the WMF can pretend to talk with the community, while they are talking just to a tiny peace of the community, bur one that conveniently speaks the only language they seem to know. Grüße vom Sänger ♫ (talk) 05:19, 31 January 2020 (UTC)
• Support concept but different name and framing WMF communications happen in a decentralized way and there are regular disagreements about what WMF representatives communicated effectively and what was hidden in some out-of-the way area. I support the idea of centralized posting but think it should be either outside the village pump, or if listed with the village pump boards, then it should have a different name and branding. WMF communications are different because everything that organization does is entangled with money and someone's career, and consequently much of that organization's activity here is in a conflict of interest with some individual or team's financial livelihood. The interests of the Wikimedia Movement and the Wikimedia Foundation often diverge, and staff of the Wikimedia Foundation are not part of the Wikimedia community in that they each have a commitment to serve the interests of the Wikimedia Foundation as an organization and favor that organization in the case of any conflict between the Wikimedia Community and that organization. The reason why the village pump is not the place for WMF discussion is that the village pump is established as a community volunteer space. Instead, I think the right board for the WMF would be something like a Wikipedia:Local Embassy, where the WMF sends its diplomats and negotiators into English Wikipedia space to negotiate something. Maybe the WMF should set up embassies wherever it would log its efforts to establish agreements with a local Wikimedia community. The idea of a central space is great. We should distinguish ideas and proposals from the WMF from ideas and proposals from Wikimedia community volunteers, though. Blue Rasberry (talk) 19:57, 31 January 2020 (UTC)
• Support concept. I am a little concerned that not all the messages that would be posted to such a board would actually be matters that require the attention of the WMF. There should be norms established that if inappropriate content is added, it can be moved to a different pump page. Sdkb (talk) 21:29, 2 February 2020 (UTC)
• Support the concept... but I ain't holding my breath on this being useful if the WMF decides to have a rerun of the Fram and Flow Show.A little blue Bori v^_^v Onward to 2020 23:43, 3 February 2020 (UTC)
• Dont mind, but don't think it will approve communication of either the foundation or the community one bit. The problem is not the amount of locations to discuss, its that there are too many stakeholders with too many different opinions and too many thing happening to keep track of no matter what you do. —TheDJ (talkcontribs) 09:18, 6 February 2020 (UTC)
• Support Concept per above, especially Creffet and EllenCT. Puddleglum 2.0 20:29, 7 February 2020 (UTC)
• Support this idea for now. Anything to open constructive communications seems fine. I would like to suggest we review the actual results later. a channel to discuss things with WMF seems fine, but we should also hjave the option to look at other methods later, if this new idea doesn't have the full effect desired. --Sm8900 (talk) 04:28, 10 February 2020 (UTC)
• Support the concept of constructive communications with "norms established": I am one of those that very rarely "go there" (Meta), and think comments to "just go to Meta" are out of touch, as I imagine many also don't "go there". I think there would be community benefits in this proposal and help others not "easily miss important discussions". We "advertise" to get involvement so why not have a local centralized place? Will the WMF get involved or "buy-in"? I don't know, but I will continually assume good faith that others will do the same. If true, the comments "WMF is completely non-responsive" might be a reason that a collaborative effort (and a fairly large show of support), will hopefully gain more involvement ("WMF-community interaction"), and "might" be a game changer, or not. We will never solve issues or find solutions by just complaining and not trying. I do not know anything about "anglocentric" concerns (Is this a real problem and how is it really relevant here?) the WMF "might" be complaining about. I assume enWiki is among the more active projects. I cannot help where I was born (demography of the editors), but this is where I am, and I imagine that is true for the many on this project. The WMF has to understand that it is not the fault of any considered anglocentric that broad community involvement somehow created some sort of bias. I want to see worldwide involvement but I only speak English so my endeavors, that consume most of my free volunteer time, would very logically be focused here, so I "favor this organization" for obvious reasons. The WMF and the other projects need to worry about their end. On this "end" I would like to see better communication (dedicated forum?) and support anything in that direction. Maybe a new tab here, or another supported location, but I don't see that Wikipedia:Local Embassy ("Wikipedia-related multilingual coordination") would be proper. If the WMF is picky about what involvement they wish to be involved in, then at the least, we can have a central location for discussions and potentially important news, as well as hopefully collaborative communication. Any thoughts that we possibly somehow shouldn't continually make attempts doesn't seem logical. Otr500 (talk) 17:41, 11 February 2020 (UTC)

### Discussion (NEW VP)

Jayron32, you used the phrases 'expecting answers' and 'expecting announcements' from the Foundation. I want to emphasize that this is a community page, and creating a community page does not create any particular obligation on the Foundation. An appearance of imposing an obligation or responsibility onto the Foundation could raise objections and resistance. The new page is a workplace for us, and I wish us to extend an open invitation to the Foundation utilize the page. I hope and believe they will accept that invitation (likely with hesitation and fear, as conflicts have been painful for both sides). The only expectation on the Foundation is that they continue their existing efforts, and I have hope that we can help work towards improvement. Alsee (talk) 22:05, 29 January 2020 (UTC)

See, I still feel that is backwards. Wikipedia and the en.wikipedia community does not exist for the purpose of supporting the whims of the Foundation. The Foundation exists to support the work of the volunteers and the various communities of the Wikipedia movement, and increasing and improving communication between the Foundation and the communities it serves is what we should be focusing on. We should not be focused on being better foot soldiers blindly following whatever mission the Foundation has decided to set us upon, we should be expecting and receiving support from the Foundation for the purpose of building an encyclopedia. Where conflicts have been painful have been where the Foundation has acted unilaterally and in its own interest without regard for the interests of the Community. The expectation is, the Foundation should seek input and advice from the community on major issues, and that the Foundation should be willing to respond to legitimate concerns from the community. If they are not willing to do either of those things, the noticeboard is pointless. --Jayron32 12:40, 30 January 2020 (UTC)

I will pass along a link to this discussion, but I think I can predict some of the questions I'll get, so perhaps some of you would like to start answering them now, just in case:

1. Why do we need a single, separate page? Why not have all of us talk on whichever pages are relevant? At least some of you have figured out how to ping me ;-) and if that's too hard, we could always create a generic {{ping the WMF}} template. Having a discussion half at one page and half at a "Village pump (WMF)" sounds like a WP:CENT problem. On the other side, imagine that the WMF is offering hackathon scholarships to bot operators. Why should that be announced at a special "WMF" page instead of at WP:BOTN? Have you thought about the signal-to-noise problems in the movement? The main problem isn't a lack of information. It's finding the thing you care about in the middle of all the things you don't care about.
2. What's the specific purpose? Specifically, is it primarily one-way information from editors to the WMF, primarily one-way information from the WMF to (some) editors, primarily discussions to exchange views without trying to make decisions, or is it primarily a location for decision-making? I see comments above that seem to believe each of those four. Forums that try to do all of the above usually fail at achieving most of them.
3. Why shouldn't this online community join all the other online communities in central locations (such as Meta)?
• The Working Group volunteers for the 2030 Strategy discussions say that we should be integrating the movement across all the online and offline communities. This proposal is for more separation, elevating the status of one online community and one movement organization.
• To give a concrete example, I see elsewhere on this page that the OP still thinks that the WMF is planning to cram the visual editor down our collective throats. Why shouldn't we be talking about which editing options to offer in a central place, so that people like User:Sänger, who has been asking the Editing team to enable the visual editor on talk pages for years now, can join the conversation and share his insights? (Sorry, Sänger, they're still saying no.)
4. Do you really understand that it's not just the WMF that you need to deal with?
• The Strategy folks are advocating for a smaller role for the WMF and decentralized action. This proposal seems to be focused on a single organization, when editors at the English Wikipedia need to be talking to many.
• For example, WMDE is finishing up a project that will change the <ref name="Alice"> syntax to do something similar to the {{sfn}} templates. I'm not taking bets on how long it will take for someone to complain that "the WMF" did this "unwanted" work (which was democratically selected through a public, on-wiki voting process), but I do want to point out that if you're setting up a page for just the WMF, you are excluding all of the (multiple) organizations whose activities affect us here.
• To give another example, see http://discuss-space.wmflabs.org/c/events/13 for a list of 300+ events that have been announced in the last few months. Many of these are editing events, which have a direct effect on New Page Patrollers and other editors. Very few of those announcements are from the WMF. This trend is going to continue: more events, and more articles about people, places, and things that the average English Wikipedian has never heard of. You might want to hear about them, and a WMF-focused page won't tell you about any of them, because the WMF isn't running those events.

There will probably be other questions, but perhaps these would be a good starting place. In terms of a response, I predict that the WMF's managers first thought will likely be that they're hiring someone to create something called a "strategic communications plan", so nobody should make any final decisions today. (My own personal thoughts sound a lot like http://xkcd.com/927/ – namely that it would be convenient for me if a single forum could replace all the others, and if people would actually pay attention to it [even though most of it would be irrelevant to them], but I do not expect that to happen.) Whatamidoing (WMF) (talk) 23:41, 30 January 2020 (UTC)

Whatamidoing (WMF) You mentioned above the global watchlist work; and here you list several items that can be summarized as, "people should use Meta". One thing I'm thinking this would be useful for is as a repository for links to important discussions happening on Meta. Because if there is a discussion happening on Meta, but people who would be interested aren't aware of it, they aren't going to participate. A global watchlist to remind you to check up on developments with discussions you are interested in on Meta is only useful in as much as you are aware of the discussion and have added it to your watchlist. People on en wiki are constantly surprised when action gets taken as a result of a discussion happening on Meta that affects 100% of the en wiki editing community, but less than 1% of the community was even aware the discussion was occurring. The end result is that the WMF looks like the Vogons in Hitchiker's Guide to the Galaxy.

“There’s no point in acting surprised about it. All the planning charts and demolition orders have been on display at your local planning department in Alpha Centauri for 50 of your Earth years, so you’ve had plenty of time to lodge any formal complaint and it’s far too late to start making a fuss about it now. … What do you mean you’ve never been to Alpha Centauri? Oh, for heaven’s sake, mankind, it’s only four light years away, you know. I’m sorry, but if you can’t be bothered to take an interest in local affairs, that’s your own lookout. Energize the demolition beams.”

My thought is that the board could be used to post announcements about discussions happening on Meta, with reminders to discuss this there. ~ ONUnicorn(Talk|Contribs)problem solving 14:57, 31 January 2020 (UTC)
ONUnicorn, a page for links to relevant discussions (more than fit in CENT) could be created by any interested person. It already happens in some other communities, and there's no reason why you couldn't do the same here if you wanted to (e.g., w:de:Wikipedia:Projektneuheiten, which is specific to technical changes, or w:fr:Wikipédia:Annonces, which is general news). Subject-specific pages might improve the perceived signal-to-noise ratio for readers. I recommend against making it WMF-specific, as this community is affected by far more organizations and individual-led projects than just the WMF. You might want to talk to the Signpost about this, as they have some experience with announcements, and they already have an audience.
It won't solve the problem that most people won't read it (or remember what they've read). I've manually posted messages to more than a hundred high-traffic pages, and run site-wide banners to 100% of logged-in editors for weeks, and still had editors say they never heard about it; I've seen a CENT-listed, month-long RFC here at VPPR, with 20+ editors supporting it and nobody opposing it, get overturned because some other editors didn't notice the RFC; I've even seen someone actively participate in a discussion on wiki, and then ask a month later why nobody ever discussed the subject. There is no way to make people read and remember everything that's relevant to them. But the fact that it won't be a total and perfect solution doesn't mean that it's not worth doing it at all. Whatamidoing (WMF) (talk) 20:45, 31 January 2020 (UTC)
Whatamidoing (WMF) I find it ironic that you come here opposing the new page and apparently blaming me regarding the WMF cramming the visual editor down our throats. It's ironic because, on exactly the issue of WMF's VE throat-cramming, you are responsible for letting us get to the brink of second Superprotect-level crisis. In case you don't recall you were liaison for the Single Edit Tab (SET) deployment. I told you that the manager explicitly assured me it would NOT be deployed as VE-default without a community consensus. I repeatedly asked you weather the the product was going to deploy with a VE-default. I presented a pattern of evidence that the product was about to deploy with a VE-default. Your responses and denials on the subject turned out be... unhelpful and untrue... that is the most generous way I can put it. Furthermore the manager on the project later asserted surprise at the issue... suggesting that either (1) you failed to ask or mention the issue with staff or (2) the manager was lying. I will not speculate between those options. In any case, the project for which you were liaison was in fact deployed with a VE-default. Exactly as I anticipated. Exactly as I repeatedly brought to you in advance. After deploying the VE-default the Foundation went non-responsive for well over a week, despite attempts to reach the Foundation in multiple places including the manager's personal talk page. We only got a response when I escalated the issue to the Executive Director's talk page! She had to summon the manager to give an answer. The manager gave us assurances that it was a bug and that he would fix it. More than a week went by with no action. We went back to the manager and he told us that VE-default was always his intention and he had absolutely no intention of fulfilling his promise to change it. At that point things went from ugly to obscene blatant bad faith. He was outright called a "liar", and ANI decided that "liar" was not uncivil given the diffs of his own words. A community member then wrote a hack for the sitewide javascript to change the default. The community members involved were acutely aware that hacking the sitewide javascript to explicitly override a manager was putting us on the threshhold of repeating the Superprotect incident. Note that the manager said it was a bug - so either the javascript hack was an undisputed bugfix or the manager was acting in deceitful bad faith. Either way the editors involved considered the javascript absolutely justified. At that point the manager finally agreed to fix the default-editor from his end, as he had promised to do a week earlier.
Whatamidoing, I respect your work and experience and expertise and dedication as a community member. However as a liaison your job was to prevent any of that from happening. I persistently attempted to ask you and warn you, attempting to head off the impeding problem. The reason I want this new Pump page is because you and other staff consistently ignore my accurate warnings that manure is about to hit the rotary air-mover. I am trying to tell you that there are a whole series of fans spinning right now. Maybe I'm overly optimistic, but I'm hoping the new page will help us sort out issues before they escalate to crisis. I hope the page will help us get moving in a common direction.
To minimize WallOfText I'll limit my reply to that one subject. Oh, and Spoiler Alert, the Foundation is about to release hard data on how badly a VE-default reduces edits. Alsee (talk) 18:36, 31 January 2020 (UTC)
Last I checked, I still hadn't been appointed queen of the wikiverse. (I'm sure it's just an oversight. ;-)) However, until that happens, I can't actually prevent everything that I'd like to prevent, any more than I can force someone to build the things that I want built (e.g., phab:T89970).
The movement might need a clearer understanding of which groups ultimately get to make which kinds of decisions, and specifically where the English Wikipedia's editors fall in a typical responsibility assignment matrix for different kinds of projects undertaken by outside communities. Are you supposed to be "informed" or "consulted" about projects that affect you, but the people responsible for the project get to make the decisions? Or do you see yourself as the ultimate "approver" or "decider", with veto power over everyone else? The volunteers in the Strategy Working Groups have proposed that a movement charter be written to clarify some of these points of contention. Perhaps having a document that explicitly says something like "An online community {can|can't} veto a project that affects that online community, but which was undertaken by another group" would forestall some of these disputes by preventing all sides of any dispute from thinking that their side has the ultimate decision-making authority. Whatamidoing (WMF) (talk) 21:24, 31 January 2020 (UTC)
But the Foundation did appoint you queen of Single Edit Tab liaising. You do an excellent job as liaison - until the Foundation agenda is questioned. At that point you tend to cease liaising. That doesn't serve the community or the Foundation. I can't decide whether it's better or worse than a liaison who lacks your community knowledge and understanding. The job should be to facilitate communication, understanding, and collaboration between the Foundation and the community. One of the most important things is to alert staff of any issues that may negatively impact their work, especially any potential or actual opposing consensus. Those staff then need your expertise and help to reach a viable resolution. Too often such situations go unacknowledged until too late. Most staff don't seem to have have the mandate or understanding to constructively engage that kind of situation. That leaves us with unconstructive approaches and bad outcomes. The Foundation and community need to work as partners.
Regarding Responsibility assignment matrix, I spent some time absorbing the page. The models generally seem to presume a context essentially internal to an organisation, generally everyone is an employee. It's a bit more complicated to apply the models here. I will try to summarize my view this way: Those models generally acknowledge approval may be needed from multiple parties to initiate a project and/or approve deployment. I acknowledge the Foundation has something approximating universal veto of every stage of anything affecting them or expending their money or labor. Wikis should get broad local decision-making on things affecting us, and I see cases where a global level consensus could apply. For example the Foundation sometimes cite the issue of a wiki unreasonably blocking some deployment - perhaps even one admin on a tinywiki. The community has the solution. It's documented in WP:CONLEVEL. If a wiki goes Nationalistic and violates NPOV and abuses admin tools, the global community can revoke the admins and reboot the wiki. If a wiki is unreasonably obstructing some deployment, global consensus can assert global deployment. Problem solved - if the Foundation engages consensus. Alsee (talk) 09:57, 1 February 2020 (UTC)
Liaison work, as any professional liaison officer could tell you, does not mean that you can always make two sides agree. It is possible to do excellent work as a liaison (i.e., as a person who carries information from one side to the other, and back again) and still end up with an intractable disagreement.
Before we could agree that things could be done by global consensus, we would have to have a consensus that consensus is the movement's method of making decisions. "The consensus of people who showed up" is mostly how we do it here at this wiki, but it is not how things happen in other communities. Some prefer straight-up majority votes or super-majority votes. There are also disagreements about what to do when there's no consensus. The Strategy volunteers favor the idea of a more integrated movement, but I think that will require us to spend time sorting out the details. For example, is it each human who gets a "vote", or each community or organization? And how do we respect devolution and local autonomy if we all get to vote on other group's affairs? (Surely we wouldn't want to say that the 99% of us who don't speak Swedish get to tell the relatively few Swedish speakers what they're supposed to be writing about.) And what do you do about intractable disagreements, e.g., that on the one hand, "the Foundation has something approximating universal veto of every stage of anything affecting them" but on the other hand, this community very much wants to have the opposite outcome, and sees itself as being the primary party affected by a WMF decision? Whatamidoing (WMF) (talk) 22:10, 3 February 2020 (UTC)

Sdkb, we'll collectively sort out how the page actually gets used. But for what it's worth, my concept for the page is "about WMF" rather than "to WMF". For example I picture anyone could post "The WMF is working on X", information which might be of interest here. That post might or might not spark a conversation. That conversation might or might not rise to a level where we want to actively talk to the WMF about it. Although I do anticipate a need for feedback-to or discussion-with the WMF for some initial topics that I want to post. Alsee (talk) 12:34, 3 February 2020 (UTC)

I support Alsee's proposal. and this new resource would be beneficial to WMF, and to Wikipedia. --Sm8900 (talk) 18:44, 9 February 2020 (UTC)

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

## Proposal to streamline the welcome template

I'm here following the AN/RFC request for closure. I note that there was another discussion about this RfC but it seems to have stalled out a couple weeks ago. Since there does seem to be a consensus here, it would be unfortunate to let it be pocket-vetoed by not being closed. Here's my closing statement:

A great majority of the participants at this RfC supported the general concept of streamlining the welcome template in this general way. Some participants had different ideas about what the buttons should look like, what the first link should be, and similar matters. Other participants argued that, to paraphrase, we shouldn't let perfect be the enemy of the good and we should implement the changes now. Some participants argued for A/B testing, but there was insufficient participation on that question to find a consensus to do A/B testing as a condition of implementing these changes. Overall, there is a strong consensus in favor of the general changes proposed (reducing links, making the template more personal, and better visual design), and a rough consensus in favor of the specific proposed template. There is also consensus that the specifics of the proposed template could be improved (which specific links to use, etc.), but no definitive consensus as to what those specifics are.

There seems to be a couple different ways we could go from here:

• We could implement the proposed template now, and allow discussion and changes from there
• We could open a new discussion to work out the details of the new template, leaving the current template in place until specifics are worked out
Both of these options are valid ways to enact the consensus from this discussion, but I would personally suggest (without the closer hat on) in the spirit of incremental improvement that we implement the changes now and discuss and adopt further improvements to it over time. As always, questions about this closure are welcome. Best, Kevin (aka L235 · t · c) 20:36, 4 April 2020 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Template:Welcome (the standard welcome template) contains too many duplicate or unnecessary links and needs some streamlining so that new users aren't paralyzed by choice. For instance, it currently suggests four different places to go if you have a question[a] and four different tutorials[b]. Following a survey of Wikipedia's introductory materials, I drafted some changes to streamline the template that establish a clearer visual hierarchy to point new users to our best resources and remove more minor links to topics covered in Help:Introduction (such as the Manual of Style). After receiving some positive feedback at the Welcoming committee WikiProject, I'm bringing it here to establish a broader consensus for implementation. Here's the proposal:[c]

Welcome!

Hi [Username]! I noticed your contributions and wanted to welcome you to the Wikipedia community. I hope you like it here and decide to stay.

As you get started, you may find this short tutorial helpful:

You may also want to complete the Wikipedia Adventure, an interactive tour that covers the same topics.

If you have any questions, we have a friendly space where experienced editors can help you here:

If you are not sure where to help out, you can find a task here:

Please remember to sign your messages on talk pages by typing four tildes (~~~~); this will automatically insert your username and the date.

Happy editing! Sdkb (talk) 21:42, 11 February 2020 (UTC)

The full code (which includes customization options) is at the template's sandbox. Please let me know what you think! Cheers, Sdkb (talk) 21:42, 11 February 2020 (UTC)

1. ^ The Teahouse, WP:Questions, the welcomer's talk page, and the new user's own talk page
2. ^
3. ^ Note: Refactored 03:08, 27 February 2020 (UTC) by Sdkb (talk) to include Task Center button.

Initial comments copied over from the Welcoming committee WikiProject:

:I most often leave GF newcomers the {{Welcome!}} or {{Welcome-anon}} templates. I prefer the proposal by Sdkb as simplifying their choices to one of two, rather than a roster of policies and procedures. We may want to have a third choice for people who appear to be creating a draft article? - Bri.public (talk) 17:30, 27 January 2020 (UTC)

Yeah, as I was looking around the new user welcome pages, I noticed that the WP:Article Wizard and Help:Your first article (which has a big bold link to the wizard) are both well-designed and useful. Users that seem to be creating an article should definitely be pointed there. I'm not so sure about including it in the standard welcome message, though, since I think it's a bad idea to encourage newcomers to create an article right off the bat — they're very likely to try creating an inappropriate article for a topic with which they have a COI, and when it gets rejected they'll feel bitten. Do you have a sense of how many new users try creating an article as one of their first edits? If it's something they're going to do anyways, we may need to point them to our resources by default, whereas if most new editors can be steered initially toward other types of editing, I think we're better just leaving it out. The edit notice when you try creating a new article points there anyways (although perhaps not quite boldly enough). Sdkb (talk) 21:30, 27 January 2020 (UTC)
Wow, this looks MUCH more approachable to me than any of the other welcome templates! I think it's very effective at directing new users to two main ways to learn more about the "hows" of editing Wikipedia. It's amazing how different it is vis-a-vis choice paralysis compared to the other options, especially the more "graphical" options, which tend to look overwhelming.
Having just praised the simplicity and restraint of the links included..... I find myself wanting to add a link to the Five Pillars, because I think the one aspect that's missing right now is an approachable entry point to the core goals and norms of Wikipedia. Of the resources intended to introduce that information, I think the Five Pillars page does the best job of hitting the key points in a visually approachable way. I wonder if it can be slipped in as a sentence or phrase that doubles as a wikilink somewhere? So it's not an immediate "call to action" but it's present for a newbie to find early in their process of exploring. Or -- could it be added to the Introduction help page itself? I think that helping newbies feel like they have a handle on the core principles of the culture and norms is as important as technical knowledge.
I'd be very happy to see this template in use, though, with further tweaking after it's entered the real works! Well done on the research and design work to build a compelling alternative. ~ oulfis 🌸(talk) 04:28, 30 January 2020 (UTC)
Thanks for the praise, Oulfis! Regarding the pillars, the second module of the linked introduction is titled "Policies and guidelines", and while it doesn't explicitly list the pillars, it does mention that the project is "founded on five fundamental principles" and goes on to cover them. Sdkb (talk) 05:24, 30 January 2020 (UTC)
This hasn't gotten enough discussion to reach too solid of a consensus, but since there's been some support and no strong opposition, I'm going to act boldly and go ask for it to be implemented. Sdkb (talk) 06:05, 11 February 2020 (UTC)
• @Sdkb: Is there a reason one button is blue and the other is not? I'd prefer they be the same but it's not a huge deal; I like the general concept. 21:54, 11 February 2020 (UTC)
You can see a little bit about the different types of buttons WP has at the template page here. The blue button is the "progressive" class, i.e. something that we think you ought to click. The white button is "neutral" class, i.e. something that you can click if you want. I classed them that way since the tutorial is something we strongly want to encourage new users to check out, so it makes sense to have a more prominent styling, whereas the Teahouse is something we want them to know about but don't need to push them toward. Per the rules of visual hierarchy, it's also better to have a single point of focus, i.e. if a new user is only willing to click on one link, we should let them know that it should be Help:Introduction. Now, all that said, I also thought it looked slightly odd, and if it also appears that way to others, I'd be fine with making them both blue. Sdkb (talk) 01:39, 12 February 2020 (UTC)
• I like it. I remember being overwhelmed by the many links and options when I was welcomed. I've been using {{welcome-screen}} because some other editors in a discussion seemed to think it the best of the options at the time, but even simpler (like this) would be better. I think some way to set it off (a border, perhaps?) and make it stand out on a talk page would be helpful. Schazjmd (talk) 21:58, 11 February 2020 (UTC)
A border would definitely be nice! I focused on changing the text/buttons since that's more what I know how to do, but feel free to tweak the sandbox if you're inclined, and we can consider it. One thing to keep in mind is that when the welcome template is used, it being it's own section provides a sort of natural border, so it doesn't appear as floaty as it does here when I put it in the middle of a conversation. Sdkb (talk) 01:39, 12 February 2020 (UTC)
That's a good point (about the separate section). I know nothing about making templates, I just admire and appreciate them. Schazjmd (talk) 01:43, 12 February 2020 (UTC)
I use the Welcome template regularly, especially when I see a red Talk box in a history. Concistentcy in the wording would be a good change. Allowing an article name to go in from a box in more places would be good, too. Perhaps we could allow a choice of images, not just cookies, as we already have in some barnstars. There are too many ways to warn new users or IP users, and not enough ways to welcome a new user with many or especially good contributions. Good idea to post the revision here for us to see and comment on. Cheers!--Dthomsen8 (talk) 02:14, 12 February 2020 (UTC)
Strong oppose choice of links "if only one page"...should be WP:Contributing to Wikipedia. .Not good feed back or good data for multi-page tutorials that are not formatted property for mobile view. Main problem I see above is the fact our main intro page is missing WP:Contributing to Wikipedia (the page with all the info, links to all the main help pages, and videos, brochures produced by this community and the Wikimedia Foundation). We have learned over the years the "Next page style" doesn't retain readers. Should not replace links to our help articles maintained by the community with mobile view format problem tutorials that lack basic info and our outdated. If trimming of links is required...tutorials should go and our 3 main help articles that have watchers to help should be retained. Don't send new editors on a goose chase trying to find information ...make it available on one page with a nice TOC for navigating to the section most relevant. Raw data Wikipedia:IntroductionDaily average:723....next page Daily average:85...page after that Daily average:44.....by page 50 only 6 virws. People dont want a list of link to another list of links.....they want serviceable info at a glance in a recognizable format.--Moxy 🍁 06:42, 12 February 2020 (UTC)
Hi Moxy — I'm very much with you about reducing the lists of links, so hopefully we're at least in agreement about the overall need to streamline. Funneling users to a single intro when we currently have multiple is unfortunately going to have to involve stepping on someone's toes. I see that you're by far the top contributor to WP:Contributing to Wikipedia, so I apologize, but in its current state it just does not feel as modern and user-friendly as Help:Introduction. Essentially all other large websites (which, let's be honest, devote a lot more resources to user interface issues than we do) have onboarding processes for new users that use multiple short pages as Help:Intro does, rather than one really long one. I have to imagine they know what they're doing. Sdkb (talk) 21:49, 12 February 2020 (UTC)
We will simply have to disagree. ..... I don't see how info separated out over 50 different pages that does not work properly in mobile view is more helpful ...run around setup.--Moxy 🍁 22:32, 12 February 2020 (UTC)
We have lots of welcome pages, no objection to another being created. But changing the default this radically should not be done without first testing different welcomes and seeing which has the best result in terms of turning newbies into regulars. ϢereSpielChequers 08:02, 12 February 2020 (UTC)
I see these changes as an improvement to the standard welcome template, not an alternative to it; they're substantial but build on what's currently there rather than replacing it from scratch. More to the point, since so many editors default to using the standard welcome, I think it's important we make that one as good as it can be; the old one could be renamed to something else if any editors really want to keep using it. I also don't think it's great to have too much welcome template proliferation — we need to keep our best resources centralized so they can be maintained/improved, not fork them every time there's a controversial upgrade.
Regarding testing, I'm very much behind the idea of doing some A-B testing in theory, but when we previously discussed it, it didn't seem to be very practical. It would take a long time to build up a sample (since I don't know of any way to welcome newbies in bulk) and would take some programming to measure the results. If you or someone else has the expertise and time to conduct that sort of experiment, I'd be fascinated to see it, but barring that, we should act boldly and go with whatever we think will likely work best. We risk as much through inaction as through action, and there's a lot of room for improvement in converting readers to editors. Sdkb (talk) 22:23, 12 February 2020 (UTC)
@Sdkb: off the top of my head, you could create two redirects, E.G. WP:TEST1 and WP:TEST2 that both go to the same page. Have the template randomly link to one of them on each transclusion. After a few days/weeks, compare the number of page views each redirect got with the number of back links to show which had the most best ratio of clicks to transclusions. 03:06, 14 February 2020 (UTC)
A redirect could be used to measure the engagement of this template, but it wouldn't work with the current Template:Welcome as a control, since that template links to many intros, not one. And there's still the issue of building up a meaningfully sized sample. Sdkb (talk) 03:42, 14 February 2020 (UTC)
• This welcome message doesn't work on an Android mobile device. In its current state it takes you through several pages of broken formatting. Until that is fixed, this is not an improvement and is more likely to drive many editors away. While I can see your good intentions here, simplicity is best when we have to consider mobile audiences. From Hill To Shore (talk) 00:22, 14 February 2020 (UTC)
Can you share a screenshot of the issue you're encountering? It works alright on my Android device. And yes, simplicity is the whole goal here—that's what this template is doing. Sdkb (talk) 03:29, 14 February 2020 (UTC)
A note regarding mobile formatting: I fully agree that ability to read on mobile is vital, and the {{intro to}} and {{intro to single}} templates both need to be updated to use flexbox css to make that smoother. Thet should be a relatively quick fix. The cause of the poor mobile formatting is that these are all currently in rigid divs, rahter than flexbox divs (main culprits are the handling and placement of {{Intro to tabs}} and the column implementation in {{intro to single}}). Sidenote: this is also a problem with a lot of templates that aim to implement multilpe tabs (compare Wikipedia:Tutorial vs v:WikiJournal_User_Group for a flexbox equivalent for tabs). T.Shafee(Evo&Evo)talk 05:31, 26 February 2020 (UTC)
Thanks for that info! I made a request for help at the technical pump since I don't know how to use flexbox divs myself, but I'm not sure if anyone will take me up on it. If you end up being inclined to make the fixes yourself, it might go a long way toward helping this proposal achieve consensus. Sdkb (talk) 09:37, 26 February 2020 (UTC)
@Sdkb, From Hill To Shore, and ToxiBoi: I've updated the Template:Intro_to/sandbox to work pretty well on mobile I think (as well as making the window on a desktop narrow). I'd welcome any testing by others though! Formatting parameters now controlled through Template:Intro_to/styles.css. Side-by-side comparison to Wikipedia:Tutorial on others' devices also valuable. Just waiting for the sandbox version to be copied over to the main template before it's viewable as the default for all pages using that template. T.Shafee(Evo&Evo)talk 07:25, 1 March 2020 (UTC)
Good work, the problems I was seeing in Firefox on Android have now gone. From Hill To Shore (talk) 14:18, 1 March 2020 (UTC)
We had talked about linking the main To-do page Wikipedia:Maintenance in the past but most seem to think that pointing new editors to what to do page off the bat would not be all that helpful. I personally think Wikipedia:Maintenance gives a good overview. PS was looking for this link for hours last week.... As it was one of the reason WP: contributing to Wikipedia was updated with Foundation brochures and added to the templates.--Moxy 🍁 00:02, 25 February 2020 (UTC)
@Moxy: WP:Maintenance is certainly comprehensive, but I'm not sure it's accessible to new editors. It has too much detail on too many tasks — for instance, the very first item after the intro is a full section on copyvio, a complex area I'm not sure many new editors are going to want to dive into. I think the best approach for new editors is to provide a bunch of options of areas where help is needed, let them choose one, and then provide instructions for that area and clear examples of pages where they can apply what they've learned. The Task Center does this with a short intro followed by a concise list of tasks. I like how it plugs the benefits of participating in different areas. The open tasks list has the advantage of listing actual articles editors can click on and then help out with. Overall, I'm leaning toward including the task center. Sdkb (talk) 07:19, 25 February 2020 (UTC)
Update: I've added a button for the Task Center to the sandbox. If there are no objections, I'll wait a day or so and then refactor the proposal here to include it. Sdkb (talk) 00:19, 26 February 2020 (UTC)
• Comment: Research and testing It makes a lot of sense to actually assess how effective our welcome messages are, and to improve them where possible. Ensuring that not only the welcome messages, but also the pages they links to will display properly in mobile view seems almost as important as the effectiveness of the welcome template itself. Sadly, as Moxy has found, there seems to have been no serious research into the effectiveness of welcome messages and their impact on editor retention since around 2011/2012. (i.e. all pre Teahouse) All I could find is this, this and this, which was mentioned above.
One 2011 study on German Wikipedia concluded that:
Back at English Wikipedia, there is a study currently ongoing by WMF researchers into Teahouse invitation message effectiveness. (Summary: It is comparing the old automated invitee selection process against an ORES-based editor selection process for HostBot to send out invitations to new editors who've made their first few edits here. The research process unfortunately contained a small number of variables which rendered the results on editor retention inconclusive, and a second wave of research will hopefully go ahead soon. It did not look at the effectiveness of the Teahouse invitation wording, or timing, - only the criteria for the selection of good faith editors to send them to. See here for summary and feedback)
Now, it strikes me that the A/B study methodology used to look at Teahouse HostBot invitations must be very similar to that needed with Welcome messages. Therefore, I am pinging @Jtmorgan, Maximilianklein, and Halfak (WMF): in the hope that one of them might be willing to offer ideas or insight on whether any research study is currently ongoing or planned, and whether there might be a possibility of encouraging, supporting or funding an investigation into this important and related area of editor welcome and retention. Nick Moyes (talk) 12:34, 25 February 2020 (UTC)
Maximilianklein is considering doing some more testing of AI-powered HostBot invites later this year, but no plans are finalized. If it looks like it's going forward, we'll notify on the Teahouse. Depending on the scale of the experiment, I could see experimenting with different welcome templates being a component of it. When it comes to what should be on the generic invite template, I'm definitely in the "less is more" camp. We can't, and shouldn't expect new editors to RTFM before they do anything. J-Mo 19:53, 27 February 2020 (UTC)
Simply is best in my view as per this - thus I use Template:W-short alot. Years ago we created 2 types of "MAIN" help pages - one static article style WP:Contributing to Wikipedia and duplicated that at info at Wikipedia:Tutorial with tabs/next buttons (see what worked best). We can see and saw by the numbers most dont go beyond the first page of the tutorial. This is also what happens at the Wikipedia:Adventure - 50 percent drop in views by the second page....with a loss of 90 percent by page 3. I am all for making things easier ...not harder by making people click 50 times to get serviceable information....less is best and of course mobile view must be considered. -- Moxy 🍁 14:22, 25 February 2020 (UTC)
@Moxy: those numbers are certainly concerning. To me, they potentially point to those resources not being as well-designed as they ought to be. (Do you have a link to the data, btw?) Some dropoff is natural, though, since we're never going to convince everyone to read a full tutorial, and for all we know, the dropoff rate on the pages that present it all together could be even higher. (The metric we'd need to measure that would be average time spent on page, and probably only the WMF knows that.) The benefit of splitting materials into multiple pages is that short chunks are more digestible, whereas sending readers to one long huge page will overwhelm many and make them give up. Sdkb (talk) 00:03, 26 February 2020 (UTC)
Good day I phone user.....can you elaborate on your experience! I am assuming your our normal IP poster and get a lot of welcomes.....what template is used most in your case?--Moxy 🍁 23:35, 25 February 2020 (UTC)

The blue-with-white-text button seems wrong to me. I believe (though I might be wrong) that blue buttons have a specific semantic meaning on Wikipedia. On my desktop interface, the "Publish changes" button is blue/white, and the "Search" button on the search page is blue/white, implying submission of a request, not just a link. – Jonesey95 (talk) 05:03, 26 February 2020 (UTC)

I haven't been able to find any stylebook or documentation about when it's appropriate to use a blue vs. gray button. I gave my rationale for choosing blue to Wugapodes above, but similar to what I mentioned above, I'd be open to it being gray if it looks weird to others, too. Sdkb (talk) 03:39, 27 February 2020 (UTC)
At the very least we should follow MOS:COLOUR "Links should clearly be identifiable as a link to our readers." Big changes here...removal of most links....replaced with a link to an intro with 50 sub-pages that is currently not viable for 60 percent of our readers.....and big buttons that may or may not look like links. Best create a new template see if it gets good feedback ...then ask for a whole scale change to the main welcome template.--Moxy 🍁 04:07, 27 February 2020 (UTC)
This style guide was very difficult to find. I think it is current and accurate. Jon (WMF) may be able to give us some pointers or send us to the right resource or person. It would be useful to have some version of this UI style guide in a form comprehensible to regular editors. – Jonesey95 (talk) 05:26, 27 February 2020 (UTC)
Interesting read.--Moxy 🍁 05:32, 27 February 2020 (UTC)
Thanks; that's what I was looking for (without knowing it existed)! The key phrase seems to be this: Use progressive variant for actions which lead to a next step in the process. (progressive variant = the blue one) Whether that's applicable here is a little borderline; I think we could go either way. Courtesy pinging Wugapodes, as you had the same concern about the color. Sdkb (talk) 05:45, 27 February 2020 (UTC)
Action.= ."If an action is to “navigate the user to a new resource, taking them away from current context, consider a link instead.". The norm as per all wikis. the most significant navigational symbol we have.--Moxy 🍁 06:08, 27 February 2020 (UTC)
The major advantage of buttons over links here is that we can easily make a button fittingly prominent, whereas I'm not sure how to do that for a link. If you want to experiment, I'd be interested to see a design that uses a prominent link instead. Sdkb (talk) 07:03, 27 February 2020 (UTC)
Sdkb You make a good point about experimentation. To that end please do not overwrite the old welcome template, but create a new one instead which will allow side by side comparison as to its effectiveness, as Moxy suggested above. I appreciate there is already an over-abundance of tweaked welcome templates, but this is a significant change and one well worth testing and tweaking alongside the older approach. Nick Moyes (talk) 10:31, 27 February 2020 (UTC)
We can also consider the example and precedent of the Teahouse HostBot invitation template, which uses what looks like a custom-designed button. If we used that style of button here, it would display as this:

Sdkb (talk) 23:16, 27 February 2020 (UTC)
• Support. I agree that the current Welcome template is in need of some streamlining. My only concern with the new design is with the buttons, it could trip up a new editor when they press one and get taken to a different page (that's what I think, though). Also can confirm it works fine on Mobile Web. – (contribs) 02:06, 28 February 2020 (UTC)
If concerns are with the mobile app, I can see that happening. I won't be able to test that myself though. – (contribs) 02:07, 28 February 2020 (UTC)
• I strongly support this new welcome template. Simply put, less is more. This new message feels more personal and less like automated spam, it's got a clear actionable goal you can take to learn the basics about the site (rather than a dump of a couple dozen links that don't feel like they have a cohesive narrative) and it's less prone to being bloated over time. (Brought here by a neutral message at Wikipedia talk:Wikipedia Signpost/2020-03-01/Opinion.)Bilorv (talk) 22:16, 4 March 2020 (UTC)
Less links would be better. Should keep link to standard page over an assembly of tutorial pages. If simplicity is the goal then multiple page tutorials is not the answer.--67.201.160.202 (talk) 23:10, 4 March 2020 (UTC)
• Support generally as long as some of the other considerations above are taken into account, like making it mobile-friendly and reconsidering the first link. I personally would have loved to see the Teahouse link or the "Task Center" links earlier on when I first joined -- I only found out about them somewhat recently, but they both make Wikipedia way more approachable/simpler to new users. The simpler design of the template overall is also really approachable.
My concern is that I don't think the first link is the most helpful introduction to editing. And I agree with some above that it should probably have either an option for or one extra link about drafting articles. - Whisperjanes (talk) 04:05, 17 March 2020 (UTC)
Thanks for the support! Regarding mobile-friendliness, to my understanding the issues above have been fully addressed at this point. Regarding WP:Your first article, I think editors really set on creating one will find their way there—it's linked from the Task Center and from the uncreated page edit notice, which we recently strengthened. For all others, we should direct them toward tasks less likely to bite them. Regarding the introduction link, what would you consider the most helpful intro? Having surveyed them all in some detail, I feel the blue button should go to Help:Introduction, but I'd have no problem modifying the line beneath it, perhaps to Alternately, the Contributing to Wikipedia page and interactive Wikipedia Adventure tour cover the same topics. It's worth noting that whatever we choose here will almost certainly be an improvement over the current version of the welcome template, which links first to WP:Introduction, an intro so bad it is likely to be converted to a redirect soon. Sdkb (talk) 06:37, 18 March 2020 (UTC)
Only agreement here is for less links.....no agreement to change to an action button....or to link the 60+ page intro over our main help pages....So really all we have is the WP:Introduction that will change to Help:Introduction but if we drop links multiple page tutorials should be dropped...As mentioned above ...best test before trying to implement multiple changes.--Moxy 🍁 06:50, 18 March 2020 (UTC)
I actually do think they should be changed to action buttons, because they stick out more and I think are easier to read and click (although that's just a personal opinion). Testing it might also be a helpful step in this process (although I'm not sure how that's usually done on Wikipedia, or if it's really feasible). Although, I assume you have to make it first anyways to test it. So possibly finding a way to collect data on the templates already used, as editors have been talking about above. Whisperjanes (talk) 16:44, 19 March 2020 (UTC)
@Sdkb: Thanks for following up! Yeah, now that you mention it, I'd be fine with leaving "your first article" out -- especially since I think most new users get on to make an edit first (from my personal observation). And it's hard to say which alternative for the introduction link... I would like to say Wikipedia:Contributing to Wikipedia (because it's written in a similar style to most guidelines... although, to be honest, it's incredibly dense and I'm not sure how helpful/quick it is to use). I was actually going to suggest Wikipedia:Introduction, until I read the current discussion happening on it. I'm not sure all of which pages exist out there for intros, but the one thing I think is most important is that it gives information on the first page immediately after you click away from your user talk page. That's why I'm not as much a fan of Help: Introduction (because the first page gives you a directory of links, not info). I actually think I would prefer Help:Introduction to Wikipedia because it brings you immediately to information, but the only downside is that if you keep clicking, it automatically teaches you Wiki markup, not the visual editor. Obviously, I have a lot of thoughts but not many answers, so I'm more open to seeing what others think than my own opinions. Help: Introduction might end up being the best option, I just find it daunting (to have to choose what you're going to learn before you understand Wikipedia, including which editor you want to use) and have a problem with the fact that it draws your eyes first to the editing interfaces, rather than the intro tutorial. Whisperjanes (talk) 17:11, 19 March 2020 (UTC)
I would be ok with....- -Moxy 🍁 07:02, 18 March 2020 (UTC)

Hello, Example, and welcome to Wikipedia! Thank you for your contributions. I hope you like the place and decide to stay. Here are a few links to pages you might find helpful:

You can visit The Teahouse to ask questions or seek help.

Please remember to sign your messages on talk pages by typing four tildes (~~~~); this will automatically insert your username and the date. If you need help ask me on my talk page, or ask for help on your talk page, and a volunteer should respond shortly. Again, welcome!

• Late support from me too. I just saw the proposed template on a user talk page and was positively surprised. ~ ToBeFree (talk) 19:34, 18 March 2020 (UTC)
• My main concern has always been the removal of our main help page and the pillars for a tutorial that is 60plus page of info that just has more links.....a clicking nightmare for anyone with a disability. But after seeing another concern raised about visibility I wonder how many other people see little mini boxes? as seen here. --Moxy 🍁 21:11, 25 March 2020 (UTC)
On my mobile browser (Chrome on Android), it looks fine (screenshot). This might be an issue to raise at Template:Clickable button 2, as templates such as the Teahouse HostBot invitation also use buttons. Sdkb (talk) 21:43, 25 March 2020 (UTC)
What happens when you turn your phone sideways? Anyways... queation is should we direct new editors to 60plus non standard pages that may or may not work properly for mobile readers (the majority of out readers). Not sure why accessibility for disabled people is being thrown to the wind here.--Moxy 🍁 23:21, 25 March 2020 (UTC)
• Strong support for this new welcome template. Time for us to move forward with a good welcome template. Further improvements could be made after implementation right now.--Dthomsen8 (talk) 00:01, 26 March 2020 (UTC)
• Note: A little discussion spilled onto my user page and can be found at this thread. Sdkb (talk) 01:09, 28 March 2020 (UTC)
• Support - Admittedly I prefer the old one simply because it's what I'm used to however as Dthomsen8 says It is time for us to move forward and I agree with the nom that the old template had far too many links, Although the blue/white box is used for Publish changes I don't personally see that as a reason to oppose,
The new template is a major improvement over the old one and so support it being the default one. –Davey2010Talk 10:58, 30 March 2020 (UTC)

Strong support of the proposal on teaching code to newcomer. also the page http://en.turkcewiki.org/wiki/Help:Wikitext is difficult to follow. I am proposing for a easier help page with limited number of necessary commands. Currently I have kept the draft in my sandbox http://en.turkcewiki.org/wiki/User:RIT_RAJARSHI/sandbox Regards and thanks RIT RAJARSHI (talk) 09:31, 1 April 2020 (UTC)

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

## Auto-linking titles in citations of works with free-to-read DOIs

I propose to change the behaviour of the CS1/2 citation templates: the auto-linking mechanism (which provides a default value for |url= when |pmc= is available) would also cover |doi= with |doi-access=free.

In short: if |url=, |chapter-url= and |pmc= are not set, but |doi= and |doi-access=free are set, the title of the citation would be linked using the DOI.

#### Example

With the following code:

 {{cite journal |author1= Hoffman S.J. |author2=Lavis J.N. |author3=Bennett S. | year = 2009 | title = The Use of Research Evidence in Two International Organizations' Recommendations about Health Systems | journal = Healthcare Policy | volume = 5 | issue = 1| pages = 66–86 | doi = 10.12927/hcpol.2009.21005 | doi-access = free }} 

You would get the same result as if |url=http://doi.org/10.12927/hcpol.2009.21005 was set:

• Hoffman S.J.; Lavis J.N.; Bennett S. (2009). "The Use of Research Evidence in Two International Organizations' Recommendations about Health Systems". Healthcare Policy. 5 (1): 66–86. doi:10.12927/hcpol.2009.21005.

Pintoch (talk) 19:02, 23 April 2020 (UTC)

### Motivation

As a reader, it is natural to click on the title of a citation to access it. Clicking on identifiers is less intuitive, even when they are marked as free with . In fact, editors often fill the |url= field with the URL the DOI resolves to, to obtain this linked title (see statistics below).

When an article is free to read from the publisher, it is generally preferable to point readers to the publishers' version. Not only is it the version of record, but this is also the place where any errata or retraction will be published, and the DOI link is less likely to rot. If for some reason another version is preferred (because it is the one the editor read when citing the work, or because it is more directly accessible than via the publishers' website), it would still be possible to override the link with |url=, just like for |pmc=.

Since |pmc= is already used for auto-linking, I propose that |pmc= has priority over |doi=+|doi-access=free to generate the title link. This will ensure that all titles currently linked will not be changed by this move. PubMedCentral also stores versions of record, in a clean and readable way, so I do not think there is a need to override them.

### Statistics

Here are some figures extracted from the enwiki dump of 2020-04-20. At this point, 189,097 citations had a |doi= and |doi-access=free set.

• 1,773 (1%) of these also had a |pmc=
• 28,012 (15%) did not have a |pmc= but had a |url= or |chapter-url=
• 159,312 (84%) had none of |pmc=, |url= or |chapter-url=, so their title was not linked, but would be linked using the DOI with this proposal.

Among the templates with both a free-to-read DOI and a manually-specified URL, 66% of these are equivalent to the DOI link (they eventually redirect to the same website) or the URL points to the publishers' website but no longer works (404 error). This figure was obtained by randomly sampling 100 pairs of DOI/URL from the dataset and comparing the links manually. This shows that editors are keen to link the title of their citations. This encourages link rot since they rarely use |url=http://doi.org/... but rather the URL the DOI redirects to.

### Survey

I am closing this because discussion seems to be petering out. There is consensus to implement the proposal. Sandstein 15:53, 22 May 2020 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

• Support as proposer. − Pintoch (talk) 19:03, 23 April 2020 (UTC)
• Oppose. There are too many different ids to link (jstor, doi, bibcode, pmid, hdl, citeseerx, arxiv, etc) for auto-linking an arbitrary choice among them to work well. Better to just list them as links. I am also opposed to autolinking pmc, for the same reason. —David Eppstein (talk) 19:11, 23 April 2020 (UTC)
• It's rather trivial to make work well. Is it identifier of record (e.g. doi, jstor, pmc, etc...) that links to a full free version of the text? If yes, autolink. If it's not an identifier of record (citeseerx, arxiv, etc...), or does not link to a free full version, do not autolink. Headbomb {t · c · p · b} 22:04, 23 April 2020 (UTC)
• That doesn't actually respond to the issue I raised. There may be multiple conflicting identifiers of record. On what basis should we make an arbitrary choice to front one of them? —David Eppstein (talk) 19:54, 26 April 2020 (UTC)
• If multiple identifiers link to a free full version of record, it doesn't matter which is used, since they all link to the same version. What's important is that the reader is given one. Editors could always override the default if there's a specific need for it (e.g. using the bibcode links instead of the doi links on an astronomy article). Headbomb {t · c · p · b} 20:07, 26 April 2020 (UTC)
• Support, and hallelujah for this proposal, as this issue has been causing me grief for years. In all of our articles, readers generally know that a blue-linked title takes them to free full text. We cannot expect our readers to understand (in medical content) what PMC, PMID, DOI or anything else stands for. We also should not expect them to have to scroll through all of these to determine if they can locate free full text (as opposed to just an abstract). We can standardize the experience for our readers by giving them a blue link in the title when free full text is available, as that is what they find on other articles. This is a service to our readers who may not know what any of those other codes stand for, but will recognize a blue-linked title. SandyGeorgia (Talk) 19:40, 23 April 2020 (UTC)
• What happens if there is both a |url= filled out and both |doi-access=free and |doi= filled out? Jo-Jo Eumerus (talk) 19:51, 23 April 2020 (UTC)
• That's covered in the proposal: |url= overrides |pmc=, and both override |doi-access=free + |doi=. Kanguole 20:02, 23 April 2020 (UTC)
• Why would url override PMC, when PMC might be more enduring? SandyGeorgia (Talk) 20:05, 23 April 2020 (UTC) That is, I provide a url only when there is not a PMC, but my preference is PMC. SandyGeorgia (Talk) 20:11, 23 April 2020 (UTC)
• The priority question arises if more than one of |url=, |pmc= and |doi=+|doi-access=free are set. Kanguole 20:36, 23 April 2020 (UTC)
• URL, if provided, means someone thought to overrule the PMC (or the DOI if this passes). If PMC/DOI is desired to take precedence over URLs, that could be enforced by bots or by the template depending on consensus. Headbomb {t · c · p · b} 21:55, 23 April 2020 (UTC)
• OK, that resolves my concern, since I only give a URL where no PMC is available. SandyGeorgia (Talk) 22:08, 23 April 2020 (UTC)
• Support the simplest thing for a reader to learn is that clicking on a title link takes them to the freest available online source. This proposal helps that happen. No citation with a free online source should have an unlinked title. --RexxS (talk) 20:08, 23 April 2020 (UTC)
• Oppose. The DOI link is already present in the citation, and it is helpfully marked as free. Clicking on it is as natural as clicking on an ISBN link. Duplicating the link adds nothing but more blue text and more complexity. If a reader sees a linked title, is it an explicit |url= or a copy from one of the identifiers? If there is more than one identifier, which URL was copied? We're already seeing confusion with just two extra URL sources, but after this there will be a push to copy URLs from other free identifiers as well. And then editors will be worrying about the priority order and asking for additional knobs to tweak it, adding more complexity. Let's avoid all that, by not duplicating the link. Kanguole 20:52, 23 April 2020 (UTC)
"is it an explicit |url= or a copy from one of the identifiers" this does not matter to a reader. But if consensus is that which identifier is used is important, |via= could reflect this too, e.g.
Headbomb {t · c · p · b} 22:01, 23 April 2020 (UTC)
• Support all advantages, no negatives. This very reader friendly and greatly improves accessibility on mobile and other platforms. We already do this for PMCs, it's time to extend the behaviour to free DOIs too. Headbomb {t · c · p · b} 21:53, 23 April 2020 (UTC)
• Support As some have pointed out, this is a trivial change if you already know what to expect from dois and the symbol for free access. However, this can significantly improve usability for those whose first instinct will be to click on the title. ${\displaystyle \langle }$ Forbes72 | Talk ${\displaystyle \rangle }$ 00:21, 24 April 2020 (UTC)
• Support. This is common sense, as it leads the reader more easily and intuitively towards the full text. It serves the purpose of practical verifiability, deeper research, and expected user experience. Objections that this makes the citation more "complex" vastly misunderstand the background knowledge of the average encyclopedia reader (or human), who has no idea what an identifier means. Best practice in usability is to reduce the distance between user knowledge and interface behavior: it's overwhelmingly obvious that a linked title is closer to user expectation than a linked [insert weird number/abbreviation most have never heard of]. Verifiability has an internal policy purpose, and also an outward mission-function of actually sharing knowledge by building the web through linking to it. To the extent that Wikipedia aspires to capture the sum of all human knowledge, we must as a responsible node in the ecosystem of reliable sources facilitate access for our readers to those sources. This proposal is a simple, minimal, concrete, and reasonable step towards that. --Founder of The Wikipedia Library, Jake Ocaasi t | c 00:27, 24 April 2020 (UTC)
• Support lots of stuff has a doi, and its main benefit is its stability. If we know there is a stable, gratis version out there, we should link to it since it's pretty much the single most useful link for readers and reusers. Common sense proposal. 00:38, 24 April 2020 (UTC)
• Example of references with DOI green locks: Zika fever
Example of references with PMC green locks (already auto-linked): List of sequenced bacterial genomes
Example of references with DOI and PMC green locks, a link to another repository and a toll access DOI: 2019 in paleobotany
Support as a useful step in the daunting task of improving our citations to follow guidelines on verifiability. Open access works need to be easy to identify in the jungle of references which the bigger articles often have, especially in a period when many cannot visit a library any more to benefit from "walk in" access. Others have addressed concerns above already, I'll just note that the users who know the difference between identifiers, and have preferences about them, don't need to know which one is used for the URL, because they can just continue clicking their preferred identifier. The automatic linking mostly changes the experience of the vast majority of users who have no idea what the various identifiers are (although we may hope to educate them gradually). Nemo 07:03, 24 April 2020 (UTC)
• P.s: I've added some screenshots for those who may not be familiar with the DOIs and access-level locks we're talking about. Nemo 07:11, 24 April 2020 (UTC)
• Support per above. Thanks for addressing this. {{u|Sdkb}}talk 07:08, 24 April 2020 (UTC)
• Oppose per David Eppstein and Kanguole above. This proposal is fixing a problem that does not exist. It is adding unnecessary complexity without a benefit in functionality, flexibility or maintainability of citations, now or in the future.
The link to the identifier already exists and it is obvious and trivially easy to use ("click on it"), so this change would just add to the "sea of blue". Providing the same link twice may even cause confusion for readers (and therefore be against the principle of least surprise) because nobody would know any more if a blue title means that it points to some |url= or not. Also, there are often several identifiers to choose from (and there will likely be even more in the future), so we would have to define arbitrary priorities which identifier would take precedence over another. I can already see endless discussions about why one identifier is more important than another, and it will be impossible to make everyone happy with a decision. Worst, over time, different identifiers may be declared to take precedence causing a citation's title to link to resources which could not be predicted by the editor who added a citation in the first place. This borders on falsification of an original editor's contribution. In the readers' perception, the title link will no longer link to some conscientiously selected url, but just to some pseudo-random resource somehow related to the citation - this is degrading the quality of citations and is weakening our network of trust rather than improving it. For the same reasons, I'm also against autolinking |pmc=.
Several decades into the future, many urls will be broken, but likewise many dois will be broken as well. Even some web archivers may have stopped working by then. The solution to this problem of link rot is to provide as many independent backups as reasonably possible, but not to provide links to identical resources twice under different names.
Somewhat related, if a url points to the exact same target as a doi, the url can be safely removed, but often enough I see editors removing urls which point to the same (or only similar) content on a different target page as well. Removing |url= they also remove |access-date= and |archive-url=. While this is not the topic of this RFC, it is driven by the same misguided idea that dois were somehow superior to urls, and that urls (and related framework parameters) can be removed if a similar doi exists. These editors are weakening our citations rather than improving them. Therefore - and this is topic of this RFC - I see this attempt to let dois look like kind of urls in disguise as potentially harmful to the long-term integrity of our citations.
--Matthiaspaul (talk) 12:05, 24 April 2020 (UTC)
Viewed at it from a rather different angle, but partially related to the problem of having to define and maintain arbitrary priorities for multiple potential identifiers which might be used as a source for auto-linking: Help_talk:Citation_Style_1#Google_books_example
--Matthiaspaul (talk) 16:38, 6 May 2020 (UTC)
• Support for the same reasons as Forbes72 above, and as DOIs are an international standard designed for persistence [1], the idea makes good sense to me of using a DOI as a first-class title-linking source with optional pmc or url overrides. ― Shnizzedy (talk) 14:12, 24 April 2020 (UTC)
• Support It would be a slight change in any given instance, but it would move the project as a whole in the direction of easier use. It's a sensible default that can be overridden when doing so would be beneficial. Overall, a good idea. XOR'easter (talk) 15:45, 24 April 2020 (UTC)
• Support I find the above oppose arguments unpersuasive. Daask (talk) 22:02, 24 April 2020 (UTC)
• Support - The less-informed reader (who doesn't know what means) will end up at a site where he/she/they can read the full article, and more-informed wonky folks will click on the doi link because it has the next to it. Everyone's happy ... which means we should all "... get up and dance to a song, that was a hit before your mother was born, though she was born a long long time ago, your mother should know ...." ♫   - Mark D Worthen PsyD (talk) (I'm a man—traditional male pronouns are fine.) 08:21, 25 April 2020 (UTC)
• Weak Oppose: I'm afraid I'm with matthiaspaul on this proposal; adding to the "sea of blue" might confuse readers, and that's not what we should be trying to do. Still, I see the benefits; but I wonder how this might affect, say, ProveIt, which I use... 18:26, 26 April 2020 (UTC)
I do not see how this could affect ProveIt in any way: it does not change the meaning of any template parameter, it does not add any new parameter, any syntax currently valid remains valid. − Pintoch (talk) 19:07, 26 April 2020 (UTC)
Maybe Josve05a can provide an opinion, as I've seen him active with all of ProveIt, OAbot, citation bot and a plethora of other gadgets. Nemo 19:12, 26 April 2020 (UTC)
Tools which uses the source (wikitext) to edit an article (such as ProveIt) would in no way be affected by this. This proposal is only regarding the layout/display of the cite template, not how the parameters should be added/work on a basic level. Jonatan Svensson Glad (talk) 19:25, 26 April 2020 (UTC)
• Support We want open-sourced references as much as possible, as to allow our readers to be able to verify as much information as possible for themselves if they wish. That's why we add references in the first place. Currently, we auto-link the title if a PMC is added since all such links are openly sourced. I don't see a reason why another identifier if marked as being open/freely accessible already, should not also auto-link the title. A sea of blue links might be a problem, but having all identifiers listed at the end is still a list of blue links and if we wish to give one of them more prominence, it should be a link which is open. Therefore, I can't see any issues with this proposal. Jonatan Svensson Glad (talk) 19:19, 26 April 2020 (UTC)
• Support I cross posted notice of this discussion to WikiProject Medicine. Wikipedia citations have already developed beyond anything in conventional academia so we are far beyond looking to anyone else's standards to do what we think is best. Our objective in Wikipedia is to provide readers with stable legal access to free versions of articles. This change helps us to accomplish that. Blue Rasberry (talk) 21:43, 26 April 2020 (UTC)
• Support This is my default way to indicate that links are free. Right now there are hacky ways around it, and citation bot will automatically remove a url that is identical to the doi-link to my annoyance. Not a big fan of {{oa}} and similar because they're ugly and distracting. 22:13, 26 April 2020 (UTC)
Note: If this proposal is implemented, the free access green hook should also be eliminated as redundant. 10:20, 20 May 2020 (UTC)
• Support this is the best indicator that more information is available.....no run around links is best.--Moxy 🍁 22:19, 26 April 2020 (UTC)
• Support Even among relatively sophisticated/educated readers, unless you spend time dealing with journal articles you probably don't know what doi/pmc/acronym soup means. In the absence of another blue link to click on you may try those links out, but standard web formatting is that the linked title takes you to the actual article being referenced. That in this case there's some arcane doi linkages happening doesn't change that for the average reader interested in checking a source article, the only thing the want or care about is a clear link to the article being cited, and the article title linking to that fully-readable journal article is the normal expectation, not having to guess what "doi" means. --PresN 03:25, 27 April 2020 (UTC)
• Comment In some instances such as
of an out-of-copyright paper the DOI points to a protected copy but a free access URL is legitimately available. Now, I understand this proposal would leave this reference alone but some of the remarks above suggest DOIs are inherently better than URLs and this is not always the case. We should be careful to avoid a BOT-like approach. Thincat (talk) 09:16, 27 April 2020 (UTC)
Yes, that's why it's proposed that the URL override be possible. PubMed Central also has a lot of public domain content, another reason to let PMC take precedence over the DOI. For instance an article contains this citation:
Nemo 12:08, 27 April 2020 (UTC)
This wouldn't replace any manually provided alternatives like the above. If the DOI doesn't link to a free-copy, no automatic link would be given. And if a free copy is "manually" provided, it would take precedence over the automatic links. Headbomb {t · c · p · b} 16:05, 27 April 2020 (UTC)
• Support – per nom and other supporters above. Levivich[dubiousdiscuss] 22:04, 27 April 2020 (UTC)
• Support per others above. It will help readers to have access to free sources, and is also helpful for more professional editors. Ahmadtalk 06:07, 28 April 2020 (UTC)
• Support. As someone who has made over a thousand edits to a scientific/medical article (deep vein thrombosis), I would like readers to have the simple benefit of clickable titles whenever there is a free and legal full-text version available for them to access. The reasoning of this proposal is straightforward and beneficial to readers, in my opinion. On the other hand, I am confused by some of the comments from the opposers. One says "as natural as clicking on an ISBN link". I, for one, as an editor and reader of Wikipedia, have no idea what one is to gain from clicking on ISBN links. I don't do that. I do, however, understand the simple logic that (at least on scientific articles) blue-linked titles = always free full text. One opposer claims "This proposal is fixing a problem that does not exist." But in my opinion, there is a simple problem that this proposal fixes. We do readers a favor by linking the free full-text on the title for PMCs. We should do the same for DOIs. Biosthmors (talk) 17:47, 30 April 2020 (UTC)
• Support Provides an easy (more) visual way to access the information. Redalert2fan (talk) 13:27, 2 May 2020 (UTC)
• Support. I have personally observed readers not realize that they needed to click on the DOI numbers because they have no idea what a DOI is (nor should they have to know). Clicking on a linked source title is the intuitive interaction. (not watching, please {{ping}}) czar 07:11, 3 May 2020 (UTC)
• Comment: Pintoch, the RfC initiator, requested closure at WP:ANRFC. RfCs usually last 30 days but can be closed earlier if WP:SNOW applies. The RfC has been open for 10 days. Do any editors object to a WP:SNOW close of the RfC? Cunard (talk) 09:22, 4 May 2020 (UTC)
• Oppose early closure. Instead, I would counter-suggest that presence of any autolinked url should be accompanied by removal of the lock icon, as redundant clutter. 98.0.246.242 (talk) 01:51, 6 May 2020 (UTC)
• Support. per nom, Czar, Headbomb and others. Thryduulf (talk) 09:32, 5 May 2020 (UTC)
• Support. Net benefit, clearly. Rehman 09:54, 5 May 2020 (UTC)
• Support. Agree that clicking on the title is far more intuitive than clicking on the identifier. the wub "?!" 16:02, 7 May 2020 (UTC)
• Support: readers are used to clicking on titles. The "sea of blue" argument is invalid, as there's quite often a second blue link for the publisher, author, or whatever, so having a blue doi will not harm the reader. PamD 11:45, 9 May 2020 (UTC)
• Support: one commentor above argues Clicking on it is as natural as clicking on an ISBN link. I quite agree. Like with ISBNs, clicking on DOIs is unnatural to layfolks and second practice to Wikipedians, who really struggle to internalise just how complex our website is to readers. To be fair, in academic contexts we can maybe assume more of our readers' knowledge, but it's still best to keep it as simple as possible. I support that proposal because it adjusts the templates to fit a general rule that almost all Wikipedia article citations follow: if the source is available online then it's linked through its title. — Bilorv (talk) 09:47, 10 May 2020 (UTC)
• Support Blue is good. GenQuest "Talk to Me" 11:00, 10 May 2020 (UTC)
• Strong suppport that free links should be highlighted. Encouraging access to free material is part of our basic purpose. DOI has the advantage of working across all fields, unlike PMC. The only significant question is how to deal with things if thee are multiple free links. In principle the publishers doi, not pmc is the version of record and should be theone presented in almost all cases, if it does indeed link to the full free text and not an abstract, , and also preferred to other repositories. But,f rom the librarians point of view, all possible links should be entered, as the way to handle disappearing links, but they need nor necessarily all be displayed. DGG ( talk ) 16:41, 13 May 2020 (UTC)
• Strong support! Per SandyGeorgia, Ocaasi and DGG. comrade waddie96 (talk) 09:05, 14 May 2020 (UTC)
• Support, but there needs to be a careful additional discussion of the priority order when multiple identifiers are present. For academic journal articles, there are many cases where doi's link to the publisher's website which has a restricted access version, but the author(s) have placed free-to-read copies at JSTOR, etc., because of their institution's policy on access to publications. At present, if you include a url that goes to JSTOR, it's usually removed in favour of using |jstor=, so over-riding via the URL doesn't work, unless this change is forbidden. The proposal seems to require that when there are multiple links, they must be marked as free access or not when access differs in order to choose the best. This information is far from universally present right now. Peter coxhead (talk) 09:30, 14 May 2020 (UTC)
• Oppose, redundant, adds to the "sea of blue", and insults the intelligence of our readers. Stop making assumptions about which link a reader would most likely follow. Boghog (talk) 09:55, 15 May 2020 (UTC)
• No need to make "assumptions", we have data: m:Research:Characterizing Wikipedia Citation Usage. Nemo 12:32, 15 May 2020 (UTC)
• An interesting analysis, but it answers a different question. The analysis concerns reader preferences for different types sources (scientific article, newspaper article, company webpage, blog, social media, etc.) I was referring to alternative links to the same underlying source (doi: the original source: pmid: an abstract of the source + related sources, pmc: an alternative full text source, etc.). Boghog (talk) 14:07, 15 May 2020 (UTC)
• Nope. Read closer. Nemo 15:43, 15 May 2020 (UTC)
• There is no mention anywhere in the analysis about different links to the same underlying citation. There are extensive "between source" comparisons on the same Wikipedia page in the preprint (i.e., RQ2 and RQ3), but no "within source" comparison where the click frequency of links within the same citation are compared. What is needed is a finer grain analysis on a per reference and not per page basis. Boghog (talk) 16:39, 15 May 2020 (UTC)
• The authors claim they found statistically significant correlations sufficient to conclude that certain kinds of links in references produce clicks more than others. For instance, ISBN appears to be clearly less clicked than average, other things equal. I still have some nitpicks myself about the data (more on the talk page over there) but we can no longer say we're in the blind about certain things. Nemo 17:14, 15 May 2020 (UTC)
• Support Seems a sensible proposal for journal articles. SportingFlyer T·C 08:05, 18 May 2020 (UTC)

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

## Automatically remove protection from a page when it is moved

When a protected page is moved, the old title stays protected and the protection settings are duplicated to the new page, so we've now got two indefinitely protected pages when we should only have one. Here's an example. This, in essence, is preemptively protecting the redirect against something it hasn't yet experienced, and there are hundreds of improperly protected redirects like this. I think it's important to recognise that these old titles rarely ever see edits ever again, unless of course they themselves get turned into articles (in which case the preemptive protection is even more of an issue).

We're wasting resources having double the amount of required pages protected and tracking categories are full of pages that shouldn't be there. A page like "Guns" has a reason to be indefinitely semi-protected but First Emperor of Qin doesn't, and yet they were both present in the database report and might have been in Category:Semi-protected redirects.

Additionally, and might be of concern, this software feature has an exploit in which a page can be protected without an admin. Here's an example:

1. An existing and protected page, such as User:Anarchyte/protected, is moved.
2. The new title, User:Anarchyte/protected2, is now protected, as is the old title User:Anarchyte/protected.
3. Someone who wants protection moves User:Anarchyte/protected to User:Anarchyte/protected3 and now we've got three indefinitely protected pages all because one page was protected. Note that protected3 was never directly related to protected2 (the original article).

I suggest the way protection works be modified so that the protection is automatically removed from the old page and given to the new page when it's moved, or at least there be an option to leave protection like there is to leave a redirect. If that were the case, the only protected page (in the example above) would be protected2. I'm not sure if this should be here or at technical, so let me know if this is the wrong avenue. Anarchyte (talkwork) 07:19, 7 May 2020 (UTC) Majorly edited (see original): 16:20, 7 May 2020 (UTC)

I think this would require a change in the software to implement, but the devs will reject that unless there is a consensus that the community wants the change. This seems a good place to discuss whether there is a desire for this.
Personally, I'm on the fence about this as there are times where leaving the redirect protected is desirable - page move vandalism, title disputes, and competing versions spring to mind as examples, but equally there are times when it probably isn't necessary. For temporarily protected pages - the protection expires at the same time on both new and old titles, so it's only an issue for pages that are moved while indefinitely protected - how often does that happen? My initial gut feeling is that if you find an indefinitely protected redirect that is protected only due to the move of a fully protected page and there is no obvious need for it to be protected, then just request unprotection. Thryduulf (talk) 09:01, 7 May 2020 (UTC)
Note that this was added in phab:T12527 after suggestions that the protection be preserved. There could be another alternative too like adding checkbox to specify whether you want the protection to remain or not. Not sure, but in some cases/or on some wikis, preservation of the protection might be needed or even required. – Ammarpad (talk) 09:20, 7 May 2020 (UTC)
I'm not sure this is a good idea. I'm unconvinced that the number of people scheming to gain protection on pages in the way that you're describing here is anywhere near the scale where this might be an issue - and why would it be, apart from anything else? Protection isn't some badge of quality to a page, au contraire it's a badge indicating that the page might be in danger of vandalism or other disruption. Meanwhile, although a small risk usually, there is sometimes a real and present risk that redirects to protected pages might end up being vandalised, especially if the vandalism to the protected page is so severe that it warrants permanent protection. As Thryduulf says quite rightly above, this issue seems to solve itself quite neatly by simply requesting unprotection where protection genuinely isn't needed. Naypta ☺ | ✉ talk page | 10:32, 7 May 2020 (UTC)
I'm struggling to think of any plausible example where the way this currently works is likely to cause a problem. Protection is applied to pages because there has been some disruptive editing, and surely that could continue at the old title as well as at the new title? Anarchyte, do you have any real-life example where there has been a problem? Was there any reason for anyone who couldn't edit the coronavirus page that you mentioned to be able to edit the redirect left behind by the move? Phil Bridger (talk) 11:47, 7 May 2020 (UTC)
Like Phil, I'm struggling to think of a problem that this addresses. It seems to be working the way we expect it to. However, the proposed change would create an odd situation. As a non-admin, I cannot protect or remove protection from pages; but as a page mover, I can move pages. Therefore, the effect of this would be to allow me to remove protection from pages. Hawkeye7 (discuss) 12:40, 7 May 2020 (UTC)
Sorry, I wasn't very clear in my opening message. I was somewhat rushed and didn't fully flesh out what I wanted to say. I'll make an edit to that above so that newcomers to the discussion understand what I'm actually trying to accomplish.
@Phil Bridger and Naypta: As we're now discussing the problem I've brought up, I think it's important to also discuss the protection policy. Protecting a page should be done to prevent vandalism or other disruption to the page at hand. When an admin, or at least myself, protects a page, they're protecting that one page. If it gets moved to a new title, the protection on the old title remains, meaning we've technically preemptively protected the page because there has been no harm done to the redirect yet. Redirects get a lot less page views than main articles and are often, or at least in comparison with their article counterparts, left alone by vandals because their work isn't going to be seen. There is no reason why in my example anything should be protected except protected2. The only page that has been "vandalised" is that, and User:Anarchyte/protected wasn't even considered when the protecting admin protected the page.
I definitely agree -- this is only going to be relevant for the edge case that an article is indefinitely protected and then moved. However, I've been running through all the semi-protected redirects as of late and I fail to see how retaining the protection on any of these (1, 2, 3, 4, 5, 6, 7, 8) is benefiting the encyclopedia (obviously it could be argued that leaving them protected also doesn't do any harm). If an article is experiencing page move vandalism, the article can get given sysop move protection. If that happens, we can't get any more moves anyway and so the issue is moot. Similarly, if there's a title dispute we can do the same thing (and perhaps fully protect the redirects temporarily so that they can't get overwritten by page movers).
@Hawkeye7: Yes, you could in essence move User:Anarchyte/protected elsewhere and then vandalise that page, but you need to be autoconfirmed before you can move a page so semi-protection is already irrelevant.
Cheers, Anarchyte (talkwork) 16:20, 7 May 2020 (UTC)
I wasn't thinking of someone like myself vandalising a page (which wouldn't happen), but of accidentally removing protection, which I wouldn't be warned had happened. I'm uncertain as to whether your proposed method of adding protection would work. You can't move a page over a redirect, so it would require non-existant pages to retain their protection. Hawkeye7 (discuss) 20:47, 7 May 2020 (UTC)
I understand the argument you're making, for sure; I just think it's an argument based on "policy says this might be a problem" rather than "this is actually a problem in reality", if that makes sense. I don't mean that as a slight against you in any way - it's certainly an interesting point, and I'd not thought about it before!

The point you raise about creating new articles over redirects that are accidentally protected is an especially good that I hadn't considered before at all - although, at the same time, I can't think off the top of my head of any examples where a protected page is moved from a prior location, and then at that prior location a new article is created. That's not to say it couldn't happen (or that it hasn't!), just that I can't think of what the circumstances might be.

I'd certainly not be opposed in any way to the introduction of a checkbox when moving for page movers allowing them the option of transferring the protection to the new redirect or not; however, I certainly don't think this ought to be a priority, and I do think it needs some further thought. For instance, if only page movers have the right, then what happens when a normal autoconfirmed user moves a page? Likewise, if not only they have the right, don't we still have the same issue?

The only way to get around this issue as a whole might end up being to restrict all protected page moves to page movers or administrators. I feel this might be one of those cases where yes, the current behaviour is weird, but alternative behaviour might potentially be even weirder without significant thought. Naypta ☺ | ✉ talk page | 16:32, 7 May 2020 (UTC)

I tend to agree with Naypta. If after a decade of the current behaviour there are less than 20 examples where the protection might not be appropriate this really isn't a high priority issue. A checkbox (that defaults to the current behaviour) wouldn't be a bad idea, just not a terribly urgent one. In the absence of that, it seems that the best thing to do would be to get a bot to maintain a list of all redirects created by moves of pages that are protected for longer than X time (1 week? 1 month? 3 months?), people can then look through that list and unprotect/request unprotection of any that don't need to be protected as they desire. It's not likely to be a very long list. Thryduulf (talk) 17:19, 7 May 2020 (UTC)
If there's a demand for such a thing, I'm happy to get a bot to do that set up. Naypta ☺ | ✉ talk page | 21:05, 7 May 2020 (UTC)
@Naypta: Late response but a database report of such pages would be greatly appreciated. There are hundreds of "improperly" protected pages. I'm running through the database report and most of the indef protected redirects in the last 5 years are because of moves. I'm working my way through the list. Anarchyte (talkwork) 06:55, 15 May 2020 (UTC)
Database report sorted for you! Returns any redirects in mainspace that were created after a page move which have any sort of indefinite protection. You can find the query here on Quarry, so feel free to run it again yourself every so often if you like. For convenience, though, I've put the list on a page in my userspace, too, with the relevant wikilinks in it. You can find that over here. Hope it helps - let me know if you need anything else! Naypta ☺ | ✉ talk page | 15:01, 16 May 2020 (UTC)
@Naypta: Thank you! I've forked the query and modified it so that the pages don't redirect. I've uploaded this new version to your userpage, but feel free to undo it if you'd prefer your version remain there. Anarchyte (talkwork) 15:38, 16 May 2020 (UTC)
No problem! Looks good to me - I didn't think of adding the noredirect param, good call :) Naypta ☺ | ✉ talk page | 16:01, 16 May 2020 (UTC)
@Anarchyte and Naypta: a link to the protection and move logs would be useful too. Knowing why the protection was originally applied gives a clue for what to look for to see if it is still needed, while the move log can also be useful to see whether the reason for moving is relevant to the protection. Thryduulf (talk) 22:43, 17 May 2020 (UTC)
your wish is my command - the list is updated! Naypta ☺ | ✉ talk page | 15:04, 18 May 2020 (UTC)
Thank you. Thryduulf (talk) 16:15, 18 May 2020 (UTC)
As with some others here, I'm less concerned about cluttering database reports than the potential for vandalism on redirects. Yes, redirects do seem to retain watchers (just checked at 2019–20 coronavirus pandemic), but still, there's some potential for subtler vandalism that could be disruptive. On the other side of the coin, I don't see us losing all that many positive contributions from this — redirects have some complexity to them, so I can't think of all that many scenarios in which I'd want to see an unconfirmed editor making changes to a redirect for a page that was protected at some point. I hope the database report that came out of this discussion is useful, but with regard to making potential changes, I just don't see the WP:BROKEN criterion being met. {{u|Sdkb}}talk 04:24, 21 May 2020 (UTC)

## Proposed: a massive automated invasion of privacy for the greater good

This is going to be a very controversial proposal, so here is my framing device.

Imagine that you managed a department store where shoplifting was rampant. There are cameras set up all over the store, recording everything that happens, so every act of shoplifting could theoretically be caught. However, you have a strict rule (in order to protect shopper privacy) that no security person will look at any of these cameras or any of their recorded footage unless a customer comes to complain of some observed or suspected instance of shoplifting. What if, however, instead of having a security person look at the cameras, you trained a bot to view the footage and flag actions that were likely instances of shoplifting, which the security people could then review?

I propose to apply a model like that to the problem of sockpuppetry. All the data needed to be reviewed to determine who is in fact engaged in sock puppetry is already stored in our servers, so why don't we set a bot to a task of reviewing all the edits that have been made over some reasonable period (perhaps some number of weeks), and then flag to the attention of the Checkusers a list all of the instances of probable sock puppetry in that period? To be clear, this proposed review would be carried out by a bot rather than a human, and would be done indiscriminately. The only information being reported for human eyes would be actual instances of likely sockpuppetry violations, and that information would only be reported to the Checkusers. BD2412 T 15:40, 7 May 2020 (UTC)

• No. This is not even good as satire. 50.74.165.202 (talk) 15:50, 7 May 2020 (UTC)
It is interesting, however, that the first opposition comes from an IP with a grand total of 14 edits. BD2412 T 16:21, 7 May 2020 (UTC)
• Let's say someone volunteered to run machine learning for sockpuppetry and it worked - what do you think it would tell us? SportingFlyer T·C 16:28, 7 May 2020 (UTC)
• I expect that it would tell us, for example, when one conflicted individual is trying to fool us into thinking that multiple editors independently support a position in a discussion. BD2412 T 17:10, 7 May 2020 (UTC)
• I guess the question I have is "why", really. Why do we need such a thing? I can see that it's something that's possible, but I'm not clear on what the advantage would be, apart from sockpuppeters being "more effectively punished", even if they aren't actually doing any harm. I know there's the argument that they're doing harm just by sockpuppeting, and I have a great deal of sympathy for that, but I don't think a punitive effect alone, rather than actually helping the encyclopedia in any way, would justify measures like this. Naypta ☺ | ✉ talk page | 16:37, 7 May 2020 (UTC)
• I'm actually not particularly concerned with "punishing" sockpuppetry, but we all know that there are plenty of instances where deletion discussions or content discussions for articles on companies, commercial products, celebrities, and the like are influenced by sockpuppet accounts appearing as independent editors. That sort of conduct should be stopped, even where the sockpuppeteers are successful in hiding their misconduct. BD2412 T 17:08, 7 May 2020 (UTC)
• To my mind, the far more obvious problem to address there in which case is the situations in which you feel !votes are being treated as votes for the purposes of establishing consensus. I can see it might lead to issues of false consensus, but I suspect those sorts of problems would reveal themselves fairly quickly, in the same way in which we deal with meatpuppetry. Naypta ☺ | ✉ talk page | 17:51, 7 May 2020 (UTC)
• There are discussions where reasonable arguments are being made on both sides, but where one side has strong numerical support. That is to say, there are instances where sockpuppetry, while not obvious or mindless, can turn the outcome of a discussion. BD2412 T 18:06, 7 May 2020 (UTC)
• I would suspect a bot like this would be incapable of telling an illegitimate sockpuppet from a valid one. Not to mention that if we are relying on data which is shielded per the priv-pol there's a not-inconsiderable risk of false positives from public terminals (not as much of an issue now but will become one once shelter-in-place and similar orders are lifted). —A little blue Bori v^_^v Onward to 2020 17:04, 7 May 2020 (UTC)
• There are activities that a valid sockpuppet should never be engaging in, like voting multiple times in an XfD process under different usernames, or having a back-and-forth with itself made to appear as if two unconnected editors were having that discussion. The parameters of a bot review can be tweaked to focus on instances of conduct like that. BD2412 T 17:12, 7 May 2020 (UTC)
• Transcluded to Wikipedia talk:CheckUser and Wikipedia talk:Sock puppetry. * Pppery * it has begun... 17:20, 7 May 2020 (UTC)
• Theres been talk by global CUs of using machine learning on a limited basis to look at the behaviour between accounts (not technical). I think this is fine and wouldn’t be a privacy violation anymore than the editor interaction utility. If we’re looking at publicly available data, academics are already using it in studies of abuse on Wikipedia. Not a big deal there. I’m not really sure a bot running on every account makes sense, though.
I would not support a bot or machine learning on CU data as that’s vague enough where anything the machine learning produces would likely be overwhelming and not useful. TonyBallioni (talk) 17:31, 7 May 2020 (UTC)
• This is a completely bizarre idea. And I don't know why a transclusion is necessary, Pppery a simple link on those other pages surely would have sufficed. But the IP^^^ makes a good point about satire. serial# 17:32, 7 May 2020 (UTC)
• BD2412, you seem to be assuming that one IP address equals one user. That's not always the case. Everyone in my house uses same router, so we share an IP address, but we each have our own accounts. If I attend an edit-a-thon, I share the same IP with all the other attendees. I don't think I should be investigated based on that "evidence". Vexations (talk) 17:36, 7 May 2020 (UTC)
• I have not doubt that there are instances that may look like sockpuppetry but have an innocent explanation. However, there are also instances that will look like sockpuppetry because they are in fact sockpuppetry, which would otherwise go unnoticed and allow Wikipedia to be spammed with commercial content or the like. BD2412 T 17:44, 7 May 2020 (UTC)
• Where does the "invasion of privacy" come in? If the proposal is to have a bot analyze edits to look for patterns, have at it, that involves no private data. If the proposal is to have the bot look at everyone's user agent and/or IP addresses and flag the overlaps, thats basically an automated checkuser-everyone, which will probably be a useless invasion of privacy, as it will just tell us, for example, which users are from the same university. I think some behavior probable cause should continue to be required, as it is now, for a CU to be run. Levivich[dubiousdiscuss] 17:41, 7 May 2020 (UTC)
• I had rather assumed that people would automatically consider this an invasion of some kind of privacy. What I am really interested in is finding instances where different registered accounts from the same IP address are participating in discussions or appearing to talk to each other, which is where suspicious should arise. BD2412 T 17:47, 7 May 2020 (UTC)
• @BD2412: I don’t mind sharing that some smaller version of the behavioural analysis that Levivich mentioned is being worked on by a CU on another project as a tool. People on non-English wikis (read: authoritarian regimes) were more concerned with the privacy aspect for understandable reasons. My argument is something along the lines of We literally already have researchers doing this. There’s absolutely nothing private here. It’s a decision aid to help focus resources, and would likely be likely to decrease use of CU and protect against false positives. I don’t see this as a privacy policy issue because as part of the nature of an open wiki, literally everything is public and people already have AI being run on their edits (see ORES). ST47 might have more to add. TonyBallioni (talk) 18:04, 7 May 2020 (UTC)
• @BD2412 and ST47: fix ping. TonyBallioni (talk) 18:04, 7 May 2020 (UTC)
• I would agree that if something along these lines is already being done, then there's no need for a proposal for it to be done. However, I had not previously heard of such an effort. BD2412 T 18:08, 7 May 2020 (UTC)
• Yeah, it’s very early stages but wouldn’t impact the privacy policy and would be focused on behaviour, not IPs. I don’t think it would be run automatically either. Basically the idea that’s been floated is to use a tool that looks at certain similarities to be a behavioural analysis tool that humans can then look at as a decision aid. Like I said, early stage, but the idea of using additional tools has been discussed. TonyBallioni (talk) 18:14, 7 May 2020 (UTC)
• I think this is a great idea. However, who is going to run the bot? We would also need to see the source code.--SharʿabSalam▼ (talk) 18:06, 7 May 2020 (UTC)
• @BD2412: What about the prosecutor's fallacy and the birthday paradox? There will be thousands of editors every day who by chance alone will have an IP+Useragent match with a completely unrelated user. And some of those, will, by chance, be participating in the same discussions. That's why  CheckUser is not for fishing. How would the bot distinguish socks from unlucky matches? Suffusion of Yellow (talk) 22:08, 7 May 2020 (UTC)
• [...]thousands of editors every day who by chance alone will have an IP+Useragent match this is actually much less common than it used to be, but sure, it happens. Usually exact IP+UA at the same time is the same person. It requires human judgement and we tend to be fairly conservative in blocking. The bigger issue would be on ranges, where you’d be overwhelmed easily and the data would be fairly useless unless you knew what you’re looking for. TonyBallioni (talk) 22:19, 7 May 2020 (UTC)
• To be fair, whilst it might be less common than it used to be for now, I strongly suspect it'll increase rapidly over the next few years as IPv4 address exhaustion forces more ISPs to implement carrier-grade NAT. It remains to be seen whether IPv6 adoption will continue at the same rate - I hope it does, but at least over here in the UK, very few ISPs currently support v6, and even fewer have it as a default. At the point at which CGNAT is the norm for residential networks, like how it presently is for many mobile data networks, that issue of multi-user IPs is going to become bigger. Naypta ☺ | ✉ talk page | 22:23, 7 May 2020 (UTC)
• Well, yeah, the UK is second only to Nepal in being the exception to my above statement :) TonyBallioni (talk) 22:26, 7 May 2020 (UTC)
• The Checkusers would be the ones to make that distinction. Actual suspect cases (matches of identity occurring on the same article or discussion) will likely be a small number—unless the problem itself is much bigger than anyone realizes. BD2412 T 22:22, 7 May 2020 (UTC)
• I will never support a proposal with a section title like that. Merits aside (this is an area I have no interest or knowledge in), you've poisoned the well for me, and I suspect I'm not alone. —⁠烏⁠Γ (kaw)  22:35, 07 May 2020 (UTC)
• As it turns out, the point is rather moot. BD2412 T 16:07, 10 May 2020 (UTC)
• What? —⁠烏⁠Γ (kaw)  00:23, 12 May 2020 (UTC)
• It might be easier to start with a narrower approach that could serve as a proof of concept. Maybe a bot that searches for the known characteristics of specific LTAs, if that doesn't already exist. Otherwise, maybe a bot that specifically checks XfDs, or even just XfDs in specific categories where sockpuppetry is likely to be common. Sunrise (talk) 15:57, 10 May 2020 (UTC)
• Would this be permissible under the various privacy regulations that the WMF may be subject to? If so, would the WMF need to re-write its privacy policy to reflect this additional processing of personal information? Also, I share the sentiments of User:KarasuGamma. Privacy is important, and I cannot support "a massive automated invasion of privacy." Thanks, Tony Tan · talk 04:24, 13 May 2020 (UTC)
• I agree with Suffusion of Yellow: what happened to WP:NOTFISHING? Double sharp (talk) 13:19, 17 May 2020 (UTC)
• With the caveat that sockpupetry isn't an area I'm very familiar with,that's exactly what a sockpuppet would say... I'm persuaded by BD2412 and the others arguing that this isn't that different from research. With the data already on our servers, I don't see how hiding it from ourselves by disallowing a bot to run in this way would preserve privacy. If those of you opposed can come up with a realistic example of a way this could go wrong in practice and end up violating someone's privacy in a way that meaningfully harms them, I might be persuaded, but currently I'm drawing a blank on that. There are clearly technical aspects to be worked out, and that could get complicated especially if the privacy policy ends up being involved, but overall, when we're looking at a tool that could deliver probable cases of sockpuppetry to highly trusted editors able to investigate them, WP:NOTFISHING seems like a less relevant piece of guidance than WP:SUICIDEPACT. {{u|Sdkb}}talk 04:50, 21 May 2020 (UTC)

## Adding images to all created article

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

@Tbiw: I'm afraid I'm not clear on what it is that you're proposing. Freely-licensed images that are found on Commons can already be used in articles whenever appropriate per the image use policy and the Manual of Style's guidelines on images. What changes are you looking for? Naypta ☺ | ✉ talk page | 11:29, 13 May 2020 (UTC)
See Wikipedia:Village pump (idea lab)/Archive 31#Adding images to all created article. Doug Weller talk 16:14, 13 May 2020 (UTC)
• Bad idea both as a tool, as a policy, and as a bot. See WP:CONTEXTBOT for why. Headbomb {t · c · p · b} 16:34, 13 May 2020 (UTC)
• There are several sets of articles that do not have images:
1. Those for which a suitable image is available but nobody has added yet. Please add these images to the article.
2. Those for which a suitable image is (potentially) available but is not on Commons (yet). Most articles about living people that do not have an image are in this set for example.
3. Those for which an image would be suitable but no such image is known to exist. For example most articles people that lived before the invention of photography.
4. Those articles for which an image does exist, but due to legal or policy reasons cannot be included on Wikipedia. For example images of copyrighted buildings in countries without freedom of panorama.
There are a small subset of articles where the restriction is not copyright but something else, for example we cannot legally include a freely licensed image of child pornography (assuming such an image exists, for obvious reasons I've not investigated).
5. Those articles for which no suitable image can exist. For example articles about abstract concepts such as Hermitian matrix or Li (Confucianism).
Your proposal only deals with the first set. Thryduulf (talk) 16:50, 13 May 2020 (UTC)
I don't understand why this discussion was moved here from Wikipedia:Village pump (idea lab)/Archive 31#Adding images to all created article. The responses there were that this is a bad idea, so why should the responses here be any different? Phil Bridger (talk) 18:01, 13 May 2020 (UTC)
despite this idea is going badly due to negative response. But let me further tell you about history during the olden days ways of communication were imagery and image gives expression,image tell us about history. Phil Bridger saying that there was no good response in idealab is no true one supported but told me about the problem that it may have and I am thinking of a way to solve. I won't stop this until the deal is done so i am still hearing the response I waiting for a strong positive response. Tbiw (talk) 20:15, 14 May 2020 (UTC)
That's not how Wikipedia works. Decisions on Wikipedia are based on consensus, if you refuse to listen to consensus you will end up getting blocked for disruption (this is not a threat, it is a statement of the facts of life). We all agree that images are important, and that articles that can be illustrated generally should be. However there are articles that cannot be meaningfully illustrated, as explained above and at the idea lab. Thryduulf (talk) 20:41, 14 May 2020 (UTC)
Please I don't want to get block due to this matter if you find a way to help quit this I will appreciate. Wikipedia is only may chance of getting engaged during the lockdown please don't block me Tbiw (talk) 21:06, 14 May 2020 (UTC)
It seems this idea as it stands is not supported. Why not spend your time changing your idea based on the feedback you've gotten instead of WP:IDHT? Limit the scope of articles based on subject or other criteria? Limit the scope of images considered? Think about and then explain very clearly how your idea will overcome the concerns others have raised? Or recognize that this idea just isn't viable right now, and spend your time directly finding images and adding them to articles yourself. DMacks (talk) 02:34, 21 May 2020 (UTC)
Okay DMacks thanks you have given me the courage again thanks. I will try my best again. Thank you
I have another plan like now one is creating an article one should have prepare the images ready and fix it. Even images suppose to be a strong element. I agree that in some times images are not the answer but inost cases images are the answer image is communication. In classes we do have chart and we used it to give more idea and sense to the topic. In some places many story we heard from them we there we saying we only see the images of computer but they don't see it in real. In image you do not need to really see those things now if we had image to an article in india and you are in USA you might not have the chance to visit the place,person but you have an idea. Image support an idea. Image is strong beauty I'd image. Commons should be only viewing of images it should also be very adequate use. Can someone just give me the ratio or percentage of image. So that I can know how to do more on that. Tbiw (talk) 11:42, 23 May 2020 (UTC)
• It's possible that this could be turned into a semi-automated process...eventually. So... ideally every article on Wikipedia should be linked to a Wikidata item, linked with the same article in every language, and eventually a large share of images on Commons should be identified with a depicts. So it is possible in theory to create a semi-automated tool to:
1. Identify articles that have no images
2. Identify which of those articles have matching depicts on Commons and/or
3. Identify which of those articles have corresponding articles in a different language that have images
The user can then be presented with a list of options for images based on these criteria. If the image is presented is selected from criteria #3, they can be also presented with the option to add the appropriate depicts on Commons if missing. However, depicts is fairly new, less than a year old IIRC. So it probably needs filled out more before such a tool could be truly useful, and it would probably be more useful for non-English projects using the English Wikipedia to mine images rather than visa versa, since en.wiki has the largest share of articles missing on other projects, just through sheer volume.
But the process still has to be human operated by someone with a thorough knowledge of image use policy and copyright. Have to keep in mind that there is a non-negligible amount of images on Commons that have been retained not because they have been thoroughly vetted for licensing, but because they have just been dropped into a pit of tens of millions of images and no one has vetted it at all. GMGtalk 11:59, 23 May 2020 (UTC)
This is largely the idea I suggested in the section immediately below, but using a bot rather than Wikidata depicts. Thryduulf (talk) 12:23, 23 May 2020 (UTC)
Ah I see. Great minds think alike (though likely poor minds thing alike also :P). It would be helpful to have an idea of what the reach here would be. I honestly couldn't tell what the "saturation rate" (for lack of a better term) would be for either method. It's also possible that current reach of depicts could be nearly useless once you have data in your hands, even if the raw numbers are high. So, for example, how many depicts are going to be for things like "hammer", "house", or "Harry Truman"... instances of very common subjects where there is no need for additional images.
Maybe User:Fuzheado knows enough to give a back-of-the-envelope guess at how useful something like this might be. GMGtalk 12:41, 23 May 2020 (UTC)
All ideas are great. I would encourage the use of a tool or bot for this job by telling it what to do like what greenmeansgo said about it . If we assign it to editors were might end up blaming ourselves. Inorder for that I really like greenmeansgo idea. It won't make us say we want to improve article and later cause disaster . All ideas are great . Tbiw (talk) 15:34, 23 May 2020 (UTC)

## Articles illustrated in other Wikipedias

Is there (or could there be) a list of articles that have no image here, but are interwiki linked to articles on another Wikipedia that do have an image, and that image is hosted on Commons? If so could a bot post a message to the talk page of the articles on the list noting this fact and including a thumbnail? The bot would not add images to articles, simply present suggestions for human editors to consider? Thryduulf (talk) 16:55, 13 May 2020 (UTC)

Now that seems like a viable proposal, unlike the one above. Let's have bots that help human editors, rather than try to make decisions themselves that may be bad. Phil Bridger (talk) 18:03, 13 May 2020 (UTC)
I agree with Phil. This sort of tagging would be very helpful. De728631 (talk) 18:17, 13 May 2020 (UTC)
Thirded on this idea. bibliomaniac15 18:22, 13 May 2020 (UTC)
This to my mind is a good idea, but I'm not sure how it'd be technically implemented. Having something simply iterate through all articles that are interwikied to another language, then looking at those articles, evaluating whether they contain images, and if they don't, iterating through every other language that article might be in (potentially many for some articles) performing the same check, strikes me as something that would take a long time and potentially use a lot of resources. And yes, I know, WP:DWAP, but even if the performance doesn't matter on the WMF end, it does for the person running the bot to some extent at least. But this is VPR, not VPT - we can get into that set of weeds later, I suppose! Naypta ☺ | ✉ talk page | 20:28, 13 May 2020 (UTC)
As a first step maybe just looking at those articles tagged as needing an image or which can be improved from an article in another language would be a smaller set. Given that popups tell me how many images an article has I'm guessing that either this is somehow stored in metadata or is very simple to calculate, however that only deals with the total number of images in an article not whether there is a lead image, e.g. the incidental image in Righteousness counts the same as the single primary image in Georgie Thompson. Maybe that means it need only look at the first section? I'm the wrong person to talk to about technical implementation though! Thryduulf (talk) 21:13, 13 May 2020 (UTC)
The popups value seems to be confused by some infobox/template spaghetti. For example, benzyl fluoride pops up as "Stub, 1.8kB, 8 wikiLinks, 0 images, 2 categories, 53 weeks old" but has three images in its infobox. The pg.re.image regexp in MediaWiki:Gadget-popups.js claims to process infoboxes, but clearly some infoboxes are quite complex. DMacks (talk) 05:19, 21 May 2020 (UTC)
I think the bot should tag the articles directly so that they can be automatically added into a category (namely, a newly created subcategory of Category:Wikipedia requested images). The bot should keep track of everything it tags, and never reinstate a tag if reverted (some articles have no images for a good reason). -- King of ♥ 22:09, 13 May 2020 (UTC)
Why would the bot be reverted? It's only editing talk pages, not articles. Either the suggestion would be ignored or it would be discussed and one of three things happen: the suggested image is added to the article (now out of scope for future runs); a different image is added to the article (now out of scope for future runs), or consensus would be against adding the image (in scope for a future run). In all cases the message would remain on the talk page. I agree the bot should not suggest the same image for the same article more than once (I was imagining this being tracked by its own log page or something) but suggesting a different image should not be a problem? The number of articles that are intentionally unillustrated on en.wp but are illustrated with a free image on another project must be so incredibly tiny that a category seems overkill - just exclude the bot from that specific page using {{nobots}}. The bot would need to be told not to suggest placeholder images if any wikis use those, but that is probably best just to just give it a list of file names never to suggest. In terms of frequency, the only reason why a page would get a second message would be if (a) no image has been added after the first one, and (b) a different free image has been added to another language edition of the article since the last run. That's not going to happen that often, even if the bot runs as frequently as weekly. Thryduulf (talk) 23:02, 13 May 2020 (UTC)
Ah never mind, for some reason I thought {{Image request}} was meant to be used on article pages, and just wanted us to do the same here. In that case yes, keep it on the talk page. Anyways, the main idea I wanted to get across is that the bot should be (via the template) adding those pages to a category so that Wikignomes can come in and help. The category needs to be distinct from Category:Wikipedia requested images, as the current task is far easier than obtaining a free image that we don't yet have. -- King of ♥ 23:56, 13 May 2020 (UTC)
Yes, making these pages easy to find is a good idea, maybe something like Category:Wikipedia articles with suggested images or something like that. Thryduulf (talk) 09:37, 14 May 2020 (UTC)

## New template to make Wikipedians more aware of proposals for new WikiProjects

I have a proposal which is intended to make more people aware of new WikiProject proposals. At Wikipedia: WikiProject Council, I have made a proposal for a WikiProject Mysticism, and there is also a proposal for a WikiProject Justin Bieber. If one goes to the article on mysticism, one can see that information about the relevant WikiProject proposal is on the talk page, and the same goes for the article on Justin Bieber. My proposal is that, when there are proposals for new WikiProjects at Wikipedia: WikiProject Council, there is a template heading the main article (not just the talk page) on the relevant subject, saying something to the effect of "A proposal has been made at Wikipedia: WikiProject Council for a WikiProject on...."" This might help people to become more aware of new WikiProject proposals. Vorbee (talk) 17:28, 13 May 2020 (UTC) At Wikipedia: WikiProject Council there are proposals for a WikiProject Hausa and WikiProject Brass Bands. If one goes to the articles Hausa people and Brass band, one will see that information on the proposals for these WikiProjects is not even on the talk pages. This, I feel, strengthens the case for such a template. Vorbee (talk) 19:48, 13 May 2020 (UTC)

This is a very good idea and I am in support of it if we enlighten people about wikipedia project we will get 98% of the wikipedia undone project done so let do it. Very great idea.Tbiw (talk) 08:10, 17 May 2020 (UTC)
Articles should only have banners pertaining to the content of that article, not information about Wikipedia's background processes. By all means put such proposals at the talk page of course. Fram (talk) 08:18, 18 May 2020 (UTC)
I agree with Fram. Banners on the article should be exclusively related to content matters that affect that article - e.g. issues with sourcing, proposals to merge or split, current nominations for deletion, {{current}} and the like. WikiProjects, GA/FA discussions, old discussions, mentions at ITN, and other process or meta issues belong on the talk page. Thryduulf (talk) 10:06, 18 May 2020 (UTC)
• Thank you for your feedback. I appreciate that Wikipedia may have a policy of only mentioning WikiProjects on the talk page, but does any one think that such a template could head the talk on the talk page of relevant articles? Vorbee (talk) 18:36, 18 May 2020 (UTC)
gibberish
Wiki project should be more advanced we on know that wikipedia project are grouped such as one for football is different and others. Article writing is about what you know,see and hear. Do when you send this template you gonna ask them I you willing to write an article then if yes choose which you wish to write. If may then leave it alone. When those who answered will be tagged voluteener of wiki project and the name or as we maintain a article grouply then let's write article groiply. To make more article archived. Tbiw (talk) 08:26, 19 May 2020 (UTC)

I had a look at the User Page of the User who left the last command, and see that English is that Wikipedian's native language - I did wonder about that, as the last comment was not written in very clear English. Vorbee (talk) 11:41, 22 May 2020 (UTC)

I guess what I am asking is how to make people aware of proposals for new WikiProjects at Wikipedia: WikiProject Council - there are probably many Wikipedians who have never seen that page on Wikipedia. Vorbee (talk) 11:41, 22 May 2020 (UTC)

Am very sorry for using not understandable language,errors and blunders,jargon which was tagged gibberish . Sorry all wikipedians for that mistake . It is a great mistake sorry for that . Tbiw (talk) 15:39, 23 May 2020 (UTC)
• The talk page of the relevant parent wikiproject (e.g. WP:WPMU) would be a more appropriate place for a notice about a proposed new wikiproject (than the talk page of a specific article). DexDor (talk) 19:13, 24 May 2020 (UTC)

## Two thoughts about notability

I work a lot on articles relating to history. Recently, I've been cleaning up some articles on people belonging to a family that flourished in Asia Minor of the 2nd century AD. After pruning away the cruft on two of them, I find there's not much there to save. (By "cruft", I mean some redundant & unsourced genealogical statements, & lots of flowery language.) For one, there is the assertion that he is a consul, but I have been up to my elbows in the sources for Roman consuls for quite a long time now (since 2018, at least), & I can't verify that claim with the reliable sources. Once pruned, the article will basically read "A is an aristocrat of the second century living in Perga. His parents are A & B." The other is about his sister-in-law, who is the daughter of a king & the wife of a Roman Senator; her husband is the subject of an article. There should be more information about her, but the records of the time rarely told us more than the names of women -- & often not even that. The first, IMHO, is a candidate for deletion or merging; most civic notables don't meet Notability standards, even if we had a list of offices for them -- & we don't for this guy. I'm mulling on nominating his article for deletion (or merging; either choice will result with the article being replaced with a redirect). As for the sister-in-law, I'm torn: she is someone, if we had access to more information, who might be Notable -- after all, she was in a situation where she could have influenced events. And we need more articles about women. (Her article might end up in AfD, regardless.) All of this leads to a couple of thoughts.

1. Should we adjust the standards of Notability to reflect the fact that the further back one goes in history, the less we know about people? In some cases, what would be a slam-dunk decision to include in our coverage ends up being a reluctant deletion because we just don't have anything to say about the person. If we allow this, then in theory we could have an article about an average peasant, otherwise unremarkable, simply on the basis he is the earliest person documented to have existed by contemporary records. (Right now, the earliest documented people are kings -- one of ancient Egypt, the other of Sumeria.)
2. If we do make adjustments based on historical distance back, should we also adjust based on sex? In most societies, there will be less information about women than men: few Roman women have left as much of an impression in history as Livia, Augustus' second wife, & even fewer Greek women. Sometimes we can piece together a sketch of a woman from various hints for those periods, but for most women all we will be able to provide is these 3 barren facts: the names of father (& sometimes mother), the name of her husband, & the names of her known children. (It's a depressing problem to face.)

My intent is not so much to change the Notability guidelines as to hopefully start a discussion about maybe changing them for these reasons. -- llywrch (talk) 19:27, 14 May 2020 (UTC)

• I would oppose adjusting the standards of notability for the further one goes back in history for the following reason. Wikipedia is probably biassed to things going on in the recent past (the article Criticism of Wikipedia mentions racist and sexist bias, but does not appear to mention recentist bias). There are probably many people in ancient history who are notable (think of characters from the Bible, or ancient Greek philosophers) and we should look at the notability of these people independently of how long ago they lived. The article Criticism of Wikipedia does mention that Wikipedia probably suffers from sexist bias, with not enough coverage of women's issues, so I would oppose adjusting notability guidelines for sex, too. Vorbee (talk) 19:39, 14 May 2020 (UTC)
• That the article Criticism of Wikipedia doesn't mention recentism as a problem is an omission in that article, not an absence of that problem. This bias has been mentioned before, although after spending an hour searching online this was the only article I could find on the topic. A simple yet effective way to see that this is a persistent problem is to watch the articles under "On This Day" on the Front Page: I am routinely disappointed at how it is dominated by articles on events after 1900. Not that I expect that events in ancient Rome or China should be given the same weight as to events since that year, but sometimes I wonder if the majority of Wikipedians inadvertently think World War I is half way to the deposition of Romulus Augustulus. History books are full of detailed events since 1500, if not centuries before, yet we fail to draw on any of them for OTD. (For example, I remember adding many years ago the date Dante first glimpsed Beatrice -- considered by more than a few a memorable literary event -- but has either person been mentioned at OTD for 1 May?) -- llywrch (talk) 17:51, 15 May 2020 (UTC)
• Thanks for starting this discussion. I think my problem with the idea is what it buys us as an encyclopedia. Let's say we loosen our notability requirements for ancient women; it seems that you suggest most of the new articles will top out at a few sentences. Wouldn't it be better to mention her in some larger article and redirect the title? Having an article in this situation doesn't really fix our bias unless the definition is simply "articles for men vs articles for women" which is a rather crude metric. We want article on women to not simply exist, but to cover the subject with the same quality and depth that articles on men receive. While the raw numbers are important, the best way to fix the gender bias is to not simply have articles on women, but articles on women that are reasonably well written and useful for the reader. As proposed, it seems like doing this for ancient subjects or ancient woman subjects seems like it will sacrifice one for the other.
I do sympathize with the proposal, and think that in general we should be more cognizant of how sourcing survives through the ages. For modern subjects, we don't often think about preservation of sources as showing evidence of people being noteworthy since we don't really have that time depth; it's creation of works about the subject that we use as a metric. For ancient subjects, creation is similarly important, but because of the time depth, someone has to actually care enough about the subject to preserve the information and so we should be receptive to that as evidence as well. As a pragmatic stance, I think it's worthwhile in these cases to consider the quality of the article in proportion to its available sourcing. If there's not enough extant sourcing to get us past a stub, then I don't think anyone benefits from it being a separate article, but if the subject has been treated well enough in the limited extant sources to write a C-ish class article, I think we should consider keeping despite the limited resources since humans through history found the individual interesting enough to create and preserve enough information to develop a reasonably well written article thousands of years later. 20:11, 14 May 2020 (UTC)
• Wugapodes, I think you capture the dilemma I felt when I wrote the above much better than I was able to express it: on the one hand, I want to work towards a balance in content & sometimes feel that the rules prevent me; yet on the other, I lack the information needed to achieve this balance. Sometimes a bit of imagination can be used to make up for lack of information. For example, I've been fiddling with another article, Plancia Magna, where the subject is arguably notable for her civic donations: I believe this article could be properly expanded into C class quality (if not into a Featured Article) by discussing how her philanthropy fits into the ancient practice of euergetism. (At least doing so this article would escape the fate of so many Wikipedia biographies of being carefully pasteurized essays that present only facts, while omitting any opinions let alone insights about the subject.) But to achieve this, we may need to move the dividing line of Notability. -- llywrch (talk) 17:51, 15 May 2020 (UTC)
• My interpretation of Notability is that we resolved the old inclusionist/exclusionists wars by declaring that it's not for us to decide - it is the world that decides what is Notable. The world Takes Note of something when Reliable Source write about it. Or job is to step back from the topic itself, our job is to evaluate whether the world has Taken Note sufficiently for us to summarize that Note into an encyclopedic article.
Regarding someone who died a thousand years ago, that means the world has had a thousand years to Take Note and write about them. If that hasn't happened, they're not Notable.
Regarding women, in a perfect world half of our biographies would be on women. Unfortunately we don't live in a perfect world. And we we can't fix the world. The best we can do is try to make a perfect encyclopedia. A perfect encyclopedia accurately reflects the world as it is, warts and all. The fact is, throughout the world and throughout history, women have rarely had equal opportunity to achieve or be Noted. We can document that accurately, but we can't fix it. If Wikipedia lacks an article on someone notable, woman or not, that article should be added.
To make the point more dramatically, it's like trying to fix Wikipedia by increasing the number of articles we have on Women U.S. Presidents. If we try to do that we'd be writing fiction. Only the world can do that.
As a person I support various social progress and improvement. As an editor, my policy-analysis shouldn't change to fit my personal opinions and desires. Alsee (talk) 11:46, 15 May 2020 (UTC)
• I tend to disagree with that. A perfect encyclopedia accuratelly reflects the world as it is. This is not necessary true, that is not the "perfect" encyclopedia, it is maybe an encyclopedia most useful for journalists and corporate employees. The perfect encyclopedia would be different and we COULD be creating it, we COULD have half of biografies on women. We COULD have more articles on eastern, soutern etc topics, we could do all that. But we would need better policies and we would have to take some responsibility. The current use of notability, OR and foremost RWG policies is just reproducing sexual, racial, class, systemic etc biases and is preventing use to create a perfect encyclopedia. And "the world" is just an exuse. Ludost Mlačani (talk) 21:24, 17 May 2020 (UTC)
• I strongly support adding some consideration of the age of a figure to the notability guidelines. It's always struck me as a misplaced emphasis on "rules" over "building a better encyclopaedia" when articles on minor historical figures get deleted for notability concerns. Notability has two main purposes. One, to place some limit on what we cover, and exclude insignificant, unencyclopaedic topics. But if verifiable information about an individual has survived for hundreds or thousands of years, even if it's only one or two facts, they are surely significant and worthy of encyclopaedic coverage. The second purpose is to ensure a minimum standard in how we cover a topic, i.e. to avoid articles that will never have the "breadth of coverage expected from an encyclopedia". But here I think "breadth" has to be judged relative to the topic. If all that is known about a historical figure can be summarised in a few sentences, then those few sentences can be satisfactorily encyclopaedic coverage. Even a stub saying just "Marius Panemus was a baker in Rome in 67 AD" will be helpful for many readers and can provide useful context for other articles. – Joe (talk) 12:31, 15 May 2020 (UTC)
• I agree. I get the impression that many of those who claim that the "breadth of coverage expected from an encyclopedia" is more than a sentence or two for anything except the most important topics have never seen an old-fashioned print encyclopedia. Most entries in such encyclopedias are very short, so why should Wikipedia be any different? Many people seem to judge rules to be more important than the simple question "would a comprehensive encyclopedia be expected to have an entry for this?" Phil Bridger (talk) 16:44, 15 May 2020 (UTC)Phil Bridger (talk) 16:41, 15 May 2020 (UTC)
• Joe Roe, you've touched on two issues I've noticed that have become more apparent since I started back in the Wikipedia Stone Age around 2002: (1) An increasing number of contributors have never seen, let alone read widely in, one of the universal encyclopedias that were common before the Internet took off. While some did have thoughtful & well-written articles, the majority of the content of them was not as well organized or as complete as what Wikipedia usually provides -- & I'm saying that while freely admitting much of Wikipedia still sucks. (2) The belief that the longer a Wikipedia article is, it must follow that it is better than a short article. (It is true in many cases longer is better because it means there is more information, but concisely-written articles always delivers more information in a more accessible form.) Sometimes all that one needs to know about a subject can & should be presented in a few sentences. -- llywrch (talk) 17:51, 15 May 2020 (UTC)
• I agree with others here regarding the quality over quantity of articles on women. For an ancient senator's wife—is it really even her article if she is defined entirely by her relationship to other (male) people? I also wonder if this can't also be applied to current "notables" whose only achievement is their pedigree. There was a discussion recently on inappropriate title-bombing for people who have never been given or even inherited an extant title, and several of the articles in question are completely devoid of information other than who their wife's great-grandfather was or whatever. I think it'd also ease the recency bias if we approached it from the other direction and were more discerning on what or who is due an encyclopedic article. JoelleJay (talk) 18:42, 20 May 2020 (UTC)
• I would generally suggest that permastubs that exist because precisely one line of information can be gleaned about a figure from the whole of the historical record should be merged into a list article of similar permastubs on people from the same region and era. BD2412 T 03:57, 21 May 2020 (UTC)
• I agree that if a historical figure meets some form of a notability guideline but there's little coverage on them, then we probably shouldn't dedicate a full length article to them. This can be difficult even for relatively recent characters, if they date back from a time before internet..., example: a WWI Brigadier-General; a post-WWII ship commander. A list (or inclusion in the article of a closely related person), such as User:BD2412 suggests, could be appropriate, especially for some of the more obscure figures. The overreaching criteria is of course WP:GNG - I'd argue that if there's very little coverage of them (read: nothing more than "they existed" or "they were the [relation] of [notable person]" (see also WP:INHERITED) then we should probably not include an article... RandomCanadian (talk / contribs) 16:43, 23 May 2020 (UTC)

This item has inspired me to air my current beef re notability. Since when is an article in the Australian Dictionary of Biography not deemed reasonable evidence of notability? I have recently had two articles on minor Australian explorers, supported by information from the ADB and other documents, rejected as “Not notable”. While this attitude remains a whole group of “second-tier” people who helped to open up this country and fill the often large gaps left by the well-known explorers will remain largely unknown. Downsize43 (talk) 03:34, 24 May 2020 (UTC)

• Out of curiosity, do you have a link to these articles? SportingFlyer T·C 07:57, 24 May 2020 (UTC)
I think that we can all agree that "notability" is a vague concept and that it has some (or many) failings... The main concern when creating articles should be whether there is sufficient coverage in sources which indicate that the topic in question is worthy of mention (beyond it simply existing). In short, WP:GNG, everything else is just "presumptions" which can be false. Sometimes, depending on the sources, this can require many, and sometimes one really solid source (such as, say, an entry in the ADB, or, in my currently preferred subject (hymns), an entry in an authoritative publication) is also plenty enough). RandomCanadian (talk / contribs) 04:22, 24 May 2020 (UTC)
• Just because a person isn't notable enough for a standalone article doesn't mean we can't include something about them in the encyclopaedia, especially in sourced list format. I also think notability is read a bit subjectively - in theory, a historical person's biography is less likely to be deleted than a BLP. SportingFlyer T·C 07:57, 24 May 2020 (UTC)
a side issue, but the Australian Dictionary of Biography explicitly includes articles about people whom they think not notable, but representative of ordinary people in their mileu. I can understand theit purpose, and do not necessarily disagree with it, but it doesn't match what we mean by notability . ". In it you will find concise, informative and fascinating descriptions of the lives of significant and representative persons in Australian history....The subjects come from all walks of life ... providing a cross-section of Australian society.....ADB prides itself on its blend of elitism and egalitarianism." [1] DGG ( talk ) 18:04, 26 May 2020 (UTC)

## Proposal: Bot for the current main-page-related vandalism

There's been a rapidly IP-hopping editor vandalizing the TFA and pages linked to it. See also two AN discussions, EFN discussion, and EFR discussion. I figure we should have a bot specifically watching for and reverting these edits. An edit filter (1050) has been tried, but I think a bot would catch a broader range of edits (that is, the LTA has proven to be pretty good at evading new edit filter rules as they come up). A user script would work but a bot would be available all hours of the day. They've also gone cross-project (e.g. enws) so this would function more like a "cross-project abusefilter" (pending local discussions, obviously). Getting approval here before the BRFA. Thoughts? Enterprisey (talk!) 01:07, 15 May 2020 (UTC)

Enterprisey, I think it's a great idea. Kevin (aka L235 · t · c) 02:46, 15 May 2020 (UTC)
Who would have access to the bot's "rules"? In order for this bot to be effective, it would have to (unlike ClueBot) edit war endlessly with users it thinks are the LTA. So if the bot is wrong, and you are asleep, who can fix that, without blocking the bot? Suffusion of Yellow (talk) 02:51, 15 May 2020 (UTC)
Just me, but I can share the source code with people who ask. It will indeed have to edit war endlessly, unless it's given permission to block IPs (which probably isn't that good of an idea). It'll have a shutoff page onwiki. Enterprisey (talk!) 03:12, 15 May 2020 (UTC)
How is a bot different from an edit filter, other than polluting the history? * Pppery * it has begun... 02:52, 15 May 2020 (UTC)
A bot can perform a much broader set of checks. An edit filter is just a word filter with extra steps. Further details are probably BEANS territory. Enterprisey (talk!) 03:13, 15 May 2020 (UTC)
• It's more worthwhile to protect TFA articles pre-emptively for a definite duration until this subsides. --qedk (t c) 18:35, 15 May 2020 (UTC)
Sounds fine to me. Enterprisey (talk!) 00:55, 17 May 2020 (UTC)
The problem I have is that it's not limited to the TFA; we've protected the TFA and the vandal moves to other pages linked from ITN, DYK, RD, etc. Protecting every main page article preemptively by bot would definitely work, but seems like too much maybe? I think the targeted approach would be better, but would be fine with either as long as we're stopping all of it. 01:44, 17 May 2020 (UTC)
The idea of semi-protecting the TFA is on the perennial ideas list, so there may be opposition to that. I have no strong feelings about it on way or the other, though. {{u|Sdkb}}talk 11:15, 17 May 2020 (UTC)
Now, there's actually a reason for that, hence my suggestion. I'm not a big fan of restricting pages tbh, but it's important to show that LTAs are not welcome. :) --qedk (t c) 04:42, 19 May 2020 (UTC)
There was a reason for it in 2018-19, and for a much more severe case of LTA vandalism than this. The community didn't approve of preemptively protecting pages then either, but we did it anyway (though we used PC, not semi). Fortunately better solutions were devised, and they can be used now too. Most of you have access to the edit filter mailing list, I suggest we communicate there rather than spell out our plans here in the open. 16:39, 20 May 2020 (UTC)

### Another idea

Adminbot to apply 6-hour semi (or maybe even an edit filter) to articles linked from the main page with at least three rapid reverts by non-confirmed editors (numbers subject to debate), because if an admin's not around we end up getting a ton of reverts. We could also do this with a user script and click-to-confirm on the actions described above, which I assume would be much less controversial. CC Wugapodes. Enterprisey (talk!) 07:34, 17 May 2020 (UTC)

What about a bot that just tags/untags pages with {{linked from main page}}? An edit filter would prevent anyone other than the bot or an admin from adding or removing the template. Then edit filters could be built that only check MP-linked pages, which would vastly reduce FPs. Suffusion of Yellow (talk) 23:07, 18 May 2020 (UTC)
User:MusikBot/TFATagger (which could be expanded for all pages linked on the Main Page). There's a better solution, though. We've been through this sort of thing before, Zzuuzz remembers. Let's discuss on the edit filter mailing list. There was a report about this issue there earlier today, I'll reply to that with my ideas. 00:40, 19 May 2020 (UTC)
That's a good idea imo. --qedk (t c) 04:40, 19 May 2020 (UTC)

### The best solution

If anything is to avoid this person to go unblocked for 30 minutes[2][3], and leaving the page unprotected. What's the point of warning these IPs and reporting them for edit-warring. They have been doing this since April 20, this is blatant vandalism and not a content dispute. I have already requested the deletion of several of these cross-wiki edits; at first they are denied because it's childish vandalism with no legitimate reason to be deleted. Then, they are spammed and only after that problem persists, they are deleted. That happened with Wikidata:Connie Glynn and Wikivoyage:London, which once again has undeleted vandalism. Just stop playing games with this person, they want attention and you are giving it to them. © Tbhotch (en-3). 21:55, 18 May 2020 (UTC)

You will never fill these gaps in RCP. If nothing else is working then the best solution is to take it out of the hands of the recent changes patrollers, and the gaps in patrolling, and place it the hands of an adminbot - blocking or protection or both. I am interested in what Enterprisey might be able to rustle up. also pinging MA -- zzuuzz (talk) 22:28, 18 May 2020 (UTC)
Maybe we need to better communicate to the RCP crowd that LTAs can be reported to AIV on sight. I don't know why, but some people, who are clearly aware of the LTA, always start at level 1 each time they come back with a new IP. Suffusion of Yellow (talk) 22:55, 18 May 2020 (UTC)

I don't know how many of you here are admins, but if you look through my suppression log you will see plenty of evidence, including their character substitutions. User:MusikAnimal, I just blocked another one of those loser IPs. I placed one rangeblock earlier. Drmies (talk) 00:54, 20 May 2020 (UTC)

Hmm, admins can't see suppression logs though. :/ --qedk (t c) 08:16, 20 May 2020 (UTC)
I don't know if there's some reluctance to this but if this is a case of WP:DFTT as User:Tbhotch suggests, then maybe simply having an adminbot protect the daily TFA for the duration (either Pending Changes or SP, pending changes seemed to work pretty fine at Peresvet) would be the most simple solution. RandomCanadian (talk / contribs) 04:59, 21 May 2020 (UTC)

(for the others who might be watching, see also yesterday's drama-free discussion at the Dramaboard) Is there any change in the situation since yesterday? The vandal seems able find what is the next TFA without our help so I'm pointing out that it's Paul E. Patton, in case those interested haven't put it on watchlist yet. I've had a glance at other linked pages but don't notice anything suspicious either so I guess this will be another case of wait and see... RandomCanadian (talk / contribs) 23:06, 25 May 2020 (UTC)

• The solution is what it has always been. Semi-protect TFA articles starting 12 hrs before they go live on the main page until a few hours after they drop off the page. The main page is itself indefinitely protected for good reason. This should be seen simply as a less extreme and temporary extension of that. But for some reason the wisdom of this recourse has not commended itself to the broader community. -Ad Orientem (talk) 23:13, 25 May 2020 (UTC)
I for one would certainly not object to that, since it seems to be a far simpler solution than having a bot which would require some form of constant updates because of an evolving opponent... RandomCanadian (talk / contribs) 23:22, 25 May 2020 (UTC)
The filter log is already abuzz with quite a few attempts though so far it has worked out (at the risk of catching a few false positives, which in this case is probably not a major issue given the potential). Cheers, RandomCanadian (talk / contribs) 00:59, 26 May 2020 (UTC)
Perhaps we should have a more formal proposal/RfC and consider that. As I think about it, there seems to be a solid case from WP:READER that it's more important to try to ensure readers have a vandalism-free experience reading the TFA than it is to recruit potential new editors via the TFA. It might even be for the best for recruiting — a recently vetted FA is definitely not the best place to make your first edit, and is probably fairly likely to lead to you getting reverted and bitten. {{u|Sdkb}}talk 04:09, 26 May 2020 (UTC)
@Sdkb: Regarding "new editors" - another heavily edited but protected articles (Talk:COVID-19 pandemic) has a nice notice encouraging new editors to try their hand at editing at a less difficult place. Do you think we could come up with something satisfying for TFAs? RandomCanadian (talk / contribs) 04:20, 26 May 2020 (UTC)
If you're referring to the talk page notice there, that was my doing, so glad you appreciate it :). Yeah, I think that's a good idea — something like "this page is protected to prevent vandalism, BUT you can edit here instead." Where would you want the notice to appear? If the page is semi-protected, it'd have no "edit" button for unconfirmed editors, just a view source button. Perhaps we should table this, since it'll only be necessary if the policy is changed. But changes to Template:Protected page text (the notice that appears when you try to edit a page you don't have permission to) would certainly be welcome. {{u|Sdkb}}talk 04:37, 26 May 2020 (UTC)
I would have suggested the talk page but the edit notice is also a very good place. It could also be a custom edit-notice specifically for TFAs (if we want to be precise and helpful), but the eventually updated default template could also do. RandomCanadian (talk / contribs) 04:44, 26 May 2020 (UTC)

### Make a bot autoblock users who hit the filter

I think that would be a good idea for a bot to autoblock any users who hit the TFA targeted vandalism #2 filter 🌸 1.Ayana 🌸 (talk) 23:26, 26 May 2020 (UTC)

There have been a few false positives (see the filter and edit history of the last TFA...), this might not be the best course of action. Maybe if the user hits the filter multiple times, then yes. RandomCanadian (talk / contribs) 23:36, 26 May 2020 (UTC)
Extension:AbuseFilter is capable of automatically blocking editors based on filter hits. This functionality is disabled on the English Wikipedia, and for good reason. Wikipedia talk:Edit filter/Archive 1 provides some of the background there, but it basically comes down to human judgement and discretion. Some situations may be better dealt with by a warning, a short block, or a long/indef block, but the abuse filter does not have the ability to make that decision. --AntiCompositeNumber (talk) 00:07, 27 May 2020 (UTC)
This certainly could be revisited, but using the native filter blocking action would be my preference over someone running an adminbot for this. — xaosflux Talk 16:23, 27 May 2020 (UTC)
I was not aware the abuse filter could block editors but i suppose we would need a RFC before enabling it and the false positives are a possible issue as with any filter not sure a RFC is a good idea for just 1 filter to change software so i guess either a adminbot or just regular blocking is better 🌸 1.Ayana 🌸 (talk) 20:12, 27 May 2020 (UTC)
As this problem caused me to learn about the edit filters, I kept wishing that the block feature wasn't disabled. Now that I've actually had to deal with false positives and getting the filter right, it's harder to stomach allowing edit filters to block editors without human discretion. It would be an interesting discussion to have again, but I doubt it would be successful. 00:33, 28 May 2020 (UTC)

## Template: Current etc

Yeah, I think I agree that this should be closed at this point. From what I can see, the consensus is that this template is useful. The relevant bot also has a bot request hanging out for resurrection. --Izno (talk) 20:23, 21 May 2020 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

What is the point of Template:Current, Template:Recent death etc? Two rationales are given:

• those extraordinary occasions that many editors (perhaps a hundred or more) edit an article on the same day, for example, in the case of natural disasters or other breaking news; cases where many editors (perhaps dozens or more) are editing the article on the same day.
• The latest updates to this article may not reflect the most current information.

These two rationales are contradictory: the more edits that are being made, the more likely the article is to be current, generally speaking. And why warn readers that an article is being heavily edited? Anyone who gets into an edit conflict will know they are in an edit conflict. It would be more logical to tag pages that are inactive.--Jack Upland (talk) 01:01, 17 May 2020 (UTC)

As a reader, I always took it as a signal that the article is undergoing rapid churn. If I wait 30 seconds and refresh, it is likely to have changed. I like knowing that. Schazjmd (talk) 01:05, 17 May 2020 (UTC)
But this template doesn't accomplish that. It's not automated.--Jack Upland (talk) 01:13, 17 May 2020 (UTC)
• It lets the reader know how stable an article is. Most people don't expect pages to change rapidly, so it's important that they may not be viewing the same version as their friends. 01:46, 17 May 2020 (UTC)
No, it doesn't. If there was an automated function that told you the page was experiencing a high number of edits, that would be true. But if you go to a page that is subject to a breaking news story, then you should know that anyway. In any case, WP:NOTNEWS. No, this tag is placed on a page by an editor and remains there until another editor removes it (and may be subsequently reinserted). It does not tell you how "unstable" an page is at all. In any case, the template says nothing about instability.--Jack Upland (talk) 06:31, 17 May 2020 (UTC)
WP:NOTNEWS is for disqualifying content that is breaking/primarily sourced WP:OR and for disqualifying articles on routine events, especially recent routine events. It doesn't mean notable information on an already notable person/event/thing can't be updated quickly after it happens using reliable secondary sources. These templates simply guide readers to let them the information on the page may not be correct or updated - i.e., the topic is "unstable," not that the page itself is receiving lots of edits. It's also not impossible Wikipedia could inadvertently "break" the news to someone, for instance in a case of a recent death. It functions similarly to how other warning templates tell readers the article is unsourced, unverified, overly promotional, et cetera. SportingFlyer T·C 08:02, 18 May 2020 (UTC)
• When it comes to issues like this, I'm firmly on the side of WP:READER. We should be using {{Current}} and the like only when it's necessary to convey something about the quality or character of information in the article, not as a general "hey, this is a recent event" tag. You all may want to check out Template talk:Current, where I've recently been speaking into the void about issues in this general realm (the only real discussion lately has been COVID-related, where a bunch of inappropriate uses have been approved). But did you all know, for instance, that there used to be a CurrentPruneBot that automatically removed the template whenever an article went unedited for more than two hours? {{u|Sdkb}}talk 11:04, 17 May 2020 (UTC)
Update: I've made a BOTREQ to revive the prunebot. {{u|Sdkb}}talk 08:55, 19 May 2020 (UTC)
Used according to the guidelines in the template doc, it serves the purpose it was designed for. The fact that so many editors use it incorrectly is insufficient reason to get rid of it. When I remove one, I always link directly to Template:Current#Guidelines in my editsum, which serves two purposes. It decreases the likelihood of a revert, and it increases awareness of correct usage, to whatever extent editors who are interested in learning click the link and read the clear and concise information written there. I don't recall having a removal disputed when I've done that. ―Mandruss  11:41, 17 May 2020 (UTC)
But Mandruss, what is the purpose it was designed for?--Jack Upland (talk) 01:50, 18 May 2020 (UTC)
• The latest updates to this article may not reflect the most current information. — several times a news is out, but it take several hours to get a clear idea about the background. It may be a celebrity's mysterious death. It might be an ongoing problematic calamity. For a short span of time, newspapers and other sources also contradict. There are 2 options, a) put all information you get on an article, b) wait a little, judge, assess reliability, and then add. Also more importantly, Wikipedia is not a primary source. We don't have journalists on the ground chasing a cyclone. We can write about something only when a other secondary/primary reliable sources right about it. So, in comparison to those sources and the most current information, we are a bit late. Now, you might ask why don't we put the template in other/news-type articles? Well, that is in the guidelines and Mandruss and others have explained that part. About Recent death also, if it is a normal (non-mysterious death) and details are already clear we don't need a notice on an article. Concluding: the template is a) for readers firstly and informs some content may rapidly change as we get more reliable information, b) for editors as well, suggesting to be more-swift/vigilant while editing (updating article, article history, talk page, watchlist and so on), --Titodutta (talk) 02:52, 18 May 2020 (UTC)
No, no one has explained it. No one has dealt with the contradiction I pointed out in my original post. With regard to your other points, mysteries are not confined to current events. We still don't know what happened to Lord Lucan. And contradictions in sources are not confined to current events either. We have contradictory sources about the birth year of Kim Jong-un. These are just things we have to live with. We don't need a template. The fuss about celebrity deaths is just silly. It is a near certainty they are dead. In some cases the cause of death will be debated for some time, as with Elvis Presley.--Jack Upland (talk) 03:12, 18 May 2020 (UTC)
You seem to be the only person who doesn't understand this, as those questions have been answered. But to try again, celebrity deaths are nothing special - any death of a person or any other event where the news is breaking and things are rapidly changing are within scope - information can become outdated very quickly as the real-world situation changes, or there might be important omissions or discrepancies as the article takes time to edit. As just one example, if someone who has a long biography dies unexpectedly it can take quite a while for the tense to be updated, expectations for ongoing projects revised - and those details will often not be known by anyone, let alone reported in a reliable source. The template alerts readers that the article is not stable and that what it says right now may or may not be correct because things in the real world have changed and are continuing to change. Rightly or wrongly people look at Wikipedia for information about breaking news events, these templates inform the reader that the article may change rapidly. This is very different to situations like Kim Jong-Un or Lord Lucan where, although there are contradictions and unknowns they are stable, long term contradictions and unknowns that can be (and are) discussed in the prose with reference to reliable sources about these contradictions and unknowns. Compare the editing history of a biography around the time of an unexpected sudden death with the editing history of Kim Jong-Un - if you cannot see the immediately see the difference then I don't think you will ever be able to understand the purpose or utility of these templates. Thryduulf (talk) 07:46, 18 May 2020 (UTC)
What an illogical response! We have established that many people don't understand the point of the templates. Read the discussion above! If you are concerned about pages being "unstable" - whatever that means - then change the template to say: THIS PAGE IS UNSTABLE. There is no need for anything else.--Jack Upland (talk) 09:44, 18 May 2020 (UTC)
As far as I can see, everybody except you is saying the exact same thing - they're just using different words to try and help you understand. Not everybody uses the template appropriately, true, but that's very much not the same thing as not understanding what it means, and mostly it's just differences of opinion about the threshold. Thryduulf (talk) 09:59, 18 May 2020 (UTC)
As compared to merely THIS PAGE IS UNSTABLE, it would be more informative to say "Information may change rapidly as the event progresses, and initial news reports may be unreliable. The latest updates to this article may not reflect the most current information." As it happens, that's what it says. Sorry if that's an illogical response, it's the best my muddled mind can produce. ―Mandruss  10:34, 18 May 2020 (UTC)
The reality seems to be that this template is a sacred cow with no practical use. Its worshippers provide inconsistent explanations for it use because they worship it.--Jack Upland (talk) 18:39, 18 May 2020 (UTC)
I'm starting to wonder whether you're actually unable to understand what people are saying or whether you are just trolling? I hope it's the former. Thryduulf (talk) 20:16, 18 May 2020 (UTC)

An example of why this template is a good thing: Once, I killed Gabrielle Giffords. I stand by that edit - sources were reporting it. But the template is useful to show that, hey, what you're getting here is being changed every second, and what you're looking at may be already out of date or even outright wrong. Having the template does zero harm to readers and to editors; omitting it can give the impression to those less familiar with Wikipedia that they're viewing an authoritative snapshot of fact. --Golbez (talk) 20:35, 18 May 2020 (UTC)

@Golbez: That incident will forever remind me of this scene from The Newsroom. Genuinely beautiful, and a reminder of just how important those calls are. (Not in any way meant as criticism towards you - it just reminded me of the scene!) Naypta ☺ | ✉ talk page | 21:16, 18 May 2020 (UTC)
Think the template is a good idea but this should be standardized....we have a few examples of badly used current templates like {{Current COVID-19 Project Consensus}} that lists non consensus and talks involving a few editors about non-contentious points.--Moxy 🍁 20:49, 18 May 2020 (UTC)
Ironically, they say they are using current templates on "less-trafficked" pages.--Jack Upland (talk) 23:53, 18 May 2020 (UTC)
The WP:NODISCLAIMERS guideline is relevant here. {{u|Sdkb}}talk 08:42, 19 May 2020 (UTC)
Notably the false information about Giffords only remained on the page for 11 minutes. We were wrong about Pluto for years. Is the fact that it is a "current event" really relevant?--Jack Upland (talk) 06:28, 21 May 2020 (UTC)
I don't see were WP was wrong on Pluto: this old revision from 2006 (and that's just an arbitrary one) clearly has it as a dwarf planet... Regarding WP:NODISCLAIMERS, the template here discussed is listed explicitly as "an exception", and I agree with that because I think that there are plenty of cases where it's use would be justified (as described by others). Simply because some people misuse it is not a good reason to... do something about them? It's not even clear what User:Jack Upland wants, anyways. RandomCanadian (talk / contribs) 16:54, 21 May 2020 (UTC)
I think it is clear the current template and the associated templates should be scrapped. The Disclaimer clearly covers it. Obviously the current template is a sacred cow with many acolytes who will die in a ditch to defend its bovine holiness. That is a pity.--Jack Upland (talk) 18:01, 21 May 2020 (UTC)
Well, "Obviously the current template is a sacred cow with many acolytes who will die in a ditch to defend its bovine holiness" sounds a lot like you have some form of grudge with it – and so far I see no evidence of a silly situation of the WP:BATTLEFIELD type... Are you sure that's really what meant to say? As I mentioned, entirely scrapping it simply because some editors use it excessively/inappropriately seems to be a very literal example of using a sledgehammer to crack a nut... RandomCanadian (talk / contribs) 18:24, 21 May 2020 (UTC)
I never said it should be scrapped because people misuse it. I think it should be scrapped because it's pointless. (And, by the way, Wikipedia was wrong about Pluto: its page originally called it a planet, not a dwarf planet!)--Jack Upland (talk) 19:23, 21 May 2020 (UTC)
Now you have confirmed, if it wasn't obvious before, that you are just making stuff up rather than trying to hold a rational discussion. Pluto was classed as a planet until 2006, so Wikipedia correctly described it as such, and was then downgraded to a dwarf planet, when Wikipedia correctly changed its description. I would suggest that you get your head around such simple things before offering your opinion on more complicated matters. Someone please close this as a case of either WP:CIR or trolling. Phil Bridger (talk) 19:35, 21 May 2020 (UTC)
False. If Pluto is a dwarf planet, it always was a dwarf planet. Was Gabrielle Giffords really dead because CNN said she was? I fear you are trapped in a logical fallacy.--Jack Upland (talk) 19:41, 21 May 2020 (UTC)
No, she was dead because I said she was. --Golbez (talk) 20:15, 21 May 2020 (UTC)
Fair point. According to the rules of Wikipedia, she was clearly dead and the assertion she was alive would be OR. Therefore the template is wrong, because Wikipedia can't be wrong, any more than the scientific consensus can be wrong. Like Schrodinger's Cat, she was alive or dead depending on the editor.--Jack Upland (talk) 20:20, 21 May 2020 (UTC)
Depending on the edit. Until I was reverted, she was dead. Then she wasn't. Easy to understand. --Golbez (talk) 20:21, 21 May 2020 (UTC)

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

## "Gentler" versions of CSD notices

Dear all, I believe that some CSD notices are a bit all-too-hostile towards new editors, and seeing a good faith creation with a big red deletion notice just puts off new users. There are some CSDs that could be used n good-faith edits:

1. WP:G1
2. some types of WP:G6
3. WP:G7
4. some types of WP:G8
5. WP:G13
6. WP:G14
7. WP:A2
8. WP:A10
9. WP:U1

IMO I believe that it is undesirable for a "big fat red" notice that may deter users, particularly for WP:G7/WP:U1.

Hence I suggest making the notices more user-retaining, as I am working on at User:Eumat114/lab/new CSD notices. May I please have some input? Thx Eumat114 formerly TLOM (Message) 03:40, 19 May 2020 (UTC)

I'm not seeing any new versions at your userpage yet, but this seems like a reasonable idea overall. {{u|Sdkb}}talk 08:34, 19 May 2020 (UTC)
Sdkb, this is a work in progress and it naturally takes weeks to complete it, given that I'm on a semi-wikibreak. Eumat114 formerly TLOM (Message) 09:28, 19 May 2020 (UTC)
This makes perfect sense, and I'd be happy to take a look further on, but make more sense for VPI (with a line dropped to CSD) in the interim Nosebagbear (talk) 14:49, 19 May 2020 (UTC)
Nosebagbear, thanks. I'm going to work on the templates in my userspace and come back when something appears. Anyone is welcome to work here. Eumat114 formerly TLOM (Message) 03:11, 20 May 2020 (UTC)
I hate to be a killjoy, but I don't think that the notices are the problem; it's our practice of speedy deletion that "deters" newbies. I don't think making the notices happy and friendly will have a material impact on newbies; rather, if we want to improve things here, we might encourage, say, replacing some speedy deletions with moves to the draft or user namespaces. A scary notice for a scary process is appropriate. {{Nihiltres |talk |edits}} 17:40, 20 May 2020 (UTC)
I don't think deleting per G7 or A10 should be particularly scary. The big red notices are what worries me the most. When I was a newbie, I got slightly intimidated by these notices, less so by the deletion process. Eumat114 formerly TLOM (Message) 04:04, 21 May 2020 (UTC)
When I was an IP, someone tagged an article I was creating to CSD G2 (test page), and I was freaked out! because I was working hard on the article! It was not a test page! I remember thinking that that article... how could it be deleted before being published? The article, List of nicknamed tropical cyclones, is proof that we need to give these IPs/newbies a chance to make their draft better. Guide them to the Teahouse, some Wikipedia policies on sourcing, notability, etc. This is one of the worst cases of WP:BITE there is. Please do not bite the newcomers, 🐔Chicdat ChickenDatabase 10:15, 22 May 2020 (UTC)
That's why Wikipedia:Why I Hate Speedy Deleters exists, to discourage bad CSD nominators. Eumat114 formerly TLOM (Message) 14:14, 22 May 2020 (UTC)

## Bring back database reports/long pages

Hi. My name is Chicdat. I've barely been on Wikipedia for three months, but several of my proposals became something (Wikipedia talk:WikiProject Tropical cyclones/Archive 40#Redirect-quality and List-class, Talk:1893 San Roque hurricane#Move, and Talk:Pacific typhoon season#Move?), so listen to this one: I would like to bring back Wikipedia:Database reports/Long pages. 🐔Chicdat ChickenDatabase 10:45, 22 May 2020 (UTC)

There is Special:LongPages which is updated live and might be useful. However it only shows pages in the Article namespace, phab:T156583 is a request to get it working for other namespaces too. the wub "?!" 14:30, 22 May 2020 (UTC)

## Populate medical resources in disease articles with information from curated sources

Wikipedia is a valuable source of textual data in many areas, including disease understanding. In order to interoperate Wikipedia with other sources (Electronic Health Records, Biological databases, etc), disease articles must contain disease codes (aka medical resource). Currently many articles about disease contain either few or no medial resources, which hinders interoperatibility. My proposal is to use curated mapping sources to automatically populate the medical resources of disease articles in Wikipedia.Eduardo P. García del Valle (talk) 14:31, 23 May 2020 (UTC)

This sounds like an idea to discuss with WikiProject Medicine. Taking Coronavirus disease 2019 as an example, I see we already do list:
ICD-10: U07.1, U07.2 MeSH: C000657245 SNOMED CT: 840539006
Those values are easy to parse and taken from Wikidata. I have no idea how easy it is to look up a value in Wikidata (which links to the Wikipedia article), rather than having to start from a known topic-name to find the Wikidata entry. DMacks (talk) 14:45, 23 May 2020 (UTC)
I agree WikiData is a good source for disease codes. In many cases, it's more complete than the corresponding Wikipedia equivalent. However, WikiData is still incomplete. For instance,azotemia is missing the SNOMED CT code 445009001. Thus, it's necessary to consume other curated sources of mappings. --Eduardo P. García del Valle (talk) 22:06, 28 May 2020 (UTC)

## Partial block – moving pages

Special:Block allows administrators to block users from (1) Editing, (2) Account creation, (3) Sending email, and (4) Editing their own talk page. Should a fifth option, Moving pages, be added to the menu?

This would force the pagemove-blocked editor to request all moves at a venue such as WP:Requested moves, where at least one editor would review their request to ensure that it wasn't potentially controversial. Potentially controversial requests should be discussed, generally for at least one week, at WP:Requested moves, to ensure there is a consensus before implementation. Some editors seem unwilling or unable to recognize potentially controversial requests in advance, and have developed a track record for making controversial moves that often are reverted. The proposed pagemove-block would ensure anther set of eyes on their moves in order to minimize disruption. – wbm1058 (talk) 18:14, 24 May 2020 (UTC)

• Support the idea generally, especially after having just gone through an ANI thread about this that went nowhere. An option like this would have made things simpler probably. But is this option already available in MediaWiki and merely requires enabling, or would the devs have to add it first? Also, it might be a little easy to game by using WP:RMTR instead. Should a page move blocked user be blocked from editing that page as well? Etc. –Deacon Vorbis (carbon • videos) 18:24, 24 May 2020 (UTC)
• Support Disruptive page moves require admin cleanup afterwards (unlike regular vandalism which can be dealt with by any so-inclined user); and if a user were to engage in such inappropriate behaviour repeatedly this would be a good option. If you think that someone could attempt to game the system, it could also be a possibility to enforce requirements for a full RM discussion on article talk page (and if this is not respected, an additional partial block of WP:RM#TR could be enforced, though that would probably mean the editor in question is not showing signs of improvement...). RandomCanadian (talk / contribs) 18:43, 24 May 2020 (UTC)
Disruptive page moves require admin cleanup afterwards How is that the case? As long as no one has edited the redirect left behind from the move, then any autoconfirmed editor can revert the page move, and admin action is only necessary if the user moved a page to a title that isn't an implausible redirect. * Pppery * it has begun... 19:02, 24 May 2020 (UTC)
Moving a page is not always that simple. For long-term embedded titles, cleaning up after the move can be a lot of work. If that work then needs to be reversed, the "executive" making that bold move just wasted a lot of the gnomes' time. – wbm1058 (talk) 22:01, 24 May 2020 (UTC)
And if it was a multi-move of many pages that changed a longstanding naming convention, multiply that cleanup by the number of pages that were moved en masse. wbm1058 (talk) 22:06, 24 May 2020 (UTC)
• Sure, so long as it doesn't require a ton of work to implement. There might be some policy concerns about when this would be appropriate, but as a technical matter, it's a tool administrators ought to have available to them. {{u|Sdkb}}talk 06:27, 26 May 2020 (UTC)
• Support Why not, seems like it could be useful —pythoncoder (talk | contribs) 16:36, 28 May 2020 (UTC)
• @Wbm1058: this is already on the list of things to work on, see phab:T194529 - I don't expect it will would require a "community approval" to make it available to local administrators once it gets implemented. (Locally it would be up to us to determine if any policies/procedures/etc need to be adjusted). — xaosflux Talk 19:39, 28 May 2020 (UTC)
• Support definitely. --TheSandDoctor Talk 02:11, 29 May 2020 (UTC)
• FYI --DannyS712 (talk) 02:19, 29 May 2020 (UTC)
Thanks for the heads up, DannyS712! -- NKohli (WMF) (talk) 21:50, 29 May 2020 (UTC)
• Support as some editors have this as their main problem. Graeme Bartlett (talk) 05:05, 29 May 2020 (UTC)
• Extremely Strong Support... There's a type of editing restriction called a pagemove ban, as we all know, but it is technically still possible for the user to move a page. This would make it impossible. 🐔Chicdat ChickenDatabase 12:44, 29 May 2020 (UTC)
If someone violates a ban, they should be blocked. Do we need a new mechanism? Dicklyon (talk) 16:47, 29 May 2020 (UTC)
This allows blocking them from the area they are not productive in while potentially keeping helpful edits elsewhere. Cheers, RandomCanadian (talk / contribs) 16:49, 29 May 2020 (UTC)
• Support, as long as it is reasonably practicable to implement. · · · Peter Southwood (talk): 17:45, 29 May 2020 (UTC)
• Note Local "voting" on this is unlikely necessary, this is already a requested software update and I don't imagine it will only be made available to projects to vote for it. You can express support by commenting here: phab:T194529. The only thing we need locally would be guidance for admins on when to use or not use this feature, and local documentation. — xaosflux Talk 18:05, 29 May 2020 (UTC)
• It is useful to learn whether this is modification is something that would add value. So, I appreciate the users leaving support for the change. Sydney Poore/FloNight♥♥♥♥ 22:19, 29 May 2020 (UTC)
• Comment I will note that this will probably only block the move action but the user can still perform workarounds like manual wikitext copy/paste under a new title. There's a deeper explanation about this limitation on the phabricator ticket. Thanks for opening up this discussion, Wbm1058. -- NKohli (WMF) (talk) 22:36, 29 May 2020 (UTC)

## Partial block – editing rate

Special:Block allows administrators to block users from editing:

Sitewide, or
Partial (specific pages or namespaces).

Should a third option,  Editing rate (per minute) be added to the menu? This option would allow blocking administrators to specify a restricted, pedestrian edit rate (say between 1 and 6 edits per minute) to mitigate disruption caused by unapproved high-speed editing.

High-speed editing should get prior approval via the WP:Bots/Requests for approval (BRFA) process, where (semi-)automated editing projects are scrutinized by other editors before full implementation, for better quality control. Editors repeatedly failing in quality control of their high-speed editing could have their editing rates restricted until their BRFA was approved.

Technically this should be possible. The backend operators can already restrict bots' editing rates as needed to stop denial-of-service attacks. When this option is activated for a specific editor, the software would simply check the editor's recent history and deny the edit if more than the specified number of edits have already been made within the past minute. – wbm1058 (talk) 13:16, 25 May 2020 (UTC)

This can already be implemented using the Edit Filter, but it may still be a good idea to implement it less hackily using partial blocks. * Pppery * it has begun... 13:58, 25 May 2020 (UTC)
The notion of rate limiting a specific person kind of makes me feel 'meh'. Truly disruptive fast-editors can simply be blocked, which leaves the good faith more or less, whose attention can usually be caught with a "stop editing" 1minute/hour/day block. That leaves the outliers like the discussion I'm sure triggered this one, and for those this is still an edge case remedy. I wouldn't oppose a task hanging out in Phab for it, but I also don't think paid developer time should be spent on it. --Izno (talk) 17:06, 25 May 2020 (UTC)
Don't really see the point either. There aren't many people who run unapproved bots and blocking people who run them is a more reasonable response than just slowing down the bot's edit rate. And that's assuming the person is actually being constructive, anyone who's running a vandalbot should just be blocked indefinitely. Hut 8.5 18:11, 25 May 2020 (UTC)

I feel it would be relatively useful if bursts were allowed and tailored to permission levels. I.e. something like

• IP/Non-autoconfirmed, no more than 30 edits in 10 minutes [3EPM average].
• Autoconfirmed, no more than 60 edits in 10 minutes [6 EPM average].
• Extended-confirmed no more than 100 edits in 10 minutes [10 EPM average].
• Highly-trusted users [Template editors, admins, bots] [∞ EPM / unrestricted]

Headbomb {t · c · p · b} 19:01, 26 May 2020 (UTC)

Setting edit restrictions to all user groups doesn't require the edit filter; it's a simple configuration change * Pppery * it has begun... 19:23, 26 May 2020 (UTC)
I don't see the point of this. Making a lot of edits rapidly can be the result of various things, good faith (anti-vandalism with some of the semi-automated tools, for example) or bad faith. As per User:Hut8.5, it's much simpler to simply ban vandalbots (especially since slowing them down doesn't stop the vandalism, blocking them is what does the trick)... RandomCanadian (talk / contribs) 21:26, 26 May 2020 (UTC)
• Technically-unenforced rate limiting has been tried before as a remedy for users whose edits were problematic but not vandalism. Examples I am aware of are MZMcBride (ping) Betacommand (AKA user:Δ) and Rich Farmbrough (ping). Although in Rich's case no specific figure appears to have been set that I can find, 4 edits per minute was applied to Δ and 12 per minute to MZMcBride. All of these cases are years old though (2009-2012, although later actions/enforcement may have happened), I have a feeling it has been tried more recently but apparently not as an arbitration remedy and a more general search is swamped by bot requests. Thryduulf (talk) 08:32, 27 May 2020 (UTC)
This is where myth comes from, but thanks for the ping. I have never been rate limited over and above the general guidelines (there's a back-off bit that's signalled to bot accounts for example, I don't remember the details). I think I was asked to slow down once, which I did. The now defunct ArbCom rulings were never related to speed (or accuracy), only to characteristics which are indeterminable. All the best: Rich Farmbrough 16:34, 27 May 2020 (UTC).
• Why? We shouldn't be scared of using block if someone is causing disruption. I could only see this as possibly useful for IP's (i.e. a registered user that can't follow community standards can just be shut down until they can be constructive). As far as IP's go - how would you want to enforce this, during the attempt to get an edit token, during the save process (spoiling the edit), sending them to CAPTCHA, something else? — xaosflux Talk 14:24, 27 May 2020 (UTC)
• @Headbomb: regarding your list above, being a template editor shouldn't mean you get to flood watchlists and recent changes. Bots have the ability to flag edits as bot to avoid this, and admins do for when they have a bulk rollback activity. — xaosflux Talk 14:27, 27 May 2020 (UTC)
There's many types of "watchlist flooding" that can be done with AWB that really isn't problematic (usually in category space, or various cleanup/checkwiki tasks). I'd trust template editors to be able to handle that sort of thing without needing to go through an RFA. Headbomb {t · c · p · b} 14:42, 27 May 2020 (UTC)
Maybe you don't consider it as such, by I consider flooding watchlists with minor cleanups to be problematic for sure. — xaosflux Talk 15:59, 27 May 2020 (UTC)
Depends on the details of the task. I know I never had any pushback on anything I did in category space, either because barely anyone watches these pages, or because I'm clueful, and probably a combination of both. Point is, template-editors are a small (~184) generally clueful bunch, and they aren't the ones causing issues with high edit rates. Imposing limits on them that they don't currently have would serve little purpose. Headbomb {t · c · p · b} 16:08, 27 May 2020 (UTC)
Clueful and lucky, I would say. And having "bomb" in your name probably stops people from trying to jump you in dark wiki-alley. All the best: Rich Farmbrough 16:44, 27 May 2020 (UTC).
• I can see why this is being suggested, but beware of the potential sideeffects. Aside from losing good edits of people improving the pedia, this would give editors an incentive to opt out of issuing optional warnings to other editors, or for example of maintaining a CSD noination log. Three CSD tags in one minute would be uncontentious if you just templated the three articles, but if you set your Twinkle options to inform the creator and log the tag it would be 9 edits in one minute. ϢereSpielChequers 14:32, 27 May 2020 (UTC)
Exactly my point... RandomCanadian (talk / contribs) 16:33, 27 May 2020 (UTC)
I'm not too sure about these tools. I get templated every week and 95% of the time the page is either kept or I {{g7}} it. So in 19 out of 20 cases an unnecessary discussion is started, where had they simply notified me and followed up if it wasn't deleted much community time could have been saved. Scale this up across the project, and there may be "more damage than harm". All the best: Rich Farmbrough 16:48, 27 May 2020 (UTC).
• I can see this being useful in certain situations where a standard block is rejected by the community. Giving more options to the community to handle unique situations is a good thing as long as the community dictates how and when it is used. Nihlus 16:11, 27 May 2020 (UTC)
• I can see some not-so-obvious benefits. For example rate limiting a blocked user to 1 edit per day would allow then to express themselves on their talk page, but require them to think carefully about what they write. Useful for the type that tends to spam unblock requests, for example. It might be useful to temporarily restrict nationality and genre warriors to give a period when they can edit, but not effectively edit war. I'm not sure if we have the skills as a community to use such a tool wisely, but you never know. All the best: Rich Farmbrough 16:40, 27 May 2020 (UTC).
In that case I am willing to reconsider what I said above. However, it should not be based on user permission levels, but rather used as other tools only with accounts which have proven to be problematic (much like partial blocks or topic bans). Cheers, RandomCanadian (talk / contribs) 02:03, 28 May 2020 (UTC)
• I think the possible use of this would be fairly limited unless we gained the ability to pair up rate limits and certain pages (which would allow nuanced restrictions usually refused due to difficulty in enforcement). However, that sounds like it would be significant Dev work, and I'm reticent to ask for that when it's not particularly needed. Nosebagbear (talk) 09:11, 28 May 2020 (UTC)

## Proposal: Placing a set of different references all under the same title

Would anyone here be prepared to actually make this possible to do? I'll try and show you what I mean:

[ref] Cite web, url=1, url=2, url=3, title=same, work/website=1, work/website=2, work/website=3, accessdate=1, accessdate=2, accessdate=3 [/ref]

The same title for multiple citations. If all citations were accessed on the same date, then obviously you would just use one access date for all citations. Make sense? The reason I'm suggesting this is because it can provide additional verification to both references and a particular source of information. I asked this at the Teahouse and was ultimately referred here by AlanM1. Does anyone else see the same value in creating a template like this? — 29cwcst (talk) 01:10, 28 May 2020 (UTC)