Wikipedia:Village pump (proposals)
Policy | Technical | Proposals | Idea lab | WMF | Miscellaneous |
New proposals are discussed here. Before submitting:
- Check to see whether your proposal is already described at Perennial proposals. You may also wish to search the FAQ.
- Consider developing your proposal at Village pump (idea lab).
- Proposed software changes should be filed at Phabricator (configuration changes should have gained a consensus).
- Proposed policy changes belong at Village pump (policy).
- Proposed WikiProjects or task forces may be submitted at Wikipedia:WikiProject Council/Proposals.
- Proposed new wikis belong at meta:Proposals for new projects.
- Proposed new articles belong at Wikipedia:Requested articles.
Proposal: New Village Pump Page
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
There has been a long recognized need for improved communication and coordination between the community and the Wikimedia Foundation. Too often Foundation plans have come as an unexpected and unwelcome surprise to the community. Too often community concerns or objections have come as an unexpected surprise to staff members. Better communication and collaboration would reduce the rate of conflict and failed projects. Staff members are generally enthusiastic about our public service mission, have good intentions, and want to help us. However to be frank, most of them know about as much about what goes on over here as most of us know about what goes on inside the Foundation. They are employees in a conventional top-down authority structure. Most of them have no experience in the community, and our consensus system is alien concept. Sometimes they struggle to understand how we work, what we want, what we need, and even how to talk with us effectively. There is a communication and culture gap.
I have seen positive efforts from the Foundation over the last few years. However I believe both sides need to work to bridge the communication gap. I have some ideas, and it begins with this proposal to create a new village pump page. The current Draft Village Pump Page header reads as follows:
The WMF section of the village pump is a community managed page. Editors or Foundation staff may post and discuss any information, proposals, feedback requests, or any other issues of significance to both the community and the Wikimedia Foundation. It is intended to aid communication, understanding, and coordination between the community and the Foundation.
There is currently a Pump Proposal open above, asking WMF Legal to enforce the Terms of Use against an abusive company. That is a prime example of kind of topics I envision for the new page. The Central Notice template also currently lists an RFC for the Foundation's rebranding strategy to rename itself from Wikimedia to Wikipedia. As part of that project they evaluated the level of community support and produced a report, which I believe has been delivered to the Board of Trustees. The report states Measure community appetite for change: ✓ 0.6% of informed oppose. The 0.6% oppose figure is in rather stark contrast to the over 92% oppose on the RFC. I have several other examples of confirmation bias in Foundation's gathering or handling of data. I believe bad data has contributed to some of the tensions between the Foundation and Community. The RFC page also has a Statement by the Foundation. Given how the RFC is going, I believe it is clear that the staff handling the project do not grasp the significance of the RFC.
I have long been following Foundation projects, plans, and strategy. I have a small pile of similarly significant topics for the new page, including matters of past and future Foundation strategy. As some of you may be aware the Foundation has finally given up on the Flow project, and a Consultation resulted in a decision to keep and enhance existing Talk pages. I am concerned that the enhancement project is going off course. For example, like Flow, the project has a design flaw that can result in wikitext content corruption. The manager has indicated that he considers it an insignificant matter, not worth fixing. One of my priorities for the new Pump page will be to provide more detailed information on the new Talk Page Project. I hope to bring that team helpful information on our needs, concerns, and expectations for any major changes to Talk pages.
Over the years I have had discussions with several top managers, with the previous Executive Director, and with the current Executive Director. I believe the Executive Director would be receptive if we produce some consensus message regarding Foundation strategy and engagement. That is beyond the scope of the immediate proposal.
Proposed: Install Draft Village Pump Page. The page may of course evolve based on comments here or later. Alsee (talk) 12:04, 29 January 2020 (UTC)
Responses (NEW VP)
- Support as proposer, per the rationale above. Alsee (talk) 12:04, 29 January 2020 (UTC)
- Support Additional communication is a good thing! This makes hella sense! GenQuest "Talk to Me" 12:53, 29 January 2020 (UTC)
- So another village pump page that most people won't watch? Much less WMF? Nah. --Izno (talk) 15:08, 29 January 2020 (UTC)
- Izno... Can you come up with a better suggestion? We do need SOME way to facilitate more communication with the WMF. Blueboar (talk) 15:20, 29 January 2020 (UTC)
- Comment Previous discussion: Wikipedia:Village pump (proposals)/Archive 130#New Village Pump page?. Anomie⚔ 15:23, 29 January 2020 (UTC)
- Support concept, but in practice, this will need buy-in from the WMF - if they don't use it, then there's no point. creffpublic a creffett franchise (talk to the boss) 15:32, 29 January 2020 (UTC)
- In my opinion, such a thing is better placed on the Meta wiki; that's where the WMF does most of its work and it would make this venue usable for non-enwiki projects as well. Jo-Jo Eumerus (talk) 15:47, 29 January 2020 (UTC)
- Support as beneficial, even a less active Village PUmp page would be seen more then the current set-up which is basically "meta pages only seen by a couple of keen souls. They panic and dump on CENT after a significant delay". The only other action that could provide a substantial assistance would be something akin to Tech News "WMF Newsletter". The issues with this are threefold: you'd need about 200 sign-ups to get reasonable awareness; you'd need several active people to run it reliably; some major WMF discussion areas would need much quicker response times than (a max) 30 days to give a chance for proper discussion. Nosebagbear (talk) 15:53, 29 January 2020 (UTC)
- Summoning @Whatamidoing (WMF):... — xaosflux Talk 16:13, 29 January 2020 (UTC)
- User:Nosebagbear, rather than creating Yet Another Newsletter that nobody reads, the English Wikipedia would probably find it easier to promote the WP:Wikipedia Signpost, which already has the subscribers, and which could be a reliable source of information that mattered to this particular community. Whatamidoing (WMF) (talk) 23:45, 30 January 2020 (UTC)
- Support concept per Creffpublic's similar comment above, but Jo-Jo Eumerus has a good point too. Ivanvector (Talk/Edits) 16:57, 29 January 2020 (UTC)
- Strong support Regarding Jo-Jo Emerus's comment; Meta is where the WMF does most of its work, but the problem with discussions on Meta is that members of the individual communities rarely go there and can easily miss important discussions. Having a page here to discuss things with the WMF makes it easier on the community. Such a page can house links to important discussions that are taking place on Meta, thereby driving traffic there. ~ ONUnicorn(Talk|Contribs)problem solving 17:05, 29 January 2020 (UTC)
- ONUnicorn, have you heard about User:DannyS712's work on a global watchlist? Flow/Structured Discussions, which is widely used at MediaWiki.org, will ping people with every new discussion thread on a watched page. That's great for cross-wiki notifications, but at Meta, your options are either changing your prefs to email you for every change to your Meta watchlist, or hoping that we get a global watchlist. Whatamidoing (WMF) (talk) 23:48, 30 January 2020 (UTC)
- @Whatamidoing (WMF): I'm glad you find it useful. Useful enough to support the grant request / incorporate it as an extension? See m:Grants:Project/Create a global watchlist extension DannyS712 (talk) 23:58, 30 January 2020 (UTC)
- Yes, I'm aware of the global watchlist project. I also have no idea why it's relevant to this discussion. ~ ONUnicorn(Talk|Contribs)problem solving 01:13, 31 January 2020 (UTC)
- Being able to see, while you're still "here", that a discussion page has changed "there", seems like a way to improve the problem you identified, that "members of the individual communities rarely go there and can easily miss important discussions". Whatamidoing (WMF) (talk) 20:10, 31 January 2020 (UTC)
- Yes, but in order to add a discussion "there" to your global watchlist, you need to first be aware that it exists "there". ~ ONUnicorn(Talk|Contribs)problem solving 20:42, 31 January 2020 (UTC)
- I agree with you that it's not a complete solution, but it could improve the situation, especially if you put Meta's central announcement pages, such as m:Template:Main Page/WM News, on your watchlist. Whatamidoing (WMF) (talk) 21:50, 31 January 2020 (UTC)
- Yes, but in order to add a discussion "there" to your global watchlist, you need to first be aware that it exists "there". ~ ONUnicorn(Talk|Contribs)problem solving 20:42, 31 January 2020 (UTC)
- 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)
- 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)
- Support Having a dedicated page for communication with the WMF seems like a no-lose proposition. I think it needs to be two-way; people should be able to post questions for, and expect answers from, Foundation personnel, and the Foundation should also be expected to make announcements for the community, using the page. I can't think of a downside to this proposal. --Jayron32 17:08, 29 January 2020 (UTC)
- Support A direct way to see WMF related proposals, and for clear, one on one communication with them? Yes please! This would, hopefully, greatly help with places where the WMF clearly didn't get proper consensus, and would allow for us to bring proposals their way in a place everyone would see. --moonythedwarf (Braden N.) 17:24, 29 January 2020 (UTC)
- Support in principle per Creffett. I would love to see this happen. Our best chances for greater two-way communication with the Foundation may be by raising it as an issue in the Board of Trustees election. EllenCT (talk) 19:13, 29 January 2020 (UTC)
- Support - Having a centralized enwiki discussion forum for interacting with WMF would be beneficial. I hope that WMF agrees. - MrX 🖋 13:06, 30 January 2020 (UTC)
- Oppose. On issues for which the WMF is completely non-responsive, I don't think having a dedicated board would make them willing to respond. On issues where they are willing to respond, they're frequently willing to participate anywhere, unless it's a cross-project issue, in which case they'll sometimes only interact on Meta. The WMF has given no indication that they'd be more willing to use a dedicated forum. The task of dragging the WMF into areas where we can have some level of mutual awareness is going to take a long time. The WMF has the ability to communicate things well, they even use a wiki internally to host things like every team's weekly report (which they won't let us see, or comment on), but as far as I can tell, they just don't want to allow that much WMF-community interaction, for reasons unknown to me. --Yair rand (talk) 01:08, 31 January 2020 (UTC) seems fine, but
- Oppose, I wonder, why the enWP, who already is the center of the anglocentric WMF, is complaining, just go to Meta, unfortunately for the non-anglophone projects they seem to speak only english over there. This sounds to me more like a venue, whre the WMF can pretend to talk with the community, while they are talking just to a tiny peace of the community, bur one that conveniently speaks the only language they seem to know. Grüße vom Sänger ♫ (talk) 05:19, 31 January 2020 (UTC)
- Support concept but different name and framing WMF communications happen in a decentralized way and there are regular disagreements about what WMF representatives communicated effectively and what was hidden in some out-of-the way area. I support the idea of centralized posting but think it should be either outside the village pump, or if listed with the village pump boards, then it should have a different name and branding. WMF communications are different because everything that organization does is entangled with money and someone's career, and consequently much of that organization's activity here is in a conflict of interest with some individual or team's financial livelihood. The interests of the Wikimedia Movement and the Wikimedia Foundation often diverge, and staff of the Wikimedia Foundation are not part of the Wikimedia community in that they each have a commitment to serve the interests of the Wikimedia Foundation as an organization and favor that organization in the case of any conflict between the Wikimedia Community and that organization. The reason why the village pump is not the place for WMF discussion is that the village pump is established as a community volunteer space. Instead, I think the right board for the WMF would be something like a Wikipedia:Local Embassy, where the WMF sends its diplomats and negotiators into English Wikipedia space to negotiate something. Maybe the WMF should set up embassies wherever it would log its efforts to establish agreements with a local Wikimedia community. The idea of a central space is great. We should distinguish ideas and proposals from the WMF from ideas and proposals from Wikimedia community volunteers, though. Blue Rasberry (talk) 19:57, 31 January 2020 (UTC)
- Support concept. I am a little concerned that not all the messages that would be posted to such a board would actually be matters that require the attention of the WMF. There should be norms established that if inappropriate content is added, it can be moved to a different pump page. Sdkb (talk) 21:29, 2 February 2020 (UTC)
- Support the concept... but I ain't holding my breath on this being useful if the WMF decides to have a rerun of the Fram and Flow Show. —A little blue Bori v^_^v Onward to 2020 23:43, 3 February 2020 (UTC)
- Dont mind, but don't think it will approve communication of either the foundation or the community one bit. The problem is not the amount of locations to discuss, its that there are too many stakeholders with too many different opinions and too many thing happening to keep track of no matter what you do. —TheDJ (talk • contribs) 09:18, 6 February 2020 (UTC)
- Support Concept per above, especially Creffet and EllenCT. Puddleglum 2.0 20:29, 7 February 2020 (UTC)
- Support this idea for now. Anything to open constructive communications seems fine. I would like to suggest we review the actual results later. a channel to discuss things with WMF seems fine, but we should also hjave the option to look at other methods later, if this new idea doesn't have the full effect desired. --Sm8900 (talk) 04:28, 10 February 2020 (UTC)
- Support the concept of constructive communications with "norms established": I am one of those that very rarely "go there" (Meta), and think comments to "just go to Meta" are out of touch, as I imagine many also don't "go there". I think there would be community benefits in this proposal and help others not "easily miss important discussions". We "advertise" to get involvement so why not have a local centralized place? Will the WMF get involved or "buy-in"? I don't know, but I will continually assume good faith that others will do the same. If true, the comments "WMF is completely non-responsive" might be a reason that a collaborative effort (and a fairly large show of support), will hopefully gain more involvement ("WMF-community interaction"), and "might" be a game changer, or not. We will never solve issues or find solutions by just complaining and not trying. I do not know anything about "anglocentric" concerns (Is this a real problem and how is it really relevant here?) the WMF "might" be complaining about. I assume enWiki is among the more active projects. I cannot help where I was born (demography of the editors), but this is where I am, and I imagine that is true for the many on this project. The WMF has to understand that it is not the fault of any considered anglocentric that broad community involvement somehow created some sort of bias. I want to see worldwide involvement but I only speak English so my endeavors, that consume most of my free volunteer time, would very logically be focused here, so I "favor this organization" for obvious reasons. The WMF and the other projects need to worry about their end. On this "end" I would like to see better communication (dedicated forum?) and support anything in that direction. Maybe a new tab here, or another supported location, but I don't see that Wikipedia:Local Embassy ("Wikipedia-related multilingual coordination") would be proper. If the WMF is picky about what involvement they wish to be involved in, then at the least, we can have a central location for discussions and potentially important news, as well as hopefully collaborative communication. Any thoughts that we possibly somehow shouldn't continually make attempts doesn't seem logical. Otr500 (talk) 17:41, 11 February 2020 (UTC)
Discussion (NEW VP)
Jayron32, you used the phrases 'expecting answers' and 'expecting announcements' from the Foundation. I want to emphasize that this is a community page, and creating a community page does not create any particular obligation on the Foundation. An appearance of imposing an obligation or responsibility onto the Foundation could raise objections and resistance. The new page is a workplace for us, and I wish us to extend an open invitation to the Foundation utilize the page. I hope and believe they will accept that invitation (likely with hesitation and fear, as conflicts have been painful for both sides). The only expectation on the Foundation is that they continue their existing efforts, and I have hope that we can help work towards improvement. Alsee (talk) 22:05, 29 January 2020 (UTC)
- See, I still feel that is backwards. Wikipedia and the en.wikipedia community does not exist for the purpose of supporting the whims of the Foundation. The Foundation exists to support the work of the volunteers and the various communities of the Wikipedia movement, and increasing and improving communication between the Foundation and the communities it serves is what we should be focusing on. We should not be focused on being better foot soldiers blindly following whatever mission the Foundation has decided to set us upon, we should be expecting and receiving support from the Foundation for the purpose of building an encyclopedia. Where conflicts have been painful have been where the Foundation has acted unilaterally and in its own interest without regard for the interests of the Community. The expectation is, the Foundation should seek input and advice from the community on major issues, and that the Foundation should be willing to respond to legitimate concerns from the community. If they are not willing to do either of those things, the noticeboard is pointless. --Jayron32 12:40, 30 January 2020 (UTC)
I will pass along a link to this discussion, but I think I can predict some of the questions I'll get, so perhaps some of you would like to start answering them now, just in case:
- 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 Wikipedia need to be talking to many.
- For example, WMDE is finishing up a project that will change the
<ref name="Alice">
syntax to do something similar to the {{sfn}} templates. I'm not taking bets on how long it will take for someone to complain that "the WMF" did this "unwanted" work (which was democratically selected through a public, on-wiki voting process), but I do want to point out that if you're setting up a page for just the WMF, you are excluding all of the (multiple) organizations whose activities affect us here. - To give another example, see 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 [even though most of it would be irrelevant to them], but I do not expect that to happen.) Whatamidoing (WMF) (talk) 23:41, 30 January 2020 (UTC)
- Whatamidoing (WMF) You mentioned above the global watchlist work; and here you list several items that can be summarized as, "people should use Meta". One thing I'm thinking this would be useful for is as a repository for links to important discussions happening on Meta. Because if there is a discussion happening on Meta, but people who would be interested aren't aware of it, they aren't going to participate. A global watchlist to remind you to check up on developments with discussions you are interested in on Meta is only useful in as much as you are aware of the discussion and have added it to your watchlist. People on en wiki are constantly surprised when action gets taken as a result of a discussion happening on Meta that affects 100% of the en wiki editing community, but less than 1% of the community was even aware the discussion was occurring. The end result is that the WMF looks like the Vogons in Hitchiker's Guide to the Galaxy.
My thought is that the board could be used to post announcements about discussions happening on Meta, with reminders to discuss this there. ~ ONUnicorn(Talk|Contribs)problem solving 14:57, 31 January 2020 (UTC)“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:Wikipedia:Projektneuheiten, which is specific to technical changes, or w:fr:Wikipédia:Annonces, which is general news). Subject-specific pages might improve the perceived signal-to-noise ratio for readers. I recommend against making it WMF-specific, as this community is affected by far more organizations and individual-led projects than just the WMF. You might want to talk to the Signpost about this, as they have some experience with announcements, and they already have an audience.
- It won't solve the problem that most people won't read it (or remember what they've read). I've manually posted messages to more than a hundred high-traffic pages, and run site-wide banners to 100% of logged-in editors for weeks, and still had editors say they never heard about it; I've seen a CENT-listed, month-long RFC here at VPPR, with 20+ editors supporting it and nobody opposing it, get overturned because some other editors didn't notice the RFC; I've even seen someone actively participate in a discussion on wiki, and then ask a month later why nobody ever discussed the subject. There is no way to make people read and remember everything that's relevant to them. But the fact that it won't be a total and perfect solution doesn't mean that it's not worth doing it at all. Whatamidoing (WMF) (talk) 20:45, 31 January 2020 (UTC)
- Whatamidoing (WMF) I find it ironic that you come here opposing the new page and apparently blaming me regarding the WMF cramming the visual editor down our throats. It's ironic because, on exactly the issue of WMF's VE throat-cramming, you are responsible for letting us get to the brink of second Superprotect-level crisis. In case you don't recall you were liaison for the Single Edit Tab (SET) deployment. I told you that the manager explicitly assured me it would NOT be deployed as VE-default without a community consensus. I repeatedly asked you weather the the product was going to deploy with a VE-default. I presented a pattern of evidence that the product was about to deploy with a VE-default. Your responses and denials on the subject turned out be... unhelpful and untrue... that is the most generous way I can put it. Furthermore the manager on the project later asserted surprise at the issue... suggesting that either (1) you failed to ask or mention the issue with staff or (2) the manager was lying. I will not speculate between those options. In any case, the project for which you were liaison was in fact deployed with a VE-default. Exactly as I anticipated. Exactly as I repeatedly brought to you in advance. After deploying the VE-default the Foundation went non-responsive for well over a week, despite attempts to reach the Foundation in multiple places including the manager's personal talk page. We only got a response when I escalated the issue to the Executive Director's talk page! She had to summon the manager to give an answer. The manager gave us assurances that it was a bug and that he would fix it. More than a week went by with no action. We went back to the manager and he told us that VE-default was always his intention and he had absolutely no intention of fulfilling his promise to change it. At that point things went from ugly to obscene blatant bad faith. He was outright called a "liar", and ANI decided that "liar" was not uncivil given the diffs of his own words. A community member then wrote a hack for the sitewide javascript to change the default. The community members involved were acutely aware that hacking the sitewide javascript to explicitly override a manager was putting us on the threshhold of repeating the Superprotect incident. Note that the manager said it was a bug - so either the javascript hack was an undisputed bugfix or the manager was acting in deceitful bad faith. Either way the editors involved considered the javascript absolutely justified. At that point the manager finally agreed to fix the default-editor from his end, as he had promised to do a week earlier.
- Whatamidoing, I respect your work and experience and expertise and dedication as a community member. However as a liaison your job was to prevent any of that from happening. I persistently attempted to ask you and warn you, attempting to head off the impeding problem. The reason I want this new Pump page is because you and other staff consistently ignore my accurate warnings that manure is about to hit the rotary air-mover. I am trying to tell you that there are a whole series of fans spinning right now. Maybe I'm overly optimistic, but I'm hoping the new page will help us sort out issues before they escalate to crisis. I hope the page will help us get moving in a common direction.
- To minimize WallOfText I'll limit my reply to that one subject. Oh, and Spoiler Alert, the Foundation is about to release hard data on how badly a VE-default reduces edits. Alsee (talk) 18:36, 31 January 2020 (UTC)
- Last I checked, I still hadn't been appointed queen of the wikiverse. (I'm sure it's just an oversight.
;-)
) However, until that happens, I can't actually prevent everything that I'd like to prevent, any more than I can force someone to build the things that I want built (e.g., phab:T89970). - The movement might need a clearer understanding of which groups ultimately get to make which kinds of decisions, and specifically where the English Wikipedia's editors fall in a typical responsibility assignment matrix for different kinds of projects undertaken by outside communities. Are you supposed to be "informed" or "consulted" about projects that affect you, but the people responsible for the project get to make the decisions? Or do you see yourself as the ultimate "approver" or "decider", with veto power over everyone else? The volunteers in the Strategy Working Groups have proposed that a movement charter be written to clarify some of these points of contention. Perhaps having a document that explicitly says something like "An online community {can|can't} veto a project that affects that online community, but which was undertaken by another group" would forestall some of these disputes by preventing all sides of any dispute from thinking that their side has the ultimate decision-making authority. Whatamidoing (WMF) (talk) 21:24, 31 January 2020 (UTC)
- But the Foundation did appoint you queen of Single Edit Tab liaising. You do an excellent job as liaison - until the Foundation agenda is questioned. At that point you tend to cease liaising. That doesn't serve the community or the Foundation. I can't decide whether it's better or worse than a liaison who lacks your community knowledge and understanding. The job should be to facilitate communication, understanding, and collaboration between the Foundation and the community. One of the most important things is to alert staff of any issues that may negatively impact their work, especially any potential or actual opposing consensus. Those staff then need your expertise and help to reach a viable resolution. Too often such situations go unacknowledged until too late. Most staff don't seem to have have the mandate or understanding to constructively engage that kind of situation. That leaves us with unconstructive approaches and bad outcomes. The Foundation and community need to work as partners.
- Regarding Responsibility assignment matrix, I spent some time absorbing the page. The models generally seem to presume a context essentially internal to an organisation, generally everyone is an employee. It's a bit more complicated to apply the models here. I will try to summarize my view this way: Those models generally acknowledge approval may be needed from multiple parties to initiate a project and/or approve deployment. I acknowledge the Foundation has something approximating universal veto of every stage of anything affecting them or expending their money or labor. Wikis should get broad local decision-making on things affecting us, and I see cases where a global level consensus could apply. For example the Foundation sometimes cite the issue of a wiki unreasonably blocking some deployment - perhaps even one admin on a tinywiki. The community has the solution. It's documented in WP:CONLEVEL. If a wiki goes Nationalistic and violates NPOV and abuses admin tools, the global community can revoke the admins and reboot the wiki. If a wiki is unreasonably obstructing some deployment, global consensus can assert global deployment. Problem solved - if the Foundation engages consensus. Alsee (talk) 09:57, 1 February 2020 (UTC)
- Liaison work, as any professional liaison officer could tell you, does not mean that you can always make two sides agree. It is possible to do excellent work as a liaison (i.e., as a person who carries information from one side to the other, and back again) and still end up with an intractable disagreement.
- Before we could agree that things could be done by global consensus, we would have to have a consensus that consensus is the movement's method of making decisions. "The consensus of people who showed up" is mostly how we do it here at this wiki, but it is not how things happen in other communities. Some prefer straight-up majority votes or super-majority votes. There are also disagreements about what to do when there's no consensus. The Strategy volunteers favor the idea of a more integrated movement, but I think that will require us to spend time sorting out the details. For example, is it each human who gets a "vote", or each community or organization? And how do we respect devolution and local autonomy if we all get to vote on other group's affairs? (Surely we wouldn't want to say that the 99% of us who don't speak Swedish get to tell the relatively few Swedish speakers what they're supposed to be writing about.) And what do you do about intractable disagreements, e.g., that on the one hand, "the Foundation has something approximating universal veto of every stage of anything affecting them" but on the other hand, this community very much wants to have the opposite outcome, and sees itself as being the primary party affected by a WMF decision? Whatamidoing (WMF) (talk) 22:10, 3 February 2020 (UTC)
- Last I checked, I still hadn't been appointed queen of the wikiverse. (I'm sure it's just an oversight.
Sdkb, we'll collectively sort out how the page actually gets used. But for what it's worth, my concept for the page is "about WMF" rather than "to WMF". For example I picture anyone could post "The WMF is working on X", information which might be of interest here. That post might or might not spark a conversation. That conversation might or might not rise to a level where we want to actively talk to the WMF about it. Although I do anticipate a need for feedback-to or discussion-with the WMF for some initial topics that I want to post. Alsee (talk) 12:34, 3 February 2020 (UTC)
- I support Alsee's proposal. and this new resource would be beneficial to WMF, and to Wikipedia. --Sm8900 (talk) 18:44, 9 February 2020 (UTC)
Proposal to streamline the welcome template
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Template:Welcome (the standard welcome template) contains too many duplicate or unnecessary links and needs some streamlining so that new users aren't paralyzed by choice. For instance, it currently suggests four different places to go if you have a question[a] and four different tutorials[b]. Following a survey of Wikipedia's introductory materials, I drafted some changes to streamline the template that establish a clearer visual hierarchy to point new users to our best resources and remove more minor links to topics covered in Help:Introduction (such as the Manual of Style). After receiving some positive feedback at the Welcoming committee WikiProject, I'm bringing it here to establish a broader consensus for implementation. Here's the proposal:[c]
Welcome!
Hi [Username]! I noticed your contributions and wanted to welcome you to the Wikipedia community. I hope you like it here and decide to stay.
As you get started, you may find this short tutorial helpful:
You may also want to complete the Wikipedia Adventure, an interactive tour that covers the same topics.
If you have any questions, we have a friendly space where experienced editors can help you here:
If you are not sure where to help out, you can find a task here:
Please remember to sign your messages on talk pages by typing four tildes (~~~~); this will automatically insert your username and the date.
Happy editing! Sdkb (talk) 21:42, 11 February 2020 (UTC)
The full code (which includes customization options) is at the template's sandbox. Please let me know what you think! Cheers, Sdkb (talk) 21:42, 11 February 2020 (UTC)
- ^ The Teahouse, WP:Questions, the welcomer's talk page, and the new user's own talk page
- ^ WP:Introduction, WP:Getting Started, WP:Contributing to Wikipedia, and the WP:Wikipedia Adventure
- ^ Note: Refactored 03:08, 27 February 2020 (UTC) by Sdkb (talk) to include Task Center button.
Initial comments copied over from the Welcoming committee WikiProject:
:I most often leave GF newcomers the {{Welcome!}} or {{Welcome-anon}} templates. I prefer the proposal by Sdkb as simplifying their choices to one of two, rather than a roster of policies and procedures. We may want to have a third choice for people who appear to be creating a draft article? - Bri.public (talk) 17:30, 27 January 2020 (UTC)
- @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 Wikipedia. It's amazing how different it is vis-a-vis choice paralysis compared to the other options, especially the more "graphical" options, which tend to look overwhelming.
- Having just praised the simplicity and restraint of the links included..... I find myself wanting to add a link to the Five Pillars, because I think the one aspect that's missing right now is an approachable entry point to the core goals and norms of Wikipedia. Of the resources intended to introduce that information, I think the Five Pillars page does the best job of hitting the key points in a visually approachable way. I wonder if it can be slipped in as a sentence or phrase that doubles as a wikilink somewhere? So it's not an immediate "call to action" but it's present for a newbie to find early in their process of exploring. Or -- could it be added to the Introduction help page itself? I think that helping newbies feel like they have a handle on the core principles of the culture and norms is as important as technical knowledge.
- I'd be very happy to see this template in use, though, with further tweaking after it's entered the real works! Well done on the research and design work to build a compelling alternative. ~ oulfis 🌸(talk) 04:28, 30 January 2020 (UTC)
- Thanks for the praise, Oulfis! Regarding the pillars, the second module of the linked introduction is titled "Policies and guidelines", and while it doesn't explicitly list the pillars, it does mention that the project is "founded on five fundamental principles" and goes on to cover them. Sdkb (talk) 05:24, 30 January 2020 (UTC)
- @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)
- That's a good point (about the separate section). I know nothing about making templates, I just admire and appreciate them. Schazjmd (talk) 01:43, 12 February 2020 (UTC)
- I use the Welcome template regularly, especially when I see a red Talk box in a history. Concistentcy in the wording would be a good change. Allowing an article name to go in from a box in more places would be good, too. Perhaps we could allow a choice of images, not just cookies, as we already have in some barnstars. There are too many ways to warn new users or IP users, and not enough ways to welcome a new user with many or especially good contributions. Good idea to post the revision here for us to see and comment on. Cheers!--Dthomsen8 (talk) 02:14, 12 February 2020 (UTC)
- That's a good point (about the separate section). I know nothing about making templates, I just admire and appreciate them. Schazjmd (talk) 01:43, 12 February 2020 (UTC)
- 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)
- Strong oppose choice of links "if only one page"...should be WP:Contributing to Wikipedia. .Not good feed back or good data for multi-page tutorials that are not formatted property for mobile view. Main problem I see above is the fact our main intro page is missing WP:Contributing to Wikipedia (the page with all the info, links to all the main help pages, and videos, brochures produced by this community and the Wikimedia Foundation). We have learned over the years the "Next page style" doesn't retain readers. Should not replace links to our help articles maintained by the community with mobile view format problem tutorials that lack basic info and our outdated. If trimming of links is required...tutorials should go and our 3 main help articles that have watchers to help should be retained. Don't send new editors on a goose chase trying to find information ...make it available on one page with a nice TOC for navigating to the section most relevant. Raw data Wikipedia:IntroductionDaily average:723....next page Daily average:85...page after that Daily average:44.....by page 50 only 6 virws. People dont want a list of link to another list of links.....they want serviceable info at a glance in a recognizable format.--Moxy 🍁 06:42, 12 February 2020 (UTC)
- Hi Moxy — I'm very much with you about reducing the lists of links, so hopefully we're at least in agreement about the overall need to streamline. Funneling users to a single intro when we currently have multiple is unfortunately going to have to involve stepping on someone's toes. I see that you're by far the top contributor to WP:Contributing to Wikipedia, so I apologize, but in its current state it just does not feel as modern and user-friendly as Help:Introduction. Essentially all other large websites (which, let's be honest, devote a lot more resources to user interface issues than we do) have onboarding processes for new users that use multiple short pages as Help:Intro does, rather than one really long one. I have to imagine they know what they're doing. Sdkb (talk) 21:49, 12 February 2020 (UTC)
- We will simply have to disagree. ..... I don't see how info separated out over 50 different pages that does not work properly in mobile view is more helpful ...run around setup.--Moxy 🍁 22:32, 12 February 2020 (UTC)
- Hi Moxy — I'm very much with you about reducing the lists of links, so hopefully we're at least in agreement about the overall need to streamline. Funneling users to a single intro when we currently have multiple is unfortunately going to have to involve stepping on someone's toes. I see that you're by far the top contributor to WP:Contributing to Wikipedia, so I apologize, but in its current state it just does not feel as modern and user-friendly as Help:Introduction. Essentially all other large websites (which, let's be honest, devote a lot more resources to user interface issues than we do) have onboarding processes for new users that use multiple short pages as Help:Intro does, rather than one really long one. I have to imagine they know what they're doing. Sdkb (talk) 21:49, 12 February 2020 (UTC)
- We have lots of welcome pages, no objection to another being created. But changing the default this radically should not be done without first testing different welcomes and seeing which has the best result in terms of turning newbies into regulars. ϢereSpielChequers 08:02, 12 February 2020 (UTC)
- I see these changes as an improvement to the standard welcome template, not an alternative to it; they're substantial but build on what's currently there rather than replacing it from scratch. More to the point, since so many editors default to using the standard welcome, I think it's important we make that one as good as it can be; the old one could be renamed to something else if any editors really want to keep using it. I also don't think it's great to have too much welcome template proliferation — we need to keep our best resources centralized so they can be maintained/improved, not fork them every time there's a controversial upgrade.
- Regarding testing, I'm very much behind the idea of doing some A-B testing in theory, but when we previously discussed it, it didn't seem to be very practical. It would take a long time to build up a sample (since I don't know of any way to welcome newbies in bulk) and would take some programming to measure the results. If you or someone else has the expertise and time to conduct that sort of experiment, I'd be fascinated to see it, but barring that, we should act boldly and go with whatever we think will likely work best. We risk as much through inaction as through action, and there's a lot of room for improvement in converting readers to editors. Sdkb (talk) 22:23, 12 February 2020 (UTC)
- @Sdkb: off the top of my head, you could create two redirects, E.G. WP:TEST1 and WP:TEST2 that both go to the same page. Have the template randomly link to one of them on each transclusion. After a few days/weeks, compare the number of page views each redirect got with the number of back links to show which had the most best ratio of clicks to transclusions. — 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)
- @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)
- 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 Wikipedia:Tutorial vs v:WikiJournal_User_Group for a flexbox equivalent for tabs). T.Shafee(Evo&Evo)talk 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)
- @Sdkb, From Hill To Shore, and ToxiBoi: I've updated the Template:Intro_to/sandbox to work pretty well on mobile I think (as well as making the window on a desktop narrow). I'd welcome any testing by others though! Formatting parameters now controlled through Template:Intro_to/styles.css. Side-by-side comparison to Wikipedia:Tutorial on others' devices also valuable. Just waiting for the sandbox version to be copied over to the main template before it's viewable as the default for all pages using that template. T.Shafee(Evo&Evo)talk 07:25, 1 March 2020 (UTC)
- @Evolution and evolvability: Good work, the problems I was seeing in Firefox on Android have now gone. From Hill To Shore (talk) 14:18, 1 March 2020 (UTC)
- @Sdkb, From Hill To Shore, and ToxiBoi: I've updated the Template:Intro_to/sandbox to work pretty well on mobile I think (as well as making the window on a desktop narrow). I'd welcome any testing by others though! Formatting parameters now controlled through Template:Intro_to/styles.css. Side-by-side comparison to Wikipedia:Tutorial on others' devices also valuable. Just waiting for the sandbox version to be copied over to the main template before it's viewable as the default for all pages using that template. T.Shafee(Evo&Evo)talk 07:25, 1 March 2020 (UTC)
- @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)
- A note regarding mobile formatting: I fully agree that ability to read on mobile is vital, and the
- Another idea After looking over some research that was done on the welcome template rhetoric in 2011 that noted that new users are often unsure where they can be useful, another potentially useful link that occurs to me (probably as a second white button) is Wikipedia:Community_portal#Help_out or perhaps Wikipedia:Task Center, both of which have lists of tasks needing attention associated with links to guidance on how to do them. Thoughts on that? Sdkb (talk) 23:49, 24 February 2020 (UTC)
- We had talked about linking the main To-do page Wikipedia:Maintenance in the past but most seem to think that pointing new editors to what to do page off the bat would not be all that helpful. I personally think Wikipedia:Maintenance gives a good overview. PS was looking for this link for hours last week.... As it was one of the reason WP: contributing to Wikipedia was updated with Foundation brochures and added to the templates.--Moxy 🍁 00:02, 25 February 2020 (UTC)
- @Moxy: WP:Maintenance is certainly comprehensive, but I'm not sure it's accessible to new editors. It has too much detail on too many tasks — for instance, the very first item after the intro is a full section on copyvio, a complex area I'm not sure many new editors are going to want to dive into. I think the best approach for new editors is to provide a bunch of options of areas where help is needed, let them choose one, and then provide instructions for that area and clear examples of pages where they can apply what they've learned. The Task Center does this with a short intro followed by a concise list of tasks. I like how it plugs the benefits of participating in different areas. The open tasks list has the advantage of listing actual articles editors can click on and then help out with. Overall, I'm leaning toward including the task center. Sdkb (talk) 07:19, 25 February 2020 (UTC)
- Update: I've added a button for the Task Center to the sandbox. If there are no objections, I'll wait a day or so and then refactor the proposal here to include it. Sdkb (talk) 00:19, 26 February 2020 (UTC)
- @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)
- We had talked about linking the main To-do page Wikipedia:Maintenance in the past but most seem to think that pointing new editors to what to do page off the bat would not be all that helpful. I personally think Wikipedia:Maintenance gives a good overview. PS was looking for this link for hours last week.... As it was one of the reason WP: contributing to Wikipedia was updated with Foundation brochures and added to the templates.--Moxy 🍁 00:02, 25 February 2020 (UTC)
- Comment: Research and testing It makes a lot of sense to actually assess how effective our welcome messages are, and to improve them where possible. Ensuring that not only the welcome messages, but also the pages they links to will display properly in mobile view seems almost as important as the effectiveness of the welcome template itself. Sadly, as Moxy has found, there seems to have been no serious research into the effectiveness of welcome messages and their impact on editor retention since around 2011/2012. (i.e. all pre Teahouse) All I could find is this, this and this, which was mentioned above.
- One 2011 study on German Wikipedia concluded that:
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 Wikipedia, there is a study currently ongoing by WMF researchers into Teahouse invitation message effectiveness. (Summary: It is comparing the old automated invitee selection process against an ORES-based editor selection process for HostBot to send out invitations to new editors who've made their first few edits here. The research process unfortunately contained a small number of variables which rendered the results on editor retention inconclusive, and a second wave of research will hopefully go ahead soon. It did not look at the effectiveness of the Teahouse invitation wording, or timing, - only the criteria for the selection of good faith editors to send them to. See here for summary and feedback)
- Now, it strikes me that the A/B study methodology used to look at Teahouse HostBot invitations must be very similar to that needed with Welcome messages. Therefore, I am pinging @Jtmorgan, Maximilianklein, and Halfak (WMF): in the hope that one of them might be willing to offer ideas or insight on whether any research study is currently ongoing or planned, and whether there might be a possibility of encouraging, supporting or funding an investigation into this important and related area of editor welcome and retention. Nick Moyes (talk) 12:34, 25 February 2020 (UTC)
- @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-Mo 19:53, 27 February 2020 (UTC)
- Simply is best in my view as per this - thus I use Template:W-short alot. Years ago we created 2 types of "MAIN" help pages - one static article style WP:Contributing to Wikipedia and duplicated that at info at Wikipedia:Tutorial with tabs/next buttons (see what worked best). We can see and saw by the numbers most dont go beyond the first page of the tutorial. This is also what happens at the Wikipedia:Adventure - 50 percent drop in views by the second page....with a loss of 90 percent by page 3. I am all for making things easier ...not harder by making people click 50 times to get serviceable information....less is best and of course mobile view must be considered. -- Moxy 🍁 14:22, 25 February 2020 (UTC)
- @Moxy: those numbers are certainly concerning. To me, they potentially point to those resources not being as well-designed as they ought to be. (Do you have a link to the data, btw?) Some dropoff is natural, though, since we're never going to convince everyone to read a full tutorial, and for all we know, the dropoff rate on the pages that present it all together could be even higher. (The metric we'd need to measure that would be average time spent on page, and probably only the WMF knows that.) The benefit of splitting materials into multiple pages is that short chunks are more digestible, whereas sending readers to one long huge page will overwhelm many and make them give up. Sdkb (talk) 00:03, 26 February 2020 (UTC)
- template:W-short should be the default. The Wikipedia Adventure is for children. — Preceding unsigned comment added by 2605:8d80:542:b5b3:65bb:37c9:5b31:11b5 (talk) 22:26, 25 February 2020 (UTC)
- Good day I phone user.....can you elaborate on your experience! I am assuming your our normal IP poster and get a lot of welcomes.....what template is used most in your case?--Moxy 🍁 23:35, 25 February 2020 (UTC)
The blue-with-white-text button seems wrong to me. I believe (though I might be wrong) that blue buttons have a specific semantic meaning on Wikipedia. On my desktop interface, the "Publish changes" button is blue/white, and the "Search" button on the search page is blue/white, implying submission of a request, not just a link. – Jonesey95 (talk) 05:03, 26 February 2020 (UTC)
- @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)
- Interesting read.--Moxy 🍁 05:32, 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:
- 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)
- 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)
- @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)
- Interesting read.--Moxy 🍁 05:32, 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)
- 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)
- 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! (contribs) 02:06, 28 February 2020 (UTC)
- If concerns are with the mobile app, I can see that happening. I won't be able to test that myself though. –ToxiBoi! (contribs) 02:07, 28 February 2020 (UTC)
- I strongly support this new welcome template. Simply put, less is more. This new message feels more personal and less like automated spam, it's got a clear actionable goal you can take to learn the basics about the site (rather than a dump of a couple dozen links that don't feel like they have a cohesive narrative) and it's less prone to being bloated over time. (Brought here by a neutral message at Wikipedia talk:Wikipedia Signpost/2020-03-01/Opinion.) — Bilorv (talk) 22:16, 4 March 2020 (UTC)
- Less links would be better. Should keep link to standard page over an assembly of tutorial pages. If simplicity is the goal then multiple page tutorials is not the answer.--67.201.160.202 (talk) 23:10, 4 March 2020 (UTC)
- Support generally as long as some of the other considerations above are taken into account, like making it mobile-friendly and reconsidering the first link. I personally would have loved to see the Teahouse link or the "Task Center" links earlier on when I first joined -- I only found out about them somewhat recently, but they both make Wikipedia way more approachable/simpler to new users. The simpler design of the template overall is also really approachable.
- My concern is that I don't think the first link is the most helpful introduction to editing. And I agree with some above that it should probably have either an option for or one extra link about drafting articles. - Whisperjanes (talk) 04:05, 17 March 2020 (UTC)
- @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 Wikipedia page and interactive Wikipedia Adventure tour cover the same topics.
It's worth noting that whatever we choose here will almost certainly be an improvement over the current version of the welcome template, which links first to WP:Introduction, an intro so bad it is likely to be converted to a redirect soon. Sdkb (talk) 06:37, 18 March 2020 (UTC)- Only agreement here is for less links.....no agreement to change to an action button....or to link the 60+ page intro over our main help pages....So really all we have is the WP:Introduction that will change to Help:Introduction but if we drop links multiple page tutorials should be dropped...As mentioned above ...best test before trying to implement multiple changes.--Moxy 🍁 06:50, 18 March 2020 (UTC)
- I actually do think they should be changed to action buttons, because they stick out more and I think are easier to read and click (although that's just a personal opinion). Testing it might also be a helpful step in this process (although I'm not sure how that's usually done on Wikipedia, or if it's really feasible). Although, I assume you have to make it first anyways to test it. So possibly finding a way to collect data on the templates already used, as editors have been talking about above. Whisperjanes (talk) 16:44, 19 March 2020 (UTC)
- @Sdkb: Thanks for following up! Yeah, now that you mention it, I'd be fine with leaving "your first article" out -- especially since I think most new users get on to make an edit first (from my personal observation). And it's hard to say which alternative for the introduction link... I would like to say Wikipedia:Contributing to Wikipedia (because it's written in a similar style to most guidelines... although, to be honest, it's incredibly dense and I'm not sure how helpful/quick it is to use). I was actually going to suggest Wikipedia:Introduction, until I read the current discussion happening on it. I'm not sure all of which pages exist out there for intros, but the one thing I think is most important is that it gives information on the first page immediately after you click away from your user talk page. That's why I'm not as much a fan of Help: Introduction (because the first page gives you a directory of links, not info). I actually think I would prefer Help:Introduction to Wikipedia because it brings you immediately to information, but the only downside is that if you keep clicking, it automatically teaches you Wiki markup, not the visual editor. Obviously, I have a lot of thoughts but not many answers, so I'm more open to seeing what others think than my own opinions. Help: Introduction might end up being the best option, I just find it daunting (to have to choose what you're going to learn before you understand Wikipedia, including which editor you want to use) and have a problem with the fact that it draws your eyes first to the editing interfaces, rather than the intro tutorial. Whisperjanes (talk) 17:11, 19 March 2020 (UTC)
- 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)
- @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
- I would be ok with....- -Moxy 🍁 07:02, 18 March 2020 (UTC)
Hello, Example, and welcome to Wikipedia! Thank you for your contributions. I hope you like the place and decide to stay. Here are a few links to pages you might find helpful:
You can visit The Teahouse to ask questions or seek help.
Please remember to sign your messages on talk pages by typing four tildes (~~~~); this will automatically insert your username and the date. If you need help ask me on my talk page, or , and a volunteer should respond shortly. Again, welcome!
- Late support from me too. I just saw the proposed template on a user talk page and was positively surprised. ~ ToBeFree (talk) 19:34, 18 March 2020 (UTC)
- My main concern has always been the removal of our main help page and the pillars for a tutorial that is 60plus page of info that just has more links.....a clicking nightmare for anyone with a disability. But after seeing another concern raised about visibility I wonder how many other people see little mini boxes? as seen here. --Moxy 🍁 21:11, 25 March 2020 (UTC)
- On my mobile browser (Chrome on Android), it looks fine (screenshot). This might be an issue to raise at Template:Clickable button 2, as templates such as the Teahouse HostBot invitation also use buttons. Sdkb (talk) 21:43, 25 March 2020 (UTC)
- What happens when you turn your phone sideways? Anyways... queation is should we direct new editors to 60plus non standard pages that may or may not work properly for mobile readers (the majority of out readers). Not sure why accessibility for disabled people is being thrown to the wind here.--Moxy 🍁 23:21, 25 March 2020 (UTC)
- Strong support for this new welcome template. Time for us to move forward with a good welcome template. Further improvements could be made after implementation right now.--Dthomsen8 (talk) 00:01, 26 March 2020 (UTC)
- Note: A little discussion spilled onto my user page and can be found at this thread. Sdkb (talk) 01:09, 28 March 2020 (UTC)
- Support - Admittedly I prefer the old one simply because it's what I'm used to however as Dthomsen8 says It is time for us to move forward and I agree with the nom that the old template had far too many links, Although the blue/white box is used for Publish changes I don't personally see that as a reason to oppose,
- The new template is a major improvement over the old one and so support it being the default one. –Davey2010Talk 10:58, 30 March 2020 (UTC)
Strong support of the proposal on teaching code to newcomer. also the page https://en.wikipedia.org/wiki/Help:Wikitext is difficult to follow. I am proposing for a easier help page with limited number of necessary commands. Currently I have kept the draft in my sandbox https://en.wikipedia.org/wiki/User:RIT_RAJARSHI/sandbox Regards and thanks RIT RAJARSHI (talk) 09:31, 1 April 2020 (UTC)
Proposals to redirect WP:Introduction/WP:Tutorial and the Welcoming Committee welcome
You are invited to join the following discussions:
- Wikipedia talk:Introduction#Proposal: Redirect this page and WP:Tutorial to Help:Introduction
- Wikipedia talk:Welcoming committee#Let's get rid of Wikipedia:Welcoming committee/Welcome to Wikipedia.
Sdkb (talk) 08:21, 13 March 2020 (UTC)Template:Z48
Starting tomorrow I've decided to launch this long term to try to bring our stub count down. Aiming for 50,000 expanded stubs over the decade, covering every country and topic. We need a mass of editors to make it work. If you support the idea please sign up and if you have any suggestions or want to discuss it please do so here. Cheers.† Encyclopædius 08:42, 31 March 2020 (UTC)
Delete naturally stale Draftspace Redirects
If a Redirect exists on a Draftspace article, then it should be subject to the same rules as G13. As in, if the draft hasn't been edited for 6 months past the approval to Mainspace, then it shouldn't be exempt from G13 Speedy-delete.
I have been tagging pages with G6 instead, though when an admin comes along to delete it it will get deleted under G13. I feel that although this will increase initial workload on admins, the workload going forward will match the amount of articles that successfully make their way to the Mainspace. Thepenguin9 (talk) 13:09, 31 March 2020 (UTC)
- I don't see what this fixes. What problem does a draft space redirect cause? --Izno (talk) 14:55, 31 March 2020 (UTC)
- If the target article is moved again (causing a double redirect) then it means bots waste time fixing a double redirect which has no reason to be there anymore. It also helps clean up the space in general. Thepenguin9 (talk) 15:26, 31 March 2020 (UTC)
- I'm finding it a bit difficult to understand what you are getting at here (some concrete examples might help). Are you saying that humans should do more work to relieve those poor hard-working bots of drudgery? If so this seems to be getting the roles of humans and bots the wrong way round. Phil Bridger (talk) 15:36, 31 March 2020 (UTC)
- Suppose Article X was originally a draft, and it was made back in 2014. It was accepted that same year, and the draft served as a redirect should there be any links to it (talk pages for example). That draft is then sitting unused, unaccessed, except for the times Article X gets renamed to Article Y, then Article Y#Topic, and so on and so forth.
- By allowing Draftspace redirects to be eligible for deletion through G13, it would also allow said bots to compare the last edit (or creation date) against the current date, and if it is a redirect to automatically delete (or tag if not privileged) Thepenguin9 (talk) 16:03, 31 March 2020 (UTC)
- But we still need to consider links from outside Wikipedia to draft space. This is just one more piece of evidence as to why the experiment with draft space has failed. If we just kept doing things the wiki way, in which articles are created in main space and speedily deleted if hopeless, then this wouldn't be an issue. Phil Bridger (talk) 16:15, 31 March 2020 (UTC)
- @Phil Bridger I can think of a few cases where someone would link to a draft from off-wiki, however wouldn't it be the same as Mainspace articles that were speedily deleted for some reason. Thepenguin9 (talk) 16:29, 31 March 2020 (UTC)
- I don't think it's the same at all. If the article exists, then the redirect will point to the article. BD2412 T 18:37, 31 March 2020 (UTC)
- @Phil Bridger I can think of a few cases where someone would link to a draft from off-wiki, however wouldn't it be the same as Mainspace articles that were speedily deleted for some reason. Thepenguin9 (talk) 16:29, 31 March 2020 (UTC)
- But we still need to consider links from outside Wikipedia to draft space. This is just one more piece of evidence as to why the experiment with draft space has failed. If we just kept doing things the wiki way, in which articles are created in main space and speedily deleted if hopeless, then this wouldn't be an issue. Phil Bridger (talk) 16:15, 31 March 2020 (UTC)
- I'm finding it a bit difficult to understand what you are getting at here (some concrete examples might help). Are you saying that humans should do more work to relieve those poor hard-working bots of drudgery? If so this seems to be getting the roles of humans and bots the wrong way round. Phil Bridger (talk) 15:36, 31 March 2020 (UTC)
- If the target article is moved again (causing a double redirect) then it means bots waste time fixing a double redirect which has no reason to be there anymore. It also helps clean up the space in general. Thepenguin9 (talk) 15:26, 31 March 2020 (UTC)
- Oppose the proposal that I think is being made here. Redirects from Draftspace to the same target in the mainspace have perpetual value, to show someone who comes back to the draftspece in order to work on the draft that it is now located in the mainspace. Within-draftspace redirects are almost always useless (within draftspace pagemoves should be performed by admins/pagemovers, to allow the option of suppression of redirect creation), and in such cases I have no problem with tagging them as G6 and would strongly oppose the adding of (presumably hundreds each day of) them to the G13 process that is already quite strained just from non-redirect draft pages. FWIW, no one, and I mean no one, links to the Draftspace from outside WP. UnitedStatesian (talk) 06:30, 1 April 2020 (UTC)
- Wouldn't the use of the redirect go down over time? So either 6 months or maybe longer after the redirect was made should the article be deleted? Thepenguin9 (talk) 21:03, 1 April 2020 (UTC)
- I have no idea; only way to know would be to look at pageview stats. As an overarching philosophy in this case, remember redirects are cheap: there are only about 70,000 in the entire draftspace. UnitedStatesian (talk) 05:09, 3 April 2020 (UTC)
- Wouldn't the use of the redirect go down over time? So either 6 months or maybe longer after the redirect was made should the article be deleted? Thepenguin9 (talk) 21:03, 1 April 2020 (UTC)
Proposal: Wikipedia's April Fools 2020 cancelled due to coronavirus
Considering April Fools' is almost done in UTC in less than a couple of hours and it's already April 2nd in much of the world, this proposal is now moot. If next year there's going to be a proposal to ban or regulate AFD jokes, make sure to propose it long before the actual day. Narutolovehinata5 tccsdnew 22:51, 1 April 2020 (UTC)
- The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
In conjunction with Google's decision to respect coronavirus victims, do we think we should cancel Wikipedia's April Fools tradition just for this year? SpinnerLaserz (talk) 23:38, 31 March 2020 (UTC)
- I think it might be a bit late for that, given that it's scheduled to start in 15 minutes. I also wouldn't trust that Google isn't just trying to fool us with a fake cancellation. And there's something to be said for allowing some levity in a bleak time. That said, we should be watching 2019–20 coronavirus pandemic and related pages like a hawk, and prepared to raise its protection level if needed (currently semi-protected). I know we don't normally do pre-emptive protections, but I worry that some vandal who changes the page for 30 seconds before being reverted is going to lead to a spate of "you can't trust the internet" articles in the media. Sdkb (talk) 23:47, 31 March 2020 (UTC)
- I agree with Sdkb. It's too late. And that old adage about laughter being the best medicine might just be what we all need. — Javert2113 (Siarad.|¤) 23:56, 31 March 2020 (UTC)
- I assumed this proposal was an April Fool's joke.--Wehwalt (talk) 00:00, 1 April 2020 (UTC)
- Heh, well, you never know. If it is, it's a mighty fine one. — Javert2113 (Siarad.|¤) 00:01, 1 April 2020 (UTC)
- Perhaps we should start a proposal for cancelling "cancel April Fools day jokes" April Fools day jokes. --Yair rand (talk) 00:34, 1 April 2020 (UTC)
- a while later, I'm starting to suspect it should've been canceled. —moonythedwarf (Braden N.) 04:57, 1 April 2020 (UTC)
- Perhaps we should start a proposal for cancelling "cancel April Fools day jokes" April Fools day jokes. --Yair rand (talk) 00:34, 1 April 2020 (UTC)
- Heh, well, you never know. If it is, it's a mighty fine one. — Javert2113 (Siarad.|¤) 00:01, 1 April 2020 (UTC)
- I assumed this proposal was an April Fool's joke.--Wehwalt (talk) 00:00, 1 April 2020 (UTC)
- Support. Despite it being April 1st UTC, the middle of a pandemic is not the time for jokes. Find some serious DYKs, G3 all the joke XFDs, and continue with the jerryfoolery on 4/1/2021. Catgirllover4ever (talk) 00:13, 1 April 2020 (UTC)
- Strong Support. I was considering such a proposal earlier, and given the background and the disaster that struck this year's April Fools, it might be wise to cancel the event and sysop-protect the 2020 Fools page. -- JavaHurricane 04:59, 1 April 2020 (UTC)
- Oppose - It's the one day of the year that the usually-serious Wikipedia gets to have some fun. As long as the jokes don't go beyond limit or be in bad taste (like joking about anything coronavirus-related) having some fun should still be allowed. It's just one day, we will go back to our regular scheduled boring and serious programming soon anyway. Narutolovehinata5 tccsdnew 05:02, 1 April 2020 (UTC)
- Oppose (edit conflict) Hate to say this, but April 1st is going to happen whether or not the community consensus sanctions it. New editors have already caught wind of it. Also, older editors like myself recall conflicts about April 1 in less conscientious times; consensus to cancel April Fools proved impossible then, and it could very well prove impossible now. We need to set boundaries in place, and we need to be willing to delete pages and block people to enforce those boundaries, which people are. Also, everyone can use a good laugh, and stress relief during these difficult times.
- In place of entirely revoking April Fools, I propose that we instead ban jokes about COVID-19 and/or China. I dream of horses (talk) (contribs) Remember to {{ping}} me after replying off my talk page 05:03, 1 April 2020 (UTC)
- In the interest of full disclosure, SpinnerLaserz tried to say that April Fools was cancelled before starting this discussion. I dream of horses (talk) (contribs) Remember to {{ping}} me after replying off my talk page 05:18, 1 April 2020 (UTC)
- Support- The time for making jokes finished four hours ago. What's that? American time is the only one that matters? In a global encyclopaedia? Too many time zones. Too many cultures. They aren't funny anyway. This is one of our more stupid customs. HiLo48 (talk) 05:20, 1 April 2020 (UTC)
- HiLo48, Wikipedia operates on UTC. All jokes started very late in the day for the US. —moonythedwarf (Braden N.) 05:33, 1 April 2020 (UTC)
- Whatever time zone is used, it will still be out of synch with most of the world. This simply isn't a sensible place to play those silly games. HiLo48 (talk) 05:40, 1 April 2020 (UTC)
- HiLo48, why did you assume it was America-centric when Wikipedia always operates on UTC? – Muboshgu (talk) 15:58, 1 April 2020 (UTC)
- Because in one of the several threads about this matter (can't be bothered checking which one), one editor had said that the time for jokes was just about to start. It was 4 pm where I am. That editor had to be speaking from a time zone in the Americas. I know we are supposed to use UTC. My impression is that lots of others don't. And my basic point about time still stands. Whatever time zone is used, it will still be out of synch with most of the world. HiLo48 (talk) 21:36, 1 April 2020 (UTC)
- That is definitely true. I started seeing the April Fools jokes at 5pm on March 31 my time, because I live on the Pacific Coast of the U.S. – Muboshgu (talk) 22:04, 1 April 2020 (UTC)
- Because in one of the several threads about this matter (can't be bothered checking which one), one editor had said that the time for jokes was just about to start. It was 4 pm where I am. That editor had to be speaking from a time zone in the Americas. I know we are supposed to use UTC. My impression is that lots of others don't. And my basic point about time still stands. Whatever time zone is used, it will still be out of synch with most of the world. HiLo48 (talk) 21:36, 1 April 2020 (UTC)
- HiLo48, why did you assume it was America-centric when Wikipedia always operates on UTC? – Muboshgu (talk) 15:58, 1 April 2020 (UTC)
- Whatever time zone is used, it will still be out of synch with most of the world. This simply isn't a sensible place to play those silly games. HiLo48 (talk) 05:40, 1 April 2020 (UTC)
- Please tag your jokes with {{April fools}}, because whatever joke this is supposed to be, it's pretty lame. In case I wasn't clear, this is an oppose. epicgenius (talk) 14:08, 1 April 2020 (UTC)
- Also, I am aware this proposal is serious. I don't think it should be treated that way, since starting a "Cancel April Fool's" proposal 15 minutes before April Fool's is pretty laughable. Should have done that well beforehand. epicgenius (talk) 14:17, 1 April 2020 (UTC)
- I don't think this was supposed to be a joke. In any case, the cat has already escaped the bag and run miles away, so Oppose * Pppery * it has begun... 14:09, 1 April 2020 (UTC)
- Moral support - When the same shit gets nominated and repeated year after year the whole April Fools thing becomes less funny and more disruptive, Also I will say COVID jokes should be banned entirely, "Jokes" such as Wikipedia:Articles for deletion/Severe acute respiratory syndrome coronavirus 2 just aren't funny ..... –Davey2010Talk 14:22, 1 April 2020 (UTC)
- While I find myself in opposition to this proposal, I'll refrain from casting a formal !vote since I don't think we should seriously entertain a proposal that was filed 20 minutes before April Fools Day began according to Wikipedia time. And you can count me among those who don't see the logic in arguing that we can't have fun because of the pandemic. LEPRICAVARK (talk) 14:38, 1 April 2020 (UTC)
- I didn't see any fun. (Sit's back and awaits personal attacks). HiLo48 (talk) 21:39, 1 April 2020 (UTC)
- Neutral. I don't have a strong opinion on this proposal; I neither support nor oppose it. What I am concerned about is, well, plankton. That's right: plankton. A lot of people don't realize this, but if all the world's plankton (about 500 billion tonnes of biomass) were to be suddenly transported to North America -- AND WHO'S TO SAY IT WON'T BE? -- it would cover the entire continental United States to a depth of 20 metres, killing millions of people, destroying hundreds of dollars of property, and snuffing out most plant and animal life. Yet nobody talks about this. This is what we should be worrying about instead of some boo-foo twerps having or not having a joke day at some encyclopedia website. Yet the last time I tried to bring this up, all I got was the same old brushoff: "Oh Jesus this guy again" and "Excuse me, but why aren't you wearing pants" and "Sir, this is a Wendy's, you'll have to leave" and so forth. Nobody's willing to engage on the issue. So go have your joke day or not, I don't care. Herostratus (talk) 22:47, 1 April 2020 (UTC)
- The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Improve the Wikicode Tutorial.
I started my wikipedia account on around 2013 and it is now 2020 and I still face a lot of difficulty handling Wikicodes. I routinely visit many help articles, often copy-paste codes, often get anxious or frustrated to format. I have systemised the difficulties I faced.
- I tend to forget the commands and syntax.
- There are too many detailed help pages but there isnt a brief list of necessary commands and examples.
- The WP, help-pages, etc are too difficult to quickly scan and find the necessary codes.
- I cannot yet handle big codes such as table, gallery, references (especially when same paper to link with multiple source such as DOI, PubMed, Wayback machine, etc), templates, etc.
- Forgetting the source codes cause distraction and frustration.
- Still, I am dependent on source code formatting. visual editors are fast but it does not give me the comfort to rectify existing minor errors. The source code editing is more dependable, customisable and explanatory.
In this circumstances; my solutions are:
1. Create a such a page where a single page will contain a list of Wikipedia features and the source code to do them. Curently I am doing a sample in my sandbox . Please feel free to improve this article.
2. Wikipedia has a certain "do not scream" policy that makes many articles very unreadable. But It is necessary for me to use very large texts, highlights, very big headings, bold texts, combination of large and normal fonts within single sentence; to make necessary informations more accessible. So the "Do not scream" policy should be partly retracted from that help page.
3. To develop some excercise or sample lessons.
Assumingly it would be of great usage to many people worldwide, and will increase activity and will make wikipedia editing a less-distracting task.
Regards.
RIT RAJARSHI (talk) 09:22, 1 April 2020 (UTC)
- I agree with your desire for a quick and simple guide to markup – there's the markup cheatsheet, which seems to accomplish the purpose of your draft page. I am firmly opposed to retracting the policies against excessive text modifications such as bolding, size changes and highlighting, as these ensure Wikipedia retains its clean look, avoids tackiness, and reduces the possibility of NPOV violations caused by editors' personal decisions to highlight a particular point. – Teratix ₵ 10:47, 1 April 2020 (UTC)
Deleting TimedText Files
Three TimedText files have been nominated for deletion at MFD. However, two of the regular editors there, User:SmokeyJoe and I, think that TimedText pages are a special type of files, and that the expertise to discuss them is more likely to be at Files for Deletion than at Miscellany for Deletion. User:Snaevar, who is the nominator, may also want to comment. SmokeyJoe and I think that the procedure for considering deletion should be revised to send the deletion discussions to FFD. Robert McClenon (talk) 01:37, 3 April 2020 (UTC)
- That seems obvious. --Izno (talk) 02:07, 3 April 2020 (UTC)
- Based upon just the name it would seem obvious, but it shouldn’t matter where the discussion takes place as long as there’s sufficient participation of knowledgeable editors. So, moving such discussions to FFD does not necessarily mean there will be better discussions. FFD discussions tend to involve copyright related matters for the most part; so, if that’s why those particular files ended up at MFD, then moving them to FFD might work out fine. If there are other concerns (as seems to be the case with those files), then moving the discussion to FFD might not lead to any better discussion, and the file’s may simply end up deleted by default after the FFD has run its course if nobody challenges the deletion. Unchallenged FFD nominations for deletion typically end up deleted by default. — Marchjuly (talk) 15:19, 4 April 2020 (UTC)
- I think this type of nomination should remain at MfD. They are nominated so infrequently that we should be able to bring the relevant editors into the discussion every time. It is alos possible that MfD participants will become more knowledegable as a result. UnitedStatesian (talk) 17:32, 4 April 2020 (UTC)
- There are two - one was transcluded twice. Both are pure vandalism and should be G3d. Cabayi (talk) 17:53, 4 April 2020 (UTC)
- Could someone please tell me what the hell "TimedText files" are? A link or a diff maybe? I'm sure I'm not the only one who would have to go searching to find this out. Phil Bridger (talk) 18:00, 4 April 2020 (UTC)
- They're subtitles. They've got their own namespace. This is one of the files under discussion - TimedText:Gradual Liquidation.ogg.en.srt Hope that helps, Cabayi (talk) 18:04, 4 April 2020 (UTC)
- You learn something new every day. Thank you. Phil Bridger (talk) 18:17, 4 April 2020 (UTC)
- They're subtitles. They've got their own namespace. This is one of the files under discussion - TimedText:Gradual Liquidation.ogg.en.srt Hope that helps, Cabayi (talk) 18:04, 4 April 2020 (UTC)
- "Daddy, what did you do during the Coronavirus lockdown?"
- "Well son, I spent the time debating the proper forum to debate the proper process to get rid of low grade innuendo about mutual oral sex."
Really? Is this where we're at? Cabayi (talk) 18:22, 4 April 2020 (UTC)
- Well, if the files were vandalism, then what matters is that someone recognizes that they were vandalism rather than requiring a real discussion. Robert McClenon (talk) 02:35, 5 April 2020 (UTC)
RfC for new user warning
You're invited to comment at an RfC proposing a new user warning for violations of MOS:FLAG (improper usage of flags in articles). It may be found at Wikipedia talk:Manual of Style/Icons. The last one did not garner enough participation to reach a consensus, and was closed prematurely by a bot. –LaundryPizza03 (dc̄) 16:46, 5 April 2020 (UTC)
Itemising the history of discussion on Wikipedia
I am about to go through the history of discussions on philosophy so that I can note the more significant discussions. In most cases I can point to particular sections with a link, such as Wikipedia:Village pump (proposals)#Itemising the history of discussion on Wikipedia pointing directly to this section. But in older discussions, sections were created by simply adding a line ----. The contents do not pick these lines up. To make it possible to point to these discussions individually, I can go through an archive page and replace each line with a section header. I could number them, 1, 2, 3, etc, rather than attempt to name them. I am proposing to make this a standard and acceptable thing to do. I am proposing to request a bot to do this for all archives. ~ R.T.G 18:59, 5 April 2020 (UTC)
- Why not just add anchors? ‑ Iridescent 19:06, 5 April 2020 (UTC)
- Anchors are less recognizable and less semantic, among other things. --Izno (talk) 19:18, 5 April 2020 (UTC)
- When a section is untitled I simply just add a header and something like "Untitled section YYYY"; you can do similar in your case. I see no reason to make this a standard thing, but I don't see a reason why it would be unacceptable. --Izno (talk) 19:18, 5 April 2020 (UTC)
- I went ahead and just did it but AFAIR it is against the letter of the guides to alter an archive. ~ R.T.G 01:53, 6 April 2020 (UTC)
- For a bot proposal, go to WP:BOTREQ. {{u|Sdkb}} talk 00:54, 7 April 2020 (UTC)
Science Photo Competition 2020 Russia targeting CentralNotice banner
Dear colleagues, this is a notification about a request to display the following CentralNotice banner to enWP visitors from Russia (IP targeting) @ 5 impressions per week max. It is made by Wikimedia Russia for the traditional annual contest running April 2-May 31.
Shoot science for Wikipedia!
We are grateful for your support or other appropriate comments in the discussion on Meta. Thank you.--Frhdkazan (talk) 15:43, 6 April 2020 (UTC)
Feature Request: Serif Font style for Wikipedia
Proposal bumped to Technical tab. RIT RAJARSHI (talk) 09:17, 8 April 2020 (UTC)