Wikipedia:Village pump (proposals)

 Policy Technical Proposals Idea lab WMF Miscellaneous 

The proposals section of the village pump is used to offer specific changes for discussion. Before submitting:

Discussions are automatically archived after remaining inactive for nine days.


Defining a process for the discussion of making Vector 2022 the new defaultEdit

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


Hi everyone,

We would love to see the Vector 2022 skin (see what it looks like) become the new default on desktop across all wikis, including English Wikipedia. The skin would be turned on for all anonymous users, and also all logged-in users who now use Vector (the current default). Logged-in users are and will be able to switch to any of our other available skins, including the current Vector. We will be ready to begin making the change at the end of August (and not in July, as previously announced), when the visual refinements and other deployment blockers are ready.

The goal of the project is to make the interface more welcoming and comfortable for readers and useful for advanced users. The project consists of a series of feature improvements which make it easier to read and learn, navigate within the page, search, switch between languages, use page and user tools, and more. The team has been working on this change for the past 3 years, ensuring that every change is thoroughly tested and proven to work.

Making this change is important for both readers and contributors.

We need your help and feedback on how to proceed. We have two requests:

  1. We need to talk in a way that works well for the English Wikipedia community. What would be the best format and timeline to discuss the change? We have included a proposed format below, and are interested in what you think about it. If you agree, we can begin the deployment conversation in one week. Here is our suggestion:
    1. Have the deployment conversation that would take 2 weeks. The goal for that discussion will be to identify breaking issues or opportunities for improvement for the new skin. It will be important for us to reduce the risk of bugs or imperfections that would be particularly troublesome on English Wikipedia
    2. After the deployment conversation, we get back to you with a prioritized list of remaining work/fixes necessary prior to deployment
    3. Before the deployment,
      1. Banners announcing the change will be displayed for logged-out and logged-in users
      2. The announcement will be made both on the Village Pump as well as in the Tech News.
    4. We proceed with deployment once the agreed upon fixes are ready.
  2. We need to understand the perspectives of different parts of the English Wikipedia community. What forms of communication would help to gather feedback and further raise awareness for the English Wikipedia community? We would like to have an open discussion, but are open to other forms such as requests for comments, office hours dedicated specifically for the English Wikipedia community, or guest presentations at community meetings. If necessary, we can also adjust the timeline of conversations based on your needs.

We welcome your replies here, or via email (olga@wikimedia.org, sgrabarczuk@wikimedia.org), as well as during our next office hours (26 July).

Thank you for your time and help. OVasileva (WMF), SGrabarczuk (WMF) (talk) 12:05, 13 July 2022 (UTC)

The comments from jawp above suggest that this change may not be entirely uncontroversial, with some editors feeling that it is not an improvement. Will enwp be allowed any say in whether the change is rolled out at all, or is it being imposed with our only input being into the details? Certes (talk) 12:48, 13 July 2022 (UTC)
No matter what change, there is a guarantee that a certain amount of people will not feel like it is an improvement. That in itself is a very bad metric for decision making. Are the points being made valid, is there an opt out, what other problems are we solving and are the people responding an accurate representation of the larger group of users. Those seem like much more critical questions to me. —TheDJ (talkcontribs) 13:08, 13 July 2022 (UTC)
I didn’t like it at all when I tried it, but I’ve been won over after spending some time with it. Doug Weller talk 13:14, 13 July 2022 (UTC)
Is there a list of blockers that are being accepted as blocking tasks right now?
  • I think the table of contents handling parts are the biggest problem right now. We currently have a lot of control over the TOC placement and display, which seems much harder or impossible with vector-2022.
  • Personally, I think with our "wide vector-2022" gadget option being an option for editors, general editors may be OK -- if we can ever get control over what is going on with the left sidebar - it comes, it goes, it is hard to control.
xaosflux Talk 13:08, 13 July 2022 (UTC)
Here are 2 examples of the sidebar with the wide gadget: an article that doesn't for a TOC, and article that has a displayed TOC. In the later, the entire sidebar will collapse, but only at certain display sizes, there is a task out there about being able to collapse the TOC - but very notably, even when collapsed that sidebar stays open an empty. Is the "grid" work going to address that at all? The sidebar element seems to be part of the content container. — xaosflux Talk 13:11, 13 July 2022 (UTC)
I quite like the wide-vector-2022 layout and I'm sure I could be won over after a few weeks of it being the default. I think I'm in the minority when I say I like the ToC positioning on the left (but only on wide-vector). I strongly dislike the normal (non wide) version of Vector 2022, and I've left comments here on why this is. As for the OP's question: I don't think enwp will take kindly to a discussion about setting Vector as the default while these issues of narrowness, ToC placement, and unnecessary top banner whitespace exist. Anarchyte (talk) 13:31, 13 July 2022 (UTC)
I don't hate the side-bar based TOC in vector-2022 (even with wide mode) - I mostly hate that when all the sidebar elements (toolbar, and hopefully soon to be TOC) are collapsed or docked, that the sidebar can't be collapsed without also adding in javascript hacks - I'd think this should be possible with css and a layout that allows it to widen if there are contained elements pushing the margin. — xaosflux Talk 13:38, 13 July 2022 (UTC)
Hiding the TOC and then regenerating a custom TOC (as in this article does achieve what I'm looking for I suppose - not sure why that is so hard? — xaosflux Talk 13:42, 13 July 2022 (UTC)
Perhaps something the team could look into could be having the __TOC__ magic word forcing the TOC to exist within the page instead of in the sidebar. Anarchyte (talk) 14:38, 13 July 2022 (UTC)
Hey @Xaosflux - thanks for the feedback, and quick answer to the sidebar question (I'll follow up on your other points around magic words a bit later). Once the new ToC collapsing behavior is ready (phab:T306660), the gadget should work again to stretch the full width if both the sidebar and the ToC are collapsed OVasileva (WMF) (talk) 13:37, 15 July 2022 (UTC)
@OVasileva (WMF) thanks, looking forward to trying that out - I think it will at least alleviate some worry for logged-in-editors that have concerns about "too narrow" - likely some of the more heavy power editors that are using wide desktop monitors, I don't think it is a big deal for casual readers. From initial notes below, seems like the loosing control of Table of Contents styling in general is at least an emerging concern among editors - I'd hate to see ugly hacks get pushed by the community if there is an impasse (like the continuing problems going on in Wikipedia:Village pump (proposals)#RfC: Showing Editnotices to mobile editors below with Mobile Front End and developers preventing certain elements from being controllable). — xaosflux Talk 13:52, 15 July 2022 (UTC)
  • Regarding TOC handling in general, for example in these articles editors have specified a custom right-sided TOC, which vector-2022 overrides. — xaosflux Talk 13:34, 13 July 2022 (UTC)
    It seems quite inconsistent though, see this article in vector where editors have determined the best TOC layout type, compared to it vector-2022. — xaosflux Talk 13:46, 13 July 2022 (UTC)
    I think the primary reason we have customized TOCs is when they are very long. Of the most common variants, the floating variants ({{toc left}}, {{toc right}}), {{toc limit}}, and {{horizontal toc}} all exist to deal with a long table of contents. General point: except for people who customize their skin selection away from Vector22, I don't think we need to support these at all in the new skin. We can leave the templates alone right now for those people who do use the other skins, if we want. Specific points:
    1. Floating variants: simply don't care
    2. Toc limit: With a per-level collapsible table, totally obsolete.
    3. Horizontal toc: Maybe the only interesting one, since its major use cases are 'letter/number-driven' lists and large categories, and I expect that a TOC that long will be rough on the sidebar version (I haven't checked yet). I think there's probably a feasible feature request somewhere regarding category tables of contents.
    I think forcing the TOC to appear in page besides maybe that last one isn't needed at all (and I don't think that needs anything more than the customization we can already build with a template). Izno (talk) 19:59, 13 July 2022 (UTC)
phab:T306246 was mentioned above in #Consultation on Search improvements by CX Zoom and Ahecht and myself. That must be solved, and not by updating documentation, declaring it not a bug or closing it as a duplicate of $random other task. (I occasionally see tasks getting closed without a real solution so I'm just saying) I see plenty of open tasks on phab:T309972 so there's plenty to do. From a UI perspective, I suggested some improvements on phab:T302641, that alone is a hard deal breaker to switch for me personally. Alexis Jazz (talk or ping me) 20:31, 15 July 2022 (UTC)
@OVasileva (WMF) / @SGrabarczuk (WMF) - I think the entire design/implementation/documentation/testing about page meta-content and collisions with content things like our "coordinates" templates (see also -Wikipedia:Village_pump_(technical)#Coordinates_in_Vector_2022, phab:T292617, and phab:T281974) may be a bit of a blocking issue here - seeing as we make use of these features on literally millions of pages. I fear there seems to be a bit of tension in layout/design goals between skin developers and community use. What are your thoughts on the best way to reconcile these sort of things? — xaosflux Talk 12:41, 22 July 2022 (UTC)
 
Visual Editor is still in beta as of July 2022

SGrabarczuk (WMF), if you choose to make this change, it will be important to the success of the change to have a team of developers available to monitor forums where bugs and feature requests are reported, create phab tickets actively, and resolve those tickets quickly. Too often, new features are rolled out in beta form (I'm thinking especially of the Visual Editor) and then the development team appears to move on to new projects, leading to bug reports that linger for years (I'm thinking especially of the Visual Editor). I encourage you to designate a place local to en.WP, de.WP, Commons, and other large MediaWiki installations, where editors can report problems without having to travel to unfamiliar sites with different interfaces and watchlists, like mediawiki.org. – Jonesey95 (talk) 14:38, 13 July 2022 (UTC)

Hi @Jonesey95. Oh, that's a very fair comment. I'm giving a bunch of quick replies to different parts of your comment. I hope these bits make sense together:
  1. VE was launched, correct me if I'm wrong, like... 9 years ago? we've learned a lot since that. For example, earlier this year, when planning the current Californian fiscal year, we decided that we would dedicate some time this summer and fall (the first months of the fiscal year) just to further improve Desktop Improvements if needed. So that part's safe, not only in our hearts, but on the governance level, too.
  2. As a result, some bugs and feature requests will definitely be handled. Depending on how much related to Desktop Improvements, these will either be just done or considered as part of future projects.
  3. Vector 2022 is the default on ~30 wikis. On a few of these, incl. French Wikipedia, it has been the default for almost two years! So they've done a great deal of bug-reporting/feature-requesting already. I think both our team and other communities may be truly grateful for that.
SGrabarczuk (WMF) (talk) 15:04, 13 July 2022 (UTC)
Thanks. I wish you luck. If all goes well with desktop improvements and the developers find that the set-aside time is available for other work, maybe some of the team can work on the VE backlog and officially get it out of beta status. A bunch of us gnomes who clean up errors that it generates would be very grateful. – Jonesey95 (talk) 15:52, 13 July 2022 (UTC)
?? "Vector 2022" has been the default on frwiki since 2020? Does it have time traveling properties? — xaosflux Talk 18:22, 13 July 2022 (UTC)
@Xaosflux, you are kidding, right? Let's make it clear for everyone around: back then, it wasn't labelled as "Vector 2022", but it was there. We've been adding more and more features and changes, but the first ones (different logo, collapsible sidebar, limited width) have been the default on some wikis since July 2020. SGrabarczuk (WMF) (talk) 19:11, 13 July 2022 (UTC)
@SGrabarczuk (WMF) Yes, that was mostly humorous, just contrasting that the entire current incarnation it hasn't had 2 years of bake-in. — xaosflux Talk 19:17, 13 July 2022 (UTC)
Yeah, right. It's a good opportunity to make it clear that this interface isn't static, really. These incarnations are like ogres - both have layers. Some are two years old, and some (like the sticky ToC) are two months old. The older a layer is, the more people have actually used it, noticed bugs, advocated for improvements, everything. It's not like we're pulling Vector 2022 with everything about it out of a hat. I hope it's reassuring. SGrabarczuk (WMF) (talk) 19:29, 13 July 2022 (UTC)
Jonesey95, to sober up here's Growth-Team's profile on Phabricator. Two projects in active development, one project with a new owner and 11 projects with "passive maintenance" (read: unless the building is on fire expect nothing) with the note "New owner needed". Probably just some obscure projects, right? Yeah, it's just WP:WikiLove, WP:Echo, WP:Thanks, WP:Nuke, WP:Page Curation, Special:RecentChanges. Not anything people really use, you know. Alexis Jazz (talk or ping me) 21:03, 15 July 2022 (UTC)

I suggest having a page somewhere that essentially functions as a press release and/or a list of FAQs. At the miminum, link this page in the banners (i.e. with a CTA: 'Read more about the upcoming change!') so that 1. non-registered visitors can read more about the impending changes (and possibly encourage them to register as editor even if it is just to revert back to the previous skin); 2. interested publications may organically pick it up as a story for their audience. – robertsky (talk) 18:08, 13 July 2022 (UTC)

Great idea, @Robertsky! We're working on a page on wikimediafoundation.org (for readers, media, the "general public"), and we'll definitely have a more detailed FAQ for editors. SGrabarczuk (WMF) (talk) 18:18, 13 July 2022 (UTC)
I'd recommend that said press release/FAQ page should also include instructions on how to revert back to the older vector skin. I imagine that there will be a fair few (including myself) using the current vector who would like revert back to the older form, and while I know how to switch skins, there are some who may not be familiar. Hog Farm Talk 19:58, 13 July 2022 (UTC)

For this change to be a success you can't just impose this on enwiki; you need consensus from the community. Are you willing to open an RfC that seeks to obtain consensus to implement this change? BilledMammal (talk) 21:25, 13 July 2022 (UTC)

@BilledMammal, I think the proposal pretty much answers your question. Let me rephrase a part of the first message: in the next conversation, we'd like to talk what remains to be done instead of having a yes/no situation. And we do mention RfC there, too. SGrabarczuk (WMF) (talk) 22:36, 13 July 2022 (UTC)
Your comment comes across as if this is a done deal, with only small details (what remains to be done) to be worked out, but the community needs to be able to reject this. It needs to be able to say that it is not satisfied with the current version of Vector 2022, and instead ask you to come back and see if consensus has changed when you believe you have addressed the objections raised in the discussion.
To rephrase my question; are you willing to open an RfC that seeks to obtain consensus to implement this change, with an option that will permit the community to reject the change? BilledMammal (talk) 22:53, 13 July 2022 (UTC)
+1 to User:BilledMammal's comment. In that vein: Consider me an Oppose to switching the default. On my screen at least, V2022 has a very poor layout that looks unclean and would create a poor impression of Wikipedia, forced upon us by the WMF. I want to see a finished product before everyone without an account (that is the majority of users) are suddenly switched to a new (worse) look. Happy Editing--IAmChaos 21:44, 13 July 2022 (UTC) edited 01:50, 14 July 2022 (UTC)
We believe this change is extremely important for readers, and have a lot of data and research that can help us prove this.  That said, we understand that that community might need more from the skin than what is currently developed. That’s why we hope to get into the details so we can identify what needs to be changed before the conversation on whether and when that change will happen begins. That said, to be clear, we will not be rolling out the new skin prior to coming to such an agreement with the community. SGrabarczuk (WMF) (talk) 16:46, 15 July 2022 (UTC)
@SGrabarczuk (WMF): Thank you, I am glad to hear that. Are you able to provide us with the data and research reports so that we can consider this change in that context? BilledMammal (talk) 22:35, 16 July 2022 (UTC)
@BilledMammal see § UX research and usability testing below. There's a great deal available there and at other pages, so please specify what else you're seeking if you'd like additional research. {{u|Sdkb}}talk 22:40, 16 July 2022 (UTC)
Thank you, I missed that. BilledMammal (talk) 02:13, 17 July 2022 (UTC)
@IAmChaos Olga and Szymon explicitly structured this conversation as a meta-conversation about process, not a !vote on implementation. Let's respect that by avoiding bolded !votes, just as we do at VPI. {{u|Sdkb}}talk 23:02, 13 July 2022 (UTC)
I appreciate that. I will unbold. Happy Editing--IAmChaos 01:50, 14 July 2022 (UTC)

I think just waiting until the "final" release version is ready and usable before starting any discussions on adding it is best. While prototypes are still ongoing it isn't great to start any discussion on a non "final" version when signficant changes can still occur and the outcomes on changes are not released. Using the latest prototypes: Color schemes, borders, toc highlighting & logo choices should be able to be viewed at the point the discussion starts rather than lumped in at the end and not allowing anyone to voice their opinions on these choices specifically isn't a good idea. Terasail[✉️] 22:02, 13 July 2022 (UTC)

@IAmChaos, @Terasail, we're not there yet. Please take a look at the proposal. You'll find the replies there. We don't have a definition of a "good enough" product. (In a way, it will never be quite "finished", just as most Wikipedia articles never are.) We'd like to make it together with the community, and now, we're asking how do you think we should do that. SGrabarczuk (WMF) (talk) 22:34, 13 July 2022 (UTC)
It sounds like this product, if approved, will see regular releases. Will these releases also be discussed with the community or will they be boldly implemented? BilledMammal (talk) 22:58, 13 July 2022 (UTC)
@BilledMammal, I'm not sure I understand your question. What do you mean? Could you elaborate on that? SGrabarczuk (WMF) (talk) 23:26, 13 July 2022 (UTC)
@SGrabarczuk (WMF): If I have understood you correctly this version of Vector 2022 is not the final version; instead, it will see regular significant updates. My question is what your process for implementing these updates will be; will you do them boldly or will you discuss them with the community first?
In some ways, this question is related to my question above from 22:53, 13 July 2022, which I believe you may have missed. BilledMammal (talk) 00:58, 14 July 2022 (UTC)
Thanks for clarifying your question! What we mean when we say that this is not the final version is:
  • We still have some identified issues (documented as tasks) that are not resolved. This is the list that is under this task.
  • The two-week conversation we're proposing would be meant to help us define the version upon deployment. We need agreement between our team, the needs of readers, and the community in the identification of what their needs from the skin are. What are the blockers to changing the default? That is the conversation we are currently trying to set up.
  • Once deployed, we plan on continuing to work on the desktop experience. Our next focus will be on improving some of the features we’ve built here, but also using some of the things within the new interface to begin exploring goals that are even further-reaching, such as encouraging more interested readers to begin editing.  With Vector on most Wikipedias, we didn’t change the skin for 12 years. This project, while improving usability for existing tools, did not add or remove any current tools from the interface. Once it’s done, it gives us the opportunity to work with communities to provide new and necessary tools both for readers and editors. This is a process that is ongoing and will be done with the feedback and collaboration of the community here and across other projects.
SGrabarczuk (WMF) (talk) 17:18, 15 July 2022 (UTC)
Thank you for clarifying this as well. I am glad to hear that you will seek input and hopefully consensus from the community before implementing any significant updates. BilledMammal (talk) 22:35, 16 July 2022 (UTC)
@SGrabarczuk (WMF) Firstly, thanks for your reply, I appreciate you being willing to answer so please don't feel like I'm jumping on you specifically, its just that you brought this here and I figured I should voice my concerns with a switch to V22. @Sdkb replied to my earlier comment, and I agreed so I modified it with their suggestion. I strongly believe though, even in this so called "meta" conversation about process, we shouldn't be ignoring the issues. Logged out editors are the most populous user, even though they have practically no voice in ProjectSpace discussions. If we are to implement a change to what they see (ie default settings), we need to address this more than other things, because those affected won't discuss it. Here's a quick list of what I've found.
  1. The TOC issues. They are being overriden against specific decisions by editors who chose to design a page a certain way. for example, see Alien, which is the first page alphabetically that uses {{TOC right}}, why should V22 override, there is no precedence in monobook, timeless, minerva which are the other skins installed on enwiki. I think overrides like that (and there may be others, this is just what I have seen conversation about above) should fall to editors, not to software.
  2. The look of it. Not to be mean to the team who worked very hard on it, and I appreciate what you've done for the MediaWiki community, but I feel that there are (in the current state) some things objectively worse. Why is there just blank space to the right of articles when V(legacy) reaches the edge of my screen? Why is there space blank to the left of the sidebar that is just white? The sidebar is highlighted in gray which only makes the large blank more obvious.
  3. In a similar vein to the blank space - the bar across the top is unbalanced - The user icon is all the way to the right over the blank space, but the arrow on the left is indented like the sidebar, it looks unbalanced.
  4. This one is a much more niche issue - and probably one that you will never work on (and don't need to at least for enwiki), but for a user such as myself who has a long sidebar - multiple scripts add links to mine, the TOC is impossible to find for multiple sections - for example on Butetown - I have scrolled down to section 4 (#Welsh language) before the TOC is caught up with me. This may be a concern though for other projects that have added links to their sidebar, such as my private mediawiki site, which has many sidebar links for my convenience.
On the note that I have now spoken about your hard work in a less than stellar light, I again apologize if I came across as harsh, but these are things that I feel need to be addressed before such a big switch for such a prominent website in today's world. Again, I don't want to come across as rude, but I feel we shouldn't rush into this, and that as sdkb called it, the 'meta-process' should include the community's voice on the actual skin itself, and how it could work for enwiki, instead of just how it will be rolled out. (full disclosure: I havent looked at the deployment blockers you linked, because that's a long phab list, and I still don't quite understand all the lines on it, but I will and am open to the possibility that there are other concerns that are more pressing or maybe I'm a complete minority opinion.) Happy Editing--IAmChaos 02:20, 14 July 2022 (UTC)
I find myself agreeing with you here, particularly on aesthetic grounds, where it looks almost amateurish to me. I have not yet had the time to introspect on why I’m receiving that impression (perhaps I’ll update this later though), so take my take with a grain of salt. I definitely think it’s important not to rush this, considering the extreme outsized effect UX design seems to have on people. Yitz (talk) 03:29, 17 July 2022 (UTC)
@Yitzilitt, thanks for mentioning the aesthetic aspect. Look at this page. We simply haven't built that part yet, because we've been focused on changing the features. We'll implement the visual changes in the next couple of weeks. SGrabarczuk (WMF) (talk) 15:48, 18 July 2022 (UTC)
Hey @IAmChaos — thank you for your feedback, and apologies for my delayed response. We appreciate your honesty here.
Regarding your comments about whitespace and the look of Vector 2022: I’m curious if you have been able to take a bit of time to sit with the new skin, and if so, if that has changed any of your opinions so far? The reason why I ask is: several editors who have given feedback and collaborated with us over the past two years have initially disliked Vector 2022 (often for similar reasons), and then after a few weeks of using it they have come to appreciate the changes that have been made, and even ended up liking it more than legacy Vector.
Some design-specific notes regarding the whitespace: the majority of research on readability and reading comfort over the past ten years have concluded that limited line-length, and whitespace surrounding the text, are critical to a good reading experience (more info here). So we started by limiting the line-length, which ultimately leads to limiting the width of the entire interface (otherwise we would end up with even more whitespace). I know it’s a big adjustment, and it feels like there is a lot of “wasted” space. Fortunately there are several community members who have already begun to develop scripts and gadgets to address this, resulting in a more dense version of Vector 2022 (we were joking that it’s kind of like Monobook version of Vector 2022). You can find those gadgets and scripts here. From a process standpoint: the layout has been worked on and reviewed extensively by the entire WMF design team, supported by the majority of community members who have given feedback over the two year development process, and proven via testing to work better for both logged-in and logged-out people in various ways. So while it may not look aesthetically pleasing to you at this time, we wonder if you can go more in depth in terms of what makes it objectively worse. I am of course happy to discuss these topics further with you.
Regarding your comment about the long sidebar pushing the table of contents down the page: fortunately this is a functional issue so it is easier for us to discuss and agree on. In case you have not yet seen it I invite you to first look at our latest prototype here: https://vector-2022.web.app/Flamingo. You will find that with the tools menu moved to the article toolbar the sidebar becomes much shorter (and please note that the tools menu is able to be pinned to the right side of the article for immediate access upon page load). Secondly, due to the infrequent use of the remaining items in the main menu, we expect that over time most logged-in people will discover their experience is improved by collapsing the main menu (allowing for immediate access to the table of contents upon page load), and then opening the main menu when needed.
Thanks, AHollender (WMF) (talk) 23:27, 28 July 2022 (UTC)
Thanks for the reply @AHollender (WMF). I have looked a bit more, and noticed that I hadn't collapsed teh sidebar which addressed part of my issues mentioned above - particularly the long sidebar hiding the TOC. I will definitely look into the research on readability, I personally find it disconcerting as the software used at my day job is chock full of information too all four corners of my work desktop, all of which I need access to, so maybe it's a bit of Status quo bias in my comfortability with a crowded workspace, but I feel like after looking around there are a few places I don't quite feel fit together right. As for an example where it doesnt match up well: Clicking on Special:Random today brings me to an article in V22. The Categories box is the width of the article, followed immediately by a horizontal line the width of the screen and the footer info is full width across the bottom. I will definitely be looking into the community scripts with density, thanks for the link. Happy Editing--IAmChaos 03:46, 29 July 2022 (UTC)
Hey @IAmChaos — ok right, so this is related to your earlier comment about the width of the header. So how we've currently setup the page layout is:
- there's a max-width for the entire interface, which is currently 1514px. This is the max-width that the site-header, sticky header, and footer all have
- there is a max-width for the content, which is currently 1244px for pages that have a table of contents, or 960px for pages that do not. Again, this max-width is the result of first establishing a comfortable line-length for the article text, then finding a reasonable width for the table of contents. Once we move the tools menu to the other side of the page, if you decide to pin the tools menu this max-width will then be 1514px and everything will be balanced. To explain visually:
Currently this is the situation, with the blank space you're noticing called out in red:
 
Vector 2022 page layout schematic
However if your screen is less than 1325px wide (which most laptops are), there is no longer a blank space:
 
Vector 2022 page layout schematic (laptop screen)
Once we move the tools menu to the other side of the page, if you decide to pin the tools menu this max-width will then be 1514px and everything will be balanced:
 
Vector 2022 page layout schematic (with page tools)
Unfortunately, aside from having the tools menu pinned, there's not really an easy way to make these max-widths match. The easiest thing to explore would be limiting the max-width of the site header to 1244px. However if we did this, and then you decided to pin the page tools, the max-width of the site header would have to change in order to stay aligned.
I hope this is helpful. I can promise you that we are also concerned about possible imbalances in the page layout, are keeping a close eye on this, and are on the lookout for opportunities to achieve better harmony. Your comments are super helpful to us as we continue to explore our options here. AHollender (WMF) (talk) 16:39, 29 July 2022 (UTC)
A request for comment is an open discussion. It's just an open discussion that is geared towards assessing consensus rather than discussing something in the abstract, or as in this topic, having a discussion where you create a plan. So a request for comment, which often runs for 30 days but can go shorter if consensus is clear or longer if discussion remains active, advertised on WP:CENT feels like the right way of having this open discussion with the enwiki community. Best, Barkeep49 (talk) 01:34, 14 July 2022 (UTC)
One extra thought. If there's a sense that consensus might be initially hard but there's a courage of conviction that the skin will genuinely help, some sort of testing, whether through a trial period (owing to enwiki's massive reach lots of data can be collected in shorts period of time), or through A/B testing, with clearly defined metrics could lead to a consensus that wouldn't be there without that data. This is something the Growth Team has done to large success. Best, Barkeep49 (talk) 01:39, 14 July 2022 (UTC)
I like a lot of what Skdb has said below, particularily that it will be an uphill battle for it to gain acceptance. Another factor is that the enwiki users being asked what they think about the change would generally be the heaviest users; casual readers won't see any future RfC's. These users are probably most accustomed to Wikipedia's current look and would most likely be relatively quick to oppose in my opinion. I also think that starting an RfC about 'Should Vector 2022 become the default after it is modified' (so that the RfCs aren't forcing the community to do things and don't have that appearance, also forestalling complete skin opposition in other RfCs) and then following up with one about 'what should those modifications be' could be a good idea. That assumes the community would reject the skin in its current form. —Danre98(talk^contribs) 00:05, 15 July 2022 (UTC)
I would second both thoughts by Barkeep. Specifically, (1) a full 30-day policy RfC, listed on CENT and following the requirements of WP:PROPOSAL, is the gold standard and the only realistic path to legitimacy for such a large change. (2) The change is much more likely to gain consensus with solid supporting data from A/B testing. Best, KevinL (aka L235 · t · c) 00:39, 15 July 2022 (UTC)

FWIW, I am a moderate user (just under 10 edits per day average over the past year, but with over 5,000 pages on my watchlist). After using Monobook for many years, I switched to Vector 2022 a few months ago. It felt a bit wierd at first, but I am now quite comfortable with it. Of course, you are much more likely to hear from users that don't like it than from the rest of the spectrum of user reactions. - Donald Albury 15:56, 15 July 2022 (UTC)

Agreed. Doug Weller talk 17:24, 15 July 2022 (UTC)

Re BilledMammal, Barkeep49, IAmChaos, Sdkb comments on this page about consensus...YES. Changing the editing experience by default for Vector 2010 users without an Opt in....not my favorite and would probably guarantee a strong blowback. Changing the editing experience around here is always fraught with challenges and difficulties (Yeah, VisualEditor...), the chief among them, for me at least, is that I am an editor. I am not someone who approached Wikipedia editing from a developer/programmer/coding/data point of view, I'm just an editing/researching/writing fool and I think there are many of my kind amongst named Wikipedia accounts. I just stumbled upon this discussion by accident and probably wouldn't have known that a change was coming/had been instituted until it happened...
And a plea for the future... If the Vector 2022 skin comes online can we please have clear/easy-to-understand Opt-Out instructions? Maybe have them come up for six months afterwards for Vector 2010? Maybe have an Easy-to-find/Clearly-labeled FAQ for the changes and for Opting-Out? When the "Section edit/Reply to individual posts" change came online recently (I'm sorry but I can't quite remember what the name actually is/was) it was Not Easy to find how to disable/Opt-out from the change. Heh, at least it was not easy for me and I have over 35K posts... That's about all, I'll try to keep up and follow this discussion so it won't be another Big Surprise to me. Shearonink (talk) 17:01, 15 July 2022 (UTC)

Hey @Shearonink, first of all, I understand you. I became a Wikipedian years before I was hired by the Foundation. I personally, as well as other staffers at the Foundation, know that there are thousands of people not editing every day, not engaging in the Village Pump discussions, and finding it difficult to adjust to technical changes impacting the editing experience. So the link to opt-out is and will be available in the Vector 2022 version of the sidebar (left menu). As we wrote, we are also thinking about putting up banners before the launch. SGrabarczuk (WMF) (talk) 17:46, 15 July 2022 (UTC)
It is unfortunate that the en.wiki editor community has been determined through all obstacle to keep this embarrassment of a UI stuck in the year 2001. Despite many excellent proposals for reform of the Main Page, it remains a dull and outmoded layout; the left sidebar is cluttered and unusable by all who have not become accustomed through years of use to its contradictions. Here we have a vector that is far more modern, far more intuitive and far more pleasant for readers—the only problem is that editors who have been here for many years can't possibly approve of it because they've optimised their workflow within the current janky hackjob we have, and the slightest change threatens that.
There are suggestions for changes to the skin that would be useful, but the website's design should not be motivated by the navel-gazing within the editor community. It is apparent in many editor discussions on design that articles are overly focused on how it looks on the editor's desktop view, when most readers will be on mobile. There are discussions for us to have on what the new layout will mean for ToC placement, but we cannot hash out every small detail before first agreeing the adoption of the new layout. There are complaints here about interaction with gadgets and Javascript: this means that those bits of code need to be changed, not the website layout. Many of these gadgets are operating under UI assumptions that are not some functional specification guarantee.
We should not hold back on improvements due to complaints of a vocal minority, but go forwards with the quantitative testing-approved solutions to the problems identified by readers and editors (see below for the WMF's explanation of each stage of this project). — Bilorv (talk) 20:46, 16 July 2022 (UTC)
discussions on design that articles are overly focused on how it looks on the editor's desktop view, when most readers will be on mobile - It's possible to give different views for mobile and desktop readers; I don't think we should be catering for mobile to the exception of desktop. I also note that even the current mobile view is less than ideal; I switch to desktop view when reading from mobile because even there it is easier to read the article in that format. BilledMammal (talk) 22:40, 16 July 2022 (UTC)
I think you've missed my point, BilledMammal, perhaps because I didn't make it clear enough. The issue is not that desktop layout doesn't matter, or that making a good desktop layout contradicts making a good mobile layout. It's that editors generally consider their own layout only (often a desktop layout and specific browser and specific skin) and give no thought to other layouts. As editors, we should be thinking as much about mobile (or more!) as about desktop. But we don't, and that is one example of how editors are not the best people to consult about UI changes. — Bilorv (talk) 08:03, 17 July 2022 (UTC)
Ah, I see what you are saying now - I fully agree, we do need to consider this on a variety of platforms, and even if it isn't currently suitable for all platforms it may be suitable for some. Below, I have actually asked for some data to be presented separately for desktop and mobile users. BilledMammal (talk) 02:53, 18 July 2022 (UTC) Struck following clarification that this is only proposed for desktop. BilledMammal (talk) 04:43, 23 July 2022 (UTC)
Agree with this. I find Vector 2022 much more modern and have been using it for a couple of months now. The only hitch was getting used to all the links being under a dropdown menu instead of listed at the top. Sungodtemple (talk) 03:18, 4 September 2022 (UTC)

Sdkb commentsEdit

I've been following/commenting on New Vector throughout the development process and have a lot to say here, so with apologies in advance for the length, I'm creating a subsection.

@SGrabarczuk (WMF) and @OVasileva (WMF): In some other circumstances, I've encouraged the WMF to plunge forward with seeking consensus for deployment, even though development isn't yet complete. My advice here is the opposite: we're not ready for that conversation yet. Users of any site are inherently biased against redesigns, and with Wikipedia's community consensus model, that gives you an unenviable uphill climb if you wish to succeed where past efforts have failed. Because of this, there will be a certain level of guaranteed opposition, and to overcome it, you'll need the design refined enough to get every winnable editor on your side. New Vector has improved a lot over legacy Vector, but I don't think it's at that point yet.

Some of the changes are fairly simple things. For instance, looking at the ToC to the left right now, it ends a ways before the bottom of the page, resulting in an ugly scrollbar that likely could've been avoided if it just extended the full vertical length of the page. Making refinements like that will help avert a gut "this is ugly" reaction and could making the difference between consensus and no consensus.

Other changes are more fundamental. The reduced screen width is something I'm fairly used to at this point, but it seems to be a sticking point with many others. Given that, I think you need to decide how many of the New Vector changes are segmentable. I.e. if the community says "we're okay with everything in New Vector except the screen width" or "we're okay with everything except the ToC", will you be able to implement that? I know you'd prefer to be able to implement everything, but if it has to be an all-or-nothing decision it'll make your task all the harder, because opposition to any one element could foil the entire proposal. So I'd put some thought into what can be segmented out vs. what has to be bundled.

On the ToC, getting it to display so that it doesn't require scrolling in normal cases, even when the main menu is uncollapsed, is something that I predict will be crucial for getting community buy-in. We've been discussing it on MediaWiki, so let's continue the conversation centralized there.

Lastly, I'll reiterate that I think that the upper right corner is going to be a sticking point. We've previously discussed (with Izno and others) how the decision to commandeer that spot for the language switcher appears to have been made based on user research that began with the baseline assumption that making it more prominent was an inherent good, ignoring the other elements that currently occupy that space and that are also important. In your most recent newsletter, you write that the page tabs/title switch moved the language button into an even more prominent position at the top of the page, once again making this assumption, and once again ignoring that you're pushing the other elements down yet another row. When we've brought up those elements, namely coordinates and good/featured article icons, you've declared them out of scope for your project. I don't understand that — you consider it in scope to push them out but not to care about where they're pushed to? Helping readers understand through the site design which articles have undergone a peer review is absolutely crucial for information literacy, and I really wish you'd convene one of your focus groups to understand whether they have any clue about GA/FA currently (my guess is no) and, if not, what can be done through design to fix that (my suggestion is moving them left next to the article name).

If you manage to address these sorts of things, I think it'd be possible to start a productive conversation on making New Vector a default few months from now. That conversation could incorporate multiple steps as you suggest, and it'd probably best take the form of a CENT-listed and watchlist-advertised RfC. If you start it prematurely, though, I think the combination of reasonable and knee-jerk concerns will result in failure to reach consensus, which would set you back. (And I hope it goes without saying that attempting to push through the changes without community consensus would result in a Framgate-level firestorm.) Cheers, {{u|Sdkb}}talk 00:34, 14 July 2022 (UTC)

@Sdkb Thank you for your thoughtful reply and thoughts here, and for being super helpful and giving us feedback throughout the process! Apologies for the long response time - we’ve been monitoring this conversation and replying to quick questions, but wanted to sit with your comment for a little bit to make sure we can address all the points you raised. Here are some of our thoughts and answers - curious what you think as well:
  1. Thank you for flagging that you think the conversation feels a bit premature. We're very excited to begin bringing the changes to readers as well as to flag where the issues are early on, but agree that the next step would be to continue at a longer timeline than the three weeks we had originally suggested. We would like to continue the conversation by identifying which blockers we have for deployment, making sure that our understanding of “finalized” matches that of the community here. In future iterations of this conversation, we’ll also make sure to highlight this point so as to avoid confusion.
  2. ToC issues. Just adding note here, but also agree we can continue discussing in the other thread - sorry for the repetition! We’re currently working on some improvements to the ToC for narrow screens, tracked in phab:T306660 which we hope to have live next week. In these, we have improved the styling of the ToC so that the scrollbar does not appear unless actively scrolling - I agree it’s pretty unsightly. Does that alleviate your concerns somewhat? In the future, after the deployment, we plan on separating more tools out from the main menu, such as the page specific tools. These changes will also allow all menus to be individually collapsible and can also serve as the first step to a more highly customizable system. They will also shorten the main menu significantly. That said, as these changes are pretty technically significant, we would like to confirm the plans for the new default before beginning this next part of our desktop development.
  3. On the reduced width - I agree this is tricky. We do have some capability to offer customization, but this becomes more difficult to maintain and test with every option we add. To us, the best case scenario would be to continue to promote the use of individual gadgets and scripts among editors, but if this is deemed insufficient, we can begin scoping out a potential setting for logged-in users. That said, it’s probably not something we’d be able to offer for every feature - it would depend on the request, how difficult it would be to maintain, and how independent it is of the other changes we’ve introduced.
  4. Coordinates and upper-right corner issues. This is a priority for us right now as well. In terms of the prominence of language switching - getting higher priority for languages is an important aspect of the project’s goals which are to focus on growing our readership and communities globally. This includes an enormous audience for whom language switching is crucial, and who tend to use a global language, such as English or French, in addition to their local language, for learning on a daily basis. We want to make sure we’re taking their needs into account as much as those who are native speakers. That said, we need to make sure the other elements like indicators and coordinates work well with the new location. This has been tricky as the location of these has traditionally been in the hands of the community. Our view on this is that the order should be as follows (vertically): language button, tabs, indicators and coordinates. Indicators and coordinates should appear on the same line and preferably, coordinates would be treated as indicators. We'll be adding some more thoughts and hopefully some ideas for next steps on the current conversation in VPT.
Hope this is helpful! We’ll continue getting into the details on the individual threads as well, but can also definitely keep talking here too. Also we hope to post a longer response to everyone that’s been involved in the conversation here later today on the next steps in the process. OVasileva (WMF) (talk) 12:27, 27 July 2022 (UTC)
@OVasileva (WMF), thanks for the reply! On the ToC scrollbar, it's not the scrollbar itself that's ugly so much as the fact that you have to scroll to see the full ToC. The entire point of a ToC is to let you see a summary of a page without having to scroll through it all, so if you can't do that, why have a ToC at all? This is certainly an issue for larger articles or talk pages. One possible solution to explore is having the ToC width double when you hover the cursor over it so that less needs to go onto two lines; does that make sense as a concept? {{u|Sdkb}}talk 04:12, 29 July 2022 (UTC)
I think that spacing the TOC entries out less would be a good idea as well. The current TOC is just a bit too "fluffy" in my opinion. CactiStaccingCrane (talk) 04:14, 29 July 2022 (UTC)
Hey @Sdkb - thanks for replying to the reply! You bring up a good point. Hovering on the ToC is something that we had initially explored in our first prototypes which we tested with groups of readers and editors in English, Spanish, and Indonesian (more details on the report page). However, we saw that across all groups, people preferred having the ToC shown in full without having to take an action (such as hover or collapse) to view it. So we decided against it and opted for maximizing the space within the sidebar instead to show as much of the ToC as possible. It's possible that later on, we can explore a more specialized solution for cases where line wrapping is particularly prominent (such as talk pages like you mentioned). For now though, I think the tradeoff of having the ToC available persistently is worth the introduction of scrolling in some cases. Our A/B test data came in recently and we're seeing a 50% increase in clicks to the ToC. We'll be monitoring this over time, but are really happy to see that it's helping people navigate back and forth across the page more. Next we'll be looking at the scrolling data - we hope to see a similar decrease in scrolling that we saw with the sticky header. OVasileva (WMF) (talk) 08:51, 2 August 2022 (UTC)
I am just an editor/reader that uses one language (as well as "many" others I suspect) so please consider this when "prioritizing". If it is rushed there will be more negativity than imagined.
A consideration has to be given to those that write before it can be read. From what I read, in a search, it seems that "a reader could be forwarded to the English Wikipedia without any reference to a page in their native language, especially when the page does not exist in the Wikipedia of the redirect's language". This would mean that ease of language change would be helpful.
Otr500 (talk) 02:04, 5 September 2022 (UTC)

UX research and usability testingEdit

Note, I am an engineer that uses terminals a lot and I still use the MonoBook skin. But, here's a question. If moving to the new Vector skin is controversial, why not commission and publish an extensive user-centered design case study to prove that the Vector 2022 is actually better. Then the community will have to see reason. (Maybe) Andrevan@ 03:23, 15 July 2022 (UTC)

Hey all,

A number of you have asked us about our research and testing (both Qualitative and Quantitative), so we wanted to write a pretty detailed and long comment to address this. We wanted to confirm that not only the Growth team conducts complex testing :) This is more like the standard for big projects now. Each feature change has gone through the process below (which we also described in the Signpost in April). This is what gives us the confidence that everything we have built so far is, in principle, an improvement. At the same time, we acknowledge that there's room for more adjustments.

  1. Problem identification research with both readers and editors - during this phase, in 2019, we studied the way people used the site and identified the largest usability issues as well as issues to exploring the site further, becoming more engaged with reading or editing. We did this by interviewing readers and editors across multiple countries and locations. (See the links: Research and design: Phase 1, Research and design: Phase 2.)
  2. Prototype development and testing - this is when we build out the ideas of a feature and begin showing solutions to our audiences. Each feature was tested with readers and editors through interviews and wider rounds of prototype testing. Generally, for testing with editors we used central notice across multiple language Wikipedias, including English Wikipedia, so that we can get the widest audience possible. Each prototype was tested by approximately 200 editors on average. (Example)
  3. Refining and building - we then take the feedback from the prototype testing and refine or change the prototype based on what needs were identified in the prototype testing. In some cases, we ask for additional feedback during this process so that we’re sure we’re making the right decisions.
  4. A/B testing and other quantitative testing on pilot (early adopter) wikis - we perform a quantitative test for whether the feature works as expected based on the criteria of success we have previously defined. For example, the sticky header was designed to decrease scrolling to the top of the page. We gave the sticky header to 50% of users and compared them to the other 50% for two weeks. After two weeks we compared the results and identified that people who had the sticky header were indeed scrolling less to the top of the page in order to select any of the tools available there. If we get negative results from our test, we change the feature and test again. This is the "beta" phase. During this phase, we also monitor usage across all wikis, including English Wikipedia, where many account holders are already using the new skin.
  5. Finally, we deploy Vector 2022 on more wikis and continue monitoring the way people are using it so that we can flag any issues. In this phase, Vector 2022 isn't "beta" anymore. It's more like a B-class article. Different wikis have different thresholds for B-class, and we believe that in the case of English Wikipedia, we'll be there when the visual refinements and other deployment blockers are ready.

We are currently working on an easy way to explore all of the above data and research (and are welcome to suggestions on the best format). For now, the best way to learn more about the testing is:

  • From Reading/Web/Desktop Improvements/Features, select the feature you are most interested in
  • Within that feature page, refer to the Qualitative or Quantitative testing section to see the results and our conclusions

Just so we can have a short version of this as a part of this conversation, we're posting a quick list of our learnings:

Collapsible sidebar

The collapsible sidebar allows people to collapse the main menu in order to focus on reading - helping to find the information needed without distraction

  • Qualitative testing with readers and editors on the usefulness of the sidebar and our navigation. Our conclusion here was that the number of different tools provided on the page by default was found to be overwhelming by readers and actively discouraged them from reading, but also from exploring the functionality within the page, an effect opposite of what the exposure of multiple tools aims to do. More details can be found on our feature page for the collapsible sidebar, as well as within the original report
  • Quantitative testing on the usage behavior of the sidebar itself, in both its open and collapsed states (see the results). When using the sidebar, logged-out users are much more likely to collapse it and, once collapsed, to keep it collapsed. In addition, the rate of un-collapsing also indicated that users are aware that, were they to need to navigate to an item in the sidebar, that option was available to them.
Maximum line width

We have introduced a maximum line width to articles. Research has shown that limiting the width of long-form text leads to a more comfortable reading experience, and better retention of the content itself.

  • Our studies with readers showed that readability was an issue with the current interface, in particular being able to focus on the content
  • Pages that are not in a long-text format (such as diffs, special pages, page history) will be presented at full-width as before
  • Logged-in users who wish to read articles at full width are welcomed to set up a script or gadget that will allow for this, such as this one
  • For more details on research and motivation, see ourresearch section
Search

The new search widget includes important context that makes it easier for users to find the query they are looking for by adding images and descriptions for each search results

  • People had difficulties finding the correct result using our previous search
  • Our A/B testing showed that adding the new search can lead to a 30% increase in search sessions initiated on the wikis we tested
Language switching

The new language switching tools are more prominently-placed than before. They allow multilingual readers and editors to find their preferred language more easily.

  • Readers did not previously know they could switch languages from the page, even if they read multiple language wikis habitually. They would use external search engines to find the correct article instead.
  • In our user testing, new readers were able to find the new location much quicker than the previous location
  • Our qualitative testing showed that this was more difficult to find for existing users who were used to the previous location, leading us to iterate on the feature. We have since added a note in the previous location of the language switcher and made the button itself a more prominent color
  • In the future, we will continue exploration on languages, considering potentially a direct link to a person’s most frequent languages
(note to @Sdkb: we know you have some questions on language links that are still open - we’ll get back to you on these in a separate message)
User menu

The new user menu provides links to all links related to the user in one place. This reduces confusion between general navigation links and specific user links

  • New editors were confused between the links at the top of the page and other navigation. They didn’t know these links pertained to their personal tools
  • Our user testing with readers and editors showed that people found it intuitive that all user links are in a single menu and that the menu is easy to find
  • In our prototype testing, 27 out of 38 (71%) editors and other logged-in users showed strong positive experiences with the user menu
  • Based on community requests and current data, we iterated on the feature and moved the watchlist link out of the user menu for easier access
Sticky header

The sticky header gives access to functionality that is used most frequently that was previously only accessible at the top of the page. The goal is for people to scroll less and thus, save time

  • Our A/B test showed an average 15% decrease in scrolls to the top per session for logged-in users within the 15 pilot wikis we tested on

OVasileva (WMF), SGrabarczuk (WMF) (talk) 16:14, 15 July 2022 (UTC)

Thank you for posting this; there is a lot to read through so I have only reviewed two features so far, sticky header and persistent table of contents. For the latter, it appears you have yet to conduct A/B testing but when you do I would be interested in seeing data on the percentage of page views that involve at least one click on the table of contents, and the percentage of page views that involve at least two clicks on the table of contents. In addition, I would be interested in seeing separate data for mobile users and desktop users. Struck following clarification that this is only proposed for desktop. BilledMammal (talk) 04:43, 23 July 2022 (UTC)
For the former, I see you have already conducted A/B testing but there is some additional data that I would like to see:
  1. Currently, you show the clicks per session and clicks per page only when skinversion=2; I would be interested in comparing this to the clicks per session and clicks per page for skinversion=1. My hypothesis would be that the sticky_header makes it more convenient for readers to access these links, and thus increases the number of readers using them.
  2. The rate of accidental clicks. Assessing this would vary by link, but I have a few ideas and am happy to discuss further if required. My hypothesis would be that the sticky_header increases the number of accidental clicks, and we would need to consider whether this increase offsets the benefits of the sticky_header.
  3. Time on page, time on page when limited to pageviews that do not involve following a header link, and time on page when limited to pageviews that involve following a header link. Clicks on pages with stickyHeaderDisabled would need to be split between those that involve a scroll back and those that do not. My hypothesis would be that it does not affect time on page for readers who do not click on a header link, and that it has a small but relatively constant absolute decrease in time on page for readers who follow links on the sticky_header compared to those who scroll back to click on a header link. The former would suggest that this does not negatively affect the reading experience, the latter would suggest that that this has a positive effect on the reading experience for readers who are wanting to navigate to one of those pages.
Alternatively, is there raw data that we can look at from the A/B testing for the sticky header? I suspect it won't answer #2, but it may contain information on #1 and #3.
BilledMammal (talk) 03:33, 17 July 2022 (UTC)
@BilledMammal - thanks for your questions! You bring up some really good points that we considered during the design phase of the experiment. The full data analysis is available here: https://jenniferwang-wmf.github.io/Web_sticky_header/. In terms of your questions:
1. Comparing overall clicks. This is something we can look into and report back. The reason it wasn't a main goal for the A/B test is because we wanted to focus on decreasing scrolling (i.e. making the site easier to navigate by requiring less of the user) rather than setting a goal for increased interactions. As in, we would still consider the feature a success if people used the tools as frequently as they did before but had to scroll significantly less in order to do so. That said, I agree with your hypothesis that we most likely would see a significant increase in clicks as well.
2. Accidental clicks are a bit trickier to measure. Generally, with new features, we get a lot of clicks in the first day or so after deployment (which are generally more based on curiosity than accident). This is why we run our tests for an extended period of time - 2 weeks, to make sure it's sufficient time for people to get used to the new functionality and begin using it as they would naturally
3. We discussed looking at time on page at the beginning of the test but decided to look at scrolling specifically instead. While I personally believe that your hypothesis is correct, we've had some issues in the past with looking at the time on page metric and receiving conflicting data. For example - time on page may actually increase over time with the sticky header available because people would be less frustrated with not being able to access specific tasks and thus more open to spending longer on our sites overall. The same is true of scrolling - people might scroll more overall because the site is easier to use. This is why we specifically looked at scrolling to the top of the page as we thought it was the clearest signal that people are going there specifically to find one of the tools available in the sticky header. OVasileva (WMF) (talk) 09:06, 2 August 2022 (UTC)
@OVasileva (WMF):, thank you for your reply, both here and below.
To summarize my position; I see the tests you have done as testing whether the feature is used, but not anything beyond this. With this, it is only possible to come to the conclusion that this proves that each feature is an improvement if the pre-existing assumption is that the feature is an improvement, and thus the user experience is improved so long as the feature is used; I understand how you can see this differently, but I disagree.
I do agree that time on page isn't a perfect metric, but I believe it is a better metric than what is currently being used, and I also believe that those concerns can be partially addressed. For example, looking at the various options on the header bar the only one that I can see plausibly altering behaviour is the search bar, with readers using it more and doing a shallow dive into multiple articles rather than a deep dive into one; to address this we could separate the data into sessions that use the search bar and sessions that don't.
Regarding accidental clicks, that is a good point regarding the curiosity clicks; most methods to identify accidental clicks that I am aware of would likely see those as false positives. Are you able to identify which sessions belong to same logged-in user, as that might offer a way to exclude most curiosity clicks? BilledMammal (talk) 16:46, 7 August 2022 (UTC)

Has anyone actually used the link given at the very top as "see what it looks like" on a smartphone? For me, instead of getting an encyclopedia article, I get a full screen with the sidebar and no encyclopedic content until I scroll down. Can other people please test this? Because this seems like a quite major bug or worse experience than the current mobile version. Fram (talk) 08:46, 17 July 2022 (UTC)

Same bug here but only if I'm using the mobile view in a browser. If I'm using the desktop view on mobile it works fine (and actually looks quite nice). With this said, it may be a non-issue as I've not read anything about mobile transitioning away from MinervaNeue. Anarchyte (talk) 09:01, 17 July 2022 (UTC)
FWIW, I see the same bug as Fram does, on both a Macbook laptop (not mobile) running Safari 14.1.2, and on an Android phone running Opera 69.3.3606.65458 in desktop mode. I just see a banner at the top, a sidebar on the left, and a big blank space on the rest of the page. I have to scroll way down past the sidebar before I see any content, and the content fills the full window width (that is, the sidebar is not to the left of the content, it's above it). There's also no visible TOC on the left side or anywhere, just a hamburger icon that I have to click on to open a TOC. I do not see this bug on Firefox 102.0.1 on a Windows machine. It seems there is still some browser dependency that makes this skin very unpleasant to use in some environments, and not only mobile ones. CodeTalker (talk) 00:51, 18 July 2022 (UTC)
Confirming I see the same thing as Fram in mobile view on Firefox 101.2.0 on Android 11. Desktop view looks intentional. Folly Mox (talk) 18:01, 18 July 2022 (UTC)
It looks great to me (tablet, mobile & desktop) if the sidebar's collapsed. ― Qwerfjkltalk 21:29, 18 July 2022 (UTC)
This is indeed what you see if you force the mobile website to the desktop website/skin (not something anyone but a few realistically is doing) and you open the menu (for me the menu is collapsed by default on that size). While this desktop skin is more compatible with mobile and will eventually probably be fully suitable for mobile, that has not been the primary target of these changes. I believe there is an invite on its talk page asking people for feedback and ideas on what the menu SHOULD look like on mobile. But don't forget that lots of the content is not mobile compatible (minerva on the mobile site has all kinds of hacks to make content not break out of the mobile constraints) and Vector 2022 doesn't have those hacks. So for the immediate future it is still better to use the mobile website on mobile. —TheDJ (talkcontribs) 08:49, 19 July 2022 (UTC)
Apparently you get the same bad results on a Macbook laptop though, see above... Fram (talk) 09:21, 19 July 2022 (UTC)
I've just tested this on a Macbook in Safari and can't reproduce the issue - the link destination looks exactly as intended. Sam Walton (talk) 10:39, 19 July 2022 (UTC)
And of course, nothing in the opening statement of this section said anything about this not being for mobile and only for desktop, it just said that this would become the default, full stop. Fram (talk) 09:23, 19 July 2022 (UTC)
Just to confirm, this conversation concerns changing the skin on desktop only. This will affect the desktop view on mobile as well, but not the current default mobile view. OVasileva (WMF) (talk) 13:27, 20 July 2022 (UTC)
On desktop (not mobile), using Firefox on a MacBook Pro, if I click on the suggested Galaxy link and narrow my window to about half my screen width, I get a view in which only the left toolbar is visible. The rest of the window is blank. The article itself is off-screen below the toolbar. This is a normal width to narrow the window for when I want to see two apps at once, and much wider than its minimum width (which I sometimes use as a quick test of mobile views). On the other hand, when I view it in full screen width, only maybe 60% of the window width is dedicated to content, with maybe 10% sidebar and 30% unused blank space. This extreme sensitivity to window width, unusability on too-narrow windows, prioritization of sidebar over content, and inability to use much of the real estate on too-wide windows, makes this seem like a non-starter to me, but maybe these are things that are still subject to improved design before the push to roll this out to the world? —David Eppstein (talk) 01:29, 8 August 2022 (UTC)
@OVasileva (WMF): Backing up here, can you clarify whether the team has tested the new skin altogether for readers yet (as opposed to the individual feature changes like sidebar and header)? Sorry if you or someone else said that already and I missed it. It's cool you tested the independent impact of each change, but to help make final decision on the default, it's also important to see whether all the changes holistically had impact on basic readership metrics (unique visitors, bounce rate, time spent on page, etc.) Thanks, Steven Walling • talk 03:06, 31 August 2022 (UTC)
Hi @Steven Walling, thank you for your question! Here is a quick overview to the approach to monitoring:
To ensure the success of the skin as a whole, health metrics are defined with the purpose of monitoring across the usage of the skin as a whole. This monitoring happens across all the partner projects where the skin is already default (thus, it is possible to monitor the different stages and states of the skin over time, so that we can quickly identify if any given feature was affecting the health metrics negatively). This allows monitoring of large projects (such as French Wikipedia or Japanese Wikipedia) as well as smaller projects across a number of languages. These metrics include pageviews, unique devices, edit rates, account creation, and more.
Because it is difficult to run A/B tests on logged-out users for long periods of time, the focus is on monitoring significant fluctuations in the short term, and also on reviewing on a quarterly basis to establish any long-term trends (which are compared to the long-term trends of similar wikis where the skin is not default). So far, we have found slight increases in account creation on initial pilot wikis, no decreases in pageviews attributed to the new skin, and no decreases in active editors or overall editings attributed to the new skin.
As mentioned above, time on page is not used as a key metric since fluctuations in time spent on the page can be quite misleading without having more detailed data on precisely what people are doing during this time (which generally would require tracking that is complicated and potentially not privacy-friendly). For example, an increase in time on page could be seen as negative - many of the our new features (such as a persistent ToC and sticky header) are designed to save people time in scrolling. But it could also be positive - the new experience makes a wiki so much easier to use that people are spending more time reading and interacting with the content. OVasileva (WMF) (talk) 13:03, 5 September 2022 (UTC)
Thanks for reply! This all makes sense. I'd just suggest during the RFC that you link to / summarize the health monitoring metrics for the Wikipedias where the new skin is the default, in order to show the community that in addition to the A/B test results, the rollout of the skin has either improved or not regressed key metrics. People will continue to have feedback based on what their individual preference is, but these data really help prove that the skin is worth changing the default to for readers. Steven Walling • talk 16:31, 5 September 2022 (UTC)

Easy switching skinsEdit

After I switched to the 2022 skin, I noticed a new link "Switch to old look" in the left margin, right below the "donate" link. But in the legacy (current) skin there is no corresponding "Switch to new look" link. Why not? wbm1058 (talk) 05:21, 23 July 2022 (UTC)

@Wbm1058 that is a temporary link designed to help anyone that is all of a sudden lost in the change to get back to being able to get around again. — xaosflux Talk 11:40, 23 July 2022 (UTC)
I understand that, but the purpose of the "Switch to new look" link is to give readers a heads up that the change is coming so that they can check it out if they opt to. Then hopefully feedback on the changes is given in a manageable trickle so that things can be fixed before a hard change is made that causes an angry mob reaction. Not everyone is as tuned into this as you are; the only way I've become aware of this is from seeing the change in the French and other foreign-language versions. Not everyone is a power-user like me who reads foreign language wikis using Google Translate.
Will the French 2022 skin and the English 2022 skin be the same width, or is the English 2022 skin wider than the French 2022 skin? – wbm1058 (talk) 15:05, 23 July 2022 (UTC)
@Wbm1058 by default all of the vector-2022 skinned sites will have a similar look and feel. We have a opt-in gadget available if you want vector-2022 but in wide mode (mostly for wide screen desktop monitor users); it is still getting some improvements. — xaosflux Talk 16:01, 23 July 2022 (UTC)
It looks like this. — xaosflux Talk 16:04, 23 July 2022 (UTC)
Wide vector-2022 on a page with a TOC , there is work pending on a collapsible TOC for vector-2022 overall still. — xaosflux Talk 16:06, 23 July 2022 (UTC)
And for users like me, will it be easy to use the version suitable for a large monitor on my PC and the other on my iPad. Doug Weller talk 17:20, 23 July 2022 (UTC)
If it became popular, a toggle such as "dark mode" toggle could possibly be built. — xaosflux Talk 17:02, 25 July 2022 (UTC)
This is a great question, @Wbm1058. When we made the decision to put this link into the sidebar, the project was on an early stage. Now I think we could revisit this and put an equivalent link into the legacy Vector sidebar. SGrabarczuk (WMF) (talk) 16:48, 25 July 2022 (UTC)
+1 this both for easy toggling as expressed in the Phab task, but more importantly as a pre-release promotion per Wbm1058. This should also be available as a cookie-backed pref for non-account/not-logged-in readers, SGrabarczuk. ⁓ Pelagicmessages ) 14:25, 9 August 2022 (UTC)
Thanks, @Pelagic. Regarding the last sentence, this is unfortunately off the table. It's beyond our power to make it possible. I'm sorry. SGrabarczuk (WMF) (talk) 23:00, 24 August 2022 (UTC)
@Pelagic: Just so. SGrabarczuk, who has the power to make it possible? It seems like a natural step. – SJ + 15:22, 1 September 2022 (UTC)
@Pelagic and @Sj, I'll try to explain this based on what I managed to figure out myself (thanks to @Jdlrobson for review and input). For more details, read blog posts: How a new data center in Singapore is helping people access Wikipedia around the globe, Building DReaMeRS: How and why we opened a datacenter in France, and Why performance matters.
The priority has been to make our sites load quickly. Most traffic comes from logged-out users. Put everything below in the context of these two factors.
To handle the vast majority of traffic, we have a few "caching servers" which only save and send "snapshots" of web pages to the logged-out users (instead of generating actual web pages). This allows us to serve these pages significantly faster in a way that doesn't overload the other servers.
These "snapshots" are the same for all logged-out users. Dark mode and any other preferences for logged-out users would require generating different versions of actual web pages. This would overload our servers. But we don't want to do that because we need to reduce cache fragmentation.
The only reason we have preferences for logged-in users is we don't serve these "snapshots" to logged-in users. We can do that only because the group of logged in users is tiny compared to the total page views.
The only possible way of providing preferences for logged-out users now is making the settings (whether any custom ones are enabled by an individual user or not!) load always after the page. This takes much more time to load and looks odd. For example, if a logged-out user was to see the dark mode in action, then immediately after loading each page, they would first see the light interface for a short moment, and then the interface would become dark.
If you disagree with any of the above, or have ideas on how to change that, please discuss this on wikitech-l.
The decisions on making changes to the architecture mentioned above would require work and input from multiple teams in both the Product and Technology departments, and are quite outside of the scope and capabilities of the Web team. Which is why this is way beyond the project of Desktop Improvements and the Vector 2022 skin.
Is this all clear? Thanks, SGrabarczuk (WMF) (talk) 13:33, 20 September 2022 (UTC)
As a semi-technical follow up: the front end caches that we serve logged out ("anon") content from are a signficant chunk of our server hardware and have a huge effect on perceived experience. We try to avoid splitting that cache at all costs. (There have been experimental efforts on "Edge Composition" or "Client-side composition" as a means to efficiently customize content post-cache, but these have never made it to production.)
Splitting the anon cache to serve a light mode and a dark mode would halve the space available for that cache. That wouldn't halve our hit rate, exactly, but it would have a significant performance impact on all users (or a significant financial impact on the foundation, if we doubled our hardware budget for that cache).
We do have mechanisms to do (for example) A/B testing, but those are based around bypassing a small fraction of the incoming traffic to a small dedicated cluster serving the test. That sort of traffic splitting /does/ scale: add another small dedicated cluster and you can either double the participation in the A/B test or add a "C" option. The difference with dark mode (or vector-2022) is that the proposal is to make it available on 100% of the traffic. In theory you could send everyone with a "dark mode" cookie over to a separate cluster, but that only works if hardly anyone ever uses dark mode. C. Scott Ananian (talk) 21:29, 21 September 2022 (UTC)
Thanks SGrabarczuk and Cscott -- that makes sense. Flickering-dark-mode sounds fun for about two seconds. I suppose one could still offer logged-out users the same sort of option, but have it take them to a login page that after login redirects them back to the page they were viewing, with the preference set...
How large are current A/B test fractions -- 0.1% of sessions, less? Is the new skin getting such a test w/ logged-out readers? – SJ + 23:23, 21 September 2022 (UTC)

Vector 2022 office hoursEdit

Join an online meeting with the team working on the Desktop Improvements! It will take place on 26 July 2022 at 12:00 UTC and 19:00 UTC on Zoom. Click here to join. Meeting ID: 5304280674. Dial by your location.

Read more. See you! SGrabarczuk (WMF) (talk) 16:49, 25 July 2022 (UTC)

Hey all, wanted to ping @Sdkb, @Xaosflux, @Bilorv, @TheDJ, @BilledMammal, @IAmChaos, @Jonesey95 and anyone else who is curious - we're hosting office hours later today - if you're interested and have the time, you're welcome to join to talk through questions, comments, and the plan overall. In terms of the conversation here, we plan on answering open questions (we know there's still a few), summarizing the discussion, and identifying some next steps over the next couple of days. OVasileva (WMF) (talk) 08:07, 26 July 2022 (UTC)
Just want to say it's great that you are offering this and I hope people take you up on it! Andrevan@ 21:34, 30 July 2022 (UTC)

An update after two weeks of discussionEdit

1. What should the process look like?Edit

Hey all,

Thank you for your feedback. We recognize that this is a large and important change to our interfaces that will affect the default experience for millions of people. We appreciate your patience in this discussion on how to proceed in the best way possible for our readers, contributors, and communities.

We will try to summarize the feedback we have gotten so far, and continue with identifying next steps. Based on your feedback, we would like to propose the following process:

  1. Agree on what changes need to be made to the interface before the final deployment conversation
  2. Continue with a conversation focused on building consensus around deployment
  3. Deploy and continue with other improvements and requests that were agreed to be non-crucial for deployment

Does this seem in-line with your expectations? Do you have any concerns?

2. Why are these changes improvements?Edit

Many of you were curios about the changes, and especially expressed interest in getting more details on our data and process. Below, we are outlining a bit about our process, as well as the data we have collected that proves that each feature is an improvement. Ping: @BilledMammal, @IAmChaos, Barkeep49, KevinL, Andrevan.

TLDR: Every one of our changes goes through a rigorous process of research, development, qualitative and quantitative testing with readers and editors, prototype testing with editors (across 30+ language communities), iteration, and post-deployment monitoring. When a change does not meet the success criteria or does not perform better than the existing version of a tool, we either stop developing the change or iterate until performance is improved.

We believe that the changes we have made will be crucial to making the site more welcoming and easier to use to new readers and editors.

When compared to the older version of the Vector skin, Vector 2022 is proven to:

  • Save time while reading and editing (measured by decreases in scrolling to the top of the page after the introduction of sticky header and table of contents)
  • Increase exploration within a given page (measured by increased clicks to the table of contents)
  • Improve readability (measured via collapsible sidebar usage)
  • Improve the discovery of new content (measured by an increase in searching)

You will find more details in the section #UX research and usability testing. We have tweaked the existing comment a bit. OVasileva (WMF), SGrabarczuk (WMF) 01:53, 28 July 2022 (UTC) — continues after insertion below

Thank you for spending the time to write this out. My concern is that you are focused too much on testing for the change you intended to make and in doing so miss the broader impact. Because of this I feel your analysis only proves that you brought about your intended change, rather than proving that each feature is an improvement.
For example, consider the sticky header. Here, the goal is to (1) improve the user experience, by (2) saving reader time, by (3) reducing the amount of scrolling to the top that they need to do.
However, you only test for (3); you then infer (2) from the positive result for (3), and infer (1) from the positive result for (2). Testing directly for user experience is difficult, but to reduce the risk of errors the goal should be to get as close to that level as possible, and in this case it means testing for (2) rather than (3); if you look at #3 in my previous comment you will see that I am requesting data that should give us an answer to (2).
In addition, you assume there are no negative impacts from the change. This isn't a safe assumption, and with #2 and #3 of my previous comment I request data that will allow us to consider this possibility. BilledMammal (talk) 06:56, 28 July 2022 (UTC)
Hey @BilledMammal - sorry for the delay in response! I replied briefly to your initial comment above. TLDR is that we try to design experiments using more precise metrics because more open-ended metrics (such as time spent on page) could be interpreted in multiple ways. More time on page could be an improvement (people have a better experience and thus spend more time on the site overall). Less time on page could also be seen as an improvement (we're saving people time in scrolling so they get to what they need to do quicker). We can keep discussing there or under this thread - whatever is easier! OVasileva (WMF) (talk) 09:11, 2 August 2022 (UTC)
Thank you; no worries about the delay in response, and apologies for my own delay in response. I've replied above. BilledMammal (talk) 16:46, 7 August 2022 (UTC)

3. Why are we having this conversation while development is still happening?Edit

We are eager to bring the improvements mentioned above to our readers. Currently, many new readers do not feel welcome by the interface as it is, and this is something we hope to solve as soon as possible. We recognize that no feature or skin will ever be perfect, and there will always be room for improvement. As we mentioned above, the skin, in its current form, is already a significant improvement over the current state.

The final state of the skin also depends on the conversation we’re having right now. There are many possible improvements or ideas for changes we can build and focus on. We’d like to discuss which of these are most important to the community as we proceed to implement and put the last touches on this version of the skin.

Finally, as we mentioned in a previous post, once deployed, we plan on continuing to work on the desktop experience. This project opens more possibilities for the future and gives us the opportunity to work with communities to provide new and necessary tools both for readers and editors. This is an ongoing process and it will be done with the feedback and collaboration of the community here and across other projects.

4. What changes will be made before deployment?Edit

Our request for you is to review the list below and let us know if it looks correct in your opinion. What should be added? What should be removed? Do you have any questions on what each of these items will and will not include?

As a part of these conversations, we plan on placing requests into three categories. This categorization is based on our research, previous conversations with communities and prototype testing, as well as the feedback we received from all of you last week. These categories are flexible. We need your feedback to move something from one category to another, as well as to add items to each category.

  1. Issues we would like to address prior to the deployment
    1. Table of Contents collapsing and narrow screens behavior (@xaosflux, @sdkb). We are working on this and hope to have it ready within the next few weeks (more details in T306660)
    2. Visual refinements (@IAmChaos, @Terasail). We are working on this and we will finish before deployment, with the first part landing next week (week of August 1). To see more details on what visual refinements we are and how we worked with communities to define these, please see this page
    3. Making a decision on ToC handling and magic words (ping @xaosflux, @izno, @IAmChaos, @Anarchyte). We are doing a more in-depth review of magic words and hope to come to you all with a proposal on what (if anything) we think would be best to change. Our sense is that for some of these use cases, the new ToC has solved the initial issues for them existing. We’re interested in finding out which use cases this is not the case for, and providing a solution for those. To confirm, however, the __NOTOC__ magic word will continue to work, as will the templates creating the ToC based on __NOTOC__ such as {{horizontal toc}}
    4. Coordinates display and other indicator issues. We would like to ensure that coordinates do not overlap with any existing indicators and that the area in the top right corner of the article is well-organized (T281974). Special thanks to Xaosflux, Izno, theDJ, Sdkb, AlexisJazz for participating in the discussion and helping us identify next steps. The conversation around coordinates continues in VPT#Coordinates in Vector 2022
    5. Making it easy to opt-in and opt-out ​​(@Shearonink, @wbm1058) - we have a button in the sidebar, which allows for easy recognition of opting out. Opting in is, however, only available through the preferences page. We’d like to explore the possibility of running banners that explain that the change was made and provide opt-out instructions as well. Similarly, prior to the change, we’d like to run more banners that encourage people to opt in and give us feedback
  2. Issues we would like to address after the deployment
    1. ToC/sidebar length and the separation of page tools from wiki-wide tools (@sdkb). This is a significant change that we would like to move forward with once we have everyone using the new default. This will be the best way to study and build out customizations for the various use cases (example: the ability to add admin tools or gadgets like Twinkle to the menu)
  3. Issues that will not be addressed at this time (issues that are not part of the Desktop Improvements project, belonging to other teams, etc.)
    1. A preference which allows the fixed width of the page to be turned off. OVasileva (WMF), SGrabarczuk (WMF) 01:53, 28 July 2022 (UTC) — continues after insertion below
      A local gadget (currently experimental) or personal userscripts may address this at an individual editor level. — xaosflux Talk 10:10, 28 July 2022 (UTC)
A quick note here that we've started collecting a list of different gadgets and customizations that folks have built over the course of the project in our repository. We hope to expand this as we hear of more gadgets and scripts and encourage whoever is interested to use what's there or add their own to the list. OVasileva (WMF) (talk) 13:12, 22 August 2022 (UTC)

5. What should the deployment conversation look like?Edit

Some of you said that an RfC would be the best approach for the conversation around deployment. Does that sound like the right course of action? One thing that we have been thinking about is ways to include the voices of readers into the decision making process. We are planning to run surveys asking readers what they think about the new skin compared to the old one. How can we incorporate their thoughts into the conversation?

OVasileva (WMF), SGrabarczuk (WMF) (talk) 01:53, 28 July 2022 (UTC)

Amazing work! CactiStaccingCrane (talk) 05:31, 28 July 2022 (UTC)
You could run a banner that provides an opt-in button for the new skin only visible for unregistered users, but then I'm not sure how they'd be able to leave feedback anonymously. The RfC could then be run in parallel with this campaign, with the ultimate decision relying on the inputs from both. Anarchyte (talk) 06:03, 28 July 2022 (UTC)
with the ultimate decision relying on the inputs from both How would this work? Who gets to decide how much to weight each if they conflict? I don't foresee the community willingly relinquishing control, so as much as I'm concerned that the community isn't going to follow WP:READER and is going to overprivilege editor needs, I think BilledMammal's suggestion is the only practical way to take reader input into account. {{u|Sdkb}}talk 04:27, 29 July 2022 (UTC)
I echo Sdkb's concerns. The skin should only be implemented if there is an affirmative consensus to switch to the new skin, especially since the new skin (as it currently stands) will make breaking changes to Wikipedia editor tools and Wikipedia article layouts. — Ⓜ️hawk10 (talk) 23:41, 29 July 2022 (UTC)
To incorporate their thoughts I would suggest running the surveys prior to the RfC, and allowing editors to assess the results of the survey when making their decision. In the end, this needs to be based on the consensus of the community, as assessed by the community. For this assessment I would suggest one thing; asking for a panel close, such as was done for the 2021 review of RfA. BilledMammal (talk) 07:23, 28 July 2022 (UTC)
I think it's premature to decide in advance that multiple closers are needed. Most discussions can be evaluated adequately by a single closer. The 2021 RfA review was by design open-ended in the number of proposals that could be made, and thus unconstrained in the variety of rationales, which were primarily opinion-based, since often there's no way to collect data without actually trying a change to the process. It remains to be seen if an RfC on a new skin will have these or other characteristics such that more than one closer might be desirable. Ideally, if the development process goes as planned, there won't be an RfC unless there is already widespread support for the changes in question, much like the default deployment of the reply tool feature. isaacl (talk) 07:45, 28 July 2022 (UTC)
My suggestion was mainly to reduce the chance of the close being appealed at AN; I don't want us to have a situation where the discussion is closed with a consensus to implement the change, only to have the AN overturn the close. Normally such a situation would not be problematic but in this case I believe it would be due to the scale, prominence, and technical nature of the change. BilledMammal (talk) 08:04, 28 July 2022 (UTC)
I think I agree with BilledMammal that the best way is to present the results of the surveys at the RfC. Olga, you really don't want to end up in the scenario where the enwiki community reaches a consensus against the change while readers say they like the change – I think the community will feel betrayed if you don't respect its decision. If you don't think you can commit to abiding by the outcome of an RfC, you shouldn't hold an RfC; I would be quite upset but less than if you ran an RfC and then overruled its outcome. Best, KevinL (aka L235 · t · c) 17:55, 2 August 2022 (UTC)

Two pretty glaring issuesEdit

Ok, so, first, the collapsable toc. if you say readers find it easy, cool, but to me it seems like we're burying our navigational tools. Which to me seems like a really really bad idea. This feels more like something done for phones to save screen real estate, than what would need to be done on a computer monitor, but whatever. If that's a fail, we'll probably find out soon enough by analyzing number of clicks on toc/side menu links.

That aside, not having the user talk page right next to the user's name is also a really bad idea.

We've already had issues with the mobile interface where it was difficult for new editors to know they were receiving warnings, because they didn't see they had a user talk page.

I realize we have our alerts system, but a direct link to the user talk page seems paramount.

if space is an issue, move the watchlist to the drop down, next to contributions (they both should be at the top of the drop down)..

But "talk" should be right next to the user name, before the notice icons. to make it clear that it's the user's talk page. - jc37 11:51, 28 July 2022 (UTC)

If that's a fail, we'll probably find out soon enough by analyzing number of clicks on toc/side menu links. That is a good point, and A/B testing should include data on this. Hopefully the WMF will be willing to engage with this and the other requests for data I made above. BilledMammal (talk) 00:09, 30 July 2022 (UTC)
Can u explain ur thoughts further? Because talk page is a concept completely unique to us, id think. So why would that be more recognizable to ppl than a notice in the notice menu? More recognizable outside of a user’s menu than within the menu ? Isn’t it just that ppl simply need to learn these things no matter where they are ? —TheDJ (talkcontribs) 08:58, 31 July 2022 (UTC)
It's simply a matter of understandability and use-ability. If you look at the various icons that are intended for the user, both displayed and those in the drop-down, I think it's fair to say that the most important ones would be the user page, the user talk page, and alerts/notices. Contributions/watchlist next, then misc "other stuff", and then preferences and logout at the end/bottom.
Wikipedia is a learning curve, to be sure. But as our user model is based upon consensus, and discussing things is often the way of things here, putting the user talk page readily viewable would seem rather obvious.
My return question might be: Why shouldn't it be there? What is the logic here?
And with that in mind, pinging @User:OVasileva (WMF) and @User:SGrabarczuk (WMF). - jc37 08:00, 1 August 2022 (UTC)
@Jc37 - sorry for the late reply here! I had missed the question around the user menu here and focused on the ToC (data for which is available in our latest update below). In terms of the user menu - what we were seeing in our research is that newcomers were having difficulty identifying that the links on the top of the page were related to their accounts at all. The standard across the web is for these links to be collected in a single visual container, such as a menu. For example, people didn't understand what the difference was between the talk link for the article and their personal talk page link, since both said just "talk". By collecting these in a menu, we're sending the signal that they are items related to the user account. That said, we did also look at the data to make sure that access to the most commonly used links are still available (https://phabricator.wikimedia.org/T289574#7462391). We saw that the watchlist, which was also initially within the user menu, was getting more than 52% of the clicks within the entire user menu on Wikipedias, and thus moved it out of the menu for easier access. OVasileva (WMF) (talk) 13:08, 22 August 2022 (UTC)
  • Comment I'm ok with the "two weeks to discuss it" idea. Best way to gather discussion points is to have an unobtrusive banner ad at the top of every page explaining what is going on. Oaktree b (talk) 23:02, 2 August 2022 (UTC)

Another TOC thing "Beginning"Edit

Vector-2022 inserts a section-0 link on the TOC, and it is labeled "Beginning". Anyone else think this is odd? See this page as an example. When I first saw that in the TOC, I didn't think "this is the beginning of the article", but "this is a section about the early days of this subject". Luckily we can localize this via Mediawiki:vector-toc-beginning. Anyone think we should? Perhaps something like "(Top)" or "(Return to top)".? — xaosflux Talk 00:38, 3 August 2022 (UTC)

@Xaosflux, we've absolutely raised this already. In the latest mockups, it's bolded, which helps a bit to distinguish it. Still, I think we'd want to consider localizing it, perhaps to "Introduction," which aligns with what we actually call the section (making the entry ramp for newcomers shallower). {{u|Sdkb}}talk 01:36, 3 August 2022 (UTC)
@Sdkb that label is on all pages, not just articles (e.g. https://en.wikipedia.org/wiki/Talk:Ireland?useskin=vector-2022 ) so "Introduction" seems even worse to me. — xaosflux Talk 09:18, 3 August 2022 (UTC)
Hmm, we could use different labels for different namespaces. Or go with something like "Top" everywhere. As I mentioned at the other conversation, I think the key will be differentiating it somehow through design rather than finding an unambiguous word (which may be impossible). {{u|Sdkb}}talk 17:16, 3 August 2022 (UTC)
Some kind of icon, such as a stylized caret ^ , seems to be the best option to me. Daß Wölf 15:40, 7 August 2022 (UTC)
Use italics (not bold) or put (Beginning) in brackets or (Top) in brackets. Definitely not (Return to top) since we are already at the top when the page loads — GhostInTheMachine talk to me 16:10, 7 August 2022 (UTC)
I've loaded in (Top) as a try; any feedback? — xaosflux Talk 16:13, 7 August 2022 (UTC)
@Xaosflux - thanks for starting this as an experiment! A few weeks in, I think "(Top)" works quite well. We discussed a little bit internally and think that leaving this up to the wikis with the default remaining as "Beginning" might be the best way forward. We explored some other options for a visual solution by adding an arrow or icon, but it felt a bit heavy on the page and potentially confusing with the carets that open/close the sections. @Daß Wölf, @Sdkb, @GhostInTheMachine - any thoughts on this approach? This also allows us to change the copy of the default, if necessary as well. OVasileva (WMF) (talk) 10:52, 24 August 2022 (UTC)
If ... "(Top)" works quite well then it is probably best to use it as the default. If "Beginning" is seen to be easier to translate, then the default should still include the brackets — GhostInTheMachine talk to me 11:07, 24 August 2022 (UTC)
@OVasileva (WMF) I agree with GITM above, that some sort of styling is beneficial there. Perhaps wrap it in Mediawiki:Parentheses-start / Mediawiki:Parentheses-end. Such styling helps to indicate to the reader that it is not a specific content label.
I think that "top" is better than "beginning" for English encyclopedia articles, but that is something the community will eventually decide. Here's an example of an english wikitionary page [1] - Just plan styled "beginning" seems out of place there as well. — xaosflux Talk 13:21, 24 August 2022 (UTC)
Maybe a thin line between (Top) and the rest of the sections would help more in making them distinct. --NGC 54 (talkcontribs) 14:06, 24 August 2022 (UTC)
Note, I tried to demo that with the label, via a <span style="text-decoration:underline; text-underline-position:under;">(Top)</span> udpate, however the vctor-2022 TOC does not process spans, instead outputting them literally. — xaosflux Talk 14:23, 24 August 2022 (UTC)

Hide/ShowEdit

(split from prior section — xaosflux Talk 13:10, 19 August 2022 (UTC))

Better. Can Contents [hide] be altered as well? In this case, the opposite of "hide" seems to be "move to sidebar" which is just a bit evil — GhostInTheMachine talk to me 16:25, 7 August 2022 (UTC)

@GhostInTheMachine I'm not sure if that one is as confusing? To answer your question, it can be localized at MediaWiki:Vector-toc-toggle-position-title. Clicking on "hide" does result in the TOC being completing removed from view (hidden), I don't think (collapse in to the page menu) or something like that would be better? — xaosflux Talk 15:34, 15 August 2022 (UTC)
If two buttons act as the inverse to each other, then their names should reflect that inverse nature. The oppose of "Hide" is "Show". If clicking "Hide" does hide something, then the inverse should be clicking "Show" to show something. If clicking "Hide" moves something elsewhere, then it should instead be named "Move to ABC" and the inverse should be "Move to XYZ" or maybe "Move out of ABC". I don't think that the current TOC hide / slide across action is at all pleasant, and the confusion of labels is just a symptom of the confusion of function — GhostInTheMachine talk to me 17:59, 18 August 2022 (UTC)
@Xaosflux: Better still, a "Hide" button should be the "Show" button — it should toggle like a light switch, without moving. Just the label changes. In practice, this could be implemented so that the TOC "rolls up" while leaving the toggle button in exactly the same place, and then a second click "unrolls" the TOC back to where it was before. We already use that form of toggle button to "Collapse" and "Expand" navboxes and tables, so it would be kinder to the users to stay with the same mechanism for interface components. — GhostInTheMachine talk to me 18:25, 18 August 2022 (UTC)

@GhostInTheMachine: functionally, the UX on this is not just a boolean condition:

The the transition options are:

  • STATE 1 to STATE 2 (This is a MOVE and HIDE effect)
  • STATE 2 to STATE 3 (This is an UNHIDE effect)
  • STATE 3 to STATE 2 (This is a HIDE effect)
  • STATE 2 to STATE 1 (This is a MOVE effect)

So I'm not really sure what the best label is, just calling out that it is not just an ON/OFF effect. — xaosflux Talk 13:10, 19 August 2022 (UTC)

Just wanted to note that we're reading along and keeping track of the new ideas on verbiage for both this as well as the "top/beginning/introduction" link. In terms of the decision on the current copy, I can confirm that @Xaosflux correctly identified the reason for why the call to action is not a binary hide/show. Potentially another approach would be to clarify the "hide" action further since the ToC is hidden but still accessible via the button - something like "collapse into title" or similar. OVasileva (WMF) (talk) 12:55, 22 August 2022 (UTC)

Mockups for first TOC linkEdit

Hey, regarding the first link in the TOC: I'm going to try and summarize the ideas in this conversation (and other conversations about this topic that have happened elsewhere), articulate the design goals, and provide mockups to (hopefully) help us evaluate our options.

Ideas
  • Ideas for labels:
    • Top
    • Beginning
    • Introduction
    • Article title
    • (remove label and instead make "Contents" itself a link)
  • Ideas for styling:
    • Add ↑ before label
    • Add ( ) around label
    • Add border underneath label
Design goals
  • (Primary) Provide people with an easy way to get back to the top of the page
  • Find a solution that works across various namespaces
  • Ensure that the link doesn't conflict with other links within the TOC (e.g. having two links labeled "Introduction")
Mockups
  • the mockups assume that this change, which bolds the active section link in the TOC, has been deployed.
  • because I think it's helpful to see how this link looks when you are both at the top of the page, and scrolled down (so that this link is no longer selected), an interactive prototype seemed more appropriate than static mockups.
  • link to prototype: https://di-toc-first-link.web.app/Education
  • use the options panel in the bottom-right to explore the various options
  • be sure to view several different articles (for example articles where the second TOC link have an expand/collapse arrow, seem to change the feel of things, especially the option where there's an arrow before the first TOC link — e.g. https://di-toc-first-link.web.app/Moss)
  • since people might have other ideas for the text of the first TOC link there is an input box that allows you to customize it
What do people think?
Some of my thoughts so far:
  • Using "Contents" as the back to top link doesn't seem as discoverable or intuitive to me as the other options
  • Adding an arrow next to the first TOC link makes the TOC feel more cluttered, and I'm not sure it makes a significant difference in terms of discoverability
  • Adding a border below the first TOC link makes the TOC feel more cluttered, and I'm not sure it's particularly helpful in clarifying things
  • Using the article title as a label results in the article title appearing twice, pretty close together (the main article title, then just below and to the left of it the article title again in the TOC). It also doesn't seem quite right when scrolled down on the page that the first link in the TOC is the article title and that clicking it will take you back to the top, though I can't quite figure out why.
  • Using "Introduction" as a label (at least in the main namespace) seems clear to me, and I don't think requires any additional styling
  • Using "Top" as a label seems clear, and seems like it works well across various namespaces, though I think it requires some kind of additional styling to help people make sense of it because it doesn't really fit in with the other TOC links.
    • Adding parenthesis around it feels like a simple and effective way of differentiating it from the other TOC links (which map directly to section names)
I think my favorite option so far is using "Introduction" with no additional styling (with the assumption that we would make it customizable by namespace), or using "(Top)". AHollender (WMF) (talk) 21:32, 2 September 2022 (UTC)

Daß Wölf's commentsEdit

  • Changing skins is unworkable for non-logged-in users since ?useskin= switches are reset every time you click on a link. They should be made more permanent, through cookies for instance. You can see this for yourself by logging out and visiting a Wikipedia that uses the new interface, e.g. the French Wikipedia. The option to return to the old skin also isn't shown to unregistered and logged-out users, who are the ones who need it the most (since they're much less likely to know about our query string tricks). IMO it would be best to follow Reddit's practice (see [2][3][4]) and let users switch between skins in an easy an obvious way with something like https://en.new.wikipedia.org and https://en.old.wikipedia.org. Daß Wölf 15:56, 7 August 2022 (UTC)
    I wish this idea would garner some interest. We're one of the most viewed sites on the internet and obviously we'd be alienating many readers, just as we'd be accommodating many. This small step for a $150 million organisation would easily avoid moving an (in absolute numbers) large amount of our readers to Wikipedia mirrors. We're really focused on trying to create the perfect skin, when any single design will always drive away somebody. We have to be more flexible here. Daß Wölf 05:06, 12 August 2022 (UTC)
    @Daß Wölf, what is your claim based on? My understanding of the research around site appearance changes (which is mostly not Wikipedia-specific) is that most frequent users dislike noticeable changes, some complain, and a few weeks later, even the people who complained about it usually can't tell you how the old site differs from the new one.
    I also understand that the last time the English Wikipedia's default skin was changed, it had no significant effect on page view traffic to the desktop site. If you have found any good research showing that changing the site appearance alone (and not, e.g., removing tools people needed – an incompatible gadget delayed my own transition from MonoBook to Vector 2010 by months) drives away an appreciable number of readers, then I'd be very interested in reading it.
    P.S. You might be interested in https://nostalgia.wikipedia.org/wiki/HomePage This is the real "en.old.wikipedia". Whatamidoing (WMF) (talk) 04:44, 13 August 2022 (UTC)
    @Whatamidoing (WMF): If that's true, then why is https://old.reddit.com still so popular (~1/6 of desktop views 3 years since the switch)? [5] Daß Wölf 20:29, 13 August 2022 (UTC)
    The fact that some people use an old version doesn't prove that they would leave the site if the old version stopped working. Many admins and other high-volume editors here use non-default skins. Common reasons for this include liking what I'm used to and because it makes it really obvious if I've accidentally gotten logged out. But: "I prefer _____ and will go to some extra trouble to use it" doesn't actually mean that "I'll quit unless I can use _____". Whatamidoing (WMF) (talk) 19:42, 15 August 2022 (UTC)
    Does that make it fine if the ordinary reader's experience gets worse and worse, just as long as they don't leave? Daß Wölf 18:22, 16 August 2022 (UTC)
    That’s a really big if. Doug Weller talk 19:46, 16 August 2022 (UTC)
    @Doug Weller and Whatamidoing (WMF): Please excuse my POINTy wording. I'll try to rephrase my argument in a more neutral manner:
    Clearly, a significant minority of people, for different reasons, prefer website skins using older design language. Many people are simply afraid of the new, others simply like a more verbose design language, still others (maybe relatively few) actually make better use of that language. For example, I use a workaround that removes the interactive date picker in page history, because the old date picker loads instantly and takes fewer clicks to get things done. I won't quit if this workaround is removed, and I will come to terms with it, and maybe even completely forget that the old style ever worked faster, but nevertheless that would be another several seconds lost time and time again -- that would not an improvement. But maybe these cases are relatively few in number.
    Now, Reddit is a commercial website that can impede and/or sue mirrors as they see fit. Despite this, they see it worth their money to maintain their old design. OTOH, we're a GPL/CC-licenced website running on FOSS technology. If I remember correctly, one of the reasons cited for this redesign on mw: was that we are losing traffic to commercial mirrors like WikiMili and there's nothing we can legally do other than compete with them. Yet if we now cease offering a full-width option publicly, somebody else will start, etc. Likely we'll be losing fewer readers this way, but why not try and keep them all? Daß Wölf 19:42, 17 August 2022 (UTC)
    I was reading Wikipedia when the main page looked like that. I miss it. But then, I still use a frankensteinian emulation of the Standard skin without side column, shoehorned into the now-also-obsolescent-and-soon-to-be-discarded Cologne Blue, so what do users like me matter. Some day, they'll come for your Monobook, too. —Cryptic 00:08, 14 August 2022 (UTC)
    I suspect that Cologne Blue and Modern will not be de-installed until they actually break. It's not much work to remove them, but it's no work at all to leave them alone (in the absence of security problems, etc.), so I suspect that the removal, if it is ever planned in the first place, will be postponed repeatedly. Whatamidoing (WMF) (talk) 18:38, 18 August 2022 (UTC)
    I don't remember hearing any overall reasons for updating the skin this round. I'm aware that there are always some editors asking for a more modern appearance, and I have heard reasons for some of the individual changes, but I don't know happen to know what motivated the overall project. To give an example of an individual change relevant to your comments, there is external/non-Wikipedia-focused research showing that most people have trouble reading very long lines of small text. If you have an extremely large screen, it is not helpful to have 14 pt text run across the full width of that screen. It's hard to keep your eyes on the same line when you have to physically move your head (or your whole body) so you can see the words at the far end of the screen. These people are not helped by a full-width skin.
    The idea that people might struggle to chase a single line of small text across a meter-wide screen makes intuitive sense, but to get further than speculations about whether the normal width of a piece of standard paper has something to do with the width that people are comfortable reading, then you have to look into the research. If memory serves, the research indicates that – for the average reader – the "best" screen width in terms of Reading comprehension (which would be a very natural goal for an educational website like this one, right?) is about 15 words wide. I personally prefer something closer to 25 words, and I get annoyed when the size is reduced to 10 words (typical for The New York Times website, and supposedly faster for skimming), but something around 15 words is supposedly better for the average person.
    As for whether the movement should try to be all things to all people: I'm not aware of any websites except Reddit doing this, and I don't expect Reddit to do this forever. If almost no website thinks this is a good idea, then why would it be a good idea for us? Whatamidoing (WMF) (talk) 18:35, 18 August 2022 (UTC)
    @Daß Wölf I agree. i don't understand why the UI and the content aren't, or at least modifiable.
    Actually, how difficult is it for a volunteer developer to contribute?~~~ Wakelamp d[@-@]b (talk) 05:24, 16 September 2022 (UTC)
    @Wakelamp, you might start looking around at https://developer.wikimedia.org There are even ways for people to contribute if they don't already know how to code. Whatamidoing (WMF) (talk) 17:07, 19 September 2022 (UTC)
    ooooh I used to program (Fortran 77 ! ), but possibly that may be outdated (hollereith cards I miss you not at all) I work as a Business/process Analyst now - and volunteer BAs are never a good idea . Are there many volunteer developers? Wakelamp d[@-@]b (talk) 13:25, 20 September 2022 (UTC)
    I don't know that we can assume that the average Redditor – a nerdy, tech-savvy 13–35-year-old man – is representative of the average Wikipedia reader. Graham (talk) 05:44, 1 September 2022 (UTC)
  • Regarding the skin itself, I see nothing has been done to make the skin look better on wide screens. How about letting the user set the page width (ideally in a noJS-accessible way) and/or a picture-in-picture sort of preview in the right !ad-banner space for WP:NAVPOPS? Daß Wölf 15:56, 7 August 2022 (UTC)
    @Daß Wölf while it only applies to logged-in users, we have an experimental gadget to widen the view you could try. — xaosflux Talk 16:11, 7 August 2022 (UTC)
    There any several (many?) user scripts to fix the width issue. It really would be better if full width was just a standard Skin preferenceGhostInTheMachine talk to me 16:19, 7 August 2022 (UTC)
    I agree completely, but it would be even better to have this setting somewhere on the page, perhaps more prominently than the way the "Desktop view"/"Mobile view" link is buried right now. User scripts and Special:Preferences are well and good, but they do nothing for the vast majority of Wikipedia's users, who do not edit nor have accounts. Daß Wölf 05:00, 12 August 2022 (UTC)

Update on Vector 2022Edit

What changes will be made before deploymentEdit

Hey everyone! Thank you for your continued feedback. Wanted to send out an update on the project and next steps, and get your thoughts:

In our last message, we posted a list of tasks that we had placed in three categories based on our research, previous conversations with communities and prototype testing, as well as incoming feedback. Below is an update for the tasks within each category. For this updated version, we would like to ask the same questions - What should be added? What should be removed? Do you have any questions on what each of these items will and will not include?

  1. Issues from this conversation that we would like to address prior to the deployment
    1. Table of Contents collapsing and narrow screens behavior - The ToC is now collapsible at narrow screen sizes as well as for all screen sizes. During the next week we will be making changes to the width and centering of content with collapsed ToC's (T314579). We will also be adding the ability to access a collapsed ToC from the sticky header (T311103).
    2. Visual refinements - We're working on this part now. We have made the first changes based on the feedback we have received. The styles for menus and buttons are now back to their default blue state. We have also made some changes to the styles of the ToC. To see more details on the remainder of visual refinements please see the page on MediaWiki.org.
    3. Making a decision on ToC handling and magic words - We will be updating on the state of magic words early next week.
    4. Revisiting the naming of the ToC “beginning” section - @Sdkb, Xaosflux, and GhostInTheMachine: thank you for your continued participation in this conversation and your ideas here. We're monitoring the conversation and are evaluating the idea of the new “(Top)” link as well as other previous suggestions from the conversation on the project talk page. This work will be tracked in this phabricator ticket. We commit to finalizing the name of this section prior to deployment.
    5. Coordinates display and other indicator issues - We are continuing the conversation around coordinates in WP:VPT#Coordinates in Vector 2022 and will post a specific update soon.
  2. Issues we would like to address after the deployment
    1. ToC/sidebar length and the separation of page tools from wiki-wide tools - This is a significant change that we would like to move forward with once we have everyone using the new default. This will be the best way to optimize for studying and building out customizations for the various use cases for the page menu (example: the ability to add admin tools or gadgets like Twinkle to the menu).
  3. Issues that are not part of the Desktop Improvements project, issues that belong to other teams, and other requests that will not be prioritized at this time
    1. Introducing a setting in preferences which allows the fixed width of the article to be turned off - as some of you mentioned, there are a number of gadgets and scripts that allow for increasing the width or using the space for other tools for people that have larger screens. We have published a list of these on our repository page. Feel free to add any scripts/gadgets that you have created or use the ones available there.

Why are these changes improvements: Update on ToC A/B test resultsEdit

We have received the results of our ToC A/B test.

  • We see that among the sessions with at least 1 click on ToC, the treatment group (the group that is exposed to the new ToC) has more clicks on ToC than the control group (the group exposed to the old ToC). Our data model predicts 53% more clicks on new ToC with logged-in users and 45.5% more clicks on new ToC with anonymous users.
  • We saw that this trend is consistent across all edit count buckets: i.e. we saw that logged-in users clicked on the ToC at roughly the same frequency regardless of how many edits they had previously made.

Update on survey resultsEdit

@Sdkb, KevinL, and BilledMammal: thank you for your suggestion on the survey results! We will proceed as suggested. We plan on running the surveys for readers on a limited set of pages starting this week and publishing the data here for review immediately afterwards for review and discussion (within 2 weeks) prior to the RfC. @kevinL - we will also include the data within the RfC itself for anyone that might be interested but is not following along just yet. Let us know if this doesn't make sense.

Wikimania session infoEdit

We will be hosting an introductory session to the project at Wikimania on Saturday, August 13, at 8:05 UTC in tent 2 (join on Pheedloop; see the details). We welcome anyone to join the session. We also welcome anyone with questions or comments to the Q&A afterwards (join on Zoom, dial by your location).

And that's all for now - thank you all again, as usual, for your continued interest, feedback, and help! OVasileva (WMF), SGrabarczuk (WMF) (talk) 15:32, 9 August 2022 (UTC)

It would be great to get a quick fix for T311277, short descriptions being cut off in Vector 2022 instead of being displayed on two lines. There is available space, so there does not seem to be a reason for the truncation of this useful information. The bug was generated by this discussion. – Jonesey95 (talk) 11:38, 29 August 2022 (UTC)

Reinstate link to our sister projects on the sidebarEdit

@OVasileva (WMF) and SGrabarczuk (WMF): Please revisit the decision to hide by default the links to sister projects to non-logged users (phab:T287609).

This decision directly contravene our Strategic Direction ("we will become a platform that serves open knowledge to the world across interfaces and communities"), the Improve User Experience recommendation of Movement Strategy ("tools to connect cross-project and cross-language functionalities to provide an enhanced experience of the knowledge contained in the Wikimedia ecosystem for a particular interest, informational need, or inquiry"), and the long-established convention of cross-wiki co-operation among Wikimedia projects of different languages.

As I've pointed out in the MW talkpage, "no one's clicking this so we should remove it" is not a very good argument, and the data presented to back it up is not very convincing. As Theklan pointed out: you're going against a pretty clear Strategy recommendation; if you think that this doesn't go against it, please show how this is helping it. dwadieff 04:44, 13 August 2022 (UTC)

Thanks dwadieff for bringing this here. Let's see if we have some luck and the problem is solved. Theklan (talk) 09:53, 13 August 2022 (UTC)

Skin is deployedEdit

A/B testing is now in progress for logged-out users. CactiStaccingCrane (talk) 11:24, 19 August 2022 (UTC)

@CactiStaccingCrane - thank you for pointing this out. Just to clarify, we are not A/B testing or deploying the skin at this stage. We have switched a small group of pages (<10 pages) to the new skin in order to qualitatively survey readers for their opinions on the new experience, as discussed in our message above. We hope to get about 500 - 1000 replies to the survey, the results of which we will publish here prior to continuing the deployment conversations. Our goal here is to include the opinions of readers into the conversation around the deployment of the skin and potential improvements. Please see Wikipedia:Village_pump_(proposals)#Update_on_survey_results above for more details. OVasileva (WMF) (talk) 12:47, 22 August 2022 (UTC)
Oh, sorry, thanks for the clarification OVasileva (WMF)! CactiStaccingCrane (talk) 12:52, 22 August 2022 (UTC)
Hi, is there a list of those pages as I'd like to test them too (as a logged out user). CX Zoom[he/him] (let's talk • {CX}) 10:28, 24 August 2022 (UTC)
@CX Zoom - sure! The list is available in phab:T314286. OVasileva (WMF) (talk) 11:47, 24 August 2022 (UTC)
Thank you very much! CX Zoom[he/him] (let's talk • {CX}) 12:32, 24 August 2022 (UTC)
I find it ironic that the banner uses more screen width than the article content. I really hope that the WMF will come around on making it as easy as possible, even for logged-out readers, to use the whole window to view the content that volunteers have created. – Jonesey95 (talk) 13:07, 25 August 2022 (UTC)
Hey @Jonesey95. I appreciate your previous comments and I think I understand the irony :> But for the sake of anyone reading this who hasn't read our documentation yet, just wanted to give the context again on why the banners are appearing at full width.
  • The limited width is intended for long-form text. For more information on that, check out the Goals and Motivations section on our project page or the relevant section within the FAQ or the Wikipedia article on line length.
  • Through the development process, we have made decisions on displaying content meant to be scanned or read quickly at full width. You can see an example of this within banners, as well as on pages that are table-based, such as diffs, History, or Recent Changes.
SGrabarczuk (WMF) (talk) 16:00, 25 August 2022 (UTC)

Update of August 24Edit

Hey everyone, thank you all for your continued feedback. We wanted to give a quick update on the status from our side and what to expect over the next couple of weeks. Please give us your thoughts, questions, and concerns on any of this:

  1. Table of Contents collapsing and narrow screens behavior - This work is now completed. The table of contents is collapsible, and can be accessed from both the title of the page as well as from the sticky header. Please let us know if you have any concerns around the implementation here or additional requests around the ToC.
  2. Surveys with readers - We are currently running surveys for logged-out users here on English Wikipedia. We hope to wrap up the surveys and have the results ready for you prior to beginning the RfC.
  3. Visual refinements - We are currently wrapping up the core parts of our visual refinements work. Please see the Qualitative Testing section on our page dedicated to this part of the project for a full list of the changes we plan on making. We appreciate your feedback on any and all of these.
  4. Coordinates - We are continuing to explore different solutions for coordinate alignment, including potentially adding coordinates directly into the styles of the skin in the future. Do you have any thoughts on this idea? Any immediate concerns? Let us know within the Phabricator ticket.
  5. New blog post published - We have published a new blog post on equitable product development within the Desktop Improvements project. We encourage you to check it out, especially for those of you that are interested in reading a little deeper about the motivations for our changes, and the ways we have tried to change our process and approach in order to build equitably for diverse and global audiences and communities.
  6. RfC Preparation - Finally (and most importantly), this week, we are focusing on preparing for the deployment RfC on enwiki. We hope to have a specific update on the process here soon, but would appreciate any ideas and feedback that have not yet been discussed. We might come back throughout the week with some questions for you all as well as we build out our plan.

Thank you all, again, for your thoughts and help throughout this process! OVasileva (WMF), SGrabarczuk (WMF) (talk) 10:11, 24 August 2022 (UTC)

Thank you for the update! Sounds like sensible progress in all areas. Will the RfC be in this forum? If so, I recommend creating a new section and linking back to this one as needed to keep things clean. —Ganesha811 (talk) 18:56, 24 August 2022 (UTC)
I'm using the new skin as is except that I have the wide-vector-2022 gadget enabled to remove the added whitespace on my laptop. For the reader I think having the whitespace is probably a nicer thing, but it makes doing admin tasks harder. For example, currently viewing diffs has the extra whitespace content which means there is less width and to therefore still fit things more height which increases scrolling. Ideally it would be good to make an option that's opt in to remove the added whitespace. Dreamy Jazz talk to me | my contributions 12:55, 26 August 2022 (UTC)
For anyone that wants to preview widemode, try this link. I think the main "known issue" right now is: if you dock the TOC to the title and collapse the sidebar, the pop-up TOC pops up a bit to the right. (If you have a pure-css fix for this, let us know at MediaWiki talk:Vector-2022.css. — xaosflux Talk 13:43, 26 August 2022 (UTC)
Thanks for the update. Reading the blog post, I have to say that it's quite disappointing. Wikipedia's present design absolutely has lacunae about the needs of a global audience, and I'm glad that the WMF is pursuing equity in the new design. But it's also clear that the efforts to avoid, as the post put it, "a scattered strategy" have failed, and that the idea that the foundation is pursuing equity has led it to unduly dismiss the community's concerns about the language switcher as just reactionary pushback. We've read the Hureo report and raised serious issues about its methodology and conclusions, but as we were not consulted before the decision to move the switcher was made, there was never any real opportunity to influence the WMF's course. And that's a mistake — we've also offered feedback about ways to make language switching genuinely more useful for multilingual users (e.g. take into account article length/quality, since a Google translated article in a topic's primary language is better than the WP article in your local language 9 times out of 10), but it seems that either came too late or was just ignored. Fundamentally, information dissemination is a lot more complex than the commercial products consultants like Hureo are used to working on, and not meaningfully collaborating with the folks in the editor community who actually have relevant expertise has harmed the result. {{u|Sdkb}}talk 05:32, 28 August 2022 (UTC)

Office Hours August 30Edit

Hi everyone! We would like to invite you all to our office hours later today. 12:00 UTC and 19:00 UTC on Zoom. Click here to join. Meeting ID: 5304280674. Dial by your location.

We would like to discuss our preparation for the upcoming RfC, discuss and answer any questions on the tasks we are currently wrapping up, as well as any other blockers to deployment. Thank you and we hope to see some of you there! OVasileva (WMF) (talk) 08:36, 30 August 2022 (UTC)

UX Feedback, revisited (Sj)Edit

Offer preferences. The lack of meaningful user prefs -- dark mode, wide-screen option, cookie-based skin prefs -- speaks to a deep challenge facing this design framework. Similarly, feature requests that originate from a community request or ticket seem to get much less traction than internal design ideas. This seems to lie at the heart of a range of common concerns.

  • There should be a wide-screen preference. It's the most mentioned concern for a reason; the current whitespace / grayspace handling is the least strong aspect of the current design, so it's a matter of more than just "how wide is my column?". The current widemode css seems to work well, it should be offered as an easy to find pref.
  • There should be basic skin-mod preferences that readers can toggle without logging in. There are many reasons a frequent reader might not want to log in; skinning is one of the simplest ways to feel a kinship to a site. cf @Daß Wölf:
  • Add a dark-mode preference, please. By far the most-requested skin update for years.
  • Make switching in/out as easy as possible for all parties. Lower the barrier to exploration and feedback after release.
    On fr:wp it is not very easy at all. Have a persistent link that you click to toggle the pref w/o leaving the current page.

Improve language switching

  • The language switcher is more visible (nice) but slower, more confusing, and has specific unaddressed problems around what languages it highlights. Work w/ some of the people sharing detailed concerns + help get most switches down to 1-2 clicks. Something that explicitly elevates featured work on other projects would have a particularly wiki spirit.

Sidebar/TOC/top need work on margins/padding

  • At all resolutions margins and padding are too big. At low resolution, the sidebar takes over everything -- looks like just a bug.
  • The top now has significant extra padding above the article. (the margin + padding of the persistent header, in contrast, is elegant.)

Be kind to mobile users

  • The new vector should not be significantly worse than current vector when viewed on mobile. In particular, it should not ever default to a massive sidebar taking up the entire screen when landing on a page.
    DJ wrote above: "This is indeed what you see if you force the mobile website to the desktop website/skin (not something anyone but a few realistically is doing)" but I and a number of others commenting here do use desktop-skin on mobile b/c the mobile skin is significantly harder to use for many types of pages, or hides elements of the page that are needed for intent reading/editing.

Honor whitespace management (more :)

  • I know it's currently on the list of design features, but it deserves more focused attention, perhaps a dedicated proofreader for whitespace of all kinds. This accounts for the top three bugs I see in the current interface; which would make me hesitant to share it with others.
    Unappealing mix of white and grayspace at larger resolution; falls off the map on the sides; feels like the skin design is incomplete
    TOC / sidebar padding and margins both too wide
    Top now has 3 extra linespaces above the article
    Sidebar pops out to full rather than something more appropriate

Cheers, – SJ + 16:19, 1 September 2022 (UTC)

Strongly support the widescreen preference. The gutters are absolutely massive on 3860 resolution with 2x magnification - about 500px x 2 goes to vector-sidebar, margin, padding, etc, with the middle div mw-parser-output at like 950px, versus about 150px total for monobook's sidebar, leaving the main div about twice as large. The sidebar TOC is nice, but there's a huge gutter on the right. On a page like the Main Page or any page without a TOC, it looks really narrow and squished in the middle, making it basically unusable for my purposes. However, I just switched to Vector 2022 and it does appear to be in dark mode. I had the dark mode turned on in gadgets for Monobook and it seems to still work. Andre🚐 16:40, 1 September 2022 (UTC)
Also: make explicit use of the gutters: indicate what else they might be for. Annotation has been a perennial feature request for almost 20 years, and the primary challenge was figuring out where it might go without overwriting the page. If we have a path to solving annotation, that would be worth more than all of the difficulties w/ narrower text. – SJ + 21:20, 3 September 2022 (UTC)

Latest?Edit

  • Folks pardon the barging in. I got the new Vector 2022 desktop rollout earlier today. Has this now been rolled-out to all users? Can we still provide some feedback or is it too late? What is the best way for me to provide feedback at this time? Is there an upcoming office hours session? Thanks. Ktin (talk) 00:02, 10 September 2022 (UTC)
    I am adding a few of my observations here. If there is a different place, please feel free to move them.
    1. Full-screen width / wide-screen. This needs to be resolved as P0. There are a few issues here. If we do not want to go "full-screen" wide, but, want to leave a layer of gray on either side, that is fine, but the problem is further compounded because the text selection within the white area is again not 100% so that leaves a suboptimal screen utilization. Furthermore when you jump pages, depending on the presence or absence of the navigation bar the text jumps around and that is a bad visual experience.
    2. The top row (with the static WP icon) scrolls out of the screen when you move down the page and is replaced by a different row / header that does not allow for you to access the links present in the static banner row. e.g. WP homelogo, watchlist etc.
    3. The table of contents is on the LHS which is a new experience, but, perfectly alright from a design consideration. However, it has a scrollbar that shows up when the table of contents exceeds a particular length. That scrollbar is visually a disjointed experience. You can consider removing the scrollbar.
    4. <xx Languages>> Dropdown. E.g. on this page you see 47 Languages. That is the most prominent link on any given page now. Clicking on that link takes you down a rabbit hole of broken experiences. Not the least because clicking on any of the language links takes you to a different language wiki with a different look and feel from this new skin. On the classic skin, if we had enabled this jump wiki functionality, at least the skins would have been consistent. On the most prominent link on the page, this is a suboptimal experience. Curious if our analytics info indicated that folks were trying to look up the same page on different language wikis that we created this as the most prominent link. I think this is an interesting feature, but, not worth making it the most prominent link.
    Overall - I think the experience is still clunky and it would be worthwhile smoothening things out before rolling it to a wider audience.
    PS: I know a new UI/UX rollout is not easy and often has resistance, but, in this case, I think some more work needs to be done before this is ready for primetime. Ktin (talk) 03:16, 10 September 2022 (UTC)
    Hey @Ktin - thanks for your feedback on the new skin! Just to confirm, the skin is not currently rolled out by default to logged-in or logged-out users. However, we are running some banners that invite users with accounts to check out the new skin and give us feedback - so thank you for doing so :) Some initial thoughts on your feedback:
    - On the layout for wider screens. There is now limited width for the content. You can read more about the reasons for doing this in the FAQ. Generally, the limited width makes it easier to read content and to remember it after reading. That said, we encourage folks who prefer a more dense layout to customize the skin. There is currently a list of existing gadgets and customizations available.
    - Table of contents scrollbar. The scrollbar is controlled by the operating system itself and required for users that are using a keyboard and mouse. That said, we're planning on improving its styling a bit for a smoother experience. More details are available in this ticket.
    - Languages. Many of our readers and editors are multilingual and use English Wikipedia alongside their native languages. Our research showed that a lot of people were not aware that they could switch languages directly from the site and were using complicated workarounds like typing the url directly or searching for the page using a search engine. Increasing the visibility of this link makes it easier for them to switch directly from the page. That said, I agree with you that the current experience is a bit jarring due to the difference in the default experience across different wikis. We're currently working with the remainder of our communities to switch all projects to the Vector 2022 skin, which should resolve this. OVasileva (WMF) (talk) 13:10, 13 September 2022 (UTC)

Update on sentiment survey resultsEdit

Hey everyone! Thank you for your continues feedback in preparation for the RfC.

As planned, we ran a survey for logged-out users about the Vector (2022) skin with the goal of gathering feedback for the new skin. Though there are some things we think we learned from the survey, we also ran into a number of issues with experimental design and technical constraints, meaning that the results of the survey did not give us a clear picture of overall sentiment and usability as we had hoped. That said, we believe the data we gathered can still give us some valuable information on the very first impressions of logged-out users of English Wikipedia when presented with the skin on a single pageview.

Overall, a close majority of logged-out users reported that they would view the changes either positively or neutrally. This was true for questions related to both the usability and welcomeness of the new experience. Among these, most respondents indicated that they perceive the old and the new skin equally.

However, we also received a large number of responses indicating preference for the current skin. After analyzing the reasons people gave for their preference, we identified that most of these responses mentioned familiarity with the current interface, or an aversion to change as the major factor in their response. Our next steps based on these results will be to look into ways we can prepare logged-out users for change more smoothly. This might include giving additional information ahead of deployment in the form of banners and other types of context on the upcoming change.

This information allows us to anticipate first-impressions that the general public might have immediately upon launch. This isn’t data on people’s thoughts and feelings after using the new skin, it is rather a measure of people’s feelings towards the initial change in look and feel within the first few minutes of making the change. Studying large design changes on other websites and related research, a significant amount of negative initial responses to changes is expected. The survey’s results are in line with this. Perhaps we can use these results to help us maintain realistic expectations of sentiment immediately after release.

In the future, we would like to revisit the experimental design itself in ways that would allow us to study the way people feel and use the skin once they begin using it across a session, rather than in a more static form. This will allow us to have data on people’s sentiment towards using the skin, as well as allow us to predict long-term opinions after deployment.

The full results are available here - let us know if you have any thoughts or questions. Thank you! OVasileva (WMF) (talk)

RfC Draft is now ready for reviewEdit

Hi everyone! We are wrapping up the drafting phase of the RfC and would appreciate your feedback and thoughts prior to opening the RfC.  In particular, it would be great to get thoughts on whether the questions and language are clear, if the structure makes sense, if there’s too much or too little information we’re providing, if we’ve missed anything that might be important for the community to consider as part of the RfC, or any other open-ended feedback.

Currently, our plan is to open the RfC next Tuesday, September 20th.  The current version of the draft is available here, and we’ll be making small changes to the language as feedback comes in. Thank you! OVasileva (WMF) (talk) 15:35, 15 September 2022 (UTC)

RfC is now open for commentsEdit

Hi everyone! Thank you to everyone that has been helping us draft the RfC over these past few weeks.  The RfC on whether to adopt the new skin after the completion of the issues discussed in this conversation is now open for comments.  We look forward to continuing the conversation there. OVasileva (WMF) (talk) 15:42, 22 September 2022 (UTC)

Adding a ping to the folks that have been most involved in the discussion so far, as well as those specifically asking about the RfC: @Andrevan, @Barkeep49, @BilledMammal, @CactiStaccingCrane, @CX Zoom, @Daß Wölf,@Donald Albury, @Doug Weller, @Femke, @IAmChaos, @Ganesha811, @Ktin, @Jonesey95, @L235, @Pelagic, @Sdkb, @Sj, @Terasail, @Xaosflux. Thanks! OVasileva (WMF) (talk) 15:48, 22 September 2022 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Review of English Wikimedia fundraising emailsEdit

The Wikimedia Foundation has posted samples of its upcoming English fundraising emails on Meta, for community review. These are the Jimbo emails that will be used in the upcoming English email campaign, scheduled to run from September 6 to November 20. Each features a photo of Jimmy Wales, followed by texts asking past donors to donate again to "keep Wikipedia online", "ad-free", keep Wikipedia "free" (the absence of a subscription fee is mentioned), "protect Wikipedia", etc.

I've copied the texts below, for reference. I propose that we establish a rough consensus as to the appropriateness or otherwise of these emails and communicate that to the WMF. --Andreas JN466 15:31, 11 August 2022 (UTC)

N.B.: I've left off the small/greyed print with the unsubscribe options at the bottom of each email, to save space. To see the complete layout, complete with the pictures and small print, please click the links provided in the headings below. --Andreas JN466 10:21, 18 August 2022 (UTC)
Email content

Email 1Edit

From: jimmy@wikipedia.org donate@wikimedia.org
Subject: You are one of those rare exceptions
Date: August 3, 2022 at 7:58 PM
To: nisrael@wikimedia.org

My name is Jimmy Wales, and I'm the founder of Wikipedia. In the past, you donated to keep Wikipedia online for yourself and millions of people around the world. Each year, fewer than 2% of Wikipedia readers choose to support our work. You have been one of those rare donors, and for this I want to thank you warmly. I'm grateful you agree that we can use the power of the internet for good. We will achieve this not as individuals, but as a collaborative movement of knowledge seekers. Together, we can rebuild trust in the internet, and by extension, in each other.

Will you renew your solidarity with a donation?

This is awkward to admit, but I have to be honest: 98% of our readers don't give; they simply look the other way when we ask for an annual donation. We choose not to charge a subscription fee, but that doesn't mean we don't need support from our readers. We don't send a fundraising email every month. We respectfully ask for just one donation this year so that Wikipedia may continue to move forward and offer knowledge to the world.

If all our past donors gave a small amount today, our fundraiser would be over. Unfortunately, most people will ignore this message. We have no choice but to turn to you: please renew your gift to ensure that Wikipedia remains independent, ad-free, and thriving for years to come.

We're a non-profit. That means we aren't selling the articles that millions of people read on Wikipedia each day. We don't profit from the knowledge you seek. In fact, we firmly believe that knowledge should exist outside of the realm of supply and demand. That's hardly a given nowadays; so much of the world's digital knowledge is driven by profit.

Wikipedia is different in that it doesn't belong to the highest bidder, the advertisers, or corporations. It belongs to you, the readers, editors, and donors. You're our community, our family. You're the reason we exist. The fate of Wikipedia rests in your hands and we wouldn't have it any other way.

It's readers like you who safeguard our non-profit mission. You help us maintain our integrity, quality, and accessibility. Today, please consider giving again, or even increasing your gift, to keep Wikipedia free and independent.

Now is the time we ask: can we count on you to renew your solidarity with a small donation? It will keep Wikipedia online, ad-free, and growing for years to come.

https://donate.wikimedia.org

Thanks,
Jimmy Wales
Founder of Wikipedia


Renew your donation

Where will your donation go?

42% of your gift will be used to sustain and improve Wikipedia and our other online free knowledge projects.

31% of your gift will be used to support the volunteers who share their knowledge with you for free every day.

27% of your gift will give the Wikimedia Foundation the resources it needs to fulfill its mission and advance the cause of free knowledge in the world.

Email 2Edit

From: jimmy@wikipedia.org donate@wikimedia.org
Subject: It's non-negotiable
Date: August 3, 2022 at 8:01 PM
To: nisrael@wikimedia.org


You have been a Wikipedia donor in the past and have donated once. You've unlocked:

Bronze Badge / Silver Badge / Gold Badge / Platinum Badge

When you gave in the past, you were one of those rare donors who kept Wikipedia thriving for yourself and millions of other readers.

Ready to earn your next badge? Please match your last gift today.

I took the liberty of emailing you a second time on behalf of the Wikimedia Foundation (the organization responsible for the protection of Wikipedia), because I wasn’t sure you got a chance to read the first email we sent to nisrael@wikimedia.org, the address we have on file for you since your last gift. I hope this badge will act as a reminder of how crucial your commitment to supporting free knowledge has been and still is to us.

At every turn, we have been pressured to compromise our values, but I'll be honest: This isn’t negotiable for us. People always ask us, why not just run ads to make revenue? Or capture and sell reader data? Or make everyone pay to read? While these things seem like the norm online nowadays, we'd like to remind you that there is another way--a way that doesn’t jeopardize the neutrality of our content and threaten your personal data. We just ... ask! Not often, but it works. After 21 years of saying no, I can still say we are proud to have left that money on the table.

We’re a non-profit. Only 2% of our readers give, but we manage to serve hundreds of millions of people per month. Imagine if everyone gave? We could transform the way knowledge is shared online.

I've been happily stunned by the response from our donors, but we haven't reached our fundraising goal and we don't have a lot of time left. We’re not salespeople. We’re librarians, archivists, and information junkies. We rely on our readers to become our donors, and it’s worked for over 20 years.

This year, please consider making another donation to protect and sustain Wikipedia.

We know people’s circumstances have changed a lot in

the last year. Some find themselves with less to spare, but
a lucky few happen to have a bit more. If you’re one of
the lucky ones, will you give a little extra to keep Wikipedia growing?

Renew your donation

Give 5

Give 20

Give 35

Give another amount

Any gift will unlock your next badge.

Thank you,
Jimmy Wales
Wikipedia Founder

DONATE NOW

Email 3Edit

From: jimmy@wikipedia.org donate@wikimedia.org
Subject: Our final email
Date: August 3, 2022 at 8:01 PM
To: nisrael@wikimedia.org

I know you've heard from me twice already, so I'll get straight to the point. In the past, you were among the extremely rare readers who made a donation to invest in the future of free knowledge. If you've made it far enough to open this email, could you take a minute to help us out?

Many of our readers see our emails and think they'll get round to it later, but life happens and of course they forget. Our annual email fundraiser is coming to an end, so if you've been holding off until “later”, this is your moment.

I'm asking you respectfully: Please, renew your donation; it matters.

Around the time our fundraising campaign starts, I hear from friends, family, and long-lost classmates who see our fundraising messages while they're looking something up on Wikipedia. It's a reminder of how many folks, from all walks of life, rely on Wikipedia.

This incredible public support is crucial for our organization and our movement to thrive. It allows us to serve the world, and to do so with independence and integrity. We don't belong to anyone, because we belong to everyone.

You donated in the past and we sincerely thank you. If you still see value in Wikipedia, please sustain your support in 2022 and keep Wikipedia thriving.

This is our biggest fundraising moment of the year. It's when we launch the online campaign that brings in donors who will propel us throughout 2022 and beyond. I'm one of them. I'm a regular donor.

We are the non-profit that supports one of the world's most visited websites. We don't generate revenue by selling off our users' data to the highest bidder. We don't run ads that could jeopardize the integrity and neutrality of our content.

Though our size requires us to maintain the server space and programming power of a top site, we are sustained by the support of our donors who give an average of about $16. This year, will you take one minute to keep our work going?

5 / 20

25 / Other

Renew your donation

Give less this year

Thank you,
Jimmy Wales
Wikipedia Founder

DiscussionEdit

These emails are almost identical to the ones that were used in the recent Indian fundraising campaign (see June Signpost report, "Wikipedia's independence" or "Wikimedia's pile of dosh"?). As can be seen, the second email once again invites people to unlock "badges" (Bronze, Silver, Gold, Platinum) by making sure they never miss a year of donating.

 
Financial development of the Wikimedia Foundation (in US$), 2003–2021
Black: Net assets (excluding the Wikimedia Endowment, which passed $100m in June 2021)
Green: Revenue (excluding third-party donations to Wikimedia Endowment)
Red: Expenses (including WMF payments to Wikimedia Endowment)

People are told very little in these emails about what it is that drives the Wikimedia Foundation's money needs, what additional work is being carried out that has caused the vast increases in budget and salary costs over the past decade, and what the benefit of this added spending is to volunteers and the public. Nor is there any mention of the Strategic Direction.

Instead, everything is focused on communicating a need for money to keep Wikipedia online/ad-free/free/independent, as though the Foundation were really struggling to keep Wikipedia online without ads – as though it were not richer than ever, with about $400 million (including the Endowment) in assets and reserves.

I think we, as a movement, should do better than these emails, and aspire to more transparency. Moreover, right now, the Internet Archive is arguably much more deserving of donations; unlike the WMF, they have a stable budget, low salary costs, no history of vast budget surpluses, and are currently fighting a lawsuit against publishers – all while supplying an absolutely critical and free service to Wikipedia. --Andreas JN466 15:31, 11 August 2022 (UTC)

  • Objection to the Wikimedia Foundation speaking for the community without consultation The Wikimedia Foundation and the community of editors are not the same. The foundation is paid staff recently hired now that donations come in at a rate of US$200 million / year. The community are the volunteers and activists who produce content for the platform. When donors give money, it is because they love Wikipedia as a community of volunteers even while they have little awareness about the staff of the Wikimedia Foundation at all. More discussion is useful, but as a starting point, the Wikimedia Foundation should 1) be transparent about how it calculates its budgets and 2) only talk about budgets for the Wikimedia community the consent and approval of the Wikimedia community. For this point especially -
  • 31% of your gift will be used to support the volunteers who share their knowledge with you for free every day.
Since 31% of the donations are to support the volunteers, then 31% of the money should be in the control, governance, and oversight of the volunteers. The volunteers do not have good access to the accounting for money, nor is there any public process for including volunteers in the spending decisions for this US$90,000,000 a year. The Wikimedia Foundation makes many budget decisions without the support and consent of the volunteers. There are many possible talking points for how the Wikimedia Foundation has different priorities as compared to the contributor community, but to name one, the volunteer community has much more compassion for underrepresented demographics such as people in lower and middle income countries. If the Wikimedia community made governance decisions about that 31%, then programs to increase diversity would include showing monetary equity in the allocation of global funding. I have anxiety because the values and ethics of the centralized and control-seeking Wikimedia Foundation are diverging from those of the decentralized and power-sharing Wikimedia community. The power belongs to the user community, not to paid staff who operate without community support. Bluerasberry (talk) 16:15, 11 August 2022 (UTC)
Agreed. The 31% line is misleading and definitely needs context. When I hear that my "gift will be used to support the volunteers" they don't sound much like volunteers any more. Retswerb (talk) 23:17, 14 August 2022 (UTC)
@Retswerb: It also makes it sound like volunteer editors receive monetary compensation in some way for their editing – which could definitely be confusing in regards to Wikipedia's policies on paid editors and conflict of interest; "if you're not allowed to be paid to edit, how come 31% of fundraiser money goes to volunteers?", etc.--Ineffablebookkeeper (talk) ({{ping}} me!) 15:39, 26 August 2022 (UTC)
Serious miswording. I am financially struggling and hither to forth considered a volunteer. I need to know when I became a paid editor ("31% of fundraiser money goes to volunteers?") and when I can expect my back pay? Will I receive a 1099? If I can augment my retirement I can contribute more. -- Otr500 (talk) 02:45, 28 August 2022 (UTC)
@Otr500: For just $5000 a day, I'll lift a finger to fix a typo...$6000 a day, I'll even stop adding them in.--Ineffablebookkeeper (talk) ({{ping}} me!) 12:37, 28 August 2022 (UTC)
Less facetiously, I got a Wikipedia shirt as a gift some years ago, and I'm geek enough to wear it in public occasionally. About a half dozen times people have commented to me, "Oh, I donate to them!", and I make it a point to stop and chat with them if we both have time (all but once). Every single one thought that at least part of what they gave went directly to editors, and was genuinely surprised when I told them otherwise. —Cryptic 14:40, 29 August 2022 (UTC)
@Ineffablebookkeeper: Good help is expensive these days. The CEO/Executive Director makes around $1062 for every day of the year, not counting any perks or benefits. For a 5 day week that would be around $1491. a day. If it wasn't located in the Bay area it would be a lucrative job. Staff gets annual cost-of-living increase, annual merit increases, annual vacation of 5-20 days, 11 paid public holiday days per year, 9 sick days, special leave for certain circumstances (bereavement, jury duty, and maternity/paternity.), and my favorite; discounted in-office massage service. The 12th lowest salary from the top was $184,729 a year. -- Otr500 (talk) 03:33, 29 August 2022 (UTC)
If we wish to negotiate with them, saying their salary is high is unwise,
I suggest we should avoid discussions of salary because hiring the cheapest would be awful, it's direction that is our main concerns. and complaining starts to look like sour grapes. Her job is difficult, and I think you migh t be suprised by IT Salaries in the Bay Area
Overall, her pay seems seems probably a bit low., (as long as there is no n=bonus for donation targets) is low considering staff and revenue Wakelamp d[@-@]b (talk) 05:27, 29 August 2022 (UTC)
@Otr500: I believe you are looking at outdated figures. The most recent ones are for 2020: [6]. CEO base compensation was $404,053, and $423,318 total incl. benefits. The 12th-highest salary was $217,193 base, $240,345 total. These figures are from two years ago; current figures are likely to be about 10–25% higher (compare these 2020 figures to the 2018 figures). Let's meet here again in May 2024, which is when we'll have the Form 990 with the 2022 figures.   Andreas JN466 07:00, 29 August 2022 (UTC)
Thanks -- Otr500 (talk) 03:28, 3 September 2022 (UTC)
I have chnaged my mind - attack their salaries, and especially ask if they are receiving money/shares from other sources, and are there bonuses linked to new articles, edits, or new editors
BTW their salaries are based on comparable tech as well as charities Wakelamp d[@-@]b (talk) 00:52, 16 September 2022 (UTC)
I don't think there are any such bonuses; I think what you see in the Form 990 is what it is.
Perceptions of a $350K salary vary widely around the world: in Silicon Valley, it seems quite normal to people, in Europe it causes raised eyebrows (even top managers at Volkswagen earn less, someone said the other day on Hacker News), and in somewhere like India, South Africa or Brazil it's just off the charts.
If you fundraise globally, I think it's always necessary to compare the income of the donors you're addressing to the income of the people who are ultimately being paid the money. In particular, if your audience on average earns something like 1/500 of your managers' pay, I think it would behoove you to phrase your fundraising messages conservatively – you don't want to frighten poor people into donating small amounts of money that they can barely afford (case in point) by telling them Wikipedia is about to blink out of existence if they don't give money today. That is just callous. (By the way, the current Dutch banners actually ask people to give money to "keep Wikipedia alive" or "keep Wikipedia going" – see the discussions on m:Talk:Fundraising. Talk of over-dramatizing ...)
For off-wiki discussions in the past couple of days see Hacker News and this Twitter thread (re-tweets and comments welcome). Andreas JN466 11:08, 16 September 2022 (UTC)
At the start of this thread, I assumed good faith from the WMF... But I can't find any.
I went through one small overseas charity that WMF is linked to. I thought being paid twice for the same work was cool, but 6 times is awesome. (WMF, government, private investment matching, local government, kickback from employer, employee payment, Social impact bond, ...)
So, nearly all the same issues were discussed 6 years ago, and it's got a lot, lot worse since then, and changing one email won't do much
What do we do next? Wakelamp d[@-@]b (talk) 14:15, 16 September 2022 (UTC)
Write to journalists, go on social media, etc., until the WMF is prepared to have a discussion. There were such discussions in the past, so who knows, maybe there will be in the future. Indeed, post-campaign discussions will shortly be held with the Dutch community – but of course post-campaign discussions are less effective than pre-campaign discussions. They assuage everybody, giving people the feeling that they have been listened to, and then next year much the same happens again, with a post-campaign discussion to follow. At any rate, effective discussion and meaningful changes will only happen if enough people complain, on and off wiki, and especially if the matter reaches the media, as it did in 2015. Incidentally, the WMF is five times richer today than it was at the time of that Washington Post article.   See also discussions here. Best, --Andreas JN466 15:00, 16 September 2022 (UTC)
If your aim is to tone down this or the next round of emails, then I think you may get some visible results.
BUT it would be relatively easy to send a different email for anyone with that address on their account, or at the same IP address, of anyone that had ever complained.
Wakelamp d[@-@]b (talk) 03:46, 17 September 2022 (UTC)
With the post campaign discussions, it would be really great to get the Trustees involved, but as we have discussed they are silenced under the Code of Conduct ;-( Wakelamp d[@-@]b (talk) 03:48, 17 September 2022 (UTC)
@Jayen466 I have been looking at discreet corners of the web and it looks like all large non-profits have bonuses and incentives these days. Didn't you do a media article on Golden handshake s??
Have you a recent version of WMF compensation policy? Wakelamp d[@-@]b (talk) 10:25, 18 September 2022 (UTC)
I asked on the mailing list once whether there were bonuses or incentives related to fundraising revenue and received no reply. :/ At any rate, the Form 990 should contain whatever compensation has been paid. It also includes severance pay; as you say, some of these severance payments have been quite considerable.
I am not aware of any more recent version of the WMF compensation policy being online anywhere. Transparency with regard to such matters has steadily reduced over the past decade. Andreas JN466 12:31, 18 September 2022 (UTC)
  • Completely agree with your concern, Jayen466. I don't think these emails as they stand are in keeping with our values. (I also complained over at Meta a few months ago, but I unfortunately failed to follow up due to other commitments.) I share your unhappiness with the obsequious, obfuscating tone and I'd like communications to be more transparent about where donors' money will go. I'm not sure the WMF will listen to these concerns, though. However, what I do find strongly objectionable are manipulative or clearly misleading phrases, of which there are several:
Specific objections (manipulative and/or misleading): "Subject: It's non-negotiable"; "we have no choice but to turn to you... to ensure Wikipedia remains ... ad-free ... for years to come" & "[your donation] will keep Wikipedia ... ad-free" (not true); "this is our biggest fundraising moment of the year" (there'll be another fundraising campaign in a different region); "donors who will propel us throughout 2022" (we already comfortably meet our running costs); "X% of your gift will be used" (not it won't, if my understanding is correct, these are expenditure breakdowns and don't account for money put into the endowment etc., it should say "X% of our spending"); "we haven't reached our fundraising goal" (what if we have reached it, will this still be sent?); Jr8825Talk 19:04, 13 August 2022 (UTC)
@Jr8825: "This is awkward to admit, but I have to be honest: 98% of our readers don't give; they simply look the other way when we ask for an annual donation" is cringe-worthily sheepish language; it comes across as obsequious and critical in the same sentence. It's not "awkward", WMF is actively choosing to send out fundraising emails – there's literally no reason to behave like a shrinking violet when you're a multimillion dollar non-profit choosing to do this, we're not kids asking to go through the McDonald's drive-thru. And "they simply look the other way" alienates people who can't/won't (for whatever reason) donate as cold, or even cruel, like they're taking advantage of us. We don't know people's financial situations; pigeonholing everyone who doesn't donate as turning away from WMF's figurative little match girl on the streets is upsetting.
Wikipedia can't be free for everyone to access and be taken advantage of by the people who don't donate in the same serving, that's wildly contradictory. And not convincing, either – instead of playing the woe-is-me angle, we could be focusing on the genuine good that Wikipedia is enabled to do through WMF fundraising. Guilt isn't a convincing fundraiser tactic, and it leaves a bad taste in the mouth that our unpaid, willing, free and often heartfelt contributions are being dangled over people's heads to shame them into giving money. It's grim, insincere and misleading.--Ineffablebookkeeper (talk) ({{ping}} me!) 15:54, 26 August 2022 (UTC)
Also seems nuts that they need more money, but when it comes to funding very important page review software that hasn't been updated in a decade and whoopsie! We can't expect anything more than critical updates, because why assign a developer to deal with long-standing bugs at what is essentially the Hoover Dam of Wikipedia? If that 31% goes to volunteers, how come we have to beg WMF to give us the tools we need to run this website for them?--Ineffablebookkeeper (talk) ({{ping}} me!) 11:18, 27 August 2022 (UTC)
The NPP software has been updated over the last decade, and (it is more Hoever vacuum than hoover Dam)  :-)
We are the customers from Hell, but they are a social movement charity trying to run a technical business. Neither of us have long term roadmaps. Neither of us want to address the difficult stuff.....yet Wakelamp d[@-@]b (talk) 13:12, 27 August 2022 (UTC)
  • Bronze Badge / Silver Badge / Gold Badge / Platinum Badge This language sounds like what some multi-level marketer might use to get you to buy their product. The WMF are not salespeople, and should not be using "badges" or any other promotional language to get people to make a donation. I suspect User:Jimbo Wales would not approve of this either. 2601:647:5800:1A1F:AC39:F771:78B1:4C47 (talk) 21:29, 13 August 2022 (UTC)
    +1 Jr8825Talk 21:51, 13 August 2022 (UTC)
    I share your feelings about the badges. But let's bear in mind that these are very high-profile emails, sent to hundreds of thousands of people in Jimmy Wales's name. It strikes me as very unlikely that he should be unfamiliar – or indeed unhappy – with their contents. Andreas JN466 19:21, 14 August 2022 (UTC)
  • As an actual volunteer and content contributor, I would say WMF's money would be much better spent on propping up the IA and similar projects than probably anything else that counts under "supporting the volunteers". Money is being wasted on keeping up with the Joneses. Daß Wölf 22:12, 13 August 2022 (UTC)
    Use money more efficiently, rather than asking for more. This is giving cost-plus contract vibes... CactiStaccingCrane (talk) 10:59, 15 August 2022 (UTC)
    Seconded absolutely. Granted, I haven't seen WMF in action many times, but I see a pattern of prioritizing highly visible over damaging problems, lack of serious timeframes, lack of communication and a general "may thy left hand not know etc." air -- sometimes you'd think it was them donating the few weekly hours of their free time to the project, not just us. What does WMF spend the money on? Server costs, MediaWiki development, legal department -- those are the indispensable bits. I'm also willing to believe that there's a lot of back-end community work that produces results that we simply don't perceive here on the wikis (T&S?). Is $120 million needed for this? Why won't $20 million from 10 years ago suffice today? TBF the root problems here are not something that WMF can address by tweaking a fundraising email, but donors should be at least given evidence that they're still getting their money's worth, as opposed to just building some kind of hypothetical war chest, or worse. Daß Wölf 17:59, 15 August 2022 (UTC)
  • These emails will make people believe they are donating to Wikipedia. Unlike the WMF which doesn't need the money, Wikipedia could do with more donations to fund necessary software improvements (for example, to allow full participation on mobile platforms without disabling the "mobile enhancements" of the m. subdomains). Unless far more donations are spent on Wikipedia, I suggest to tell every potential donor to donate to the Internet Archive instead of to the WMF. As an aside, anyone using the threat of ads in this context is clearly a liar and should probably be banned from editing Wikipedia to prevent them from introducing other lies here. —Kusma (talk) 11:38, 15 August 2022 (UTC)
  • I would suggest that this discussion should close at the end of August, a few days before the emails are due to go out. If it gets sufficient participation and a consensus to object, then we should be clear to the WMF that they do not have en.wiki community endorsement to run these emails. Each WMF staff member's attention should then be drawn to this RfC. When the WMF ignore us and send the emails anyway, we should contact the news media, alerting them to this discussion and offering to be interviewed about why we oppose the WMF's current fundraising approach, and what interested readers can actually do if they want to contribute to Wikipedia (i.e. edit). Thanks to Jayen466 for raising this. — Bilorv (talk) 11:42, 16 August 2022 (UTC)
    I think the discussion should continue as the WMF deadline is arbitrary. In regards to contacting the media they are always a two edged sword, and we currently only have only had short term goals. I am 100% that WMF staff know about this exchange. We seem to have three options
    1. Email - Going to the media would get us a few articles in the New York Times etc, but it is attention But not strategic, and might accelerate tech donors to stop funding us
    2. Burn the house down - We could stop all fundraising through doing tricky things on their display ads, or we could run our own ads using templates asking for donations to EFF to defend us, or request Vandals to attack Wikimedia Foundation article. Now that would get Major media attention, but decisions would be made quickly and not strategically. There are some other options, but they are quite extreme,
    3. Negotiation WMF sends a toned down email , and becomes far far more transparent. We , in turn, accept that we are part of the problem. We didn't tell WMF what their purpose was, we are really awful to deal with, we have been delaying needed changes, newer editors are not involved in decision making, and we are dependant on WMF for coordination with other Wikis. Wakelamp d[@-@]b (talk) 23:39, 27 August 2022 (UTC)
    Agreed with option 3 – that seems to be a good idea. Option 1 and 2 is really the nuclear options really, and I really don't want that to happen. CactiStaccingCrane (talk) 01:16, 28 August 2022 (UTC)
 
The picture used in email 3
Thanks for pointing out the inconsistencies in our email image attributions. We have now fixed the attribution to all images across all emails (please note the emails on meta are the old ones with the non fixed attribution). Best, JBrungs (WMF) (talk) 06:46, 22 August 2022 (UTC)

Statements from board candidatesEdit

It is interesting to note that in their campaign materials, three of the six candidates currently running for the WMF board (vote here) support the view that WMF fundraising is deceptive. A fourth (a current board member) criticises aspects of WMF fundraising. Below I am quoting relevant excerpts from –

  • the written responses of these four candidates to Election Compass Statement 5, WMF fundraising is deceptive: it creates a false appearance that the WMF is short of money while it is in fact richer than ever,
  • the candidates' Campaign Videos answering Question 3, "What do you think about the Wikimedia Foundation's current approach to fundraising?"

For a complete picture of candidates' views see the Meta page with the full responses of all six candidates and watch the Campaign Video for the fundraising question. Note that all emphases below are mine.

  1. In the Election Compass, Mike Peel strongly supports the statement that WMF fundraising is deceptive: it creates a false appearance that the WMF is short of money while it is in fact richer than ever, and says in his written statement: "I agree with the statement, and this needs to be fixed. ..." In the Campaign Videos, Mike says, "the banner campaigns are not entirely honest".
  2. In the Election Compass, Kunal Mehta supports the statement that WMF fundraising is deceptive: it creates a false appearance that the WMF is short of money while it is in fact richer than ever, and says in his written statement: "The current fundraising approach is based on the WMF constantly growing. The board and upper management set aggressive growth targets and then the fundraising team needs to resort to more and more extreme measures to reach them, which end up being perceived as deceptive. I would like to see the WMF stop growing and stabilize at its current size." In the Campaign Videos, he similarly says, "The Board and upper management set aggressive growth targets and then the fundraising team needs to resort to more and more aggressive measures to reach them. Some of those measures result in misleading fundraising banners that editors feel don't appropriately reflect the financial reality around the WMF."
  3. In the Election Compass, Michał Buczyński supports the statement that WMF fundraising is deceptive: it creates a false appearance that the WMF is short of money while it is in fact richer than ever, and says in his written statement: "… our fundraising, while efficient, is stressing too much server's maintenance, and should boast with other areas of activity more: from technical work to e.g. fight with misinformation." In the Campaign Videos, he says: "... a concept of systemic internal ethical validation of Wikimedia Foundation fundraising should also be explored".
  4. In the Election Compass, Shani Evenstein Sigalov, a current board member, opposes the statement that WMF fundraising is deceptive: it creates a false appearance that the WMF is short of money while it is in fact richer than ever, but says in her written statement: "I do feel that the online campaign can be improved. See videos for more." In the Campaign Videos, she says, "The one thing that I think we can improve is our on-wiki campaign. It is sometimes too aggressive to my taste." --Andreas JN466 20:11, 23 August 2022 (UTC)
Thanks @Jayen466 for copying our statements here. Candidates are forbidden from campaigning while voting is open, so I can't say anything else on the matter, but I'd like to emphasize and encourage people to vote. Legoktm (talk) 00:27, 24 August 2022 (UTC)
Um - What is the rationale for candidates being forbidden?? Wakelamp d[@-@]b (talk) 21:30, 27 August 2022 (UTC)
@Wakelamp: The Elections Committee takes the view that because candidates may have different amounts of time for campaigning, those with less time to engage with the community might be unfairly disadvantaged if others engage more. So candidates have essentially been limited to answering the official questions. Andreas JN466 09:27, 28 August 2022 (UTC)
I did a quick look, but I can't find a tech o cultural non-profit with similar policies.
I suggest we ask for a stop in the election until that is corrected, becuase.
  1. The electoral process is already of cooncern, but it seems the campaigning process is more so.
  2. The rationale for WMF guideline policydo not make sense as we expect board members to engage with us and contribute large amounts of time working on the board, and
  3. Together with the WMF policy, the [code of conduct], and [Guidelines] mean that there is no time that a trustee CAN interact with us. Of particular concern is that,
  • "Board Members should not undermine a Board decision by stating their opposition to it, refusing to participate in any efforts or activities that follow from it, or attempting to relitigate it in a public forum,
  • Board members should avoid taking a public position on a matter that will (or is likely to) come before the Board."
If the trustees can not represent us becuase of policies we need a council of affiliates, to show true diversity Wakelamp d[@-@]b (talk) 02:50, 29 August 2022 (UTC)
I agree those two "Board Members should ..." passages from the Board's Code of Conduct stink. It's the complete opposite of transparency. Imagine a parliament that tells all its representatives – including the members of all opposition parties – that a prerequisite of their becoming a member is that they must be seen to endorse every decision taken by the parliament's majority. Andreas JN466 07:23, 29 August 2022 (UTC)
I'm curious whether any other boards have similar provisions in their CoCs. Levivich 16:28, 30 August 2022 (UTC)
Not that I could find
National Council of Non Profits Board Responibilties
Sample board code of conduct (direct link to pdf)
Apache
https://www.asha.org/siteassets/uploadedFiles/Legal-Responsibilities.pdf Wakelamp d[@-@]b (talk) 14:36, 31 August 2022 (UTC)
Yeah I couldn't find it either. And this idea that once the board makes a decision, none of the board members should question it, is called democratic centralism, and has had some, um, colorful proponents over the years. Levivich 14:47, 31 August 2022 (UTC)
From a discussion on WMF enteprise Jimbo Wales "For quite some time, the WMF has been managed well, financially, such that we bring in more money every year than we spend so that we can build up our reserves - which we have done. Additionally we have built up the WMF Endowment fund into something quite substantial. There are occasional news stories about this, basically saying "Why is Wikipedia asking for money, they have a ton of money already?" And the impact on donations has not been negative at all - indeed, I think it is arguable (and I know this in a direct way if we consider major donors who I've personally talked to) that having the WMF on sound financial footing, so that we can do more for free knowledge globally, is a stronger and more stable longterm incentive to donors, as opposed to pursuing what I would regard as folly: teetering forever on the edge of bankruptcy in order to panic people into donating money. That would be terrible!" Wakelamp d[@-@]b (talk) 00:10, 1 September 2022 (UTC)

Fundraising messages of various charities comparedEdit

Below is a list of charities in the same spaces as us (cultural/pivacy/free speech/tech). The first link is to the main source of informaton (I also had to do some calcs, conversions, guesses from Profit/Loss, etc), and the second takes you to the donation page for that charity. All the other donation pages are very different from WMFs and the email. Our peers do not try to create negative emotions (guilt, shame, blame, fear of impending doom), have alternating praising/damning building up to a promise of heaven, or down market type text.

Main Source of Data Donate Link Revenue Program % Fund Raising % Admin % Working Capital Ratio
ACLU Donate 200 84.5 10.2 5.2 2.4
Apache Donate 1 0.05 50K 30K 1
Educate Girls Donate 11 74 20 5.9 3.5
EFF Donate 2.2 72.5 12.7 14.6 2.46
Free Software Donate 2.1 88.4 4.8 6.6 0.68
Medicins Sans Frontieres Donate 1735 80 16 5 1.2
Open ID Donate NA NA NA NA NA
Phorge (was Phabricator) Donate NA NA NA NA NA
Project Gutenberg Donate 0.2 100 0 0 1.5
Reporters without borders Donate 1.75 75.17 12.8 75 0.3
Smithsonian Donate 1600 76.3 34 20.2 2.69
The Guardian Donate 223 NA NA NA 6.04
The Internet Archive Donate 37 91.89 3.5 1.7 0.08
The Khan Academy Donate 54 88.7 75 3.6 1.66
Tor Donate 4.4 89.72 7.1 35 0.4
Wikipedia Donate 124 74.5 11.5 13.8 3.2
Wiklleaks Donate NA NA NA NA NA

Wakelamp d[@-@]b (talk) 10:28, 27 August 2022 (UTC)

Thank you for your hard work, Wakelamp; this really puts things in perspective, and the tone of these other examples is massively different.
Some thoughts I had on wording, after coming across this post on communication (and headology) on my Tumblr:
  • Using positives after the word 'but' ("we don't receive funding from advertisers, but thanks to the hard work of our volunteers and the generous donations we receive, we're able to make Wikipedia the Internet's largest free repository of knowledge");
  • Alternatively, replacing 'but' with 'and' when a negative follows a positive ("We don't receive advertising money and we rely on the donations of people like you; and we'd like to keep it that way");
  • Replacing so-called "low energy phrases" (like worst, struggling, dangerous, precarious) with "high energy phrases" (like least ideal, least functional, least secure); this can verge into business speak but it can work well;
  • Not making it sound like Wikipedia is a stone's throw away from the house catching on fire;
  • Giving, as other people have stated, some definite bloody reasons as to why this is our "biggest fundraiser yet";
  • Completely nixing all mention of people who don't donate, for whatever reason:
    • "Each year, fewer than 2% of Wikipedia readers choose to support our work [...] I'm grateful you agree that we can use the power of the internet for good", as if the people who don't donate don't agree with this;
    • "We choose not to charge a subscription fee" sounds like a threat, as if it's a button that could be hit at any moment;
    • "Unfortunately, most people will ignore this message. We have no choice but to turn to you" is some guilt-inducing, cap-in-hand nonsense;
    • "The fate of Wikipedia rests in your hands" is needlessly dramatic;
    • "but I'll be honest: This isn’t negotiable for us" is pressuring language. Further up in email 1 it states that "You're our community, our family." If my family acted this way – made it sound like a choice, but also not a choice – I'm not sure I'd feel too great about lending them some money. Would you?
    • "We just ... ask! Not often, but it works. After 21 years of saying no, I can still say we are proud to have left that money on the table. [...] Only 2% of our readers give, but we manage to serve hundreds of millions of people per month. Imagine if everyone gave? We could transform the way knowledge is shared online" contradicts itself in part; the donations work, and we have money left on the table...but also a lack of donations is what holds us back from doing more, even though we have a comfortable amount on the table?
    • Several mentions of how "extremely rare" it is for someone to donate really don't make things sound good; if you can't donate, for whatever reason, you're part of the common group of people who "turn away" [shame bells start ringing];
    • "Many of our readers see our emails and think they'll get round to it later, but life happens and of course they forget"; a number of reasons are vaguely offered for why people don't donate, but they seem to come from the wrong place. People "turn away" or "ignore" the emails, it's implied because they are stingy or cold; or they "forget", it's implied because they are neglectful and careless. No mention is given that people maybe can't donate. Instead of shaming people, we could simply state that if people can't give anything, that's fine; we could ask them to spread the word instead, and that anything they can do, whether it involves money or not, helps us out.
I think we could do a lot better than WMF holding up a puppet of Jimbo and pretending it's him talking; every single organisation you've linked talks about their actions as they are – a large non-profit corporation.
I don't find the tone of the WMF emails humanising, I think they aim to make WMF seem smaller than it is – more vulnerable, more precarious, when in fact we have been going for a long time and quite comfortably so. We could be listing the good Wikipedia does, the specific goals of WMF, what we've already achieved (more than 'we have an encyclopedia woohoo') and the benefits of donating, rather than mixing in pressing language, which creates an email that pretends WMF is the same as Wikipedia and doesn't list its goals and achievements on one hand, and scare-mongers about what happens if you don't donate (and what people who don't donate are like) on the other.--Ineffablebookkeeper (talk) ({{ping}} me!) 13:14, 28 August 2022 (UTC)
Wiki Commons has two collection of past banner banners 1) and 2. Also "Bill we looked up" Wakelamp d[@-@]b (talk) Wakelamp d[@-@]b (talk) 04:09, 29 August 2022 (UTC)
Jayden 466 Working ratio WP upated from 1.92 t0 based on your numbers that they had $393 M. Thank-youWakelamp d[@-@]b (talk) 07:01, 1 September 2022 (UTC)

Decentralized fundraising report by Wikimedia DeutschlandEdit

@Wakelamp: Wikimedia Germany have just published a report titled "Decentralized Fundraising, Centralized Distribution". This research report "describes the fundraising and distribution practices of eight large international NGO confederations and networks, and puts them in the context of the changing Wikimedia Movement."

From the Executive Summary (emphases in original):

Based on interviews and information sharing with staff of eight organizations, including Amnesty International, Oxfam International, CARE International, World YWCA, Greenpeace and the International Cooperative Alliance, the research asks about key practices in the areas of fundraising, decision-making about fund allocation, and in particular, about redistribution policies and mechanisms. This latter topic was given particular focus, because Movement Strategy emphasizes equity in funds distribution across an economically unequal international movement. Yet it leaves open how this should be structured.

The main findings of the research show that the Wikimedia Movement differs significantly in its practices from the screened organizations: All of the organizations are based on their affiliates fundraising independently, online and offline. In several cases the INGO specifically invests in the fundraising capacity of affiliates. Yet fundraising is highly strategic rather than diversified, in terms of markets, fundraising affiliates, and revenue sources. ...

The results of this research can be summarized as follows: International NGO confederations practice decentralized fundraising, and those that redistribute funds for equity do so in a centralized manner, based on policies agreed upon by the democratic governance bodies of the confederation. The affiliates that fundraise in strong markets thus support the affiliates in smaller markets. --Andreas JN466 12:26, 7 September 2022 (UTC)

We should support affiliates, but I think WMF are mainly dropping in fundraising staff.
Those organizations are very different from WMF, asbut hey all going towards Donors->WP WMF -> Endowment ->
then
1/ WMF recommends and Tides decides-> Grant recipient-> recipient projects.
2/ Affiliate recommends and Tides decides-> Affiliate -> grant recipient-> recipient projects.
The de WMF seems more transparent https://spenden.wikimedia.de/use-of-funds has what German Donors are told are the percentages. I am using translations, They fund work in other European countries that are close to them. But the work they are funding seems related to provision of information. The DE press releases are also totally different, and they have less of the good looking editor close up pictures, and the rest as a very distance group. Wakelamp d[@-@]b (talk) 12:46, 20 September 2022 (UTC)

Tracking of Donors by WMFEdit

  1. Donor Privacy Policy [[7]]

"We also collect or automatically receive some other information, such as: which of our pages you request and visit; "As you interact with the Wikimedia Fundraising Services, we may use automatic data collection and other locally stored data technologies such as tracking pixels, JavaScript, cookies, and local storage to collect certain information about your device. WMF uses cookies and other locally stored data to enhance your donation experience. We also use this information to create a safer online environment and gain a better understanding of donor preferences and interactions with the Wikimedia Fundraising Services."

  1. Foundation Privacy Policy We actively collect some types of information with a variety of commonly-used technologies. These generally include tracking pixels, JavaScript, and a variety of "locally stored data" technologies, such as cookies and local storage.

.... "We use this information to make your experience with the Wikimedia Sites safer and better, to gain a greater understanding of user preferences and their interaction with the Wikimedia Sites, and to generally improve our services. "

  1. And from the Board minutes "Staff noted that the Foundation does not currently track unique users for privacy reasons but staff is investigating different ways to analyze the data that is available. The Board noted that data is important and staff and the Board need to align on what the common goals are for tracking information. Staff is already working on developing metrics to show donors what impact their gifts are having." Wakelamp d[@-@]b (talk)

Board Plans more fundraising, Wikipedia pageviews levelling off, more expenditureEdit

  • Minutes March 2022 "The Foundation’s financials are looking positive but there are new trends, like declining pageviews in major markets, that are worrisome for fundraising revenue. There are macrotrends in the internet environment that are having an impact on decreased views, including TikTok rising as a popular website, Facebook being in decline, Google search being in decline (where 80% of traffic is from), and the rise of voice assistants. As a result, staff is projecting that banner revenue will be flat this year. There are two new revenue streams coming online in the next year, Enterprise and the Endowment. The biggest projected expansion in any of the revenue streams is in major gifts."

and "The Board had a discussion on working capital reserves, which is the amount of net surplus held per average annual spending. Currently, the Wikimedia Foundation is within the best practices range of 16-18 months (as determined by Charity Navigator). However, as the organization grows, the capital reserves are expected to drop, which will need to be compensated for with fundraising. The Board requested that staff draft a reserve policy with the oversight of the Audit Committee. When the reserve policy is ready, the Community Affairs Committee will help communicate the policy and the need to have reserves."

This "within the best practices range of 16-18 months" is such a joke. Wales and the WMF have been saying this for a decade, but every time their reserves exceed 16-18 months' expenditure, they raise projected expenditure. And when even that did not do the trick, they stuffed $100 million into an Endowment so it would not show up on the Foundation's balance sheet. (Every time they pay into the Endowment at Tides, that shows up as an expense in the Foundation's balance sheet, and with that the money – poof! – disappears from the Foundation's balance sheet.) --Andreas JN466 16:04, 31 August 2022 (UTC)
It's important to note that when they say "16-18 months" they don't mean 16-18 months of running Wikipedia, they mean 16-18 months of running the WMF, meaning 16-18 months salaries, rent, etc. That's why their reserves are like $100-$200 million. And of course, since they're constantly hiring, constantly expanding their staff, and so constantly needing higher cash reserves. "Most of the money we raise either goes either to pay our salaries or to fill cash reserves that will be used to pay our salaries in the event you stop donating in the future" doesn't make a good fundraising message though. Levivich 16:29, 31 August 2022 (UTC)

The data below come from the "Statements of Activities" in the audited reports. Assets do not include funds held in the Wikimedia Endowment. Expenses from the 2015–16 financial year onward include payments to the Wikimedia Endowment.

Year Source Revenue Expenses Asset rise Total assets
2020/2021 PDF $162,886,686 $111,839,819 $50,861,811 $231,177,536
2019/2020 PDF $129,234,327 $112,489,397 $14,674,300 $180,315,725
2018/2019 PDF $120,067,266 $91,414,010 $30,691,855 $165,641,425
2017/2018 PDF $104,505,783 $81,442,265 $21,619,373 $134,949,570
2016/2017 PDF $91,242,418 $69,136,758 $21,547,402 $113,330,197
2015/2016 PDF $81,862,724 $65,947,465 $13,962,497 $91,782,795
2014/2015 PDF $75,797,223 $52,596,782 $24,345,277 $77,820,298
2013/2014 PDF $52,465,287 $45,900,745 $8,285,897 $53,475,021
2012/2013 PDF $48,635,408 $35,704,796 $10,260,066 $45,189,124
2011/2012 PDF $38,479,665 $29,260,652 $10,736,914 $34,929,058
2010/2011 PDF $24,785,092 $17,889,794 $9,649,413 $24,192,144
2009/2010 PDF $17,979,312 $10,266,793 $6,310,964 $14,542,731
2008/2009 PDF $8,658,006 $5,617,236 $3,053,599 $8,231,767
2007/2008 PDF $5,032,981 $3,540,724 $3,519,886 $5,178,168
2006/2007 PDF $2,734,909 $2,077,843 $654,066 $1,658,282
2005/2006 PDF $1,508,039 $791,907 $736,132 $1,004,216
2004/2005 PDF $379,088 $177,670 $211,418 $268,084
2003/2004 PDF $80,129 $23,463 $56,666 $56,666

--Andreas JN466 16:08, 31 August 2022 (UTC)

@Andreas Thank you for this table. I think it is worthwhile to create two subsections on revenue and expenses. The expenses part bothers me considerably, because of the WMF grant process. Wakelamp d[@-@]b (talk) 23:19, 31 August 2022 (UTC)
When I said create, I meant I am working on it rather than asking you to so. Currently going through WMF grant procedures. audit, regionals, outcomes, and board policies. Wakelamp d[@-@]b (talk) 09:06, 1 September 2022 (UTC)

ExpensesEdit

I am trying to check the percentages, but the most up to date staff/contractors list I can find is this one one and it doesn't include all the other related companies. There also are many many sections in the link, and I would appreciate if editors could advise the split into fundraising, editors, others, platform. For instance I think Community Investment is for making grants to non WP, so it would be others. Oh they are hiring a community specialiist (although they are hiring 3 fundraisers at the same times) Wakelamp d[@-@]b (talk) 04:34, 3 September 2022 (UTC)

WMF Staff split into Sustain/Support/WMFEdit

This is a list of all the staff sections at WMF. I have tried to work out what they do, but there is no information I would appreciate if people could advise what the ??? areas do in terms of the fundraising split, and if the other percentage splits are correct-ish. Once this is done, then with the the directors salary and contractors, average salary for that functional area for the Bay Area (even though some are remote) we should have a percentage we can understand.

Department Section Fundraising Sustain Support WMF Dev/Backe Profit
Ceo Office CEO 100
ADV. Office Fund 100
ADV.  Comm Programs Fund 100
ADV.  Comm Resources Fund 100
ADV.  Endowment Fund 100
ADV.  Fund Operations Fund 100
ADV.  Fund Tech Fund 100
ADV.  Major Gifts & Found Fund 100
ADV.  Online Fundraising Fund 100
ADV.  Partnerships Fund 100
ADV.  Wikimedia Enterprise Profit 100
Comms Comm office WMF 100
Comms  Brand FUND 100
Comms  Communications Team WMF 100
Comms  Marketing WMF 100
Comms  Movement Comms Move 100
Fin. & Adv Office Admin 100
Fin. & Adv  Finance Operations Mixed
Fin. & Adv  Finance Strategy Admin 100
Fin. & Adv  IT Services Admo 100
Legal Legal office WMF
Legal  Community Dev Move 100
Legal  Community Res and Sus Move 100
Legal  Compliance WMF 100
Legal Fellow WMF 100
Legal  Governance & Risk WMF 100
Legal  Move Strategy & Gov Move 100
Legal  Public Policy Move 100
Legal  Trust and Safety Editors 100
Product Office WMF 100
Product  Abstract Wikipedia Movement 100
Product  AHT ???
Product  Campaign Fund 100
Product  Community Relations WMF 100
Product  Content Integrity WMF 100
Product  Content Transform Team Wikipedia 100
Product  ConProduct Mgmt Wikipedia 100
Product  CR Ambassador Wikipedia 100
Product Design ???
Product  Growth Movement 100
Product  Inuka Profit 100
Product  Langand Trans ??? 25 25 50
Product  Mobile Apps ???
Product  Parsing & Infrastructure Dev
Product  ProdAnalytics ???
Product  Prod Design ???
Product  Prod Design Strategy ???
Product  Prod Infrastructure Dev 100
Product  Program Management Dev 100
Product  Readers Product ????
Product  Structured Content Product ????
Product  Structured Data ???
Product  Trust and Safety Tools Editor 100
Product  Web Dev 100
Product  Wishlist Ediitpr
Tal. & Cul  Diversity, Equity and Inclusion Movment 100
Tal. & Cul Learnin and Development WMF 100
Tal. & Cul  People Experience HrR?? 100
Tal. & Cul  People Operations Payroll?? 100
Tal. & Cul  Recruiting Admin 100
Tech office Back End 100
Tech  Architecture Back End 100
Tech  Data Center Operations Back End 100
Tech  Data Engineering Back End 100
Tech  Global Data & Insights Back End 100
Tech  Infrastructure Foundations Back End 100
Tech  Machine Learning NPP 100
Tech  Performance Back End 100
Tech  Platform Engineering Back End 100
Tech  Quality and Test Engineering Dev/Back en 100
Tech  Release Engineering Dev/Back en 100
Tech  Research (cool so make it supprot) R and D 100 100
Tech  Search Platform Back End 100
Tech  Security Back End 100
Tech  Site Reliability Engineering Back End 100
Tech  Technical Engagement Profit 100
You're gonna have to start with what your existing categorization system here is.. Because some of this doesn't make sense right now. —TheDJ (talkcontribs) 19:57, 19 September 2022 (UTC)
^ this, but specifically (and with my bias apparent) — Wishlist (Community Tech to the rest of us...) is marked as Ediitpr (Editors?) and probably should mostly be assigned to "Dev/Backend"? — TheresNoTime (talk • they/them) 20:08, 19 September 2022 (UTC)

RfC (WMF fundraising emails)Edit

So far no one appears to have said they like the emails or find the wording appropriate. On the other hand, there have been fewer than ten people commenting to date. Perhaps it would help to get a clearer and more representative result if we do an RfC with options editors can simply sign to express their views (see below). --Andreas JN466 17:48, 15 August 2022 (UTC)

Endorse wording of emailsEdit

  1. As someone in the relatively small intersection of the sets of "Wikimedians" and "professional fundraisers (other than those employed by the WMF)", I think this is fine. One can raise objections to the fact that WMF has so much money, or how it's spent, and those objections are fairly well aired in various places. But if this discussion is actually about the content of the emails, then I don't see anything to complain about. The messaging is well-tested with donors and will succeed in its objective. There are a few fundraising 'tactics' used but nothing remotely unethical. And at the heart of it is a truth: Wikipedia depends on donations, and if the fundraising campaigns weren't effective and people wouldn't respond to them then WMF would run out of money quite quickly, with an inevitable impact on Wikipedia. I'm not exactly sure what the best way to bring Wikipedia offline actually is, but starting to edit fundraising campaigns based on the likes and dislikes of people on this page, rather than 15 years' evidence of what donors will actually respond to, is probably fairly high up the list. Thanks, The Land (talk) 19:34, 16 August 2022 (UTC)
    Thanks for commenting. Unfortunately though I have to disagree, The Land. In my view, getting people on very limited incomes to donate $2 they can't afford, by making them "believe that Wikipedia is in trouble and that they need to give money to keep it online", is unethical. All the more so if it's done in part to raise WMF executives' compensation to $350K and beyond (bear in mind that these salary figures are two years old). Andreas JN466 20:09, 16 August 2022 (UTC)
    Yes, it's obvious you disagree, as you not only started the RfC and then voted 'oppose' , but you also make these and similar points at every available opportunity in every possible place. Given that, I'm unsure why you felt the need to comment on my !vote. But thanks for clarifying and have a nice day. The Land (talk) 20:23, 16 August 2022 (UTC)
    It's worth mentioning that some of those salaries have been rising steeply, even as the WMF claimed to be in urgent need of money. Compare the entries here in the 2020 Form 990 to the corresponding entries here in the 2018 form. As far as I can make out
    • the CEO's total compensation incl. benefits increased by 7% (to $423,318),
    • the DGC's and GC's by 10%,
    • the CFO's by 11%,
    • the CTO's by 17%,
    • the CAO's by 22%,
    • the CCO's by 25%,
    • the CT/CO's by 28%, and
    • the CPO's by 32%
    – all over a two-year period when the annual inflation rate in the US was at 2%. Andreas JN466 16:18, 1 September 2022 (UTC) I've added some more salaries to the list. --Andreas JN466 09:48, 4 September 2022 (UTC)
    To quote Upton Sinclair, "it is difficult to get a man to understand something when his salary depends on his not understanding it." I have no doubt that WMF staff, whose salary depends on WMF fundraising, will want to send out whatever fundraising messages work best based on 15 years' evidence of what donors will actually respond to, including but not limited to messages that convey urgency and dire need, even if there is no urgency or dire need, or messages that suggest the money will go to support volunteers, even when most of the money does not go to support volunteers (or messages that suggest Wikipedia has one founder). Thankfully, a volunteer community, not dependent upon WMF fundraising, oversees the WMF, and can ensure that Wikipedia lives up to its ideals, and doesn't just pursue whatever messaging donors will best respond to. As Email #1 says, Together, we can rebuild trust in the internet, and by extension, in each other. Levivich 02:33, 17 August 2022 (UTC)
    The "well-tested with donors" claim - and the "15 years of evidence" argument in particular - is somewhat of a McNamara fallacy as it's easy to point to the fundraising bottom-line and say "There's the proof that it works" without needing any comparative basis to determine whether it would be more or less effective than other fundraising strategies. If you were able to prove or at least demonstrate by means of comparison that the current messaging is both effective and ethical as compared to other non-profits that engage in fundraising campaign, you might have an argument there. As it is, when no such comparisons exist to back up your assertion, we are left only to point towards anecdotal evidence. And from where I'm sitting, I'm not seeing a heck of a lot of anecdotes that Wikimedia's fundraising is well-received. All of this is important because it goes to credibility. Credibility is still an extremely vital long-term commodity to possess in a public arena, particularly if one's finances ever become scrutinized by a whistleblower or a governing body, in order to show that funds are being raised in good faith. Credibility is not something that can be easily measured (except in broad, statistically sound surveys), but ongoing, repeated murmurs of discontent and disapproval does not do well to signal having wealth in this space. 🌈WaltCip-(talk) 13:14, 17 August 2022 (UTC)
    So the evidence it's effective is there in the WMF's extensive A/B testing of its fundraising. Worth taking a look on Meta, it gets summarised occasionally. Also, I don't think you can invoke the McNamara fallacy here; that's something that happens when you confuse metrics for outcomes. The desired outcome of a fundraising email campaign is raising money in the long term, the metric and the outcome are pretty identical. If I was saying "look, these emails have really high open rates so they are bound to raise money" it would be a valid criticism. I'm still not sure that '15 Wikipedians can be found who don't like it' would be better data, though. I'd say that's of pretty much zero value as data, as 15 Wikipedians can readily be found to dislike any given thing. ;)
    Regarding ethics, I could give you a really long answer regarding fundraising methods, professional standards and regulatory frameworks. However I don't have time. All I can say is the emails are gold-standard, A+ quality stuff that should be nominated for fundraising awards and which I fully intend to use as examples of good practice the next time I'm running a training session. 14:51, 17 August 2022 (UTC) The Land (talk) 14:51, 17 August 2022 (UTC)
    According to who? What fundraising awards? Levivich 15:08, 17 August 2022 (UTC)
    Me. Just expressing my professional opinion on the matter. The Land (talk) 16:45, 17 August 2022 (UTC)
    I hope at your next training session, you also cover AFP and CFRE ethical standards for fundraising solicitations. Levivich 17:18, 17 August 2022 (UTC)
    No, because I'm based in the UK so neither of those is relevant. What I do refer to is the UK Fundraising Regulator's Fundraising Code of Practice, which is rather more detailed. You might want to look at the Regulator's completed investigations which gives an indication of what kind of thing actually breaches the code.
    You'll also hopefully note that none of these guidelines says anything along the lines of "charities must stop fundraising when they have over X amount of money" or "fundraising emails must not convey urgency" or anything along those lines. The Land (talk) 19:19, 17 August 2022 (UTC)
    Let's avoid straw manning: concerns that fundraising communications are misleading are not along the lines of "charities must stop fundraising when they have over X amount of money" or "fundraising emails must not convey urgency". Thank you for the UK Fundraising Regulator links; I found them very interesting to read, in particular:
    • 1.1.1 "Your fundraising must be ... honest ..."
    • 1.2.1. "While reasonable persuasion is allowed, you must not fundraise in a way which ... places undue pressure on a person to donate."
    • 1.3.1. "You and the fundraising materials you use must not mislead anyone, or be likely to mislead anyone, either by leaving out information or by being inaccurate or ambiguous or by exaggerating details."
    • 1.3.2. "Before you make any direct or implied claim in your fundraising which is likely to be taken literally, you must make sure that there is evidence to prove the claim."
    • 1.3.6. "You must take all reasonable steps to treat a donor fairly, so that they can make an informed decision about any donation."
    • 8.1.1. "While fundraising, you must not ... act dishonestly or manipulatively, or deliberately try to make a potential donor feel guilty; or act in any other way that a reasonable person might consider would damage the charitable institution’s reputation. This includes: ... putting undue pressure on members of the public to donate; ... or any other behaviour that harms the reputation of the fundraising profession or the charitable institution you are representing."
    • 9.1.1. "You must ... make sure all advertisements are ... honest and truthful."
    • The 2021 Shelter investigation: "However, we found that contrary to the standards in the Code of Fundraising Practice (the code), the charity had inadvertently suggested in the advertisement that donations would be spent only on the work of its helpline, when the aim of the appeal was to raise money for Shelter’s work more generally. The addition of a few clarifying words would have avoided the risk of breaching the code on potentially misleading people and restricted donations."
    And, of course:
    • 2.4.5. "You must have a clear and published procedure for members of staff and volunteers to report any concerns they have about your fundraising practice."
    • 2.4.3. "You must make sure that: complaints are investigated thoroughly and fairly to find out the facts of the case, avoiding unnecessary delay; and you respond to complaints fairly and in a way that is in proportion to the complaint."
    Cheers, Levivich 20:32, 17 August 2022 (UTC)
    Is there evidence to prove the claim the Wikipedia is at risk of being forced to run ads? Jr8825Talk 21:41, 17 August 2022 (UTC)
    I think it's important to look at the actual wording of the emails, not the construals that have been put upon them by other people in this thread. I see no claim that, for instance, if anyone doesn't respond to the emails, then Wikipedia will shortly become ad-supported. I do see statements that Wikipedia decided not to be ad-supported and therefore relies on donations (true!), and also statements that if people give then this will enable Wikipedia to remain ad-free for years to come (true, hopefully!). As Levivich helpfully pointed just above, it's important to avoid straw-manning, so let's look at what the emails actually say, not what people claim they say. The Land (talk) 21:49, 17 August 2022 (UTC)
    To me, "Unfortunately, most people will ignore this message. We have no choice but to turn to you: please renew your gift to ensure that Wikipedia remains independent, ad-free, and thriving for years to come" implies that there's a risk Wikipedia will have to run ads, or otherwise the WMF would not say that it has been forced ("no choice") to request help from the recipient. Jr8825Talk 21:58, 17 August 2022 (UTC)
    Undeniably, such a risk exists. If the WMF stopped soliciting donations, or no-one responded to WMF fundraising appeals, then it'd have to find other sources of funding or fold completely. The WMF have always refused to entirely rule out advertising funding and would have to consider it. It's only a non-question because of the continued success of the fundraising campaigns. The WMF may have a choice about whether it sends a particular person an email, but it doesn't really have a choice about whether to conduct fundraising activity from the general public. And it's entirely legitimate to say the result of someone giving is that Wikipedia will "remain independent, ad-free and thriving for years to come". The Land (talk) 22:33, 17 August 2022 (UTC)

    WMF Vice President Erik Möller estimated in 2013 that Wikimedia's mission, beyond merely keeping Wikipedia online, could be sustained on $10M a year. Even if we double that 2013 estimate, to $20M, the Foundation would at that level of spending – bearing in mind the interest it earns each year on its investments – have enough money to keep Wikipedia online and fulfil its wider mission, as scoped in that 2013 post, indefinitely, without ever asking the public for another penny.
    — User:Jayen466, m:Talk:Fundraising, 15:04, 3 June 2022 (UTC)


    To me, that shows that no such risk truly exists. * Pppery * it has begun... 22:37, 17 August 2022 (UTC)
    Last year, the WMF had (figures rounded to nearest million):
    • reached its $100 million goal in the Wikimedia Endowment
    • an additional $87 million in cash and cash equivalents
    • an additional $117 million in short-term investments ($81M in corporate bonds, $21M in mortgage-backed securities (!), $15M in US Treasury securities)
    • an additional $20 million in long-term investments ($4.5M in corporate bonds, $12.5M in stocks, $1M in mortgage-backed securities, $2M in US Treasury securities)
    • Between July 2020 and June 2021, the WMF brought in $159 million in revenue, and didn't spend $47 million of it (just added it to its cash/investment stockpile)
    • It did spend $68 million in salaries, benefits, and other compensation for fewer than 400 full-time equivalent employees (FTEs), which comes out to at least $170,000 per FTE (the real number is higher because there are, no doubt, far less than 400 FTEs employed by the WMF)
    • ...and spent less than $3 million on internet hosting and less than $6 million on grants.
    • Since then, there is no doubt the WMF has collected at least another $100 million in donations. We'll find out when the next audit is released in October.
    We have no choice but to turn to you, my foot. Levivich 22:41, 17 August 2022 (UTC)
    In the nine months from July 1, 2021 to March 31, 2022 the WMF collected another $153.6 million in revenue and already substantially exceeded its own year goal. It nevertheless proceeded to fundraise in places like India, Latin America and South Africa in the fourth quarter (April–June 2022), using much the same pleading email wordings as shown above (see Meta). However, perhaps to acknowledge that they had already surpassed their annual fundraising goal, the WMF fundraisers did change we haven't reached our fundraising goal and we don't have a lot of time left. We’re not salespeople ..., as shown in email 3 above, to we haven't reached our fundraising goal in India yet, and this fundraiser will be over soon. We're not salespeople ... (bolding is my emphasis) in the Indian email samples provided on Meta. --Andreas JN466 10:58, 18 August 2022 (UTC)
    @Levivich: Thanks for reviewing the UK Fundraising Regulator links. As for the code breach example they provide where "the charity had inadvertently suggested in the advertisement that donations would be spent only on the work of its helpline, when the aim of the appeal was to raise money for [its] work more generally", it's worth noting that email 2 e.g. says "Wikipedia donor" rather than "Wikimedia donor" and makes no reference to any other Wikimedia projects. (According to WMF staff quoted here Wikipedia costs the WMF about 30 percent of their $112.5 million operating budget ($33.75 million) to maintain.) Andreas JN466 07:22, 19 August 2022 (UTC)
    re: "the desired outcome of a fundraising email campaign is raising money in the long term", a trial which shows an email format generates immediately higher revenue does not indicate it's sustainable, it indicates it's successful at manipulating people into a desired course of action. As others have said, these campaigns are also generating bad publicity and it's plausible donors will be less likely to respond for urgent requests for money when they occur at regular intervals. The broader objection is that we don't need to mislead donors about the health of our situation. Doing this in our community's name and being unclear about how money is spent are additional frustrations. A positive campaign that focuses on why Wikipedia/WMF are precious & valuable could avoid these issues. It's not like the WMF needs that additional revenue. Jr8825Talk 15:33, 17 August 2022 (UTC)
    The email programme has been running for about 15 years, which to my mind shows a good level of long-term sustainability. The negative publicity is, again to my mind, fairly minimal and consistent between years. It is just about conceivable it could start to have some cumulative impact, but in my view the reduction in income from deliberately choosing to make the emails less effective would likely be much higher. The Land (talk) 16:45, 17 August 2022 (UTC)
    To me, the most striking aspect of WMF fundraising is the contrast between –
    • the WMF's very significant annual budget surpluses (over $50 million in 2020/2021, or close to $90 million if you count the Endowment growth of over $37 million in the same year) and the huge growth in expenses, above all salary costs, versus
    • fundraising messages focused strongly on the need for donations to ensure the protection and survival of Wikipedia as a subscription-free, ad-free and independent website.
    Wikipedia (as well as Wikimedia) could run and has run on a tiny fraction of the current budgets. But the narrative that Wikipedia, the website, is under some sort of threat is regularly trotted out, supported by serviceable journalists who are telling the public, counterfactually, that people at the WMF "often struggle to have enough money to keep Wikipedia up and running" or that Wikipedia is "launching a distress signal seeking financial help from its users" because it is having difficulty "balancing its books" – when in fact the WMF has just reported that after the first three quarters of its 2021/2022 financial year it had already exceeded its own revenue target for the entire year (which at $147.8 million was almost $40 million higher than the previous year's $108 million target, of course), had underspent and was anticipating another year-on-year net asset rise of $25.9 million (not counting Endowment growth).
    Good fundraising to me would not mislead people into thinking that Wikipedia, the website, was at risk of going offline, or losing its independence. Instead, good fundraising would (1) tell the public about all the things that the WMF is doing today that it wasn't able to do a little over a decade ago, when it had 10% of today's budget, and (2) invite people to support this new and additional work. Given that it now has a combined total of about $400 million in net assets and in the Endowment, the WMF could comfortably keep Wikipedia online, ad-free and independent in perpetuity without ever asking the public for another penny, just from the interest it earns. Andreas JN466 16:05, 17 August 2022 (UTC)
    • The Land, this portion is just flat false. 31% of your gift will be used to support the volunteers who share their knowledge with you for free every day. How could one figure that? I know of no case where the community at large has been permitted to control the use of any WMF funds whatsoever, let alone 31% of them. So, since the guidelines require evidence for the truth of a claim, where's the evidence for that one? Seraphimblade Talk to me 10:40, 24 August 2022 (UTC)
  2. When you hire someone to raise funds and they succeed in raising funds, this is generally seen as a good thing, except on Wikipedia for some reason. Gamaliel (talk) 19:18, 30 August 2022 (UTC)
    It is not the undoubted skills of the staff that are at issue here. Surely it is the board that determines how much money should be raised, and how much aggressivenes should be considered tolerable in fundraising messages. The staff merely do what they have to do to fulfil the targets set. Andreas JN466 20:00, 30 August 2022 (UTC)
  3. I spent most of my working life in not-for-profit organisations and, if you want income to achieve your mission, then you need to employ experienced marketeers and fund raisers and let them do their job using their expertise, just as I would expect them to let me do my job with my expertise. I don't see WMF as any different. I do my part to write good cited content and I don't expect the fund raisers to tell me how to do it and I don't think I should tell them how to do the fund raising. Yes, I have opinions on how those funds might be best spent (I share the wish expressed by others for more expenditure on technical development to better support volunteers), but that's a separate discussion. Let's all focus on what we can each do best towards the mission. Kerry (talk) 01:19, 1 September 2022 (UTC)
    Comment: In Wikipedia, we generally declare conflicts of interest. May I therefore invite commenters who –
    • are past or present board members, employees or contractors of Wikimedia affiliates, i.e. organisations that are wholly or in part funded by the Wikimedia Foundation, or
    • have ever taken full-time or part-time employment paid for by a Wikimedia Foundation grant
    to please identify themselves as such? This will result in more transparency. Thanks. Andreas JN466 08:23, 1 September 2022 (UTC)

Object to wording of emailsEdit

  1. Object for reasons stated above. --Andreas JN466 17:48, 15 August 2022 (UTC)
    The emails' "From" field – "jimmy@wikipedia.org donate@wikimedia.org" – also deserves a mention. As Craig Younkins put it in a piece on Medium:
    Another abuse is found in the “From” address:
    From: "jimmy@wikipedia.org" <donate@wikimedia.org>
    Reply-to: donate@wikimedia.org
    This one is so common that some people won’t consider it abuse at this point. But really, it’s an email from donate@wikimedia.org that tries to trick the user into thinking it’s from jimmy@wikipedia.org by putting that where a person’s name is intended to go. Notice that in the inbox view, only jimmy@wikipedia.org is shown. Andreas JN466 18:32, 26 August 2022 (UTC)
  2. Daß Wölf 17:59, 15 August 2022 (UTC)
  3. * Pppery * it has begun... 18:38, 15 August 2022 (UTC)
  4. I have two specific objections. (1) I think the whole "unlock your badges" thing is tacky, and a bad look for the project. And (2) I don't like the percentages of what the funds are used for because, as already noted by others above, it's misleading. As for the rest of the text signed by Jimmy, I'm OK with that. It's the typical jargon of fundraising messages from nonprofits, and I'm not going to nitpick about it. --Tryptofish (talk) 21:18, 15 August 2022 (UTC)
  5. Strongly object to the wording of the emails. The tugging at the heartstrings of people under the false impression that we need more server money or that WMF money goes mostly to Wikipedia. The Bronze/Silver/Gold/Platinum badge gimmick is tacky. The email claims: 42% of your gift will be used to sustain and improve Wikipedia and our other online free knowledge projects. 31% of your gift will be used to support the volunteers who share their knowledge with you for free every day. 27% of your gift will give the Wikimedia Foundation the resources it needs to fulfill its mission and advance the cause of free knowledge in the world. None of this wording is quite an outright lie, but as others have said, "used to support the volunteers" creates a misleading impression—almost all of us are not paid, nor given grants or funding or reimbursement for money that we spend purchasing reliable sources or travelling to meet-ups and conferences, and so on. "Sustain and improve Wiki[m]edia" is a very vague thing to do with 42% of donations: this amount of money is not spent on server costs and technical maintenance—the WMF fail even to implement bugfixes made by volunteers.
    WMF fundraising damages the reputation of us as a community, as evidenced by the spate of news stories—admittedly often in the gutter press—which have followed fundraising drives for a number of years now ([8][9][10]). Their wealth has grown inordinately, and the community has not seen a difference. — Bilorv (talk) 11:40, 16 August 2022 (UTC)
    In fairness, the donor response wouldn't be nearly as good if they were more accurate about how the donations are spent: About a third of your gift will be added to our $200-million coffers (not to be confused with our separate $100-million endowment). Most of the rest will be spent on our salaries and benefits. Less than a quarter of every dollar you give will be spent on actually running the website. Levivich 00:22, 18 August 2022 (UTC)
    Or they could follow the model used by the "public radio station" in Rockstar's GTA Vice City. That at least would be amusing...something like "If you view Wikipedia without donating, you're stealing." Intothatdarkness 16:59, 25 August 2022 (UTC)
  6. In addition to the issues raised by others above, it's "co-founder" not "founder". Levivich 16:05, 16 August 2022 (UTC)
    Made me chuckle, but it's true and a good point. — Bilorv (talk) 15:36, 17 August 2022 (UTC)
  7. The wording of the emails, which imply that Wikipedia is in desparate need of money, are not accurate, and place unwarranted expectations on the volunteers by the general public. the WMF is not supposed to be a slush fund for the Tides Foundation. Hemiauchenia (talk) 18:14, 16 August 2022 (UTC)
  8. Deeply misleading. Yngvadottir (talk) 21:01, 16 August 2022 (UTC)
  9. Misleading and unethical. AndyTheGrump (talk) 21:05, 16 August 2022 (UTC)
    This comment best summarises my opinion. Dutchy45 (talk) 19:04, 4 September 2022 (UTC)
  10. Anything feeding the cancer needs to be stopped. Chris Troutman (talk) 22:20, 16 August 2022 (UTC)
  11. Misleading, and I am choosing a very mild word here. I also concur with what others above have said. Spot on, Hemiauchenia. - Darwinek (talk) 23:53, 16 August 2022 (UTC)
  12. I've already shared my thoughts about this above. Jr8825Talk 23:58, 16 August 2022 (UTC)
  13. These manipulative emails make us little different than an evil corporation. We should do everything in our power change this. Kolya Butternut (talk) 02:07, 17 August 2022 (UTC)
  14. The first time someone outside a station tells you they've lost their money, can you help them get home, etc., you do and leave with a warm feeling of having helped out in a crisis; when they approach again some time late, you have a sinking feeling of having been had; the third time you are a snarling misanthrope. These recurring emails with their appearance of being reluctantly written in a crisis degrade the benevolence which is the core of the project and they are an easy target for negative coverage. All such emails should be community-marshalled, with defined circumstances where the WMF can flag up that fundraising has become necessary (which would have to be accompanied by an explanation of what had happened to the previously-accumulated funds) and an clear and appropriate message and appropriate recipients can be defined and agreed before anything is sent out. AllyD (talk) 06:09, 17 August 2022 (UTC)
  15. The percentagewise breakdown (quoted by Bilorv above) is galling, because the categories aren't even distinct. For example, take "support the volunteers" and "sustain and improve Wikipedia": does supporting the volunteers not sustain the project? If there were no percentages at all, I doubt I would have missed them, but this makes me feel looked down upon. It's disrespectful. XOR'easter (talk) 14:33, 17 August 2022 (UTC)
  16. As above. ― Qwerfjkltalk 15:32, 17 August 2022 (UTC)
  17. These fundraising messages are (nearly) unrelated to reality. In addition to the above comments, I state that creating a new, decent article is a much better way to help Wikipedia than donating 2$ to WMF. From the WMF messages, one can understand that the donations are the only accessible way to help Wikipedia. --NGC 54 (talkcontribs) 23:20, 17 August 2022 (UTC)
  18. Apart from the emails containing the usual distortions and half-truths, there is an absence of any option to indicate where an email to the effect of "Fuck off! I've fallen for your scam once but I've now learnt how misleading your fundraising messages are. Don't you ever dare contact me again." I thought that at least through much of Europe that there was a requirement for a clear opt out in all communications of this sort. --82.45.168.246 (talk) 08:12, 18 August 2022 (UTC)
    There very likely is in the emails that are actually sent. What's been posted is the email copy, not the full email as it's built in HTML. Previous emails I've received from the WMF have "If you do not wish to receive any future emails from the Wikimedia Foundation, unsubscribe instantly." in small print at the bottom, with the unsubscribe instantly as a link to an unsubscribe page. The Land (talk) 08:19, 18 August 2022 (UTC)
    The unsubscribe options are in fact there, in the small print; I'd left them off to save space. I've added a note to that effect above. Andreas JN466 10:49, 18 August 2022 (UTC)
  19. Fundraising emails that purport to request funds for Wikipedia ought to be more transparent and truthful about the Foundation's real financial position. This wording isn't untruthful but it deceives by omission. The word for this practice is paltering.—S Marshall T/C 12:39, 18 August 2022 (UTC)
  20. Strong oppose, as the WMF is going directly against its Wikimedia Foundation Values. Three quotes from the value statement that I think is worth mentioning are:
    • "For it [collaboration] to work well, each of us needs to be honest, accountable, and transparent to one another." — Is asking people making another donation to protect and sustain Wikipedia honest, accountable and transparent, when WMF's funds have been spent recklessly and inefficiently? Is the statement If all our past donors gave a small amount today, our fundraiser would be over honest, accountable, and transparent, when surely the next fundraiser would be longer in length and be more aggressive?
    • "Engaging in civil discourse requires kindness, care, respect, tact, empathy, trust, and safety. It is key to getting, giving, and receiving good information." — Is saying This is awkward to admit, but I have to be honest: 98% of our readers don't give; they simply look the other way when we ask for an annual donation and Unfortunately, most people will ignore this message. We have no choice but to turn to you: civil to non-donating contributors of Wikipedia, or non-donators in general? Is saying I've been happily stunned by the response from our donors, but we haven't reached our fundraising goal and we don't have a lot of time left. is grateful to our existing donors?
    • "We are duty-bound to steward our resources and deliver exceptional products and services." — Is mentioning ..., why not just run ads to make revenue? Or capture and sell reader data? Or make everyone pay to read? or Wikipedia is different in that it doesn't belong to the highest bidder, the advertisers, or corporations. shows the would-be donors about our excellence, when we have repeated this false doomsday mantra for 20 years?
    My suggestion to the Wikimedia Foundation here is to tone down the message and don't just simply aim for getting ever more revenue than the last year. At some point, it's not gonna work anymore. Use the existing money efficiently and addressing our perennial issues would be the best way to prove the would-be donors and editors here of our worthiness. CactiStaccingCrane (talk) 15:03, 18 August 2022 (UTC)
    Another thought: It gives the false impression that the existence of Wikipedia is irreversibly dependent on donations, to the point in which disgruntled readers/editors throwing a fit will turn around and say "I used to donate to Wikipedia, but because you guys reverted me/blocked me/annoyed me, I will never donate again". This sort of empty threat generally results in scoffing replies along the lines of "We don't see a penny of your donations anyway". This is information that most people familiar with the WMF's behind-the-scenes budget machinations are familiar with, but apparently most other people are not, and it may be causing a detrimental sense of entitlement that could also be contributing to instances of incivility or tendentious editing. 🌈WaltCip-(talk) 16:04, 18 August 2022 (UTC)
  21. Object because the language is overly promotional, which compromises the reputation of Wikipedia and the WMF. 2601:647:5800:1A1F:5D03:C0E9:18B8:AF26 (talk) 03:21, 19 August 2022 (UTC)
  22. Misleading and, per S Marshall, paltering indeed. Retswerb (talk) 03:56, 19 August 2022 (UTC)
  23. Object, especially to If all our past donors gave a small amount today, our fundraiser would be over. I believe this statement to be untrue, and possibly a deliberate and fraudulent lie. However rich it becomes, I do not believe that the WMF will ever voluntarily stop fundraising, because it now sees fundraising as a goal rather than a necessity. Certes (talk) 11:24, 20 August 2022 (UTC)
    Exactly. CactiStaccingCrane (talk) 12:08, 20 August 2022 (UTC)
    Exactly, Certes. The $150 million fundraising goal for 2021/2022 was already far exceeded by the end of the third quarter; even so, Indian and South African readers and donors were told in the fourth quarter to give money again "to keep Wikipedia online" and "ad-free", "to keep Wikipedia free" (i.e. accessible without having to pay a subscription fee), "to sustain Wikipedia's independence", etc.
    The 2020/2021 goal was revised upwards during the year, from $108 million to $125 million, and that revised, higher goal was then also exceeded, by almost $30 million ($154 million). This includes revenue generated in South America in spring 2021, at the height of the pandemic there. I believe we are witnessing untrammeled corporate greed – all the more shameless for being largely based on volunteer labour. Andreas JN466 12:54, 20 August 2022 (UTC)
    It's like NASA kept asking for more budget while spending the money on the Senate launch system. More money does not mean faster operations. CactiStaccingCrane (talk) 13:53, 20 August 2022 (UTC)
  24. The wording is at best misleading, and that's being generous. Intothatdarkness 15:46, 21 August 2022 (UTC)
  25. Strong Objection The language used is highly misleading. That something is effective does not make that something ethical. CoffeeCrumbs (talk)
  26. Strong Objection The %s are incredibly misleading.
  27. The percentages are misleading and inspecific, for one. The whole bit about a fundraising goal and 'we don't have a lot of time left' is also misleading because I doubt the campaign would stop if a goal was met (as Jayen466 points out, they didn't in India when they had already met their annual goal) and the Foundation would be just fine if it happened to not meet a goal. The general impression that Wikipedia is in dire need of money is misleading. Mostly mentioning supporting wikipedia (there's one mention about "...Wikipedia and our other online free knowledge projects" in the percentage breakdown, styling taken from the email) is also problematic: it's misleading to donors and isn't true. If supporting Wikipedia (plus the other projects) and the community behind it was the Foundation's priority, some things would have a greater priority. The emails should mention the strategic direction, their non-Wikipedia use of funds and what else the foundation prioritizes, and/or how well they pay their staff (Jayen466 makes a similar point in their 2nd paragraph under "Discussion). The foundation should encourage people to donate based on the things the foundation does now with its large budget (of which keeping Wikipedia online is a fraction). Perfection shouldn't be expected, but these emails aren't good enough [collectively, perhaps not individually]. (The badges, though, seem permissible to me) —Danre98(talk^contribs) 18:49, 23 August 2022 (UTC)
  28. The Land above suggests that the metric applied to the fundraising appeals is primarily their effectiveness. And I suspect that messages like these are, indeed, effective. If I stuck a gun in someone's face, that would probably also be a very effective way of getting them to give me money. The question in both cases, however, is whether doing so is ethical. These messages in the most charitable reading distort the truth, and in a more realistic one flat out lie. Even if WMF got absolutely no donations this year, they could quite comfortably keep the lights on without running ads or any of that other doomsaying stuff. They might have to lay off some administrative staff, but well, I'm not really convinced that would be a negative. So far as "Well, every charity does this"—remember your mother asking you "If all your friends ran off a cliff, would you run off it too?". The primary value in Wikipedia is to present things honestly and neutrally. These messages are not in keeping with that, and damage that reputation. These messages are unethical and must be reframed to accurately and neutrally reflect the actual situation, even if that makes them less effective. If you're going to include percentages, include the percentage of the budget that goes to WMF staff salaries and benefits. Seraphimblade Talk to me 10:55, 24 August 2022 (UTC)
  29. Strongly Object . I don't really care if this kind of immature, US style marketing-hype is successful or not. I don't care if it is possibly authored by the fundraising team on the fake premise that Jimbo Wales is behind it. I don't object to fundraising, I've done enough of it myself but it was always for critical humanitarian objectives. What I do object to is when an oganisation whose product is based on claims of accuracy, honesty, and neutrality, resorts to a fundraising campaign based on lies and deception. Especially when it constantly tells its volunteer workforce that there suddenly isn't enough money to develop the very software that is needed to keep the encyclopedia corpora clean. Kudpung กุดผึ้ง (talk) 09:56, 25 August 2022 (UTC)
  30. It is really important that a charity's marketing be in accord with the core values of that charity and a serious risk if they undermine them. Our core values are in providing factual information. If we were running a donkey sanctuary we could probably be forgiven for claiming something was 31% of spending instead of 3.1% or 0.31%, but if it turned out that our annual report was stuck together with glue made from rendered equine hooves we'd be in trouble. It would be easy to work out the cost of running the Wikipedia library and then put in a claim that "just $31 gets one of our volunteer factcheckers online access to her city's newspaper archives" or some similar factoid. There are charities that market in ways that project and protect their core brand values. The WMF should do the same. ϢereSpielChequers 15:27, 26 August 2022 (UTC)
    yes, Yes, YES! This is what the WMF should do: showcase that we are competent people and we are worth donating. Not forcing people to donate out of guilt. Two question arose though: 1. What would the money the WMF gained will be used to benefit the community? 2. Are we actually competent enough to persuade people to donate? CactiStaccingCrane (talk) 15:32, 26 August 2022 (UTC)
  31. Strongly Object, too disappointing to put into words really. Aza24 (talk) 17:57, 26 August 2022 (UTC)
  32. Strongly object – this is people's money that WMF is using, and the revelation that several people end up contributing money they can't afford because of the pressing tone of these emails is genuinely horrifying to me. I edit out of love, to bring knowledge about my areas of interest to a wider group of people; you can't help but feel that your work is being taken advantage of to tug on the heartstrings of others. Some have raised the point that objections to these emails are relatively "minor and consistently minor", and that it shows that the emails are mostly successful and unobjected to, but I don't think this is a reasonable argument to take – that if it works, why think about it otherwise, and if we rework it, what if it breaks? WMF has somewhere around $400m in assets and reserves; reworking emails will not irrevocably harm it so that it has nothing to lean on. As one editor has noted, it's going to catch up to us in the long run, and it'll bite us in the ass if people realise that these emails aren't an honest appraisal of WMF funding. We can do a lot better than "send it and forget it".
    $400m in assets and reserves is a new context that no longer matches up to these fundraising methods. Maybe these emails were warranted a decade or so ago, but in light of how well the WMF is doing, it's unfair to put forth misleading, vague, emotionally pressing statements that lead people to part with their money under circumstances that are not honest. It's unethical to accept donations acquired like this, and it's antithetical to the goals of a non-profit.--Ineffablebookkeeper (talk) ({{ping}} me!) 18:11, 26 August 2022 (UTC)
  33. The fundraising campaign runs counter to the values of the Wikipedia community and misrepresents what we are (Kudpung and WereSpielChequers said this more eloquently). Running a scaremongering campaign risks that people will give money to the WMF and then not give money to causes that are much more in need of money (food banks in the UK will run out of food this winter, putting people at actual risk of starvation). It is disgusting to see a charity sitting on fat stacks of cash that still tries to get a bigger slice of the donation pie. —Kusma (talk) 19:40, 26 August 2022 (UTC)
  34. Object. These spams are just toxic and horrible. I'm not sure we should be spamming people at all, even, because
    1) We don't need the money.
    2) But people give it to us cos we ask -- people who don't have a lot of money, who have to give up family pizza night that week to make the contribution.
    3) And for people who do have money, they still have a contribution budget and so contributions to us come out of the pile for Doctors Without Borders etc.
    4) And the more extra loose money the WMF has the more chances for corruption -- I'm not talking about embezzlement or bribery, but rather featherbedding, nepotism, raising each others salaries, contributing to personal favorite charities, buying fancier equipment and furnishings than you need, taking trips you don't need to, increasing the headcount of your department, and just generally "staff expand to meet available payroll money". This is close to an iron law of people with extra money available. If the WMF is not subject to these behaviors they would be of nearly superhuman virtue and character, which I doubt. Herostratus (talk) 10:24, 28 August 2022 (UTC)
    @Herostratus I agree Staff capture is common :-( i was also amazed by how little the most famous open source charities exist on (see table above). I was trying to find out the value of the WP banner, and saw guesses of 1 to 2 Billion dollars Let's give a week each to each of our open source brethren - they are far better at most of the missions that the WMF has set for itself Wakelamp d[@-@]b (talk) Wakelamp d[@-@]b (talk) 03:53, 29 August 2022 (UTC)
  35. Strongly object The emails are deceptive to the point of dishonesty, and there is an inappropriate pressure put on previous donors to give more money. None of this is in the spirit of Wikipedia, and if it is not illegal for an organisation to obtain money by deception in this way, it should be. SilkTork (talk) 03:07, 29 August 2022 (UTC)
  36. Object for reasons stated above. Peter Damian (talk) 11:10, 29 August 2022 (UTC)
  37. Object for the reasons stated above. BilledMammal (talk) 14:11, 30 August 2022 (UTC)
  38. Object on the strongest terms. Wikipedia is not a poor organization that has to live on the lifeline of donations. They have enough money for Tide Foundation which engages in political left activities, but somehow they didn't have enough funding to fix things up. They do not need money to "continue to survive". With these emails, WMF didn't show proper respect to thousands of editors who are truly keeping the encyclopedia alive. For an organization that claimed to be "neutral" and "transparent", WMF surely is not showing them to be one. It is worthwhile to remember that Wikipedia is not ran by some suits in WMF headquarters, but it is ran by thousands of editors from around the world who is not paid. ✠ SunDawn ✠ (contact) 01:22, 1 September 2022 (UTC)
    This discussion is to review e-mails being used in Wikimedia's fundraising campaign. That they donate to a "foundation that engages in political left activities" is unimportant here and I wouldn't be able to tell by looking at your comment. "With these emails, WMF didn't show proper respect to thousands of editors who are truly keeping the encyclopedia alive", can you elaborate? I think it's reasonable to donate to an organization which supports rights for Black and LBGT people, as well as women. Many of our editors fall into these groups. But it's also hard to tell exactly what you're talking about, so I could be misinterpreting —VersaceSpace 🌃 02:56, 1 September 2022 (UTC)
    "With these emails, WMF didn't show proper respect to thousands of editors who are truly keeping the encyclopedia alive" is not aimed at WMF's donation towards Tides. It is aimed at how WMF seems to be "begging" for money, while not giving any assistance to the editors, who are the real backbones of the project. As for where WMF donated its money, I disagreed if they donated to any organization that is political, whether it is conservative or progressive. Tides clearly favor progressive political causes, which I do not think align with the neutrality principles of WMF. ✠ SunDawn ✠ (contact) 03:47, 1 September 2022 (UTC)
    It is reasonable for an indiviual to donate. But it is not reasonable for an orgsanisation to donate(especially if these organisation donate to Political parties), especially if there is a strong relationaship between directors, and officers and the company, and without the donors and volunteers being aware,
    At the moment the Tide Foundation (which controls the Endowment, and the knowledge fun) and WMF donate to each other, WMF CEO was CEO at grantee Tides Advocacy, and many WMF for Fraud due to WMF process issues Wakelamp d[@-@]b (talk) 04:17, 1 September 2022 (UTC)
    I'm not sure what that means, but I wasn't promoting Tides. Just was saying Wikimedia donating to political left orgs is not what the discussion is about. —VersaceSpace 🌃 13:24, 1 September 2022 (UTC)
    My point is that if WMF have the money to donate to other political organization, whether it is progressive or conservative, it is wrong and dishonest to portray themselves as "vulnerable" and "in severe need of your donation to continue operating". ✠ SunDawn ✠ (contact) 23:14, 1 September 2022 (UTC)
  39. Object The Wikimedia Foundation is at odds with the ethics and values of the Wikimedia community. Increasingly the Wikimedia Foundation is centralizing power and money into the control of people who are claiming the right to speak for the community without the community's input. There have been years of community objections to the nature of Wikimedia Foundation fundraising and years of community calls to decentralize the spending of the money collected. The normal and ethical way that the Wikimedia community operates is to make decisions with public, published discourse that has diverse participation from the global stakeholders, with special emphasis on the wishes of current and future volunteer content creators who have ensure the success of the Wikimedia Movement. If I am in error, then someone correct me by sharing the link to the discussion, but unfortunately I know that the Wikimedia Foundation has entered no such conversation. Donations are a US$200 million / year concern. This ethical issue is worth investment in public conversation and discourse. When the conversation does finally happen, let it be said that the Wikimedia Community called the Wikimedia Foundation to it repeatedly, and the Wikimedia Foundation declined to discuss. This is not a problem lacking a solution: the solution is a committed investment in ongoing community conversation about social and ethical issues in the Wikimedia Movement, and the sponsorship of community members and researchers to find compromise and consensus in the same. Bluerasberry (talk) 14:35, 1 September 2022 (UTC)
  40. Object to the dishonest wording of the emails. The WMF are not idiots, and should have been able to predict the backlash they are now receiving for this obvious affront to the communities that sustain its wikis. When they go ahead with this anyway, it should read taken as nothing less than an open declaration of their cynical intent. The gamification aspect is the most awful, like a parody of the barnstars that we use to recognise actual contributions to the project. --small jars tc 19:41, 3 September 2022 (UTC)
    Do we got any information on what sorts of gamification WMF would be doing? I know that the donors will receive badges, but what kind of badges? ✠ SunDawn ✠ (contact) 01:46, 5 September 2022 (UTC)
    Stinking badges ?  :-) Wakelamp d[@-@]b (talk) 01:54, 5 September 2022 (UTC)
  41. Object This is misleading and it's awful. It's the kind of thing I would expect in my spam email and not from a legitimate fundraiser from the WMF. Jimmy Wales is personally sending me an email to ask me to donate? No, he isn't. Also: I feel like I should mention that we often don't see how persistant these fundraising campaigns are when we're logged in editors. If you're ever browsing Wikipedia without being logged in when one of these are going on, you get the impression that Wikipedia is in dire need of support and that your financial contribution could make or break the world's access to knowledge. Like a lot of people, I make barely above minimum wage IRL and have enough to worry about. I think using these tactics undermines the ethos of the Wikimedia Movement in itself. Clovermoss (talk) 17:17, 4 September 2022 (UTC)
    I'd like to undersign this point about us not realising the intrusiveness of the banners to logged out readers, because I didn't until recently. Banner blindness can be strong but you absolutely cannot ignore these fundraising banners, even when you've donated. Very intrusive and give the (false) impression that donations are urgent or readers will notice consequences in changes to the site. — Bilorv (talk) 19:16, 6 September 2022 (UTC)
  42. Object --- not only "deeply misleading" as Yngvadottir rightly comments, but intentionally so. It masquerades as personal and emotional (starving children in the East African famine, anyone?), when in fact it's corporate and calculating. Wholly wrong. Chiswick Chap (talk) 08:03, 7 September 2022 (UTC)
  43. Object for at least three concrete reasons:
    Firstly, the percentages alluded to are ambiguous and potentially deceptive. I have no idea what the words "27% of your gift will give the Wikimedia Foundation the resources it needs to fulfill its mission" mean. Doesn't... all of the donation give resources to the WMF? What about "31% of your gift will be used to support the volunteers"? That wording is vague and misleading. The percentages should be removed, or at least edited to be more specific about where donations go.
    Secondly, adding badges to gamify the donation process seems like bad optics at the very least. It feels rather puerile. Wouldn't it be preferable to straightforwardly ask for donations without jeopardizing the sincere, serious message by tacking on a piece of digital tinsel?
    Thirdly, the insinuation that without donations Wikipedia would run ads and steal user data is wholly unjustifiable. This is base, guilt-tripping behavior that (in my opinion) has no place in a fundraising message. Focus should be placed on the benefit that the Wikimedia community provides to the world, not the threat of losing that benefit, or the threat of having that benefit poisoned by unethical practices. Perhaps it might be suitable to mention briefly, but the message is hammered in over each of the three emails. That, to me, is unethical.
    I also have concerns with the way that fundraising always harps on the financial instability of the WMF, as if it were perpetually on the brink of bankruptcy, when in fact it has been very financially successful. I don't know enough on that topic, however, so I will refrain from commenting unduly on it. I think Andreas has done magnificent work as a gadfly and muckraker, and, not yet having seen any strong defenses of the WMF's behavior, I will continue to voice my concerns in this space and in other locations until they are addressed.
    P.S. I assume the fundraising campaign has started already (unless I missed a statement to the contrary), so my comments are pretty irrelevant. Mere words are still important, though. I hope to see change come soon. Shells-shells (talk) 03:21, 9 September 2022 (UTC)
  44. Object Maybe successful but I don't think ethical Perrak (talk) 18:23, 13 September 2022 (UTC)
  45. Strong Object The fundraising wording is misleading and unethical, which still isn't OK if misleading and unethical appeals have become standard practice in the fundraising industry. The WMF should implement a total fundraising hiatus for at least the rest of 2022/2023, or clearly state at the beginning of the all appeals that they already have enough of money to keep the wikipedia.org online without ads for years without any additional fundraising. - GretLomborg (talk) 22:08, 14 September 2022 (UTC)

Neutral (WMF fundraising emails)Edit

  • Ambivalent, not neutral - Come on. Nobody's going to "endorse" fundraising emails on Wikipedia. There are going to be people who strongly object, people who don't care, and people who have mixed feelings. File my !vote under the latter.
    Yes, the language of the fundraising emails is more like a fundraising email than something you'd see on Wikipedia. In that way it's not so different from the fundraising messages I get on a daily basis from various other organizations. I'm certainly not going to endorse how my local public radio station regularly tells me that without my donation, their programming wouldn't be possible, or when other nonprofits tell me some terrible political injustice will happen if I don't donate today. They have to balance what works with what's in line with the philosophy of the organization. In these emails I see the standard use of exaggeration and cultivated urgency that I see in many other organizations' emails. It's jarring when juxtaposed with what's said within the Wikipedia community, but they don't strike me as being contrary to the philosophy of Wikimedia/Wikipedia outside of that exaggeration. I also don't have a problem with gamification (the badges) which, again, is ubiquitous and doesn't strike me as fundamentally in conflict with the Wikimedia spirit.
    The reservations I have are mostly bound up in that breakdown of where the money goes that others have highlighted. Like some others I suspect my skeptical reaction is based less on any specific figure than on various historical frustrations regarding the foundation's allocation of funds (and/or lack thereof). So I find myself ambivalent, and curious to dig further into those figures in the email copy.
    I do think it's important to draw a distinction, however, between how the fundraising department does their job and how the funds it raises are spent. One shouldn't be a proxy battle for the other, although I wouldn't blame anyone for feeling like they don't really have a voice regarding allocation, but may have a voice about what happens on the wiki.
    TL;DR - The $ breakdown made me raise an eyebrow, but I think that's more about the debate over allocation of funds than the wording of these emails, so I'm ambivalent. — Rhododendrites talk \\ 19:26, 15 August 2022 (UTC)
    @Rhododendrites: See m:Talk:Fundraising#Discussion_of_the_India_emails for a WMF response on what the 31% (or 32%, as it was then) is supposed to represent. Andreas JN466 19:59, 15 August 2022 (UTC)
  • Mixed, not neutral This is rather weird phrasing - ultimately it's a fundraising email. Additionally, your formatting is flawed - you are encouraging a combined up/down consideration, as opposed to per email. For example, I quite like email 3, and I could survive email 1 with no great worry on my mind. The things I dislike (badges, suggestion we are not succeeding on fundraising by not yet meeting the goal, a statement that Jimmy has been anti-ads for all 21 years) are all on email 2. Remove email 2 (it's such a wide set of issues I don't think trimming is the way to go) and the complaints lapse. Nosebagbear (talk) 12:43, 16 August 2022 (UTC)
    I agree with your comments on email 3. Email 3 seems to have the tone most consistent with the WMF's goals and mission. 2601:647:5800:1A1F:40D5:8B1F:2BD2:8163 (talk) 01:12, 20 August 2022 (UTC)
  • Mixed. First of all, I applaud the WMF for allowing community review of the emails in advance. (This is great progress!) Regarding the content: I find the first two texts to be very problematic, and the third... contains certain issues which are endemic in WMF communications (eg, vaguely identifying its work with Wikipedia's own success), but which I don't think it's urgent to deal with within the next two weeks before the emails are to be sent. I would be quite happy if email 3 were used, and emails 1 and 2 were replaced with a similar style (ie, without misleading content, unnecessary alarmism, blatantly false statements about spending, etc). I hope this is achievable. --Yair rand (talk) 06:52, 22 August 2022 (UTC)
    @JBrungs (WMF): This sounds like a sensible way forward to me. Could you please inquire? Andreas JN466 09:47, 23 August 2022 (UTC)
  • Mixed, this is from WMF not Wikipedia. Whatever happens here will be overturned by WMF. – The Grid (talk) 22:44, 22 August 2022 (UTC)
    Bilorv mentioned above that if the WMF send the emails as they are anyway, we should contact the news media and offer to be interviewed. I think that is a good idea – it doesn't take more than a statement by email. Andreas JN466 09:45, 23 August 2022 (UTC)
    Great idea. CactiStaccingCrane (talk) 09:47, 23 August 2022 (UTC)
    Or we could just add a template on all articles saying that the email does not reflect the views of the WP editors.:-) Wakelamp d[@-@]b (talk) 10:26, 23 August 2022 (UTC)
    Well, we had had enough. If the WMF had't listen to us for years, we will eventually have to do something about it. Hopefully things will go alright this time. CactiStaccingCrane (talk) 10:33, 23 August 2022 (UTC)
    WP:WMFThe Grid (talk) 18:49, 23 August 2022 (UTC)
    Do we need our own separate Wikipedia Board? Wakelamp d[@-@]b (talk) 11:18, 24 August 2022 (UTC)
    Something I was thinking about was people potentially writing and publicizing essays, but potentially doing interviews (and any other thing for that matter) is a good idea. Sending objections to the WMF won't have an impact if they don't have an incentive to respond to community concerns. —Danre98(talk^contribs) 19:03, 23 August 2022 (UTC)
  • Meh I think the editors in this section make the most compelling arguments, particularly Rhododendrites and Nosebagbear. It's a fundraising email, not a manifesto. Wug·a·po·des 22:27, 23 August 2022 (UTC)
  • Mixed The WMF won't suddenly stop asking for donations and that means being persuasive during fundraising. Not bad in itself. However, it is a problem to state erroneous claims that Wikipedia may go offline, or not saying that WMF is not volunteer-run, etc. A little honesty is needed. Yes, this might mean that donations won't exceed expectations, but the Foundation needs to accept, sooner rather than later, that donations won't continue to massively increase forevermore. Dege31 (talk) 15:58, 2 September 2022 (UTC)

Talk to the media if the WMF launches the campaign anywaysEdit

If the WMF launches the predatory fundraising mails without changes mentioned in the Review of English Wikimedia fundraising emails thread, we should sent tips to newspapers about this issue. The emails will be sent by September 6, and a lack of response from a WMF representative is very concerning to me. I know that this sounds a bit over the top, but based on the fact that the community's overwhelming rage almost did not overturn the WMF's Fram's ban, it is likely that the WMF will not change their fundraising strategy or even talk to us without drastic action. CactiStaccingCrane (talk) 17:32, 27 August 2022 (UTC)

I thought you were against the nuclear options? Wakelamp d[@-@]b (talk) 08:07, 28 August 2022 (UTC)
@Wakelamp: Hmm ... what do you propose to do if the WMF launches the campaign anyway, with the email texts as they are?   Andreas JN466 09:11, 28 August 2022 (UTC)
I don't think they will send the letter as is
Instead WMF may do the following,
  1. Reach out to large donors and charity rating firms, and frame this as Morlocks refusing to obey the [[Eloi]'s charter. They will emphasise that they have a 100 % scored feedback process which they will improve "collecting feedback from the constituents and/or communities it serves." with the wiki wishlist as an example
  2. Go Public first. The CEO will send a letter saying that the letter was a draft, and that they were reaching out to the community as part of a review, The will say that emails were written by someone who has left, but it is wonderful to have this chance to renew,
  3. Change the letter (just enough to pacify us),
  4. Ensure that their fundraising staff are trained on editing, edit, and report back how awful we are
  5. Create a new wide Wiki wide community consultation process, to stop us doing the same,
  6. Set up a committee of external experts and public fighters for diversity or free speech. The committee will report back that changes are needed, but the charity is at risk becuase of our lack of diversity and bullying, and our lack of commercial acumen, but that we are good people,
  7. Think about creating a secret WMF project to see if they could block option 2.
  8. Contact their PR firm (see page 8 of IRS 990) (Minassian Media Ny, Ny $319 K pa, to create an approach and ther advertising company Swift Possible LLC Po,OR $ 461 K pa),
  • Do a push poll on the donation form, or public polling
So, to encourage WMF to change the letter
We understand that you are in a bit of a perfect storm ; NPP complaints, elections, fund raising, structural issues within WP to do with lack of resources, general global anger, WP long term decline in behaviour, and your policies
Frankly we probably wont do option 1 as it is ineffective, but we could think about improving connectivity (new editors to old, intrawiki, with open source, with WMF, within projects) so that we are able to respond/mobilize to WMF. And option 2 is worthwhile looking at so that we can put controls in place Wakelamp d[@-@]b (talk) 10:19, 29 August 2022 (UTC)
User:JBrungs (WMF) briefly contributed to the above discussion a week ago, and I pinged her six days ago with a request to inquire with her managers whether changes to the emails could be made. Given that we have not heard back from her, I think it is safest to assume that the discussion here has fallen and will continue to fall on deaf ears at the WMF. It is, after all, hardly the first time such concerns have been raised. Best, Andreas JN466 10:50, 29 August 2022 (UTC)
I am concerned about jbrungs because of what WMF might decide to do.
The fundraising issues have been raised before. But the community has to decide whether to do anything or not, or just to forget till next year - but our readers don't have the option of turning off their banners. (You should see my option 4, and 5) :-) Wakelamp d[@-@]b (talk) 13:25, 29 August 2022 (UTC)
Julia has always been helpful and kind. Obviously, none of these decisions are hers; she's just doing her job as a community relations contractor. Andreas JN466 13:34, 29 August 2022 (UTC)
My concern is doubled as she is a contractor. I really do think it's a perfect storm, and it's a management issue. She is not allowed to talk to use becuase of non-disclosure agreement, and is not covered by https://foundation.wikimedia.org/wiki/Whistleblower_policy, I can't find their standard employment contract, or the policy for WMF staff interacting with WP editors Wakelamp d[@-@]b (talk) 14:23, 29 August 2022 (UTC)
Remember that anyone can talk to the media anyway, without asking permission here. Phil Bridger (talk) 11:00, 28 August 2022 (UTC)
Yeah and to add to that, talking to the media is not "the nuclear option" or even "a bit over the top." No one should think that keeping our problems "in-house" or "quiet" is somehow noble. The readers, the donors, the entire world needs to know what happens here. They spend over ten million dollars a year on fundraising. They raise over a hundred million. They spend tens of millions of that money each year buying stocks, bonds, $20 million in mortgage-backed securities. Anyone know what's in their hundred-million-plus investment portfolio besides the mortgage backed securities? Fossile fuel companies? Pharmaceuticals? Defense contractors? I have no idea, they don't say. And the Endowment? I don't know where that's being invested either, it's not even being invested by the WMF, it's handled by Tides. Last year (2020-2021) they didn't even spend $47 million they raised. The year before, they gave $9 million to Tides for the "Knowledge Equity Fund"-- where did this money go? Don't know. In both years (19/20 and 20/21, the only years I've looked at closely), they gave more money to Tides than all other grantees combined. And today I learned the WMF is open about giving grants to sitebanned editors (check the WMF pump discussion). Meanwhile they're simultaneously telling donors that we'll get shut down if they don't donate. WMF fundraising is 100% a scam and any journalist (or anyone else) who wants me to point them to the documentation for everything I just claimed is welcome to ask at my talk page. Levivich 14:45, 29 August 2022 (UTC)
I agree, going to the press is not the nuclear option. Here are the Google Trends for scam ,bias, wrong, diversity, fundraising How Wakelamp d[@-@]b (talk) 15:24, 2 September 2022 (UTC)
But which press is interested? With many more interesting headlines today, I don't see any media willing to take up the news. ✠ SunDawn ✠ (contact) 15:58, 2 September 2022 (UTC)
Part of the problem is that not many people seem familiar with the difference between Wikimedia and Wikipedia, so "Wikipedians angry with Wikimedia foundation" makes for a confusing story. small jars tc 21:18, 3 September 2022 (UTC)
  • Just going to ask if anyone has, you know, emailed (rather than pinged) Julia asking for a 1-2-1 zoom call? I did last year and she arranged within a week - while Julia almost certainly needs to be more aggressive in funding efforts than we would like, due to the goals set through the AP, she's also more responsive (not to mention friendlier!) than the discussion (and violation of AGF (yes, believe it or not, it applies to Foundation employees too, whatever some may do in practice)) here seems to be. Nosebagbear (talk) 11:04, 30 August 2022 (UTC)
    @Nosebagbear: Julia is simply a community relations contractor, not a decision-maker. As for WMF board/management – as Sänger said the other day over on Meta-Wiki, these sorts of discussions should be public so the community can see what is done and has a chance to weigh in. Lastly, it should be clear to everyone here that the decisions that govern the WMF's fundraising conduct are taken by the WMF Board – not any WMF executive, employee or contractor. Andreas JN466 11:32, 30 August 2022 (UTC)
    Also, as an afterthought: Did your call actually achieve anything other than giving you the feeling that you had been given some personal attention? If so, please let us know what changed as a result of your call. --Andreas JN466 11:39, 30 August 2022 (UTC)

Anybody happy to do a TV interview?Edit

If you're in the States and would be happy to speak on camera about your concerns about the fundraising emails, as discussed above, please drop me an email. Cheers, --Andreas JN466 20:24, 2 September 2022 (UTC)

The interest level seems low :-(
https://trends.google.com/trends/explore?date=all&q=%2Fm%2F01c7j1,%2Fm%2F0fqw_s,%2Fm%2F02k9dy,wikipedia%20scam,wikipedia%20fundraising Wakelamp d[@-@]b (talk) 04:53, 3 September 2022 (UTC)
Not as low as you think.   Try [11] Andreas JN466 07:19, 3 September 2022 (UTC)
Fun fact: Nigeria is the only country on that Google Trends page where "Wikipedia money" outstrips "Wikimedia Foundation". ;) Andreas JN466 07:23, 3 September 2022 (UTC)
Top 20 news articles mentioning WikipediaEdit

User:SunDawnUser:SmallJarsWithGreenLabels Your concerns about whether the media would be interested, or would understand made be interested to find out what the media was interested in. So

Topic BBC Guardian New York Times Google News
Anniversary 1 1 1
Conservapeia/Daily Mail 2 1 1
Doomed/Knol/Mobile 2 0.5
Edited by politicians/Businesses 2 1 2
Editing Rules 1
Editors are Biased/Diversity/Male/OCD/Crazy 1 6 8 2
Editors are People 1 1
Editors are Noble Tireless Volunteers 2 1 1
Editors are Toxic 2 1 `
Editors are warring bots 1 1
Editors were tricked 1 4
WMF Endowment 1
WMF Fundraising/Donors 1
Interesting Articles/Top N 1
WMF Legal (Sued /Right to be Forgotten 2 1 1
WMF and Nation Censorship 8 3.5
Not reliable (but used by authority figures) 3
Statistics 1 1
Vandalism/ClueBot/Sneaky Vandal 1 1
WP Blackout 1 3
WP Tech 1
WT Social 1
WMF Press ReleasesEdit

This table shows en posts/press releases on WMF using the WMF's own tags. THere ar about 750 posts, but some can have more than one tag. but some posts should have also had additional tags. The press releases that seem to get traction in the News, (and I assume with large donors) are Top Lists, WMF fighting for truth, Editors are not diverse, and WMF fighting against Nation States.

Category Press Releases
Foundation 284
From the Archives 283
Wiipedia 158
Legal 96
Technology 90
Wikimedia commons 65
Events 48
Affiliates 40
Advocacy 36
Endowment 31
Research 30
Advancement (fundraising) 26
Wikisource 26
GLAM 25
Profiles 24
Blog Transistion 21
Wikiata 19
Wikipedia vs NSA 19
Photo contests 18
Wikimania 17
Grant making 14
Wikipedia Library 10

Is this a yearly thing? What changes are needed?=Edit

There are yearly complaints about fundraising texts increased after the Strategy change in 2012. Do editors just want a change to the 2022 or 2023 letters? Wakelamp d[@-@]b (talk) 00:02, 24 September 2022 (UTC)

Report on the above poll sent to the Wikimedia-l mailing listEdit

See [12] --Andreas JN466 15:27, 4 September 2022 (UTC)

The only response from anyone at the WMF that I am aware of has been a post on Hacker News by what would seem to be a WMF Movement Communications Specialist asking another commenter whether it isn't true that "the number of editors who take umbrage with the wording is a small minority of the tens of thousands who edit and thousands (hundreds?) who are aware of the fundraising messages?"
I see no reason to assume that the emails won't go out with the wordings above. --Andreas JN466 17:04, 6 September 2022 (UTC)
If anyone has had one of these emails yet, please let me know by email. Andreas JN466 16:37, 12 September 2022 (UTC)
Well, the emails have gone out, and as expected, they still have the wording above, about donating money "to keep Wikipedia online for yourself and millions of people around the world", the "awkward to admit" bit etc. Andreas JN466 15:26, 14 September 2022 (UTC)

Discussion on Hacker NewsEdit

See [13] --Andreas JN466 08:01, 5 September 2022 (UTC)

The WMF does NOTsee the Village pump/Admin/editors as representative of the WMF community, so questioning legitimacy is to be expected. They also don't see us as representative of readers ,and also based on the hacker news comment as no threat.
Anyway, The current emails are not in line with WMF resolution 9th October 2010. "Transparency: All Wikimedia fundraising activities must be truthful with prospective donors. We need to tell people what we intend to use their money for, before they donate. And we need to report in a timely fashion on how it was actually spent ".
But I think it is important to note that it doesn't work like editing - references don't count At the moment, we are quite powerless becuase of the changes to the By-laws (especially for affilaites) , and the resolutions to do with the endowment. I am stunned to what the board has agreed to, often with the best of intentions, but each time ceding more of it's power to the CEO and to the Tides Foundation / Clinton Foundation) and George Soros Wakelamp d[@-@]b (talk) 15:02, 9 September 2022 (UTC)

BannersEdit

The current banners

 
on desktop

are invasive, but if you page down you get this

 
banner

.

As an example, In India, the fundraising amount asked for is ₹150 or about US$2.50. So, to get rid of the banners take about a 1/3 to a 1/4 of a days wage.(See India'sMedian income, otherwise... So,WMF have raised from 2010 to 2020 WMF received 2 Million dollars from India.They received some complaints in 2020 and responded thus — Preceding unsigned comment added by Wakelamp (talkcontribs)

Mass creation of pages on fish speciesEdit

I was told through a talk page message to come here and submit this as a proposal even though it has been an ongoing process for a few months. I have been creating large numbers of pages on fish species and most of them are very short due to the relative scarcity of information on many of these species. I was informed that what I have been doing is considered "bot-like editing", so I am posting this here since apparently it needs to be discussed. I should note that I started this process back in December and this is the first time I have been notified that it is bot-like in nature, so this is the first time I am posting about it here or in any similar location.

I apologize if I am not carrying out this proposal process correctly as I am rather new here and frankly still a bit confused about this whole thing. This is not really a proposal, but I was told to verify that there is a consensus for creating such pages before continuing to do so. Lumpsucker (talk) 16:30, 30 August 2022 (UTC)

WikiProject Tree of Life and WikiProject Fishes have been informed of this discussion. BilledMammal (talk) 02:55, 31 August 2022 (UTC)
Thank you for bringing this here. To provide some context, I noticed that Lumpsucher had been engaged in the mass creation of articles on fish, and requested that they seek consensus for this, here or at another suitable location, as mass creation requires an affirmative consensus per WP:MASSCREATE and to avoid creating WP:FAIT issues.
Of these articles, the majority are small, near-identical articles (eg, Hypostomus brevis, Hypostomus argus, Hypostomus johnii, Hypostomus agna) that I believe are better suited as entries in a list than as stand alone articles. BilledMammal (talk) 16:41, 30 August 2022 (UTC)
  • I said in a recent discussion about dam articles that instead of stand-alone pages, it's better to have lists of dams. Same here. Pages like Hypostomus brevis, Hypostomus argus, Hypostomus johnii, Hypostomus agna would be better off if they were either listings in a table, or sections, of Hypostomus. One of the reasons is context: Hypostomus brevis doesn't tell me that this particular species of catfish is one of 100+ species of Hypostomus. It says brevis is 7.4 inches but I don't know if that's big or small for a Hypostomus species. It tells me that brevis is in the Parana River but it doesn't tell me if all these catfish in the Parana, or just rivers, or just South America, or what. Hypostomus gives me way, way more information -- even about the brevis specis -- than Hypostomus brevis. That's why it's better to combine these one- or two-sentence stubs about list entries into one list. Levivich 16:56, 30 August 2022 (UTC)
    • Adding: for me it's not about WP:GNG--named fish species will likely meet GNG--it's about WP:PAGEDECIDE: even if the topics are notable, the brevity of the article content means "listification" will provide the reader with more information and context than stand-alone pages. Levivich 02:13, 31 August 2022 (UTC)
  • Support creation of articles on fish species. There is consensus that they are notable and short articles on species have been accepted for a long time. BeanieFan11 (talk) 17:01, 30 August 2022 (UTC)
    This is why I have been doing it this way and not through lists. These sorts of articles have been the convention for quite some time as far as I know and I have yet to see a genus article where information on the species is presented in the form of a list. Lumpsucker (talk) 17:19, 30 August 2022 (UTC)
  • Agree completely with Levivich. I think we're all aware of WP:SPECIESOUTCOMES here, which suggests species-level articles are typically kept. But to the question of what should we do: I think tiny stub articles serve our encyclopedic purpose poorly (per Levivich's points above). A more helpful way to include this information would be to host it at whatever taxonomic level we can support a half-decent well-contextualized encyclopedia article. In some cases that may be the genus; in others an even-higher order taxon. It just depends on how well-covered the organisms are in sources. Some flexibility may be required, as we're aiming to create a high-quality encyclopedia here, not a rigid rule set for where to host each tidbit of information. Ajpolino (talk) 17:12, 30 August 2022 (UTC)
  • Oppose mass creation of stub articles, on fish species or otherwise. Agree with Levivich and Ajpolino (especially the "quality over quantity" point) and would add that the guiding principle should be this: database entries alone are insufficient to support an encyclopedic article, whether that database is of actors, fish species, geographic features or some other group. Remember that the notability guideline requires 'significant coverage," and databases do not provide this. I suggest that at a minimum the creator add as a reference the scientific paper in which the species was described (and maybe even some of the information from said paper). UnitedStatesian (talk) 17:29, 30 August 2022 (UTC)
  • Support article creation We have precedent for creating species articles and guidelines confirming the appropriateness of this. That said, we could revisit the subject with a broader discussion. If anyone wants to start that discussion, they are going to have to do some background work. Things that I would expect to see are 1) list of previous discussions on this topic and 2) some summary of the previous discussions. I estimate this to be 1-2 hours of preparation for a good new discussion. Even with a new discussion though, I personally would not expect the community to reverse the precedent, because new technology is making information, data, and media more accessible at scale. I acknowledge that stub articles are problematic if they were to persist indefinitely without development, but my feeling is that we can reasonably expect good development of these articles soon. It has been some years since the project was active, but previously I contributed to the commons:User:Open Access Media Importer Bot which, among other things, pulled photos of species from open access scientific journals for upload to Wikimedia Commons. Some of those images are at commons:Commons:Open Access File of the Day. Technology for doing such activity has gotten much less expensive in the 10 years since that import project was running, so I expect something similar to happen eventually. Because of this, I do not see stubby Wikipedia articles as a problem, because I see them getting more content within years, and translated into other Wikipedia language versions not long after that. Bluerasberry (talk) 17:34, 30 August 2022 (UTC)
  • Oppose The community has become wary of mass stub creation ( as these seem to be) even if in the past such stubs were acceptable. a far better solution would be to expand the...famiky? pages (the level just above species. then you can have searchable redirects to these. when a non stub species article can be created, just add the link then. User:Masem 18:25, 30 August 2022 (UTC)
    Genus, King Philip Could Only Find Girl Scouts Andre🚐 20:09, 30 August 2022 (UTC)
  • Oppose. I have been guilty of this exact thing in the past (cfe. Synapturanus ajuricaba) but I believe that we should stop the mass creation of stubs in the future. If a genus has no associated species articles, then try covering all the species in sections on the genus article and split out the most substantial sections into their own article. casualdejekyll 18:38, 30 August 2022 (UTC)
  • I see nothing wrong with this user's creations. I wouldn't even call it "mass creation"; the user is averaging two articles per day (since the first day the user created an article) on subjects that are all notable (and articles like these have had consensus for a long time). BeanieFan11 (talk) 18:41, 30 August 2022 (UTC)
    The problem isn't as much the quantity of the articles as the quality of the articles. They're stubs. Sourced stubs, sure, but if they weren't on such an obviously notable subject they don't have the sourcing to show the notability. casualdejekyll 18:50, 30 August 2022 (UTC)
    An article being a stub is not a problem. BeanieFan11 (talk) 18:52, 30 August 2022 (UTC)
    An article being a stub that does not pass GNG is. As UnitedStatesian said, database entries alone are insufficient to support an encyclopedic article. casualdejekyll 18:53, 30 August 2022 (UTC)
    Not all subjects have to pass GNG. NPOL, NPROF (I believe), and NSPECIES only require that subjects (that meet the criteria) need to be verifiable, which is the case with the articles this user is creating. BeanieFan11 (talk) 18:59, 30 August 2022 (UTC)
    only NPROF does not require any long term requirement to show GNG type presumed notability. NSPECIES is a general outcome and NOT an SNG Masem (t) 19:15, 30 August 2022 (UTC)
    That's kind of the issue at hand here I think. If they don't pass GNG they should be merged into a list. Andre🚐 20:01, 30 August 2022 (UTC)
    they pass GNG every species is written about in multiple sources independent of the subject. Gnangarra 10:46, 31 August 2022 (UTC)
  • Question: how does this fit into Wikispecies? Looking at a typical example Hypostomus multidens vs Hypostomus multidens. Wikispecies has about 800,000 pages which is more than 10% of Enwiki, in case the idea is to allow every page Wikispecies have a twin at Enwiki per WP:SPECIESOUTCOMES. -- GreenC 18:54, 30 August 2022 (UTC)
    Great point. Maybe they should go there. Andre🚐 19:59, 30 August 2022 (UTC)
    Wikispecies is, from what I've heard on WP:DISCORD, widely considered to be a ghost town and redundant to Wikidata. To use an analogy to another group of related things where there are clear winners and losers, Wikispecies is the Michigan's Adventure to Wikipedia's Cedar Point. casualdejekyll 23:05, 30 August 2022 (UTC)
    That's a shame, it had a really cool logo Andre🚐 23:06, 30 August 2022 (UTC)
  • Oppose If there is only a line or two to say, they are better as a section or in a list at the genus level. Johnbod (talk) 18:56, 30 August 2022 (UTC)
  • I agree that WP should cover these species… BUT… that does not mean we should have separate stand alone articles for each of them. If all we can say is one or two lines (effectively noting that they exist and not much else) then we should cover them in section or list within a larger, genus level, “parent” article. Blueboar (talk) 19:06, 30 August 2022 (UTC)
    Good idea. Andre🚐 20:00, 30 August 2022 (UTC)
  • I don't think an RFC has been started, but I am of the opinion that we do not need sub-stubs for subjects for which GNG has not been met. I think it is best to incorporate what information can be reliably sourced about those subjects into higher-level articles. - Donald Albury 19:52, 30 August 2022 (UTC)
    I concur with Donald Albury. I don't know a lot about ichthyology, but when it comes to plants, there are a ton of variations. So we don't need every article on a ficus. I count about 10 red links on the ficus page. Maybe all the ficuses (fici?) will eventually be written about, but possibly not, and that's totally OK. We should only write about species that have significant coverage in the published reliable work. Andre🚐 19:59, 30 August 2022 (UTC)
  • Oppose, as said by multiple people already, these are better covered in a single article. Agree with Blueboar, the "topic" is still covered in the encyclopedia, just not with a separate article. The same goes for many other things in addition to minor species. MB 20:03, 30 August 2022 (UTC)
  • WP:PAGEDECIDE leans against creating stubs when a broader article would serve readers better. Slywriter (talk) 20:36, 30 August 2022 (UTC)
  • Comment: I think User:Casualdejekyll outlines exactly the right approach. Start by creating larger articles with sections, then divide out the sections as sufficient content develops. BD2412 T 21:35, 30 August 2022 (UTC)
  • Support this creation of stub articles for species. This user is not using an automated bot, nor a creation rate to be considered as "mass creation". Using biological databases as references is valuable as an indicator of peer-reviewed secondary sources of the species notability - not like a sports almanac of trivial facts. Now, do I think a stub should be created for every species? Probably not, it would be impossible for a start. Many genus level articles could more readily summarize all the information for their species than a series of stubs. But for a topic such as fish, with many active editors, it is not inconceivable that someone else may come along and add an image or other information that will grow the article, although maybe not for 5-10 years. In the long-term approach (that is measured in decades, not months), species stubs are an asset and not something to be dissuaded from creating.
The present creation of species stubs is well within established consensus and I would expect any serious proposal to attempt to reverse this be presented with both the proper background preparation (as detailed by Blueraspberry above) and a wide prior notification within the WP:TOL (Tree of Life) projects. Loopy30 (talk) 22:50, 30 August 2022 (UTC)
Mass creation doesn't need to be at bot speed to be a problem. Masem (t) 23:11, 30 August 2022 (UTC)
We would expect pre discussion of mass creation to be at a community wide location like WP:VPP. Wikiprojects are in general too insular for mass creation (though are a good first check). Masem (t) 23:25, 30 August 2022 (UTC)
The present creation of species stubs is well within established consensus - could you link that consensus for me? As far as I am aware, no such consensus exists. BilledMammal (talk) 23:29, 30 August 2022 (UTC)
Listed in WP:OUTCOMES for a good decade now (see shortcut WP:NSPECIES); and I went through the entirety of the past 6.5 years of AfDs listed at Organisms deletion sorting archive and cannot find so much as a single AfD that involved an actual, valid, non-fictional species being closed as delete (individual plants/animals, plant cultivars, cannabis strains, breeds of domesticated animals, "dubious" and invalid taxa, fictional species/cryptozoology stuff, etc.? Sure. Actual valid species? Nope. Not as much as one of them in the past 6.5 years) or even no consensus.
Of course it's possible that if a discussion happens, it turns out to show that consensus has, in fact, changed--but as things stand, there absolutely is plenty of evidence of consensus for the keeping-by-default of valid species articles. From that, it logically follows there is consensus for creation of valid species articles, too. AddWittyNameHere 01:31, 31 August 2022 (UTC)
using OUTCOMES to support mass creation is absolutely the wrong approach (its circular reasoning) Masem (t) 01:40, 31 August 2022 (UTC)
No, circular reasoning would be if I stated "this sums up that such articles are generally kept; therefore we shouldn't delete this specific example of it". What I'm saying is "this sums up that such articles are generally kept (and evidence shows that summary to remain correct even when it comes to the current state of things); from this follows that there is at utter minimum an implied consensus for the existence, and therefore creation, of such articles."
I don't disagree it could be a good idea to confirm whether that implied consensus is, indeed, still the wider en.wiki consensus. But it's not circular reasoning to recognize that, up until this discussion where the implied consensus was challenged, such consensus was effectively in place. AddWittyNameHere 01:54, 31 August 2022 (UTC)
I believe it is very unlikely that a proposal to create a guideline granting presumed notability (and an exemption from WP:NOTDATABASE) to species would find a consensus; given this probable inability to get a formal consensus, I cannot see an implied consensus.
I would also note that we're not discussing individual article creations; we are discussing mass creations. Actions taken at scale can be problematic and against consensus even when smaller number of actions would not be - for example, creating stubs on five WP:GEOLAND-compliant locations is not an issue, but creating stubs on 5000 is. BilledMammal (talk) 02:11, 31 August 2022 (UTC)
we are discussing mass creations - Are we, though? I'd argue that 2-3 per day (as seems to be pretty much the average in this case) fits perfectly into Alternatives to simply creating mass quantities of content pages include creating the pages in small batches right from WP:MASSCREATION. AddWittyNameHere 02:22, 31 August 2022 (UTC)
Yes; the relevant line is While no specific definition of "large-scale" was decided, a suggestion of "anything more than 25 or 50" was not opposed. - Lumpsucker has created hundreds of near-identical articles on fish. BilledMammal (talk) 02:32, 31 August 2022 (UTC)
The problem with that line is that it is so imprecise as to be entirely useless: it gives absolutely no strictures other than a vague indicator of number. It doesn't say they have to be stubs. It doesn't say they have to be on similar subjects. It doesn't specify in what time-span.
If we want to apply that line as-is, practically every content creator who has been around a while is a mass-creator by default, regardless of the quality, subject or frequency of their articles. We have over 10000 editors with at least 68 non-redirect mainspace page creations to their name. I highly doubt the intention was that they'd all be deemed mass creators who'd need prior approval before creating more articles. AddWittyNameHere 01:50, 1 September 2022 (UTC)
For what it's worth, the just-opened RfC on mass-creation currently says "Rapid and/or mass creation/deletion" refers to more than 25 per day, with a note the definition may need workshopping during the RfC. By that definition, Lumpsucker very much is not engaging in mass-creation. AddWittyNameHere 01:56, 1 September 2022 (UTC)
WP:OUTCOMES is not one of Wikipedia's policies or guidelines, as it has not been thoroughly vetted by the community. It's not an WP:SNG (which are guidelines). Levivich 02:03, 31 August 2022 (UTC)
  • Support the "mass" creation of species stubs with the proviso that at least one non-database RS is used as a reference. As an example, I found a source for Hypostomus agna and added some tidbits of info, such that now the species article contains information beyond what is given in the genus article. The substub->stub conversion took less than 5 minutes. I've written hundreds of stubs on lichen species and intend to continue doing so until there's one for each of the 20,000 or so lichens. Esculenta (talk) 01:12, 31 August 2022 (UTC)
  • Question Can anybody point me to some previous examples where editors have requested consensus/permission to mass create articles in a semi-automated way? I realize that is what WP:MASSCREATE calls for, but it's not something I'm aware of being followed in practice.Plantdrew (talk) 01:24, 31 August 2022 (UTC)
@Plantdrew: The essay Wikipedia:Bot-created articles has links to relevant history here. Particularly for plants and animals, you'll typically find that Lsjbot has mass created stubs in other languages already for many species. In practice, I think the answer is that automated creation of articles is more or less not done on English Wikipedia anymore? Steven Walling • talk 01:49, 31 August 2022 (UTC)
@Plantdrew: Wikipedia:Bots/Noticeboard#Dams articles Levivich 01:58, 31 August 2022 (UTC)
That was the one and only time that was done (at least that I can recall). BeanieFan11 (talk) 02:04, 31 August 2022 (UTC)
I found some examples in the BRFA archives (1, 2, 3, 4, 5, 6). –xenotalk 02:12, 31 August 2022 (UTC)
Every one of those editors, like Lumpsucker, deserve our thanks for seeking community input on this. Levivich 02:44, 31 August 2022 (UTC)
Xeno, thank you for digging up those examples. Those are all seeking permission for fully automated article creation. I assume Xeno would have discovered any requests for approval for semi-automated article creation, and by absence of examples, no such requests exist (aside from the recent case for Japanese dams). Plantdrew (talk) 15:32, 31 August 2022 (UTC)
Because WP:MASSCREATE says Any large-scale automated or semi-automated content page creation task must be approved at Wikipedia:Bots/Requests for approval, I don't think the automated/semi-automated distinction is relevant. Levivich 17:58, 1 September 2022 (UTC)
  • Support Animals and plants that have references to a species description are notable because there is plenty of highly reliable source material about them, even if the initial stubs are usually small. To get an accepted species description, a scientist typically has to go through peer review and have the description presented in an academic journal. An accepted species description is arguably even more reliable than say, census data used to populate stubs about tiny towns or census-designated places, and it's really easy to create one or two of these stubs manually every day once you know where to find the free online science databases and/or get a few books handy. In addition to the original species description, most of these are also covered in other reliable sources like monographs about a particular genus. Most of these scientific papers, even for rare and endangered species, are easily findable via Google Scholar or JSTOR if you search for the scientific names. TL;DR: Since there are almost always multiple highly reliable sources exclusively covering the subject these species pass the basic test of notability. Steven Walling • talk 02:08, 31 August 2022 (UTC)
    I think this argument is persuasive to a point. However, some old genus and species names have been around for a while and usually there isn't much information about them. Right? I mean could you break down a couple of really obscure fish for us? Or how about those red-linked ficus? Andre🚐 02:16, 31 August 2022 (UTC)
Ficus is one of the largest genera of plants on the planet, and there are quite a large number of scientific papers and whole books written just about various species within it. We could most definitely create reliably sourced articles about almost all of them. Just like with all subjects though, if we can't find enough source material... then don't. Each article has to be considered on its own merits, but to propose that we categorically can't have stubs about individual plant and animal species is just plain wrong when you look at WP:N and more than a decade of discussion at AFD. Steven Walling • talk 03:20, 31 August 2022 (UTC)
I didn't say we can't have stubs, but many of these are substubs. An article needs to say why it's important and why we should care, IMHO. Andre🚐 03:34, 31 August 2022 (UTC)
  • I just did a search on JSTOR and Google Scholar for the first fish I mentioned, Hypostomus brevis. There were some passing mentions, but no WP:SIGCOV. In addition, WP:N isn't the only reason these articles are problematic; WP:NOTDATABASE also applies.
    We also need to consider the interests of the reader. Even for the ones that are notable, readers are better served by the inclusion of content at Hypostomus than they are by a standalone micro-stub. BilledMammal (talk) 02:23, 31 August 2022 (UTC)
A Google Books search shows several mentions of that species in books (significant coverage doesn't have to be in sources you can read for free online after a cursory search) and there are probably even more sources out there that you and I can't find because we're not familiar with the journals that cover Hypostomus or other fish. Just because an article is small right now does not mean it's not notable. That's a logical fallacy and if we followed that argument we wouldn't have Wikipedia as it exists today. As for improving the genus article... we can have our cake and eat it too. There's nothing stopping expansion of the genus article and having a stub. There are thousands of examples of this in the encyclopedia right now. Since most of our traffic comes from Google, you'd have to redirect and merge millions of species stubs to the genus articles for your theory to work. Steven Walling • talk 03:12, 31 August 2022 (UTC)
In addition, for older species which were previously in other genera, many of the older resources will resultingly have used the at-the-time valid binomial, not the current one. Searching for just the current one is typically a good way to miss the bulk of older sources. (Though in this case, the majority of older sources are likely not going to be available online, anyway: digitization for old non-English sources lags a fair bit behind that of old English sources, and this particular fish species occurs solely outside the Anglosphere) AddWittyNameHere 03:30, 31 August 2022 (UTC)
  • I also did a search on Google Scholar for Hypostomus brevis. Looks like GNG is met pretty easily. There are additional sources available (Monographs about fish in Brazil, in Portuguese). Esculenta (talk) 05:40, 31 August 2022 (UTC)
    Two of those sources are clearly trivial coverage; the third, the Portuguese language source, might count towards GNG, but doesn't meet it on its own.
    However, that is getting off topic; the issue is that sources like these aren't being included when these articles are created. Instead, they are being mass created by duplicating database entries; we should instead be encouraging the editor to add this information to the genus article where it will be of more benefit to the reader than in a micro-stub - of course, if editors are able to find sources that permit them to create an actual article on the subject that would be of more benefit to readers than the genus article, then they are encouraged to do so. BilledMammal (talk) 05:56, 31 August 2022 (UTC)
  • Comment. What are we actually voting on here? The mass creation of articles on fish by Lumpsucker? If so, what is the scope; how many articles will be created, what genus of fish will be covered, etc? I suggest everyone hold off from voting until there is a formal proposal to vote on. BilledMammal (talk) 02:23, 31 August 2022 (UTC)
    We're not voting. This is a discussion. Andre🚐 02:28, 31 August 2022 (UTC)
    Sorry, meant !voting, in reference to the various bolded "support" and "oppose" !votes. BilledMammal (talk) 02:42, 31 August 2022 (UTC)
    On pages like this which have proposals on them, people start doing that sometimes. That's why in the old days people used to say voting is evil. And the reason why we put the ! (which means a logical not) in front a vote is to remind everyone that WP:NOTDEMOCRACY. In theory, though I guess it's increasingly less common in practice, the best arguments should prevail in a rough consensus (not a tally). All of that to say, nobody formally proposed anything and nothing's being voted on, that's the answer to your question. Andre🚐 02:45, 31 August 2022 (UTC)
    I should probably clear something up. There is no vote being called here. This discussion here would not exist were it not for the fact that BilledMammal specifically recommended I start it here, as this topic is inherently not a formal proposal. Lumpsucker (talk) 02:59, 31 August 2022 (UTC)
    It might be a good idea if you made a formal proposal and we can open an RfC on the basis of it. In particular, what is the scope of your proposed mass creation; can you give us a rough idea of what articles you will be creating? (ie, about 100 articles on species within the genus x, about 50 articles on species within the genus y, etc) BilledMammal (talk) 03:03, 31 August 2022 (UTC)
    A proposal and a formal RFC is not necessary or helpful, and you shouldn't push the discussion into that, as it's clear from this discussion that there is not a consensus for Lumpsucker to continue without some further limitations on the activities. Andre🚐 03:09, 31 August 2022 (UTC)
  • I Support the creation of animals and plants that are able to be referenced to a species description. Less work for someone else to expand in the future. If a creator has a high error rate of content that is a separate issue regardless of number of articles created. Limiting stub creation makes it very complicated - what is the cap. How big does an article need to be before editor is allowed to make another etc. Massive headache and bureaucratic creep. Cas Liber (talk · contribs) 02:52, 31 August 2022 (UTC)
  • Here's my suggestion: just stop creating new articles unless you can add 1-2 sentences explaining why they are notable and significant. Andre🚐 03:22, 31 August 2022 (UTC)
creating articles of 1 or 2 sentences plus an infobox is exactly what is being argued against by BilledMammal, and running around wikipedia disrupting good editors. Gnangarra 04:06, 31 August 2022 (UTC)
But I looked at the articles. Some, indeed, are ok. Hypostomus commersoni looks OK, it even has a pic, and it appears in the aquarium trade. It's not the most lengthy or interesting article but it seems to barely qualify. Hypostomus carvalhoi, Hypostomus chrysostiktos, Hypostomus crassicauda, Hypostomus simios Hypostomus corantijni, Hypostomus brevicauda. These don't assert notability or explain significance. It just says they're a fish, in a certain river basin, they grow to this size, and breathe air. The end. The links are to databases only. I don't see why those articles couldn't all be in the Hypostomus article. Andre🚐 04:15, 31 August 2022 (UTC)
Stating its a species of fish, plant, insect, animal. fungi or is establishing notability and data bases are are the where you get the official taxonomy from along with common names, or synonyms and previous naming. Gnangarra 06:02, 31 August 2022 (UTC)
That is not how notability works on WP. There is no special presumption of notability just because you can define its species. we need significant coverage, which 1or 2 sentences do not do. Masem (t) 07:23, 31 August 2022 (UTC)
That is the very definition of notable for species, and has been for 20 years. If you want to overturn notability of species then this isnt the place Gnangarra 09:00, 31 August 2022 (UTC)
"This" meaning this specific thread, probably not. But if the Village Pump isn't the right place, then I don't know what is. casualdejekyll 16:29, 31 August 2022 (UTC)
  • the practice of creating stubs about any Notable topic has been standard since the very first edit occurred on Wikipedia 20 years ago. On any given day I photograph 10 species within 100 miles of here that dont have an article every single one of the are notable. Its dam sight easier to add a photo, and additional information when the article has already been started. As someone who has spent many years doing outreach at various Universities having these articles already created also makes it easier to teach others how to edit Wikipedia as they cant create articles in the first few days of creating an account, standard practice has always been to create stubs in areas where the students will be writing. You'll also note that these articles are one WMF KPI's for events if you look over at Outreach dashboards. Gnangarra 04:06, 31 August 2022 (UTC)
  • I think the idea that instead of stubs, species should be listed in list articles makes perfect sense. That species are notable by default does not automatically imply that a standalone stub is the best way to present information on the species. If a given species' section expands too much, then we can split off a dedicated article for it. Jo-Jo Eumerus (talk) 10:09, 31 August 2022 (UTC)
  • Support the continued creation of stub articles for the reasons given above by Loopy and others. I don't see how the 2-3 articles a day by Lumpsucker counts as automated or semi-automated, as each will be separately evualated when created. If the creation was automated using a bot I would want guidelines and limits, but this isn't the case. Stubs are useful as they make it easy for people to extend the articles, when article creation with appropriate taxoboxes, taxonbars and categories is more of a barrier. —  Jts1882 | talk  12:03, 31 August 2022 (UTC)
    If the creation was automated using a bot I would want guidelines and limits Idk whether it could actually be automated (it sounds as if it might be possible to some extent) but assuming it could be, what guidelines and limits would you suggest? Selfstudier (talk) 12:42, 31 August 2022 (UTC)
  • Comment. From the guidelines at the page header above: "This page is for concrete, actionable proposals." - I would posit that the discussion has now strayed greatly from that requirement and has instead become merely discourse for any prejudices different editors wish to air (dislike of stubs, mis-characterization of non-automated user edits as "bot-like", perceived excessive article creation rates of 2/day, validity of species notability guidelines, or their preferred layout of genus/species/list articles). If there is actually any problem that can be identified here (ie. disruptive editing, creation of non-notable articles, incorrect facts included in the article text, etc) then that can be addressed as a separate issue. It is clear that WP:MASSCREATE does not apply in this situation, in fact the low-rate production of human-reviewed articles is specifically mentioned as a legitimate alternative to semi-automated or automated edits.
The ongoing non-automated creation of new species articles by various editors has been the status quo here for twenty years and there is no need to pressure another editor for them to now ask permission to be able to create such articles. If you feel that this type of activity is detrimental to the encyclopedia, then the onus would be on you to gather the necessary information yourself (again, as recommended by Blueraspberry above) and propose a "concrete, actionable proposal" to overturn the status quo. Loopy30 (talk) 14:13, 31 August 2022 (UTC)
The “Status quo” is that most articles on species are kept… but that does not mean that ALL articles on species should be kept. Most species will have enough sourcing to justify an article… but there will be exceptions. Those exceptions can be covered in larger articles. Blueboar (talk) 14:27, 31 August 2022 (UTC)
It has not be proven that anywhere near the majority of recently created species articles are themselves lacking sources or not notable. At best its come to perhaps 1 or 2 individual articles which could be new species, synonyms of depreciated binomials, or poorly documented though even then these articles havent been proven as not meeting GNG. The sole complaint is that the volume of creating 2 or 3 articles on species a day is too much. Some editors are very good at replicating what is a whole of project agreed MOS for such articles and implementing that consistency. What we then have is the bonus that all species articles start with universally consistent format for other contributors to follow and integrates these with Wikimedia Commons, Wikidata, and Wikispecies while facilitating Outreach activities to bring new editors to Wikipedia. Gnangarra 14:51, 31 August 2022 (UTC)
  • Support Fish species articles have an astronomically low potential for abuse; they aren't likely to be spammy or sources of promotion, they aren't likely to contain controversial information, they aren't likely to misrepresent things, they aren't likely to cause WP:BLP issues, etc. etc. Given the low potential of abuse and the fact that they will only be created based on published, reliable sources, I say go for it. --Jayron32 15:03, 31 August 2022 (UTC)
    That is a good point. There isn't a lot of fish POV pushing that I know of. Though IMHO, I prefer my fish & chips to be haddock over cod or sole. Andre🚐 15:31, 31 August 2022 (UTC)
    it is not that these are going to be spam targets or the like. WP has a problem with creation of underrepresented topics like women's studies and other minrities, which still tend to struggle due to poor non primary sourcing. we continue to thumb our noses when we allow stubby articles on things like fish species and sports players but these attempts to expand in underrepresented areas are expected to have more fully fleshed out articles. its why the community has soured of mass article creation that leaves stubby article behind even if these could be notable topics. it's lazy work. Masem (t) 19:59, 31 August 2022 (UTC)
    The problem I've noticed is that we keep these pages around of an expectation that "eventually someone will improve them" but it never really happens except in rare cases. See also Wikipedia:Don't_hope_the_house_will_build_itself, Wikipedia:An unfinished house is a real problem. casualdejekyll 20:10, 31 August 2022 (UTC)
    exactly. if it takes a bit more work to write a full two paragragh stub that includes demonstration of meeting the GNG, that would be different, but these here are all two sentence stubs with no clear notability, nor any expectation they will be improved to meet that. Masem (t) 20:17, 31 August 2022 (UTC)
  • Support creation of stubs for species. Of course it would be better if more substantial articles were being created. But it is absurd to suggest that an editor can create no more than 25-50 stubs in the course of their Wikipedia career (or needs to seek permission to do so). Plantdrew (talk) 16:54, 31 August 2022 (UTC)
  • oppose creation of taxonomy-only stubs. If at least some description were put in for each one I would be supportive. Mangoe (talk) 19:50, 31 August 2022 (UTC)
    None of these are taxonomy-only. Lumpsucker (talk) 20:21, 31 August 2022 (UTC)
  • Oppose. I while ago I did a lot of work Assessing hundreds (or thousands?) of fish articles. To do this I looked at their pageviews, and there are huge numbers of fish articles that receive about one pageview per month, and there were some that had one pageview in five years. These stubs are not helpful, and arguably non-encyclopedic. Abductive (reasoning) 20:57, 31 August 2022 (UTC)
  • Support editor's preference to create articles. Species have long had implied notability, and there can be no WP:N objection to these stubs. The project is entirely manual and at the stated rate of creation displays neither bot nor bot-like activity; the fact that some articles are very similar speaks more to the similarity of the species involved than evidence of bot-like editing. Beyond that, nobody has invoked any policy or guideline prohibiting the work, which means it should be left to the editor's own discretion. Every editor is free to edit in whatever way they think fit, provided they do so in accordance with policy and guidelines. We shouldn't be attempting to create new rules on the hoof in this thread to force an obviously committed editor to comply with some other editors' "lists are best" preferences. Suggest, by all means; compel, no. MichaelMaggs (talk) 22:17, 31 August 2022 (UTC)
  • This discussion is a waste of time. First off, creating 500 short articles in the space of 9 months isn't "mass creation" in any meaningful sense of the term. Leaving the creator what looks like a templated warning about bot [?!] editing and urging them to get permission at the village pump [??] was poor form. Still, when undertaking a big project that's going to affect a large number of articles (even if the project is slow-going), it's a good idea to first post about it in a relevant place, like  WT:FISH. This is not so much asking for permission as soliciting suggestions (this can, for example, help identify the best taxonomy sources: you wouldn't want to spend months working on something only to later find out your work was based on outdated information).
    So, what are we trying to do here? Some sort of rehearsal for Wikipedia:Arbitration Committee/Requests for comment/Article creation at scale, or just an exercise in venting our frustrations at the low-quality mass stub creations of those high-profile recently banned editors in other topic areas? Rethinking how we present information about obscure species will certainly be worth it, and I second some of Levivich's ideas above; however, treating the species only in a list at the genus articles is not the done thing, and we can't expect people to suddenly have to start asking our opinion before doing things the same way they have been done in the past 20 years. Any talk of species articles needing to "demonstrate notability" is nonsense (as clear from reading Steven Walling's comment).
    Personally, I don't think it's a good idea to create stubs that very few people will ever read (obscure species are among the least read articles in the encyclopedia), and I wouldn't be spending my time on that, but it's up to individual editors to decide how they're going to spend their time, and they shouldn't be pushed into asking for approval for medium-scale manual creations. Uanfala (talk) 22:30, 31 August 2022 (UTC)
    After watching this discussion unfold I have to agree with you. I was under the impression that there was a logical precedent for sending editors here and describing their edits as "bot-like", but it seems as though that may not be as true as I thought it was. After reading this message I will probably continue editing in the way that I have been editing. If any editor here believes that there is a logical reason to modify an individual page of mine, they are free to do so. I encourage expanding and editing small articles of all sorts. Lumpsucker (talk) 23:44, 31 August 2022 (UTC)
    Probably best to wait for Wikipedia:Arbitration Committee/Requests for comment/Article creation at scale. Levivich 23:48, 31 August 2022 (UTC)
    I don't exactly know how all of this works, so I might take a month or so off from editing to see what happens there. Lumpsucker (talk) 00:03, 1 September 2022 (UTC)
    @Lumpsucker: Please don't be discouraged from creating articles. Anyone can start a discussion on the Village Pump, it doesn't mean you are required to do anything, unless there's been a consensus declared. One of Wikipedia's core principles is to be bold, so the last thing in the world is that you should think you have to wait for someone's permission to edit. Especially since there is no agreement via an articles for deletion discussion that any of these articles are not notable and should be removed, you're doing helpful work. My only suggestion would be to try find a second source up front for each stub, not just a taxonomy database. If you aren't comfortable proceeding alone, WikiProject Fishes or other editors like myself who are supportive of writing species articles would be happy to help review and expand stubs. Steven Walling • talk 19:52, 1 September 2022 (UTC)
    Steven is correct, you may continue creating articles, but you might find that if you create an article sourced only to fishbase and another generic database site, it will end up at AFD. Andre🚐 20:09, 1 September 2022 (UTC)
    And to just to be clear Lumpsucker, if you're not familiar with AFD, that's also just like this discussion. Any random editor can propose any article for deletion at any time, and then we discuss it as a community. It would be extremely unusual for a legitimate named species to actually be deleted. What will more likely happen is that someone will just help expand the sources and then it will be kept. So don't let Andre's threatening talk stop you. Steven Walling • talk 21:04, 1 September 2022 (UTC)
    Hmm, it's not a threat, nor is it an idle statement, just a description of what might happen, I didn't say I would be the one doing it. Andre🚐 21:07, 1 September 2022 (UTC)
    Before creating any other articles, I am planning on expanding a few of my smallest articles as I already have been doing. Some of those were only created with a single source and are less than 1 KB in length, and I am looking to improve most of the articles of that size that I made. Lumpsucker (talk) 00:12, 2 September 2022 (UTC)
    I think this comment is important because it shows you are listening to the feedback and adjusting, so I would say there's no problem with your continued doing that. Andre🚐 05:36, 2 September 2022 (UTC)
    +1 to @Uanfala. WhatamIdoing (talk) 23:45, 31 August 2022 (UTC)

Also, I wonder how many people have actually looked at the articles in question? I looked at this one, which I transclude here so that you won't even have to go to the trouble of clicking through to an article:


Hypostomus robinii


(I'd tell you that I picked the name randomly, but it'd be more accurate to say that I picked it arbitrarily, on the basis of its bird-like name.)

I see above people like Levivich talking about "one- or two-sentence stubs" and Blueboar saying "If all we can say is one or two lines", but this is four sentences plus an infobox. That's not what I'm seeing in these articles.

Hypostomus chrysostiktos has four sentences, an infobox, and three sources (one of which is a scholarly paper). Hypostomus ericae has four sentences, an infobox, and two sources. These are typical. Then there are the not-so-typical ones, like Pseudacanthicus pirarara, which has 500 words, four sources, and an ==In popular culture== section. Pseudancistrus megacephalus has 250 words and 11 sources. Chaetostoma platyrhynchus has 250 words and 7 sources. Pseudoqolus, with six sentences and four sources, is about a genus.

So I wonder: If you actually look at the articles, why would anyone want to discourage this editor? WhatamIdoing (talk) 23:46, 31 August 2022 (UTC)

I removed the transcription, as I found it very confusing reading through the page only to encounter an article; I hope you don't mind.
However, to be clear we don't want to discourage articles like Pseudacanthicus pirarara and Chaetostoma platyrhynchus; they aren't mass created, they aren't WP:NOTDATABASE violations, they demonstrate notability, and they are more useful to the reader than the higher level article would be.
What we do want to discourage is articles like the ones I referenced above, and the ones like Hypostomus ericae, which are mass created on the basis of a template, and where the information would be more useful for the reader in a higher level article. BilledMammal (talk) 23:54, 31 August 2022 (UTC)
Hypostomus ericae has five sentences, three sources, and an infobox. One of the sources is a scholarly journal article. Why would you want to discourage the creation of an article like that? WhatamIdoing (talk) 03:09, 1 September 2022 (UTC)
This was the version at the time of my comment. Database-replications like that are not useful for readers; they are better off being sent to a parent article where that information can be included until an editor has time to write a more comprehensive article. BilledMammal (talk) 03:17, 1 September 2022 (UTC)
Yes, it's longer now though. So it shouldn't so clearly be AFD'd or merged. So if every new stub started out this long, I bet there wouldn't be a dispute. Just don't create it if you can't make it this long. Andre🚐 03:20, 1 September 2022 (UTC)
I bet there wouldn't be a dispute; you would be right. If that was what was happening, I wouldn't have asked them to come here and get approval for mass creation, because they wouldn't be engaged in mass creation. BilledMammal (talk) 03:48, 1 September 2022 (UTC)
At the time of your comment, H. ericae contained four sentences, two sources, and an infobox. That is not normally a size that we are concerned about. The (historical) page defining substubs said "Substubs are usually no longer than a dictionary definition, and usually contain information that anyone would know." I don't think that describes any of these articles. They are longer than a dictionary definition, and almost none of the information in them is something that anyone would know.
Your assertion that articles "like that are not useful for readers" is your personal opinion. I personally benefited from a series of equally short (or worse) species article just a couple of weeks ago (for a plant, rather than a fish). As a result, my personal opinion is that your personal opinion is wrong. I could believe that these articles a not interesting to very many readers, but that's not the same as them never being useful to anyone at all.
I think that the general principle you should be considering is related to Wikipedia:Deletion is not cleanup. It's actually okay to create a species stub with a few sentences, two sources, and an infobox. Not all articles have to be long ones, and they definitely don't have to be long articles on the day that they're created. WhatamIdoing (talk) 05:47, 1 September 2022 (UTC)
  • Oppose mass creation of any group of articles, period. Mass creations can sometimes lead to mass Prods or mass AfDs. The latter of which can get messy. GoodDay (talk) 00:02, 1 September 2022 (UTC)
  • Agree with Uanfala and WhatamIdoing. If someone wants to go around and create a bunch of species articles like Hypostomus robinii, then great. That really shouldn't be problematic. If it would only be a single line derived from basic taxonomy and/or if we were talking about some tens or hundreds of thousands, then sure we should have a discussion, but this should be a non-issue. It sure seems like some people are just against the idea of creating stubs at all, and the specter of "mass creation" (500 manually created articles, with acceptable sourcing, created over 9 months is not what I'd call "mass creation" of the sort that's controversial) provides a convenient mechanism for action. — Rhododendrites talk \\ 03:24, 1 September 2022 (UTC)
    I think there probably wouldn't be an issue if substubs such as this "article," weren't created: "Hypostomus chrysostiktos is a species of catfish in the family Loricariidae. It is native to South America, where it occurs in the Paraguaçu River basin in Brazil. It is typically seen in blackwater portions of rivers with rocky substrates at elevations of 50 to 662 m (164 to 2172 ft) above sea level. The species reaches 26 cm (10.2 inches) SL and is believed to be a facultative air-breather." Andre🚐 03:29, 1 September 2022 (UTC)
    You keep using this word "substubs" like an article with just 3-4 referenced sentences is too short to exist, which is not something there is consensus for. 18 years ago there was in fact a discussion about the essay Wikipedia:Substub which not only ended up with a consensus that very short articles are fine, but we don't even mark such articles separately from other stubs, even though according to WP:STUB there is no consensus on how big a stub is. There's no minimum required length for a Wikipedia article, only that it passes the bar for verifiability and notability. Steven Walling • talk 04:42, 1 September 2022 (UTC)
    There's no minimum required length for a Wikipedia article, only that it passes the bar for verifiability and notability. - it also needs to meet the requirements of WP:PAGEDECIDE and not violate WP:NOT. "Microstubs" or "Substubs", whatever you prefer to call them, often struggle to do so. BilledMammal (talk) 04:45, 1 September 2022 (UTC)
    I never said there were length requirements for articles, but articles do need to be encyclopedic and informative. The reason why substubs don't exist anymore per se, as I remember it, and like you said it was a very long time ago, is the advent of bright line notability requirements and referencing requirements. Back then, you could just make pages that were 1 or 2 sentences long and put {{substub}}, no references, and it would still be debated at VFD (as it was called then), and plenty of pages existed for a while before getting deleted that were all kinds of fictional characters and stuff that we today, will merge into a list article to avoid too much fancruft (to use another old wiki slang term). As I remember it, the reason why the template and the categories for substubs were done away with had a lot to do with there not being many substubs that could justify their existence. There subsequently was the requirement that articles had to assert notability. And now of course there is NPP, drafts, etc. Andre🚐 04:49, 1 September 2022 (UTC)
    "substubs" aren't a thing (well, other than a rhetorical tool). I don't see a problem with starting Hypostomus chrysostiktos the way Lumpsucker did. Expand it if you can, propose a merge if you want. All regular editorial decisions remain in place. It doesn't "create work" for other people because nobody is obliged to improve anything and as it stands it's completely policy compliant. — Rhododendrites talk \\ 19:47, 1 September 2022 (UTC)
    Substubs were a thing but let's not get hung up on terminology. I think tagging substubs stopped being necessary in part because WP:CSD began to cover A7,A9,and A11. Per this essay, Wikipedia:Credible claim of significance. You're right, no policy is being violated, it's not "making new work," but that is separate from whether all of these articles created should be kept at an AFD and not merged, which I think is a worthwhile question. Not saying Lumpsucker was the bad guy, but he should take note of the community's feedback good and bad for the article work. Andre🚐 21:02, 1 September 2022 (UTC)
    If someone wants to create a bunch of species articles like the current status of Hypostomus robinii, then great; we wouldn't be here if that was what was happening. However, that isn't what was happening; this is what was created, and that is an issue. BilledMammal (talk) 03:39, 1 September 2022 (UTC)
    Exactly, so, if the fish team could simply agree to make all the articles be up to that par or close to it, we'd have no problems. Andre🚐 04:51, 1 September 2022 (UTC)
    Hypostomus robinii as originally created was a perfectly good stub. It managed in its four sentences to include eight or nine separate facts about the species, in addition to comprehensive taxonomic information. It's now been further expanded to Hypostomus robinii. The encyclopedia is working as it should. MichaelMaggs (talk) 08:36, 1 September 2022 (UTC)
    I'm astounded that the initial version of Hypostomus robinii is being presented as an example of a bad stub. This thread started over concerns about semi-automated editing. Some of Lumpsucker's fish articles could have beeen generated by just copy-pasting a template and changing the species, river system where it occurs and standard length. The initial version of H. robinii includes a common name, diet, and more detail on habitat and distribution than just naming a single river system. I'll acknowledge that the only sources are databases, but it wasn't created in a semi-automated way by copy-pasting and changing a few variables (and FishBase has it's range as Central America:Trinidad, while the article places Trinidad in the Caribbean which I think is more accurate and shows Lumpsucker didn't just blindly insert variables from FishBase). Plantdrew (talk) 16:56, 1 September 2022 (UTC)
    I don't see anybody presenting Hypostomus robinii as an example of a bad stub. It's not even relevant to this discussion, as has been pointed out above. Levivich 17:56, 1 September 2022 (UTC)
    To clarify for you, at the start of this thread indent, BilledMammal suggests that the initial version Hypostomus robinii "is an issue". Esculenta (talk) 18:06, 1 September 2022 (UTC)
    Thanks, and sorry, I misread that comment. Levivich 18:20, 1 September 2022 (UTC)
    If someone wants to create a bunch of species articles like the current status of Hypostomus robinii, then great; we wouldn't be here if that was what was happening. True. What happened is someone manually started an article on a notable subject with two sources. Someone else came along and improved it. This is a wiki, after all. I would like it if people would improve an article they create rather than leave it a stub, but unless you find consensus for that, this sort of article isn't allowed. I didn't support Lugnuts' creation of single-sentence stubs based on databases because the databases didn't provide any real information and didn't actually ensure notability. An identified species will have some actual paperwork behind it, and indeed the starting version of this article has more than a single sentence with statistics. It may not be ideal, but it's completely in line with wikipolicy. — Rhododendrites talk \\ 19:47, 1 September 2022 (UTC)
    These several recent ANIs with mass creation and the upcoming RFC mandated by sending about mass creation and deletion are signs the community dies not want someone to mass create stubs with questionable notability. A two paragraph article may be a stub but if it shown 403 or 4 good sources for significant coverage, we are far less likely to conplain. I think it is more dose don't want editors creating mass articles with low level effort (like just pulling from databases or finding one source and calling it good). mass creation with more effort will draw less attention. they may be stubs still but they are in a better place for expansion Masem (t) 20:03, 1 September 2022 (UTC)
  • It is not clear that a problem exists. The topics are notable in that a reliable source definitively exists for every recognised described species. Two articles per day on clearly notable topics is not mass creation, and most of the articles discussed here in any detail appear to be better than sub-stubs by a significant margin. While there are debatable advantages to the utility of conbining such articles, not necessrily as lists per se, but as sections in an article on a higher taxon, (actually my personal preference), the articles in general appear to be fully legitimate, with possible exceptions which have not been specified. The editor was requested to seek comment here, which they have done. I thank them for that as it displays the attitude of collegial discussion and open-mindedness we officially strive for. Unfortunately some of the comment lacks grounding in policy, guidance or tradition, but that is pretty normal, as everyone thinks they are an expert. Expressing a personal preference, opinion or bias as a !vote gives it no extra weight or validity. Cheers, · · · Peter Southwood (talk): 05:29, 2 September 2022 (UTC)
    I concur with this Andre🚐 05:35, 2 September 2022 (UTC)
  • [ec] It might be helpful if some of our editors did a little research on the process of taxon description and publishing, and the inclusion criteria of taxonomic databases before expressing their opinions on notabilty or lack thereof of a published taxon. · · · Peter Southwood (talk): 05:40, 2 September 2022 (UTC)
    Thank-you for the suggestion that we shoul learn more about Taxanomic databases before commenting. it is quite a fascinating topic. To summarise paid and volunteer work to create a taxanomic machine readable database that links physical material, media, and the written word.
    Problems are poor countries/organisations, uncontrolled/non-updated/non-validated subsets, secondary databases inability to create 'semantic and syntactic information that would improve the fitness of these data", and difficulties with occourence datasets ( Birdwatching etc) [14] [15][16][17]
    Best practise seems to be to link dynamicially Amphibia Web Wakelamp d[@-@]b (talk) 13:10, 20 September 2022 (UTC)
  • Oppose creation of species articles cited only to database listings. These species can be covered in list articles. Support the creation of species articles that cite and summarize significant prose coverage of the species in reliable sources. Cullen328 (talk) 05:56, 2 September 2022 (UTC)
    Concur with this nuance also Andre🚐 05:58, 2 September 2022 (UTC)
  • Support. The sentiment that "mass creation from databases is bad" is close to right, but not quite there, in my opinion. Turning an accurate entry in an external public database into a stub is, in my opinion, neutral or very close to it. It doesn't really improve things—the reader could probably just as easily pull it from the original database, probably in a more useful format than Wikipedia prose—but it's not really harmful, either, the offense to some editors' taste notwithstanding. The damage occurs when the external database is not accurate (or if the mass creator is not accurately transcribing that information). In the case of biology stubs, this usually takes the form of a species being listed under a name that is no longer current or a name that was never really published. In the case of the sports stubs, my impression is that there have been widespread errors (depending on the creator) in birth and death dates, which events they competed in, standing etc. In the case of the geography stubs, places that are not, and never have been, concentrations of population have been misrepresented as being so (a single house or a landmark being misrepresented as a village). Propagating and disseminating external error, rather than correcting it through the power of many eyeballs, is directly damaging to the encyclopedia. All that said, I see no problem with the initial version of Hypostomus robinii that BilledMammal deprecates. In particular, I would note that it's sourced to two databases that appear to be substantially independent of each other. In my experience (I would note that I sink a fair bit of my leisure time into helping correct non-Wikipedia taxonomic databases), that's likely to avoid most of the damage caused by the really problematic mass creations described above, and also to limit the rate of creation to something relatively modest. Choess (talk) 15:53, 2 September 2022 (UTC)
  • Oppose Bulk creation of database stubs. More substantive content and sourcing is expected for each article. A List of Hypostomus species that compiles content for comparison and context would be welcome. Reywas92Talk 18:21, 2 September 2022 (UTC)
  • Strongly Oppose From their point of view we are creating a Wikipedia:Wikipedia_clones designed to reduce their traffic, and break thier community. We are doing the same thing on reptiles and other small databases. We also don't have as much information, our cite does not mention that we use thier cite, and we will have no one actively updating the information. Wakelamp d[@-@]b (talk) 04:49, 3 September 2022 (UTC)
  • what an amazing waste of effort this discussion is producing, the simple answer is put the data base in Wikidata like we are asked to do then generate list articles from there. No where in the discussion has it been shown these stubs arent notable subjects, nor that the creation of them is causing any disruption to the project its a simple case of "I dont like it" therefore noone can do it. Gnangarra 14:18, 3 September 2022 (UTC)
    Totally agree - except I would actually get wikidata to negotitate with the site that is maintaining it, If a user searchs for it, they get shown a wikidata created page, Wakelamp d[@-@]b (talk) 14:59, 4 September 2022 (UTC)
  • Support The OP's recent creations such as Hypostomus dardanelos and Parotocinclus hardmani look perfectly reasonable and respectable. A separate page for each such species is sensible as the page will then readily support an infobox and appropriate imagery such as a picture of the creature and map of its distribution. Lumpsucker's editing of such subjects is commendable as it seems quite fluent and encyclopedic. It does not seem especially bot-like or high volume and so no special process or permission is required. As for species, there are certainly a lot of them but so it goes and it's not a problem. Our policy is WP:NOTPAPER which states clearly that "there is no practical limit" and so we should not invent one just to be difficult. Andrew🐉(talk) 20:23, 3 September 2022 (UTC)
  • Oppose - send the bot-like mass creations to WikiSpecies – we need articles at en.WP not taxosentences that are basically definitions or more like WikiData that Google can use. Let the WMF capitalize on these BOTs and then they can use that money to get en.WP the tools we need to build this encyclopedia as the encyclopedia it was intended to be. As for all the support votes - if this Proposal passes, all the editors who voted support will be automatically added as NPP reviewers on assignment and your dedicated job will be to review all BOT-like creations.[FBDB] Atsme 💬 📧 21:15, 4 September 2022 (UTC) Correction: bot-like not bots. Apologies for the error and thank you for pointing it out to me Lumpsucker and Andrevan. I really would like to see WikiSpecies used for this purpose. Atsme 💬 📧 03:15, 5 September 2022 (UTC)
    I don't know if I am understanding this message correctly, but this discussion is not about bot-created articles. Lumpsucker (talk) 22:26, 4 September 2022 (UTC)
    Atsme misunderstood the discussion. Atsme, these are human-created articles being discussed. Andre🚐 22:31, 4 September 2022 (UTC)
  • Moral support for Lumpsucker and since nothing was being proposed, nothing is being opposed. Lumpsucker has already stated they will improve these articles and will abide by policy. Andre🚐 22:32, 4 September 2022 (UTC)
  • Oppose until a WP:BRFA has been passed, then support. Generally oppose bot-like edits with user accounts. AKAF (talk) 09:55, 6 September 2022 (UTC)
@AKAF: The question is how would you define bot-like edits? That seems to be the crux of the disagreement, because to me the original version of this article that was used as an example for this discussion doesn't look bot-like at all–it has two sources and original content not written using a template. The current version has since been expanded to be decent stub that's even better. The original creator was doing 1-2 of these a day, which is plenty slow enough that the other editors in WikiProject Fishes or related projects can review them and hardly the scale that only a bot or script could achieve. Steven Walling • talk 21:01, 7 September 2022 (UTC)
@Steven Walling: The original version was actually written using a template:
NAME is a species of catfish in the family Loricariidae. It is native to South America, where it occurs AREA OF OCCURRENCE. The species reaches LENGTH cm (LENGTH inches) SL and is believed to be a facultative air-breather.
Compare it to the other examples I provided, like Hypostomus argus and Hypostomus johnii. BilledMammal (talk) 02:08, 8 September 2022 (UTC)
Ok but I still don't agree that's a bot-like set of articles created. There's a human being reading the source material and applying that knowledge to original article content, which is subsequently being edited and expanded by others. How is this harmful rather than helpful? We now have more verifiable knowledge in the encyclopedia that has been reviewed by humans, not bots which are dumb and don't understand the meaning of sources. That's the problem with bot creation (that they're often incorrect, because the bot doesn't actually understand the sources) and why we don't allow bot-created articles generally. This is totally different in outcome. Steven Walling • talk 17:37, 8 September 2022 (UTC)
If the source is reliable, a bot is actually better than a human; the human makes transcription mistakes, the bot does not.
As for why we don't want micro-stubs like these, Levivich and Casualdejekyll has said it well. Readers are better served by a list or general article than they are by these microstubs. I would also mention that we aren't just here to build a large encyclopedia, we are here to build a quality encyclopaedia, and the proliferation of micro-stubs like these reduce the quality. BilledMammal (talk) 23:52, 8 September 2022 (UTC)
"micro-stubs like these reduce the quality"
This is false and not in alignment with core editing policy. Having a small, well-referenced article does not detract from the quality of other articles. More importantly, it's inherent to the nature of the wiki that we have articles of varying size and quality. Wikipedia is a work in progress and perfection everywhere is not required. Steven Walling • talk 16:26, 9 September 2022 (UTC)
I have to agree with this - how do micro-stubs reduce the quality of good articles? Regardless of whether you think such an article should be merged or kept, I don't see the additive production of small articles reducing the quality of the overall work. Andre🚐 16:28, 9 September 2022 (UTC)
I agree that @Lumpsucker 's 500 articles are not an issue ( and I thank them for their work), but this discussion is about the general case. The reduction in the quality of good articles is in perception. If a study was done on Wikipedia accuracy, 86% (6.5/7.5 Millions would be based on stubs/starts/unassessed)
We shouldn't create something that we will not update Nearly all updates on stubs are by bots, but with no content as @Andrevan' s example indicated. We have a higher Google page rank, so readers will view our less accurate version, at the expense of the community that we online database strip mined. Wakelamp d[@-@]b (talk) 02:22, 11 September 2022 (UTC)
I think you made a good point Wakelamp about the smaller communities. Since Lumpsucker is trying to create Wikipedia-quality entries, hopefully, there will still be a place on the Internet for Fishbase to create entries for things that may not make a good Wiki entry at present, or maybe ever. Some species may not be attested much. Who knows why. There's no rule in natural history that says everything will be documented verifiably. Andre🚐 02:25, 11 September 2022 (UTC)
  • Oppose mass creation but this one is borderline on being mass creation Maybe slow down and do a thorough source search for material for each article and put the material in. North8000 (talk) 21:12, 7 September 2022 (UTC)
  •   Support. 2 articles a day is nowhere near mass creation. — Qwerfjkltalk 20:35, 8 September 2022 (UTC)
  • oppose Levivich and BD2412 have the right idea here. -- LCU ActivelyDisinterested transmissions °co-ords° 22:16, 8 September 2022 (UTC)
  • Uh-Oh we want to be careful here because "Support" is being used for two opposite opinions ("SUPPORT OP's suggestion of reigning hn these articles" but also "SUPPORT the continued creation of these articles"; and vice versa for "Oppose". Just pointing this out. Herostratus (talk) 01:57, 9 September 2022 (UTC)
  • Well, I think these articles are fine. I think the argument is between "let's have lists" and "let's have individual articles". I think that people who don't think we should publish this material at all are in a minority compared to people who do but can't agree on the format.
So, it's basically a matter of opinion. It's the Wikipedia not ExxonMobile, so it one editor wants to create a long list and another a bunch of small articles, I'm just glad to have the info. I'm not big on telling "you can't do that, you have to do it my way" to people who have just spent hundreds of hours creating content, and might stop if annoyed. Generally and withing reason, stare decisis is the rule for formatting, giving deference to the person who did, I don't know, the actual work of creating the encyclopedia, and also to prevent sterile warring about one editors personal preferance over another. We don't need a rule for everything, and we don't need to be busybodies.
On the merits, I happen to like the articles better. That's just me. A proponent opines "One of the reasons [for having lists instead] is context: Hypostomus brevis doesn't tell me that this particular species of catfish is one of 100+ species of Hypostomus". Well it could, so go add it. But it's a reasonable point otherwise. But if there are 100+ entries on "List of Hypostomus species" when we get to them, that's a pretty long article. If you're including the infobox (much shorter, granted) and a picture, you're getting into a lot of these, and 100+ pictures for short entries makes it hard to have good formatting -- and easy reading. And the References section will be hundreds of entries long. Finding the references for only say Hypostomus brevis in particular will harder to do. Many of the refs will be just page numbers, and then you have to and find the first ref to the book I suppose. Navigation -- either your Table of Contents will be 100+ entries long which is rididulous, or you'll have to figure out some other scheme.
I just don't think it's easier to navigate a large article that is 100's entries long than 100+ individual articles. This sort of thing is studied somewhere I'm sure, and I think it's very likely that a human factors engineer or user interface designer would barf at a TOC that large. Sure you can divide the species into groups -- by Subgenus, or geographical location, or whatever -- but then accessing an individual species is hard.
But then, you can make the list shorter if you omit some information. Why omit inforation that we already have -- I don't think our readers can't handle these amounts of detail. So, sure you can omit say "...and is believed to be a facultative air-breather" from maybe the articles for a whole subgenus and put it in a section header ("All of the following are believed to be facultative air-breathers"), but then you are spreading out information about the entity into two places -- not a service to the reader. Or you can just have subgenus sections and just describe things common to all the species in that subgenus, or something. If that's how you roll. I don't.
Another thing about lists is that they can be attractive nuisences forjust destroying some information. You know, like "Geez this list is long. Do we really need say 'The fish was first formally described by John Treadwell Nichols in 1919'? That doesn't tell anything about the species itself, and we can make the list a lot more managable if we leave out the discovery info". I'm not super on board with that either. Herostratus (talk) 01:57, 9 September 2022 (UTC)
This is a very good point. I am a reader. I am not "served" by enormous lists, which take a while to load on my machine and are virtually impossible to edit for more than a few characters without the page hanging. Gnomingstuff (talk) 12:53, 16 September 2022 (UTC)
  • Support -- The crusade against valid encyclopedic content just because the articles happen to be short was absurd from the beginning and remains absurd (not least because of the mountain of undetected vandalism, PR-speak, fan-speak, un-copyedited, and generally embarrassingly written content that is actually embarrassing to the project, as opposed to neutrally-written, academic, inobtrusive entries on, in this case, fish). The vilification of the people who make them is worse. There should not have to be a topic where one can support or oppose improving the encyclopedia! Gnomingstuff (talk) 12:45, 16 September 2022 (UTC)
  • Oppose mass creation of "sub-stub articles" (per Donald Albury), on fish species or otherwise, per Levivich and Ajpolino and UnitedStatesian. Rationale: 1)- Data bases have errors. There is no actual secondary sources with significant coverage to confirm the information. I became weary of all the GNIS populated places articles that, with no proper outside sourcing, showed things like empty fields. What we end up with is just copied wording from a database to an article page, 2)- by creating these glorified dictionary entries there is too much important information missing and what is included in pieced from the database information. I know it is not the actually reasoning but since Wikipedia is gungho on stats and it does look good for article creation, 3)- it makes sense to put these in proper lists where silly things like Wikipedia:Reliable sources: Wikipedia articles should be based on reliable, published sources, making sure that all majority and significant minority views that have appeared in those sources are covered (NPOV), covers content and not notability. 4)- Article that are basically prose of database information is not encyclopedic. We can create short uninformative stubs of the "92 genera and just over 680 species" of the Loricariidae but how does that help Wikipedia except possible showing it is still growing. Why do we want to sacrifice quality for quantity? 5)- It would be better to "try covering all the species in sections on the genus article and split out the most substantial sections into their own article.", per casualdejekyll. Agree with "two sentence stubs with no clear notability, nor any expectation they will be improved to meet that." per Masem -- Otr500 (talk) 05:49, 18 September 2022 (UTC)
    @Otr500, you say that "Data bases have errors". Are you aware of any errors in these databases? Telling editors that they shouldn't rely on these sources because similarly formatted sources in a completely unrelated field have problems would be an example of a Faulty generalization.
    As for whether it contains SIGCOV, as an example, I went through one reputable fish-species secondary database to see how much of an article I could write. You can read the results here. The short answer is that if you define SIGCOV as meaning 'contains enough information to write more than a doomed permastub', then this database definitely contains SIGCOV. WhatamIdoing (talk) 17:36, 19 September 2022 (UTC)
    I have seen errors in FishBase. Lumpsucker (talk) 18:12, 19 September 2022 (UTC)
    Reply: (actually to WhatamIdoing) I did not yet look at the example (yet) for I was looking elsewhere. Hypostomus johnii contains two sources, both databases (ITIS and FishBase) and "IF" this (I assume scholarly) abstract is considered reliable then the 2007 update (redescription) seems to indicate that Steindachner (1877) may have confused the Hypostomus johnii with congeners in the São Francisco River. "If" this is true then the article, using just database information, is flawed. A preliminary survey (Burgess, W.E., 1989) apparently centered only on Siluriformes (catfish) and not on individual species. This is the very first example I randomly picked. I suppose if you found one that could be considered SIGCOV, I would have to say (the only one I checked so far) does not pass.
    In no way do I want to hinder an editor from creating or improving articles. I am just attempting to show there should be more to an article that the use of only a database, which in essence is just a database copied into prose form possible to satisfy WP:SPECIESOUTCOMES: at least a brief description must have been published in a reliable academic publication to be recognized as correct or valid., but I question if a database satisfies "academic publication" when there is no description and an editor has to create prose from the content.
    When Wikipedia was striving to be a world encyclopedia it was common to create an article with one source, no source, or the source located in the "External links". We have nothing to prove now except improving the quality of even stub articles and the accuracy of any created article. I don't assume an article (even stub) is "doomed" because it only has a database listing.I think moving forward an editor should do at least some research and not just create I think that 900 articles (I am pretty sure I read that) a year , almost 2 1/2 articles a day, to some, can be considered mass creating if just copying material into prose from a database. Although there is no hurry for improvements I can't see any way a vast majority of these can ever be be checked/expanded, especially since the author has commented continuing the status quo, knowing consensus has previously considered species notable for inclusion.
    "If" consensus deems an editor can create as many articles as desired, especially using only database content converted to prose, I would hope that editor reads the negative rational here. casualdejekyll stated: "They're stubs. Sourced stubs, sure, if they weren't on such an obviously notable subject they don't have the sourcing to show the notability", and that is a sad realization. Since sourcing on any considered notable subjects (we can leave out "presumed" and add fish species to automatically notable), would be exempt from some standards, we can just create 1000's and not worry about any sourcing at all or accuracy. If there is still a presumption of notability then reliable sourcing is still required.
    In defense of the singled out editor one can look at the project Wikipedia:WikiProject Fishes/Assessment#Quality scale (Stub: more detailed criteria): "The article is either a very short article or a rough collection of information that will need much work to become a meaningful article.", and "may be little more than a dictionary definition" to see justification for stubby-stubs. However, it also includes "Although Stub-class articles are the lowest class of the normal classes, they are adequate enough to be an accepted article, though they do have risks of being dropped from being an article altogether." This appears to support that there is presumed and not inherit notability (arguemnts to avoid).
    WP:SIGCOV states: "Significant coverage" addresses the topic directly and in detail, so that no original research is needed to extract the content. and I can't see justification in a database listing and 1000's of articles created from them. The editors comments below might have missed the one I checked as I see some issues. Donald Albury (below) seems to have hit the nail on the head, having "no objection to using a database to find subjects for creating articles, as long as each article is also supported by at least one reliable source other than the database." A list could be created for the articles that did not follow that criteria or could be placed in a higher-level article. I do agree with above statements that articles on species would very likely not be deleted at AFD, although some other course of action could be the result. -- Otr500 (talk)
    Special important Note: If we are concerned only with article creations concerning the above editor, the issue is solved per positive comments from the editor that stated: Before creating any other articles, I am planning on expanding a few of my smallest articles as I already have been doing. Some of those were only created with a single source and are less than 1 KB in length, and I am looking to improve most of the articles of that size that I made. I hope these improvements will include more than database content. That is all I need here since I do not foresee starting any AFD on species. "If" anyone does start an RFC on "mass article creation", please ping me, on species or any other subject. -- Otr500 (talk) 20:52, 19 September 2022 (UTC)
    @Otr500:, the link to that abstract doesn't work for me, but I assume it's the same as publication as this one althought that was published in 2017 rather than 2007 (but if H. johniihad be redescribed in 2007, another redescription in 2017 would probably be unnecessary). The authors examined the same specimens (allegedly) from the São Francisco River that Steindachner did, and did not find them to be anything other than H. johnii. It may be the case that H. johnii did occur in the São Francisco River in 1877, but has since been extirpated; it may be the case that the specimens weren't actually collected in the São Francisco River but were mislabelled as such (which should not be a problem for Wikipedia; Wikipedia:Verifiability, not truth). The cover of Burgess's book promises a "complete checklist of the genera and species".
    The reliable academic publication that SPECIESOUTCOMES refers to is, in this case, Steindachner's 1877 original description of the species, available on BHL. It's in German and runs not quite 2 pages. Few species articles currently cite the original description directly (but there's almost always an indirect citation with the authority in the taxobox). Original descriptions may not be available online; BHL has a lot of taxonomic literature that is out of copyright, but uploading a publication that describes a single species isn't going to be a high priority for them. Other original descriptions may not be out of copyright. Many are in a foreign language (particularly Latin in the 19th century). The original description of a species described a long time ago may not be sufficient to distinguish it from the larger number of related species that are known now (this is why H. johnii was redescribed in 2017).
    SPECIESOUTCOMES begins with Species that have a correct name (botany) or valid name (zoology) are generally kept.. So far in this thread, nobody has mentioned why species articles are sourced to taxonomic databases. The database is the source that shows that a name is correct/valid. Taxonomy is subjective to a degree; taxonomists can disagree about whether two populations represent different subspecies, or aren't worth recognizing as taxonomically distinct at all; going the other way they can disagree about whether there are two species or one species with two subspecies. If we are going to present a list of species regarded as valid/correct in a genus article, that list needs to come from a single source, and in 2022 that source is usually going to be a taxonomic database (we can't just piece together a list of species in a genus from the original descriptions; there are several times as many species that have been described as are currently recognized by a consensus of taxonomists). Original descriptions are primary sources; the act of describing a species means that the person doing so thinks it is valid. Taxonomic databases are secondary or tertiary sources that show that somebody other than the original describer agrees a species is valid.
    @WhatamIdoing:'s example doesn't mention the most important fact; it is a valid species, according to FishBase. Probably because that's taken as a given; taxonomic databases list invalid species as well as valid ones, and absolutely nobody is churning out sub-stubs for species that aren't considered valid. There are two high quality taxonomic databases for fish; the other Catalog of Fishes. For the vast majority of fish species, both databases are in agreement as to their validity. WikiProject Fishes has chosen to follow FishBase (in the early years of Wikipedia, it wasn't possible to link directly to species records in Catalog of Fishes). Every article for fish species should cite FishBase; that's the baseline to establish that the species is valid. Fish articles ought to cite the original description (if it was described recently); or a detailed rediscription (if it was described long ago). If there is active disagreement among taxonomists about the validity of a species, that ought to be mentioned as well (e.g. in article for species X "Catalog of Fishes recognizes species X and Y as distinct, but FishBase considers Y a synonym of X). Plantdrew (talk) 21:22, 20 September 2022 (UTC)
    I think this is that problem of most editors not knowing the subject area. Otr500 writes I question if a database satisfies "academic publication". The database isn't the academic publication, but these two databases don't include species unless there really was an academic publication. The real-world process for the would-be fish discoverer is:
    1. See a fish.
    2. Figure out that it's never been described in a peer-reviewed scientific journal.
    3. Publish a description that contains a description sufficient for other scientists to differentiate your new fish from other fish plus your choice of name (which must follow certain rules) in a peer-reviewed scientific journal. (Fun fact: until 10 years ago, only journals printed on paper were acceptable. It is still true that only "reputable" peer-reviewed journals are acceptable.)
    4. FishBase reads your journal article and makes a record for the fish.
    From the Wikipedia editor's perspective, if it's in one of these databases and marked as having a valid name (a "valid name" is a special thing in the real world, and it is not the same as having, say, a grammatically correct name), then Wikipedia editors [should] know, with 100% certainty, that steps 1, 2, and 3 have happened in the real world. Even if you don't have the peer-reviewed scientific journal article, you know that it was published, because publishing that peer-reviewed article is the only way to get a valid name.
    But if you feel a need to check on whether this mandatory process really was followed for any particular entry that claims to have a valid name, then using Entomocorus benjamini as an example, FishBase says, in the very first line/title of the database record that the original description was written by Carl H. Eigenmann in 1917, like this:
    Entomocorus benjamini Eigenmann, 1917
    All four of the words are links. If you click on the last one (the year), it gives you the full bibliographic citation for the original peer-reviewed scientific journal article. Skeptical editors don't have to wonder whether there was an academic publication. You just have to click on the link in the database entry and find out. WhatamIdoing (talk) 01:09, 21 September 2022 (UTC)
  • Support. I've never understood people who devote themselves to deleting useful properly sourced information. I looked at all the fish articles mentioned in this thread and don't see a problem with any of them. Some are short; so what, lots of articles start off short. Some even stay short because there aren't many sources, but that has never been an excuse for deletion if what is there is notable and properly sourced. Moreover, the claim that a species of life can be non-notable is frankly obscene. If Wikipedia had an article on every known species on Earth, that would be the most extraordinary achievement in the life of the encyclopedia. Lift your horizons. Zerotalk 08:48, 18 September 2022 (UTC)
    You're way too long in the tooth to be referring to merger as "deletion" or ignoring altogether WP:PAGEDECIDE (the section of the notability guideline dedicated entirely to the idea that just because a topic is notable doesn't necessarily mean it's best to have a stand-alone page). Levivich (talk) 14:32, 20 September 2022 (UTC)
  • Comment I have not expressed an opinion on this set of creations, and I do not have the time available to review the articles, but, since my name has been invoked, I want to clarify that while I would like to see a consensus of the community to prevent articles being created based solely on a database, I have no objection to using a database to find subjects for creating articles, as long as each article is also supported by at least one reliable source other than the database. I also feel that list articles are fine for subjects for which sufficient material from reliable source has not yet been found to support a stand-alone article. YMMV. - Donald Albury 20:49, 18 September 2022 (UTC)
WIkidata is looking at negotiating to be the central hub in DE Wakelamp d[@-@]b (talk) 08:18, 24 September 2022 (UTC)

SuicidesEdit

It's not uncommon for stories about recent suicides to include a message at the bottom to contact the suicide hotline. CNBC example. I expect a first reaction would be it is outside the scope of Wikipedia, but it's outside CNBC, and everyone else. It's done as a social good because the reality of suicide is a spur of the moment action caused by seemingly small triggers with great consequences. Copycat suicide is a thing. Wikipedia is social media, we serve society. It would be a logical fallacy to assume slippery slope (if we do this, will we warn about tobacco etc..) - in the same way we can block some sources like Daily Mail without blocking all sources, there are limits, it's not a slippery slope. A public service message about suicide at the bottom of recent suicides (not forever) might be something to consider. List of suicide crisis lines covers most places. -- GreenC 17:38, 6 September 2022 (UTC)

GreenC I'm fairly sure this concept has been discussed before, in varying ways. There are many social goods Wikipedia could help with, but that's outside our mission. We do have a link to support services at Wikipedia:Responding to threats of harm. 331dot (talk) 18:00, 6 September 2022 (UTC)
See Wikipedia:Wikipedia Signpost/2022-08-01/News and notes; "Provide access to a geotargeted suicide prevention hotline at the top of the articles on Suicide Methods" was one of the recent proposals that came out of the m:Human Rights Impact Assessment the WMF commissioned from an outside consultancy. This topic is closely related; pinging User:RGaines (WMF). Andreas JN466 18:32, 6 September 2022 (UTC)
WP:BLP: Editors must take particular care when adding information about living persons to any Wikipedia page. Such material requires a high degree of sensitivity, and must adhere strictly to all applicable laws in the United States. The policy applies to recent suicides (WP:BDP). Unfortunately, it lacks any rationale. Hawkeye7 (discuss) 18:50, 6 September 2022 (UTC)
It's outside the ability of the Wikipedia community to place geotargetted anything on site. The wikisource we save gets converted to a non-localizable HTML; and while skins and scripts can alter it, they are also unaware of the viewer's location. Animal lover |666| 06:34, 7 September 2022 (UTC)
We have geotargeted watchlist notices, for example. Andreas JN466 08:06, 7 September 2022 (UTC)
And fundraising requests too. CX Zoom[he/him] (let's talk • {CX}) 10:18, 7 September 2022 (UTC)
Hi all- for those of you who I haven't yet interacted with, I work as the Senior Human Rights Advocacy Manager at WMF. My colleagues, including LMixter (WMF), have been discussing this topic and wanted to share our perspective:
As some people in this discussion have already noted, the addition of a suicide hotline was identified as a recommendation in our recent Human Rights Impact Assessment. We also recently hosted a panel at Wikimania about mental health topics on Wikipedia.
We are definitely interested in helping the volunteer community add suicide hotline information to suicide-related articles, as a banner or other format clearly distinct from article content. We believe this can happen without violating NPOV, as we are simply providing an additional piece of information, which will be useful to some and unhelpful to others -- like anything else on Wikipedia. Maintaining a list of crisis hotlines is already a responsibility of the Wikimedia Foundation's Trust & Safety team. We have technical resources that would allow us to build, for example, geotargeted modules that show only the most relevant information based on a reader's country. We also have financial resources that we can use if needed, such as if a not-for-profit suicide hotline provider tells us that a website of our readership and reach needs to contribute back to their operating costs.
Similarly, we can also provide information regarding best practices for editing about suicide, which has been repeatedly raised to us by experts. The Manual of Style guidance on this point is a great first step.
If our volunteer communities are eager to make this change, but are concerned about the administrative difficulties of maintaining resources, please let us know; we would be happy to take on some of that burden. RGaines (WMF) (talk) 13:42, 17 September 2022 (UTC)
Most definitely NOT something we should be doing. --User:Khajidha (talk) (contributions) 11:13, 7 September 2022 (UTC)
Why not? Do you feel it's too patronising, or some other reason? Andreas JN466 11:34, 7 September 2022 (UTC)
We're an encyclopedia. Not a suicide hotline. This request is just as silly as asking McDonald's to print a suicide hotline on all of their burger wrappers. --User:Khajidha (talk) (contributions) 11:40, 7 September 2022 (UTC)
CNBC is a business website, not a suicide hotline. Why do so many sites have this notice anyway? It's because of Copycat suicide which has small triggers with great consequences.This is well understood and studied phenomenon these notices can have immediate life-saving impacts. -- GreenC 22:17, 7 September 2022 (UTC)
That's CNBC's problem. That they make a bad decision doesn't mean that we need to make the same bad decision. Lots of bad outcomes have small triggers or causes with great consequences that could conceivably be the subject of such notices that could have immediate life-saving impacts. None of which should be posted here. --User:Khajidha (talk) (contributions) 11:12, 8 September 2022 (UTC)
Why do so many sites have this notice anyway? I'm fairly cynical, but I'd not be at all surprised if it's for image and politics. Easy to quiet the activists who might otherwise try to create bad press for them by throwing a sentence or two at the end of a digital article. Anomie 11:49, 8 September 2022 (UTC)