Village pump (proposals) archive  

This page contains discussions that have been archived from Village pump (proposals). Please do not edit the contents of this page. If you wish to revive any of these discussions, either start a new thread or use the talk page associated with that topic.

< Older discussions · Archives: A, B, C, D, E, F, G, H, I, J, K, L, M, N, O, P, Q, R, S, T, U, V, W, X, Y, Z, AA, AB, AC, AD, AE, AF, AG, AH, AI, AJ, AK, AL, AM, AN, AO, AP, AQ, AR · 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175, 176, 177, 178, 179, 180, 181, 182, 183, 184, 185, 186, 187, 188, 189, 190, 191, 192, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212


Move good/featured article topicons next to article name

Closed as no consensus, despite the fact that the idea seems to have much valid support and would likely benefit our readers, and even taking into consideration and discounting the !votes of those who oppose the idea without having surveyed actual readers to see if they would benefit. Having said this, I would like to add that as closer, I am disappointed by the outcome, which I would rather have been for a consensus to implement this change. The closure is therefore without prejudice to having a new discussion on the topic and perhaps reaching a different consensus there. A loose necktie (talk) 12:49, 15 April 2021 (UTC)

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

Firstly, apologies if this has been brought up before, I couldn't find it in a search of the archives.

My suggestion is pretty simple: move the topicons indicating good or featured status from the top-right corner to after the article name, as is done on other language projects, such as here on the Danish Wikipedia. They are much more visible this way without being more obtrusive.

Why? Because I think the current icons are too well-hidden for the average visitor to notice, tucked away in the corner - I've been using Wikipedia for years and I barely ever notice the little gold star as my eyes jump to scanning through the content below. In my extensive, highly accurate survey of a couple of non-editor friends, they didn't know there's a recognised difference in quality between a long C-class article (say, Operation Market Garden) and a shorter featured article, because they didn't know good & featured articles existed.

Both have a standardised peer review process (the only subsection of Wikipedia's content that goes through this process) and have been around for a long time. Making this clearly visible is valuable for exactly the same reasons we undertake good & featured reviews: informing readers that the article is considered to meet a higher standard than average Wikipedia content; promoting greater trust in the content (vs. other Wikipedia content); increasing transparency of Wikipedia's processes (i.e. some sections of content have been peer-reviewed, others haven't); etc.

The objections I can see are that it could encourage people to think that the visible version of the page is mistake-free, to which I would respond that 1) the icons are already there, it's just that people aren't noticing them and 2) Wikipedia has been around for long enough for most people to know it's not a reliable source, and icons don't guarantee accuracy. I look forward to hearing others' thoughts on this. Cheers, Jr8825 • Talk 13:38, 6 October 2020 (UTC)

Sdkb I personally really like how it is handled now but I do see how someone not familiar with Wikipedia and the FA/GA process would miss the icons. What I'm fearing is that putting big icons next to the article titles will make it look cluttered. I can see that I'm clearly in the minority here; maybe i just need to see some concrete design suggestions, it is probably possible to move the icons as per your suggestion without making it look cluttered or obtrusive. Ichthyovenator (talk) 10:22, 7 October 2020 (UTC)
On the subject of whether it would make any difference: Rather than just speculating that this would be helpful, though, maybe we should test it out. Wikipedia doesn't use cookies like other sites, but we can experiment in other ways. For example, display a topicon that links not to WP:GA but to a dedicated subpage of the article it's displayed on with similar information. Check the pageviews after a month, move it closer, check pageviews after a month. Something like that? — Rhododendrites talk \\ 13:22, 7 October 2020 (UTC)

Mobile display

Tracked in Phabricator
Task T75299

@Eddie891 and Peacemaker67: You both mentioned mobile view in your !votes. There currently isn't any way to display topicons in mobile—see Wikipedia:Village pump (technical)/Archive 183#Featured/GA topicons for mobile—so GAs/FAs aren't currently being identified. There's a phabricator ticket for the issue but it has not yet been resolved. I suggest we stick to discussing desktop display above and discuss mobile here. ((u|Sdkb)) talk 00:26, 7 October 2020 (UTC)

Discussion

I would find it sad if this proposal ends up at no consensus→default to no action. As I've discovered through experience, making design changes to Wikipedia is hard, even in situations where change is clearly warranted, since not only does the consensus system favor the status quo by default, but editors' human tendency to prefer the familiar can also make it seem like proposals aren't as desirable as they'd seem if everyone was forced to live with them for a week before !voting on them. If this doesn't win outright support, I'd hope it'd be possible to at least try out the A/B testing, which is a much less disruptive action and should therefore require a somewhat lower bar to activate. The point is not to throw caution to the wind, but I do think we need to be less afraid of a little more design experimentation. As a result of the above factors, Wikipedia's design is notoriously outdated compared to other major websites, so there's a lot of room for improvement. Trying out a new position for the star icon won't bring about the apocalypse. ((u|Sdkb)) talk 05:44, 10 October 2020 (UTC)

It's why I said I disagreed with the premise. In order to do A/B testing, there needs to be an agreement on success criteria, and for that, there has to be an agreement on a problem statement. isaacl (talk) 07:09, 10 October 2020 (UTC)
My opposition, along with others, has nothing to do with "favoring the status quo", nor from a "fear of design experimentation". Rather it has to do with the fact that this change will mislead our readers. Paul August ☎ 16:38, 10 October 2020 (UTC)
Besides what Paul August says (that I agree with), I see several other issues here. First, it can be less hard to make design changes if you first consult the groups of editors most involved in or affected by what will be changed. You did not discuss this before with either GAN or FAC, where you might have heard the problems with your proposal. I doubt that many FA or GA participants are unaware of the shortcomings, pros and cons of those processes. Second, there were attempts to stifle the discussion here by several parties, indicating a lack of understanding about how consensus is formed. We don't just "yea or nay"; we explain our reasoning and discuss. And yet, two different editors discounted my reasoning, saying to take it elsewhere, this isn't the page ... although I was only explaining my reasoning for opposing. They didn't seem to understand that one SHOULD explain their reasoning. Third, you then went on to another proposal, about redesigning the icons, again without consulting with the involved pages or seeming to understand that the A,B,C, start, stub are WP assessments, GA is one-person, and FA is a community-wide process. If you will take the time to consult-- and listen-- you might find a lower number of failed proposals at design changes. SandyGeorgia (Talk) 22:44, 10 October 2020 (UTC)
@SandyGeorgia: I don't feel your characterisation of my suggestion as being naive or attempting to exclude regulars is fair. The village pump seemed to be the obvious place to make this suggestion, I wasn't at all attempting to bypass FA/GA participants and I'm very glad that others more familiar than myself with the bureaucracy notified the relevant talk pages. It didn't occur to me to bring up my suggestion at these places because I wasn't aware of their existence (also, a site-wide visual change seems out of the scope of those venues). I explicitly asked for feedback on my original statement and while it's shame we don't all see eye-to-eye I actually thought the discussion above was very valuable. Personally, I didn't think Sdkb and Forbes72 intended to stifle the discussion or discount your argument, both acknowledged you raised an important point and I thought they were trying to explain why they disagreed in this context. Ultimately this is a straw man, as it detracts from the main reasons you disagree with the suggestion, particularly that there's a risk of making readers feel the reliability of what they're reading is guaranteed.
I agree that this is the biggest issue, and I acknowledged this when I outlined my rationale. The discussion above has definitely reiterated the current FA/GA system's flaws, and this may, on balance, mean that my suggestion is unpalatable to the majority of editors here, which I would understand. I explained why I myself think the change could be beneficial overall at the start of the discussion: the layout could encourage readers to click to find out more about FA/GA, and this could increase awareness among readers and editors of how Wikipedia's internal processes work; it will more effectively promote the best work we have; if more readers were aware of FA/GA, it might produce greater scepticism towards other long articles that look well-written but have failed or not gone through peer reviews; most readers are already aware that Wikipedia is unreliable. The next thing that occurs to me is to only trial moving the featured star, as only featured content should be "featured" because only it has gone through a group peer review, rather than an individual one. Jr8825 • Talk 01:21, 11 October 2020 (UTC)
@SandyGeorgia: I raised the objection that your concern (which I actually agree with—I brought a page to WP:FAR not long ago that survived as a FA for way too long; you're clearly a passionate crusader for the issue and I'd be happy to see it discussed more elsewhere) was out of scope of the present discussion. I stand by that concern. You are arguing that FA/GA designations are unreliable, and there are only two ways to apply that to this discussion. The first would be to say that they're so unreliable that FA/GA designations should not be reader-facing, which is what I responded to above. That's a change that would overturn a longstanding consensus, and would require its own discussion; I expect that the closer will ignore !votes like GhostInTheMachine's (for not displaying stars) that are clearly speaking to that discussion, not this one. The second would be to say that they're reliable enough to be presented to readers but not reliable enough to be presented to readers in a way that they're likely to actually notice. That's a nonsensical way to parse things: either it's good for readers to know the FA status of an article or it's bad, and we need to stand by whatever we decide.
Regarding your attempt to pull rank based on your more active GA/FA participation, that's not how Wikipedia works. We value expertise, and the relevant projects have been appropriately invited to this discussion, but we also value input from a broad range of editors, including those less in the trenches who can often bring outsider's insights. (And if you want to get into qualifications, you may want to figure out who the most active and successful design/usability editors are.) ((u|Sdkb)) talk 03:18, 11 October 2020 (UTC)

Can the rhetoric be ramped down a bit? I don't think it's necessary to describe reasoning other than a good or bad interpretation to be nonsensical. And I don't think it is necessary to tell people who are engaging in discussion to consult and listen. I appreciate that it is disquieting for discussions to follow different paths than one might feel is optimal. For better or worse, there are always going to be slipups in communications. I trust we can overlook them and seek out common ground. isaacl (talk) 04:04, 11 October 2020 (UTC)

This seems wise. @SandyGeorgia: Admittedly, it's been a while since I've done anything with GA reviews, so maybe it would be a good time for me to help with the backlog. There's obviously some disagreement above, but we're all on the same team here. 〈 Forbes72 | Talk 〉 04:34, 11 October 2020 (UTC)

How aware are readers of GA/FA?

There's an empirical factual question here that seems to be influencing many !votes: To what extent are non-editing readers noticing the icons and aware of their significance?

On one side, JR8825 offers that in their survey of a couple of non-editor friends, none knew about it. Rhododendrites asserts In talking with hundreds of academics about Wikipedia over the years, including a whole lot of instructors who want to learn in order to help students learn about a site they use every day, they are almost invariably surprised to learn about GAs/FAs. Aoba47 concurs: I have also talked to non-editor friends and family members about Wikipedia, and none of them knew about the content assessment systems.

On the other side, we have Gatoclass's assertion, bolstered by subsequent "per" !votes, that the small coloured icons at the top right are quite eyecatching in any case and I very much doubt they are missed by readers - they are usually the first thing I notice when I open an article page and I doubt it's different for others. Guerillero argues a strong reason hasn't been given for a change, likewise dismissing that there is any problem.

Since this is a factual question, whichever side is incorrect should be appropriately discounted by the closer. What I notice is that everyone so far who has actually asked non-Wikipedians has found them unaware, whereas those arguing they are surely aware have provided nothing except speculation. This comes across to me as a classic example of the difficulty of putting ourselves in readers' shoes (a problem CJK09 has written eloquently about): yes, of course the GA/FA icons stand out to us, since we all already know about GAs/FAs; that doesn't mean they will to our grandparents. It would be ideal if we could uncover some formal research into the question, but in the absence of that, all the evidence so far seems to point to readers being largely unaware. ((u|Sdkb)) talk 22:33, 21 October 2020 (UTC)

(Yes, I'm aware some portion of the !votes/discussion above focused more on the question of how aware readers should be than the one of how aware they are. I am posing solely the are question here, since the should question has already been considered at length above.) ((u|Sdkb)) talk 22:33, 21 October 2020 (UTC)
I hope I'm not flogging a dead horse here, but I've have noted a number of relevant comments in a different discussion below in which several editors have expressed their view that very few readers ever notice these icons, and that it would be a positive thing if they did. This was the rationale for my original suggestion. I wonder if anyone else has a view on this? Jr8825 • Talk 22:43, 30 October 2020 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Priority watchlisting

I would like the ability to specify a few favored articles to appear at the top of my watchlist, and out of the main reverse-chrono sequence, anytime they meet the regular criteria for watchlist display. My use case is this: I occasionally monitor editing by student editors working on articles at Wikipedia as part of their university coursework through WikiEd, Wikipedia's collaborative program involving colleges and universities. It's important for me to see changes by student editors to any of my watchlisted articles right away, so I can respond in a timely manner. But, I have thousands of articles on my watchlist, and I might miss contributions if I don't log in for a day or two.

So, I'd like to see these articles at the top of my watchlist (or otherwise prominently displayed; perhaps a collapse button that renders everything else as display:invisible?) I realize this probably involves db and code changes and isn't going to happen overnight. But I would like to see if there is interest among other editors in something like this, and to find out what your use case might be, or how you might alter this proposal. Thanks, Mathglot (talk) 19:44, 6 November 2020 (UTC)

Watchlist suggestions seem to feature a lot on the meta:Community Wishlist. eg meta:Community Wishlist Survey 2017/Watchlists, meta:Community Wishlist Survey 2019/Watchlists. Getting the dev effort to get it done seems unlikely, but you could propose it on meta:Community Wishlist Survey 2021. Perhaps DannyS712 may have thoughts too, since he's working on mw:Extension:GlobalWatchlist. ProcrastinatingReader (talk) 19:59, 6 November 2020 (UTC)
@Mathglot Hmm, User:MusikAnimal/customWatchlists might meet your needs DannyS712 (talk) 20:03, 6 November 2020 (UTC)
If you know the particular articles they are interested in, Special:Recentchangeslinked on a subpage will do. --Izno (talk) 20:04, 6 November 2020 (UTC)
Thank you for all the suggestions, I will check those out! Mathglot (talk) 02:07, 7 November 2020 (UTC)
m:Community Wishlist Survey 2021 opens tomorrow. Whatamidoing (WMF) (talk) 21:21, 15 November 2020 (UTC)

How about making a separate "Wikipedia China Edition" that is censored to please the Great Firewall of China? (The normal version would be kept uncensored.)

Clearly viewed as a non-starter Nosebagbear (talk) 09:41, 18 November 2020 (UTC)

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

I am aware of WP:NOTCENSORED, and that's how it should stay for the normal en.wikipedia.org, zh.wikipedia.org, fr.wikipedia.org, etc. But how about making a separate en.wikipedia-cn.org, zh.wikipedia-cn.org, fr.wikipedia-cn.org etc. that, among other changes, mentions Taiwan as part of China and does not mention the 1989 Tiananmen protest, so it could be allowed in China? This way, editors that are temporarily on vacation in China that don't care about such "sensitive issues" can continue to edit normally (as you can't edit when connected to most commercial VPNs), and readers in China that don't care about such subjects could read non-controversial articles about science, culture, etc., as Wikipedia has better coverage on some niche subjects compared to Chinese wikis such as Baidu Baike. Félix An (talk) 03:58, 18 November 2020 (UTC)

This might be a discussion better for WP:VPI or WP:VPM since it doesn't seem to consider the why in any great detail, which is required for a good proposal (and in fact is something more of a question about our values, which you might indeed find at places such as NOTCENSORED, WP:5P, and many more).
From a practical point of view, this is a non-starter, since we do not have the people to maintain our 6 million articles, never mind kowtowing to whichever country/state doesn't like what we say. China isn't the only one pissed about something on any given day. :) --Izno (talk) 04:16, 18 November 2020 (UTC)
We would also need to make a Wikipedia Turkey Edition, a Wikipedia Arab Edition, a Wikipedia Armenia Edition, a Wikipedia Azerbaijan Edition, a Wikipedia American Conservative Edition.... We should not be in the business of writing PoV forks to appease emotionally-fragile authoritarians and nationalists. —A little blue Bori v^_^v Takes a strong man to deny... 04:23, 18 November 2020 (UTC)
For the record, anyone, including the governments of those countries, can make a mirror of Wikipedia and then censor it as they please. It is not our job to do so on their behalf. BD2412 T 04:56, 18 November 2020 (UTC)
Based on three replies above, the answer is no, or meh.... Enjoyer of World💬 08:54, 18 November 2020 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Redesigning the good article and featured article topicons

This proposal seeks to establish consensus for a mandate to redesign the icons that appear in the upper right corner of good articles (GAs) and featured content (FC) pages to mark their status.

Background: The current symbols for GAs and FC have been used since those systems were introduced way back in Wikipedia's early days. They have significant problems. The featured content icon is too skeuomorphic, giving it an outdated look, and its excessive detail causes it to render poorly at small scale. The good article icon, meanwhile, has been adopted throughout much of the rest of Wikimedia (and in some places on Wikipedia) as the "support vote" icon, leading to conflicting usage. More concerning than either of their individual issues is the lack of any shared visual language between them (the GA icon uses the norro style, and the FC icon is not part of any larger style system). When compounded by their overall lack of prominence (a separate issue under discussion above), this has led to the unfortunate situation where many (perhaps most) non-editing readers could not tell you whether a star or a green badge is a higher distinction, greatly diminishing the impact of the work editors put into the GA/FC systems.

Proposed process: This proposal does not put forward any specific redesign ideas, but rather seeks to assess whether there is general consensus for a change. If a mandate is established, editors at the graphics lab (where a version of this proposal is currently on hold) will have the opportunity to create designs, which will then be !voted on in a process perhaps similar to the one MediaWiki is using to redesign their logo, with the eventual winner adopted. Design proposals will likely incorporate changes to related icons such as those for good article candidates or former featured articles.

Cheers, ((u|Sdkb)) talk 20:23, 24 October 2020 (UTC)

Notified: Wikipedia talk:Featured content, Wikipedia talk:Featured articles, Wikipedia talk:Good articles, Wikipedia talk:WikiProject Usability. ((u|Sdkb)) talk 20:23, 24 October 2020 (UTC)

Survey

Should we redesign the GA and FC topicons?

@Sdkb: sorry to jump in on a mostly unrelated thread, but I find John M Wolfson's comment, that he didn't notice the FA/GA icons until becoming actively involved in Wikipedia, interesting. It relates to the point you raised above and the argument I made in my proposal there. Jr8825 • Talk 02:10, 29 October 2020 (UTC)
That they are not particularly noticeable is a good thing per arguments made above: these icons while of some use to editors, are misleading for readers. Paul August ☎ 11:57, 11 November 2020 (UTC)

Design discussion

What would you like to see in new topicons if they are redesigned? The discussion in this section will be used as guidance for designers if the proposal is successful.

General discussion

Facilitate gauging article length

Could we please make the References section of Wikipedia articles collapsed [hidden] by default, it could be opened if one clicks on a reference [n] link. One could then gauge how long an article is by looking at the size of the scroll bar. A small scroll bar means that the article is long. For example: If the scroll bar's dark middle area [the part one can drag] is a third of the size of the scollbar, one would know that the content is three screens long.

Thank you very much for Wikipedia. — Preceding unsigned comment added by GeneThomas2 (talk • contribs) 07:09, 10 November 2020 (UTC)

We have this request somewhat routinely, usually for related reasons (probably often enough it should be listed at WP:PEREN). It has been rejected each time because we do not see "knowing how long the article is" as sufficient to override the accessibility concerns with either hiding the references or (more usually) putting an in-content scrollbar into the page for the references. --Izno (talk) 14:02, 10 November 2020 (UTC)
GeneThomas2, I brought this up most recently at Template talk:Reflist.
For most readers the references are adjunct to the content proper, so making them collapsible does not break the “accessibility concerns” about hiding content. GeneThomas2
It'd be really nice to have for big articles like COVID-19 pandemic, where the reference list currently takes up nearly half the scroll length of the page, making it seem longer than it actually is (which is discouraging to readers; the longer a page looks via the scrollbar, the less people are to decide to read it).
Vietnamese Wikipedia (and possibly others) has implemented it, albeit fairly clunkily. I'm hopeful that with some technical advancements, it'd be possible to do this without introducing accessibility concerns. ((u|Sdkb)) talk 22:52, 10 November 2020 (UTC)
Rather than try to use the scrollbar for this purpose, which is hard to see on mobile devices anyway, I think displaying a word count or sentence count would be more helpful. An implementation would probably have to rely on heuristics to exclude the references, and would likely only be able to estimate what constitutes a word or sentence, but could still provide a reasonable indication for many articles. isaacl (talk) 23:25, 10 November 2020 (UTC)
DYKcheck has an implementation. --Izno (talk) 02:43, 11 November 2020 (UTC)
Thanks for the pointer, which led me to Wikipedia:Prosesize. It is able to isolate autogenerated reference lists by searching for the corresponding HTML class used to label them. isaacl (talk) 23:01, 12 November 2020 (UTC)
I would support a collapsed References section. Verifiability is essential for quality control, but the references are not really part of the message to the main reader. HTML-only accessibility is essential for the main text, but Wikipedia should take advantage of the capabilities provided by CSS and JavaScript that gives it the edge over paper encyclopedias (I feel Wikipedia is still too paper-like). Johannes Schade (talk) 12:07, 20 November 2020 (UTC)
How about "not by default." This sounds like something a gadget or preferences setting should control, at least for logged-in users. Maybe, after such a preference has been in place for a year or two, we can revisit whether to collapse the references "by default" for non-logged-in readers. For what it's worth, on the mobile interface, I think all sections except the "top" one are collapsed by default. davidwr/(talk)/(contribs) 15:39, 20 November 2020 (UTC)
@Davidwr: I like the thought of having a gadget available; that sounds like a good way to test this out and chip away a bit at the inertia of tradition. ((u|Sdkb)) talk 08:37, 22 November 2020 (UTC)

Add new edit tag for missing signatures

Should a new tag be added for when a user replies in a discussion, but forgot to sign? JsfasdF252 (talk) 07:04, 22 November 2020 (UTC)

You mean ((unsigned))? 207.161.86.162 (talk) 07:19, 22 November 2020 (UTC)
That's not a tag, which has a specific meaning on Wikipedia. To answer the original question, it would be virtually impossible to write a filter that could identify such posts, as the software has no way to tell whether you're actually adding a new comment or modifying an existing one. ‑ Iridescent 07:21, 22 November 2020 (UTC)
That's not a tag, which has a specific meaning on Wikipedia. I mean, it doesn't. It has several meanings. See, e.g., Wikipedia:File copyright tags, Wikipedia:Tagging pages for problems (WP:TAGGING), Wikipedia:Template index (which describes certain certain templates as "tags"), Wikipedia:Responsible tagging, Wikipedia:Tag bombing (just to name a few). 207.161.86.162 (talk) 07:26, 22 November 2020 (UTC)
What about edits that meet all the following criteria?
  • Didn't use "~~~~"
  • Occurred on a talk or Wikipedia page
  • Not marked as minor
  • Increased page size JsfasdF252 (talk) 07:28, 22 November 2020 (UTC)
Can you clarify the purpose for your proposed change? isaacl (talk) 07:32, 22 November 2020 (UTC)
Perhaps make it easier for editors to find and sign unsigned comments? JsfasdF252 (talk) 07:40, 22 November 2020 (UTC)
In my opinion, the editors most likely to sign unsigned comments are those participating in that discussion. Personally, I don't think some form of tagging (not sure what exactly you have in mind) is worth the effort. isaacl (talk) 07:48, 22 November 2020 (UTC)

A tool is being built which will preempt the need to hunt for unsigned pages. --Izno (talk) 14:27, 22 November 2020 (UTC)

I think we have this already, it's called SineBot. How will this tool be different? davidwr/(talk)/(contribs) 15:59, 22 November 2020 (UTC)

See RfC on changing DEADNAME on crediting individuals for previously released works

FYI
 – Pointer to relevant discussion elsewhere.

Please see Wikipedia talk:Manual of Style/Biography#RfC: updating MOS:DEADNAME for how to credit individuals on previously released works
This potentially would affect a significant number of articles.  — SMcCandlish ☏ ¢ 😼  02:22, 2 December 2020 (UTC)

Archiving webpages

Wikipedia articles are highly susceptible to weblink decay. High quality articles can be renndered worthless when a significant amount of references lead to nothing. Currently Wikipedia depends on the WayBack Machine to retrive webpages from deadlinks. But the internet archive doesn't have snapshots of many references used on the Wikipedia. Is it possible that the Wikipedia/Wikimedia archives pages linked in particularly high quality articles (Featured, Good and A-class)? Aditya(✉ • ⚒) 12:52, 27 November 2020 (UTC)

Alternatively, can we do anything to encourage external sites to keep more comprehensive archives of references used in FAs etc.? Certes (talk) 12:58, 27 November 2020 (UTC)
Sadly, there is little hope of websites in general being encouraged to keep archives of their own content. One of the most depressing phrases ever is the joyous exclamation: "We have redesigned our website!". This generally means that the pages were moved around (so breaking links) and many pages will have gone (possibly forever). — GhostInTheMachine talk to me 20:39, 27 November 2020 (UTC)
Sorry; I was unclear. I was suggesting that we encourage archive.org or similar sites to keep archives of FAs' external links. Comments below suggest that they have already done that for links added recently. Perhaps someone (a bot?) should now check that all links in FAs are archived, and prompt archive.org or similar to store those which are not, moving on to GAs etc. if resources permit. Certes (talk) 00:22, 28 November 2020 (UTC)

There are over 20 archive providers who freely provide web archive services. It would be a tough sell for WMF to dedicate resources required to run one internally; and there are questions about storing mass amounts of copyrighted content on WMF servers. -- GreenC 14:19, 27 November 2020 (UTC)

(1) WMF encouraging websites to keep their own archive must be a joke. Any websites that closes down will never take that responsibility. That is an absurd view of the world.
(2) Maintaining acrvives of copyrighted material may not be as difficult a process. Archive.org has successfully done it, and there is no record of litigation against it.
(3) It may also be possible to strike a partnership with archive.org or some site else.
Whatever the way, WMF needs an archiving system to become sustainable. Otherwise all featured, good and A-class articles are bound to become junk. Aditya(✉ • ⚒) 00:07, 28 November 2020 (UTC)
(1) I have no idea what you are talking about.
(2) Good luck with that idea.
(3) Already exists. -- GreenC 00:35, 28 November 2020 (UTC)
Andrew🐉(talk) 00:06, 3 December 2020 (UTC)

Cosmetic Bot Day (CBD)

The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion. A summary of the conclusions reached follows.
There is consensus for the relaxing of WP:COSMETICBOT so that bots may be approved, using the normal process, to allow cosmetic edits that would run only on designated cosmetic bot days (in addition to typical trials/testing done during the Bot Request process). These bots must still have appropriate consensus for their cosmetic tasks. Several editors, both those in favor, but especially those who opposed worried that the tasks would impose preferences rather than improvements.
At the moment there is consensus for a single cosmetic bot day as a trial when these bots may run as there was no consensus about a frequency among participants of this RfC. There was no consensus, largely to lack of discussion, about when such a cosmetic bot day trial should occur but to the extent it was discussed editors indicated a preference for days that experience fewer edits. In any event appropriate notification should be given to warn editors of the trial.
When approving bot(s) that may run on cosmetic bot days, the Bot Approvals Group should also take into consideration the preference expressed for bots/cosmetic bot day structures which will minimize watchlist disruption (for example Enterprisey suggested a theoretical way cosmetic edits would be aggregated before being implemented by a single bot).
Following this trial, subsequent discussion (and/or follow-up RfC) may establish consensus for further cosmetic bot days including a proposed frequency and any other supporting structure/limitations as the community may deem appropriate. — Preceding unsigned comment added by Barkeep49 (talk • contribs) 22:05, 7 December 2020 (UTC)


Caution: bots temporarily improving Wikipedia

Cosmetic edits are generally disallowed by bots because they continually light up watchlist for changes that are not substantive impeding work flow. This is good. However, as a result many changes that could easily be done by bot never get done, and the community is left to fix simple issues by hand, assuming they ever get done at all.

This proposal is to have 1 day a month or year etc.. that is exempt ie. "Cosmetic Bot Day". Any such bot would require approval though WP:BRFA as normal, bot ops can't do whatever you want, but the bot on that day would not be under Cosmetic regulation, assuming there is otherwise consensus for the bot task. It's a trade-off between allowing bots to fix some problems that are plainly cosmetic while not lighting up watchlists on a daily basis.

It is true WP:COSMETICBOT already says "Consensus can, as always, create exceptions for particular cosmetic edits", however in practice these "exceptions" rarely happen because the bots are running continuously thus the bar is set high. This proposal would allow a temporary relaxation of COSMETICBOT.

For example the period might be once a month (the first day). If there is concern about too many edits, it might be limited to 1 CBD request per month ie. only 1 bot can claim the CBD spot each month. There could be a simple list where bot owners can add their name and date and link to the BRFA discussion, it would need minimal overhead and be nearly self-regulating.

If the bot is doing questionable things (eg. moving the placement of every instance of |url= before |title=) this proposal does not give blanket or even tacit permission. The bot task must have consensus first. The proposal would free up editors time to focus on more substantive work.

-- GreenC 15:41, 25 October 2020 (UTC)

Could we have an example or two of the sorts of edits that would be done on this day? I think an annual day would be an easier sell, as far as disrupting watchlists goes, than a monthly one. ((u|Sdkb)) talk 16:06, 25 October 2020 (UTC)
Examples might be adjusting spacing of infobox parameters and their values (to make them line up in edit view); replacing template redirects with their canonical names; adjusting spacing within and above/below headers in a way that does not change the rendered view but standardizes them; or many of AWB's general fixes, like some of those listed in the FixSyntax section. Or cosmetic edits that some editors do regularly, including editors like me. Although it might be annoying one day per month, getting millions of articles looking more similar in edit mode may be helpful. – Jonesey95 (talk) 16:40, 25 October 2020 (UTC)
Another example would be users like NicoV and others might be able to clear out the entirety of WP:CWERRORS if we had enough bots working on it. Primefac (talk) 17:33, 25 October 2020 (UTC)
Thanks Primefac for the notification. I already have some tasks approved for cosmetic edits alongside other edits (T6, T8, T9, T11), maybe some of them could be approved to run if the CBD proposal was accepted. I'm sure there are also other tasks related to other WP:WCW errors that could be added (I never spent the time required for BRFA for other errors that would only be cosmetic edits). --NicoV (Talk on frwiki) 19:33, 25 October 2020 (UTC)
I would be in support of something like this. I think the idea of a cosmetic bot day of the month/half month would be the best. Year seems to far apart if this is actually needed. Week might be too often if the task is purely cosmetic.
I think that these tasks should only be allowed on this proposed day if the task has been approved by a BRFA for running on that day. This could be that the BRFA has to state that on the "cosmetic day" the bot will do X, Y and Z cosmetic changes. This will ensure that the bot will have explicit approval to run on that day in particular.
Perhaps limiting the number of cosmetic tasks that can be run on that day might be needed, but I wouldn't want a limit unless it is needed. I think a list of what tasks will run on each cosmetic day would be good, regardless of whether limits exist to ensure that it is all transparently logged and prevent any misunderstandings. Dreamy Jazz talk to me | my contributions 16:15, 25 October 2020 (UTC)
  • Another reason is that for us with a "copy-edit, gnomish" bent, it is quicker and easier to edit when there is consistency in the edit-mode view of pages. This would also stop the undeclared hidden-space-wars (eg: white space additions/removals in infoboxes, line returns between headers and sub-headers, and other stuff). Regards, GenQuest "Talk to Me" 20:03, 25 October 2020 (UTC)
That's not quite true. There's some edits that would make things things a lot more editor-friendly, even if they are technically cosmetic. There's certainly a threshold, but there's a subset of them that would be useful. Edit conflicts and 'performance issues' are overblown as issues. Watchlist flooding could be minimized by choose days with lower editor activity, and edit history clutter can also be minimized by focusing on higher-value tasks, and by performing them only once per every few months. It's not anything that technically couldn't already be handled via normal bot approval though. Headbomb {t · c · p · b} 02:20, 26 October 2020 (UTC)
likely to cause edit conflicts and performance issues. I've already noticed Wikipedia running slowly in recent weeks. Doesn't Wikipedia:Don't worry about performance apply here? 207.161.86.162 (talk) 02:49, 29 October 2020 (UTC)
My concern is not hypothetical. This morning, for example, Wikipedia froze on me for a period of over a minute. It's not clear why but other apps were ok so the problem seemed to be at the Wikipedia end. And that's not the only sort of performance issue. Wikipedia is constantly growing in size and so this tends to cause technical limits to be hit. Some pages can't easily be deleted now because they have had too many edits. Some pages won't display properly because they have too many templates. DYK had to divide its operations in two for such reasons and AfD is regularly affected too. Blithe reassurances are unconvincing because it seems apparent that no sizing or testing has been done – the only estimate we seem to have of the impact is "gazillions". The planned process seems to be to turn bots loose for a day and find out the hard way. This is just asking for trouble.
And note that the effects are permanent; not just a transitional spike. By adding lots of unnecessary edits, the page histories will all be that much longer and harder to analyse, process and understand.
And the purported benefits seem marginal. For new editors, the future is the Visual Editor, which does not require this. And for scripting, you can't rely on a particular format because there will always be new pages which will not conform. The effort seems mainly to be busywork for its own sake – playing with bots as toys or to boost edit counts.
My !vote stands.
Andrew🐉(talk) 12:27, 29 October 2020 (UTC)
Andrew Davidson, the number of bot edits taking place has zero effect on the performance of the site. The MediaWiki software is designed with scalability in mind and is capable of handling a lot of more edits daily than the number that actually takes place. In extreme occasions where a botop loses control and drives in 1000s of edits in a few seconds, the database locks up in a read-only mode for a number of seconds during which no edits can be made, but even that does not impact readability of the site. Of course, Wikipedia may freeze and go offline occasionally, but high rate of edits is AFAIK never the reason for those issues. – SD0001 (talk) 09:31, 30 October 2020 (UTC)
@Andrew Davidson: Is this not a question for the developers? And if this is likely to result in performance issues (or is unlikely to result in performance issues but does so in the future), do you not think that they will intervene? 207.161.86.162 (talk) 08:48, 6 November 2020 (UTC)
It's usually easy enough to find out the answer to that question: Aaron Schulz, Krinkle, would your team like to propose any limits on this, if it were adopted? Whatamidoing (WMF) (talk) 21:14, 15 November 2020 (UTC)
Every bot requires consensus at WP:BRFA ("Bot Request for Approval"). The proposal does not remove the need for consensus for individual bot tasks. GreenC 18:23, 29 October 2020 (UTC)
The proposal is not a not a free-for-all cosmetic day. All bots requires consensus and approval per normal procedures at WP:BRFA. -- GreenC 18:15, 29 October 2020 (UTC)
It's the work of a minute to adjust your watchlist settings so bot-tagged edits are filtered out. – Teratix ₵ 13:51, 29 October 2020 (UTC)
Bot proposals are made at WP:BRFA. This CBD idea is not a bot proposal. -- GreenC 18:10, 29 October 2020 (UTC)
@Cthomas3: Every bot requires consensus at WP:BRFA ("Bot Request for Approval"). The proposal does not remove the need for consensus for individual bot tasks. -- GreenC 16:58, 29 October 2020 (UTC)
Just because a few editors at BRFA think something sounds like a good idea doesn't mean that every editor on every article agrees. If the bot changes someone's pet article in a way they don't like, they are just going to revert it at their first opportunity. Next month, the bot makes the same edit, and so on. Is our plan to allow a bunch of slow-motion bot vs. human edit wars? CThomas3 (talk) 20:47, 29 October 2020 (UTC)
BRFA in general has the same issue, and it seems to have gotten along fine. Enterprisey (talk!) 05:01, 30 October 2020 (UTC)
That's a good point, but I would suggest that several of the suggestions already presented here tend to be more of the 'editor preference' type and not necessarily an objective improvement (such as lining up infobox parameters, converting tables to one cell per line, and converting template redirects to their canonical equivalents). If we're saying that these types of edits would likely not be approved at BRFA then perhaps I am being overly cautious. CThomas3 (talk) 06:30, 30 October 2020 (UTC)
This proposal doesn't aim to loosen standards for consensus or create new 'good' cosmetic tasks. It's simply to relax WP:COSMETICBOT for a day, which is overriding exclusionary criteria (even when the edit otherwise would have consensus). In a similar manner to how WP:NOT is exclusionary criteria; even if an article would otherwise meet notability guidelines, its presence can be prohibited by an overriding policy. COSMETICBOT is that for cosmetic edits (with some exceptions, eg substitution bots). Things like a general 'converting tables to one cell per line' would (if they're even supported by a PAG in the first place) likely fail WP:CONTEXTBOT anyway. Others may genuinely not be an improvement (per Headbomb's posited questions above). Those, I suspect, would not be approved to operate. ProcrastinatingReader (talk) 13:04, 30 October 2020 (UTC)
InternetArchiveBot will not be taking cosmetic edit requests :) The proposal for *text to * text is a strawman ie. easily rejected as a bad idea. But the existences of this bad cosemtic edit ideas does not preclude other better ideas. --GreenC 15:11, 7 November 2020 (UTC)
  1. As long as the WP:BAG isn't overwhelmed. Enough lead-time should be give so that all bots are able to receive the regular amount of scrutiny & testing prior to CBD.
  2. Perhaps a 1-time CBD, and then reevaluate via another VPP to see the effect & community response to making it a regular (monthly, yearly, etc.) thing.
  3. Many of the Opposes above seem ignorant of the Watchlist option to exclude bot edits.
~ Tom.Reding (talk ⋅dgaf)  14:29, 7 November 2020 (UTC)
Almost all of those commenting about the option to exclude bot edits seem ignorant that the drawbacks to this option have been explained (and ignored) multiple times already. It also completely ignores all the other reasons this is a terrible idea. Thryduulf (talk) 16:34, 7 November 2020 (UTC)
@Thryduulf: not agreeing with certain cosmetic edits is not a legitimate reason to oppose. Regardless of the outcome of this VPP, WP:BAG/WP:MOS/the community/etc. will continue to decide if particular cosmetic edits, and the way in which they are programatically found & fixed, will make it into a BRFA.   ~ Tom.Reding (talk ⋅dgaf)  16:55, 8 November 2020 (UTC)
That addresses one more reason (given the reasons peopel give for supporting here I'm not confident they wont be passed at BRFA, but that's a separate issue) but ignore the rebuttal to the "hide bots" argument and the other reasons given. Thryduulf (talk) 17:32, 8 November 2020 (UTC)

Closure

In my opinion as a BAG member, this closure should be undone and the outcome of the RFC should be judged by the BAG. There's consensus for a general trial/exploration of having more cosmetic bots on Wikipedia, but the details of the trial have not been mandated by the community and should be left to the BAG. Cosmetic bots are already allowed on Wikipedia, provided they have community consensus and a BRFA. The above 'proposal/supervote' in the closure is simply untenable. There is zero special concerns with bot edits to vital articles or BLPs. Requiring only one single bot edit per article is also untenable, unworkable, unwarranted, and undesired. Part of the point of this trial is to figure out what happens if you give permission for cosmetic bots to edit on Wikipedia a bit more freely, perhaps on a monthly basis. That means seeing what happens with edit conflicts, if there are cosmetic edit wars, how much people get ticked off, and the like. We don't even know what level of interest there is amongst bot coders for coding cosmetic bots to begin with. Maybe there'll be two, maybe there'll be twenty. Headbomb {t · c · p · b} 13:11, 2 December 2020 (UTC)

  • There's relevant discussion on my talk page.—S Marshall T/C 20:27, 2 December 2020 (UTC)
Yes, in which multiple editors asked you to undo the close and let BAG review this, or at the very least leave the details of any trial to the BAG. Which you've refused to do. Headbomb {t · c · p · b} 21:39, 2 December 2020 (UTC)
  • That discussion resulted in consensus to overturn the closure, which I have done. For the record, this was the now-removed closing statement. Sandstein 14:31, 6 December 2020 (UTC)
    I had been following along for much of the discussion with an eye to possibly closing. I will be reading again today with the intent of closing (it's always possible that after reading/beginning to write my close I will discover I am not an appropriate closer for some reason - if so I'll strike this and post a comment). Best, Barkeep49 (talk) 16:01, 7 December 2020 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

A bot to exclude vanished users from mass messages and/or bot talk page messages

I have filed a BRFA for a task which would if approved add ((nobots)) template and/or Category:Wikipedians who opt out of message delivery to user talk page's of vanished users. The bot will not create user talk pages for vanished users, so only vanished users with talk pages will be affected. This was discussed at Wikipedia talk:Requests for comment/Arbitration Committee Elections December 2020 § Mass message, where it was discussed that sending mass message notifications to vanished users was unneeded for the arbitration committee elections. The idea of using a bot to add the category and also possibly nobots was suggested. I think such a bot would be useful. Vanished users are exceedingly unlikely to be reading their talk page, as they have vanished. Although the messages are harmless, I think talk pages of vanished users should ideally remain unedited unless it is necessary, as it is the closest thing that we have to deleting an account and vanished users are unlikely to every read these messages. The bot task will only edit the page once, so if the bot is reverted, it will not reinstate the changes. For more information on how and what the bot would do, the BRFA is where I've listed specifics. This discussion is to give this some wider attention, so that consensus can be found for a particular way forward. The options that can be taken are:

  1. Option 1: Have a bot task which adds ((nobots)) and exclude the talk page from mass messages
  2. Option 2: Have a bot task which adds Category:Wikipedians who opt out of message delivery to prevent mass messages
  3. Option 3: Have a bot task which adds ((nobots))
  4. Option 4: Have no bot task

If you have questions about the bot, please ping me when commenting here or comment at the BRFA. Dreamy Jazz talk to me | my contributions 18:42, 30 November 2020 (UTC) (modified Dreamy Jazz talk to me | my contributions 20:39, 7 December 2020 (UTC))

I would personally vote for Option 1, with a second choice of Option 2. I think that vanished users don't need these messages, so preventing them seems reasonable. Dreamy Jazz talk to me | my contributions 18:42, 30 November 2020 (UTC)

Wikipedia for children

Good day I've been informed you can ask questions and give suggestions.

I would like Wikipedia to consider. Start a Wikipedia platform for children at the age of 14. Children are not taught common law or criminal law at schools. It would be important for a growing population to learn there rights, how can children be expected to know the law without it being taught. I believe it would be really good platform for everyone.

People could be members of the platform. A small subscription could be charged.

Let Wikipedia stand out above the rest. After all you are a educational platform. 🇬🇧

Kind regards Andre Hulse — Preceding unsigned comment added by 2a00:23c7:6011:2c01:1084:5d67:531:866b (talk) 18:01, 6 December 2020 (UTC)
Andre Hulse, It is not clear what you are actually requesting. · · · Peter Southwood (talk): 20:02, 6 December 2020 (UTC)
Try w:simple:Main Page. The general idea of a Wikipedia for kids is nothing new either: m:Kidswiki. — Alexis Jazz (talk or ping me) 21:03, 6 December 2020 (UTC)
There's also Vikidia, which is not a WMF project (though it is loosely associated with Wikimedia France). Vahurzpu (talk) 21:58, 6 December 2020 (UTC)
Kids actually can edit the English Wikipedia, there's no rule against it. --a gd fan (talk) 19:01, 9 December 2020 (UTC)

Proposal to enhance Template:Section sizes

There is a discussion about a proposal to improve Template:Section sizes going on at Template talk:Section sizes#Proposal for optional cumulative size column. Your feedback would be appreciated. Mathglot (talk) 08:27, 12 December 2020 (UTC)

Revenue plan: City governments subscribe to Wikipedia on behalf of residents

Ask readers of Wikipedia to sign a petition for their City to subscribe to Wikipedia. When sufficient signatures are gathered, present the petition to the City. A City subscription costs $10k/month? Or, $0.10/month per resident? — Preceding unsigned comment added by Keihatsu1 (talk • contribs)

Hi @Keihatsu1:, we are "owned" by a charitable organization, and want to give away the information on the project for free, to everyone. Any person or organization is welcome to make donations to us, but subscriptions are not necessary as we are free. — xaosflux Talk 05:30, 10 December 2020 (UTC)
Selling access to Wikipedia might reduce quality, by discouraging editors who prefer to donate time to improving a freely available resource rather than for one which someone else is collecting money. Certes (talk) 10:19, 10 December 2020 (UTC)

Hide rollbacks from watch lists

Twice in the last oh couple months or so I have accidentally rolled back changes on my watch list due to mis-clicks. Both times I have tried to click on something fairly quickly, before all the scripts on the page have loaded. A similar thing with the late-loading scripts happened again today, but I just went to a separate article, and I almost just mis-clicked again, which is why I'm here in the first place. Is there currently a way to either hide the rollback on the watch page until you need to use it (by toggling it off/on), or to at least have a confirmation page come up before you commit a rollback from a watch page, and if not, would this be easy to implement? SportingFlyer T·C 23:12, 10 December 2020 (UTC)

Go to your preferences > Appearance; in the Advanced options, check Show a confirmation prompt when clicking on a rollback link. Enjoyer of World(bother...) 23:37, 10 December 2020 (UTC)
Alternatively, there are instructions on how to remove the rollback button from your watchlist at Wikipedia:Customizing watchlists (check the section called "Remove or modify the [rollback] link"). Armadillopteryx 23:40, 10 December 2020 (UTC)
Fantastic. Thank you both for your help - I've sorted it! SportingFlyer T·C 01:15, 11 December 2020 (UTC)
The other major issue here is the jumps that occur because of how the page loads. The developers really need to find a fix for that, since it's incredibly annoying. ((u|Sdkb)) talk 19:33, 11 December 2020 (UTC)
If the jumps are due to images that load more slowly (and are likely pulled from a different server), one possible solution is to enclose the image in a box of the same size which will load first and occupy the page space, while the image loads whenever it loads, occupying the same size space and avoiding jumps. Mathglot (talk) 23:25, 12 December 2020 (UTC)
@Mathglot: I think it's often due to watchlist announcements or other banners. ((u|Sdkb)) talk 19:58, 13 December 2020 (UTC)
Same solution, unless I'm missing something. Mathglot (talk) 20:06, 13 December 2020 (UTC)
Since HTML 3.2 (January 1997), the <img /> element has provided the width= and height= attributes, which according to the HTML 5.2 spec allows the user agent to allocate space for the image before it is downloaded (the code example there is from our own main page of 18 June 2014). The MediaWiki software emits these attributes. --Redrose64 🌹 (talk) 21:52, 13 December 2020 (UTC)

Time to change fundamentals

First time here. Not sure if this is the right place to write this.

Wiki keeps asking for money. It is about time to monetize the site. It has been great all these years without ads but it is time for a change.

You are asking the wrong people for money. Ask the corps that are willing to pay and more importantly that have the means to pay.

Make the ads small and keep them at the top of the page or left hand side.

I examined your financials, with over $120M per year in operating budget and still cannot make ends meet? It is time someone in charge took a long hard look at what's really going on. Take a big step back and view it from a different perspective. Bring in some top financial tech consultants to help re-organize and restructure. It's time to cut costs, a lot of costs. I run a business and have had to make major changes twice over the last 20 years to save money and to survive.

It's doable in any sector and industry, especially tech. — Preceding unsigned comment added by JamesStape (talk • contribs) 22:35, 3 December 2020 (UTC)

Any company that wants to is free to mirror or fork Wikipedia and turn the fork into a commercial enterprise. If the WMF "went commercial," it's almost certain there would be a "hard fork" by a new non-profit and the major editors would abandon the WMF for the new organization. Or, to put it another way, "DO NOT WANT". davidwr/(talk)/(contribs) 00:25, 4 December 2020 (UTC)
Agreed. Wikipedia should not have ads. See: Wikipedia:Perennial proposals#Advertising Tony Tan · talk 09:41, 6 December 2020 (UTC)
Who said WMF can't make ends meet? My understanding is that they have a healthy financial buffer. RudolfRed (talk) 00:56, 4 December 2020 (UTC)
Well, with all the advertising the last few days to non-logged-in editors, I can see how one might get the impression that they were strapped for cash. davidwr/(talk)/(contribs) 01:37, 4 December 2020 (UTC)
They're not saying they are strapped for cash. They are saying they need the donations. Which they do, both to cover expenditure and to build the financial buffer even further. I think the long-term goal is to create an endowment. -- The Anome (talk) 01:41, 4 December 2020 (UTC)
Yes, that's the long-term goal. --Izno (talk) 01:57, 4 December 2020 (UTC)
Like the responsible boards at any soundly-run non-profit, the Wikimedia Foundation is trying to build up a solid endowment for the future. As we keep having to repeat every time this idea comes up, any effort to commercialize or otherwise degrade Wikipedia would be met with massive and effective resistance from the thousands of editors who make it work. We would down tools and walk away, pausing only to note the names of those who destroyed all our work in the name of a bogus "efficiency." --Orange Mike | Talk 02:50, 4 December 2020 (UTC)
I'm not sure a project like this could ever work (in today's time) as a commercial enterprise. Perhaps in the future when software - eg a more coherent GPT-3 - can generate this content automatically, but otherwise it's infeasible. There's minimal commercial interest in trying to create a neutral encyclopaedia that covers so many topics. Brittanica could not (and does not) come close to the sheer volume and breadth of content. Which means you can't hire enough writers, which means you need volunteers, and volunteers will (most likely) not spend their hours chugging away at a project for the sake of shareholder profit. These kinds of projects only work as mission-aligned projects, I think, rather than shareholder-aligned ones. The rebuttal to these thoughts is Baidu Baike, but a lazy defence would be that that's a different culture and its quality is perhaps varying. ProcrastinatingReader (talk) 08:01, 4 December 2020 (UTC)
This happens every year, the requests for donations mislead readers, we complain, WMF wave their hands and spout platitudes and do it again. Same old story.· · · Peter Southwood (talk): 19:56, 6 December 2020 (UTC)
At least the WMF has a title which clearly distinguishes it from Wikipedia. Certes (talk) 20:15, 6 December 2020 (UTC)
@Certes: The question is for how long. — Alexis Jazz (talk or ping me) 18:57, 7 December 2020 (UTC)
Indeed; hence my first userbox. When I first visited Wikipedia, I clicked Donate, naively expecting to give to Wikipedia. Instead it solicited money for something I didn't quite understand, so I decided to donate my time instead. I think it only fair that future donors be clear as to where any funds might go. Certes (talk) 19:18, 7 December 2020 (UTC)
Hi, James, thanks for your suggestion. There is a project underway to provide a premium access tier for the big consumers: please see meta:OKAPI.
Some other sites out there run MediaWiki software with advertising and do okay for themselves, e.g. Wikia. But I think in the free-encyclopedia niche, Wikipedia has become so dominant that it would be hard for any competitors to get a leg-up. (Unless W?F messes things so badly that there is a mass exodus.)
As to the questions about whether the Foundation is spending its money wisely, is running a lean and focused operation, or is pushing donation-appeal campaigns that reflect its standing and aim to become the world's "essential knowledge infrastructure", I'll leave those for another time. :)
— Pelagic ( messages ) – (09:54 Mon 14, AEDT) 22:54, 13 December 2020 (UTC)

Make links to disambiguation pages orange by default

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.

Should links to disambiguation pages be orange by default? --RexxS (talk) 16:33, 23 November 2020 (UTC)

In the Special:Preferences#mw-prefsection-gadgets 'Appearance' section, there is an option to Display links to disambiguation pages in orange. I've found this very useful, and at a recent virtual UK meetup, it was suggested that it ought to be made the default option. I do not believe that there is any technical obstacle to doing that.

Please indicate your support or opposition for the proposal. I've created a separate discussion section to avoid fragmentation of debate within the other sections. --RexxS (talk) 16:33, 23 November 2020 (UTC)

Notified: WikiProject Usability. ((u|Sdkb)) talk 17:27, 23 November 2020 (UTC)
Notified: WikiProject Disambiguation. — Rod talk 17:36, 23 November 2020 (UTC)
Notified: MediaWiki talk:Gadget-DisambiguationLinks.css. —⁠andrybak (talk) 18:47, 23 November 2020 (UTC)
Notified: Template:Centralized discussion. –MJL ‐Talk‐☖ 17:45, 28 November 2020 (UTC)

Support (orange dab links)

Oppose (orange dab links)

Discussion (orange dab links)

Tracked in Phabricator
Task T268855
Items that attract attention at the proposal stage are generally the ones that are problematic in some way. They may be unnecessary because of a feature the proposer didn't know about or the idea needs to be better fleshed out. If your proposal doesn't attract any comments, it means you wrote it up clearly and there isn't an alternate solution to the issue. VanIsaacWScont 12:46, 1 December 2020 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Simplify links to redirects

This is an extremely minor suggestion for a bot.

Let's say there's a link: [[Page name|Text of link]]

The bot would do the following:

  1. If the (Page name) redirects to (Another page name) then (Page name) is replaced with (Another page)
  2. If the (Page name) redirects to (Text of link) then the code becomes: [[Text of link]]

Maybe not #1, because of, say, "apple" changing in: [[Apple|Apples]], but #2 seems good.  AltoStev Talk 00:02, 19 December 2020 (UTC)


I've had another idea where when moving a page it auto-changes all the links.
Also I forgot to include when [[Page Name 1]] redirects to [[Page Name 2]] although that's even more disastrous because it changes the text itself.  AltoStev Talk 00:08, 19 December 2020 (UTC)

Redirects are WP:NOTBROKEN and don't need fixing in this way. --Izno (talk) 00:29, 19 December 2020 (UTC)
More