Article snapshot taken from[REDACTED] with creative commons attribution-sharealike license.
Give it a read and then ask your questions in the chat.
We can research this topic together.
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 Misplaced Pages. 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.
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)
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)
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. ~ ONUnicornproblem solving17: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)
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)
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. --Jayron3217: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 - 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 ♫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 Misplaced Pages:Local Embassy, where the WMF sends its diplomats and negotiators into English Misplaced Pages 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)
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 (talk • contribs) 09:18, 6 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 Misplaced Pages:Local Embassy ("Misplaced Pages-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. Misplaced Pages 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 Misplaced Pages 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. --Jayron3212: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:
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.
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.
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.)
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 Misplaced Pages 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 https://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 https://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 , 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.”
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:Misplaced Pages: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 Misplaced Pages'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)
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 and four different tutorials. Following a survey of Misplaced Pages'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:
Welcome!
Hi ! I noticed your contributions and wanted to welcome you to the Misplaced Pages community. I hope you like it here and decide to stay.
As you get started, you may find this short tutorial helpful:
: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)
@Bri.public: 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 Misplaced Pages. 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 Misplaced Pages. 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. — Wug·a·po·des 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)
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 Misplaced Pages. .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 Misplaced Pages (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 Misplaced Pages: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 Misplaced Pages, 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. ϢereSpielChequers08: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. — Wug·a·po·des 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)
@From Hill To Shore: 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 Misplaced Pages:Tutorial vs v:WikiJournal_User_Group for a flexbox equivalent for tabs). T.Shafee(Evo&Evo)05:31, 26 February 2020 (UTC)
@Evolution and evolvability: 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)
@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 Misplaced Pages concluded that:
Overall, these results support our findings from other tests: Welcome messages that are relatively short, to the point, and which contain only a few important links are more effective at encouraging new editors to get involved in the project. Our recommendation is to change the default German welcome template to the short version.
Back at English Misplaced Pages, 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)
@Nick Moyes: 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-Mo19: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 Misplaced Pages and duplicated that at info at Misplaced Pages: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 Misplaced Pages: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 Misplaced Pages. 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)
@Jonesey95: 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)
@Jonesey95: 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:
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. –ToxiBoi!02:06, 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 Misplaced Pages talk:Misplaced Pages 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 Misplaced Pages 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)
@Whisperjanes: 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 Misplaced Pages page and interactive Misplaced Pages 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 Misplaced Pages, 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 Misplaced Pages:Contributing to Misplaced Pages (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 Misplaced Pages: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 Misplaced Pages 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 Misplaced Pages, 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)
Hello, Example, and welcome to Misplaced Pages! 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!
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)
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)
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 discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Note: For anyone just jumping into the conversation, some of the proposals look to me to be ready to close, with SNOW in some cases. If you are an experienced editor and feel confident assessing consensus (not just counting !votes), please feel free to make some closes. {{u|Sdkb}} 23:58, 20 April 2020 (UTC)
Grant Template Editors and Mass Message Senders the editcontentmodel right
Pages on the wiki can contain different kinds of content such as wikitext, JavaScript, and CSS. The software handles these different kinds of content using content models which allow technical pages to look and be edited differently than our articles and talk pages. It also includes the ability to create mailing lists for mass messages and newsletters. Changing a page's content model is currently restricted to administrators. There was some debate about this in a 2016 VPProp discussion.
Rationale
Mass message senders use mailing lists which are implemented as a special content model in the software. Creating these lists requires editcontentmodel. Granting this right to mass message senders by default will make their job easier and reduce the (admittedly small) administrative overhead.
Template editors work with CSS pages as part of template styles. editcontentmodel will allow them to fix the occasional error where the software misrecognizes the page content.
The level of trust and technical ability required to edit template protected pages is similar to the trust and technical ability required to change content models. Many template editors have other technical projects that utilize content models such as CSS, JSON, and JavaScript, and the ability to change content models may be useful as they go about editing.
This is an intentionally limited proposal. The risk of disruption is not trivial, but imo not much worse than the disruption a rogue page mover would cause with that permission. The 2016 discussion touched on how liberally we should grant this user right, and while there was some support for groups like extendedconfirmed, such a wide grant is likely to be controversial. The two groups, mass message sender and template editor, strike me as the groups most likely to actually find the permission useful and so the most viable place to start from.
Question IIRC, some pages with a JS or CSS content model are in some way "protected" (in order to prevent users without Interface Admin from creating CSS or JS code that would be served to other users, a security vulnerability). Would the "editcontentmodel" right allow these users to "protect" pages by changing the content model to CSS/JS, or to "unprotect" CSS or JS pages in other users' userspace? ST47 (talk) 02:41, 21 April 2020 (UTC)
@ST47: w/r/t the security concerns, I tested this out and it seems that taking those actions requires interface administrator privileges. At User:Wugapodes/editcontentmodeltest I was able to change the content model, but when logged out I was not able to edit it. Logged into this account, I was unable to change a page in WugBot's userspace to JavaScript and it returned an error that this action required interface admin privileges. W/r/t being able to protect pages, it seems that this is not possible. At Misplaced Pages:Sandbox/Wugapodes/editcontentmodeltest I was able to successfully change the content model to JavaScript and I could edit the page while logged out despite the change in content model. My best conclusion is that changing content models respects the "edituserjs" and "editusercss" permission levels which are restricted to interface admins, but Xaosflux may know more. — Wug·a·po·des 03:35, 21 April 2020 (UTC)
I've done some research, and it seems that:
You can't change the content model of a page that you can't edit, so you can't "unprotect" someone else's user JS and then modify it.
Even if you change the content model of a "normal" page to something like JS or CSS, it doesn't gain any protection unless it's either a subpage in User: namespace, or any page in MediaWiki: namespace.
So, I don't have any security concerns, though obviously a dev should confirm that this is "okay". We have 60 Mass Message Senders and 175 Template Editors, they seem to be relatively well controlled permissions (though I see one fellow who is checkuser-blocked on the list of Template Editors...). Since it's low risk, I'm willing to say Support, if only because the current process of Xaosflux creating empty lists at titles like Misplaced Pages talk:Mass message senders/Shell-0057 so that non-admin mass message senders can move them to a real title is a silly workflow that makes me sad. ST47 (talk) 05:15, 21 April 2020 (UTC)
@ST47: empty lists would still be useful, because anyone can use a list - and we normally expect that someone has experience managing a list and making good requests for messages before we let them do the sending part themselves first. — xaosflux16:13, 21 April 2020 (UTC)
Oppose for MMS, in favor of fixing the workflow instead as requested at phab:T92795 (basically, they should be allowed to create the lists because they are a MMS - not as a side affect of ECM) and the bar for entry for this is not really about using this technical ability. Weak support for TE as that group is normally vetted fairly well and people that are trusted to update modules are generally trustworthy and competent enough to not break things with ECM. — xaosflux11:17, 21 April 2020 (UTC)
Support for template editors. Sane, sensible proposal. Template editors are trusted and as the OP says, many of them deal with other technical stuff on Misplaced Pages such as JS/JSON where the ability to switch content models would also be useful. Neutral for MMS. SD0001 (talk) 15:54, 21 April 2020 (UTC)
Support for template editors. As explained above, they may need it when working with templatestyles, and they are trusted enough for having this tool. I'm not sure about Mass Message Senders. Perhaps it should be granted to them until phab:T92795 is resolved? Ahmad05:29, 22 April 2020 (UTC)
Support for template editors per nom. Unsure for MMS, so no !vote yet from me on that. {{u|Sdkb}} 10:55, 22 April 2020 (UTC)
Support for template editors: it's a no-brainer for that group. For mass message senders, I'm on the fence; fixing the workflow is a better solution, but temporarily adding the privilege might be a good compromise—the catch of course being that removing it later might be awkward. {{Nihiltres |talk |edits}} 16:05, 22 April 2020 (UTC)
Support ish... for content models, but there's a few security concerns with content models that I'm loath to get into for WP:BEANS reasons. Oppose MMS.Headbomb {t · c · p · b} 16:13, 22 April 2020 (UTC)
Support permanently for template editors and temporarily for mass message senders (until phab:T248294 is completed). Both have a viable use-case for it and the risk of misuse that would damage the project (ie serious and not easily reversed) is reasonably low in my opinion. If and when phab:T248294 is completed, the right should be removed from mass message senders (which can be part of the close here). Callanecc (talk • contribs • logs) 06:01, 26 April 2020 (UTC)
Oppose for MMS: for those who don't know, we have had a well-functioning workaround for a while, where MMSers (and others) who want to create new mailing lists can move a "mailing list shell" from Wikipedia_talk:Mass_message_senders#Mass-mail_subscription_list_shells to wherever they need. To date, 64 have been used (since the content model was created on enwiki four years ago), so I'm not sure that we need to grant this permission to the MMS group. 64 is around one per current MMS group member, so I really don't think this is much of a problem for them. I'm ambivalent towards this for TEs, but consensus seems to be leaning that way. Best, Kevin (aka L235·t·c) 00:49, 30 April 2020 (UTC)
Support for Template Editors, per above, there is an obvious need. Neutral/no opinion with regards to the mass message flag. -FASTILY04:55, 30 April 2020 (UTC)
Support for template editors, oppose for MMS - Template editors are essentially required to know how to code, which means they are more prepared to go into and edit these content models. However, mass message senders don't need 'wikicoding' experience to get their role, which means they could be given a responsibility they are not prepared for (and I'm not going to list potential consequences of that due to reverse psychology). Kirbanzo 18:08, 1 May 2020 (UTC)
Support for template editors as there is a need for this right in the group. Neutral on whether this right should be given to MMS. Dreamy Jazz12:42, 7 May 2020 (UTC)
Support both, we can always remove for mass message senders if/when the underlying technical issues are fixed. the wub"?!"15:58, 7 May 2020 (UTC)
Auto-linking titles in citations of works with free-to-read DOIs
When discussion has ended, remove this tag and it will be removed from the lists. If this page is on additional lists, they will be noted below.
I propose to change the behaviour of the CS1/2 citation templates: the auto-linking mechanism (which provides a default value for |url= when |pmc= is available) would also cover |doi= with |doi-access=free.
In short: if |url=, |chapter-url= and |pmc= are not set, but |doi= and |doi-access=free are set, the title of the citation would be linked using the DOI.
Example
With the following code:
{{cite journal |author1= Hoffman S.J. |author2=Lavis J.N. |author3=Bennett S. | year = 2009 | title = The Use of Research Evidence in Two International Organizations' Recommendations about Health Systems | journal = Healthcare Policy | volume = 5 | issue = 1| pages = 66–86 | doi = 10.12927/hcpol.2009.21005 | doi-access = free }}
As a reader, it is natural to click on the title of a citation to access it. Clicking on identifiers is less intuitive, even when they are marked as free with . In fact, editors often fill the |url= field with the URL the DOI resolves to, to obtain this linked title (see statistics below).
When an article is free to read from the publisher, it is generally preferable to point readers to the publishers' version. Not only is it the version of record, but this is also the place where any errata or retraction will be published, and the DOI link is less likely to rot. If for some reason another version is preferred (because it is the one the editor read when citing the work, or because it is more directly accessible than via the publishers' website), it would still be possible to override the link with |url=, just like for |pmc=.
Since |pmc= is already used for auto-linking, I propose that |pmc= has priority over |doi=+|doi-access=free to generate the title link. This will ensure that all titles currently linked will not be changed by this move. PubMedCentral also stores versions of record, in a clean and readable way, so I do not think there is a need to override them.
Statistics
Here are some figures extracted from the enwiki dump of 2020-04-20. At this point, 189,097 citations had a |doi= and |doi-access=free set.
1,773 (1%) of these also had a |pmc=
28,012 (15%) did not have a |pmc= but had a |url= or |chapter-url=
159,312 (84%) had none of |pmc=, |url= or |chapter-url=, so their title was not linked, but would be linked using the DOI with this proposal.
Among the templates with both a free-to-read DOI and a manually-specified URL, 66% of these are equivalent to the DOI link (they eventually redirect to the same website) or the URL points to the publishers' website but no longer works (404 error). This
figure was obtained by randomly sampling 100 pairs of DOI/URL from the dataset and comparing the links manually. This shows that editors are keen to link the title of their citations. This encourages link rot since they rarely use |url=https://doi.org/... but rather the URL the DOI redirects to.
Oppose. There are too many different ids to link (jstor, doi, bibcode, pmid, hdl, citeseerx, arxiv, etc) for auto-linking an arbitrary choice among them to work well. Better to just list them as links. I am also opposed to autolinking pmc, for the same reason. —David Eppstein (talk) 19:11, 23 April 2020 (UTC)
It's rather trivial to make work well. Is it identifier of record (e.g. doi, jstor, pmc, etc...) that links to a full free version of the text? If yes, autolink. If it's not an identifier of record (citeseerx, arxiv, etc...), or does not link to a free full version, do not autolink. Headbomb {t · c · p · b} 22:04, 23 April 2020 (UTC)
That doesn't actually respond to the issue I raised. There may be multiple conflicting identifiers of record. On what basis should we make an arbitrary choice to front one of them? —David Eppstein (talk) 19:54, 26 April 2020 (UTC)
If multiple identifiers link to a free full version of record, it doesn't matter which is used, since they all link to the same version. What's important is that the reader is given one. Editors could always override the default if there's a specific need for it (e.g. using the bibcode links instead of the doi links on an astronomy article). Headbomb {t · c · p · b} 20:07, 26 April 2020 (UTC)
Support, and hallelujah for this proposal, as this issue has been causing me grief for years. In all of our articles, readers generally know that a blue-linked title takes them to free full text. We cannot expect our readers to understand (in medical content) what PMC, PMID, DOI or anything else stands for. We also should not expect them to have to scroll through all of these to determine if they can locate free full text (as opposed to just an abstract). We can standardize the experience for our readers by giving them a blue link in the title when free full text is available, as that is what they find on other articles. This is a service to our readers who may not know what any of those other codes stand for, but will recognize a blue-linked title. SandyGeorgia (Talk) 19:40, 23 April 2020 (UTC)
Why would url override PMC, when PMC might be more enduring? SandyGeorgia (Talk) 20:05, 23 April 2020 (UTC) That is, I provide a url only when there is not a PMC, but my preference is PMC. SandyGeorgia (Talk) 20:11, 23 April 2020 (UTC)
URL, if provided, means someone thought to overrule the PMC (or the DOI if this passes). If PMC/DOI is desired to take precedence over URLs, that could be enforced by bots or by the template depending on consensus. Headbomb {t · c · p · b} 21:55, 23 April 2020 (UTC)
Support the simplest thing for a reader to learn is that clicking on a title link takes them to the freest available online source. This proposal helps that happen. No citation with a free online source should have an unlinked title. --RexxS (talk) 20:08, 23 April 2020 (UTC)
Oppose. The DOI link is already present in the citation, and it is helpfully marked as free. Clicking on it is as natural as clicking on an ISBN link. Duplicating the link adds nothing but more blue text and more complexity. If a reader sees a linked title, is it an explicit |url= or a copy from one of the identifiers? If there is more than one identifier, which URL was copied? We're already seeing confusion with just two extra URL sources, but after this there will be a push to copy URLs from other free identifiers as well. And then editors will be worrying about the priority order and asking for additional knobs to tweak it, adding more complexity. Let's avoid all that, by not duplicating the link. Kanguole20:52, 23 April 2020 (UTC)
"is it an explicit |url= or a copy from one of the identifiers" this does not matter to a reader. But if consensus is that which identifier is used is important, |via= could reflect this too, e.g.
Support all advantages, no negatives. This very reader friendly and greatly improves accessibility on mobile and other platforms. We already do this for PMCs, it's time to extend the behaviour to free DOIs too. Headbomb {t · c · p · b} 21:53, 23 April 2020 (UTC)
Support As some have pointed out, this is a trivial change if you already know what to expect from dois and the symbol for free access. However, this can significantly improve usability for those whose first instinct will be to click on the title. Forbes72 | Talk00:21, 24 April 2020 (UTC)
Support. This is common sense, as it leads the reader more easily and intuitively towards the full text. It serves the purpose of practical verifiability, deeper research, and expected user experience. Objections that this makes the citation more "complex" vastly misunderstand the background knowledge of the average encyclopedia reader (or human), who has no idea what an identifier means. Best practice in usability is to reduce the distance between user knowledge and interface behavior: it's overwhelmingly obvious that a linked title is closer to user expectation than a linked . 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 Misplaced Pages 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 Misplaced Pages Library, Jake Ocaasi00:27, 24 April 2020 (UTC)
Support lots of stuff has a doi, and its main benefit is its stability. If we know there is a stable, gratis version out there, we should link to it since it's pretty much the single most useful link for readers and reusers. Common sense proposal. — Wug·a·po·des 00:38, 24 April 2020 (UTC)
Example of references with DOI green locks: Zika feverExample of references with PMC green locks (already auto-linked): List of sequenced bacterial genomesExample of references with DOI and PMC green locks, a link to another repository and a toll access DOI: 2019 in paleobotanySupport as a useful step in the daunting task of improving our citations to follow guidelines on verifiability. Open access works need to be easy to identify in the jungle of references which the bigger articles often have, especially in a period when many cannot visit a library any more to benefit from "walk in" access. Others have addressed concerns above already, I'll just note that the users who know the difference between identifiers, and have preferences about them, don't need to know which one is used for the URL, because they can just continue clicking their preferred identifier. The automatic linking mostly changes the experience of the vast majority of users who have no idea what the various identifiers are (although we may hope to educate them gradually). Nemo07:03, 24 April 2020 (UTC)
P.s: I've added some screenshots for those who may not be familiar with the DOIs and access-level locks we're talking about. Nemo07:11, 24 April 2020 (UTC)
Oppose per David Eppstein and Kanguole above. This proposal is fixing a problem that does not exist. It is adding unnecessary complexity without a benefit in functionality, flexibility or maintainability of citations, now or in the future.
The link to the identifier already exists and it is obvious and trivially easy to use ("click on it"), so this change would just add to the "sea of blue". Providing the same link twice may even cause confusion for readers (and therefore be against the principle of least surprise) because nobody would know any more if a blue title means that it points to some |url= or not. Also, there are often several identifiers to choose from (and there will likely be even more in the future), so we would have to define arbitrary priorities which identifier would take precedence over another. I can already see endless discussions about why one identifier is more important than another, and it will be impossible to make everyone happy with a decision. Worst, over time, different identifiers may be declared to take precedence causing a citation's title to link to resources which could not be predicted by the editor who added a citation in the first place. This borders on falsification of an original editor's contribution. In the readers' perception, the title link will no longer link to some conscientiously selected url, but just to some pseudo-random resource somehow related to the citation - this is degrading the quality of citations and is weakening our network of trust rather than improving it. For the same reasons, I'm also against autolinking |pmc=.
Several decades into the future, many urls will be broken, but likewise many dois will be broken as well. Even some web archivers may have stopped working by then. The solution to this problem of link rot is to provide as many independent backups as reasonably possible, but not to provide links to identical resources twice under different names.
Somewhat related, if a url points to the exact same target as a doi, the url can be safely removed, but often enough I see editors removing urls which point to the same (or only similar) content on a different target page as well. Removing |url= they also remove |access-date= and |archive-url=. While this is not the topic of this RFC, it is driven by the same misguided idea that dois were somehow superior to urls, and that urls (and related framework parameters) can be removed if a similar doi exists. These editors are weakening our citations rather than improving them. Therefore - and this is topic of this RFC - I see this attempt to let dois look like kind of urls in disguise as potentially harmful to the long-term integrity of our citations.
Viewed at it from a rather different angle, but partially related to the problem of having to define and maintain arbitrary priorities for multiple potential identifiers which might be used as a source for auto-linking: Help_talk:Citation_Style_1#Google_books_example
Support for the same reasons as Forbes72 above, and as DOIs are an international standard designed for persistence , the idea makes good sense to me of using a DOI as a first-class title-linking source with optional pmc or url overrides. ― Shnizzedy (talk) 14:12, 24 April 2020 (UTC)
Support It would be a slight change in any given instance, but it would move the project as a whole in the direction of easier use. It's a sensible default that can be overridden when doing so would be beneficial. Overall, a good idea. XOR'easter (talk) 15:45, 24 April 2020 (UTC)
Support - The less-informed reader (who doesn't know what means) will end up at a site where he/she/they can read the full article, and more-informed wonky folks will click on the doi link because it has the next to it. Everyone's happy ... which means we should all "... get up and dance to a song, that was a hit before your mother was born, though she was born a long long time ago, your mother should know ...." ♫ - Mark D Worthen PsyD(talk) (I'm a man—traditional male pronouns are fine.) 08:21, 25 April 2020 (UTC)
Weak Oppose: I'm afraid I'm with matthiaspaul on this proposal; adding to the "sea of blue" might confuse readers, and that's not what we should be trying to do. Still, I see the benefits; but I wonder how this might affect, say, ProveIt, which I use... — Javert2113 (Siarad.|¤) 18:26, 26 April 2020 (UTC)
I do not see how this could affect ProveIt in any way: it does not change the meaning of any template parameter, it does not add any new parameter, any syntax currently valid remains valid. − Pintoch (talk) 19:07, 26 April 2020 (UTC)
Maybe Josve05a can provide an opinion, as I've seen him active with all of ProveIt, OAbot, citation bot and a plethora of other gadgets. Nemo19:12, 26 April 2020 (UTC)
@Javert2113: Tools which uses the source (wikitext) to edit an article (such as ProveIt) would in no way be affected by this. This proposal is only regarding the layout/display of the cite template, not how the parameters should be added/work on a basic level. Jonatan Svensson Glad (talk) 19:25, 26 April 2020 (UTC)
Support We want open-sourced references as much as possible, as to allow our readers to be able to verify as much information as possible for themselves if they wish. That's why we add references in the first place. Currently, we auto-link the title if a PMC is added since all such links are openly sourced. I don't see a reason why another identifier if marked as being open/freely accessible already, should not also auto-link the title. A sea of blue links might be a problem, but having all identifiers listed at the end is still a list of blue links and if we wish to give one of them more prominence, it should be a link which is open. Therefore, I can't see any issues with this proposal. Jonatan Svensson Glad (talk) 19:19, 26 April 2020 (UTC)
Support I cross posted notice of this discussion to WikiProject Medicine. Misplaced Pages 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 Misplaced Pages is to provide readers with stable legal access to free versions of articles. This change helps us to accomplish that. Blue Rasberry (talk)21:43, 26 April 2020 (UTC)
Support This is my default way to indicate that links are free. Right now there are hacky ways around it, and citation bot will automatically remove a url that is identical to the doi-link to my annoyance. Not a big fan of {{oa}} and similar because they're ugly and distracting. buidhe22:13, 26 April 2020 (UTC)
Support this is the best indicator that more information is available.....no run around links is best.--Moxy 🍁 22:19, 26 April 2020 (UTC)
Support Even among relatively sophisticated/educated readers, unless you spend time dealing with journal articles you probably don't know what doi/pmc/acronym soup means. In the absence of another blue link to click on you may try those links out, but standard web formatting is that the linked title takes you to the actual article being referenced. That in this case there's some arcane doi linkages happening doesn't change that for the average reader interested in checking a source article, the only thing the want or care about is a clear link to the article being cited, and the article title linking to that fully-readable journal article is the normal expectation, not having to guess what "doi" means. --PresN03:25, 27 April 2020 (UTC)
of an out-of-copyright paper the DOI points to a protected copy but a free access URL is legitimately available. Now, I understand this proposal would leave this reference alone but some of the remarks above suggest DOIs are inherently better than URLs and this is not always the case. We should be careful to avoid a BOT-like approach. Thincat (talk) 09:16, 27 April 2020 (UTC)
Yes, that's why it's proposed that the URL override be possible. PubMed Central also has a lot of public domain content, another reason to let PMC take precedence over the DOI. For instance an article contains this citation:
This wouldn't replace any manually provided alternatives like the above. If the DOI doesn't link to a free-copy, no automatic link would be given. And if a free copy is "manually" provided, it would take precedence over the automatic links. Headbomb {t · c · p · b} 16:05, 27 April 2020 (UTC)
Support per others above. It will help readers to have access to free sources, and is also helpful for more professional editors. Ahmad06: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 Misplaced Pages, have no idea what one is to gain from clicking on ISBN links. I don't do that. I do, however, understand the simple logic that (at least on scientific articles) blue-linked titles = always free full text. One opposer claims "This proposal is fixing a problem that does not exist." But in my opinion, there is a simple problem that this proposal fixes. We do readers a favor by linking the free full-text on the title for PMCs. We should do the same for DOIs. Biosthmors (talk) 17:47, 30 April 2020 (UTC)
Support. I have personally observed readers not realize that they needed to click on the DOI numbers because they have no idea what a DOI is (nor should they have to know). Clicking on a linked source title is the intuitive interaction. (not watching, please {{ping}}) czar07:11, 3 May 2020 (UTC)
Oppose early closure. Instead, I would counter-suggest that presence of any autolinked url should be accompanied by removal of the lock icon, as redundant clutter. 98.0.246.242 (talk) 01:51, 6 May 2020 (UTC)
Support: readers are used to clicking on titles. The "sea of blue" argument is invalid, as there's quite often a second blue link for the publisher, author, or whatever, so having a blue doi will not harm the reader. PamD11:45, 9 May 2020 (UTC)
Support: one commentor above argues Clicking on it is as natural as clicking on an ISBN link. I quite agree. Like with ISBNs, clicking on DOIs is unnatural to layfolks and second practice to Wikipedians, who really struggle to internalise just how complex our website is to readers. To be fair, in academic contexts we can maybe assume more of our readers' knowledge, but it's still best to keep it as simple as possible. I support that proposal because it adjusts the templates to fit a general rule that almost all Misplaced Pages article citations follow: if the source is available online then it's linked through its title. — Bilorv (talk) 09:47, 10 May 2020 (UTC)
Strong suppport that free links should be highlighted. Encouraging access to free material is part of our basic purpose. DOI has the advantage of working across all fields, unlike PMC. The only significant question is how to deal with things if thee are multiple free links. In principle the publishers doi, not pmc is the version of record and should be theone presented in almost all cases, if it does indeed link to the full free text and not an abstract, , and also preferred to other repositories. But,f rom the librarians point of view, all possible links should be entered, as the way to handle disappearing links, but they need nor necessarily all be displayed. DGG ( talk ) 16:41, 13 May 2020 (UTC)
Support, but there needs to be a careful additional discussion of the priority order when multiple identifiers are present. For academic journal articles, there are many cases where doi's link to the publisher's website which has a restricted access version, but the author(s) have placed free-to-read copies at JSTOR, etc., because of their institution's policy on access to publications. At present, if you include a url that goes to JSTOR, it's usually removed in favour of using |jstor=, so over-riding via the URL doesn't work, unless this change is forbidden. The proposal seems to require that when there are multiple links, they must be marked as free access or not when access differs in order to choose the best. This information is far from universally present right now. Peter coxhead (talk) 09:30, 14 May 2020 (UTC)
A bot to remove stub templates from non stub articles and to update the talk page tags
Discussing this with Rosiestep yesterday, there's literally thousands of wrongly assessed articles inflating our stub count. A lot of editors don't remove the stub templates or update the talk pages once expanded. I propose that a bot scans our entire list of 3.3 million odd stubs and removes stub tags from all articles with over 1.5 kb of readable prose and updates the talk page tags to start class. I also propose a permanent bot which will automatically update the talk pages to start class once an established editor removes a stub tag from the article and vice versa, when somebody updates the talk page project parameters to start class it removes the stub tag from the articles. I think it's important to be consistent, the current situation is a mess and it needs sorting out asap, particuarly with the Misplaced Pages:The 50,000 Destubbing Challenge running now.† Encyclopædius10:05, 29 April 2020 (UTC)
Support automation, however I doubt that a specific threshold is going to fly. It would be possible, and only slightly more complicated, to use a moving threshold: for instance, remove the stub tag if the article has grown by over 100 % and over 1000 characters since being tagged. Nemo11:00, 29 April 2020 (UTC)
Comment The problem that immediately strikes me with this is that this would require us to have a much stricter version of WP:STUBDEF - because effectively, this bot would be setting one. To do that, I think, requires very strong community consensus - because it has quite broad-ranging implications for what we describe as a stub. Not that that's inherently not a reason to do it - and I have a great deal of sympathy with the issue you take with the current approach, which basically boils down to "you know it's a stub when you see it" - but it does need a lot of thinking about, I think. What makes a stub a stub may be greatly different across articles, and I'm not sure that a pure measurement of text length is a good way of dealing with it. Naypta ☺ | ✉ talk page | 11:03, 29 April 2020 (UTC)
Yes, every article is different. But if an established editor removes a stub tag after an expansion I think it would be easy to get a bot to recognise that it is no longer a stub and update the talk page. Of course it could have been expanded to B class and wrongly assessed as start, but you know what I mean, we need something at least to sort much of this mess out and the false listings. I think pretty much universally 1.5 kb of prose is accepted as no longer a stub, if there was a bot to measure readable prose and remove stub tags from them all and update the talk pages to start class that would solve a lot even if there might be some questionable individual cases.† Encyclopædius11:58, 29 April 2020 (UTC)
To start with, a bot which scans all of the articles in the subcategories of Category:Stub-Class articles and removes stub tags and updates talk page tags for all entries which are more than 1.5 kb of readable prose. That would be very helpful.† Encyclopædius12:02, 29 April 2020 (UTC)
@Encyclopædius: you would have to specify how the bot would determine what is "readable prose". Those of us who regularly edit articles about genera, families, etc. of organisms often have to re-add stub templates to articles that consist of almost nothing but a list of subtaxa (e.g. a list of species in a genus article). The list can be long, but this doesn't stop the article being a stub. Length alone is not a deciding factor. Peter coxhead (talk) 13:39, 29 April 2020 (UTC)
Comment Can we break down the problem. It is a good idea to let a bot remove the stub tag from substantial articles. What it does next is contentious. Possibly the simplest solution is to tag it with Lengthy article automatically destubbed.
It does not become a Start Class article if it has no independent references- or if the reference does not support the text. I have been destubbing UK schools. Using the length criteria, repeating the content of the lead in the new section 'Description' I can change a length of 600 to 1500- and its still a stub, and conversely I can reduce a 'Start' to a stub. But I also see substantial, referenced articles that have incrementally built up that are still catted as stubs. (Teachers genetically won't self-assess articles they have improved without firm criteria- I am sure that applies to other professionals) That is where the bot could be helpful.
It is certainly 'picking the low hanging fruit' to use English place names as examples, and unfair not include tables in the length criteria- encyclopedias do need lists of elected councillors. Look at Pratt's Bottom that is padded with unsourced material to qualify- but the bulk of the info is in the table- so is not counted. Still a lengthy article detector bot is a good idea- the question is what does it do next?
If it is going to run- I am sure it could add some useful analysis to the talk page. You guys are the experts- but my favorites are, missing infobox, missing image, missing source- relies solely on primary related sources, sources possibly too dated to be of use. Editors ploughing though the new backlog lists we have created will at least have a clue to the issues before committing them selves.ClemRutter (talk) 15:44, 29 April 2020 (UTC)
Lengthy book articles with no references are considered Stubs by WikiProject Novels and WikiProject Children's Literature; and if they are written by a woman, then WikiProject Women Writers also considers them to be Stubs (e.g. for purposes of the WPWW talkpage template classification). In this case, adding an infobox or a photo won't change the class, but adding four non-bare references will. For more context, Encyclopædius and I have been discussing destubbing here, User talk:Rosiestep#Using ORES for destubbing. cc: EpochFail. --Rosiestep (talk) 16:36, 29 April 2020 (UTC)
@ClemRutter, I can tell you now that using a bot to tag missing infobox, missing image would backfire massively (and have a decent chance of getting someone blocked). As Encyclopædius can testify, we have a serious ongoing issue with people turning up on articles where there's a broad consensus that the topic is too complicated to summarise in infobox format, trying to "fix" them by adding infoboxes, and getting aggressive or upset when they're promptly reverted; having some kind of bot-added "this article needs an infobox" flag would make matters much worse because editors would reasonably assume that by adding an infobox they were addressing an error. The same issue holds (albeit to a lesser extent) with images; for many articles, particularly historical biographies, there literally is no appropriate image, but a "this article needs an image" flag would encourage people to think they were being helpful in "no image exists of this 13th-century nun or of anything connected with her, but we know she was born in Barnsley so I've added a photo of Barnsley Town Hall" edits, which again would lead to new editors who are genuinely trying to be helpful being reverted en masse and getting confused and annoyed. ‑ Iridescent19:03, 29 April 2020 (UTC)
I have a bold counter-proposal. Why not use ORES predictions directly? ORES can predict what quality level an article currently is and it's pretty accurate. We could use the predictions directly to track status and progress. For when ORES makes a mistake, I'd like it to be simple to override ORES' prediction. E.g. if the talk page assessment is greater than ORES' prediction or it matches some criteria for freshness, use the talk page assessment. What do you think? --EpochFail (talk • contribs) 17:45, 29 April 2020 (UTC)
@Iridescent: Too right! :-) No "needs infobox" parameters please. Generally I'm not a fan of automated assessing but there's tens of thousands of articles which are really not sorted out here, I can understand drawbacks to doing things enmasse but there must be a way to improve the situation.† Encyclopædius19:20, 29 April 2020 (UTC).
EpochFail, nice! (a) Recommendation #1: Can this table be presented with links; and if I click the link for 1846 Stubs, it'll give me another table which has links for each of the 1,846 stub articles? (b) Here User:WP 1.0 bot/Tables/Project/Women writers we see that there are 36,865 talkpages with the WPWW talkpage template, but the above table totals 22,448. Do you know why that is? --Rosiestep (talk) 20:44, 29 April 2020 (UTC)
Rosiestep It could definitely be formatted more clearly. I think we'll need a bot to produce it. I wonder if WP 1.0 bot might be extended for this. I think the reason for the difference in count is likely that many of the articles in the set haven't been edited in a long time. We started storing article quality predictions in the database about a year ago. Any article that hasn't been updated in the last year won't have a prediction. We could back-propagate the quality predictions to get full coverage. That part I can certainly help with if we get interest from a bot dev. --EpochFail (talk • contribs) 20:09, 30 April 2020 (UTC)
EpochFail, IMO, back-propagating for full coverage makes sense. Let's see if a dev comes along who's interested in taking this on... maybe at this month's Hackathon? --Rosiestep (talk) 20:34, 30 April 2020 (UTC)
Leaning oppose, as I do not think that "not-a-stub" is a call that a bot can make, but I would support generating a list of stub-tagged articles that have grown substantially since being tagged for quick human review. We had a project like that before once, where we listed several thousand articles that had gone the longest without human attention, sorted by factors such as article length and number of human editors. I believe we sorted through that list pretty quickly. BD2412T21:03, 29 April 2020 (UTC)
Oppose I like stub templates and always add them when I start an article. Their good points include:
they are attractive to the eye, typically having an appropriate icon and a simple easy-to-read message
they encourage readers to pitch and help expand the article without being too preachy or pushy
they go at the foot of the article so they don't get in the way
they help classify the article
These features make them better than the obnoxious banner tags which you find at the head of many articles. Rather than removing them perhaps we could enhance them. If an article has grown past stub stage then maybe the template could auto-detect this and adjust its message accordingly? We still want readers to help develop articles until they are perfect. The classifications which get buried in the project templates on the talk pages could be echoed so that the reader can see and understand the level of the article. Andrew🐉(talk) 22:50, 29 April 2020 (UTC)
@Andrew Davidson: Did you not read the proposal? This has nothing to do with obnoxious tags at the head of artiles nor expanding stubs. "Rather than removing them perhaps we could enhance them". There's thousands of articles which are start class or higher which are wrongly tagged as stubs. Of course we want to see articles improved but I'm basically trying to do something to bring the stub count down which includes both destubbing/improvement work and identifying wrongly classified stubs. Your oppose and "liking of stub tags" disrupts my overall effort on this.† Encyclopædius16:10, 3 May 2020 (UTC)
Oppose. This idea engineers the editor out of Misplaced Pages. Stub assessment is probably one of the most important tasks for early-to-middle Wikipedians. It is subjective, it involves topic assessment, many will be better AfD-ed or merged than reclassified, and doing these things is a learning process for editors. Instead, have a bot identify probable cases for reclassification, but leave it for a human to make the decision. —SmokeyJoe (talk) 23:02, 29 April 2020 (UTC)
The important thing SmokeyJoe is that the articles are at least identified or guessed to be in a list by a bot and then people can assess them. We need something automated to help.† Encyclopædius11:13, 30 April 2020 (UTC)
Support ORES isn't perfect, but it's pretty good for this specific task. Unsourced articles should be deleted on sight in my opinion. buidhe09:31, 30 April 2020 (UTC)
Support We already do this at MilHist. The Bot can easily determine whether an article is a stub or not; this is purely objective. The hard part is the determination of B class, which generally requires human input. Hawkeye7(discuss)11:46, 30 April 2020 (UTC)
Recommendation #2: Using the Rater feature, if I rate all the talkpage templates of an article to better than Stub-class, and if the article is tagged as a Stub, I get a pop-up message that says:
Ratings saved successfully.
Note that the article appears to be
tagged as a stub.
But currently, the converse isn't happening so it's my recommendation for someone to create a pop-up message for that: if I rate all the talkpage templates of an article to Stub-class, and if the article is not tagged as a Stub, give me a pop-up message that says:
Ratings saved successfully.
Note that the article appears to not be
tagged as a stub.
Plus, it would be nice if these pop-ups weren't limited to appearing only if an editor is using the Rater feature, e.g. if the pop-ups also appeared when an editor manually edits the talkpage templates. --Rosiestep (talk) 15:01, 30 April 2020 (UTC)
Weak support There's a lot of stubs and not enough people doing stub sorting. Early-to-middle tenure editors can still benefit from checking the bot's work, and it will help them prioritize the other aspects of page patrol like AfD and cleanup tagging. — Wug·a·po·des 19:26, 30 April 2020 (UTC)
Recommendation #3 A bot assesses and make changes which are clearly not stub articles (i. e. more than 2,500 prose characters) and the bot creates a page/list for human review (like orphaned free files, or STiki). When you get a thousand of pages at one place, which may not be stub, it becomes easier. --Titodutta (talk) 16:35, 3 May 2020 (UTC)
If, after three days, the discussion has remained focused on the proposer rather than the proposal, consensus will not form; there is nothing substantive for it to form from. ——SN5412905:42, 4 May 2020 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
I would like to propose some changes to various components of the top portion of Misplaced Pages:Community portal. I posted this for discussion at the talk page there, but I was not able to get any discussion going there, at all.
Below is my draft for changes to the top portion of the page. this draft includes the portion of the page from the top of the page, down to the large pictorial navbar
Please note, I also have some ideas for the small navbox at the top; namely, to add just some more links, e.g. to Misplaced Pages:Goings-on,etc, as described below. Below is a separate draft, for the small navbox.
I appreciate any feedback. I would like to move ahead with this, if possible. I am open to any and all ideas, feedback, comments, etc on this. thanks!!! -- Sm8900 🌎 17:27, 30 April 2020 (UTC)
If you haven't garnered any support from your previous four post about the same thing last week and the week before .....perhaps best to assume support is simply lacking. Very hard to move forward when suggestions are suggested and ignored.--Moxy 🍁 20:41, 30 April 2020 (UTC)
Hi Moxy. it is good to have your response here. just to clarify, I did sincerely follow your suggestion; I removed the duplicate links, to WP:Goings-on, and to WP:News. so this proposal was meant to directly accord with your points on that. If you prefer, I will restore WP:Goings-on to its original place, and remove the new links that I added to WP:Goings-on, and to Misplaced Pages:About. Would that make this proposal more amenable? I did ask for your input on the ideas tab, as to which you prefer. I would be glad to follow your suggestions in either respect. I will be glad to modify my draft. I appreciate your response; your reply was truly helpful in helping me to perceive some of the points needing to be addressed. thanks!! --Sm8900 🌎 00:21, 1 May 2020 (UTC)
Sorry, I don't see most of these as positive changes. You'll have a better chance if you propose them individually as pieces than in one giant chunk. To address a few specifically: There's no need for the top to be bulleted (it's already short). Adding WP:About isn't appropriate since that page is for readers, not editors. News is already covered on the portal further down, and the Signpost is really the main item, so if there's a link it should just be there (WP:Goings-on is certainly not very active). {{u|Sdkb}} 05:35, 2 May 2020 (UTC)
@Sdkb: I agree with you. Based on your helpful suggestion, I have narrowed my proposal to the two items below. does this sound okay? I appreciate your help.
Readers will expect to find the nav box at the bottom of the page per MOS:LAYOUT, and RfCs are already linked to from the "Discussions and collaborations" section. {{u|Sdkb}} 02:50, 3 May 2020 (UTC)
I would appreciate if you would please refrain from making personal comments here. I did not make any personal comments to you. To answer your inquiry above, I agreed only to cease presenting a proposal in any venue other than the central venue for discussing such proposals. . I did not agree to just to stick to content creation and normal editing for a while … and to cease with the 'grand ideas' and problem-solving for a bit". the specific issue raised in that colloquy was posting a proposal at several pages for wikiprojects. I agreed to not do so in the future. your characterization here of my approach here is not accurate. I appreciate your attention to my response. thanks. ---Sm8900★ 🌎 22:55, 3 May 2020 (UTC)
Just for the record, I would like to note that I have posted a reply to Iridiscent at their talk page. I am copying and pasting a portion of that reply below, in order to publicly respond, and to hopefully provide a response that will be helpful, constructive, and substantive in a manner to enable future discussions here to proceed in a positive, constructive, civil and helpful manner. I appreciate the help and understanding of all participants here. thanks.
Hi. I appreciate your note to me at Village Pump. I understood that you were posing a question to me, and I provided a response, which I hope was responsive and helpful. also, you stated that I "feel this constant need to propose grand redesigns of Misplaced Pages and constantly act like the only opinions of any value are those of people who agree with you." I am not aware of any area or venue that I am acting in that manner in any way at the present time, or at any time in any edit over recent weeks. In any future interactions, I would appreciate if we could please address each other in a positive and constructive manner, and avoid any personal comments, or any comments on individual actions that are tangential to the current topic, and obviously seek to observe WP:Civil in every respect. I do sincerely appreciate and respect your desire to make Misplaced Pages a better place.
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Is there a way that a thank tag can be added to the Recent Changes page?
Proposal for a bot to update backlinks when pages are moved, merged or otherwise become redirects
In a discussion earlier over at the talk page for the ongoing RfA, we came across a scenario where, partially as a result of backlinks not being updated after a page move, content was kept in a way that was incorrect in an article for a fair while. I'm more than sure this isn't the only similar case like that, or even the most severe case, and it set me thinking what we could do to help fix that.
Don't get me wrong, inevitably a bot will never fully replace human backlink reviewers. I'm explicitly not suggesting that this should replace the indication for people who move pages to check Special:WhatLinksHere and to go through and update the links manually. However, inevitably, people will sometimes forget to do so - I bet I probably have in the past, as did the user moving the page in the scenario that I mentioned above. As a result, I'd like to propose a bot that can clean up whatever falls through the cracks.
I know this is technically possible because I've already written the code, but I wanted to make sure there was consensus that this was a good idea before it goes to WP:BRFA. Questions of technical implementation (which I think are best left over there, if and when we get there) aside, the basic process of what the bot would do is as below:
Query a list of recent new redirects in mainspace where a page has been edited to turn it into a redirect (as opposed to pages that are created as redirects from the beginning).
I'm currently planning for the bot to start an hour in the past, to make sure that it doesn't step on anyone's toes if they are going through redirects manually. Thoughts on this would be appreciated, as to whether the time period ought to be longer, shorter, or some other mechanism altogether.
For each of these pages, find other mainspace pages that currently exist that link to the newly-redirected page.
leave a message on the article talk page explaining that the article has been moved, and that someone may wish to review the page to check if the link name should be updated
leave a small template next to the link like this on the page
some combination of the two
something else entirely
Original proposal, changed per discussion below
#Replace links to the page as below:
If the link is a plain no-pipe link ]
If the newly-redirected page is a redirect to a section of another page, turn the previously plain link into a piped link, keeping the previous link name: ]
Otherwise, keep the link as a no-pipe link, just replace it with the new page name ] (keeping the previous capitalisation, whether the first letter was a capital or lowercase)
If the link is a piped link ], replace the target, but not the link text - ]
It may be a good idea to have a limit on the number of backlinks the bot automatically updates for a single article, in order to prevent some kind of apocalypse situation in which half a million pages are updated from a single page move, but I also have in mind the fact that it's arguably even more important to get this right for large articles. Opinions on this would be greatly appreciated.
I'd also like to hear people's thoughts on whether it would be a good idea to leave a talk page message for the person who made the newly-redirected page into a redirect - something like this:
Hello, username! I saw you made WP:Example into a redirect. I noticed there are some pages on the wiki that still link to the redirect. You can see a list of these pages below:
It'd be fantastic if you could take a look at these and see if the links require updating. Thank you very much!
Good idea? Bad idea? Am I missing something humongous that would make this not work at all? Your !votes are very much appreciated :) Naypta ☺ | ✉ talk page | 22:13, 5 May 2020 (UTC)
I don't agree that it violates them. NOTBROKEN is talking about replacing links to redirects with piped links to the destination just because they're redirects, which isn't what I'm proposing. I can see you could argue that it could be cosmetic, but I think there is a good argument it's not - as we've seen in the example I linked, there is a clear case for this being a means of propagating consensus on naming across different pages. But even if it was the case that it were in violation of either of those two, I think there'd be a WP:IAR argument for it - precisely because of the consensus-propagating effect, and because (I think) it's demonstrably beneficial. Naypta ☺ | ✉ talk page | 22:54, 5 May 2020 (UTC)
If I am understanding you correctly, a page is moved and the old title remains a redirect to the new, then your bot will bypass that redirect, changing the old title to the new title (if it was not piped)? If so then, in the majority of cases, that is very much a violation of WP:NOTBROKEN, in cases where it it's changing ] to Bar]] (or similar) it is also violating WP:COSMETICBOT.
In some cases it will also be introducing errors into articles, either directly through grammatical (e.g. verb → noun, common noun → proper noun), context changes (e.g. brand name → generic name), scope changes (e.g. Joe Bloggs → Death of Joe Bloggs), political changes (e.g. Derry / Londonderry, East Sea / Sea of Japan etc.), incorrectly making changes retrospective (e.g. Macedonia → North Macedonia) etc. or through later changes, e.g. where a redirect is later converted to an article. There is also the issue of page move vandalism (although your an hour time delay will significantly mitigate against this, the shorter any delay the greater the issue will be).
Ultimately, while COSMETICBOT and NOTBROKEN might be arguable in some cases it will never be the majority, the other issues mean this is a task that an unsupervised bot could never do. Read the Misplaced Pages:Naming conventions (Macedonia)/2019 RFC to see examples of how context matters, e.g. before the name change "Macedonia" was correct in both cultural and (some) political contexts, afterwords it is correct in cultural contexts but only in historical political ones, North Macedonia is correct in contemporary political contexts (but not historic ones) but not in cultural ones. Without knowing the context a bot would get this wrong far more often than it got right, and in some cases (not just Macedonia) this would introduce potentially serious NPOV and/or BLP errors. Thryduulf (talk) 23:43, 5 May 2020 (UTC)
@Thryduulf: Hrm, the points about context, political and retrospective changes are definitely good. I had foreseen that there might in theory be some grammatical errors, but I had thought that this would probably be self-limiting by virtue of the fact that moves from a verb to a noun are probably pretty rare - I hadn't thought of things like Macedonia → North Macedonia which I can see might well be actively harmful to update in that way.
I do think the propagating consensus function is still useful. I've been thinking about how this might be done in a way which wouldn't cause those sorts of issues, and I can see two ways to do it whilst keeping a human in the loop (and have updated the proposal above as such): either leaving a message on the article talk, or leaving a Fix template inline to prompt someone to check the link. This could even be limited further to only pages where either source, target or both contain a preposition, e.g. changes from "Test in Testlandia" to "New in Testlandia", or as in the original case, "Killing of Jo Cox" to "Murder of Jo Cox". What do you reckon about this way of going about it? Naypta ☺ | ✉ talk page | 08:34, 6 May 2020 (UTC)
Most page moves do not result in a consensus to "propagate the change" as you put it because there is simply no need. In cases where there is such a need there are only two ways it can done reliably: fully manually or a fully supervised AWB (or similar) run. A bot could leave a message on the talk page letting editors know a page the article links to has been moved, but this will be useless clutter in most cases because WP:NOTBROKEN means there is no need to update the link, and in most of the few cases where change is needed editors will already be doing it manually. Thryduulf (talk) 10:09, 6 May 2020 (UTC)
@Thryduulf: I can see that in many cases it wouldn't be something needed, but for non-piped links to articles where the link contains a preposition, I'm struggling to think of any where this wouldn't be needed - that's not to say that there aren't scenarios which fit into that category, but I think the majority of the time it would be a good idea so to do. Another example would be changing "coronavirus pandemic in Country" to "COVID-19 pandemic in country" or w/e happened to be the similar change along those lines - in those cases, it is worth propagating that consensus across, as there is a meaningful difference which would likely not be mirrored in other similar articles, as the same level of thinking and understanding hasn't gone into it at those locations. Naypta ☺ | ✉ talk page | 10:22, 6 May 2020 (UTC)
As I said, there will be a few cases where propagating a change will be beneficial but (a) these will be the minority, (b) much of it will be done manually already, and (c) in some cases an explicit consensus will be required first. The correct way to handle those cases that need doing but aren't done manually is with a fully supervised AWB run so that exceptions can be detected, incorrect links fixed, etc. There is no role for a bot here. Thryduulf (talk) 10:41, 6 May 2020 (UTC)
@Thryduulf: That's fair. I'm not hugely familiar with the way AWB is managed - is there somewhere to suggest these kinds of AWB tasks? I know about WP:AWBTASKS but I had understood that those were more for one-off tasks that need doing, rather than for suggesting things that would need doing regularly. Advice appreciated Naypta ☺ | ✉ talk page | 10:49, 6 May 2020 (UTC)
Your understanding of AWBTASKS matches mine, but you are missing the point that these would be one-off tasks. At most you'd be looking at a single figure number of moves per month where a propagation would be beneficial, it hasn't been done manually and there is consensus for a mass change. Such consensus would need to be demonstrated for each task, as each will be done for different reasons, have different exceptions and cultural/political/grammatical considerations - all of which the person doing the change will need to understand. Thryduulf (talk) 11:24, 6 May 2020 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Content reviewer-protected
Content reviewers are auto confirmed users, but they have 2 restrictions: they can block users or protect pages, but they can't move it, and can't edit Wikimedia Commons files.
A user with content reviewer must have at least 99 edits, but no limit of days (if the user did more than 99 edits but it was active for more or less than 30 days then it will auto-content reviewer).
Also, in Misplaced Pages:RfA and Misplaced Pages:Age and adminship, a RfA candidate sayed he was 8 years old...
We do not know the maturity. Maturity for me is a humorous essay, and anything that does not make sense.
The logo for content reviewer protected is a + (plus) in red, just like the Flag of Switzerland.
--190.245.116.175 (talk) 03:26, 7 May 2020 (UTC)
Automatically remove protection from a page when it is moved
When a protected page is moved, the old title stays protected and the protection settings are duplicated to the new page, so we've now got two indefinitely protected pages when we should only have one. Here's an example. This, in essence, is preemptively protecting the redirect against something it hasn't yet experienced, and there are hundreds of improperly protected redirects like this. I think it's important to recognise that these old titles rarely ever see edits ever again, unless of course they themselves get turned into articles (in which case the preemptive protection is even more of an issue).
We're wasting resources having double the amount of required pages protected and tracking categories are full of pages that shouldn't be there. A page like "Guns" has a reason to be indefinitely semi-protected but First Emperor of Qin doesn't, and yet they were both present in the database report and might have been in Category:Semi-protected redirects.
Additionally, and might be of concern, this software feature has an exploit in which a page can be protected without an admin. Here's an example:
Someone who wants protection moves User:Anarchyte/protected to User:Anarchyte/protected3 and now we've got three indefinitely protected pages all because one page was protected. Note that protected3 was never directly related to protected2 (the original article).
I suggest the way protection works be modified so that the protection is automatically removed from the old page and given to the new page when it's moved, or at least there be an option to leave protection like there is to leave a redirect. If that were the case, the only protected page (in the example above) would be protected2. I'm not sure if this should be here or at technical, so let me know if this is the wrong avenue. Anarchyte (talk • work) 07:19, 7 May 2020 (UTC) Majorly edited (see original): 16:20, 7 May 2020 (UTC)
I think this would require a change in the software to implement, but the devs will reject that unless there is a consensus that the community wants the change. This seems a good place to discuss whether there is a desire for this.
Personally, I'm on the fence about this as there are times where leaving the redirect protected is desirable - page move vandalism, title disputes, and competing versions spring to mind as examples, but equally there are times when it probably isn't necessary. For temporarily protected pages - the protection expires at the same time on both new and old titles, so it's only an issue for pages that are moved while indefinitely protected - how often does that happen? My initial gut feeling is that if you find an indefinitely protected redirect that is protected only due to the move of a fully protected page and there is no obvious need for it to be protected, then just request unprotection. Thryduulf (talk) 09:01, 7 May 2020 (UTC)
Note that this was added in phab:T12527 after suggestions that the protection be preserved. There could be another alternative too like adding checkbox to specify whether you want the protection to remain or not. Not sure, but in some cases/or on some wikis, preservation of the protection might be needed or even required. – Ammarpad (talk) 09:20, 7 May 2020 (UTC)
I'm not sure this is a good idea. I'm unconvinced that the number of people scheming to gain protection on pages in the way that you're describing here is anywhere near the scale where this might be an issue - and why would it be, apart from anything else? Protection isn't some badge of quality to a page, au contraire it's a badge indicating that the page might be in danger of vandalism or other disruption. Meanwhile, although a small risk usually, there is sometimes a real and present risk that redirects to protected pages might end up being vandalised, especially if the vandalism to the protected page is so severe that it warrants permanent protection. As Thryduulf says quite rightly above, this issue seems to solve itself quite neatly by simply requesting unprotection where protection genuinely isn't needed. Naypta ☺ | ✉ talk page | 10:32, 7 May 2020 (UTC)
I'm struggling to think of any plausible example where the way this currently works is likely to cause a problem. Protection is applied to pages because there has been some disruptive editing, and surely that could continue at the old title as well as at the new title? Anarchyte, do you have any real-life example where there has been a problem? Was there any reason for anyone who couldn't edit the coronavirus page that you mentioned to be able to edit the redirect left behind by the move? Phil Bridger (talk) 11:47, 7 May 2020 (UTC)
Like Phil, I'm struggling to think of a problem that this addresses. It seems to be working the way we expect it to. However, the proposed change would create an odd situation. As a non-admin, I cannot protect or remove protection from pages; but as a page mover, I can move pages. Therefore, the effect of this would be to allow me to remove protection from pages. Hawkeye7(discuss)12:40, 7 May 2020 (UTC)
Sorry, I wasn't very clear in my opening message. I was somewhat rushed and didn't fully flesh out what I wanted to say. I'll make an edit to that above so that newcomers to the discussion understand what I'm actually trying to accomplish.
@Phil Bridger and Naypta: As we're now discussing the problem I've brought up, I think it's important to also discuss the protection policy. Protecting a page should be done to prevent vandalism or other disruption to the page at hand. When an admin, or at least myself, protects a page, they're protecting that one page. If it gets moved to a new title, the protection on the old title remains, meaning we've technically preemptively protected the page because there has been no harm done to the redirect yet. Redirects get a lot less page views than main articles and are often, or at least in comparison with their article counterparts, left alone by vandals because their work isn't going to be seen. There is no reason why in my example anything should be protected except protected2. The only page that has been "vandalised" is that, and User:Anarchyte/protected wasn't even considered when the protecting admin protected the page.
@Thryduulf: I definitely agree -- this is only going to be relevant for the edge case that an article is indefinitely protected and then moved. However, I've been running through all the semi-protected redirects as of late and I fail to see how retaining the protection on any of these (1, 2, 3, 4, 5, 6, 7, 8) is benefiting the encyclopedia (obviously it could be argued that leaving them protected also doesn't do any harm). If an article is experiencing page move vandalism, the article can get given sysop move protection. If that happens, we can't get any more moves anyway and so the issue is moot. Similarly, if there's a title dispute we can do the same thing (and perhaps fully protect the redirects temporarily so that they can't get overwritten by page movers).
@Hawkeye7: Yes, you could in essence move User:Anarchyte/protected elsewhere and then vandalise that page, but you need to be autoconfirmed before you can move a page so semi-protection is already irrelevant.
I wasn't thinking of someone like myself vandalising a page (which wouldn't happen), but of accidentally removing protection, which I wouldn't be warned had happened. I'm uncertain as to whether your proposed method of adding protection would work. You can't move a page over a redirect, so it would require non-existant pages to retain their protection. Hawkeye7(discuss)20:47, 7 May 2020 (UTC)
@Anarchyte: I understand the argument you're making, for sure; I just think it's an argument based on "policy says this might be a problem" rather than "this is actually a problem in reality", if that makes sense. I don't mean that as a slight against you in any way - it's certainly an interesting point, and I'd not thought about it before!
The point you raise about creating new articles over redirects that are accidentally protected is an especially good that I hadn't considered before at all - although, at the same time, I can't think off the top of my head of any examples where a protected page is moved from a prior location, and then at that prior location a new article is created. That's not to say it couldn't happen (or that it hasn't!), just that I can't think of what the circumstances might be.
I'd certainly not be opposed in any way to the introduction of a checkbox when moving for page movers allowing them the option of transferring the protection to the new redirect or not; however, I certainly don't think this ought to be a priority, and I do think it needs some further thought. For instance, if only page movers have the right, then what happens when a normal autoconfirmed user moves a page? Likewise, if not only they have the right, don't we still have the same issue?
The only way to get around this issue as a whole might end up being to restrict all protected page moves to page movers or administrators. I feel this might be one of those cases where yes, the current behaviour is weird, but alternative behaviour might potentially be even weirder without significant thought. Naypta ☺ | ✉ talk page | 16:32, 7 May 2020 (UTC)
I tend to agree with Naypta. If after a decade of the current behaviour there are less than 20 examples where the protection might not be appropriate this really isn't a high priority issue. A checkbox (that defaults to the current behaviour) wouldn't be a bad idea, just not a terribly urgent one. In the absence of that, it seems that the best thing to do would be to get a bot to maintain a list of all redirects created by moves of pages that are protected for longer than X time (1 week? 1 month? 3 months?), people can then look through that list and unprotect/request unprotection of any that don't need to be protected as they desire. It's not likely to be a very long list. Thryduulf (talk) 17:19, 7 May 2020 (UTC)
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. BD2412T15:40, 7 May 2020 (UTC)
It is interesting, however, that the first opposition comes from an IP with a grand total of 14 edits. BD2412T16: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? SportingFlyerT·C16: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. BD2412T17: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. BD2412T17: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. BD2412T18: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 Boriv^_^v17: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. BD2412T17:12, 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 Misplaced Pages. 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. serial17: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 Misplaced Pages to be spammed with commercial content or the like. BD2412T17: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. Levivich17: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. BD2412T17: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)
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. BD2412T18: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)
@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)
@Suffusion of Yellow: 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)
@TonyBallioni: 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)
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. BD2412T22: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. —烏Γ│22:35, 07 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·talk04:24, 13 May 2020 (UTC)
Proposal for edit notice on articles related to COVID-19
There is a discussion on Talk:Main Page to finally unbreak the mobile view of the Main Page since it is planned that the extension will stop special-casing it (see phab:T32404). For context, this is what current mobile users see now and this is the view that is proposed. --qedk (t 愛 c) 09:33, 9 May 2020 (UTC)
Protect user pages so only the owner and administrators can edit
There is an edit filter that prevents IPs from editing user pages, but I think one might request that only the account's owner can edit their user page someday. (Of course admins should be allowed as well.) I also say the same for user sandboxes and similar pages. There are some pages such as Twinkle preferences that only the owner can edit. I'm not perfect but I'm almost (talk) 18:29, 10 May 2020 (UTC)
The protection policy allows for users to request the protection of pages within their userspace if there is a need, but prohibits routine or preemptive protection, see Misplaced Pages:Protection policy#User pages. Doing what you propose would first require a change to that policy, but absent any demonstrated need I would oppose a proposal to do so. Thryduulf (talk) 19:02, 10 May 2020 (UTC)
I was reviewing the history of this policy, and I'd like to point out that it isn't clear whether the discussion leading to this policy was properly closed. Specifically, in 2013, "this discussion is closed with a consensus that users be allowed to preemptively protect pages in their user and user talk namespaces, but not their actual user talk page." However, in 2015, almost two years later, there was a closure review request that only three users participated in, and the same 2013 discussion was then re-closed with a different conclusion: "consensus seems to be the protection policy as a whole covers this situation - pre-emptive or automatic protection goes against our general principles, but if a point to protection is highlighted, then it can be used for any length needed." It is very confusing that two closers, two years apart, summarized the same discussion with two very different results. It is not clear to me that the current "policy", created by these changes, actually reflects the consensus. Tony Tan·talk04:59, 13 May 2020 (UTC)
No, this is a wiki and no one owns any page. If user pages were owned, they would be overrun with spam and Facebook imitations. This is an encyclopedia, not a social site. Johnuniq (talk) 23:46, 10 May 2020 (UTC)
One obvious problem with this proposal is that it would prevent people from posting mandatory ANI notifications to the user that they are reporting.--69.157.252.96 (talk) 17:51, 11 May 2020 (UTC)
Oppose Per User:Jimbo_Wales#You_can_edit_this_page! (I am not a big fan of quoting things or commenting "per someone", however here he explained it beautifully). A problem I can see, non-sysops not having the ability to edit a user page possibly means they can not tag the page (or sandbox) for deletion under U5, G12 or any criteria, or make any change such as hiding categories from user drafts etc. And finally if a user page is repeatedly vandalised, WP:RFPP should help . --Titodutta (talk) 21:34, 12 May 2020 (UTC)
Strong Oppose. That said, 18 months ago I concluded that it could be helpful if a user were able to semi-protect their own page (just once) for a maximum period of 24 hours in a 7 day period. I still think that could help reduce aggression and give an editor chance to seek admin involvement against personal attacks. (see here). Nick Moyes (talk) 23:34, 12 May 2020 (UTC)
Hard Metric
As someone who is 0.0091 furlongs tall, I'm closing this discussion as individuals have summarised the reasons that we will need to remain with a number of imperial-first units until the status quo changes. Nosebagbear (talk) 08:03, 13 May 2020 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
I am a monthly donator and I use Misplaced Pages every day. It is incredibly helpful to me.
I'm just so happy that Misplaced Pages is using more and more metric units in its pages. Keep it up!
I really hope that eventually Misplaced Pages goes 100% hard metric so that no one ever has to put those antiquated Imperial units in parenthesis.
I'm a 65 year young American, born in Pueblo, Colorado to white parents who didn't know a thing about metric. I just think it's time we join the rest of the world in a system that is so easy to use. I'm 82 kilos in weight and 180 cm in height. Thank you. — Preceding unsigned comment added by Japurahei (talk • contribs) 12:13, 11 May 2020 (UTC)
You can see our manual of style bit on it at WP:UNIT. In a nutshell, it depends on the article, and is intended to provide for the reader the most relevant content first, while also providing a conversion, typically. If the United States were to legally change it's measurement system, there would need to be a long discussion about if or when it would be switched over onwiki. For the record as it seems we're doing this, I weigh 28 large trout and am 6.5 squirrels in height. Thank you, Vermont (talk) 16:25, 11 May 2020 (UTC)
Misplaced Pages describes the world as it is, not as we think it should be. Very many measurements in the US, and fewer but still many in the UK, are made in non-metric units, so they come first when relevant. I have worked this out very quickly so may have missed some orders of magnitude, but I think my age is about 1960 megaseconds. Phil Bridger (talk) 18:00, 11 May 2020 (UTC)
If that's the case then I think I got the calculation about right, although a pedant might prefer me to say 1.960 gigaseconds or Phil Bridger (talk) 11:54, 12 May 2020 (UTC)
Even if the whole world started using metric for everything tomorrow, we would still need to note the measurements of things constructed or defined in previous units, for example the Brunel gauge was 7 ft ¼ in wide and the UK's Weights and Measures Act 1963 defined the permitted measures for dispensing alcoholic spirits as ¼, ⅕ or ⅙ gill (see Alcoholic spirits measure#United Kingdom. I weigh about 0.5 average reticulated pythons and 5.4% as high as the longest span of the Ponte Vecchio is long. Thryduulf (talk) 19:19, 11 May 2020 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
@Sivakumar1605: it would be useful, but this is not currently technically possible. There is an open phabricator task (phab:T238309) to add it, but it hasn't seen much discussion there and the only technical respondent so far was unconvinced of the need. It has remained prioritised since November 2019. If you or anyone else knows of any previous discussion about this idea on-wiki it would be useful to link to it. Thryduulf (talk) 10:03, 12 May 2020 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Adding images to all created article
Images should be added to all articles inorder to put more beauty into it. We all know the images gotten from Wikimedia Commons is the one added to Misplaced Pages. 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 Misplaced Pages. Images mean a lot it can describe what the article is talking about,it add to beauty,it give more meaning to article and other beneficial uses. Article standard can be completed using images. Images are powerful than seen. Let images be in all articles to give it more standard. Tbiw (talk) 11:16, 13 May 2020 (UTC)
There are several sets of articles that do not have images:
Those for which a suitable image is available but nobody has added yet. Please add these images to the article.
Those for which a suitable image is (potentially) available but is not on Commons (yet). Most articles about living people that do not have an image are in this set for example.
Those for which an image would be suitable but no such image is known to exist. For example most articles people that lived before the invention of photography.
Those articles for which an image does exist, but due to legal or policy reasons cannot be included on Misplaced Pages. For example images of copyrighted buildings in countries without freedom of panorama.
There are a small subset of articles where the restriction is not copyright but something else, for example we cannot legally include a freely licensed image of child pornography (assuming such an image exists, for obvious reasons I've not investigated).
Those articles for which no suitable image can exist. For example articles about abstract concepts such as Hermitian matrix or Li (Confucianism).
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 Misplaced Pages works. Decisions on Misplaced Pages 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. Misplaced Pages is only may chance of getting engaged during the lockdown please don't block me Tbiw (talk) 21:06, 14 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 Misplaced Pages 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)
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)
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:Misplaced Pages 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:Misplaced Pages 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)
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 Misplaced Pages: 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 Misplaced Pages: 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 Misplaced Pages: 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 Misplaced Pages: 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)
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.
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.)
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. Misplaced Pages is probably biassed to things going on in the recent past (the article Criticism of Misplaced Pages 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 Misplaced Pages does mention that Misplaced Pages 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)
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. — Wug·a·po·des 20:11, 14 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 ANdiscussions, 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). Enterprisey (talk!) 01:07, 15 May 2020 (UTC)
For a listing of ongoing discussions, see the dashboard.
Schazjmd (talk) 01:43, 12 February 2020 (UTC)
Following a half-month incubation period at the Idea Lab, a major RfC has been launched consisting of a series of independent proposals to modify the sidebar located on the left side of every page in the desktop default skin view of Misplaced Pages, aimed at improving usability and ease of navigation. You are invited to join the discussion at Misplaced Pages:Requests for comment/2020 left sidebar update. {{u|Sdkb}} 21:51, 10 April 2020 (UTC)Template:Z48
. In fact, editors often fill the 
Hello, username! I saw you made WP:Example into a redirect. I noticed there are some pages on the wiki that still link to the redirect. You can see a list of these pages below:
CheckUser is not for fishing. How would the bot distinguish socks from unlucky matches? Suffusion of Yellow (talk) 22:08, 7 May 2020 (UTC)
Moved to Misplaced Pages:Village pump (technical) § Add option filter data in tables