Wikipedia:Village pump (proposals): Difference between revisions
Peteforsyth (talk | contribs) |
→Poor tooling: Reply |
||
Line 151: | Line 151: | ||
:Absolutely. A lot of systemic bias toward the English-speaking world tends to come through in discussions like this, with editors failing to realize how much content we lack in non-English speaking areas and how much Wikidata could help us there. Reminder: <em>Two thirds of all topics covered on Wikipedia don't have an article in English.</em> <span style="color:#AAA"><small>{{u|</small><span style="border-radius:9em;padding:0 5px;background:#088">[[User:Sdkb|<span style="color:#FFF">'''Sdkb'''</span>]]</span><small>}}</small></span> <sup>[[User talk:Sdkb|'''talk''']]</sup> 16:12, 8 November 2022 (UTC) |
:Absolutely. A lot of systemic bias toward the English-speaking world tends to come through in discussions like this, with editors failing to realize how much content we lack in non-English speaking areas and how much Wikidata could help us there. Reminder: <em>Two thirds of all topics covered on Wikipedia don't have an article in English.</em> <span style="color:#AAA"><small>{{u|</small><span style="border-radius:9em;padding:0 5px;background:#088">[[User:Sdkb|<span style="color:#FFF">'''Sdkb'''</span>]]</span><small>}}</small></span> <sup>[[User talk:Sdkb|'''talk''']]</sup> 16:12, 8 November 2022 (UTC) |
||
:Yes! Thank you for making this point. ENWP is able to be self-sufficient due to the large English-speaking community, but that isn't true of many languages outside the top 10 or 15 largest Wikipedias. Being able to pull data from Wikidata to get up-to-date information is really useful for smaller communities, and having the large community of ENWP helping verify and maintain that information along with the Wikidata community and the communities of other language WPs would be a huge boon. [[User:Nicereddy|Nicereddy]] ([[User talk:Nicereddy|talk]]) 17:26, 19 November 2022 (UTC) |
|||
== Extended-confirmed protection for TFAs == |
== Extended-confirmed protection for TFAs == |
Revision as of 17:26, 19 November 2022
Policy | Technical | Proposals | Idea lab | WMF | Miscellaneous |
The proposals section of the village pump is used to offer specific changes for discussion. Before submitting:
- Check to see whether your proposal is already described at Perennial proposals. You may also wish to search the FAQ.
- This page is for concrete, actionable proposals. Consider developing earlier-stage proposals at Village pump (idea lab).
- Proposed policy changes belong at Village pump (policy).
- Proposed speedy deletion criteria belong at Wikipedia talk:Criteria for speedy deletion.
- Proposed WikiProjects or task forces may be submitted at Wikipedia:WikiProject Council/Proposals.
- Proposed new wikis belong at meta:Proposals for new projects.
- Proposed new articles belong at Wikipedia:Requested articles.
- Discussions or proposals which warrant the attention or involvement of the Wikimedia Foundation belong at Wikipedia:Village pump (WMF).
- Software changes which have consensus should be filed at Phabricator.
Discussions are automatically archived after remaining inactive for nine days.
Wikidata lists
Should mainspace lists where the contents are pulled from and maintained at Wikidata be allowed or disallowed? Fram (talk) 07:25, 19 September 2022 (UTC) (edited same day at 13.35, see start of discussion section)
Summary (Fram)
There are a number of lists where the contents are pulled from Wikidata through Template:wdtable row, with specific subtemplates for different types of content. The result can be seen e.g. here. The Wikipedia-only version of the same list can be seen here. Previous RfCs (see Wikipedia:Wikidata#Appropriate usage in articles have already agreed that "Wikidata should not be linked to within the body of the article except in the manner of hidden comment" and that it is "not appropriate to use Wikidata in article text on English Wikipedia ", but allowing Wikidata in infoboxes and de facto also many in external links templates. Previous lists where not only the contents, but even the entries were Wikidata driven have been disallowed in the mainspace as well.
The new type of lists has a number of disadvantages compared to enwiki-based lists, i.e.
- it isn't maintainable here but requires going to another website with another interface, making it harder for most people (for the data)
- requires editing templates or creating new ones for the layout
- Has issues with e.g. sorting, see for example here where (with the current Wikidata data) sorting on the "opened" column gives a random "Apr 1998" data inbetween the blank dates, and sorts "17 Apr 1968" before 1917 and so on. This example shows also a typical issue with getting data from Wikidata like this, the formatting. Wikidata has "April 1998", so I suppose the "Apr 1998" entry is formatted in a template. This makes it again harder for regular editors to maintain or layout such articles.
- Similarly, at Talk:List of dams in Saga Prefecture an editor asked to remove the image column from the article, as they were unable to do this under the Wikidata format. This required the creation of a new template, instead of simply editing the article. Fram (talk) 07:41, 19 September 2022 (UTC)
- There are other more minor issues, like the name appearing in the list being the Wikidata label, not the enwiki article name, or the sourcing being inadequate (Wikidata items referenced to some Wikipedia version, often outdated (e.g. some of the entries on List of islands of the Isles of Scilly use the 2001 census instead of the 2011 census our articles use, indicating the glacial speed of update Wikidata often has) Fram (talk) 09:03, 19 September 2022 (UTC)
- See for example List of learned societies in Australia, with issues from the start (e.g. one entry with the incorrect Wikidata title instead of the correct enwiki title, and entries which don't even belong there like the Austronesian Formal Linguistics Association), and then made worse by an editor who probably couldn't figure out how to correctly add an entry[1]. This type of list is not editor-friendly at all. Fram (talk) 12:38, 19 September 2022 (UTC)
Summary (MSGJ)
Thank you for starting this discussion and inviting me to present an alternative viewpoint. First, some background for those who may not be familiar with Wikidata. This Wikimedia sister project, launched in 2012, is designed to hold data for use by Wikipedias and other sister projects. Its use on the English Wikipedia is not at all new - it has been used extensively in infobox templates for many years now - so its use in data tables and lists should not be surprising to Wikipedia editors. I really thought and hoped that the "us and them" attitude towards Wikipedia and Wikidata had diminished over the years.
Being designed for this purpose, Wkidata offers many advantages over conventional wikitext for storing reliable data, including:
- Numerous constraints which can catch incorrect data, such as incorrect units, a date of death before a date of birth, etc.
- A very user-friendly interface (almost certainly easier than editing wikitext for new editors). For example, compare how you would update the height of a dam on wikitext version compared with on Wikidata.
- Ability to use powerful queries to find information.
- And probably most importantly, improvements to the data by one project will be of benefit to all projects.
All data on Wikidata can (and should) be referenced, just as it is on Wikipedia. All changes can be monitored via RecentChanges (if you have the appropriate option selected).
The use of a template to produce the rows of the table has several advantages, including:
- The template allows any column to be overridden by locally defined content. For example on List of Welsh mathematicians the "Notes" column is entirely local content.
- The wikicode to produce rows and columns, which is complex for many editors, is conveniently separated from the content of the table.
- A column can be added or removed from the table by making a single change to the template, rather than dozens of changes to the wikitext.
- The pencil icon
links straight to where the data is stored.
Finally, a word on the previous discussions about the use of Wikidata on Wikipedia. A table is not classed as "article text" so the prohibition on using Wikidata for article text is not relevant here. And, regarding the linking to Wikidata, the only link is the pencil icon mentioned earlier which is widely used and accepted in infobox templates. — Martin (MSGJ · talk) 17:04, 19 September 2022 (UTC)
Discussion (Wikidata lists)
- @Fram: Two things: this is asking whether they're allowed, not whether they should be allowed. Is this about getting clarity of where past decisions have landed us, or deciding whether they should be allowed? If it's really just asking whether they're allowed, the list of reasons why they're bad seems out of place. If it's asking whether they should be allowed, you may want to edit the initial statement. The other suggestion is sort of dependent on the first, but you may want to separate the summary of where consensus stands from specific arguments about what our policy should be. The latter isn't so much a summary as arguments supporting one outcome. — Rhododendrites talk \\ 13:00, 19 September 2022 (UTC)
- Well, it's kind of a double question; are they allowed viz-a-viz the previous RfCs, and should they be allowed or not? I guess the second is more important than the first, as it's not intended as a "you did something that wasn't allowed" but more of a "this is how we'll proceed from now on". I'll change the RfC accordingly. Fram (talk) 13:35, 19 September 2022 (UTC)
- Initial thoughts (should I be creating my own section per above?): I have mixed feelings about Wikidata lists. On the bad side: technical limitations. Some of the things Fram lists seem like they could be fixable, but for others it's a matter of better integration of Wikidata in Wikipedia (in the sense of editing). The current templates, which send would-be editors to a Wikidata page with no explanation, are a bit clumsy (but, granted, an early step in the process). On the good side: I can see at least two good uses for Wikidata in Wikipedia lists. The first is as a starting point. If you want to make a lists of dams in a given place, that's something Wikidata has data for, and pulling from Wikidata could save a lot of time vs. hunting it down and formatting it yourself. Then you could convert it to wikitext and move on. I don't expect that's very controversial, though. The second case is when Wikidata pulls from databases that are more easily kept up-to-date than a Wikipedia list. We have an awful lot of out-of-date lists, and if it's an appropriate topic, why not let Wikidata gnomes keep it up to date? We just need more sophisticated templates to allow for flexibility in display and for fixing errors without sending someone on a journey to Wikidata. So I guess part of my answer (although per above I'm not sure which question I'm answering) is: yes, at some point these are useful, and I'd encourage people to shift the discussion from a binary yes/no to figuring out (a) in what contexts they're useful, and (b) if the current setup is inadequate, what changes to the interface and/or templates would be needed to ensure we can take advantage of this data in those cases when it's useful? — Rhododendrites talk \\ 13:23, 19 September 2022 (UTC)
- Thanks for this very astute comment. I will happily admit that the template can be improved (e.g. sorting on dates which is mentioned earlier), and any suggestions will be much appreciated — Martin (MSGJ · talk) 18:07, 19 September 2022 (UTC)
- My understanding from past RFCs is that we continue to be extremely wary of Wikidata, and have limited its use… but that, within those limits, it can be used.
- That said, I don’t think we have been very clear as to what exactly those limits ARE. We need to spell them out clearly. Do we have a guideline or policy section covering this? Blueboar (talk) 13:55, 19 September 2022 (UTC)
- I don't think its specific use in lists/tables has been put to RfC before. The closer of 2013 discussion wrote "There is a valid point raised that while running text is clearly not suitable for Wikidata use, it might be worth discussing use in tables specifically – but no consensus regarding this has been reached in this discussion." — Martin (MSGJ · talk) 18:09, 19 September 2022 (UTC)
- I would think that this is disallowed per the previous RfC, which stated that it is
not appropriate to use Wikidata in article text on English Wikipedia
. A list article is still an article. I've actually come across some of these lists before and wondered why they were using {{Wdtable row}} instead of {{Wikidata list}}. The presumable reason is that {{Wikidata list}} produces an error when used in mainspace due to the results of that RfC and others. The use of {{Wdtable row}} in mainspace articles strikes me as a clumsy workaround to skirt consensus. Spicy (talk) 16:31, 19 September 2022 (UTC)- Yes, a list is an article but the values in a table are not "article text", which I take to mean prose. Some tables combine values and prose, e.g. List of Welsh mathematicians, and the template will only produce the content for the values and not for the prose. — Martin (MSGJ · talk) 18:12, 19 September 2022 (UTC)
- I'm of a mind that we shouldn't encourage them, and don't personally use them, but if someone wants to put together say a rather exhausting list of plant species or something, Wikidata may simplify the process. If someone finds a clever way to use them, why stop them? I agree with Rhododendrites that we should focus on where they're best used and how to improve their usage. CaptainEek Edits Ho Cap'n!⚓ 16:54, 19 September 2022 (UTC)
- I agree with Rhododendrites - tables pulled from Wikidata are suitable for some uses and not from others. Where they are suitable I see no justification for either prohibiting or requiring their use (treat it like ENGVAR or citation styles: either version is acceptable, don't change without both a good reason and consensus). Where they aren't suitable obviously they shouldn't be used, but I hope nobody is advocating for that. We should work on making the integration better so that the problems identified are fixed rather than saying the first version is not perfect so go away and never come back again. I also suggest that developing a set of guidelines about where Wikidata tables are and are not appropriate for use to be a much better use of editors' time than arguing about whether they should or should not be used at all. Thryduulf (talk) 22:30, 19 September 2022 (UTC)
- In theory, I'm fairly open to tables containing entries from Wikidata. In practice, I'd like to see more working and non-working examples. I think there are a few other language Wikipedias with deeper Wikidata integration, but perhaps I am mistaken and that is all just infoboxes. There are also a lot of things where information is rather fuzzy, making Wikidata difficult to use. It is easy to annotate uncertain dates and debates around them in wikitext; learning how to do that on Wikidata is rather hard and certainly unintuitive for people used to Wikipedia. —Kusma (talk) 08:18, 20 September 2022 (UTC)
- Thanks for your comment. I am of the opinion that only a clear-cut value can be appropriately used from Wikidata. Anything which requires clarification or explanation should be locally defined. There are a couple of approaches I have used in these cases.
- For example on List of castles in Ireland#County Clare, the imprecise build date of Ballyhannon Castle is locally specified via
|c5=c. [[1490 in Ireland|1490]]<ref>{{harvp|Westropp|1899|p=351}}</ref>
- And on List of lighthouses in Scotland, I clarified the build date of Southerness Lighthouse by adding a footnote to the value from Wikidata via
|c5+={{efn|Built in 1748 but not lit till 1800. Rebuilt in 1844.}}
- For example on List of castles in Ireland#County Clare, the imprecise build date of Ballyhannon Castle is locally specified via
- — Martin (MSGJ · talk) 16:01, 21 September 2022 (UTC)
- Thanks for your comment. I am of the opinion that only a clear-cut value can be appropriately used from Wikidata. Anything which requires clarification or explanation should be locally defined. There are a couple of approaches I have used in these cases.
- I'll perhaps expand on my rationale later, but fundamentally, I support Wikidata-derived tables being allowed. It all comes down to implementation — if done well, the appearance to readers will be exactly the same as a manually generated article, and the Wikidata-derived one will be far more future-proof. {{u|Sdkb}} talk 06:03, 21 September 2022 (UTC)
- The only argument presented by people in favor of using Wikidata continuously (as opposed to using it once to generate a list) seems to be making things easier to keep up to date. But most uses of Module:Wikidata table are timeless: lists of dams, lighthouses, and castles, etc. don't need much updating (other than adding new entries if they are built, which still needs to be done manually in the Wikidata version), so in those cases that argument is not convincing. On the contrary, there's been no refutation to several of Fram's points above which amount to the fact that it will almost always be possible to further optimize such a list with local tweaks because humans are better at this then co. So what's the harm in detaching from Wikidata and letting that be done? I'm not seeing it. For the few that aren't timeless (List of Brazilian mathematicians, List of Welsh mathematicians and List of Polish mathematicians seem to be the only ones), there is a slightly better case for using Wikidata, and I haven't come to a strong opinion either way. * Pppery * it has begun... 17:43, 21 September 2022 (UTC)
- For me it is not only about the creation of the lists, but the future updates and improvements too. I do not expect these lists to stay the same for ever more - I really hope they will be expanded with more information and better references. I believe this is both easier and better in the Wikidata version. Easier, because of the structured environment which lends itself to data import and verification. Better, because the knowledge will be shared among all language Wikipedias. — Martin (MSGJ · talk) 19:19, 29 September 2022 (UTC)
- I would have thought the prohibition applied to lists and tables as well, but if that's not the consensus I would support extending the prohibition to lists and tables. No problem with using Wikidata to initially populate a table or list, of course; the onus is on the editor to make sure it's reliable data as with any edit. The problem of "sneaky vandalism", as I think Fram named it years ago, is real -- changes to Wikidata are not easily visible which means you may not know when your article has been vandalized, and even if it's detected a user who can edit here may be unable or unwilling to learn the quite different interface there. Re Rhododendrites' comment that it would be OK to have a table sourced to live Wikidata, knowing that the gnomes over there would keep it up to date -- I don't think anyone would be OK without outsourcing our table data to, say, Fishbase, for certain tables, so why would we be OK with it with an intermediary? Mike Christie (talk - contribs - library) 22:40, 21 September 2022 (UTC)
- Sneaky vandalism is a problem that can occur with any type of list. With watchlist integration, while not perfect, I can effectively patrol all changes to data which affect these articles. So I do not really accept that changes on Wikidata are invisible or hard to catcher than on Wikipedia. — Martin (MSGJ · talk) 19:23, 29 September 2022 (UTC)
- When I last tried "Show Wikidata edits in your watchlist" it added an incredible amount of noise that made the watchlist unusable. Has that changed? Johnuniq (talk) 01:25, 30 September 2022 (UTC)
- Yes, a couple of years ago. WMDE did the work, so it's probably documented at Meta-Wiki. The volume and relevance of notified changes seems to depend on the subjects that you're watching, so I suggest trying it out and seeing what you think for yourself/your own subjects. I feel like volunteer-me gets a surprisingly large number of notifications for Apology (act) and Apologia, but less than I expect for other subjects, like Lymphoma. Most of the changes I see are changes to the linked articles (e.g., someone creating an article at another language's Wikipedia about lymphoma). Whatamidoing (WMF) (talk) 22:32, 30 September 2022 (UTC)
- It's probably fair to say that there are still too many entries that make it through the filter. I don't need to know when someone changes the Bangladeshi label or adds a sitelink to the Hebrew Wikipedia. Really the only ones needed are those which affect the display of the relevant article, although an option to display all changes might be useful for some editors. — Martin (MSGJ · talk) 14:34, 1 October 2022 (UTC)
- Yes, a couple of years ago. WMDE did the work, so it's probably documented at Meta-Wiki. The volume and relevance of notified changes seems to depend on the subjects that you're watching, so I suggest trying it out and seeing what you think for yourself/your own subjects. I feel like volunteer-me gets a surprisingly large number of notifications for Apology (act) and Apologia, but less than I expect for other subjects, like Lymphoma. Most of the changes I see are changes to the linked articles (e.g., someone creating an article at another language's Wikipedia about lymphoma). Whatamidoing (WMF) (talk) 22:32, 30 September 2022 (UTC)
- When I last tried "Show Wikidata edits in your watchlist" it added an incredible amount of noise that made the watchlist unusable. Has that changed? Johnuniq (talk) 01:25, 30 September 2022 (UTC)
- Sneaky vandalism is a problem that can occur with any type of list. With watchlist integration, while not perfect, I can effectively patrol all changes to data which affect these articles. So I do not really accept that changes on Wikidata are invisible or hard to catcher than on Wikipedia. — Martin (MSGJ · talk) 19:23, 29 September 2022 (UTC)
- Question, if I wish to change or amend something in a table that uses Wikidata to generate info, would I have to go to Wikidata to make the edit, or can it be done using the edit mode here in WP? Say something simple like a style correction. Blueboar (talk) 01:46, 30 September 2022 (UTC)
- Taking the eventualist view, with future interface improvements, yes, you'll be able to stay on Wikipedia. Also, it's worth noting that tables generated through Wikidata are less likely to have errors to begin with because there are fewer elements being created manually. {{u|Sdkb}} talk 03:47, 30 September 2022 (UTC)
- So your "yes, you'll be able to stay on Wikipedia" is actually a "no". Deciding on the current status of such lists based on what might happen one day, perhaps (Wikidata is 9 years old, so it's not as if such changes happen rapidly) is not a good idea. So, @Blueboar: you indeed have to go to Wikidata to edit the info, Wikipedia edit mode won't help you. And Sdkb, your "less likely to have errors" doesn't seem to make much sense either, the elements are created manually at Wikidata or manually at enwiki, no reason why one would be less likely to have errors (on the one hand, Wikipedia has more editors and thus more vandals: on the other hand, vandalism on Wikidata is much more likely to stay undetected, see e.g. here where it took a full month until someone noticed that the page "Punjabi" had been moved (retitled) to "josh saunders", or here where it took more than a month for someone to notice that "Aaron Ramsey" was moved to "Penalty in the UEL final". Fram (talk) 07:37, 30 September 2022 (UTC)
- The reason Wikidata-derived tables have fewer errors is that, when you're adding a row through Wikipedia, you need to add both the data and the formatting, and each of those is a potential spot to mess up. I'm sure we've all seen tables that have an extra column used only in one row because someone put an extra "|-". When you're adding information on Wikidata, however, all you have to worry about is the data. And even there, constraint violations can help identify errors that Wikipedia would not have been able to flag, and data imports can help a single experienced editor add large amounts of high-quality information (rather than relying on piecemeal contributions by many different editors, any one of whom might mess up). {{u|Sdkb}} talk 15:26, 3 October 2022 (UTC)
- That's a rather anti-wiki position you take there. "relying on piecemeal contributions by many different editors" is what makes Wikipedia, and excluding these editors from pages is a good argument against Wikidata lists, not for them. (Never mind the countless times experienced editors made completely incorrect or botched mass updates of info on Wikidata of course). Fram (talk) 16:07, 3 October 2022 (UTC)
- I'm absolutely a fan of crowdsourced editing or I wouldn't be a Wikipedian. What I'm not for is forcing information that can be more efficiently handled in bulk to be handled piecemeal. That's why I oppose the wholesale deletion of template namespace, and also why I support the use of Wikidata. Neither of those things make me anti-wiki. Regarding the potential for errors in Wikidata imports, that potential exists in normal editing, too. I think the anti-wiki position would be to say that we should prohibit a type of editing entirely just because it's not done properly 100% of the time. {{u|Sdkb}} talk 18:18, 3 October 2022 (UTC)
the wholesale deletion of template namespace
Strewth!! Was that actually proposed? When? — GhostInTheMachine talk to me 19:15, 3 October 2022 (UTC)- I'm using it as a hyperbolic analogy here, but there are certainly examples of resistance to template usage for things like census data that I'd say fall at a milder point along the same spectrum. {{u|Sdkb}} talk 20:54, 3 October 2022 (UTC)
- I'm absolutely a fan of crowdsourced editing or I wouldn't be a Wikipedian. What I'm not for is forcing information that can be more efficiently handled in bulk to be handled piecemeal. That's why I oppose the wholesale deletion of template namespace, and also why I support the use of Wikidata. Neither of those things make me anti-wiki. Regarding the potential for errors in Wikidata imports, that potential exists in normal editing, too. I think the anti-wiki position would be to say that we should prohibit a type of editing entirely just because it's not done properly 100% of the time. {{u|Sdkb}} talk 18:18, 3 October 2022 (UTC)
- That's a rather anti-wiki position you take there. "relying on piecemeal contributions by many different editors" is what makes Wikipedia, and excluding these editors from pages is a good argument against Wikidata lists, not for them. (Never mind the countless times experienced editors made completely incorrect or botched mass updates of info on Wikidata of course). Fram (talk) 16:07, 3 October 2022 (UTC)
- The reason Wikidata-derived tables have fewer errors is that, when you're adding a row through Wikipedia, you need to add both the data and the formatting, and each of those is a potential spot to mess up. I'm sure we've all seen tables that have an extra column used only in one row because someone put an extra "|-". When you're adding information on Wikidata, however, all you have to worry about is the data. And even there, constraint violations can help identify errors that Wikipedia would not have been able to flag, and data imports can help a single experienced editor add large amounts of high-quality information (rather than relying on piecemeal contributions by many different editors, any one of whom might mess up). {{u|Sdkb}} talk 15:26, 3 October 2022 (UTC)
- And in at least one proposal to implement a list from Wikidata that I examined, the one list of items here would have been replaced with code that got items from dozens of different pages at Wikidata. In other words, the attack surface for vandalism would have been multiplied dozens of times, and manual checking of Wikidata items would have been dozens of times more difficult than looking at wikitext here. Johnuniq (talk) 09:12, 30 September 2022 (UTC)
- So your "yes, you'll be able to stay on Wikipedia" is actually a "no". Deciding on the current status of such lists based on what might happen one day, perhaps (Wikidata is 9 years old, so it's not as if such changes happen rapidly) is not a good idea. So, @Blueboar: you indeed have to go to Wikidata to edit the info, Wikipedia edit mode won't help you. And Sdkb, your "less likely to have errors" doesn't seem to make much sense either, the elements are created manually at Wikidata or manually at enwiki, no reason why one would be less likely to have errors (on the one hand, Wikipedia has more editors and thus more vandals: on the other hand, vandalism on Wikidata is much more likely to stay undetected, see e.g. here where it took a full month until someone noticed that the page "Punjabi" had been moved (retitled) to "josh saunders", or here where it took more than a month for someone to notice that "Aaron Ramsey" was moved to "Penalty in the UEL final". Fram (talk) 07:37, 30 September 2022 (UTC)
- If I need to go to WD to edit WP… that is a deal breaker for me. So put me down as still opposed. Blueboar (talk) 11:26, 30 September 2022 (UTC)
- Taking the eventualist view, with future interface improvements, yes, you'll be able to stay on Wikipedia. Also, it's worth noting that tables generated through Wikidata are less likely to have errors to begin with because there are fewer elements being created manually. {{u|Sdkb}} talk 03:47, 30 September 2022 (UTC)
- I remain extremely sceptical about the value of using Wikidata directly in articles for anything, although obviously compiling a list/table using Wikidata, and then disassociating it, is completely acceptable. As is using it in project space, and potentially talk pages. It makes editing the content nearly impossible for those not used to Wikidata, and it makes watching the page for changes completely impossible. ETA: For instance, List of Welsh mathematicians, linked above as an example, contains entries with three inline sources for things like date of birth, presumably unnecessary (and if the sources disagree, this should be footnoted), and has abbreviated months, which is not Wikipedia style but can't be edited within the Wikipedia page. The repeated edit links are also obtrusive. Espresso Addict (talk) 05:44, 1 October 2022 (UTC)
- Thanks for your comments.
- MOS:DATES suggests that abbreviated dates like 2 Sep 2001 or Sep 2, 2001 are acceptable in tables. I think the full unabbreviated dates would take up too much space in most tables.
- Do you have any suggestions to make the edit links less obtrusive? They are necessary to allow editors to change the values, but are only currently visible to logged in users.
- The maximum number of references is set at 3 and could be reduced further.
- — Martin (MSGJ · talk) 14:32, 1 October 2022 (UTC)
- Thanks for your comments.
- "Sep" as an abbreviation for September looks very odd in UK English, which would appertain to a list of Welsh people. The problem is the lack of easy-to-understand customisation. If I have five sources for a dob, I can choose to include only say no 3 because it is reliable & accessible, or put in two sources because one is highly reliable but not readily accessible, and another less reliable but accessible, &c&c. I have absolutely no idea how to do that within Wikidata, and no desire to have to learn a new and cumbersome editing interface. Also using things like n/a for the death date of a living person feels disrespectful. No clue how to make the edit links less prominent; I dislike them in infoboxes, but there's usually plenty of whitespace there to absorb them. Perhaps if they only showed in edit mode, somehow? And how are logged-out editors supposed to amend things? Espresso Addict (talk) 23:44, 1 October 2022 (UTC)
- @Espresso Addict: absolutely. If you are curating a list/table to such a degree then you will almost certainly want to forgo the convenience of the template and gain the greater flexibility. But 99% of lists are not like this, many of which are a bare list of links without additional information or references. For these, the template can produce a nice looking table with more detail, and is more likely to stay up to date. PS I use "Sep" all the time as an abbreviation for September, and it doesn't look odd to me! — Martin (MSGJ · talk) 15:51, 3 October 2022 (UTC)
- "Sep" as an abbreviation for September looks very odd in UK English, which would appertain to a list of Welsh people. The problem is the lack of easy-to-understand customisation. If I have five sources for a dob, I can choose to include only say no 3 because it is reliable & accessible, or put in two sources because one is highly reliable but not readily accessible, and another less reliable but accessible, &c&c. I have absolutely no idea how to do that within Wikidata, and no desire to have to learn a new and cumbersome editing interface. Also using things like n/a for the death date of a living person feels disrespectful. No clue how to make the edit links less prominent; I dislike them in infoboxes, but there's usually plenty of whitespace there to absorb them. Perhaps if they only showed in edit mode, somehow? And how are logged-out editors supposed to amend things? Espresso Addict (talk) 23:44, 1 October 2022 (UTC)
- Unless it can be altered on ENWP without going to Wikidata, I am in line with the previous consensus that wikidata imported content should not be used in article space except under the very limited exceptions. If it can be amended on ENWP and draw through to Wikidata, all my concerns disappear. Keep in mind those exceptions exist precisely because of the issues with Wikidata, chiefly its another project with its own rules and policies, its own admins, far less active users to combat deliberate vandalism, BLP violations etc. Importing lists that include living people is most BLP-watchers nightmare when you have to go to other projects to rectify it. (The same issues exist with imported commons content but at least thats relatively simple to fix). Being able to alter the content as it displays on ENWP, while on ENWP, without having to go to another project would seem to be something the WMF's tech tech could spend some time & cash doing (hint, its not difficult as anyone who has worked with a data warehouse and multiple databases knows) instead of whatever waste of time they are concentrating on. Only in death does duty end (talk) 16:22, 1 October 2022 (UTC)
- Frankly, I read the spirit of the various RFCs on wikidata as being pretty clearly against their use in making articles - so the claim that a table isn't "article text" and so it is fine to make tables from wikidata ... strikes me as very much a rules-lawyering type of statement. I wish that the proponents of wikidata would quit pushing it in such ways - it doesn't help their "cause". Ealdgyth (talk) 13:29, 3 October 2022 (UTC)
- The past RfCs have explicitly considered Wikidata use in tables and found no consensus on the question, so I'm not sure where you're getting that it goes against their "spirit" other than that you're reading your preferred opinion into them. Your idea of "pushing" can just as easily be flipped: I wish that those who fail to see Wikidata's potential would quit resisting it in such ways. {{u|Sdkb}} talk 15:19, 3 October 2022 (UTC)
- Its more that we do see the potential ... for abuse. And there needs to be either a strong mitigation or exceptional reason in place to ignore that risk. Which when it comes to wikidata, there rarely is. Only in death does duty end (talk) 16:47, 3 October 2022 (UTC)
- Particularly for lists that include BLPs, there is potential for BLP violation going unnoticed; a particularly common form of vandalism is to state a living person is dead, or less malevolently, to believe unreliable sources and assume incorrectly that death has occurred. This happens time and time again, and requires careful oversight. Espresso Addict (talk) 22:13, 3 October 2022 (UTC)
- Its more that we do see the potential ... for abuse. And there needs to be either a strong mitigation or exceptional reason in place to ignore that risk. Which when it comes to wikidata, there rarely is. Only in death does duty end (talk) 16:47, 3 October 2022 (UTC)
- No, Wikidata has been repeatedly banned from the body of the article. Every time a Wikidata-activist tries to shove Wikidata into the body of the article there is always consensus against it, they can't even get consensus for infoboxes. That's stuck in no-consensus. It appears that the only way to stop the recurring and disruptive creeping rollout-contrary-to-consensus by Wikidata-enthusiasts is to entirely shut off the calls to Wikidata in Wikitext itself. As long as it's available they just keep cooking up new ways to shove it out unilaterally. Alsee (talk) 06:50, 7 October 2022 (UTC)
- Additional issue: editing of tables like this in Visual Editor is nearly impossible and gives, for the few things it can do, very poor results. I tested this with List of dams in Tochigi Prefecture. Compared to "normal", non-Wikidata lists, here I can only add a new line at the top, not anywhere else in the list, and the result is badly formatted. I don't know if the WD list template can be changed to solve these issues, but if not, I don't think it is acceptable to introduce new things into Wikipedia which are incompatible with Visual Editing (even though I loathe it, it is used by a fair percentage of people and many new editors, and making it impossible for them to edit a type of articles is not anything that should be tolerated). Fram (talk) 10:04, 13 October 2022 (UTC)
- That could be partially mitigated through proper use of TemplateData. {{u|Sdkb}} talk 14:06, 13 October 2022 (UTC)
- How so? My remark about the template is not that an editor won't know that they need to add the wikidata template or add a Qnumber, but that even with that information, you can't produce a good result in VE. Perhaps I am missing something, but I don't think Templatedata can solve or even mitigate the underlying technical issue. Fram (talk) 14:26, 13 October 2022 (UTC)
- VisualEditor at this point is capable of doing anything with templates that source editor can do, I believe. Having good TemplateData makes the interface easier for editors. {{u|Sdkb}} talk 17:56, 13 October 2022 (UTC)
- Have you actually tested this, e.g. with List of dams in Tochigi Prefecture? Try to add e.g. a new dam in the middle of the list, or to move one of the existing entries up or down. TemplateData won't change anything about this functionality. Fram (talk) 18:32, 13 October 2022 (UTC)
- VisualEditor at this point is capable of doing anything with templates that source editor can do, I believe. Having good TemplateData makes the interface easier for editors. {{u|Sdkb}} talk 17:56, 13 October 2022 (UTC)
- How so? My remark about the template is not that an editor won't know that they need to add the wikidata template or add a Qnumber, but that even with that information, you can't produce a good result in VE. Perhaps I am missing something, but I don't think Templatedata can solve or even mitigate the underlying technical issue. Fram (talk) 14:26, 13 October 2022 (UTC)
- This is a valid point, and I have made a start on creating TemplateData for this template, which can be observed on List of dams in Tochigi Prefecture. I do not know if rows can be added in different places, but I will seek advice on this. — Martin (MSGJ · talk) 12:08, 14 October 2022 (UTC)
- Thanks. Adding entries anywhere in the list is just one of the issues, you e.g. also can't delete the existing ones, and when you add a new line at the top (using the Wikidata template) it only fills the first cell, instead of filling the table as it should (no idea if this list is exhaustive, I stopped testing after this). Templatedata helps at editing the already existing lines (though not removing them or moving them inside the table), but does nothing to make the editing of the table possible. Just tested again at List of dams in Toyama Prefecture, and the new Templatedata is good (e.g. overriding an existing row label), but no solution to the fundamental issue. Fram (talk) 12:47, 14 October 2022 (UTC)
- That could be partially mitigated through proper use of TemplateData. {{u|Sdkb}} talk 14:06, 13 October 2022 (UTC)
- Thanks for the interesting discussion. I came here after participating in Wikipedia:Articles for deletion/List of CryEngine games and Category:Video games by game engine, and I was pointing people to here to see if a bigger discussion could be had. However this discussion is interesting with respect to the deletion discussion, as one suggested solution to prevent information being deleted was actually using WikiData to store the information, and not need categories or lists, and for users who are interested they could pull the data out of Wikidata. I've read with interest everyone's positions, and I agree with user User:Rhododendrites and User:CaptainEek. We should absolutely not force people to use them, but if editors use them appropriately that is also fine. I feel that inboxes and tables are good uses. Perhaps *not* inline text *for the moment* - we need to still make Wikipedia useful to casual editors and this is likely a step too far. However a table in the text is fine. With the original RfC being done in 2013 (as noted above), it is likely a good time to revisit the topic. I think we should use structured data in tables to help WP articles, and the benefit is that using it consistently means that updating information in WikiData updates it on all language Wikipedias (?potentially even other wikis such as WikiVoyage). The downside is single point of failure; however also single point of fixing - this may need other policies e.g. only logged in edits on WikiData. However may be better for consistency than some pages in WP where information on the same topic is markedly different as pages have not all be updated simultaneously. The application to lists for data is something I'm equivocal about. I hate a lot of list pages and think they should be better categorised, however there are supporters and detractors to this method of organisation as well. I do not like deleting referenced information, and if there was a way of archiving and easily searching it via WikiData I would be all for that. It would be nice if in future a "WikiData Explorer" page type was created where we could just pass it a search string to autogenerate data so we could get rid of lists. This is one for the future. However in the meantime I think we need to at least try improving our use of structured data - not ban but also not force its use. And if it doesn't work go back to normal tables. I quite like the WikiData sourced list of dams provided by the OP. Out of interest for User:Fram - I looked at the example you gave at List of learned societies in Australia. It was interesting as I think the table is generated by passing individual IDs - my futurist hat btw would be looking at this and saying in future it should be "table = learned society + based in australia -> autogenerate table with these fields". Why is this not a case of taking the ID code pointing to the wikidata entry out of there? This kind of error would also be made if manually creating the table, and isn't a commentary on why not to use wikidata for information. It's more a comment on how if you're not careful incorrect information can be put in any type of table, and what I get out of this is that if we truly passed a query to a database (if we made sure we had properly structured data) the presented information would be "better". Or have I missed the point here? - Master Of Ninja (talk) 07:42, 14 October 2022 (UTC)
- Thanks for sharing your comments.
- No one is suggesting using data for inline text, and I can't think of a situation when that could be appropriate.
- The reason that each row of the table is produced seperately is to allow human editors to override the data with locally defined content.
- I agree completely with your comments on keeping tables updated.
- There are all sorts of ways to browse Wikidata already, and Wikipedia is not really needed for that. See wikidata:Wikidata:Tools/Visualize data for ideas.
- I can see the possible benefit, if someone is searching for a list which we do not yet have on Wikipedia, of linking to an automatically generated list. But there would be a lot of technical and policy issues to navigate.
- — Martin (MSGJ · talk) 12:21, 14 October 2022 (UTC)
- Thanks for sharing your comments.
- Not only does Wikidata have questionable sourcing and verifiability policies not fully compatible with Wikipedia, but I wonder if folks would consider whether it's worth the trouble to make editing list pages even more complicated than they already are? I hate having to jump back and forth between Wikipedia and Wikidata just to manage interwiki links, and it would be an absolute nightmare if it was allowed to make up significant chunks of actual list content. Just say no to more complex articles, so we can focus more on encyclopedic content and less on formatting or template garbage. As for the idea that Wikidata is easier to edit than Wikipedia... I am highly skeptical of this claim, given that I think the average person couldn't even define what a knowledge graph is, much less find out how to add a statement to a Wikidata page. For new and anonymous editors in particular, it is likely extremely confusing to click edit on a cell in a Wikipedia list and then be taken to the read mode of an entirely different website that 99% of our readers have probably never heard of at all. Steven Walling • talk 20:41, 17 October 2022 (UTC)
- On a procedural note: it seems clear from previous RFCs that existing consensus is toward disallowing Wikidata use in articles. It should almost certainly be removed from any existing lists unless and until a new consensus supporting it develops. Steven Walling • talk 21:01, 17 October 2022 (UTC)
- Sorry for late comment but I only just saw this discussion. As an occasional compiler of lists of power stations in non-English speaking countries I support the use of Wikidata in lists. There are often new or retired power stations and keeping such a list up to date in 2 languages is too much work without Wikidata. Chidgk1 (talk) 19:10, 30 October 2022 (UTC)
- But I just looked at the template mentioned and I am pretty sure I will not use it as it seems more work than {{Wikidata list}}. I will just leave the English article out of date unless {{Wikidata list}} is allowed here Chidgk1 (talk) 19:47, 30 October 2022 (UTC) *
- It might be easier for some editors to pull data from WD, but using it in a WP article can make it impossible for other editors to edit.
- But I just looked at the template mentioned and I am pretty sure I will not use it as it seems more work than {{Wikidata list}}. I will just leave the English article out of date unless {{Wikidata list}} is allowed here Chidgk1 (talk) 19:47, 30 October 2022 (UTC) *
- To share my own experience … I went to WD and simply could not figure out how to edit it. I don’t even understand its basic structure, much less it’s coding. I was completely baffled. The thing is, Wikipedia is supposed to be an encyclopedia that anyone (including me) can edit. When an article pulls data from WD, it means that I simply can not edit that data. That is a fundamental flaw. Blueboar (talk) 19:51, 30 October 2022 (UTC)
- This unfortunately is my experience too. The idea of Wikidata seems so good, put having tried to use it the implementation of that idea is terrible. That is aside from the implementation of interfacing in Wikipedia to Wikidata. The chances of a new editor trying to edit a Wikipedia page being aware, let alone able, to edit Wikidata to achieve there edit is zero. I have also struggled with trying to edit Wikidata, and having to do so to fix minor issue is a major headache. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 19:03, 5 November 2022 (UTC)
- To share my own experience … I went to WD and simply could not figure out how to edit it. I don’t even understand its basic structure, much less it’s coding. I was completely baffled. The thing is, Wikipedia is supposed to be an encyclopedia that anyone (including me) can edit. When an article pulls data from WD, it means that I simply can not edit that data. That is a fundamental flaw. Blueboar (talk) 19:51, 30 October 2022 (UTC)
- Strongly support allowing the use of Wikidata and {{Wikidata list}} in lists. I'll make my case in the first paragraph, and respond to opposition in the second one.
- Wikidata gives us an enormous advantage: structured data. It'll be highly beneficial to transition more content to Wikidata anyway, thanks to the fantastic meta:Abstract Wikipedia project. It improves verifiability and reliability across Wikipedias (since all data is in one place); allows editors from all languages to contribute to the same database, which automatically gets updated across all Wikipedias (reducing Anglo-centric bias); and will likely help these very low-visibility articles stay "fresh". Using more structured data is vital to reducing our maintainability burden, saves tons of time with adding images and data on separate Wikipedias, and future-proofs the encyclopedia for projects like Abstract Wikipedia.
- Most of the counterarguments I've seen result from current deficiencies in Wikidata. That doesn't mean we shouldn't use it; we should seek to improve it. It's a collaborative Wikimedia project too, not some kind of exogenous imposition. Some Wikidata pages can't be edited by even established editors here, who lack user rights on Wikidata, due to semi-protection; that should be fixed by switching to a "pending changes" or "edit request" model. Wikidata being edited on a separate website, not here, is a good thing, since it makes it clear that people are changing the structured data, not its presentation. I find {{Wikidata list}}s significantly easier to edit. Some criticized Wikidata's verifiability policy, but they're explicitly based on enWiki's guidelines.
- I'm only addressing whether Wikidata should be blanket-banned in tables/lists; not whether it should be mandated. Page-specific consensus still reigns; I just don't want the consensns of a few dozen editors here (you gotta concede this is a low-visibility page) to bind our hundred thousand active editors. DFlhb (talk) 09:30, 8 November 2022 (UTC)
- Unfortunately the discussions to include also have low participation as well, and of course WP:LOCALCONSENUS. Maybe it's time to have a site wide discussion of somesort. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 17:45, 8 November 2022 (UTC)
- This is a sitewide discussion. * Pppery * it has begun... 17:50, 8 November 2022 (UTC)
- Nevermind. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 18:14, 8 November 2022 (UTC)
- This is a sitewide discussion. * Pppery * it has begun... 17:50, 8 November 2022 (UTC)
- Unfortunately the discussions to include also have low participation as well, and of course WP:LOCALCONSENUS. Maybe it's time to have a site wide discussion of somesort. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 17:45, 8 November 2022 (UTC)
Poor tooling
The arguments here are transferable to a number of other sister projects, like Commons, which suffer from many more problems than enwp and wikidata, including low adminship, tooling, limited i18n and yet it is the standard way to insert images in enwp, despite the built in tooling that enwp has for hosting files. If the goal is to solely focus on enwp and screw other language editions of Wikipedia, then yes wikidata/commons can feel like overkill at times. Wikidata is one of the few projects, that leverage the knowledge and expertise of non English editors, that can directly benefit enWP, and likewise allow english editors to benfit other language editions. We should celebrate that instead of admonishing it. I am sympathetic to many comments here, about difficulty in editing, and leave the recommended/preferred solution per specific articles (list of plants versus evolving breaking news section). ~ 🦝 Shushugah (he/him • talk) 15:25, 8 November 2022 (UTC)
- Absolutely. A lot of systemic bias toward the English-speaking world tends to come through in discussions like this, with editors failing to realize how much content we lack in non-English speaking areas and how much Wikidata could help us there. Reminder: Two thirds of all topics covered on Wikipedia don't have an article in English. {{u|Sdkb}} talk 16:12, 8 November 2022 (UTC)
- Yes! Thank you for making this point. ENWP is able to be self-sufficient due to the large English-speaking community, but that isn't true of many languages outside the top 10 or 15 largest Wikipedias. Being able to pull data from Wikidata to get up-to-date information is really useful for smaller communities, and having the large community of ENWP helping verify and maintain that information along with the Wikidata community and the communities of other language WPs would be a huge boon. Nicereddy (talk) 17:26, 19 November 2022 (UTC)
Extended-confirmed protection for TFAs
Recently many TFAs are extended-confirmed locked because of vandalism caused by auto-confirmed accounts. It seems that there's someone that is dedicated enough to intentionally lock these articles up, seemingly just because they can. Evidence: Megalograptus, Borodino-class battlecruiser, Sayfo, Second Punic War (4 most recent TFAs), and more.
Is it by any means possible for the TFA protector bot to ECP FAs pre-emptively? Magnatyrannus (talk | contribs) 01:50, 22 October 2022 (UTC)
- Replying so that this thread doesn't get archived... Magnatyrannus (talk | contribs) 01:35, 31 October 2022 (UTC)
- I would be hesitant to preemptively protect these as they often see productive editing when not protected due to vandalism. ScottishFinnishRadish (talk) 01:39, 31 October 2022 (UTC)
- I'll try to look into the specifics of what prompted this in a bit. From a technical perspective it is certainly possible but probably unwise, admitting I'm generally in favor of allowing new and unregistered users to edit unless there is very good reason not to. 74.73.224.126 (talk) 23:00, 7 November 2022 (UTC)
- Well, it depends on whether most of the constructive edits on such TFAs are from Extended-confirmed users or auto-confirmed or non-registered users. --Magnatyrannus (talk | contribs) 23:17, 7 November 2022 (UTC)
- That's a fair point, and we could do some analysis grouping TFA editors into those with 0-9, 10-499, and 500+ edits. That aside, the numbers game isn't really the best way to look at this. Reverts are cheap, error checking is not. It takes far less time to revert a dozen disruptive edits than to go over even a single mid-sized section for issues, so I'm willing to deal with a fair amount of random disruption to get those adventitious catches by new and unregistered users that were not spotted during review. I will admit that when dealing with determined LTAs semi, and even ECP may be the only way to control disruption, which is why I need to look over the histories you referenced when I have some time. 74.73.224.126 (talk) 23:53, 7 November 2022 (UTC)
- I looked this over earlier. I can understand why you made this suggestion, and there are clearly one or more LTAs periodically conducting sustained vandalism on TFAs, but it's not continuous (from spot checking going back 6 months), and the page is pretty closely monitored. Now, sometimes bad edits have stayed live for 10-15 minutes, but that's usually the result of novice autoconfirmed editors breaking templates/formatting due to not understanding how they work; once autoconfirmed an accounts edits are less likely to be flagged for review by the tools RCPs use which explains the lag.
- Obviously we want to leave oversightable content up for the least time practical (true everywhere), but using preemptive ECP or even semi, is a rather blunt solution, using a sledgehammer to crack a nut if you will.
- I am open to adding adding a note, somewhat similar to the TFA 3RR exception, that allows sysops considerable leeway in applying either semi or ECP to TFA, even preemptively, but also encourages the use of judgement and cautions against protecting casually, and yes that would need a lot of wordsmithing.
- If an LTA has added oversightable content to a page a few days in a row then it may make sense to apply preemptive ECP for a short time, just don't publicly say how long or they'll wait it out, so they get discouraged and move onto something else. Another related tactic is to apply protection for the full day when disruption starts then later manually remove at an unpredictable time so the LTA isn't waiting to jump back on and disrupt again.
- In the past we have had even worse LTAs attack TFA and protection was applied preemptively (essentially per IAR) without too much of a fuss, but only for a limited period of time. There's also a few LTAs that have made it their mission to force us to protect as many pages as possible because they despise our open nature, and I really don't want to let them have their way.
- I also think that people exaggerate the effect of vandalism on the reputations of individual articles or Wikipedia as a whole. Wikipedia vandalism is an internet meme, everyone knows about it, and recognizes what it is. Some may even become involved in editing for the first time by reverting or removing it I did, a long time ago. What really harms our reputation are non-obvious errors, especially if they propagate and are later traced back to us. I saw a random IP fix a subtle category error on a TFA a few weeks back that had eluded all review; I'm willing to press the undo button a lot of times to get those kind of fixes.
- Anyway I'm willing to hear you out if you have any ideas. I'll be on Wikibreak again for a few weeks, or maybe a few months starting sometime tomorrow. But even if this archives you're always welcome to leave a message on my talk page. 74.73.224.126 (talk) 23:15, 10 November 2022 (UTC)
- Well, it depends on whether most of the constructive edits on such TFAs are from Extended-confirmed users or auto-confirmed or non-registered users. --Magnatyrannus (talk | contribs) 23:17, 7 November 2022 (UTC)
RfC on the banners for the December 2022 fundraising campaign
![]() |
|
Are the WMF's banners for the December 2022 fundraising campaign appropriate? If they are not, what changes need to be made before the campaign can start?
Note that due to the WMF not providing a complete listing, only four examples are available; a sampling of banners run by the WMF between September and November 2022 may be indicative of what content the other banners will contain. 05:47, 23 October 2022 (UTC)
Name | Banner | Sticky Banner |
---|---|---|
Desktop large | To all our readers in Country, |
If Wikipedia has given you $2.75 worth of knowledge this year, take a minute to donate. |
Desktop small | We ask you, humbly: don't scroll away. |
This isn't a paywall |
Mobile large | To all our readers, |
None |
Mobile small | Hi. This isn’t the first time we’ve interrupted you recently, but only 2% of our readers give. This Day we humbly ask you to help sustain Wikipedia. We don't run ads, and we never have. All we ask is $2.75 if you can afford $2.75, or $25 if you can afford $25. Please don’t scroll away. |
Please, don’t ignore this message: be the rare exception who gives us $2.75. |
See below for comment from the WMF.
Survey (2022 fundraising banners)
If opposing, please specify what changes need to be made to the banners before the campaign can start.
- Satisfied (the phrasing of the RfC feels...odd. Anything that isn't an "oppose" is inherently a support, as that's what the default is) - while there are changes I would like, and the tone is somewhat "whiny" through the repeated recalls, it is a significant improvement over those of the past year or two. The desktop ones are not as drastic visually (though the mobile ones are), and the text is not indicative of imminent bankruptcy as it was, which is also a significant improvement. I'd advise those "opposing" to split their changes into "what are the minimum changes do I need to not oppose" and "what changes should be made, in toto". Nosebagbear (talk) 22:31, 14 November 2022 (UTC)
- @Nosebagbear: Do you know where examples of previous banners and emails can be found? It'd be nice to compare them side by side for those of us who weren't involved in this last year; I can draw an idea of what about the wording I don't like, but I don't know what's changed from previous years and what hasn't.—Ineffablebookkeeper (talk) ({{ping}} me!) 22:46, 14 November 2022 (UTC)
- #Comment_from_the_WMF might help. Seddon talk 23:20, 14 November 2022 (UTC)
- @Nosebagbear: Do you know where examples of previous banners and emails can be found? It'd be nice to compare them side by side for those of us who weren't involved in this last year; I can draw an idea of what about the wording I don't like, but I don't know what's changed from previous years and what hasn't.—Ineffablebookkeeper (talk) ({{ping}} me!) 22:46, 14 November 2022 (UTC)
- Strong Oppose The basic problem I have remains unchanged: the implication that money donated is primarily for the day-to-day upkeep of Wikipedia when, in fact, the money is used at the behest of the WMF board, only some of the uses which include Wikipedia. Far, far more is raised and requested than is actually used directly on Wikipedia sites. The board ought to be free to argue in favor of the WMF's nebulous "movement" expenses, the opaque financial relationship with Tides, the poorly documented payroll bloat that has little to do directly with Wikipedia, and fattening the Endowment, but those uses should be directly laid out to donors, not hidden behind "keeping Wikipedia independent." CoffeeCrumbs (talk) 22:45, 14 November 2022 (UTC)
- While I did not initially address that and only looked at the financial plea, I fully support @Bilorv's follow-up about including other ways that people can make Wikipedia better besides money. CoffeeCrumbs (talk) 23:02, 14 November 2022 (UTC)
- Strong oppose all banners. Where to begin? 5P1 says that Wikipedia is not an advertising platform. Donors' money goes, it seems, towards the Tides Foundation, though transparency over WMF donations is decreasing. The use of donations is not made clear in these banners, which say things like:
If you donate just $2.75, or whatever you can this Tuesday, Wikipedia could keep thriving for years. The price of a cup of coffee is all we need.
This is a lie. If every reader donated just $2.75 then next year we'd see a banner saying "If every person reading this donated just $5.50, our fundraising campaign would be over". It is already true from a financial perspective thatWikipedia could keep thriving for years
if the WMF's money was decimated (literally, divided by 10). These banners provably guilt people into donating money they would be better off keeping for their own living costs. The English Wikipedia serves a large number of readers worldwide, many of whom live in countries where incomes are much smaller than the U.S. Even for donations within the U.S. and similar countries, many readers are pressured to give more than they should. Read Thomas' comment here: meta:Talk:Fundraising/Archive_6#Shame_on_you_WMF!_Shame! I have heard from those that run OTRS that these messages are commonplace, though Thomas' was a rare on-wiki one. More fundamentally, the nature of banners asking readers to donate misinforms them about how they can support Wikipedia. We have a crisis of lack of admins. We have a crisis of small bus factors in areas from NPP to bot maintenance. We have a crisis of editor retention. The principal way that a reader can support a wiki is by editing. Where are the editor recruitment banners? With our numbers in decline and malicious agents (UPE) on the rise, there has never been a more harmful time for our website to seemingly promote donation of money as the primary way in which readers can support Wikipedia. The Wikimedia Foundation has exceeded its Endowment target. Why are they actively fundraising? What is the target amount for the current fundraising period, which group of volunteers has undersigned the target, and when will the fundraising end? Until the en.wiki community actively endorse the WMF's fundraising target, there should be no banners on our website. — Bilorv (talk) 22:48, 14 November 2022 (UTC) - Oppose While the example banners are an improvement over previous years they do contain some problematic content and the sample banners are worse. In the example banners, key issues are the implication that Wikipedia is under threat; these are less explicit than in previous years, but need to be removed entirely (
humbly ask you to protect Wikipedia
,please take a minute to secure [Wikipedia's] future by making a donation
,This day we ask you to help us sustain Wikipedia
). The sample banners also present worse examples of this, likehumbly ask you to defend Wikipedia’s independence
.A similar issue is with the implication in some banners that Wikipedia might need to resort to advertising or a subscription service to remain online if donations fall. This can be seen prominently in the sample banners which say things like
We don’t charge a subscription fee, and Wikipedia is sustained by the donations of only 2% of our readers. Without reader contributions, big or small, we couldn’t run Wikipedia the way we do.
, but it can also be seen in the example banners which sayWe don't run ads, and we never have ... Without reader contributions, we couldn’t run Wikipedia the way we do.
I also oppose the section on
Here’s what your donation enables:
; given the issues we have had receiving support from the WMF in key areas such as New Page Patrol and WP:THEYCANTHEARYOU it seems dishonest to place so much focus on improvements the WMF make to Wikipedia and the support the WMF provides for volunteers.The banners should also make clear the distinction between the WMF and Wikipedia; one of the sample banners did this (
we humbly ask you to support the Wikimedia Foundation, the nonprofit that hosts Wikipedia.
), and I believe all banners should do the same.Finally, the WMF said that in response to editor concerns they no longer use the term
98% of our readers don't give; they simply look the other way
. As such, it is disappointing that they continue to use phrase98% of our readers don't give; they keep reading
, which is functionally identical. BilledMammal (talk) 22:55, 14 November 2022 (UTC)- @BilledMammal:, @Blaze Wolf: (who asked a similar question below): Thanks for flagging this. The “98% of readers don’t give…” sentence has been removed from all banners. This was an error in copying that we provided to Julia and has been corrected. Thank you. SPatton_(WMF) 19:06, 17 November 2022 (UTC)
- Thank you. That at least fixes one of my issues with it. SPatton_(WMF) could you answer the question in my 2nd comment below in the discussion section? ― Blaze WolfTalkBlaze Wolf#6545 19:12, 17 November 2022 (UTC)
- @SPatton (WMF): I can't find the updated example of the small mobile banner; the one linked at WP:VPM still contains the 98% language. Can you link the updated example? BilledMammal (talk) 06:50, 18 November 2022 (UTC)
- Sure, here is the update banner. JBrungs (WMF) (talk) 08:00, 18 November 2022 (UTC)
- Thank you, I've updated the RfC examples. BilledMammal (talk) 08:06, 18 November 2022 (UTC)
- Sure, here is the update banner. JBrungs (WMF) (talk) 08:00, 18 November 2022 (UTC)
- @BilledMammal:, @Blaze Wolf: (who asked a similar question below): Thanks for flagging this. The “98% of readers don’t give…” sentence has been removed from all banners. This was an error in copying that we provided to Julia and has been corrected. Thank you. SPatton_(WMF) 19:06, 17 November 2022 (UTC)
- Strong oppose to all banners – I haven't got the time to break them down at the minute, but the retention of guilt-tripping language and insinuations that we're desperately grasping onto the 2% of people who donate (because "most people decide they will but then forget" – hard citation needed on that fact) is still plain wrong, with the desperate insinuations being the worst thing. This is not a fundraiser for Wikipedia – this is a fundraiser for the WMF. The decision to paint this as funding "Wikipedia" and not "all the institutions the WMF oversees" is insidious; I can see how painting it as 'Wikipedia' is more of a draw, donations-wise, but that doesn't make it okay. Wikimedia Commons? Wikisource? Who uses those? (Rhetorically.) But Wikipedia? The average user, reading just the lead of any article while sat on the toilet (guilty), isn't going to care about those. The others can go hang; put the words "Wikipedia relies on just 2% of its users to survive in this cold, cruel world" and "I Vow To Thee My Wiki" starts playing in people's heads (and wallets). We could be highlighting the very important actual work that the WMF does (and should do more of). Above all else, all minor points about wording, the guilt-tripping over Wikipedia being in danger, when all it is in danger of is the WMF hoarding money and tossing us a shilling now and then, has to go. It's unacceptable to keep that in and attempt to fundraise in good faith, when it is not true.—Ineffablebookkeeper (talk) ({{ping}} me!) 23:03, 14 November 2022 (UTC) Edit: I've had some more time to look over the banners. I'd still like to know what $2.75 of knowledge looks like – half a paragraph and one quarter of an image, maybe? I'd also very much like there to be wider explanation of what "Support for volunteers" looks like; how does our funding go towards that? I want an explicit explanation, or else it continues to give the false impression that we in some way receive money occasionally for editing. We don't. It'd be nice to be paid for trawling through articles and endlessly updating formatting, templates and syntax, but we aren't.—Ineffablebookkeeper (talk) ({{ping}} me!) 13:06, 15 November 2022 (UTC)
- Agreed the average reader won't have heard of commons. But if a donor were to query it and be told that most of the images that they see on Wikipedia are actually stored on Commons, I suspect they'd accept that as a legit cost of keeping Wikipedia going. ϢereSpielChequers 23:24, 14 November 2022 (UTC)
- @WereSpielChequers: Oh, I'm certain they would; I wouldn't doubt that. There's just a real lack of emphasis on what the WMF does aside from Wikipedia, and it's really a shame.—Ineffablebookkeeper (talk) ({{ping}} me!) 13:06, 15 November 2022 (UTC)
- I agree that some of the things that the WMF spends money on are hard to defend as either an agreed part of its mission or justified by its appeal to keep Wikipedia going. But given the cost of running Commons and its close relationship with Wikipedia, I don't think we can criticise them for running Commons with money raised for Wikipedia. Going back to our hypothetical casual reader who never gets past the lede, if commons was deleted that user would suddenly notice they were seeing far fewer images on Wikipedia (disclosure, I have about twice as many edits on commons as I have on Wikipedia). ϢereSpielChequers 13:37, 15 November 2022 (UTC)
- @WereSpielChequers: Oh, my point isn't criticising them for running the Commons – sorry, I should've clarified. What I meant was that the WMF puts a strong emphasis on Wikipedia in its fundraising, but its other projects – including the Commons, Wikisource, all of that – don't get enough of a look in, in terms of "hey, we also run these other extremely important things too" sentiments in fundraising drives.—Ineffablebookkeeper (talk) ({{ping}} me!) 11:09, 16 November 2022 (UTC)
- I agree that some of the things that the WMF spends money on are hard to defend as either an agreed part of its mission or justified by its appeal to keep Wikipedia going. But given the cost of running Commons and its close relationship with Wikipedia, I don't think we can criticise them for running Commons with money raised for Wikipedia. Going back to our hypothetical casual reader who never gets past the lede, if commons was deleted that user would suddenly notice they were seeing far fewer images on Wikipedia (disclosure, I have about twice as many edits on commons as I have on Wikipedia). ϢereSpielChequers 13:37, 15 November 2022 (UTC)
- @WereSpielChequers: Oh, I'm certain they would; I wouldn't doubt that. There's just a real lack of emphasis on what the WMF does aside from Wikipedia, and it's really a shame.—Ineffablebookkeeper (talk) ({{ping}} me!) 13:06, 15 November 2022 (UTC)
- Agreed the average reader won't have heard of commons. But if a donor were to query it and be told that most of the images that they see on Wikipedia are actually stored on Commons, I suspect they'd accept that as a legit cost of keeping Wikipedia going. ϢereSpielChequers 23:24, 14 November 2022 (UTC)
- Fully oppose all fundraising on Wikipedia. Wikipedia's servers cost around £2 million a year. WMF's assets are over £230 million. See the 2021 Audit Report. If the existing assets are invested, then Wikipedia could run till the end of time and live comfortably off the investment returns with plenty to spare. However, WMF staff costs are nearly £68 million, and there's money thrown around in all directions, very little of which has anything to do with Wikipedia itself. The fundraising has nothing to do with keeping Wikipedia going, it is about making WMF richer and more powerful. WMF can fundraise elsewhere - not here. We should make clear that Wikipedia is about truth, transparency, and honesty. It's not about raising money for an already disturbingly rich organisation that has very little to do with the creation and running of Wikipedia. We should not accept any banners that give the impression that Wikipedia needs money. We don't. That's dishonest. So, we should say no to WMF's fundraising here. SilkTork (talk) 23:03, 14 November 2022 (UTC)
- I predict the most contentious ad used will not be one of the four listed above, instead it will be one we weren't warned of in advance. But of these I'd like to point out some obvious mistakes. We don't count our audience in millions, we count it in the hundreds of millions (over the course of a year, I suspect over a thousand million people will read some of the content of our sites). The WMF is selling us short. We don't share our knowledge - we are not Quora. We actually try to avoid having people come here to share their knowledge. This is not a site for veterans of the Gulf War to give their accounts of putting out burning oil wells, we are here to summarise and curate the world's published knowledge. If the WMF understood the difference between that and "sharing our knowledge" I suspect there would be a better relationship between the paid and volunteer parts of the community. On a practical note, emphasising that the normal thing is not to give money normalises the behaviour of not giving money. If I were writing such ads I would not normalise not giving unless with the caveat that our mission is global, many of our readers are in countries where $2.75 is a lot of money, but if you are in that small minority of people worldwide who can afford to give us $25 we'd really appreciate it. In other words, make people feel good about being one of the few who can pick up the tab for all of us. Lastly, as far as I'm aware, money spent by the WMF to support the volunteers who write and curate Wikipedia is such a small part of the budget that it is a bit misleading to include it so prominently in an ad (unless of course the WMF plans to usefully expand this such as by funding legal actions against those of its friends in big tech who don't honour the conditions of CC-BY-SA when reusing our work). ϢereSpielChequers 23:18, 14 November 2022 (UTC)
- Oppose – The implication that Wikipedia survives on donations, rather than editors, is as bad for Wikipedia as it is for the misled donors: People committed to supporting the project, who might otherwise have become regular editors, instead make donations that won't even go to improve the content. Wikipedia misses out on vital volunteers, and could-be-editors miss out on a rewarding hobby. The banner should say "If Wikipedia has given you $2.75 worth of knowledge this year, take a minute to share $2.57 worth of knowledge back."small jars
tc
23:21, 14 November 2022 (UTC) - Oppose all banners above as unethical bullshit. An honest one would start by pointing out the assets the WMF already has, and an admission that the funds aren't needed to maintain 'Wikipedia’s independence', since it isn't remotely under threat. At least, not from anything that the WMF adding to its pile of loot would rectify. AndyTheGrump (talk) 23:26, 14 November 2022 (UTC)
- Oppose. It's downright immoral that every year the WMF deludes users with limited incomes into thinking Wikipedia is on the verge of insolvency ("If you donate just $2.75...Wikipedia could keep thriving for years"), implying Wikipedia is somehow going to die if the readers don't pay up, despite the fact that hosting is a minority of the WMF's spending, with most of it going to grants and executive compensation. Everybody I've ever talked to who gave money to Wikipedia believed that 1. Wikipedia needed the money to survive, and 2. the money was benefiting the Wikipedia administrators (you know, the people who actually edit the site). Both of those falsehoods are directly and deliberately implied by the wording of these banners, which suggest that donation money pays for "Support for the volunteers who share their knowledge with you for free every day", "support" being a weasel word intentionally chosen so donators will think the money is somehow directly benefiting WP contributors (and what's with the mention of "sharing [volunteers'] knowledge"? I thought original research wasn't allowed here.) The WMF budget tells a different story than the flashy, obtrusive banners: as of June 30, 2022, the WMF generated $154.68 million in income, of which $2.7 million (1.7%) was spent on hosting: almost equal to the $2.7 million they gave out in executive salaries as of the end of the 2020 financial year. Wikipedia is clearly in no great financial danger (and could probably run for a couple decades on just the WMF's current financial assets and giant endowment), and yet the WMF insists on guilt-tripping ("Please, don’t ignore this message") its vulnerable readers ("Only 2% of our readers give.") into giving their hard-earned money to the Tax Exempt Executive Compensation Machine. I oppose these banners because they're clearly designed to generate profits, not communicate the truth. XenonNSMB (talk, contribs) 23:29, 14 November 2022 (UTC)
SatisfiedI'll repeat much of I said on the talk page. I've experienced being a fundraiser first hand, and in my case I've specifically done fundraising as a job at the WMF in the past (currently a WMF Engineering Manager). It is incredibly easy as an observer to simply say "it should read like this instead" but creating and designing fundraising messaging that works is incredibly challenging. Even with decades of combined experience, minor changes can result in profoundly unexpected consequences. It is an actual science as it should be, and it requires an iterative approach to be successful. We can't expect the to WMF tear up its messaging and halt on a dime in a way that simply isn't compatible with that iterative testing. Fundraising messaging by committee (or in this case, consensus) just doesn't work.- For this RfC to have a genuinely productive way forward, it should seek to propose a full suite of possible changes and variations than can then be tested rather than trying to cement a messaging that requires sign-off by consensus. That way we can help the WMF carve a path forward that leverages that iterative approach rather than simply throws a road block which works against it. Spending the time to clearly identify concerns, come up with a whole host of ideas and then give the team the time to test them. If those fail, we propose more. And we keep at it: carving a way forward, being accountable and testing more and more. That way we a fundraising campaign that is both effective and matches the needs and expectations of the community in messaging that represents us. I genuinely believe that can be a productive and effective approach for bringing about change.
- Trying to create and then enforce consensus without any informed testing, is a destination filled with nought but disappointment and failure. I don't think it has to be like that. We, as a community, have been in far more dire circumstances and even then avoided such over-the-cliff-edge approaches. It is a lever that should only be flipped in the most extreme of circumstances and we simply aren't there. Let's gives ourselves time to think and be smart about this, be creative, and then give the WMF time to get to work based on our collective input.
- Regarding some of the specifics brought up, whilst there is always room for improvement in the specifics. I whole heartedly disagree that the intent in the messaging is immoral or no longer appropriate:
- Supporting and growing the foundations budget with small donors does protect its independence and our communities ability to full OUR own mission rather than someone else's. Large numbers of non-profits of our size frequently end up being in receipt of large amounts of government or other foundation grants, and can often become the majority income source for a charity. That results in organisations chasing funding and loosing a focus on mission. The effect is a pseudo-erosion of a charities independence. Keeping a strong small donor base as the majority source of our funding is core to maintaining the independence of websites and projects etc. (addendum: especially when diversifying funding)
- A good chunk work is focused on keeping Wikipedia online. Denial of service is a huge threat to all websites and combatting that really is about keeping us online and we've invested hugely in that area and its still a massive challenge. But that challenge is no longer just technical one. It's not just about keeping a handful of servers running. For much of the last decade its also been about keeping the legislative and regulatory environment conducive to our continued existence and remain accessible to our end users. Whether it be things like section 230 in the US, or challenging governments like Turkey who have in the past denied access. That really is all about keeping us online and available.
- It's really hard and a big challenge in trying to keep messaging accessible and concise, and the result will always result in ambiguity in wording with multiple interpretations. Seddon talk 23:44, 14 November 2022 (UTC)
- Oppose: The WMF is in an excellent financial position. It does not need donations from private individuals and therefore ought not to be begging money off them.—S Marshall T/C
- (Later) I think the key takeaways for the WMF here are:
- (1) We as a community are very accustomed to people who want to use Wikipedia for fundraising or marketing. We've developed efficient and effective processes for dealing with them. We block them, revert them and ignore them. We don't spend a lot of volunteering time on fundraisers or marketers because volunteer time is Wikipedia's limiting resource.
- (2) We as a community try to demand accuracy and verifiability. We're accustomed to deception from fundraisers and marketers -- the less professional ones lie, and the more professional ones deceive by telling people carefully-selected truths. The word for that is paltering. We don't tolerate it from anyone else and we shouldn't tolerate it from the WMF when they're sitting on enough money to fund them for decades.
- (3) Below, WMF staff ask how they can adapt their fundraising banners and still hit their fundraising targets. We need to talk to the people who're setting those targets, please, not the poor people who're trying to hit them.
- Hope this helps and clarifies.—S Marshall T/C 11:26, 15 November 2022 (UTC)
- Oppose: People aren't dumb. Most know that we are rich and are spending it recklessly. They won't donate unless we show our excellent use with their money. And guilt-tripping donors will trip us down the road. CactiStaccingCrane (talk) 01:24, 15 November 2022 (UTC)
- To the WMF: you have plenty of money. But somehow Khan Academy is more effective at spreading knowledge than us. It's time to reevaluate ourselves whether we are worthy of the money. CactiStaccingCrane (talk) 01:25, 15 November 2022 (UTC)
- Genuine question, by what measure is Khan Academy more effective at spreading knowledge than Wikimedia? Seddon talk 01:31, 15 November 2022 (UTC)
- Per their 2020 report card, they have 27 million registrations in one year with a revenue of $52.6 million. Compare that to us, in our 21 years of existence, we have only 44 million registrations, with our revenue in 2020 is $129 million. I don't compare the page view between the two sites because KA does not make that info public, and having a KA (Khan Academy) account is different than having a WP account. KA accounts are used to save learning progress, while you can use Wikipedia whenever for whatever without needing an account. Let's see some other statistics:
- KA in 2020 reported having 8.7 billion minutes spent on the platform. Per a third-party research in 2019, the average minutes spent on Wikipedia's readers spent 352 billion minutes total in one year. (Wikipedia is more productive)
- KA is much more children-friendly than Wikipedia. This is because our articles are written for a general audience, though in practice articles such as Group theory are nigh impossible to understand. In contrast, KA's mission is to help children learn, so it's understandable why.
- KA spent almost all of its money it received (52.6 - 52.3 million = 0.3 mil). In contrast we withheld a significant portion of the money (129 - 112 = $17 million).
- Per the Skoll Foundation, KA has 100 million users viewing the page every year. We have 1.5 billion unique devices per month, though it is worth noting that KA mission is more specialized than Wikipedia.
- CactiStaccingCrane (talk) 02:05, 15 November 2022 (UTC)
- Per their 2020 report card, they have 27 million registrations in one year with a revenue of $52.6 million. Compare that to us, in our 21 years of existence, we have only 44 million registrations, with our revenue in 2020 is $129 million. I don't compare the page view between the two sites because KA does not make that info public, and having a KA (Khan Academy) account is different than having a WP account. KA accounts are used to save learning progress, while you can use Wikipedia whenever for whatever without needing an account. Let's see some other statistics:
- Genuine question, by what measure is Khan Academy more effective at spreading knowledge than Wikimedia? Seddon talk 01:31, 15 November 2022 (UTC)
- To the WMF: you have plenty of money. But somehow Khan Academy is more effective at spreading knowledge than us. It's time to reevaluate ourselves whether we are worthy of the money. CactiStaccingCrane (talk) 01:25, 15 November 2022 (UTC)
- Strong oppose We just need to kill the fundraising until we actually need it. It's just making the rich richer and making the WMF seem even more like a corporate company. "If Wikipedia provided you $2.75 worth of knowledge this year, please take a minute to secure its future by making a donation." just sounds like we are begging for money. Wikipedia already has a pretty secure future for the time being because guess what? The WMF is rolling in cash and does not actually need more. ― Blaze WolfTalkBlaze Wolf#6545 01:45, 15 November 2022 (UTC)
- In addition, below someone from the WMF said this: "The line “98% of our readers don't give; they simply look the other way” has been removed". Yes you've removed it but you've pretty much just replaced it with the inverse which says "Only 2% of our readers give. Many think they’ll give later, but then forget." which is another way of saying the same exact thing. Heck, the mobile small banner still says the original line, but modified. It now says "but 98% of our readers don't give; they keep reading." which again says the same thing. If we must keep the banners then we need to just get rid of this statistic altogether as it doesn't do anything but try and guilt-trip readers. I've never even seen any actual proof provided for this statistic anyways so it could just be completely fabricated. ― Blaze WolfTalkBlaze Wolf#6545 01:51, 15 November 2022 (UTC)
- @Blaze Wolf a real question here, how does WMF fundraising make "the rich richer"? We don't have any share structure that would feed it back to the c-suite, whose salaries are a matter of public record. Alongside that, are you indicating that they are lying about the % but telling the true about the absolute numbers? More relevantly, do remember that the staffers who post the figures are editors - and are entitled to the same protections you and I are. Nosebagbear (talk) 09:23, 15 November 2022 (UTC)
- In addition, below someone from the WMF said this: "The line “98% of our readers don't give; they simply look the other way” has been removed". Yes you've removed it but you've pretty much just replaced it with the inverse which says "Only 2% of our readers give. Many think they’ll give later, but then forget." which is another way of saying the same exact thing. Heck, the mobile small banner still says the original line, but modified. It now says "but 98% of our readers don't give; they keep reading." which again says the same thing. If we must keep the banners then we need to just get rid of this statistic altogether as it doesn't do anything but try and guilt-trip readers. I've never even seen any actual proof provided for this statistic anyways so it could just be completely fabricated. ― Blaze WolfTalkBlaze Wolf#6545 01:51, 15 November 2022 (UTC)
- I'd prefer banners that don't guilt trip the reader, don't imply the WMF is frugal, and don't suggest the need is dire or urgent. Maybe something like:
Elon can't buy this. Give us $2 so it stays that way.
Levivich (talk) 06:48, 15 November 2022 (UTC)- That sounds a bit worse imo. It sounds like we're demanding readers to donate, rather than simply asking them. ― Blaze WolfTalkBlaze Wolf#6545 13:23, 15 November 2022 (UTC)
Elon can't buy this. Please donate $2 to help keep it that way.
Levivich (talk) 16:58, 15 November 2022 (UTC)
- That sounds a bit worse imo. It sounds like we're demanding readers to donate, rather than simply asking them. ― Blaze WolfTalkBlaze Wolf#6545 13:23, 15 November 2022 (UTC)
- Oppose - WP:CANCER. — Qwerfjkltalk 07:11, 15 November 2022 (UTC)
- Oppose. Considering all the above, including the refusal (both now and during the trials and other fundraisings in previous months) to present all banners in advance, and considering the dreadful donation blog post (see the village pump wmf page) which continues their efforts to misuse the Wikipedia brand whenever the Wmf wants money, and considering the money wasted on stupid projects and disruptive grants, the WMF can Go Fund Themselves. Fram (talk) 12:10, 15 November 2022 (UTC)
- Oppose Who's attacking Wikipedia? What are we supposed to be defending it from? Sorry...it's all monetized fear-mongering as far as I'm concerned. Couple that with the lack of transparency and misleading statements about where the money goes...get rid of the banners. Or just be honest about it and go with the format used in Rockstar's GTA Vice City: "If you're using Wikipedia without donating, you're stealing." Intothatdarkness 14:04, 15 November 2022 (UTC)
- Oppose Costs increase every year, transparency goes down. I love Wikipedia, but the endless increase in costs, money not being actually spent on Wikipedia and the lack of clarity of why a website that has about $3m hosting costs needs nearly $200m I don't understand. I am losing faith tompagenet (talk) 14:29, 15 November 2022 (UTC)
- I'm fine with this. It's a bit difficult to unpick general WMF-hating from specific concerns about the actual content of the banners in this kind of RFC. As one of the few Wikipedians who's also a professional fundraiser, I think the messaging that's used does a really good job of reflecting the Wikimedia movement in a way that's going to be comprehensible to most people. The standards of neutrality and evidence that we require for Wikipedia articles just don't apply to Wikipedia fundraising. Also, the WMF are to be applauded for doing so much work to find effective messaging that reduces the amount of time fundraising banners are displayed. The Land (talk) 14:51, 15 November 2022 (UTC)
- I think that our standards of neutrality and evidence apply to everything displayed on a rendered mainspace page.—S Marshall T/C 15:40, 15 November 2022 (UTC)
- Oppose using Wikipedia as a cash cow on steroids to fund WMF growth through misdirecting phrases like "humbly ask you to support Wikipedia's independence" (if anything, it is the ever-expanding WMF's independence that is at issue here); "humbly ask you to protect Wikipedia" (Wikipedia is not under threat; the only thing conceivably under threat is the WMF's ability to follow through on its plans for further rapid inflation of its budget and headcount); "If Wikipedia provided you $2.75 worth of knowledge this year, please take a minute to secure its future by making a donation" (it's not about Wikipedia's future, but about Wikimedia's expansion plans that it never talks about or explains or justifies on these banners); "This Monday we ask you to help us sustain Wikipedia" (ditto). The WMF more than doubles its expenditure every five years, gives millions of dollars away to external organisations via Tides Advocacy, and still regularly enjoys eight-figure annual surpluses. The insinuation that it is short of money to keep Wikipedia online or spends a lot of money on supporting volunteers feels sneaky and misleading. As S Marshall says above, it's paltering and the precise opposite of what Wikipedia at least strives to be about. --Andreas JN466 15:01, 15 November 2022 (UTC)
- Strong Oppose Along with all the other issues mentioned by editors above and below, this is beginning to affect Wikipedia's credibility. I've seen more and more people on external websites (pretty correctly) stating that your donations to WMF don't go to Wikipedia, and more and more people seeing WP:CANCER. The blatant advertising, guilt tripping, downright keeping facts from Wikipedia readers is absolutely ridiculous, and people are seeing it for what it is. Dialmayo (talk) (Contribs) she/her 15:17, 15 November 2022 (UTC)
- I also feel it necessary to point out these worrying statements that the WMF felt they needed to include:
We ran the banners for 4 days towards the end of the campaign, and the overall result of the new banner was a 65% decrease in donations.
andthis exact message won't reach the revenue target for the year
. Although WMF did state thatthere are interesting concepts to further develop
, this is insane. The body owning Wikipedia values adding even more money to their piggy bank over truth. Dialmayo (talk) (Contribs) she/her 16:22, 15 November 2022 (UTC)
- Strong Oppose I'm also strongly opposed to all these nag-banners. If wikipedia were skint, but it's far from skint. Set up an endowment (for Wikipedia specifically) with the money you've already been given. Don't use Wikipedia to guilt-trip people into funding random schemes and political donations. MrDemeanour (talk) 15:54, 15 November 2022 (UTC)
- Strong Oppose Echoing all the above points. This is really causing a loss of credibility to Wikipedia. Keep the WMF power and money grab away from Wikipedia. I thought the mission for Wikipedia was building an encyclopedia. I don't remember seeing advertisement on Brittanica encyclopedia about funding political donations. Just stop already before the damage cannot be undone. This is also highly unethical behavior given that the fundraising is not for the people or the site these ads are being shown on. Seems like a blatant power and money grab and nothing more. WP:CANCER --Molochmeditates (talk) 16:00, 15 November 2022 (UTC)
- Strong Oppose - All fundraising banners should cease on Wikipedia. They're dishonest, annoying, and unnecessary. Wikipedia has all the money it needs to fund its operations. - GretLomborg (talk) 16:07, 15 November 2022 (UTC)
- Strong oppose Asking people to donate money Wikipedia doesn't need, during an economic crisis and a huge refugee crisis, is just bullshit. But the real problem is that the yearly Fundraising campaign misleads people into thinking Wikipedia is independent and reader-supported: it is not. It receives millions from large corporations, including Amazon and Google, and has created [2] a new "premium" API companies can sign up for. "Independent" — not. DFlhb (talk) 16:14, 15 November 2022 (UTC)
- Oppose. The banners are not truthful regarding how the donations are spent. The only halfway truth is "Resources to help the Wikimedia Foundation advance the cause of free knowledge in the world". The banners should state what the donations are used for. — RockMFR 16:16, 15 November 2022 (UTC)
- Oppose The Wikimedia Foundation's banners are socially and ethically inappropriate. The unethical part is that the Wikimedia Foundation is doing fundraising in the name of the Wikimedia community based on the trust that the public has for the Wikimedia community, but even after years of community objections, the Wikimedia Foundation has not even started a reasonable attempt at dialogue with the community about these problems. The Wikimedia Foundation has internalized and wishes to deepen a soulless mindset of a commercial corporation where money is the highest priority and any ethics can be disregarded if it increases the money, but we are a nonprofit project and activist community where we distinguish between right and wrong. There are major ethical conflicts between the Wikimedia Foundation and the Wikimedia community, and to continue without change would only widen those conflicts. The Wikimedia Foundation response below is oblivious to community concerns, and indeed, the Wikimedia Foundation will persist in ignorance and error until and unless it either relinquishes ethical oversight of some issues to the Wikimedia community, or the community attacks the Wikimedia Foundation to commandeer control of the ethical issues where the Wikimedia Foundation is transgressing. Some time ago the Wikimedia Foundation passed the point of ignorance and innocence and has become openly aggressive against the values and ethics of the Wikimedia community. That is becoming scary. I am on the side of democracy, community empowerment, protection of the underclass, diversity for underrepresented voices, and letting people speak for themselves. I hope that the Wikimedia Foundation chooses to join the people rather than spend donation money to suppress these voices. The steps to take to correct the error is that the Wikimedia Foundation should directly fund the Wikimedia community to organize social and ethical conversations about how to manage fundraising, and when the WMF gives this money, it should keep its staff out of those conversations, and confirm to the community that the community is free to oppose the WMF. It scares me when the WMF runs diversity programs in lower and middle income countries, and with those programs, the underrepresented minorities come out like zombies who only support the WMF, never disagree with anything, are sure that they want the WMF to speak for them, and ask for much less than empowered communities. Bluerasberry (talk) 16:52, 15 November 2022 (UTC)
- Oppose. The basic problem is that while much of these banners are literally true, they're lying by implication and by omission. I could go through all the other not-votes and summarize them, but I think people know the reasons already. Also, the comments from the WMF below seem to miss the point. It's not specific phrases that people object to, it's the ideas that Wikipedia is in danger, and that all donations directly go to maintaining Wikipedia. The banners need a massive overhaul to be good, not just rephrasing to make it seem slightly less like Wikipedia is in danger. Ken Arromdee (talk) 19:33, 15 November 2022 (UTC)
- Satisfied The rest of the Internet is a giant advertising machine constantly tracking you and manipulating you. Other nonprofits waste way more time and resources sucking up to megarich donors with weird agendas. The WMF runs banners for a few weeks and then basically the rest of the time we don't bother readers, because they've figured out campaigns that work. I can't imagine a better system for funding a top 10 website. Every year some group of editors wants to start a holy war over the wording or style of the banners. The real alternatives are one of two things: use banners that work less well, so we'd have to show them to more people (annoying, no thanks) or just raise less money. I think about whether we need it or not. Our goal is to give everyone on the planet a free encyclopedia. There are about 5 billion people with Internet access. We reach less than half of those people today, across all languages of Wikipedia [3]. We need to be doing a lot more to expand access, not less. Like most people, I have gripes about how they spend the money, but cutting off the tap is like shutting down the entire government because you disagree with parts of the budget. Steven Walling • talk 20:57, 15 November 2022 (UTC)
- Strong Oppose per SilkTork. Chris Troutman (talk) 21:34, 15 November 2022 (UTC)
- Strong Oppose, per the reasons of many others above. I would also support getting rid of them entirely, as they seem to just be a bunch of lies to get more unneeded money (especially statements like
Here's what your donation enables: ... Support for the volunteers who share their knowledge with you for free every day
– what? Writers here don't get any money.) BeanieFan11 (talk) 21:37, 15 November 2022 (UTC) - Oppose all fundraising on Wikipedia until further notice. As many have said, Wikipedia has enough money to operate for quite some time. Until the WMF can show us they have reformed their finances and fundraising style, they shouldn't be asking for money. Kolya Butternut (talk) 23:27, 15 November 2022 (UTC)
- Oppose, might as well add mine to the pile. For what does Wikipedia need more money? It's a website. The website's biggest assets are its volunteers and the content they create. Also, I think it's rather disingenuous to give readers the impression that Wikipedia is in dire need of cash when that's not true at all. Wikimedia collects the cash and spends most of it on things that aren't directly related to the upkeep of Wikipedia, such as racist bullshit. Frogging101 (talk) 01:58, 16 November 2022 (UTC)
- Oppose I don't mind that the WMF is fundraising and building a nest egg. Better too much money than not enough. I also think its fine that the WMF is expanding the services it provides. This isn't 2004 anymore; we face a lot of real world problems that we have to face realistically. But I do object to the tone and prominence of the banners. They get bigger and bolder seemingly each year. Our readers are annoyed with them. We, the editors, then have to deal with their anger. The banners disrupt the reading experience, and destroy the very hard won goodwill editors have fought for. Practical solutions: smaller banners, up for a shorter time. Focus more on email outreach. Less fear mongering in the messages tone. Wikipedia needs to make money, but it can't do that if it is pissing off its readers and editors. CaptainEek Edits Ho Cap'n!⚓ 02:20, 16 November 2022 (UTC)
- Oppose The WMF is spending $17M a year on fundraising, according to the annual plan. We should get more from that expenditure than running banner ads that spend a month interrupting access to free knowledge. Banner ads made sense when the WMF was a lean organization, not today. TomDotGov (talk) 02:33, 16 November 2022 (UTC)
- For a small donor based fundraising model, the WMF's fundraising cost per dollar is industry leading. The only way you get more efficient fundraising is through substantial individual and corporate major gifts and noone should want us to go in that direction. Seddon talk 04:20, 16 November 2022 (UTC)
- Given that the WMF advertises on the seventh most visited website for free, I don't think they can be compared to other non-profits with the same fundraising model without estimating how much such a campaign would normally cost. BilledMammal (talk) 04:27, 16 November 2022 (UTC)
- For a small donor based fundraising model, the WMF's fundraising cost per dollar is industry leading. The only way you get more efficient fundraising is through substantial individual and corporate major gifts and noone should want us to go in that direction. Seddon talk 04:20, 16 November 2022 (UTC)
- Oppose: This is the carousel that keeps turning, each time similar to those that went before, without proper re-evaluation. I previously commented that these messages detriment the benevolence essential to this project. The WMF Audit Committee Charter requires fundraising exercises to "ensure full transparency into the use of all donor funds raised under the Wikimedia name or on its sites"; my view is that transparency must be not merely retrospective (evaluating what was done with moneys - which, despite Andreas Kolbe's persistence remains too often unclear) but also prospective: clearly setting out both need and target as the basis for any new fundraising. While I doubt that "We already have $xM and wish to boost that to $(x+y)M to achieve (...)" would be an effective as a fundraising message, it would be transparent and honest. A practical suggestion: replace "Wikipedia" with "Wikimedia Foundation" in each text, as a minimum requirement to comply with the WMF Audit Committee Charter. AllyD (talk) 08:46, 16 November 2022 (UTC)
- Oppose due to lack of transparency and misleading nature of the campaign, per XenonNSMB and others. MB 16:25, 16 November 2022 (UTC)
- Strong Oppose per SilkTork and Bluerasberry who sum it up so well that there's no need for me to elaborate, and Bilorv who with his mention of NPP illustrates a classic example of how the funds are used for everything else rather than supporting the volunteers' dedication to keeping the corpus clean to the best of their ability. Without NPP, there will be no confidence in the content and consequently no donations anyway. Where does the $17M a year on fundraising go exactly? Less than $300K would solve all of NPP's problems. Kudpung กุดผึ้ง (talk) 18:54, 16 November 2022 (UTC)
- Strong Oppose per SilkTork, Bluerasberry, and Kudpung. These banners are ethically compromised and misleading. I have many a friend who believe that the donation money is desperately needed to keep the website online, while many more millions are going to other projects hardly related to Wikipedia at all. In addition to that, I affirm my support for at least some funding towards professionalizing NPP. ‡ The Night Watch ω (talk) 19:59, 16 November 2022 (UTC)
- Meh still not interested in micromanaging fundraising initiatives. — Wug·a·po·des 22:05, 16 November 2022 (UTC)
- Oppose per Bilorv. I oppose all fund-raising by the WMF until greater transparency and honesty is shown, which this is not. Wikipedia (and its sister sites) are not under threat in any way, they are not being sufficiently supported by the WMF with the money they already have, and neither are the volunteers being supported. The only thing I don't mind is that the staff (not the useless directors) should be paid well, which can be done with existing funds easily enough. Ciridae (talk) 06:06, 17 November 2022 (UTC)
- They're fine The WMF needs to fundraise regularly. They need to tell people they are fundraising. Banners are fine. --Jayron32 16:12, 17 November 2022 (UTC)
- Oppose there's no point in rehashing everything that has been written above. Suffice it to say that these banners are misleading and disruptive. LEPRICAVARK (talk) 23:40, 17 November 2022 (UTC)
- Oppose On the one hand, the banners are improved (over the emails and past banners) enough that I would tolerate them being shown on their own, and I thank the fundraising people for it. The single biggest remaining issue, in my opinion, is that the banner still implies some sort of financial pinch when there isn't one at all (but it's less overt). However, I recognize that the only way to (force) having a voice in how funds are spent is to prevent the banners from being shown. Related to this is objections about how the banners present money being spent; I interpret that sentiment as objecting to how funds are spent more than the banners themselves. Others have elaborated why funds are misspent; I don't think I need to elaborate. I also feel bad for the fundraising team folks--they aren't the issue. —Danre98(talk^contribs) 01:31, 18 November 2022 (UTC)
- Rhododendrites's proposal below about the WMF committing to X% of income going to the community tech team is an easy first step. —Danre98(talk^contribs) 01:38, 18 November 2022 (UTC)
- Oppose In my experience on WP, nothing has been more continuously distressing and frustrating for myself and other content creators than the lack of support from WMF on basic updates and support for the volunteers whose actual work generates their ridiculously unneeded fundraising. I have had so many people IRL who know I work on WP say they donated or spoken about how they feel bad that WP doesn't have enough money. Over and over again. It is a blatantly manipulative and harmful lie and should be removed immediately from banners and elsewhere. Aza24 (talk) 05:19, 18 November 2022 (UTC)
- Oppose us hosting any more fundraising banners until the banners all clearly report boldly, in the banner not behind a link (a) the current balance of the endownent fund (b) previous year's all sources revenue (including endowment fund revenue) and (c) what percentage of annual revenue is spent on hosting, maintaining, improving and defending Wikipedia. And, of course, they must stop implying there is any threat to Wikipedia's existence or independence. --Anthonyhcole (talk) 10:07, 18 November 2022 (UTC)
- Strong Oppose. I used to think WMF funding was merely wasteful, but I've become more cynical over the years. Benjamin (talk) 22:47, 18 November 2022 (UTC)
- Oppose Per everyone. The banners are misleading at best, and the funds definitely aren't being used to support the community in any meaningful way. ThePlatypusofDoom (talk) 23:15, 18 November 2022 (UTC)
- Satisfied the WMF does good work and having a "war chest" available is important should other funding sources cease to exist or economic conditions worsen. I agree with some other folks that the donation messages should sound less "desperate", however, as the WMF is not presently under any financial duress. Nicereddy (talk) 01:07, 19 November 2022 (UTC)
- @Nicereddy: could you expand a bit on the "war chest" point? From what I understand per the WMF employee comments below, the WMF keeps about 16 months of operating costs in reserve for crisis, but any more money they receive would simply go towards increasing their operating costs or towards unrelated projects like the Tides Foundation. How much money do you think they need in case of crisis? Is 16 months worth of $175 million per year not high enough?I can't imagine that readers would notice a major difference (at least, not a more major difference than the one we're seeing from the chronic volunteer labour shortage) if the WMF ran on $10 million per year, kept $165 million in reserve and stopped accepting donations. — Bilorv (talk) 10:54, 19 November 2022 (UTC)
- @Bilorv You are correct, I had assumed since I'd heard for so long that "the WMF doesn't need the donations", they meant that they had enough to last them for at least 3+ years on their current burn rate. It's pretty crazy to me that the WMF is working with only a 16 month runway (though they could, of course, cut costs drastically if needed, should a major recession or other such event occur). Seems somewhat irresponsible to continue to grow without preserving more runway to work with. So I will admit I was wrong regarding the "war chest", and apologize for that. It seems cutting operating expenses somewhat and slowing down their growth to get more runway would be a reasonable decision for the WMF to make in the next few years. But it's also not something they can do overnight without disrupting people's lives or the product work currently going on.
- Now, having said that, I want to comment on the idea that $10m/yr would be a realistic amount to run the WMF on. Server costs (the thing everyone says is by far the most important thing) would eat up 2.7m of that, and then at least 0.5m on conferences (assuming they cut their conference schedule down a decent amount). Then, add another 2m for general operating costs, now you've only got 5m left for salaries (and that's ignoring various other expenses that exist, but let's ignore those for now). Currently, salaries are 88m. Whether you think people are paid too much (software engineers, especially good ones, are quite expensive), the fact remains that you can't just cut everyone's salaries to 1/3rd of what they're currently paid, many wouldn't be able to pay the bills if you did that. You'd realistically need to cut around 90% of the staff to get down to 5m/yr in salaries. And, well, we'll see how that goes at Twitter. Nicereddy (talk) 17:09, 19 November 2022 (UTC)
- @Nicereddy: could you expand a bit on the "war chest" point? From what I understand per the WMF employee comments below, the WMF keeps about 16 months of operating costs in reserve for crisis, but any more money they receive would simply go towards increasing their operating costs or towards unrelated projects like the Tides Foundation. How much money do you think they need in case of crisis? Is 16 months worth of $175 million per year not high enough?I can't imagine that readers would notice a major difference (at least, not a more major difference than the one we're seeing from the chronic volunteer labour shortage) if the WMF ran on $10 million per year, kept $165 million in reserve and stopped accepting donations. — Bilorv (talk) 10:54, 19 November 2022 (UTC)
- Neutral We've had too many discussions about this, here, in WP:VPW, etc. I have become disinterested in the topic. Sungodtemple (talk) 03:56, 19 November 2022 (UTC)
- Oppose. Wikipedia is never under threat of losing its independence. While it is more covert this time - the gist is still clear - that Wikipedia can only run because of the donation of its readers. Wikipedia is not dying, it is not in financial distress, it is not under threat of bankruptcy, and it is in a good financial position. I can even add that some editors of Wikipedia that are contributing to the project are in worse financial shape than Wikipedia. What the donation is enabling is also highly misleading. Wikimedia Foundation advance the cause of free knowledge in the world is misleading, as they used Tides Foundation, an organization that is leaning to the left causes, many of them are not related to "free knowledge", instead of using a neutral organization that is focusing on free knowledge. Support for the volunteers who share their knowledge with you for free every day. is never felt, and many Improvements on Wikipedia and our other online free knowledge projects. are done by volunteers. What should be done by Wikipedia is simple - just do what most US charities are doing - plainly and simply announce how much money they are using for improvements, how much money they are "wasting" on Tides, how much money they are paying for the board of directors, etc. And WMF should segregate the donation - let the donor choose which cause they wanted to support. If the donor wanted to give to "supporting the editors" then that money should be sent into providing fixes to the site that supported the editors, not to Tides. If the donors wanted their donation to be used to "maintain the site" it should be used for site maintenance, not doing some conference somewhere. Wikipedia should be clean and lean. ✠ SunDawn ✠ (contact) 04:11, 19 November 2022 (UTC)
- Oppose. -Pete Forsyth (talk) 17:19, 19 November 2022 (UTC)
Discussion (2022 fundraising banners)
- I do feel it should be fairly clearly noted that the effects of a local project severing the capability of the WMF to do a majority of their fundraising is likely to be...drastic. Some might actually view that as a feature not a bug, others may view it as a price worth paying. Personally (if perhaps mildly dubiously) I would reserve blocking the fundraising banners for a situation where the WMF is even more obstinate than some past occasions. Whatever your position on it, every person participating in this RfC should be aware of the potential for dispute. Nosebagbear (talk) 22:36, 14 November 2022 (UTC)
- Short of totally disabling the banners, I wonder if it would be possible to tone them down a bit with common.css? We could get rid of the big red outline, disable the sticky-positioning, and shrink the big donation buttons. Removing the sticky banner is especially justifiable because it's a real hindrance when trying to read an article. I don't know if it's possible with CSS, but I like the idea of moving the banner to the very bottom of the article, where I've seen donation banners on the Stanford Encyclopedia of Philosophy website.small jars
tc
23:03, 14 November 2022 (UTC)- @SmallJarsWithGreenLabels: if we're able to modify the banners beyond just an on and off toggle, then at that point, we may as well rewrite them in big neon letters stating that the WMF doesn't need more money. Hell, we could have an RFC where we all decide to larp as those characters from Les Mis who barricade themselves in that street and point to an open letter where we lay out the fundraiser's problems. I jest (somewhat), but I feel I have to point out that if we can change things, and use those powers to move a banner, shrink things a bit and get rid of an outline, it's a bit of a wet fart. It doesn't feel like the right response if this has been going on consistently for so many years, and if we are going to admit to this fundraiser causing harm, or at least being unethical. I can understand starting small and ramping up, but I think there's a conversation to be had about whether we grab their attention and stop it now, or do this in stages before hitting the kill switch.—Ineffablebookkeeper (talk) ({{ping}} me!) 23:23, 14 November 2022 (UTC)
- If the current decision-makers at the WMF see not being dishonest and misleading as something that destroys their capability to fundraise, then either they should all resign immediately due to being fundamentally unqualified for the task or it was not something worth funding in the first place. CoffeeCrumbs (talk) 03:51, 16 November 2022 (UTC)
- Short of totally disabling the banners, I wonder if it would be possible to tone them down a bit with common.css? We could get rid of the big red outline, disable the sticky-positioning, and shrink the big donation buttons. Removing the sticky banner is especially justifiable because it's a real hindrance when trying to read an article. I don't know if it's possible with CSS, but I like the idea of moving the banner to the very bottom of the article, where I've seen donation banners on the Stanford Encyclopedia of Philosophy website.small jars
- Comment - slightly off-topic, for those of you who saw that I fairly-recently posted about my personal data potentially being breached by a payment organisation when I contributed to such a banner-appeal. I have now found the letter in the house (that I threw down in disgust), dated 5 December 2011, signed with RL identity by someone who (still) openly self-identifies with the organisation callled Wikimedia UK under Username. There was no tangible product supplied, or service performed, being purely a donation to a charitable body. I have not contributed again, and will never do so. I have not, as yet, formally contacted the payment organisation as I have had trouble accessing the 'old' records (and want to save it, in case they try to cover their tracks by deletion). I noticed in the recent appeal there is a further query: "Can we follow up and let you know if we need your help again?". Clickable Yes/No. It may be that I completed this in 2011, in the expectation of email contact, not that my personal postal address be supplied.--Rocknrollmancer (talk) 22:58, 14 November 2022 (UTC)
- Note that Wikimedia UK no longer fundraises via banners and is an entirely separate organisation. I would encourage you to email info
wikimedia.org.uk Seddon talk 23:19, 14 November 2022 (UTC)
- Note that Wikimedia UK no longer fundraises via banners and is an entirely separate organisation. I would encourage you to email info
- Comment on conflicts of interest. In the survey section Seddon, a current WMF employee, has posted a !vote, but has not disclosed their current COI although they have disclosed a past conflict of interest (
in my case I've specifically done fundraising as a job at the WMF in the past
). Should WMF employees who chose to !vote in this discussion clearly disclose their conflict of interest, or do the unique circumstances of this discussion make it appropriate to not do so? BilledMammal (talk) 23:50, 14 November 2022 (UTC)- I'm happy to be more explicit and that was my intent with the existing note. Seddon talk 23:59, 14 November 2022 (UTC)
- I've updated my comment. Seddon talk 00:01, 15 November 2022 (UTC)
- Thank you. BilledMammal (talk) 00:02, 15 November 2022 (UTC)
- Seddon, given that you are a paid employee, and the fundraising pays your wages, you are clearly in a serious conflict of interest here. I think it is acceptable to make general factual comments in the discussion section, but I can't see it as acceptable that you take part in the vote section. Your vote doesn't actually matter as there is a clear consensus in the Wikipedia community that the WMF fundraising banners are unacceptable; however, as a point of principle, your vote should not be there, and on reflection I'm sure you'll agree. Would you please strike your !vote, and refrain from taking further part in the voting section of this page. SilkTork (talk) 19:13, 16 November 2022 (UTC)
- Agreed. Seddon's participation at all is inherently manipulative and disingenuous. After being here 16 years they should know better—but since they're WMF I can't be surprised that they don't. Aza24 (talk) 05:13, 18 November 2022 (UTC)
- I've struck the !vote and indented the comment Seddon talk 02:10, 19 November 2022 (UTC)
- Comment: I notice a slight rhetorical slant toward identifying Wikipedia with the WMF as a whole; for example,
Wikipedia … is like a library or a public park where we can all go to learn. Wikipedia is maintained by a nonprofit … Without reader contributions, we couldn’t run Wikipedia the way we do.
I understand that lay readers may perhaps be better served by a simpler, more idealized view of Wikipedia's workings; nevertheless, this phraseology discomforts me slightly. The choice of libraries and public parks as a simile is (if I may speculate slightly) perhaps indicative of a cathedral mentality on the WMF's part: both examples are maintained by a centralized group of custodians or stewards, who provide a service for the public to see and use but not to touch (i.e., alter). Off the top of my head, I can't think of a better, more volunteer-focused analogy; perhaps a blood bank? I also don't quite like the words "maintained" and "run"; they carry the connotation that the WMF is directly involved in writing and editing the encyclopedia, which is a slight misconception. Perhaps "hosted" and "support", respectively, would be better word choices. In another banner, it's claimed that one'sdonation enables: Improvements on Wikipedia and our other online free knowledge projects [and] Support for the volunteers who share their knowledge with you for free every day.
It's technically true, perhaps, but I think it's stated a bit too strongly, implying (incorrectly) that the WMF is directly involved (to any significant degree) in the everyday affairs of the encyclopedia.Of course, there are probably more salient issues than my rhetorical quibble: the size of the WMF's piggy bank, the way it's publicly portrayed, its intransparency, etc. Perhaps others more knowledgeable than me can address those concerns. Shells-shells (talk) 00:06, 15 November 2022 (UTC) - Comment: The topic of “independence” has come up so I wanted to share some background on this concept. In 2013, the Wikimedia Foundation Board of Trustees defined the guiding principles that drives the Foundation’s fundraising strategy to this day. As stated in the Board approved guiding principles:
- Part of the job of the Wikimedia Foundation is to ensure that the freedom and independence of the projects is never compromised. To that end, and also because it is extremely effective, we have deliberately chosen a revenue strategy in which a large majority of the funding for the Wikimedia Foundation comes from a large number of small donors in multiple countries around the world. This model limits risk, preserves independence by reducing the ability of any one organization or individual to influence our decisions, and aligns our fundraising practices with our mission by encouraging us to pay attention to the projects’ readers.
- We go into this more in our latest Fundraising Report published today that provides more background on banner messaging as well as other critical pieces of communication with donors. We’re gathering valuable input on banner messaging on meta and welcome your ideas to try this year. Thank you for the care you put into this work. MeganHernandez (WMF) (talk) 00:30, 15 November 2022 (UTC)
- MeganHernandez (WMF), that's fine, just don't do your fundraising HERE. You are raising money for WMF, we are Wikipedia; in case you haven't noticed, those are two different things. Wikipedia is not the place for advertising or fundraising for any organisation. Use your money to fundraise elsewhere. SilkTork (talk) 10:17, 15 November 2022 (UTC)
- The main issue with that would be: where else would they advertise the fundraising campaign? Sure they could advertise it on meta, however most readers are here, reading Wikipedia. ― Blaze WolfTalkBlaze Wolf#6545 14:02, 15 November 2022 (UTC)
- Same places as other non-profits advertise. I think all of us have charities that we donate to on a regular basis - they made themselves known to us without using Wikipedia by advertising in the usual places. SilkTork (talk) 16:34, 15 November 2022 (UTC)
- I don't donate to any charities. ― Blaze WolfTalkBlaze Wolf#6545 16:38, 15 November 2022 (UTC)
- You donate your labour here. Andreas JN466 17:18, 15 November 2022 (UTC)
- You might donate your "labour" here, but I donate my labor. Levivich (talk) 19:41, 15 November 2022 (UTC)
- You donate your labour here. Andreas JN466 17:18, 15 November 2022 (UTC)
- I don't donate to any charities. ― Blaze WolfTalkBlaze Wolf#6545 16:38, 15 November 2022 (UTC)
- Same places as other non-profits advertise. I think all of us have charities that we donate to on a regular basis - they made themselves known to us without using Wikipedia by advertising in the usual places. SilkTork (talk) 16:34, 15 November 2022 (UTC)
- The main issue with that would be: where else would they advertise the fundraising campaign? Sure they could advertise it on meta, however most readers are here, reading Wikipedia. ― Blaze WolfTalkBlaze Wolf#6545 14:02, 15 November 2022 (UTC)
- MeganHernandez (WMF), that's fine, just don't do your fundraising HERE. You are raising money for WMF, we are Wikipedia; in case you haven't noticed, those are two different things. Wikipedia is not the place for advertising or fundraising for any organisation. Use your money to fundraise elsewhere. SilkTork (talk) 10:17, 15 November 2022 (UTC)
- The best possible way to keep our integrity is to give us money. Loads of money. Give it now. We are unbiased. Dialmayo (talk) (Contribs) she/her 15:35, 15 November 2022 (UTC)
- Comment BilledMammal next time when pinging people, make sure to do so in the RFC and not just at the top of the page and then delete it. ― Blaze WolfTalkBlaze Wolf#6545 01:40, 15 November 2022 (UTC)
- When I click the notice "Your mention of ... was sent" it still links to this RfC. Does it not for the notice that the mentioned editors receive? BilledMammal (talk) 01:45, 15 November 2022 (UTC)
- Nope. I get the message "This comment could not be found. It might have been deleted or moved." ― Blaze WolfTalkBlaze Wolf#6545 01:52, 15 November 2022 (UTC)
- That is annoying. I will make sure to leave the comment in the future. BilledMammal (talk) 01:56, 15 November 2022 (UTC)
- Nope. I get the message "This comment could not be found. It might have been deleted or moved." ― Blaze WolfTalkBlaze Wolf#6545 01:52, 15 November 2022 (UTC)
- When I click the notice "Your mention of ... was sent" it still links to this RfC. Does it not for the notice that the mentioned editors receive? BilledMammal (talk) 01:45, 15 November 2022 (UTC)
- Comment: The Wikimedia Foundation takes a lot of steps to educate our donors. The banner is a very limited communication space and is not the only time our donors hear from us. First, every banner links to a detailed FAQ where we explain in more detail many of the points raised in this discussion. In addition, the WMF produces an annual report each year that is mailed to all major donors and available electronically for all others. We also publish an annual fundraising report and our annual plan, which is pretty rare in the nonprofit sector. We make our 990s and annual audits public. Further, donors can sign up to receive a quarterly newsletter from us that updates them on the foundation’s work and they can also subscribe to Diff. Lastly, we spend a lot of time talking with our donors directly – both in-person and virtually. For example, we have held two events in the last two weeks where senior staff and board members made presentations and directly answered questions from donors. We want our donors to have a deep understanding of the Wikimedia Foundation’s work, which is much more complex than we can explain in any detail in a few sentences in a banner. Thankfully, that is not our only chance to educate our donors about Wikipedia and the Wikimedia Foundation.Lgruwell-WMF (talk) 04:05, 15 November 2022 (UTC)
- This is not what we are concerned about. What we are concerned about is distorted truth and unforgiving begging. Plenty of readers and editors have complained about the issue. We had had enough. CactiStaccingCrane (talk) 04:17, 15 November 2022 (UTC)
- "Every banner links to a detailed FAQ" – This would be good if detailed information on how and why to donate was the only thing accessible through the banner, but much more prominent than those links is an embedded donation dialogue in the desktop large banner, which allows people to donate without informing themselves. Readers looking to inform themselves before donating might not realise they can, because the FAQ link is relegated to a minuscule greyed-out font at the bottom of the banner, in contrast to the flashy design above it. small jars
tc
08:04, 15 November 2022 (UTC) For example, we have held two events in the last two weeks where senior staff and board members made presentations and directly answered questions from donors.
Are these presentations and QA sessions open to all donors, or only major donors? BilledMammal (talk) 09:29, 15 November 2022 (UTC)- That's all fine Lgruwell-WMF, and you can do as much educating of your donors as you like, but not here on Wikipedia, as that is not the purpose of Wikipedia. This is an encyclopedia - it is not a platform for free advertising. Please use your money to educate your donors through the same means as every other non-profit organisation does. SilkTork (talk) 13:35, 15 November 2022 (UTC)
- It's a small thing, but I'd like to point out the red circled "i" that's at the start of all the banners. It gives the false impression that the text following it is impartial information, rather than a message designed to inspire donations. It should go. small jars
tc
08:23, 15 November 2022 (UTC) - Query - why do so many of the opposes indicate that running the servers - the equivalent of keeping our lights on, is all the WMF need do? I would have hoped that the significant expenditure on the security team was viewed as beneficial, not to mention some degree of Legal team...and while the bare minimum T&S wouldn't need a disinformation team, I suspect our arbs would rather not have to take over handling CSE, all the threats of harm/suicide and so forth - I'd hope even those preferring a core Foundation would indeed consider them (and their salaries) core. Nosebagbear (talk) 09:12, 15 November 2022 (UTC)
- That would be the legal team that said it was ok to hire the outgoing chairman of the board, even though that's a Nonprofit-Board-101-type ethical mistake? The T&S team that brought us WP:FRAM? WMF spends more money on buying corporate stocks, mortgage backed securities, and donating to US political causes (via Tides, where the WMF's General Counsel and others used to work) than it does on Legal and T&S combined. (And that's without even talking about cost/benefit of the Product team.) If this campaign doesn't run, even if we shut off banners for an entire year, the WMF will be fine (they have enough cash reserves), maybe they'll stop treating Wikipedia like a cash trough. Starving this beast is a perfectly logical response to the excesses year after year, the beast doesn't work and we can't really trust it with money. Levivich (talk) 14:36, 15 November 2022 (UTC)
- Some updated figures and open issues:
- The revenue goal for this year has been raised to $175 million, a $20 million increase year on year.
- The WMF also plans to increase its expenses in 2022-2023 to $175 million; this is a 56% increase compared to 2020-2021 and a 21% increase year on year.
- Salary costs have increased by $20 million year on year ($88 million in 2021-2022, vs. $68 million in 2020-2021, a 30% increase).
- The Foundation reported a $12 million "negative investment income" in 2021-2022; questions about this on the mailing list have gone unanswered to date.
- The grant totals the community are given on Meta do not match what the WMF tells the IRS in its Form 990 (which is required to be public by law). Questions about this on Meta and on the mailing list have gone unanswered to date. --Andreas JN466 10:33, 15 November 2022 (UTC)
- @LMccabe (WMF) and MeganHernandez (WMF): Can you explain why the revenue goal has increased by $20,000,000, despite a conversation in May where you say that
the rate of growth seen in past years will not continue in the 2022−2023 fiscal year as we stabilize our growth and also ensure that new resources are delivering maximum impact for our mission
? BilledMammal (talk) 11:32, 15 November 2022 (UTC)- Actually, the new goal of $175 million marks an increase by $25 million in terms of goal-setting, because the 2021-2022 revenue goal was $150 million (up from about $110 million in 2020-2021). That $150 million goal was then exceeded by about $5 million. (The $110 million goal in the year prior was exceeded by over $50 million.)
- So to sum up, in two years the goal has moved from $110 million in 2020-2021, to $150 million in 2021-2022, and now to $175 million for 2022-2023. Andreas JN466 12:39, 15 November 2022 (UTC)
- @LMccabe (WMF) and MeganHernandez (WMF): Can you explain why the revenue goal has increased by $20,000,000, despite a conversation in May where you say that
- "Non-profit" Dialmayo (talk) (Contribs) she/her 14:30, 18 November 2022 (UTC)
- @BilledMammal: I've tweaked the second paragraphs opening sentence on the RfC for accuracy because I'm fairly certain the WMF never shared every banner tested in advance. I know its not something I did, mainly because its essentially impossible to. @JBrungs (WMF) might be able to clarify if that has changed since but its not something I've noticed. Seddon talk 13:22, 15 November 2022 (UTC)
- Thanks @Seddon and yes we cannot share every banner that will run throughout the campaign. As mentioned in more detail in the Comment by the WMF section, we are actively using feedback from volunteers and readers to create new banners to test all the time. It’s an iterative process and we do not yet have all the banners that will run throughout the campaign to share. In the past we shared the example banners, as we did now. I will try to share more banners as we test them throughout the next weeks on the Village Pump and the fundraising meta talk page. JBrungs (WMF) (talk) 13:28, 15 November 2022 (UTC)
- Seddon, I've tweaked your tweak to the RfC text. The WMF are perfectly able to share all banners, they just choose not to. Also, anyone who receives payment from the WMF, such as employees, contractors, and grant recipients, has a COI here and really shouldn't be !voting or changing the RfC text or otherwise taking up volunteer time about this issue since the fundraising pays them. Levivich (talk) 14:21, 15 November 2022 (UTC)
- I think the main point I was looking to clarify here was that banners that would get tested in a months time don't yet exist. Seddon talk 14:55, 15 November 2022 (UTC)
- By the WMF's choice. The "iterative process" mentioned above is a choice made by the WMF; they could submit each and every banner for community approval before running them, but they choose not to because they don't want to be slowed down. You had changed the RFC to "not able to provide", which isn't true: they are able. I changed it to "not provided". Levivich (talk) 15:02, 15 November 2022 (UTC)
- I think the main point I was looking to clarify here was that banners that would get tested in a months time don't yet exist. Seddon talk 14:55, 15 November 2022 (UTC)
- It was per this comment, where JBrungs said they would provide a list of the banners they planned to run. BilledMammal (talk) 23:07, 15 November 2022 (UTC)
- These discussions are so difficult. There are some interrelated elements that it must be hard for WMF staff to separate: objections to manipulative language, objections to misleading language, objections to banners being displayed at all, objections to the size of the WMF budget, objections to how the WMF spends its money [or doesn't], and in some extreme cases objections to the existence of the WMF at all. I suspect there would be fewer objections to manipulative language if it really were the case that we might not be able to keep the servers running next month, or if the community approved of absolutely all of the Foundation's budget items.
The number of people complaining about the budget, and the banners/messaging related to it, does seem to be growing. I don't know at what point some people will be angry enough to go on strike vs. just making things miserable for the fundraising team, or if enough people would go on strike for day-to-day activities to be radically upended, but it might get there.
I'd be curious what sort of banner message would get consensus among the folks who participate in these discussions (ideally without snarky sabotage). Like, what's the most effective fundraising message (i.e. most likely to bring in money) that would flip half of the opposes?
In any event, the foundation needs to give the community more control over some piece of the pie -- something other than grants (which shift the burden of labor/management away from the WMF, when it has staff, expertise, and resources to carry out tasks the community needs/wants). One "easy" thing to get started would be to allocate 5% of the WMF's budget to something like the "community tech wishlist" that allows for more and larger projects. In the end, the more disconnected the people in these threads feel from where the money goes, the more discontent there will be, and the harder it will be for the WMF to do anything on-wiki. — Rhododendrites talk \\ 14:57, 15 November 2022 (UTC)- You make a very important point in your last paragraph above. We could argue over the precise percentage, but the principle is important.
- I hope someone is listening. Andreas JN466 15:46, 16 November 2022 (UTC)
I hope someone is listening
: If you mean us, we all are - very intently. If you mean the WMF, well it would appear that they only scan the comments and very superficially. This goes not only for @Seddon, JBrungs (WMF), JVillagomez (WMF), MeganHernandez (WMF), RAdimer-WMF, and KStineRowe (WMF): and the rest of the 26 employees of the fundraising team, but also for all the staff in Product and Engineering. We have forced the WMF into according us a video conference with them, but the very main objective of the exercise has been met with basically a 'not enough money'. The question therefore remains: What does the WMF actually do with it's glut of funds from the donations that the volunteers' work brings in? They might be giving it away to other charities or hiring their friends as consultants. These are the details that are not revealed in their so-called transparency.- So back on topic: Thus the wording of the banners is extremely misleading and is certainly very wrong to confuse the public between Wikipedia and Wikimedia. The former is a community of volunteers who get no thanks for their work; the latter is a money-making machine pure and simple. A $17m budget for fundraising would out at about $600K for each of the staff, so where does the rest go? Kudpung กุดผึ้ง (talk) 02:57, 18 November 2022 (UTC)
- I suspect that donation processing expenses are included in the fundraising budget, but that still leaves $11m, or about $420k for each of the staff, so the question of where the rest goes remains. BilledMammal (talk) 03:16, 18 November 2022 (UTC)
- The processing fees of 4.17% for PayPal and credit/debit cards are about right. So yes, where does the rest go? I realise that WMF staff receive extraordinary geneorous remuneration packages and expenses, and in the interests of true transparency perhaps
- @JBrungs (WMF), Seddon, JVillagomez (WMF), MeganHernandez (WMF), RAdimer-WMF, and KStineRowe (WMF): can tell us how much they earn and where the rest goes. A rhetorical question of course because they won't anyway. They certainly don't appear to be concerned that the donations they beg for with their crocodile tears of starvation are driven mainly by the work of the volunteers at en.Wikipedia who don't even get any thanks. let alone the needed technical support. Kudpung กุดผึ้ง (talk) 03:55, 18 November 2022 (UTC)
- I would respectfully ask you focus on the institution not the people. This specific comment crosses a line for what I consider acceptable for this discussion. Seddon talk 04:03, 18 November 2022 (UTC)
- It doesn't cross a line at all. It is neither a personal attack nor uncivil. It is simply an expression orfopinion or a perception of the motivations of the team that writes these banners and as such it's a clear issue concerning the fundraising team who are listed a the employees of the institution, the WMF, the focus of this entire discussion. If they are not the authors of these misleading banners, I apologise, but then please tell us who is, or what external agency is contracted, and where the money goes. That's all I'm asking. People like us work for many hours for free maintaining this encyclopedia because we believe in what we're doing and many of us on this thread feel we have a right to know. Kudpung กุดผึ้ง (talk) 04:27, 18 November 2022 (UTC)
- I recognise that you might not consider it to have been personal attack, but I did. It crossed a line for me and I genuinely don't think directing that in the way you did is the best way of moving this RfC forward, even if our opinions differ on this matter. This applies especially towards JBrungs, RAdimer and KStineRowe. They aren't executives or directors and these challenges have histories that go back before any of them even worked at the WMF. They are good people, trying to help, doing their jobs to the best of their abilities.
- If we all want to get through this with a good outcome, I think it's vital that we focus our critiques and energies on the organisation and its practices, not taking out frustrations on people.
- Regarding the precise question what I noted when looking on meta was that the staff count based on Fundraising and mw:Fundraising tech is more than the 25 you noted (not sure what that number is based on exactly). Once you factor in the usual 25-50% direct staff overhead costs (pension, healthcare, employment taxes) + time from legal. That back of a napkin calculation already accounts for a massive chunk of what you are referring to. Seddon talk 05:21, 18 November 2022 (UTC)
- For reference, there are currently over 50 people working in m:Fundraising and mw:Fundraising tech, going by the people listed on those pages. Overall headcount is now around 700 (the WMF's Staff and contractors page still says "over 550" and is badly in need of an update). Andreas JN466 11:05, 19 November 2022 (UTC)
- @Seddon: I believe the information Kudpung is interested in isn't the amount individual members of the fundraising team earn, but details on where the $17 million goes. How much goes towards salaries, how much goes towards donation processing expenses, and where the rest goes. Can you provide that information, and if not can you pass the request on to someone who can? BilledMammal (talk) 05:20, 18 November 2022 (UTC)
- See above for what I worked out on wiki. There is probably also some infrastructure costs in there as well and some contracting costs but given they don't feature on the form 990 things start getting pretty granular. Seddon talk 05:25, 18 November 2022 (UTC)
- Thank you for the estimate, but I believe an official breakdown, including the more granular aspects, would be more useful. If you can't provide that, can you forward the request to someone who can? As a response to the broader request for transparency, such a breakdown in all areas of the foundation would also be appreciated. BilledMammal (talk) 05:27, 18 November 2022 (UTC)
- See above for what I worked out on wiki. There is probably also some infrastructure costs in there as well and some contracting costs but given they don't feature on the form 990 things start getting pretty granular. Seddon talk 05:25, 18 November 2022 (UTC)
- It doesn't cross a line at all. It is neither a personal attack nor uncivil. It is simply an expression orfopinion or a perception of the motivations of the team that writes these banners and as such it's a clear issue concerning the fundraising team who are listed a the employees of the institution, the WMF, the focus of this entire discussion. If they are not the authors of these misleading banners, I apologise, but then please tell us who is, or what external agency is contracted, and where the money goes. That's all I'm asking. People like us work for many hours for free maintaining this encyclopedia because we believe in what we're doing and many of us on this thread feel we have a right to know. Kudpung กุดผึ้ง (talk) 04:27, 18 November 2022 (UTC)
- I would respectfully ask you focus on the institution not the people. This specific comment crosses a line for what I consider acceptable for this discussion. Seddon talk 04:03, 18 November 2022 (UTC)
- I suspect that donation processing expenses are included in the fundraising budget, but that still leaves $11m, or about $420k for each of the staff, so the question of where the rest goes remains. BilledMammal (talk) 03:16, 18 November 2022 (UTC)
One "easy" thing to get started would be to allocate 5% of the WMF's budget to something like the "community tech wishlist"
. Yes. Something like this is needed (exact percentage can be worked out later). Community tech/the Wishlist is the volunteer's main way of requesting software, and it seems like this is understaffed. We are a rich organization, but as volunteers, sometimes it doesn't feel like that wealth is shared with us in tangible ways, e.g. fulfilling our software requests in a timely manner. –Novem Linguae (talk) 02:02, 18 November 2022 (UTC)
- Comment 2 I would also like to note that one of the things you can redeem via Microsoft Rewards is a donation to the WMF. I don't exactly remember how much is the minimum (since I'm sure you can adjust it) however this may indicate that the WMF has some sort of deal with external companies. I am not accusing the WMF of not truly being a non-profit and getting money from external companies (since the WMF may not even be aware of this Microsoft Rewards thing and Microsoft simply decided that a donation to the WMF should be one of the rewards), however I would like the WMF to clarify whether or not they took any part in the decision to make this one of the rewards you can redeem. ― Blaze WolfTalkBlaze Wolf#6545 15:36, 15 November 2022 (UTC)
- @JBrungs (WMF) and DannyH (WMF): pinging you 2 so I can get an answer. ― Blaze WolfTalkBlaze Wolf#6545 14:13, 18 November 2022 (UTC)
- Just to note that I'm watching this discussion (but also note that I'm not on the board quite yet, so can't do too much more than watch!). There is a lot of bad faith being assumed here, sadly - please remember to also AGF towards the WMF, and keep comments as constructive as possible, particularly on what could be done better with the banners (and isn't just nitpicking). Also to say that I've just nominated the redirect WP:CANCER for deletion (and suggested the destination page gets renamed), since it's quite offensive to anyone that's lost someone to cancer. Thanks. Mike Peel (talk) 18:56, 15 November 2022 (UTC)
- @Mike Peel: I bullet-voted you onto the Board. Why do I now find you bending the knee? If you're going to encourage WMF bad acts instead of seeking reform, you can expect to be opposed when next up for election. While we're on the subject, your mention of your WP:CANCER RfD (with your opinions) might violate WP:CANVASS. Surely you know better. Chris Troutman (talk) 21:38, 15 November 2022 (UTC)
- @Chris troutman: I'm not sure how you got that impression? I mentioned the redirect discussion for transparency, I don't expect mentioning it here would help much with the discussion. AGF is fundamental - particularly here in this controversial topic, let's focus on how to improve things in the future rather than ranting? Thanks. Mike Peel (talk) 21:51, 15 November 2022 (UTC)
- @Mike Peel: I appreciate you are not on the board yet, but do you have any substantive personal opinion on the fundraising banners? I ask because during the election campaign you strongly supported 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." Many of the people above (and in the prior RfC on the fundraising emails) are saying the same thing. Do you still agree with them? I can understand that the prospect of joining a board where you are likely to be outnumbered may be daunting, but there is more at stake here than personal comfort, and fitting in. Andreas JN466 09:52, 16 November 2022 (UTC)
- I've seen worse. Thanks. Mike Peel (talk) 15:09, 16 November 2022 (UTC)
- @Mike Peel: I think we all have.
Does that mean you endorse the banners as they are? --Andreas JN466 08:57, 17 November 2022 (UTC)
- @Mike Peel: I think we all have.
- I've seen worse. Thanks. Mike Peel (talk) 15:09, 16 November 2022 (UTC)
- @Mike Peel: I bullet-voted you onto the Board. Why do I now find you bending the knee? If you're going to encourage WMF bad acts instead of seeking reform, you can expect to be opposed when next up for election. While we're on the subject, your mention of your WP:CANCER RfD (with your opinions) might violate WP:CANVASS. Surely you know better. Chris Troutman (talk) 21:38, 15 November 2022 (UTC)
- Comment: Making Wikipedia truly accessible to everyone requires significant, ongoing investment. It requires a substantial technology investment - above and beyond data centers and caching centers, software and infrastructure as well as the engineering staff to support one of the top ten websites in the world. It includes legal support to defend our projects from threats of censorship and support our volunteer communities. It includes supporting the growth of volunteer editor communities around the world - including through our grantmaking practices. This is why we fundraise. And we have so much more to do, if we are to achieve the vision of our movement and be representative of the sum of all knowledge - across languages and regions.
- In FY2022-23, our programmatic work will be allocated across a variety of work that supports our communities and websites. We expect roughly the breakdown to be the same as it was in FY2021-22:
- 43 percent - direct support to websites (engineering improvements, design, legal support)
- 33 percent - support to the volunteer community through grants, programs, training, tools, advocacy, and other support
- 24 percent - other (14 percent on administration and governance, 10 percent on fundraising)
- As set by our Board of Trustees and outlined in our annual plan, we operate on an annual budget of USD 175 million. In the past fiscal years, as the Foundation has grown we have invested in key areas, including single points of failure in our tech infrastructure, movement-supporting infrastructure including translation, an expanded Global Advocacy team to protect against regulatory threats to free knowledge and censorship, to name a few. In the current and upcoming fiscal years, we do not expect the same budget growth from recent years to continue, as we shared in our annual plan. The increased revenue goal for FY 2022-2023 compared to the previous year is primarily due to an increase in costs due to inflation and a 28% increase ($5M) in the grants budget and less by the growth in the number of employees, which is stabilizing this year.
- In line with non-profit best practices, we started this fiscal year with roughly 16 months of operating expenses in our reserves. These are not funds that we use on a day-to-day basis. The reserve can only be accessed in exceptional circumstances, such as an economic crisis and help fulfill the Foundation’s responsibility to ensure the sustainability of Wikimedia projects, as public resources, into the future. This has become especially relevant given the global pandemic and economic turbulence. We keep a target of 12-18 months of operating expenses in our reserve as outlined in a resolution passed by the Board of Trustees in June 2022.
- Finally, regarding the question about grants - in the past fiscal year, we increased our overall grantmaking to the movement. In terms of reporting of grant totals, the difference from grant reports on Meta and those shared with the IRS is due to a few things. Firstly, our grants report focuses on our grantmaking programs listed here, while the 990 includes some additional activities that meet the definition of grantmaking. Secondly, there are some instances where the fiscal year period where grants are reported is different in the 990 and the grant report. This is the case for some instances where grants cover multiple fiscal years. Lastly, the 990 geographic classifications are different from the Foundation’s grantmaking regions. This is because some of the regional classifications in the 990 aren’t representative of our movement.JVillagomez (WMF) (talk) 23:20, 16 November 2022 (UTC)
- The "33 percent - support to the volunteer community through grants, programs, training, tools, advocacy, and other support" would be about $50 million. This is about five times the Awards and grants total once you account for the five million going to Tides. What exactly do you include in those 33%? Mathematically, it must include a significant part of the salary bill.
- The Grantmaking figures for South Asia and other regions are far smaller on the Form 990, are they not? See m:Talk:Grantmaking/Reports/2020-2021.
- Where is the public accounting for the $4.223 million Tides Advocacy were given in 2019/2020 together with the $4.5 million they were given for the Knowledge Equity Fund?
- supporting the growth of volunteer editor communities around the world - including through our grantmaking practices: Does this mean paying consultants and organisers so they can then try to get people in poor countries to edit for free?
- What is the reason for this year's negative investment income (a $12 million loss)?
- Going from a target of $108 million to a target of $175 million in two years has little to do with inflation (currently below 8%) or the ability to increase grant expenses, given that the Foundation had a $60 million surplus over the course of those two years ($70 million if you include the fact that its "expenses" included $10 million it paid to Tides for its own endowment). It's about growth – "the fundraising team will be increasing targets in each of their major streams" – while the fundraising banners speak of "protecting" and "sustaining". It's appalling.
- Andreas JN466 00:37, 17 November 2022 (UTC)
43 percent - direct support to websites (engineering improvements, design, legal support) 33 percent - support to the volunteer community through grants, programs, training, tools, advocacy, and other support 24 percent - other (14 percent on administration and governance, 10 percent on fundraising)
- Can the WMF issue a more-detailed breakdown of those figures in its budget, like using the same line item descriptions as are used on its Annual Financial Statements and/or Form 990, so the public could see a real budget-v-actual with the three classes (direct, community, admin)? 43% of $175M is $75 million. How many full-time engineers does that pay for? 33% is $57M. How much of that actually gets given away in grants, and what is the rest used for? And 10%--$17.5 million--on fundraising, how is that spent? Are we airing a Superbowl commercial? These are very broad categories, and I have a hard time matching the Annual Plan categories with the Financial Statement and Form 990 line items. Thanks, Levivich (talk) 00:33, 17 November 2022 (UTC)
- Propose replacing with "We're Hiring Community Tech Developers!" banners: Per meta:Special:Permalink/24052090, which has been replaced with the current version of meta:Community Wishlist Survey/Updates/2023 Changes Update. RAN1 (talk) 04:51, 17 November 2022 (UTC)
- @RAN1: Thanks. (Did you mean to post this here? The RfC's survey section is above.) So the Community Wishlist Survey was going to be cancelled in 2024? Interesting. Did you know about this, Kudpung? Andreas JN466 08:33, 17 November 2022 (UTC)
- I don't think this is in the scope of the survey. RAN1 (talk) 18:23, 17 November 2022 (UTC)
- @RAN1: Thanks. (Did you mean to post this here? The RfC's survey section is above.) So the Community Wishlist Survey was going to be cancelled in 2024? Interesting. Did you know about this, Kudpung? Andreas JN466 08:33, 17 November 2022 (UTC)
- Hi Andreas yes, I knew about it. See the thread about it and my reaction to it. Kudpung กุดผึ้ง (talk) 23:33, 17 November 2022 (UTC)
- Comment: Hi everyone! I’m Selena Deckelmann, the WMF’s new Chief Product and Technology Officer. I hope I can add some detail and color to this important conversation. I joined the Foundation about four months ago, and I’ve spent that time learning about the sheer scale and complexity of the technical infrastructure that powers our work. (Krinkle shared this diagram with me recently and it’s a fascinating view of just one large part of what it takes to support 950 separate wiki instances and a website that is among the top 10 in the world.) I’ve read some of the comments here comparing our costs now to ten or fifteen years ago. These estimates are outdated, and do not account for the enormous growth of content and traffic our sites support today, and the increasing challenges of a more complex, dangerous and sophisticated internet. Back then, we did not have a sustainable model for the engineers who keep the site reliable, we didn’t have backups, and we didn’t have a second data center.
- Compared to that snapshot from ten or fifteen years ago, the Foundation’s scale has increased to support the need - for our readers as well as for our contributors, for all of you. We now have two main data centers, four caching data centers in Amsterdam, Marseille, Singapore and San Francisco, and 32 internet peering connections. These systems ensure that wherever a person is in the world, Wikipedia and related projects are able to be accessed, quickly and reliably.
- We maintain the software and infrastructure for all of these wikis and over 2600 community-contributed tools. We have more than 40 product and tech teams managing more than 500 software extensions, products, features and libraries that each require specialized skillsets (1+2), more than 3.2 million lines of code as of September 2022, 900+ customized instances of MediaWiki that need a ton of code-testing for every change (1), 50,000+ open phab tasks (1), and 50+ wishlists (1). We also maintain substantial data infrastructure that enables volunteers to gain direct access to wiki content and to analytical information about the wikis, and the Toolforge platform for volunteers to host tools which assist their work. The projects are now more reliable and faster than they’ve ever been; even during the record-breaking page visits we saw after the death of the Queen of England, Wikipedia never went down, when a fraction of that amount of views would have taken the site offline before.
- This is an enormous volume of work, yet our overall efforts are still quite lean compared to the scale of needs on our sites. For example, before we added our latest Marseilles data center, staff internally used to worry that our primary European data site in Amsterdam was "too big to fail". It’s safe to say that maintaining Wikipedia, and supporting it as it grows with infrastructure and software improvements, is an enormous effort. This effort increases in scale and complexity each year, even as we seek to reduce the speed of our overall Foundation growth and better address issues of technical debt raised here and in other forums by volunteers.
- I want to acknowledge the concerns I see on this page and in many other forums about the responsiveness to the specific technical needs of volunteers. While we have places like the community wishlist to understand and respond to community needs, those should not be the only places where we’re able to hear from you and work together on what you need. As part of my listening tour as I’ve joined, I’m speaking with both editors and technical volunteers to understand how we can engage better and work together on supporting the projects. I invited volunteers to a recent product and tech department meeting in Berlin, and I attended a recent board Community Affairs Committee meeting in which we talked about support for Commons and for New Page Patrol. And I participated in a subsequent roundtable meeting to discuss page patrolling issues across the wikis, from which further conversations, code review, and technical investigations have all begun.
- One of the things I’ve said to Maryana recently is that planning out the future of work on Wikipedia and our many projects requires significant historical context, which is why I decided to spend several months on a listening tour before deciding to make significant changes to the work of my departments. In addition, the software that helps sustain the movement, and the internet itself, have changed significantly and grown increasingly complex over the last 20 years. The ever increasing complexity of our work isn’t something the staff speak about in detail, and I wonder if perhaps we should spend some time on that in the future. There’s a thread about the current state of Twitter in relation to their former staff and some of the kinds of issues site reliability engineers face at internet service companies. This is a worthwhile read and incomplete view of the kinds of issues some WMF teams face daily, which addressing requires many experienced people and their good judgment to resolve.
- To achieve what we set out to do, Foundation and volunteers together – to collect and make available to the whole world the sum of all human knowledge in perpetuity – it’s just an incredibly large and nearly impossible challenge. I feel so excited that I get to focus on this problem with you all, and it will take some time to understand the complexity, the current reality and set out a strategic path for allocating resources across the product and tech departments at WMF. I continue to meet with people on my listening tour, and I invite anyone here to reach out to my talk page to share your vision about our future together. I don’t have specific answers yet, but I am making a commitment to listen and find ways we can more frequently and productively work together. SDeckelmann-WMF (talk) 00:38, 19 November 2022 (UTC)
- @SDeckelmann-WMF thank you for this thoughtful reply and the obvious effort you're putting in here. I appreciate the difficulty of your work as a professional software engineer myself. Best of luck 🙇♂️ Nicereddy (talk) 01:20, 19 November 2022 (UTC)
- Hi SDeckelmann-WMF, thank you for the extended reply. If I understand the structure of the WMF correctly I think the area under your control is the one we are least dissatisfied with; we appreciate your efforts to keep Wikipedia online and running reliably, despite a sometimes challenging environment, and I don’t believe anyone is criticising the money spent on that, although the lack of transparency may result in us misestimating how much is spent there.
- I believe the biggest issue we have with the work of your teams, and the volunteers who work more closely with them will correct me if I am wrong, is instead the new products develop; you often decide what we need, rather than giving us the chance to tell you what we need. What we are asking for here is for you to change that; to commit to not developing major new products without talking to the people you are developing those products for, and to commit to listening to us when we tell you we need something.
- However, what I believe we want most from the WMF is to commit to respect the consensus here. Once you have done that, we can start talking about what would be required to repair the relationship between enwiki and the WMF. If you are not authorised to make that commitment can you contact those who are? BilledMammal (talk) 02:23, 19 November 2022 (UTC)
- @SDeckelmann-WMF: I don't believe you actually read the discussion above (which in itself says a lot!) – because I cannot find a single comment in the Survey section that references what costs were like 10 or 15 years ago. Your post reminds me of Boris Johnson, who'd always try to overwhelm discussions by spouting figures of "million of this ... millions of that ... new hospitals ... more nurses ... more police on the streets" whenever he was in hot water.
- It is very simple:
- The WMF reported a $60 million surplus over the past two years (that surplus is bigger than the amount this banner campaign is designed to bring in).
- The WMF is $50 million ahead of schedule with its m:Endowment.
- It's planning to increase expenditure from $112 million in the year ending June 2021 to $175 million in the present year (when I mentioned this to a journalist yesterday, they said it was "bonkers"), but is using fundraising messages suggesting Wikipedia's independence or existence is under threat – at a time when many people's financial existence is genuinely under threat.
- So far the WMF has rolled out one executive after the other on this page, each paltering and failing to actually engage – or answer queries of course. I see little sign of progress. Andreas JN466 09:12, 19 November 2022 (UTC)
- Hi SDeckelmann-WMF. I've been an editor on Wikipedia for around 9 years now and I think I'm quite typical of the volunteers in this discussion, so I'm a bit confused by your comments. If you've been working at the WMF for less than six months and I've been volunteering for nearly 10 years, why do you think you need to "add some detail and color" rather than listen to what I am saying?As a community, we are aware of what's changed in the last 10 to 15 years, because we've been here. We are aware of what the tech infrastructure is like from both a reader and an editor perspective, because we are both of those groups. Many of us also have technical backgrounds, work as programmers or have lots of experience with how the internet works. It is not news to me that we need lots of technical staff, lots of money for servers and that individual employees at the WMF do an incredible job in ensuring access to Wikipedia is available as widely as possible (given government censorship).Talking about support for Commons and NPP is of no use to us. Providing support for Commons and NPP is of use to us, and I trust Kudpung in their reports back to the community that there is no help being planned for NPP.Instead of patronising us, why not read just some of our comments in detail and leave a reply that shows that you have understood some of our concerns? — Bilorv (talk) 11:14, 19 November 2022 (UTC)
- What I can say is that I'm sure she's going to do what she can for NPP, Commons, and software requests from the communities. It won't happen overnight though and after waiting a decade, we're getting impatient. She hasn't, and never will have the institutional memory of those of us who have been around since the days when the WMF had 7 employees and and having a one-on-one Skype call with the WMF vice president was a normal thing to do and get things done. I'm not defending her because I've spoken with her, but she doesn' t have her hands on the purse strings - yet - at least until she discovers the full power of her position.
- My hope is that she will steer the devs away from their traditional thinking that they know best and what they believe the community 'might' want, and wasting millions of dollars developing it, and instead listen to the editors and understand what is needed. That would be the sensible way to spend the glut of funds that is currently used for everything else in preference to essential editor engineering and newbie onboarding, and forcing our volunteer editors to write patches only to have them rejected by the overlords at Phab.
- There would then be the basis for some honesty in the texts of the fundraising banners - which incidentally seem to have missed the copy editing stage before they were released. Let's hope she can effect that turnaround; it will be a challenge because she does first need to find her way around the madhouse she has joined and never will be able to micromanage, and for the moment all she can do is talk about it.
- In the meantime I must reaffirm my oppose vote in this RfC. Kudpung กุดผึ้ง (talk) 14:06, 19 November 2022 (UTC)
- As for the "enormous growth of content and traffic our sites support today", it should be noted that page views for English Wikipedia have been pretty stable for the past six years. The same goes for page views of all wikis taken together.
- Click the links. Select "All time" instead of "Last Two Years" on the left to see data going back to 2016. For even older data, select "Legacy page views". According to those graphs, page views for "All wikis" have risen very little:
- Monthly page views for "All wikis" were 24,242,133,946 in October 2013.
- Monthly page views for "All wikis" were 24,460,156,652 in October 2022.
- This sort of thing happens time and again with assertions made by our highly paid WMF executives. They fall apart once you actually look into them. Andreas JN466 13:05, 19 November 2022 (UTC)
Planned low level weekend test
From 18 November to 20 November, the WMF is planning to run a low level banner test as the final test before the campaign is scheduled to be launched on 29 November. Based on the overwhelming response in opposition here I've asked them to cancel that planned test. BilledMammal (talk) 02:44, 16 November 2022 (UTC)
- JBrungs has informed me that they plan to continue with the low level weekend test. Their comment also implies that they continue to prepare for the December campaign, despite the clear consensus here.
- We need to decide whether in line with the proposed method of enforcing the consensus we use Common.css to block the test this weekend, or if we wait and see if they attempt to run the campaign before taking action. BilledMammal (talk) 21:28, 17 November 2022 (UTC)
- @BilledMammal: I suggest posting at WP:AN to get more input. Andreas JN466 21:57, 17 November 2022 (UTC)
- If the WMF schedules the banners (see here and here) that may be needed, but I hope they will chose to accept the consensus of the community. BilledMammal (talk) 03:07, 18 November 2022 (UTC)
- You're getting way ahead of yourself declaring a consensus for a sitewide ban on fundraising tests. The discussion has only been running for three days and has had ~50 comments (out of 40,000+ active editors on enwiki mind you). By comparison, the WMF has been testing banners on and off for over a decade, so it's not exactly an emergency that they're going to run another short test for a few days. There's no community precedent that WMF has to stop and gain consensus prior to running banners either. This is just like when you rushed to edit WP:BOT based on your hasty misinterpretation of the RFC, and that one was actually closed by uninvolved editors, unlike this. Asking people to take the nuclear option and edit Common.css when the discussion is ongoing is pretty pointy. Steven Walling • talk 03:45, 18 November 2022 (UTC)
- I recognize that you support running these banners, but there is a clear snow consensus that they should not be run, and to run the test would be disruptive WP:IDHT behaviour. (WP:POINT, however, does not apply to any editor involved, as it only applies to an editor
making edits with which they do not actually agree
) BilledMammal (talk) 03:57, 18 November 2022 (UTC) - Steven Walling, you are fully aware that of the 40,000+ active editors on enwiki only a couple of hundred (444 at the last count) are aware of what goes on in the back office, and even fewer know what goes on behind closed doors at the Foundation. The nuclear option might well be the result the WMF gets this time. And I would support it. The loss of a year's worth of donations from en.Wiki readers is maintainable and would bring the WMF to its senses. Kudpung กุดผึ้ง (talk) 04:08, 18 November 2022 (UTC)
- Support it or not, the RFC hasn't closed. Demanding enforcement of a decision that hasn't been made yet is putting the cart before the horse. Steven Walling • talk 04:17, 18 November 2022 (UTC)
- Demanding that an editor stop engaging in certain actions while those actions are under discussion and the discussion is clearly trending towards finding those actions inappropriate is normal practice.
- However, no editor is demanding enforcement here. I asked a question, whether we should block the tests if the WMF attempts to go ahead with them, or if we should wait and see if the WMF attempts to run the campaign before taking action. I assume you prefer the latter? BilledMammal (talk) 04:49, 18 November 2022 (UTC)
- Please stay on topic Steven. I wasn't discussing the duration of this RfC or when it should be closed. or even remotely hinting on 'demanding an enforcement' of anything. I'm just putting the writing in the wall like I did many years ago about the IEP. The WMF wouldn't listen, the damage cost a couple of $M in wasted money, and I organised a team of volunteers to clean up the Foundation's mess for free. That's the level of confidence today's community has in the WMF who is driving it's own wedge even further into the rift. This is already a substantial RfC and the Foundation needs to take note. It's not a straw poll, the head count doesn't matter, they need to listen to the reasoning of the arguments and have some respect for the unpaid volunteers whose work brings in the money. . Kudpung กุดผึ้ง (talk) 04:56, 18 November 2022 (UTC)
- @Kudpung: a brief aside for the uninformed – what was the IEP? I've never come across this term on Wikipedia before in connection to the WMF's actions.—Ineffablebookkeeper (talk) ({{ping}} me!) 21:14, 18 November 2022 (UTC)
- Support it or not, the RFC hasn't closed. Demanding enforcement of a decision that hasn't been made yet is putting the cart before the horse. Steven Walling • talk 04:17, 18 November 2022 (UTC)
- I recognize that you support running these banners, but there is a clear snow consensus that they should not be run, and to run the test would be disruptive WP:IDHT behaviour. (WP:POINT, however, does not apply to any editor involved, as it only applies to an editor
- You're getting way ahead of yourself declaring a consensus for a sitewide ban on fundraising tests. The discussion has only been running for three days and has had ~50 comments (out of 40,000+ active editors on enwiki mind you). By comparison, the WMF has been testing banners on and off for over a decade, so it's not exactly an emergency that they're going to run another short test for a few days. There's no community precedent that WMF has to stop and gain consensus prior to running banners either. This is just like when you rushed to edit WP:BOT based on your hasty misinterpretation of the RFC, and that one was actually closed by uninvolved editors, unlike this. Asking people to take the nuclear option and edit Common.css when the discussion is ongoing is pretty pointy. Steven Walling • talk 03:45, 18 November 2022 (UTC)
- If the WMF schedules the banners (see here and here) that may be needed, but I hope they will chose to accept the consensus of the community. BilledMammal (talk) 03:07, 18 November 2022 (UTC)
- The fundraising team has been listening to the comments here this week. We’re excited to try ideas that have been suggested by volunteers for the weekend test. We’re preparing messages that feature a phrase that y’all have suggested we highlight, advance the cause of free knowledge in the world. We are also highlighting sister projects and the Foundation, and piloting some changes to the Only 2% give message. We welcome more ideas for messages to test here. - SPatton_(WMF) SPatton (WMF) (talk) 21:04, 18 November 2022 (UTC)
- I've updated the list of recent banners to include the ones from this weekends test. Unfortunately, it doesn't appear you are listening to us enough, both in terms of the content of the test and the test itself, which by running despite the emerging consensus suggests you are dismissive of the communities feelings.
- For the content of the test, you continue to test banners that don't address the concerns; it appears the only concern you have consistently addressed is conflating the WMF with Wikipedia, but even there you have only addressed it in about half of the banners. In addition, the biggest issue with the banners, that they suggest Wikipedia is under threat, continues. BilledMammal (talk) 21:18, 18 November 2022 (UTC)
- User:SPatton (WMF): This is not good enough. Please stop asking people to "support Wikipedia's independence" or "sustain Wikipedia". You know the performance of those banner wordings already; there is no need to run another A/B test with them. You are in WP:IDHT territory here.
- Talk about the Wikimedia Foundation, what it is, what it does, and what it wants. And please do it without paltering. Andreas JN466 21:38, 18 November 2022 (UTC)
- For some of the banners it's too late. They ran between 2022-11-18 21:00 (UTC) and 2022-11-21 21:00 (UTC) on enwiki for readers from Australia, Canada, Britain, Ireland, New Zealand and the United States and they are full of errors (I'd provide a list but I don't see why I should do the WMF's work for free again). Why should the volunteers have to suggested ideas? Isn't that what the volunteer driven donations are paying $17M for? Kudpung กุดผึ้ง (talk) 23:48, 18 November 2022 (UTC)
- @BilledMammal: I suggest posting at WP:AN to get more input. Andreas JN466 21:57, 17 November 2022 (UTC)
Deciding whether to obstruct → specific conditions to continue
I'd like to suggest reframing this discussion. The decision to halt WMF fundraising is a drastic step, but there's clearly growing support for it. Regardless of whether this represents a minority in the grand scheme of the English Wikipedia community, there don't appear to be many willing to jump in the line of fire in defending the fundraising, so canceling the banners (or a very ugly conflict) is a real possibility. I still say the main reason we're here is because of widespread hurt and resentment towards how the foundation has been run (and specifically how money is spent). There will be a few people who say "no banners no matter what" or "burn it to the ground", but that is an extreme position. For most of us, I suspect it's entirely possible the WMF could change how it does things enough that fundraising would return to being an infrequent annoyance (like all fundraising) rather than a reminder of the distance between the volunteers and the foundation.
Throughout this discussion, some people are offering concrete suggestions, but the suggestions vary by person, and are all undercut by the number of people who'd sooner write "WMF sucks, don't donate" than have any fundraising. That's in part because of how this RfC is framed: it's only about a yes/no to fundraising banners, without any attempt to turn it into something that actually benefits the community (except insofar as not running banners benefits the community). Meanwhile, we're coming up on the time when the banners run, and a sizable staff has to scramble to figure out how to interpret the opinions and emotions expressed here in a short window of time (it would be entirely valid to point out that people have been raising these issues for some time, however, so they should've been able to see this coming).
We've made it clear there's a lot of hurt here, and that there are a lot of people willing to take drastic measures because of it. Rather than just decide to obstruct fundraising, however, let's shift conversation to conditions to continue.
I still believe that most of the people who are upset about the banners wouldn't be so upset if they didn't have such a problem with how the foundation allocates its money. That makes me wonder what sort of change in the WMF budget would be enough. Above I made one suggestion. What if the WMF guaranteed that 5% of its annual budget for the next five years would be dedicated to community-selected projects (call it an expansions of the community tech wishlist or something else, but it would be entirely for tasks selected by the community and carried out by WMF staff, without the need for a grants process and without the need for volunteers to do the labor of management, hiring, etc.)? Think of all that could do for us (not to mention readers). Of course, they can't implement that in a matter of a couple weeks, but it's not impossible for them (the board, I suppose) to make that decision. If bureaucracy moves too slowly, we could also say "this is the last time you get to run fundraising until you do this" (which gives them more time to figure things out without jacking things up in the short-term). Thoughts? — Rhododendrites talk \\ 16:42, 18 November 2022 (UTC)
- I'm not sure entirely how I feel about it, but I'll say this: no banners is a perfectly reasonable position. As in: don't run these banners, don't run any banners this year, don't run any banners until further notice... all are reasonable positions. Even if WMF fundraising were necessary (and I'm not sure about that, I'd rather see them divest themselves of their toxic corporate investments, like millions on mortgage-backed securities, before they ask for donations again), they don't necessarily need to fundraiser on-wiki, or on en-wiki. If the community decided to just ban banners until the WMF gets its spending act together, I'd be fine with that. BTW this whole "guarantee 5%" idea is a dead end. They already say they spend 40% on direct support but without meaningful reporting we know it's not true. Also, the budget is set by people we elect (trustees) and always has been. This isn't really about a miscommunication, or about the community having no power. It's more like: the people we elect to trustees historically have simply not provided financial oversight of the kind the community wants. Maybe these new trustees will do something different. Meh, I'm fine with shutting off fundraising banners on enwiki until they do. Instead of us providing a roadmap, let them make a request to turn banners back on, and we can evaluate what's changed at that time. Levivich (talk) 16:57, 18 November 2022 (UTC)
- Part of my issue is that the banners are extremely misleading. And also the WMF has a crap ton of money already (more than they need) so why would they want more except to get rich? And also even if the WMF guaranteed 5% of the annual budget to community-selected projects there's nothing to enforce that. So it could be proposed, they approve it and then they never do it or just "forget" and continue with what they're doing. And there's also a lack of transparency between the WMF and the community. ― Blaze WolfTalkBlaze Wolf#6545 16:50, 18 November 2022 (UTC)
- If every cent of the money went to improving the projects in visible ways and all of their outreach initiatives around the world were extremely successful, bringing in tons of new editors and appreciation for what we do, I don't think anyone would be talking about having too much money. As for
they approve it and then they never do it
- the point here is that there are people on-wiki willing to put a stop to on-wiki fundraising efforts. They could theoretically also implement something like superprotection to force the banners through, too, but why would you get into such a massive, damaging conflict with the volunteers when you can allocate a piece of the budget to something they want instead? — Rhododendrites talk \\ 16:55, 18 November 2022 (UTC)- From my experience the people from the WMF who communicate here on-wiki have a lot of respect for the volunteers. However there are some in the WMF that don't seem to care about the volunteers and do what they think is right. For example they created Vector 2022 when no one deemed the current vector bad. And recently they changed the buttons for Wikilove and adding a page to your watchlist from pink and blue respectively, to monotone black and white without even thinking to ask if we would want that. ― Blaze WolfTalkBlaze Wolf#6545 16:58, 18 November 2022 (UTC)
- I think it's unrealistic to have them consult the community for every minor design change (like color changes for certain buttons). It'd essentially grind all development of MediaWiki software a halt, and they'd end up in even more of a bureaucratic hell then they already are. Nicereddy (talk) 01:55, 19 November 2022 (UTC)
- From my experience the people from the WMF who communicate here on-wiki have a lot of respect for the volunteers. However there are some in the WMF that don't seem to care about the volunteers and do what they think is right. For example they created Vector 2022 when no one deemed the current vector bad. And recently they changed the buttons for Wikilove and adding a page to your watchlist from pink and blue respectively, to monotone black and white without even thinking to ask if we would want that. ― Blaze WolfTalkBlaze Wolf#6545 16:58, 18 November 2022 (UTC)
- If every cent of the money went to improving the projects in visible ways and all of their outreach initiatives around the world were extremely successful, bringing in tons of new editors and appreciation for what we do, I don't think anyone would be talking about having too much money. As for
- 5% seems far too small - 95% of the budget is out of community control. Moving to some sort of model where all of the money (save for credit card processing fees) is kept in escrow for ENWP to disburse to the Wikimedia Foundation and other organizations as it sees fit would work, and would provide oversight as to how the funds are spent - making the banner ads more accurate. There used to be a Funds Dissemination Committee that provided a check on spending, and now that's gone. TomDotGov (talk) 16:58, 18 November 2022 (UTC)
- My reading of the above Opposes is that the prime objection is to the banners' content (because they confound Wikimedia and Wikipedia, imply a financial emergency for Wikipedia when there isn't one, are seen as manipulative, dishonest, unethical, lying to readers etc.). I don't see people saying, "Yes, your banners are manipulative and dishonest, but if you give us a bigger share of the loot, we'll shut up about it."
- Also agree with Levivich above. According to the 2021-2022 fundraising report, total income from banners amounted to $58 million, which was about a third of the $165 million total. Let us remember: the WMF had a $60 million surplus in the last two years, and has already brought in millions from banners run in other countries and language versions. No banners on English Wikipedia this year is a perfectly reasonable position to take. Andreas JN466 17:38, 18 November 2022 (UTC)
- @Jayen466: I'd second this. If the big problem highlighted in mostly every Oppose response is "the wording of these banners is slippery and unethical", I don't think it's reasonable for us to turn around and say "we just want more of the money, please", because that's also unethical – and I'd also hope that most people would see that as something that would give the WMF an out on this issue, and would itself be us repeating the problem, continuing what other editors have stated is a years-long issue and contributing to what seems like a pretty toxic cycle.
- The fact we're starting from a standpoint where the WMF's finances, allocations and fundraising efforts are becoming increasingly opaque over time means that there is, increasingly, becoming less and less to put our faith in. The WMF staff here seem pulled between responses that acquiesce to the will of the community and what I can only describe as corporate firefighting. I don't think that's something we should be putting faith in. I don't think it's bold, I don't think it's reasonable, and I don't think putting faith in something that could simply be rescinded later is worthwhile.
- I've seen mentions of WP:AGF used in response to editors who have posed genuine, important questions that are not comfortable for the WMF, and I've seen a mention of WP:CANCER be met with raising it at redirects for discussion, in the middle of this RfC – ostensibly because "it may be offensive to those who have lost a loved one to cancer"; it smells like a bad faith effort to avoid association with being described as "cancerous" to me. (No questions were asked about whether the editor who mentioned WP:CANCER had lost a loved one to cancer; on the redirect for discussion, this also wasn't asked of the original author of the essay themselves.)
- I appreciate that there will be some WMF staff who may be, or feel, hamstrung against speaking out as much as they would like to, and who may feel forced to offer only what they also feel is frustratingly limited progress forwards on this issue; I don't know what their working environment may be like. Likewise, I appreciate that there will be some WMF staff that won't feel this way.
- However, this is our community; not to put too fine a point on things, but at the end of the day, I have contributed several hundred hours of editing to Wikipedia for free, and what I have received in return is also several hundred hours of editing, contributed for free, from other editors. I have spent time I could have spent working on this website. I have spent time writing about my subject matter in detail, and have purposefully bought resources I can use as references, in order to proudly contribute to this project. The WMF pays to keep the lights on, and it does pay for some projects, but it also won't lay out specifically what gets allocated to which projects, so how are we to know the specifics of how effective it is?
- The entire reason we have a community consent process is that this website is run off the labour of our edits, and that we otherwise would have no controlling stake – no shares, no job position, no annual bonuses, no benefits and no pay. However, reliable editing and reliable editors is something that this website needs to run, as without it, we're looking at a return to Wikipedia of the late 2000s, when I was repeatedly told in school that it was a wholly unreliable resource, and not to be trusted at all. I don't want to see that. None of us want to see that. But I don't want to see the WMF attempt to fundraise in one hand and promise it'll do what we ask of it in the other; I don't want to be "kept happy enough" that they don't have to really sober up to these fundraising efforts. As Wikipedia grows better, do we allow the WMF to backslide as a charitable organisation, and become worse?
- Stopping banners for a year, and promising that they will not be allowed to return unless the community finds them agreeable in consensus, is entirely reasonable. Wikipedia relies on you and I to run; and the WMF relies on you and I for its continued existence, fundraising, and profit. If it cannot show that it can use our labour in good faith, then it should not be allowed to use it for its own ends at all – not this year, and not the next.—Ineffablebookkeeper (talk) ({{ping}} me!) 21:49, 18 November 2022 (UTC)
- My position is that everything that appears on a rendered page in the mainspace should comply with core content policies. The banners have to be verifiable and neutral, and they mustn't deceive by omission. No paltering.—S Marshall T/C 21:25, 18 November 2022 (UTC)
- Reading the opposes, I believe the common thread is the lack of engagement with us from the WMF. We are a key stakeholder in this broader project and I believe the community is asking that the WMF respects this.
- The exact form that the community expects this to take isn't currently defined; there are a number areas that the community wants to see change in, including giving us more influence over banners, fundraising decisions, and resource allocations, as well as the WMF providing more transparency about its operations, including in its relationship with tides. I believe what the WMF should commit to doing now is delaying the fundraising campaign to give them time to negotiate with us; I believe we will be able to come to a mutually acceptable compromise that will allow the campaign to take place this year while addressing the broad array of issues that currently exist in our relationship. BilledMammal (talk) 21:53, 18 November 2022 (UTC)
- I'm more than happy to compromise on my actual, reasonable position: no fundraising banners should be run, indefinitely (to be revisited if the WMF ever does allocate its funds sensibly and faces a shortage).If the WMF guaranteed a substantial change like the 5% budget initiative, I would be delighted with that outcome—which we could then give them space to implement, then scrutinise and revisit. A guarantee needs to be using wording agreed with us.I am not happy to compromise on what would already be a comprise until we reach the position where we're telling the WMF, "yes, you never acknowledged the substance of what people oppose around the banners, but we're giving you another year to actually listen or... well, probably nothing will happen next year either".To get a substantial change like the one you are proposing, we need to threaten to pull the banners unless they agree. Or use our leverage in some other way (like an articles blackout or complaints to the media). Without being willing to recognise and exercise our power, the WMF will continue failing to recognise our authority. — Bilorv (talk) 11:48, 19 November 2022 (UTC)
Comment from the WMF (2022 fundraising banners)
Dear all,
I would like to give you some more background and information on the fundraising banners. I have shared the latest banners that we are using for the banner pre-tests leading up to the English campaign to non-logged-in users. As our campaigns are built on continuous iteration and improvement, the team will continue to incorporate your feedback and ideas into our testing in the next few weeks, as well as daily iteration throughout the campaign.
Example Messaging (2022 fundraising banners)
Over the last year, some editors have provided feedback on messaging they would like to see changed in banners. Some of those changes we have already made and are listed below. The team combines feedback from editors, along with feedback from readers and donors, to shape our campaigns.
Example current message (this is our Desktop Large message which is shown once to non-logged in users, then smaller banners afterwards):
To all our readers in the U.S., Please don’t scroll past this. This Monday, for the 1st time recently, we interrupt your reading to humbly ask you to support Wikipedia’s independence. Only 2% of our readers give. Many think they’ll give later, but then forget. If you donate just $2.75, or whatever you can this Monday, Wikipedia could keep thriving for years. We don't run ads, and we never have. We rely on our readers for support. We serve millions of people, but we run on a fraction of what other top sites spend. Wikipedia is special. It is like a library or a public park where we can all go to learn. We ask you, humbly: please don’t scroll away. If Wikipedia has given you $2.75 worth of knowledge this year, take a minute to donate. Show the world that access to neutral information matters to you. Thank you.
Example current message (this is our Mobile Large message which is shown once to non-logged in users, then smaller banners afterwards):
To all our readers,
Please don’t scroll past this. This Monday, for the 1st time recently, we interrupt your reading to humbly ask you to support Wikipedia’s independence. Only 2% of our readers give. Many think they’ll give later, but then forget. If you donate just $2.75, or whatever you can this Monday, Wikipedia could keep thriving for years. The price of a cup of coffee is all we need.
We don't run ads, and we never have. We rely on our readers for support. We serve millions of people, but we run on a fraction of what other top sites spend.
Wikipedia is special. It is like a library or a public park where we can all go to learn. Wikipedia is maintained by a nonprofit, and the 58 million articles that compose it are free. Without reader contributions, we couldn’t run Wikipedia the way we do.
We want to make sure everyone on the planet has equal access to knowledge. We still have work to do.
If Wikipedia provided you $2.75 worth of knowledge this year, please take a minute to secure its future by making a donation. Thank you.
You can compare this most recent banner to the banner that was used in December 2021.
Here are examples of messages the team is currently working on. We would appreciate feedback on our meta page around these ideas and welcome more ideas we can try in the upcoming campaign:
- While so much of what you find online these days is questionable, we strive to provide you with a reliable, unbiased source of quality information when you need it.
- Only 2% of readers give so we can bring more of the world’s knowledge to Wikipedia, protect against disinformation, and keep the site running smoothly.
- We’re here to make sure you have access to unbiased, quality information when you need it. We have a long way to go to provide readers with all the world’s knowledge. We’re not there yet.
- We are passionate about our model because at its core, Wikipedia belongs to you. We want everyone to have equal access to knowledge.
- Access to knowledge around the world is under constant attack. As a nonprofit, we work to give access to knowledge to everyone, for free, forever. We still have work to do.
- Wikipedia is different. No advertising, no subscription fees, no paywalls. Those don’t belong here. Wikipedia is a place to learn, free from bias or agenda.
- No one person controls Wikipedia. We’re not influenced by advertisers or corporate interests. It belongs to you, the readers and editors. Wikipedia rests in your hands and we wouldn’t have it any other way.
- Wikipedia is a place to learn, free of corporate or political interests
- One donation may seem small, but when millions of readers each give, we can do great things.
Changes already made in response to feedback in the past year (2022 fundraising banners)
In the past year, the fundraising team has made the following changes to campaigns in direct response to volunteer feedback. We are grateful for the input and partnership with volunteers in improving campaigns for readers.
- The banner message no longer includes the number of reminder banner messages shown to readers. For example, "For the 2nd/3rd/4th time recently, we interrupt your reading to humbly ask you to defend Wikipedia’s independence." The message only references the first time we ask for a donation.
- The message more prominently highlights Wikipedia as a place of learning and knowledge.
- The line “98% of our readers don't give; they simply look the other way” has been removed
- The word “reliable” has been removed from the message.
- The mobile message more prominently highlights our vision: “We are passionate about our model because at its core, Wikipedia belongs to you. We want to make sure everyone on the planet has equal access to knowledge.”
- “Wikipedia is a place to learn, not a place for advertising.” has been changed to “We don't run ads, and we never have.”
- More information about what donations support has been added to the small reminder banners on mobile:
- “Here’s what your donation enables:
- Improvements on Wikipedia and our other online free knowledge projects
- Support for the volunteers who share their knowledge with you everyday
- Resources to help the Wikimedia Foundation advance the cause of free knowledge in the world.”
- “Here’s what your donation enables:
- An ‘I already donated’ feature has been added in all our fundraising banners and the thank you confirmation page to help donors dismiss banners across all their devices.
- The Foundation discontinued the direct acceptance of cryptocurrency as a means of donating. We began our direct acceptance of cryptocurrency in 2014 based on requests from our volunteers and donor communities. We made the decision to discontinue this practice based on feedback from those same communities.
In the creative process, the team uses feedback from readers, donors, and volunteers to generate new messages that will resonate with our audiences. We are always looking for new language suggestions to reach our readers to help them learn more about Wikipedia while we ask for their support. For example, the Dutch community recently wrote a fully original banner that the team tested during the Dutch campaign in September. We ran the banners for 4 days towards the end of the campaign, and the overall result of the new banner was a 65% decrease in donations. While this exact message won't reach the revenue target for the year, there are interesting concepts to further develop. We followed up on this test with a productive conversation with the community after the campaign, and we are planning to work together on incorporating more of the ideas from that session into future banners for the Netherlands.
Providing feedback (2022 fundraising banners)
As the team is actively preparing the upcoming End of Year campaign and developing new messaging, we would greatly appreciate constructive feedback and ideas for ways we can reach our donors while raising the revenue target this year. If you have messaging ideas you would like to see tested, please share them with Julia or leave a message here or on our meta talk page. We will be here, reading and listening to the discussion. The work of the global community of editors makes Wikipedia a useful resource for readers. We thank you for your work and welcome your input on the fundraising campaign.
Thank you.
Posting on behalf of JBrungs, RAdimer-WMF (talk) 23:09, 14 November 2022 (UTC)
@JBrungs (WMF) and RAdimer-WMF: so, with all that extra money coming in, why were the WMF planning on reducing the Community Wishlist Survey from once every year to once every two years, instead of increasing the size of the team working on these long-neglected wishes? Why should we take any statement above (or in the banners) about supporting Wikipedia and its volunteers serious when in reality community wishes are neglected and underfunded, volunteer created improvements and patches are being stalled, and critical voices at technical places (like Phabricator) are being brutally silenced? Fram (talk) 09:19, 17 November 2022 (UTC)
- Hi Fram, I can answer one of your questions about the Wishlist Survey. The idea of changing the cadence of the Survey came from requests that the team has received over the years from volunteers, who ask why they need to take the time to re-propose and re-vote on wishes that they already voted for in the previous year. The question has usually been framed as, "Why do we need to vote again? Just keep working on the wishes from the last survey." So the team's suggestion was to run the survey as usual in Jan 2023, and then use those results to plan the team's work for 2023 and 2024.
- That being said: I've seen here and in other discussions that people are interpreting the bi-annual idea as reducing the team's commitment and connection to the community, which was never intended. We're hearing from you that Community Tech is important, and that people value the annual cadence of the Wishlist Survey as a connection point between WMF's Product department and the active contributors who take part in the survey. We're going to talk and think some more about the annual/bi-annual question before we make a final decision about that. Either way, the team is gratified to know that people appreciate our work, and our commitment to working on projects that are important to the community is unchanged. Let me know if you have any questions. — DannyH (WMF) (talk) 23:39, 17 November 2022 (UTC)
- @Fram and DannyH (WMF): I'm not sure I see many comments that people appreciate your work. Perhaps they are the people whose prayers were answered at the Wish list - I must say, your effeorts for NPP wee very much appreciated a couple of years ago.
- What gives me pause however, Danny, is that you sat in on the conference two weeks ago and although Selena told me she would be looking into the possibility of increasing the engineer workforce (and I have a privae email from her yesterday to this effect), you are now reducing your capacity, and after telling NPP that they should queue at the Wishlist again although in the same message you said the department lacks funds. Was my attending that meeting in the middle of the night for free another waste of my time? This is a real enigma considering this thread is all about the glut of cash in the WMF coffers, and that the community no longer knows who to believe. Kudpung กุดผึ้ง (talk) 09:06, 18 November 2022 (UTC)
Information (2022 fundraising banners)
Between 29 November and 31 December the WMF will be running their English fundraising banners campaign (Australia, Canada, Ireland, New Zealand, UK, and US). Every year this results in a number of discussions objecting to certain aspects of the campaign but these discussions start too late to address any issues. This RfC, running before the campaign starts, is intended to prevent that from happening again.
The RfC started on 14 November when the WMF provides the banners they are planning and will run until 24 November (chosen so that if changes are required the WMF has time to implement them). On 24 November, the discussion will be hatted pending closure; closers are being pre-identified in order to facilitate a quick close.
Originally, the WMF were going to provide a complete listing of the banners they were going to run. This changed, and they only provided a sample on WPM.
In order to ensure that enough comment has been received that consensus is reached despite the shortened RfC period it has been listed prior to opening; editors who wished to be notified when it was opened put their name to the "Editors to notify" list, which was also pre-populated with editors who have participated in similar discussions
If there is a consensus that the banners are not appropriate to run but the WMF tries to run them without implementing the required changes then our proposed method to enforce the consensus is for Common.css to be modified to prevent them from appearing.
Editors to notify
|
---|
This list consists of editors who have added their name, or have participated in related discussions (Review of English Wikimedia fundraising emails, Wikimedia Foundation English fundraising campaign - October pre-tests, and Wikipedia Signpost/2022-06-26/Special report). Please raise any issues with the list on the talk page.
|
Recent banners (2022 fundraising banners)
Some of the banners tested between September and November are available below; they may be indicative of the final banners.
Banners
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
The following banners ran between 2022-11-18 21:00 (UTC) and 2022-11-21 21:00 (UTC) on enwiki for readers from Australia, Canada, Britain, Ireland, New Zealand and the United States. 10% of pageviews for logged-out readers included a banner, up to ten times per reader.
The following banners ran between 2022-11-07 21:00 (UTC) and 2022-11-14 21:00 (UTC) on enwiki for readers from Australia, Canada, Britain, Ireland, New Zealand and the United States. 10% of pageviews for logged-out readers included a banner, up to ten times per reader.
The following banners ran between 2022-10-26 21:00 (UTC) and 2022-10-27 00:00 (UTC) on enwiki for readers from Australia, Canada, Britain, Ireland, New Zealand and the United States. 100% of pageviews for logged-out readers included a banner, up to ten times per reader.
The following banners ran between 2022-10-11 21:00 (UTC) and 2022-10-12 00:00 (UTC) on enwiki for readers from Australia, Canada, Britain, Ireland, New Zealand and the United States. 100% of pageviews for logged-out readers included a banner, up to ten times per reader.
The following banners ran between 2022-10-03 20:00 (UTC) and 2022-10-10 20:00 (UTC) on enwiki for readers from Australia, Canada, Britain, Ireland, New Zealand and the United States. 7% of pageviews for logged-out readers included a banner, up to ten times per reader.
The following banners ran between 2022-09-23 20:00 (UTC) and 2022-09-25 20:00 (UTC) on enwiki for readers from Australia, Canada, Britain, Ireland, New Zealand and the United States. 10% of pageviews for logged-out readers included a banner, up to ten times per reader.
|
RfC: Showing a gadget menu to logged-out users
![]() |
|
![](http://upload.wikimedia.org/wikipedia/en/thumb/8/81/AnonLoader_animation.gif/110px-AnonLoader_animation.gif)
Should a JavaScript gadget be installed as a default gadget to show a gadget menu to logged-out users? The menu will initially be used to offer the Dark mode gadget, but future proposals can add/remove other gadgets/scripts to the menu. — Alexis Jazz (talk or ping me) 14:14, 26 October 2022 (UTC)
Background (showing a gadget menu to logged-out users)
Visitors without an account have no access to Special:Preferences. They can only load gadgets or scripts by appending &withgadget= or &withJS= to a URL, but this has to be done every time a page is visited which is not practical for everyday use.
Wikipedia relies on gadgets and scripts for all kinds of functionality. Dark mode is a notable one, but the WMF also suggested developing gadgets to alter/customize the behavior of the new Vector-2022 skin. Scripts/gadgets to show signatures in the local timezone of the user, add links to comments, disable access keys or add outline-style numbering to headers are examples of other gadgets/scripts that can be beneficial to visitors without an account. A gadget could also be developed to allow users without an account to manage gadgets/scripts more extensively. Such a gadget could be loaded through the proposed gadget menu.
Users who are logged out currently have no convenient way to load any of those. Before this gadget would be deployed the WMF developer team will be asked to review it and issues that should be resolved before deployment will be resolved.
The gadget menu script is lightweight: it adds ~3K to MediaWikiModuleStore. The script has no effect for users who are logged in. The script can be tested by visiting Betacommons (desktop) or Betacommons (mobile) while logged out.
Update 15:31, 27 October 2022 (UTC): in response to some of the votes it has been made possible to show the gadget without a menu, simply listing all entries instead. This means the script could be used purely for dark mode, adding a "Enable dark mode" link to the sidebar and nothing more. You can preview this menu-less mode of the gadget by visiting [4]. Note that while the testing environment currently lists four gadgets, this proposal is only for the gadget loader+dark mode. This added functionality made the script slightly bigger, but a little over 4K is still tiny. (for comparison: WP:Twinkle is ~550K)
Survey (showing a gadget menu to logged-out users)
- Support as proposer. — Alexis Jazz (talk or ping me) 14:14, 26 October 2022 (UTC)
- Support: Long overdue. There are only a few popular websites that don't allow features like dark mode to visitors in the year 2022. It is time that we follow suit by letting IPs use gadgets. What other gadgets should be added into this in future? An advertised RFC should determine. —CX Zoom[he/him] (let's talk • {C•X}) 19:22, 26 October 2022 (UTC)
- Support - this is poggers. jp×g 19:35, 26 October 2022 (UTC)
- Support. —Yahya (talk • contribs.) 20:14, 26 October 2022 (UTC)
Support, a great way to allow casual readers to use dark mode. — Qwerfjkltalk 20:19, 26 October 2022 (UTC)
- Support because it gives the user more freedom. --small jars
tc
20:53, 26 October 2022 (UTC) - Strong support - Making UI customisation easily accessible to readers without accounts is a no-brainer. Daß Wölf 21:07, 26 October 2022 (UTC)
- Oppose. I have concerns about this on a number of levels. As a baseline framework, we're talking here about logged-out users, so it's important to put ourselves in their position. All of us, by virtue of being in this discussion, are power users, and that means the way we interact with Wikipedia is far different than that of typical users. We care about customizability; normal users do not. We care about advanced editing tools; normal users do not. Etc. When we're talking about the left sidebar, we're talking about extremely valuable space that should be reserved only for our most important links. Our audience is >99% people who have never edited Wikipedia before beyond perhaps fixing an odd typo. (The far less than 1% of users who are active IP editors are negligible numerically, and are making a highly idiosyncratic choice in full knowledge of the many downsides for both themselves and others they interact with; we need not cater to them.) The best way to engage them is through links to the high-level overview pages like Help:Contents and Help:Introduction that are currently in the sidebar. The proposed gadget menu in the screenshot has a link to "CD", presumably commons:User:Jack who built the house/Convenient Discussions. (The nominator ought to specify these in the proposal so we know what we've !voting on.) That may be a useful tool for us advanced editors who spend tons of time on talk pages. It's absolutely not the best entry point for someone who's brand new to editing, especially now that most of the important functionality for newcomers is handled by the talk page improvements. Ditto for User:Alexis Jazz/Factotum. Likewise for skin changes, the quintessential example of something no one other than veteran Wikipedians cares about (and which is already easily accessible in your preferences). The dark mode is the most promising option, but if that's all we care about, it should be listed directly, not accompanied by all these other items. And per Writ Keeper below, I'm not convinced it's ready for widescale deployment yet. Our audience can be expected not to know what a gadget is, so grouping things under a gadget menu for them makes no sense. Also, the tools section where the menu currently appears is supposed to be reserved for things that affect the specific page one is on; the correct placement would be above it.I get the sense from the !votes above that editors think we're discussing just giving readers a dark mode. But this proposal goes far beyond that, and it's nowhere near ready for widescale deployment, nor is it the right overall approach. If we want a dark mode gadget for readers, that should be done through making it a default-on gadget that would add an appropriately designed/placed icon, not through introducing an entirely new menu. {{u|Sdkb}} talk 21:16, 26 October 2022 (UTC)
- @Sdkb: The nomination statement clearly talks only about Dark mode
initially
, the screenshot is simply for representation purposes. Again, as I mentioned above, adding/removing scripts should be done on a case-by-case basis via RFCs. —CX Zoom[he/him] (let's talk • {C•X}) 22:16, 26 October 2022 (UTC)- As far as
making it
[dark mode]a default-on gadget
is concerned, I'm afraid it is technologically not possible yet to install it on its own. See Wikipedia:Village pump (proposals)/Archive 191#Proposal: Dark Mode Button. AlexisJazz's AnonLoader tool appears to have achieved this without having to install a extension to individual wikis's configurations. —CX Zoom[he/him] (let's talk • {C•X}) 22:23, 26 October 2022 (UTC)- I would want to know what sorts of other gadgets we'd envision as eventually part of the menu before supporting this, since a one-item menu looks terrible. And per above, since readers don't know what a gadget is, having this as a menu doesn't make sense in the first place.
- The discussion you link was a non-starter because of the bright flash issue, which (per below) appears to still exist here. My objection is primarily to the menu, and if it were possible to have dark mode as a menu item it would presumably also be possible to have it as a normal button. {{u|Sdkb}} talk 00:50, 27 October 2022 (UTC)
- It can be a normal button as long as it is the only item, and increase to a menu if/when more items are added. —CX Zoom[he/him] (let's talk • {C•X}) 07:40, 27 October 2022 (UTC)
- As far as
- @Sdkb: The nomination statement clearly talks only about Dark mode
OpposeNeutral. Withdrawing since I don't have the MediaWiki background to evaluate this. The desire to bring dark mode to Wikipedia is well-placed, and I love how minimally this proposal is scoped, but I doubt users will reach for a "Gadgets" link or understand what it means. Generously (talk) 22:40, 26 October 2022 (UTC)- I can agree somewhat with this sentiment. Maybe the gadget button is too hidden among other links, at the sidebar. Will look forward to improvements proposed at the discussion section below. —CX Zoom[he/him] (let's talk • {C•X}) 06:48, 27 October 2022 (UTC)
- Generously, an earlier version of AnonLoader was actually different and just listed all gadgets. I've added a mode that basically restores that behavior, you can preview what that looks like by visiting [5]. This can be enabled on a project by putting window.AnonLoaderShowAll=1 in common.js/mobile.js alongside the script list. As long as there are <4 gadgets listed it's likely sensible to just show them all like this.
If we never agree on any other gadget to add, we could just use AnonLoader exclusively for dark mode without anyone ever seeing the word "gadget". As a side note: when a user does create an account, a similar argument could be made for the "gadget" wording: would a user ever reach for that tab in their preferences or know what it means? I guess curiosity and word-of-mouth are the answer to that. — Alexis Jazz (talk or ping me) 15:13, 27 October 2022 (UTC)
- Oppose. We should be encouraging people to make accounts rather than providing additional account-like features to anonymous users. -- RoySmith (talk) 01:03, 27 October 2022 (UTC)
- No one wants to give them access to WP:XFDCloser for example. Dark mode has always been more of a reading-experience-improving tool, than a editing tool. Don't see why casual readers need to create an account to "read" Wikipedia as they feel best, when we allow them to even edit articles. —CX Zoom[he/him] (let's talk • {C•X}) 06:46, 27 October 2022 (UTC)
- Oppose The white flash problem makes dark mode basically useless for non-registered users (and afaik cannot be circumvented), and without a similar killer app, I don't think this is worth deploying to every reader of Wikipedia. A good idea, and one we can and should come back to when we have a viable use case, but this intrinsically flawed dark mode gadget ain't it. Writ Keeper ⚇♔ 07:19, 27 October 2022 (UTC)
- Writ Keeper, I don't think the white flashes make dark mode "basically useless", but I'd have to agree it's suboptimal.
I made some changes to the gadget for this. You can experience a white flash for the first page you visit in a session and when performing some specific actions, but while browsing from article to article you should not experience them anymore. — Alexis Jazz (talk or ping me) 15:00, 27 October 2022 (UTC)- What actions in particular? It definitely looks better, but if someone is using dark mode in a low-light setting, for example, flashing bright white frequently might actually be worse than just white all the time, since one's eyes can't adjust to it. Writ Keeper ⚇♔ 15:35, 27 October 2022 (UTC)
- Writ Keeper, when navigating somewhere using a form, but never mind because that should work now too. Special:Search would probably be the most common example. — Alexis Jazz (talk or ping me) 17:06, 27 October 2022 (UTC)
- It seems you've figured out how to persist the url param across link clicks and form submits. But there are still ways the flash can occur: when search directly takes you to an article rather than the search page; when a page loads after being edited, etc. I have a personal script which does something similar to force use of timeless on mobile – I consider it so hacky that I don't even advertiser it as a user script, let alone propose as a gadget. – SD0001 (talk) 19:29, 27 October 2022 (UTC)
- Writ Keeper, when navigating somewhere using a form, but never mind because that should work now too. Special:Search would probably be the most common example. — Alexis Jazz (talk or ping me) 17:06, 27 October 2022 (UTC)
- What actions in particular? It definitely looks better, but if someone is using dark mode in a low-light setting, for example, flashing bright white frequently might actually be worse than just white all the time, since one's eyes can't adjust to it. Writ Keeper ⚇♔ 15:35, 27 October 2022 (UTC)
- Writ Keeper, I don't think the white flashes make dark mode "basically useless", but I'd have to agree it's suboptimal.
- Oppose. If you want to provide the dark mode to logged-out users, then write a gadget (or a patch to the toggle gadget) that allows logged-out users to use the dark mode and make it enabled by default. A gadget that allows toggling all or even a subset of the gadgets doesn't make sense, as that's the point of having an account, i.e. to have a customized site experience. Nardog (talk) 07:59, 27 October 2022 (UTC)
- Oppose mostly against the !voters that are supporting because of "dark mode" only - that should be sovled via phab:T26070, and get away having to push even more layers of locally maintained javascript hacks out. — xaosflux Talk 23:27, 27 October 2022 (UTC)
- Oppose per above. A hacky, single item menu for enabling dark mode (accompanied by a white flash on every page load) doesn't sound like good UI/UX. Agree with Xaosflux that this should be done via phab:T26070 -FASTILY 23:55, 27 October 2022 (UTC)
- Oppose Size and branding-wise, the public regards Wikipedia as probably on the same level as Facebook or Google. So if we're implementing a feature for our readers, it just can't be clunky, like at all. The AfC script? Whatever. Dark mode? Absolutely not. —VersaceSpace 🌃 01:35, 28 October 2022 (UTC)
- Support. I think IPs should have more power over their experience. Of course, some technical gadgets (ie. XFDC, which only works for XCONs anyways) should be left to registered users, and the dark mode flash isn't ideal, but some gadgets would be useful for IPs. Clyde!Franklin! 14:20, 28 October 2022 (UTC)
- Oppose: This is a toggle that enables/disables another gadget which implements dark mode through filters (MediaWiki:Gadget-dark-mode.css). Not a good idea to put this out in production. RAN1 (talk) 15:54, 28 October 2022 (UTC)
- Oppose: This is not urgent in anyway. Can wait for proper implementation in MediaWiki. – Ammarpad (talk) 12:32, 29 October 2022 (UTC)
- Oppose: While I generally support the concept of allowing non-logged in users the ability to change their interface, this seems like a very hacky and editor-centric (as opposed to reader-centric) solution. Regards, Sohom Datta (talk) 15:43, 30 October 2022 (UTC)
- In particular, I find the placement of the menu very weird. The sidebar is generally meant to host links that are more focused towards the content side of the project. If implemented, I think a better option might be to use a dropdown/link from
p-personal
. Regards, Sohom Datta (talk) 15:50, 30 October 2022 (UTC)
- In particular, I find the placement of the menu very weird. The sidebar is generally meant to host links that are more focused towards the content side of the project. If implemented, I think a better option might be to use a dropdown/link from
- Oppose, anybody who knows enough to want to use gadgets knows enough to make an account to save their settings (and giving IPs access to gadgets but only a limited selection seems like a strange choice). The Correct Way to implement dark mode on a website is the CSS prefers-color-scheme media query, which is exactly what's being done in phab:T26070. XenonNSMB (talk, contribs) 17:15, 31 October 2022 (UTC)
- I understand the idea and I find proposals to improve the experience of any Wikipedia user commendable. I don't agree that having a menu for custom user-written JavaScript "gadgets" is a viable solution, though. If the interface lacks important features or even has bugs that affect every reader, the solution to implement these features or to fix these bugs is to improve MediaWiki, not to throw community-"maintained" JavaScript at the situation. ~ ToBeFree (talk) 23:46, 10 November 2022 (UTC)
- Comment I like some of the ideas here, and dark mode is overdue, but the implementation could use some finessing. Ideally the WMF would've allocated the resources for additional features like dark mode ages ago, and given the glacial pace on their end I can understand the desire to do this on our own. Still this proposed solution is rather hacky. 74.73.224.126 (talk) 00:30, 11 November 2022 (UTC)
- Oppose, they can create an account if they want to, it takes 30 seconds. Stifle (talk) 14:34, 15 November 2022 (UTC)
- Oppose as someone who explored creating a dark mode toggle, with the way gadgets currently work, this should not be done for logged-out users. Seddon talk 15:02, 15 November 2022 (UTC)
- Opposed to this, basically per the above: hacky and just generally not a good road to start going down. I also think "logged-out users" is the wrong way to frame this, when what that really means is readers. We get, what, around 9 or 10 billion page views a month? It's a massive surface area given readership, and they are owed a certain standard. ~ Amory (u • t • c) 18:45, 15 November 2022 (UTC)
- Oppose introduction of Dark Mode gadgetry per User:Sdkb. Also, nobody here seems to notice that MediaWiki is an open source project. Everyone is allowed to contribute code to it and so mediawikiwiki:Extension:DarkMode already exists (courtesy of User:MusikAnimal who may wish to comment here). Go work on that and get it to a point where it's of an acceptable quality for the English Wikipedia. Don't code hacky JS stuff specific to enwiki. Chess (talk) (please use
{{reply to|Chess}}
on reply) 15:45, 16 November 2022 (UTC) - (Already !voted above) I'd just like to note I stick by my Support !vote above: Extension:DarkMode won't be enabled for logged-out readers per MusikAnimal
the native solution (by adding CSS on page load) via mw:Extension:DarkMode won't be offered to logged out users on the WMF cluster because it would mean we have to bypass the Varnish cache on every page load, which is an absolute no-no
. This seems to be the only reasonable way to offer Dark Mode to people without an account. — Qwerfjkltalk 15:23, 18 November 2022 (UTC)
Discussion (showing a gadget menu to logged-out users)
This is a cool thing in general, but specifically in the case of dark mode, I'm not sure it works very well, since (at least on my browser) the page will load and display in the regular white screen for a half-second or so while the Javascript executes, then flashes back to dark mode. I don't think that's practical.
(Also, not sure if it matters, but is there a particular reason it's using a global variable for storage, rather than localStorage.getItem("X","Y");
, etc.?) Writ Keeper ⚇♔ 20:18, 26 October 2022 (UTC)
- Half a second is not bad at all. In my case the first time takes about 30-35 seconds to turn on and 5-7 seconds to turn off, and in the meantime the toggle is unresponsive (TBF I'm not sure how much of that is due to new Vector which is somewhat slower on my PC). This should be rewritten in a less resource intensive way so that it works swiftly on the average computer. I think it can be done with CSS and cookies, which would also be backward compatible with nearly all browsers recent enough to be able to connect to Wikipedia. Daß Wölf 21:07, 26 October 2022 (UTC)
- Daß Wölf, on a 10-year old system it takes more or less just as long to reload a page as it does to enable/disable a gadget. (which is expected as enabling/disabling a gadget also reloads the page) On a 9-year old smartphone my experience is the same, enabling dark mode takes roughly 2 seconds which is roughly how long it takes to reload a page.
Edit: while browsing you won't see a white flash anymore, pretty much only when starting a session now as far as I can tell. — Alexis Jazz (talk or ping me) 23:00, 26 October 2022 (UTC) - @Daß Wölf: The reason it's lagging so hard is because it's applying an invert and hue-rotate filter to the page. RAN1 (talk) 15:54, 28 October 2022 (UTC)
- Daß Wölf, on a 10-year old system it takes more or less just as long to reload a page as it does to enable/disable a gadget. (which is expected as enabling/disabling a gadget also reloads the page) On a 9-year old smartphone my experience is the same, enabling dark mode takes roughly 2 seconds which is roughly how long it takes to reload a page.
I've withdrawn my !vote, but I'll add here that while logged-in users are used to large JS payloads, the logged-out experience has been made pretty slim through some WMF effort. In that context, 3KB is sizeable. Generously (talk) 20:49, 27 October 2022 (UTC)
- Generously, that article speaks of bandwidth savings and "after compression". The script has currently grown to 6K after fixing the white flash issue for searches (could possibly be optimized a bit) but this is 2.6K compressed which could be slightly less when delivery is combined with other scripts by ResourceLoader. In practice however, this would be cached in MediaWikiModuleStore (localStorage) and once it's there it won't be downloaded again.
@SD0001, I've worked on the white flash search issue. Some edge cases remain. For editing, it should be noted that the vast majority of anons never edit. There's no issue with VisualEditor or DiscussionTools. Due to the way the 2010 Wikitext editor works I don't think there's any clean way to make that work. I suspect the most viable option would be to figure out how to enable the 2017 wikitext editor in this case. Not sure how hard that'll be. As for your script, I guess my SkinEnforcer does something similar. It's quite a bit more complicated. I see some obvious issues with your script and SkinEnforcer has some different issues which also make it far from perfect, so I wouldn't propose either of those indeed. Not in their current state anyway.
@RoySmith @Nardog, that's generally how things are, but it doesn't have to be. We could offer more customization to visitors without an account. The way I see it, you create an account to get attributed for your contributions, to stop spilling your IP with every edit, to get rid of the CAPTCHA, to engage in talk page discussions more easily and to vote on things. Why should we require an account to enable dark mode, auto-number headings or perhaps some accessibility options?
@Xaosflux @Fastily, well, phab:T26070 is a ticket from 2010. 12 years old. This is kinda how it works: the community wishlist barely works, but if we vote for a gadget suddenly the WMF realizes "this is important!" and develops a native implementation. The white flash issue (which I didn't personally perceive as a big deal when I created the RfC, but I see others care much more strongly about it) has already been much reduced if not eliminated from your average anon browsing session. (apart from the start of the session) And the gadget menu can work without the menu part now, showing only the "Enable dark mode" link.
@VersaceSpace, I essentially agree, but does this mean you'd change your vote if the issues are resolved? — Alexis Jazz (talk or ping me) 14:34, 28 October 2022 (UTC)
Is there a reason for this to be a toggle in production? The stylesheet can't automatically disable itself when the toggle is. I ended up learning the hard way that these are separate gadgets when I disabled the toggle. RAN1 (talk) 15:11, 28 October 2022 (UTC)
- RAN1, dark mode consists of multiple parts. MediaWiki:Gadget-dark-mode-toggle.js ("dark-mode-toggle") provides the toggle which loads the actual dark mode from the hidden gadget "dark-mode" at MediaWiki:Gadget-dark-mode.css. In the way it's currently set up on betacommons the proposed script, AnonLoader, skips dark-mode-toggle and applies dark-mode directly. The dark-mode-toggle normally changes a user preference to enable dark-mode.css. This is not possible for anons. To prevent white flashes, the hidden "dark-mode" gadget must be loaded along with the page request. This is done through a user preference for logged-in users. AnonLoader achieves this by adding &withgadget=dark-mode to the URL with persistence.
Due to the way cache stuff is set up, using cookies is AFAIK not possible for this kind of thing. — Alexis Jazz (talk or ping me) 20:17, 28 October 2022 (UTC) - @Ammarpad,
Can wait for proper implementation in MediaWiki.
That may not be realistically possible. As explained by TheDJ in phab:T307851 for a similar question about skins:Cookies (I'm assuming for anon users ?) can be used, but we cannot vary the content based on them. This would cause a caching problem.
So cookies are out, localStorage is out due to the white flash issue and the query param method (which AnonLoader can use for 1 gadget, which it uses for dark-mode on betacommons now) seems unlikely to get implemented natively in MediaWiki. So the real choice it seems is this: either don't offer dark mode to anons at all, or put effort towards making the query param method as good as it can be. — Alexis Jazz (talk or ping me) 13:11, 30 October 2022 (UTC)- Correct, the native solution (by adding CSS on page load) via mw:Extension:DarkMode won't be offered to logged out users on the WMF cluster because it would mean we have to bypass the Varnish cache on every page load, which is an absolute no-no. I have heard through the grapevine that leadership is reconsidering this extension for logged in users, however. The extension does have a query param that could be offered to logged out users, but since the CSS has to be applied after page load, they may experience FOUCs. — MusikAnimal talk 17:37, 16 November 2022 (UTC)
- @MusikAnimal: The extension is a reproduction of the gadget. Can we get proper support out of this line of development? RAN1 (talk) 00:58, 17 November 2022 (UTC)
- Other way around actually: the extension came first and for Earth Day 2021 we (myself, SD0001, Nardog, Xaoslfux and others) ported it to a gadget here. We then advertised it in meta:Tech/News in an effort to have the gadget adopted on other wikis. It looks like it's now spread to seven other wikis, while more wikis may have their own fork or variant. This was to influence WMF leadership that communities are accepting of the "invert" solution provided by this implementation of DarkMode. As I hinted at above, there's a chance they're reconsidering it now. Not sure if that answers your question. — MusikAnimal talk 01:10, 17 November 2022 (UTC)
- My bad, I saw there wasn't a pref toggle and assumed that was a remnant. I noticed the render delays with the filter on, so I don't think this can run sitewide, even if it was limited to just a CSS media query to make it cacheable. RAN1 (talk) 04:33, 17 November 2022 (UTC)
- Other way around actually: the extension came first and for Earth Day 2021 we (myself, SD0001, Nardog, Xaoslfux and others) ported it to a gadget here. We then advertised it in meta:Tech/News in an effort to have the gadget adopted on other wikis. It looks like it's now spread to seven other wikis, while more wikis may have their own fork or variant. This was to influence WMF leadership that communities are accepting of the "invert" solution provided by this implementation of DarkMode. As I hinted at above, there's a chance they're reconsidering it now. Not sure if that answers your question. — MusikAnimal talk 01:10, 17 November 2022 (UTC)
- @MusikAnimal: The extension is a reproduction of the gadget. Can we get proper support out of this line of development? RAN1 (talk) 00:58, 17 November 2022 (UTC)
- Correct, the native solution (by adding CSS on page load) via mw:Extension:DarkMode won't be offered to logged out users on the WMF cluster because it would mean we have to bypass the Varnish cache on every page load, which is an absolute no-no. I have heard through the grapevine that leadership is reconsidering this extension for logged in users, however. The extension does have a query param that could be offered to logged out users, but since the CSS has to be applied after page load, they may experience FOUCs. — MusikAnimal talk 17:37, 16 November 2022 (UTC)
- Consider consulting with WMF devs about how this would affect caching. There may be big caching implications to making the website more interactive/less static for logged out users. –Novem Linguae (talk) 11:43, 19 November 2022 (UTC)
Proposal to make WP:LONGDAB a guideline
Please see: Wikipedia talk:Organizing disambiguation pages by subject area#RfC: make this page a guideline
This is a proposal to elevate an essay to guideline status; there's also a more specific suggestion to merge it into MOS:DAB. — SMcCandlish ☏ ¢ 😼 20:55, 10 November 2022 (UTC)
Enable features by default
There are three features which it might be best to enable by default for new users. First, automatically adding any page that you edit to your watchlist. That didn't happen for me until I changed my settings. Secondly, an edit button specifically for the introduction of an article. Third, having the diff display, with additions highlighted and deletions crossed out, whenever you run your cursor over a link to a diff. Is there any downside to enabling these features by default? DefThree (talk) 20:03, 11 November 2022 (UTC)
- @Hi DefThree; regarding #1, that ended up getting turned off on purpose as it was causing some issues with extremely large watch lists. The second is available in gadgets under
Add an [edit] link for the lead section of a page
. We don't like to push too many "gadgets" to default, but there is an outstanding software request for this (phab:T2156) that you can follow up on. The "navigation popups" gadget does provide what you are asking for third already as well (same that it is not default, as another navigation popup is already). The default popup tool is called "Popups" (a/k/a "Page Previews" and you can request features be added to that using this form. — xaosflux Talk 00:24, 12 November 2022 (UTC) - Automatically added pages to watchlist isn't an appropriate default. It's a disaster if you edit large numbers of pages, and most people don't want to watch every page where they make a passing or minor edit. Alsee (talk) 08:23, 18 November 2022 (UTC)
Do not mark popular vote winners or list popular vote changes in staggered term legislative elections for chambers where not all geographies get to vote at once
I have had an issue with these listings, most notably when it comes to US Senate elections (where while there are 50 states, only 33 or 34 are up regularly at each cycle). This also applies to elections for a number of US State Legislatives chambers, and possibly some other chambers at the international level. I went over the issue in detail here, but not once has anyone replied to me, and I feel like the issue needs to be discussed thoroughly. The crux of the issue is that you are essentially comparing apples to oranges when you compare such nationally aggregated vote totals. The core of the case is that the classes of 33 or 34 US Senate seats regularly up each cycle are not at all equal in partisanship, so in many cases, the party that nominally recieved more votes nationally, or the vote percentage swing from one cycle to the next can very well be an artifact of which geographies are up. In the context of the US Senate, based on modern US political party coalitions this means that class 1 and class 3 elections are both going to produce national vote totals that are more Democratic than they should be if you simply add up each parties votes across each race in the seats that were up without making any adjustment, while class 2 elections are going to have the opposite issue of being more Republican. Regarding the 2020 US Senate elections page, some editors want to highlight vote data showing Republicans winning more votes than Democrats nationally, and to include a swing metric showing a shift of over 20 points in voter preference from the 2018 elections (part of which is an artifact of the issue I described, another part an artifact of uncontested races, most notably with regard to the lack of a Republican on the 2018 general election ballot in California due to the top 2 blanket primary system, with only between 6 and 7 points of it being a real result of voter preferences changing). I can tolerate it if people wish to not use estimates for elections that never happened in the way I did to arrive at my numbers when totalling data on wikipedia, but if we avoid doing that, we still need to be honest about the fact that the nominal totals have flaws as I have described. MappedTables (talk) 05:26, 14 November 2022 (UTC)
- I agree with you that this comparison is not encyclopedic for US Senate seats where there is a more or less random sorting into three groups and it should be obvious that random sorting of 100 seats into three groups results in groups that have different characteristics. If it was 1000 seats, it probably would not be much of a problem. This is reflected in reality. I have been closely following US elections since 1972, and every cycle, I hear analysts saying long before the election, "The Senate prospects for Party A are better this year than for Party B". On the other hand, similar comparisons for the US House of Representatives are valid, since every seat is won or lost in every election cycle. If reliable sources report that Party A won 55% of the seats but only won 45% of the cumulative popular vote, then that is encyclopedic content that sheds light on gerrymandering and democracy. Cullen328 (talk) 06:03, 14 November 2022 (UTC)
- I've noticed this as well, and I think you're correct. It's misleading to add up the popular votes of each election in cases like this. Thebiguglyalien (talk) 13:17, 14 November 2022 (UTC)
- We are supposed to summarize what the preponderance of reliable sources say. If a preponderance of reliable sources make such comparisons, we include them, but should neither overemphasize nor underemphasize such analysis. - Donald Albury 16:02, 14 November 2022 (UTC)
- I side against this recommendation overall.
- In the case of U.S. Senate elections, I disagree completely. This could actually mislead in another way. Since states are awarded senators without any proportion to population, without the context of popular vote, a seat swing could be wrongly thought to represent that the vast majority that voted for Senate in a cycle "must have heavily supported that party". Think that the vote count is representative of the cumulative will of the states that participated. There are cases where that would be GROSSLY WRONG: for instance, the 2018 U.S. Senate election.
- I'll concede, removing that info from infoboxes is not without complete merit. It could mislead those not understanding context in one way. But, in the case of U.S. Senate, removing it misleads in another way. Also, some of other things that will likely be the norm in election articles do mislead without understood context. For instance: result maps. We will probably always be adhering to the popular practice of use maps representative of geography rather than either maps giving equal size to all constituencies or maps representing constituencies in sizes that are proportional to their population.
- Perhaps remove it from infoboxes of elections such as Illinois' state senate in years they stagger the seats. But even then, not critically necessary.
- If we do remove this info from inboxes, it should still be included somewhere in articles. This is factual information useful to some that some people will be looking for. We shouldn't make it impossible to find it on this project. SecretName101 (talk) 21:06, 15 November 2022 (UTC)
- It seems like you are misunderstanding what I am saying with regard to popular vote totals. I am only asking for the swings to be outright removed. With regard to the popular vote totals, I am calling for winners to not be marked in bold text like this, not for those to be removed as well. MappedTables (talk) 00:45, 16 November 2022 (UTC)
- Okay, I better understand now SecretName101 (talk) 15:36, 16 November 2022 (UTC)
- As the classes are stable, shouldn't the 6 year cycles be compared? It's won't be apples to apples as the Presidential will only be in every other iteration, but more accurate than comparing 2 year cycles. Slywriter (talk) 00:50, 16 November 2022 (UTC)
- Comparing the 2022 Senate votes to those of 2018 is also very inaccurate. Did the Corona crisis affect the vote patterns? Possibly, but no way to know for certain. Nor can we know if the assault on the Capitol in 2021, purportedly triggered by Trump; Biden's policies as president; or the Russian attack on Ukraine - if any of these may have had major changes on voter opinions. Animal lover |666| 12:17, 16 November 2022 (UTC)
- I think you mean 2016 to 2018. That'd be a six-year difference.
- "These things may have motivated a change in turnout between these cycles" does not make sense to me as a reason to avoid indicating changes. SecretName101 (talk) 15:38, 16 November 2022 (UTC)
- I see nothing persuasive about picking two arbitrary events to say 2 year periods make sense. National turnout is influenced by serveral independent statutory factors (and other less definable ones that are beyond scope): 6 year Senate terms, 4 year Presidential terms, vacant Senate seats, Governor's election and incumbency of the Presidency. Class I will be in 2024 with a Presidential, 2030 without a Presidential. They may or may not also have Governor's race in their state during one of those.
- Tl;Dr Given numerous variables and arbitrary ways to compare by Class at least comes closer to apples to apples. Slywriter (talk) 16:00, 16 November 2022 (UTC)
- Comparing the 2022 Senate votes to those of 2018 is also very inaccurate. Did the Corona crisis affect the vote patterns? Possibly, but no way to know for certain. Nor can we know if the assault on the Capitol in 2021, purportedly triggered by Trump; Biden's policies as president; or the Russian attack on Ukraine - if any of these may have had major changes on voter opinions. Animal lover |666| 12:17, 16 November 2022 (UTC)
- There is a similar issue with UK by-elections ("special elections" as you'd call them) where comparisons can't be made like-for-like. The only statistically correct comparison is from one general election to the next The only way to compare accurately is from the election where Group X were last elected, term-for-term, like-for-like. doktorb wordsdeeds 12:21, 16 November 2022 (UTC)
- Any actual change is statistically correct. It will not illustrate the full picture of underlying reasons for changes in turnout, but it most certainly cannot be called statistically incorrect. SecretName101 (talk) 16:26, 16 November 2022 (UTC)
- I disagree to a point. Yes, comparing last year with this year provides numbers to crunch and conclusions to be made. But for term-for-term, like-for-like comparison, to indicate exactly how a specific candidate or party has gone on after a full electoral cycle, the comparison has to be from the previous election *of that cycle*. doktorb wordsdeeds 17:26, 16 November 2022 (UTC)
- Any actual change is statistically correct. It will not illustrate the full picture of underlying reasons for changes in turnout, but it most certainly cannot be called statistically incorrect. SecretName101 (talk) 16:26, 16 November 2022 (UTC)
Establishing a guideline outline preferred dimensions (aspect ratio) for images in the inboxes for biographies and elections
Correct me if I am wrong, but there does not appear to be either a guideline or official policy outlining what the preferred dimensions for images in inboxes for biographies and elections.
I believe that there should be an agreed-upon preferred aspect ratio. Particularly to avoid disputes over the dimensions/crops that should be used in infoboxes. I also beleive these dimensions should be 3x4, though I'll delve into my arguments for that later.
The main reason I believe there should an agreed-upon recommended dimension for infobox images of biographies is consistency between articles. It is aesthetically displeasing to avoid vast variance in what dimensions are used in biography infoboxes. It helps create a more standardized identity for this project if there is constistency. Furthermore, it is particularly displeasing in biographies of officeholders for there to be variance in dimensions. When readers are navigating between predecessors and successors using infobox links, it looks best if the images in both articles' inboxes have the same dimensions.
One reason that I believe this should be the case for election articles is also for consistency between difference election articles. A second reason is that I believe that the images of different candidates in election boxes ideally should be of identical aspect ratio. It looks sloppy when they are different dimensions. Guidance in what dimensions to use would be useful in cropping the images of candidates to match each other. Additionally, when navigating using infobox links between preceding/subsequent elections, it looks sloppy when there is a noticeable variance between articles in the aspect ratio of images used for candidates. Again, a more consistent style creates a better identity for our project.
Now on the case for the recommended dimensions to be 3x4:
- These dimensions are aestheticly pleasing in inboxes. I believe it falls perfectly in a Goldilocks zone of not being overly tall nor overly wide.
- This crop maintains a common convention of portraits being greater in height than in width, and does so without making the portrait overly tall.
- These dimensions are easy to remember, and are therefore easy to input into the CropTool. Any crop dimension using decimals instead of whole numbers would be less intuitive/user-friendly when utilizing the "custom" aspect ratio tool in the CropTool for this reason.
- The dimensions have proven to be broadly accepted on this project. They have been applied in a plethora of election articles and biographic articles, which demonstrates a lack of community objection to how this aspect ratio looks. THOUSANDS of biographic and election articles are making use of this aspect ratio for their illustrating images, and have for years. I have never seen images in this aspect ratio removed for objections to the aspect ratio.
I will note, that I myself have made extensive use of this aspect ratio in both biographies and election inboxes, and have seen others do so as well. I am not sure how widely it was already being used by other editors before me as an unofficial style policy, but images of aspect ratios that at least resemble 3x4 were in good use as long as I can remember, particularly in election articles. 3x4 aspect ratio images are now very common for these uses, regardless of when they were popularized. I would like to see this be affirmed as best practice.
Moved from the Policy village pump
SecretName101 (talk) 17:19, 15 November 2022 (UTC)
- If I came across someone cropping previously-chosen images for infoboxes (or anywhere else for that matter) just to suit a 'preferred aspect ratio', I'd report them for vandalism. AndyTheGrump (talk) 01:59, 16 November 2022 (UTC)
- Most infobox images are on low-trafficked pages and not “selected” via any discussed consensus to begin with. If you thought someone did a bad job cropping an image, you could create an alternate crop with the crop tool and insert it yourself.
- on pages where discussion would arise, various crops could be created and a preferred crop could be selected. Often, cropping infobox portraits to 3x4 only eliminates unneeded background space or parts of a lower torso in the least-extreme crops. SecretName101 (talk) 03:20, 16 November 2022 (UTC)
- Also, that seems like a gross misunderstanding of what constitutes Wikipedia:Vandalism. But I'll let that slide from this discussion. SecretName101 (talk) 03:30, 16 November 2022 (UTC)
- This image [6] doesn't conform to your preferred 3*4 aspect ratio. Are you going to take the excess off the top, the bottom, or a bit of both? AndyTheGrump (talk) 03:43, 16 November 2022 (UTC)
- That is a strawman argument. Since I am proposing a guideline that only would apply to infoboxes of articles that are biographies (especially of officeholders) or articles that focus on an election.
- That is an artwork. On a page where the central topic is the piece of artwork itself, any artwork should clearly be presented in its original aspect ratio. SecretName101 (talk) 03:54, 16 November 2022 (UTC)
- Also, I am proposing this be a guideline, not a rule. Thereby allowing for reasonable exception should need arise. SecretName101 (talk) 03:56, 16 November 2022 (UTC)
- Aesthetics applies everywhere. Portrait photography, and the cropping of photographs, is art. At least, it should be. Imposition of arbitrary numeric restraints on aesthetic choice is morally unjustifiable, and Wikipedia should have no part in such facile authoritarianism. Leave that to the book-burners... AndyTheGrump (talk) 04:02, 16 November 2022 (UTC)
- This image [6] doesn't conform to your preferred 3*4 aspect ratio. Are you going to take the excess off the top, the bottom, or a bit of both? AndyTheGrump (talk) 03:43, 16 November 2022 (UTC)
Downhill from here. I think none of what I collapsed is necessary to understand either of the two bickering users’ positions; if you disagree, feel free to revert. TigraanClick here for my talk page ("private" contact) 17:32, 16 November 2022 (UTC)
| ||
---|---|---|
I have collapsed a back and forth with User:AndyTheGrump that was "otherwise distracting material" and have done this for the purposes of "improving the clarity and readability" of this discussion per Wikipedia:Refactoring talk pages. Any other discussion can continue below, but the same discussion should be continued within between the collapsed templates. SecretName101 (talk) 06:24, 16 November 2022 (UTC)
|
- I presume by this point that this whole discussion is a waste of time, but on the off chance that anybody is reading this: prescribing a particular aspect ratio for image cropping seems pointless at best and counterproductive at worst. Whatever aspect ratio is chosen, there will inevitably be cases where slavishly trying to fit that ratio will force us to either leave in elements that would be better cropped out, or crop out elements that would be better left in. The idea that prescribing a particular aspect ratio will prevent disputes is optimistic at best. There will still be plenty of scope for disputing exactly how a particular image should be cropped, and it's not hard to think of situations where a mandated aspect ratio would force editors who would have previously been able to agree on a crop at some other aspect ratio into a dispute. Inconsistency in image aspect ratios simply isn't a major problem, but mandating fixed aspect ratios is likely to create problems. Caeciliusinhorto-public (talk) 16:17, 16 November 2022 (UTC)
- Hi, appreciate your contribution. I will note I am not at all proposing a "mandated" apsect ratio that would "force" anything. Just the creation of a guideline that would be a recommended practice. SecretName101 (talk) 16:20, 16 November 2022 (UTC)
- I requested this be a recommended guideline rather than a rule for the reasons of broadly permitting reasonable exceptions when they arise. SecretName101 (talk) 16:22, 16 November 2022 (UTC)
- @SecretName101, our guidelines are "rules". Sure, we don't usually call them by that word, and we allow some sensible exceptions (we allow sensible exceptions even to most things that we call "policies"), but the fact is that our Wikipedia:Policies and guidelines are actually rules. Furthermore, even if you write down something very weak and mushy, like "As a strictly optional suggestion that any editor is allowed to reject, we suggest...", someone will try to enforce that suggestion inappropriately. WhatamIdoing (talk) 17:10, 17 November 2022 (UTC)
- Oppose What bothers one person as "aesthetically displeasing" is not a sound basis for enshrining something in a guideline. I am not aesthetically displeased in any way by variance in aspect ratios of pictures. --Jayron32 17:36, 16 November 2022 (UTC)
- Comment. I hope you're all aware that, to present a cropped image in an infobox, you don't need to crop the version of the image at Commons, nor to upload a cropped version there. You can just present the image cropped. There's an example of how to do that in an infobox at User:Maproom/cropping. Maproom (talk) 18:27, 16 November 2022 (UTC)
- Oppose per Wikipedia:Avoid instruction creep. The aspect ratio of the image at P. B. Van Trump is just fine. Cullen328 (talk) 19:48, 16 November 2022 (UTC)
- This revealing gallery demonstrates that SecretName101 really ought to abandon this misguided campaign. OMG. Most photographers think that a portrait that skims the top of the subject's head is flawed, and take several photos to later select the best. This editor actively creates such bad images by priotizing an arbitrary aspect ratio over common sense. Cullen328 (talk) 20:06, 16 November 2022 (UTC)
- As I mentioned in an earlier thread, the gallery is deceptively presented. In some cases it uses uncropped full versions of images that were already using cropped versions before they were replaced. It also omits edit descriptions of some changes that would give better context related to the crop, and also does not include the diffs which would provide you the full representation of how they changed infoboxes in appearance. A lot of things they ridicule in each of the crops they cherry-picked were actually present in the crops already being utilized, so are not due to 3x4 cropping. They also blow-up the these images, so that lower-resolution images look blurrier in their gallery than they do in the actual infoboxes (many of these were for elections infoboxes where the size of the images are as small as x150px and the images do not look poor as they do blown up to what seems triple that size).
- This revealing gallery demonstrates that SecretName101 really ought to abandon this misguided campaign. OMG. Most photographers think that a portrait that skims the top of the subject's head is flawed, and take several photos to later select the best. This editor actively creates such bad images by priotizing an arbitrary aspect ratio over common sense. Cullen328 (talk) 20:06, 16 November 2022 (UTC)
- I would recommend you provide a list of difs you take issue with instead of citing a manipulatively-presented gallery. SecretName101 (talk) 20:22, 16 November 2022 (UTC)
- Additionally, your example of P Van Trump's image would also not be affected even if this were a rule (which it's not, it'd be a guideline), since it is located outside of an infobox. SecretName101 (talk) 20:29, 16 November 2022 (UTC)
- The fact of the matter is that every single cropped image on Andy's example page is really bad. If you cannot acknowledge that, then I recommend that you stop cropping images. Cullen328 (talk) 20:40, 16 November 2022 (UTC)
- The Huckabee images, for instance, are no worse than what was already in use. You cannot find a high-def image of Mike contemporary with that era that is free to use. And, oddly, Sarah Huckabee Sanders lacks any shot on Commons that is not a candid. So, sadly we are left with less-than ideal options for both of their elections. "Inflate him instead, into a blur" is an intentionally misleading complaint, since the gallery inflated the image up to a size much greater than in the infobox for the election, and because the crop previously used in that infobox would look equally bad blown up. SecretName101 (talk) 20:46, 16 November 2022 (UTC)
- The fact of the matter is that every single cropped image on Andy's example page is really bad. If you cannot acknowledge that, then I recommend that you stop cropping images. Cullen328 (talk) 20:40, 16 November 2022 (UTC)
- Given that the main justification for your proposal other than your own personal preference is the supposed benefit of consistency, the fact that this guideline would apply to infobox images but not other lead images seems bizarre. If consistency is so important, we should have a guideline that applies across the board – not just to some subset of infobox images. Caeciliusinhorto (talk) 20:38, 16 November 2022 (UTC)
- SNot really. This would be concerned with consistency between the appearance of infoboxes. It's not inconsistent to have images outside of infoboxes unaffected by this. The aspect of images becomes more noticeable when you have a consistent frame (a standard-width infobox) that it is recessed in that provides a visual comparison point with images in other articles. Standalone lead images are no recessed inside a usually standardized-width frame, so are not much a concern. SecretName101 (talk) 20:41, 16 November 2022 (UTC)
- @Caeciliusinhorto: this is a complete misunderstanding of the point of this proposal. Election infoboxes are supposed to have a relatively standardized look across the project, and standardizing the guidelines for creating them is common sense. The point here isn't "all pictures of people should have the same aspect ratio", but that the pictures used in one particular type of infobox should be cropped to that ratio, so all of those infoboxes display in the same manner. Elli (talk | contribs) 10:54, 17 November 2022 (UTC)
- @Elli: that's precisely what I'm confused by. Why do election and biography infoboxes have a unique need for standardisation which doesn't apply to other content? Caeciliusinhorto (talk) 11:11, 17 November 2022 (UTC)
- Because election infoboxes have multiple images (one for each candidate), and having them at different aspect ratios looks weird? And having every election infobox across the site look slightly different because aspect ratios for the images in them are different would be pointless. There is no benefit really to not standardizing the ratios here. Elli (talk | contribs) 11:19, 17 November 2022 (UTC)
- @Elli: that's precisely what I'm confused by. Why do election and biography infoboxes have a unique need for standardisation which doesn't apply to other content? Caeciliusinhorto (talk) 11:11, 17 November 2022 (UTC)
That logic makes no sense: the proposal is for this guideline to apply to both election and biographical infoboxes, but biographical infoboxes don't have multiple lead images, while there are other infobox templates (e.g. {{Infobox sports rivalry}} which are likely to have multiple images but the guideline wouldn't apply to. And even fixing the aspect ratio election infoboxes still won't look the same because the number of candidates in any given election varies: the last five UK Labour Party leadership elections have had five different numbers of candidates. I'm still not convinced that the problem you identify is in fact problematic, but if it is then this proposal doesn't solve it. Caeciliusinhorto-public (talk) 12:48, 17 November 2022 (UTC)
- I oppose this proposal on its merit and the overwhelming likelyhood that its codification would not serve to improve Wikipedia. While the proposal is clearly given in sincerity and good faith, its opposition should not be taken as a personal affront (it is not). It is collegial dissent where the best interests of Wikipedia has moved others to a different conclusion than that which this proposal is premised upon. Best regards. --John Cline (talk) 09:13, 17 November 2022 (UTC)
- I am very disappointed with AndyTheGrump's conduct here, starting with them viewing this as vandalism and then creating a misleading gallery to argue against cropping images in one particular context. This probably should not have been brought to VPP, but it would be a good idea to establish a suggested aspect ratio for images in election infoboxes. Pretty much every crop presented in Andy's gallery is precisely what should be done; for these boxes, we should focus on the head/upper body of the figure and crop extraneous surroundings. And yeah, for some politicians, we don't have a good picture of them in particular, so we need to crop them out of a larger image. That's not ideal, but it's what we have to work with. I don't see the need to codify this as a guideline but the strong opposition this has gotten is discouraging and shows to me that many editors have commented without fully considering the issue that is being discussed here. Elli (talk | contribs) 10:51, 17 November 2022 (UTC)
- Please provide examples from outside Wikipedia where the creators have considered it appropriate to crop a closeup portrait from a larger image to the extent that the top of the head is a few pixels below to top of the crop. You won't find them. Nobody does that for a conventional portrait. It is ugly, and unnecessary. AndyTheGrump (talk) 11:05, 17 November 2022 (UTC)
- Our point in infoboxes is not to have a "conventional portrait", though. It's meant to be more in line with how other sites that report elections show candidate headshots, for example, check out The New York Times. While they have better pictures than we do, they do a similarly close-up crop (except they do a square crop, because they put the headshot in a circle; the idea is the same, though). Elli (talk | contribs) 11:21, 17 November 2022 (UTC)
- Who's 'point' is that? Where was it decided that infoboxes for biographies of politicians were a special case, and that cropping right to the top of their heads was appropriate? [8][9][10] AndyTheGrump (talk) 12:19, 17 November 2022 (UTC)
- I am not really talking about our biographies here. I'm talking about our election articles. Elli (talk | contribs) 13:18, 17 November 2022 (UTC)
- You may not be, but SecretName101 was:
I myself have made extensive use of this aspect ratio in both biographies and election inboxes...
I've shown the results. And if election article portraits need special treatment, it needs to be done properly, by someone who understands how to crop an image just for that purpose. As Maproom points out above, there are ways to do that without having to crop content on Commons at all. Messing up biography infoboxes with ugly crops just to make election articles 'consistent' was totally the wrong approach. AndyTheGrump (talk) 14:25, 17 November 2022 (UTC)- Well sure, and I generally agree with you that biographies don't need crops that are as aggressive. When I crop images, I almost always crop to a new file, which avoids that issue. Elli (talk | contribs) 15:20, 17 November 2022 (UTC)
- You may not be, but SecretName101 was:
- I am not really talking about our biographies here. I'm talking about our election articles. Elli (talk | contribs) 13:18, 17 November 2022 (UTC)
- Who's 'point' is that? Where was it decided that infoboxes for biographies of politicians were a special case, and that cropping right to the top of their heads was appropriate? [8][9][10] AndyTheGrump (talk) 12:19, 17 November 2022 (UTC)
- Our point in infoboxes is not to have a "conventional portrait", though. It's meant to be more in line with how other sites that report elections show candidate headshots, for example, check out The New York Times. While they have better pictures than we do, they do a similarly close-up crop (except they do a square crop, because they put the headshot in a circle; the idea is the same, though). Elli (talk | contribs) 11:21, 17 November 2022 (UTC)
- Please provide examples from outside Wikipedia where the creators have considered it appropriate to crop a closeup portrait from a larger image to the extent that the top of the head is a few pixels below to top of the crop. You won't find them. Nobody does that for a conventional portrait. It is ugly, and unnecessary. AndyTheGrump (talk) 11:05, 17 November 2022 (UTC)
- Oppose. Images should be individually evaluated for whether cropping is appropriate, and what dimensions are individually most appropriate. Fidgeting the crop of images trying to force arbitrary consistency is clearly not vandalism (as someone suggested), however it is both unnecessary and unhelpful. Also Wikipedia:Avoid instruction creep. Alsee (talk) 08:55, 18 November 2022 (UTC)
National Froggy Day
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.
national froggy day is now on September 19th. celebrate the froggy 205.137.37.23 (talk) 13:42, 17 November 2022 (UTC)
- Man, we missed it by 2 months. 🐸 ~ ONUnicorn(Talk|Contribs)problem solving 13:44, 17 November 2022 (UTC)
- On a more serious note, Do you have a source for September 19 being National Froggy day? It seems to be International Talk Like a Pirate Day, but not National Froggy Day. I see that March 20 is World Frog Day (although we don't seem to have an article about World Frog Day - but we do for World Sparrow Day on the same date). October 21 seems to be American Frog Day (also no article in our encyclopedia, sadly). And apparently, April 28 is Save The Frogs day, which we also don't have an article about. Then of course there is May 13, which is National Frog Jumping Day. So, plenty of opportunities to celebrate the froggy, but none on September 19 as far as I can tell. But also, plenty of opportunities to expand Wikipedia's coverage of froggy related festivities. ~ ONUnicorn(Talk|Contribs)problem solving 15:05, 17 November 2022 (UTC)
- Whenever Froggy Day is this young lady is ready for it :-) MarnetteD|Talk 15:12, 17 November 2022 (UTC)
- Are we sure that it isn't a celebration of this "Froggy"? --User:Khajidha (talk) (contributions) 15:38, 17 November 2022 (UTC)
- Whenever Froggy Day is this young lady is ready for it :-) MarnetteD|Talk 15:12, 17 November 2022 (UTC)
- On a more serious note, Do you have a source for September 19 being National Froggy day? It seems to be International Talk Like a Pirate Day, but not National Froggy Day. I see that March 20 is World Frog Day (although we don't seem to have an article about World Frog Day - but we do for World Sparrow Day on the same date). October 21 seems to be American Frog Day (also no article in our encyclopedia, sadly). And apparently, April 28 is Save The Frogs day, which we also don't have an article about. Then of course there is May 13, which is National Frog Jumping Day. So, plenty of opportunities to celebrate the froggy, but none on September 19 as far as I can tell. But also, plenty of opportunities to expand Wikipedia's coverage of froggy related festivities. ~ ONUnicorn(Talk|Contribs)problem solving 15:05, 17 November 2022 (UTC)
- Strong support. Thebiguglyalien (talk) 01:10, 18 November 2022 (UTC)