Wikipedia

Wikipedia:Village pump (proposals)/Archive 168

< Wikipedia:Village pump (proposals)
Latest comment: 4 years ago by Kevin McE in topic Events rather than announcements
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, 213, 214

Proposal: Bot for the current main-page-related vandalism

Latest comment: 4 years ago36 comments16 people in discussion

There's been a rapidly IP-hopping editor vandalizing the TFA and pages linked to it. See also two AN discussions, EFN discussion, and EFR discussion. I figure we should have a bot specifically watching for and reverting these edits. An edit filter (1050) has been tried, but I think a bot would catch a broader range of edits (that is, the LTA has proven to be pretty good at evading new edit filter rules as they come up). A user script would work but a bot would be available all hours of the day. They've also gone cross-project (e.g. enws) so this would function more like a "cross-project abusefilter" (pending local discussions, obviously). Getting approval here before the BRFA. Thoughts? Enterprisey (talk!) 01:07, 15 May 2020 (UTC)

Enterprisey, I think it's a great idea. Kevin (aka L235 · t · c) 02:46, 15 May 2020 (UTC)
@Enterprisey: Who would have access to the bot's "rules"? In order for this bot to be effective, it would have to (unlike ClueBot) edit war endlessly with users it thinks are the LTA. So if the bot is wrong, and you are asleep, who can fix that, without blocking the bot? Suffusion of Yellow (talk) 02:51, 15 May 2020 (UTC)
Just me, but I can share the source code with people who ask. It will indeed have to edit war endlessly, unless it's given permission to block IPs (which probably isn't that good of an idea). It'll have a shutoff page onwiki. Enterprisey (talk!) 03:12, 15 May 2020 (UTC)
How is a bot different from an edit filter, other than polluting the history? * Pppery * it has begun... 02:52, 15 May 2020 (UTC)
A bot can perform a much broader set of checks. An edit filter is just a word filter with extra steps. Further details are probably BEANS territory. Enterprisey (talk!) 03:13, 15 May 2020 (UTC)
  • It's more worthwhile to protect TFA articles pre-emptively for a definite duration until this subsides. --qedk (t 愛 c) 18:35, 15 May 2020 (UTC)
    Sounds fine to me. Enterprisey (talk!) 00:55, 17 May 2020 (UTC)
    The problem I have is that it's not limited to the TFA; we've protected the TFA and the vandal moves to other pages linked from ITN, DYK, RD, etc. Protecting every main page article preemptively by bot would definitely work, but seems like too much maybe? I think the targeted approach would be better, but would be fine with either as long as we're stopping all of it. — Wug·a·po·des​ 01:44, 17 May 2020 (UTC)
    The idea of semi-protecting the TFA is on the perennial ideas list, so there may be opposition to that. I have no strong feelings about it on way or the other, though. {{u|Sdkb}} talk 11:15, 17 May 2020 (UTC)
    Now, there's actually a reason for that, hence my suggestion. I'm not a big fan of restricting pages tbh, but it's important to show that LTAs are not welcome. :) --qedk (t 愛 c) 04:42, 19 May 2020 (UTC)
    There was a reason for it in 2018-19, and for a much more severe case of LTA vandalism than this. The community didn't approve of preemptively protecting pages then either, but we did it anyway (though we used PC, not semi). Fortunately better solutions were devised, and they can be used now too. Most of you have access to the edit filter mailing list, I suggest we communicate there rather than spell out our plans here in the open. — MusikAnimal talk 16:39, 20 May 2020 (UTC)

Another idea

Adminbot to apply 6-hour semi (or maybe even an edit filter) to articles linked from the main page with at least three rapid reverts by non-confirmed editors (numbers subject to debate), because if an admin's not around we end up getting a ton of reverts. We could also do this with a user script and click-to-confirm on the actions described above, which I assume would be much less controversial. CC Wugapodes. Enterprisey (talk!) 07:34, 17 May 2020 (UTC)

@Enterprisey: What about a bot that just tags/untags pages with {{linked from main page}}? An edit filter would prevent anyone other than the bot or an admin from adding or removing the template. Then edit filters could be built that only check MP-linked pages, which would vastly reduce FPs. Suffusion of Yellow (talk) 23:07, 18 May 2020 (UTC)
@Suffusion of Yellow: User:MusikBot/TFATagger (which could be expanded for all pages linked on the Main Page). There's a better solution, though. We've been through this sort of thing before, Zzuuzz remembers. Let's discuss on the edit filter mailing list. There was a report about this issue there earlier today, I'll reply to that with my ideas. — MusikAnimal talk 00:40, 19 May 2020 (UTC)
That's a good idea imo. --qedk (t 愛 c) 04:40, 19 May 2020 (UTC)

The best solution

If anything is to avoid this person to go unblocked for 30 minutes[1][2], and leaving the page unprotected. What's the point of warning these IPs and reporting them for edit-warring. They have been doing this since April 20, this is blatant vandalism and not a content dispute. I have already requested the deletion of several of these cross-wiki edits; at first they are denied because it's childish vandalism with no legitimate reason to be deleted. Then, they are spammed and only after that problem persists, they are deleted. That happened with Wikidata:Connie Glynn and Wikivoyage:London, which once again has undeleted vandalism. Just stop playing games with this person, they want attention and you are giving it to them. © Tbhotch™ (en-3). 21:55, 18 May 2020 (UTC)

You will never fill these gaps in RCP. If nothing else is working then the best solution is to take it out of the hands of the recent changes patrollers, and the gaps in patrolling, and place it the hands of an adminbot - blocking or protection or both. I am interested in what Enterprisey might be able to rustle up. also pinging MA -- zzuuzz (talk) 22:28, 18 May 2020 (UTC)
Maybe we need to better communicate to the RCP crowd that LTAs can be reported to AIV on sight. I don't know why, but some people, who are clearly aware of the LTA, always start at level 1 each time they come back with a new IP. Suffusion of Yellow (talk) 22:55, 18 May 2020 (UTC)

I don't know how many of you here are admins, but if you look through my suppression log you will see plenty of evidence, including their character substitutions. User:MusikAnimal, I just blocked another one of those loser IPs. I placed one rangeblock earlier. Drmies (talk) 00:54, 20 May 2020 (UTC)

Hmm, admins can't see suppression logs though. :/ --qedk (t 愛 c) 08:16, 20 May 2020 (UTC)
I don't know if there's some reluctance to this but if this is a case of WP:DFTT as User:Tbhotch suggests, then maybe simply having an adminbot protect the daily TFA for the duration (either Pending Changes or SP, pending changes seemed to work pretty fine at Peresvet) would be the most simple solution. RandomCanadian (talk / contribs) 04:59, 21 May 2020 (UTC)

@Enterprisey:@Ad Orientem: (for the others who might be watching, see also yesterday's drama-free discussion at the Dramaboard) Is there any change in the situation since yesterday? The vandal seems able find what is the next TFA without our help so I'm pointing out that it's Paul E. Patton, in case those interested haven't put it on watchlist yet. I've had a glance at other linked pages but don't notice anything suspicious either so I guess this will be another case of wait and see... RandomCanadian (talk / contribs) 23:06, 25 May 2020 (UTC)

  • The solution is what it has always been. Semi-protect TFA articles starting 12 hrs before they go live on the main page until a few hours after they drop off the page. The main page is itself indefinitely protected for good reason. This should be seen simply as a less extreme and temporary extension of that. But for some reason the wisdom of this recourse has not commended itself to the broader community. -Ad Orientem (talk) 23:13, 25 May 2020 (UTC)
I for one would certainly not object to that, since it seems to be a far simpler solution than having a bot which would require some form of constant updates because of an evolving opponent... RandomCanadian (talk / contribs) 23:22, 25 May 2020 (UTC)
The filter log is already abuzz with quite a few attempts though so far it has worked out (at the risk of catching a few false positives, which in this case is probably not a major issue given the potential). Cheers, RandomCanadian (talk / contribs) 00:59, 26 May 2020 (UTC)
@Ad Orientem: Perhaps we should have a more formal proposal/RfC and consider that. As I think about it, there seems to be a solid case from WP:READER that it's more important to try to ensure readers have a vandalism-free experience reading the TFA than it is to recruit potential new editors via the TFA. It might even be for the best for recruiting — a recently vetted FA is definitely not the best place to make your first edit, and is probably fairly likely to lead to you getting reverted and bitten. {{u|Sdkb}} talk 04:09, 26 May 2020 (UTC)
@Sdkb: Regarding "new editors" - another heavily edited but protected articles (Talk:COVID-19 pandemic) has a nice notice encouraging new editors to try their hand at editing at a less difficult place. Do you think we could come up with something satisfying for TFAs? RandomCanadian (talk / contribs) 04:20, 26 May 2020 (UTC)
@RandomCanadian: If you're referring to the talk page notice there, that was my doing, so glad you appreciate it :). Yeah, I think that's a good idea — something like "this page is protected to prevent vandalism, BUT you can edit here instead." Where would you want the notice to appear? If the page is semi-protected, it'd have no "edit" button for unconfirmed editors, just a view source button. Perhaps we should table this, since it'll only be necessary if the policy is changed. But changes to Template:Protected page text (the notice that appears when you try to edit a page you don't have permission to) would certainly be welcome. {{u|Sdkb}} talk 04:37, 26 May 2020 (UTC)
I would have suggested the talk page but the edit notice is also a very good place. It could also be a custom edit-notice specifically for TFAs (if we want to be precise and helpful), but the eventually updated default template could also do. RandomCanadian (talk / contribs) 04:44, 26 May 2020 (UTC)

Make a bot autoblock users who hit the filter

I think that would be a good idea for a bot to autoblock any users who hit the TFA targeted vandalism #2 filter 🌸 1.Ayana 🌸 (talk) 23:26, 26 May 2020 (UTC)

There have been a few false positives (see the filter and edit history of the last TFA...), this might not be the best course of action. Maybe if the user hits the filter multiple times, then yes. RandomCanadian (talk / contribs) 23:36, 26 May 2020 (UTC)
Extension:AbuseFilter is capable of automatically blocking editors based on filter hits. This functionality is disabled on the English Wikipedia, and for good reason. Wikipedia talk:Edit filter/Archive 1 provides some of the background there, but it basically comes down to human judgement and discretion. Some situations may be better dealt with by a warning, a short block, or a long/indef block, but the abuse filter does not have the ability to make that decision. --AntiCompositeNumber (talk) 00:07, 27 May 2020 (UTC)
This certainly could be revisited, but using the native filter blocking action would be my preference over someone running an adminbot for this. — xaosflux Talk 16:23, 27 May 2020 (UTC)
I was not aware the abuse filter could block editors but i suppose we would need a RFC before enabling it and the false positives are a possible issue as with any filter not sure a RFC is a good idea for just 1 filter to change software so i guess either a adminbot or just regular blocking is better 🌸 1.Ayana 🌸 (talk) 20:12, 27 May 2020 (UTC)
As this problem caused me to learn about the edit filters, I kept wishing that the block feature wasn't disabled. Now that I've actually had to deal with false positives and getting the filter right, it's harder to stomach allowing edit filters to block editors without human discretion. It would be an interesting discussion to have again, but I doubt it would be successful. — Wug·a·po·des​ 00:33, 28 May 2020 (UTC)

Articles illustrated in other Wikipedias

Latest comment: 4 years ago12 comments8 people in discussion

Is there (or could there be) a list of articles that have no image here, but are interwiki linked to articles on another Wikipedia that do have an image, and that image is hosted on Commons? If so could a bot post a message to the talk page of the articles on the list noting this fact and including a thumbnail? The bot would not add images to articles, simply present suggestions for human editors to consider? Thryduulf (talk) 16:55, 13 May 2020 (UTC)

Now that seems like a viable proposal, unlike the one above. Let's have bots that help human editors, rather than try to make decisions themselves that may be bad. Phil Bridger (talk) 18:03, 13 May 2020 (UTC)
I agree with Phil. This sort of tagging would be very helpful. De728631 (talk) 18:17, 13 May 2020 (UTC)
Thirded on this idea. bibliomaniac15 18:22, 13 May 2020 (UTC)
This to my mind is a good idea, but I'm not sure how it'd be technically implemented. Having something simply iterate through all articles that are interwikied to another language, then looking at those articles, evaluating whether they contain images, and if they don't, iterating through every other language that article might be in (potentially many for some articles) performing the same check, strikes me as something that would take a long time and potentially use a lot of resources. And yes, I know, WP:DWAP, but even if the performance doesn't matter on the WMF end, it does for the person running the bot to some extent at least. But this is VPR, not VPT - we can get into that set of weeds later, I suppose! Naypta ☺ | ✉ talk page | 20:28, 13 May 2020 (UTC)
As a first step maybe just looking at those articles tagged as needing an image or which can be improved from an article in another language would be a smaller set. Given that popups tell me how many images an article has I'm guessing that either this is somehow stored in metadata or is very simple to calculate, however that only deals with the total number of images in an article not whether there is a lead image, e.g. the incidental image in Righteousness counts the same as the single primary image in Georgie Thompson. Maybe that means it need only look at the first section? I'm the wrong person to talk to about technical implementation though! Thryduulf (talk) 21:13, 13 May 2020 (UTC)
The popups value seems to be confused by some infobox/template spaghetti. For example, benzyl fluoride pops up as "Stub, 1.8kB, 8 wikiLinks, 0 images, 2 categories, 53 weeks old" but has three images in its infobox. The pg.re.image regexp in MediaWiki:Gadget-popups.js claims to process infoboxes, but clearly some infoboxes are quite complex. DMacks (talk) 05:19, 21 May 2020 (UTC)
I think the bot should tag the articles directly so that they can be automatically added into a category (namely, a newly created subcategory of Category:Wikipedia requested images). The bot should keep track of everything it tags, and never reinstate a tag if reverted (some articles have no images for a good reason). -- King of ♥ ♦ ♣ ♠ 22:09, 13 May 2020 (UTC)
Why would the bot be reverted? It's only editing talk pages, not articles. Either the suggestion would be ignored or it would be discussed and one of three things happen: the suggested image is added to the article (now out of scope for future runs); a different image is added to the article (now out of scope for future runs), or consensus would be against adding the image (in scope for a future run). In all cases the message would remain on the talk page. I agree the bot should not suggest the same image for the same article more than once (I was imagining this being tracked by its own log page or something) but suggesting a different image should not be a problem? The number of articles that are intentionally unillustrated on en.wp but are illustrated with a free image on another project must be so incredibly tiny that a category seems overkill - just exclude the bot from that specific page using {{nobots}}. The bot would need to be told not to suggest placeholder images if any wikis use those, but that is probably best just to just give it a list of file names never to suggest. In terms of frequency, the only reason why a page would get a second message would be if (a) no image has been added after the first one, and (b) a different free image has been added to another language edition of the article since the last run. That's not going to happen that often, even if the bot runs as frequently as weekly. Thryduulf (talk) 23:02, 13 May 2020 (UTC)
Ah never mind, for some reason I thought {{Image request}} was meant to be used on article pages, and just wanted us to do the same here. In that case yes, keep it on the talk page. Anyways, the main idea I wanted to get across is that the bot should be (via the template) adding those pages to a category so that Wikignomes can come in and help. The category needs to be distinct from Category:Wikipedia requested images, as the current task is far easier than obtaining a free image that we don't yet have. -- King of ♥ ♦ ♣ ♠ 23:56, 13 May 2020 (UTC)
Yes, making these pages easy to find is a good idea, maybe something like Category:Wikipedia articles with suggested images or something like that. Thryduulf (talk) 09:37, 14 May 2020 (UTC)
It would be a sub-cat. All the best: Rich Farmbrough 22:07, 30 May 2020 (UTC).

Proposal: Placing a set of different references all under the same title

Latest comment: 4 years ago3 comments3 people in discussion

Would anyone here be prepared to actually make this possible to do? I'll try and show you what I mean:

[ref] Cite web, url=1, url=2, url=3, title=same, work/website=1, work/website=2, work/website=3, accessdate=1, accessdate=2, accessdate=3 [/ref]

The same title for multiple citations. If all citations were accessed on the same date, then obviously you would just use one access date for all citations. Make sense? The reason I'm suggesting this is because it can provide additional verification to both references and a particular source of information. I asked this at the Teahouse and was ultimately referred here by AlanM1. Does anyone else see the same value in creating a template like this? — 29cwcst (talk) 01:10, 28 May 2020 (UTC)


This would be easy enough to do, at least in principle. I presume you are talking about a document that is on more than one web site? We currently have scope for an archive url. All the best: Rich Farmbrough 21:43, 30 May 2020 (UTC).
The URLs are normally displayed with the title, so it would look at bit like this:
Maybe WP:REFBUNDLE would work for you? WhatamIdoing (talk) 21:44, 1 June 2020 (UTC)

Two thoughts about notability

Latest comment: 4 years ago23 comments16 people in discussion

I work a lot on articles relating to history. Recently, I've been cleaning up some articles on people belonging to a family that flourished in Asia Minor of the 2nd century AD. After pruning away the cruft on two of them, I find there's not much there to save. (By "cruft", I mean some redundant & unsourced genealogical statements, & lots of flowery language.) For one, there is the assertion that he is a consul, but I have been up to my elbows in the sources for Roman consuls for quite a long time now (since 2018, at least), & I can't verify that claim with the reliable sources. Once pruned, the article will basically read "A is an aristocrat of the second century living in Perga. His parents are A & B." The other is about his sister-in-law, who is the daughter of a king & the wife of a Roman Senator; her husband is the subject of an article. There should be more information about her, but the records of the time rarely told us more than the names of women -- & often not even that. The first, IMHO, is a candidate for deletion or merging; most civic notables don't meet Notability standards, even if we had a list of offices for them -- & we don't for this guy. I'm mulling on nominating his article for deletion (or merging; either choice will result with the article being replaced with a redirect). As for the sister-in-law, I'm torn: she is someone, if we had access to more information, who might be Notable -- after all, she was in a situation where she could have influenced events. And we need more articles about women. (Her article might end up in AfD, regardless.) All of this leads to a couple of thoughts.

  1. Should we adjust the standards of Notability to reflect the fact that the further back one goes in history, the less we know about people? In some cases, what would be a slam-dunk decision to include in our coverage ends up being a reluctant deletion because we just don't have anything to say about the person. If we allow this, then in theory we could have an article about an average peasant, otherwise unremarkable, simply on the basis he is the earliest person documented to have existed by contemporary records. (Right now, the earliest documented people are kings -- one of ancient Egypt, the other of Sumeria.)
  2. If we do make adjustments based on historical distance back, should we also adjust based on sex? In most societies, there will be less information about women than men: few Roman women have left as much of an impression in history as Livia, Augustus' second wife, & even fewer Greek women. Sometimes we can piece together a sketch of a woman from various hints for those periods, but for most women all we will be able to provide is these 3 barren facts: the names of father (& sometimes mother), the name of her husband, & the names of her known children. (It's a depressing problem to face.)

My intent is not so much to change the Notability guidelines as to hopefully start a discussion about maybe changing them for these reasons. -- llywrch (talk) 19:27, 14 May 2020 (UTC)

  • I would oppose adjusting the standards of notability for the further one goes back in history for the following reason. Wikipedia is probably biassed to things going on in the recent past (the article Criticism of Wikipedia mentions racist and sexist bias, but does not appear to mention recentist bias). There are probably many people in ancient history who are notable (think of characters from the Bible, or ancient Greek philosophers) and we should look at the notability of these people independently of how long ago they lived. The article Criticism of Wikipedia does mention that Wikipedia probably suffers from sexist bias, with not enough coverage of women's issues, so I would oppose adjusting notability guidelines for sex, too. Vorbee (talk) 19:39, 14 May 2020 (UTC)
    • That the article Criticism of Wikipedia doesn't mention recentism as a problem is an omission in that article, not an absence of that problem. This bias has been mentioned before, although after spending an hour searching online this was the only article I could find on the topic. A simple yet effective way to see that this is a persistent problem is to watch the articles under "On This Day" on the Front Page: I am routinely disappointed at how it is dominated by articles on events after 1900. Not that I expect that events in ancient Rome or China should be given the same weight as to events since that year, but sometimes I wonder if the majority of Wikipedians inadvertently think World War I is half way to the deposition of Romulus Augustulus. History books are full of detailed events since 1500, if not centuries before, yet we fail to draw on any of them for OTD. (For example, I remember adding many years ago the date Dante first glimpsed Beatrice -- considered by more than a few a memorable literary event -- but has either person been mentioned at OTD for 1 May?) -- llywrch (talk) 17:51, 15 May 2020 (UTC)
  • Thanks for starting this discussion. I think my problem with the idea is what it buys us as an encyclopedia. Let's say we loosen our notability requirements for ancient women; it seems that you suggest most of the new articles will top out at a few sentences. Wouldn't it be better to mention her in some larger article and redirect the title? Having an article in this situation doesn't really fix our bias unless the definition is simply "articles for men vs articles for women" which is a rather crude metric. We want article on women to not simply exist, but to cover the subject with the same quality and depth that articles on men receive. While the raw numbers are important, the best way to fix the gender bias is to not simply have articles on women, but articles on women that are reasonably well written and useful for the reader. As proposed, it seems like doing this for ancient subjects or ancient woman subjects seems like it will sacrifice one for the other.
    I do sympathize with the proposal, and think that in general we should be more cognizant of how sourcing survives through the ages. For modern subjects, we don't often think about preservation of sources as showing evidence of people being noteworthy since we don't really have that time depth; it's creation of works about the subject that we use as a metric. For ancient subjects, creation is similarly important, but because of the time depth, someone has to actually care enough about the subject to preserve the information and so we should be receptive to that as evidence as well. As a pragmatic stance, I think it's worthwhile in these cases to consider the quality of the article in proportion to its available sourcing. If there's not enough extant sourcing to get us past a stub, then I don't think anyone benefits from it being a separate article, but if the subject has been treated well enough in the limited extant sources to write a C-ish class article, I think we should consider keeping despite the limited resources since humans through history found the individual interesting enough to create and preserve enough information to develop a reasonably well written article thousands of years later. — Wug· a·po·des​ 20:11, 14 May 2020 (UTC)
    • Wugapodes, I think you capture the dilemma I felt when I wrote the above much better than I was able to express it: on the one hand, I want to work towards a balance in content & sometimes feel that the rules prevent me; yet on the other, I lack the information needed to achieve this balance. Sometimes a bit of imagination can be used to make up for lack of information. For example, I've been fiddling with another article, Plancia Magna, where the subject is arguably notable for her civic donations: I believe this article could be properly expanded into C class quality (if not into a Featured Article) by discussing how her philanthropy fits into the ancient practice of euergetism. (At least doing so this article would escape the fate of so many Wikipedia biographies of being carefully pasteurized essays that present only facts, while omitting any opinions let alone insights about the subject.) But to achieve this, we may need to move the dividing line of Notability. -- llywrch (talk) 17:51, 15 May 2020 (UTC)
  • My interpretation of Notability is that we resolved the old inclusionist/exclusionists wars by declaring that it's not for us to decide - it is the world that decides what is Notable. The world Takes Note of something when Reliable Source write about it. Or job is to step back from the topic itself, our job is to evaluate whether the world has Taken Note sufficiently for us to summarize that Note into an encyclopedic article.
    Regarding someone who died a thousand years ago, that means the world has had a thousand years to Take Note and write about them. If that hasn't happened, they're not Notable.
    Regarding women, in a perfect world half of our biographies would be on women. Unfortunately we don't live in a perfect world. And we we can't fix the world. The best we can do is try to make a perfect encyclopedia. A perfect encyclopedia accurately reflects the world as it is, warts and all. The fact is, throughout the world and throughout history, women have rarely had equal opportunity to achieve or be Noted. We can document that accurately, but we can't fix it. If Wikipedia lacks an article on someone notable, woman or not, that article should be added.
    To make the point more dramatically, it's like trying to fix Wikipedia by increasing the number of articles we have on Women U.S. Presidents. If we try to do that we'd be writing fiction. Only the world can do that.
    As a person I support various social progress and improvement. As an editor, my policy-analysis shouldn't change to fit my personal opinions and desires. Alsee (talk) 11:46, 15 May 2020 (UTC)
    • I tend to disagree with that. A perfect encyclopedia accuratelly reflects the world as it is. This is not necessary true, that is not the "perfect" encyclopedia, it is maybe an encyclopedia most useful for journalists and corporate employees. The perfect encyclopedia would be different and we COULD be creating it, we COULD have half of biografies on women. We COULD have more articles on eastern, soutern etc topics, we could do all that. But we would need better policies and we would have to take some responsibility. The current use of notability, OR and foremost RWG policies is just reproducing sexual, racial, class, systemic etc biases and is preventing use to create a perfect encyclopedia. And "the world" is just an exuse. Ludost Mlačani (talk) 21:24, 17 May 2020 (UTC)
  • I strongly support adding some consideration of the age of a figure to the notability guidelines. It's always struck me as a misplaced emphasis on "rules" over "building a better encyclopaedia" when articles on minor historical figures get deleted for notability concerns. Notability has two main purposes. One, to place some limit on what we cover, and exclude insignificant, unencyclopaedic topics. But if verifiable information about an individual has survived for hundreds or thousands of years, even if it's only one or two facts, they are surely significant and worthy of encyclopaedic coverage. The second purpose is to ensure a minimum standard in how we cover a topic, i.e. to avoid articles that will never have the "breadth of coverage expected from an encyclopedia". But here I think "breadth" has to be judged relative to the topic. If all that is known about a historical figure can be summarised in a few sentences, then those few sentences can be satisfactorily encyclopaedic coverage. Even a stub saying just "Marius Panemus was a baker in Rome in 67 AD" will be helpful for many readers and can provide useful context for other articles. – Joe (talk) 12:31, 15 May 2020 (UTC)
    • I agree. I get the impression that many of those who claim that the "breadth of coverage expected from an encyclopedia" is more than a sentence or two for anything except the most important topics have never seen an old-fashioned print encyclopedia. Most entries in such encyclopedias are very short, so why should Wikipedia be any different? Many people seem to judge rules to be more important than the simple question "would a comprehensive encyclopedia be expected to have an entry for this?" Phil Bridger (talk) 16:44, 15 May 2020 (UTC)Phil Bridger (talk) 16:41, 15 May 2020 (UTC)
    • Joe Roe, you've touched on two issues I've noticed that have become more apparent since I started back in the Wikipedia Stone Age around 2002: (1) An increasing number of contributors have never seen, let alone read widely in, one of the universal encyclopedias that were common before the Internet took off. While some did have thoughtful & well-written articles, the majority of the content of them was not as well organized or as complete as what Wikipedia usually provides -- & I'm saying that while freely admitting much of Wikipedia still sucks. (2) The belief that the longer a Wikipedia article is, it must follow that it is better than a short article. (It is true in many cases longer is better because it means there is more information, but concisely-written articles always delivers more information in a more accessible form.) Sometimes all that one needs to know about a subject can & should be presented in a few sentences. -- llywrch (talk) 17:51, 15 May 2020 (UTC)
  • I agree with others here regarding the quality over quantity of articles on women. For an ancient senator's wife—is it really even her article if she is defined entirely by her relationship to other (male) people? I also wonder if this can't also be applied to current "notables" whose only achievement is their pedigree. There was a discussion recently on inappropriate title-bombing for people who have never been given or even inherited an extant title, and several of the articles in question are completely devoid of information other than who their wife's great-grandfather was or whatever. I think it'd also ease the recency bias if we approached it from the other direction and were more discerning on what or who is due an encyclopedic article. JoelleJay (talk) 18:42, 20 May 2020 (UTC)
  • I would generally suggest that permastubs that exist because precisely one line of information can be gleaned about a figure from the whole of the historical record should be merged into a list article of similar permastubs on people from the same region and era. BD2412 T 03:57, 21 May 2020 (UTC)
  • I agree that if a historical figure meets some form of a notability guideline but there's little coverage on them, then we probably shouldn't dedicate a full length article to them. This can be difficult even for relatively recent characters, if they date back from a time before internet..., example: a WWI Brigadier-General; a post-WWII ship commander. A list (or inclusion in the article of a closely related person), such as User:BD2412 suggests, could be appropriate, especially for some of the more obscure figures. The overreaching criteria is of course WP:GNG - I'd argue that if there's very little coverage of them (read: nothing more than "they existed" or "they were the [relation] of [notable person]" (see also WP:INHERITED) then we should probably not include an article... RandomCanadian (talk / contribs) 16:43, 23 May 2020 (UTC)

This item has inspired me to air my current beef re notability. Since when is an article in the Australian Dictionary of Biography not deemed reasonable evidence of notability? I have recently had two articles on minor Australian explorers, supported by information from the ADB and other documents, rejected as “Not notable”. While this attitude remains a whole group of “second-tier” people who helped to open up this country and fill the often large gaps left by the well-known explorers will remain largely unknown. Downsize43 (talk) 03:34, 24 May 2020 (UTC)

I think that we can all agree that "notability" is a vague concept and that it has some (or many) failings... The main concern when creating articles should be whether there is sufficient coverage in sources which indicate that the topic in question is worthy of mention (beyond it simply existing). In short, WP:GNG, everything else is just "presumptions" which can be false. Sometimes, depending on the sources, this can require many, and sometimes one really solid source (such as, say, an entry in the ADB, or, in my currently preferred subject (hymns), an entry in an authoritative publication) is also plenty enough). RandomCanadian (talk / contribs) 04:22, 24 May 2020 (UTC)
  • Just because a person isn't notable enough for a standalone article doesn't mean we can't include something about them in the encyclopaedia, especially in sourced list format. I also think notability is read a bit subjectively - in theory, a historical person's biography is less likely to be deleted than a BLP. SportingFlyer T·C 07:57, 24 May 2020 (UTC)
a side issue, but the Australian Dictionary of Biography explicitly includes articles about people whom they think not notable, but representative of ordinary people in their mileu. I can understand theit purpose, and do not necessarily disagree with it, but it doesn't match what we mean by notability . ". In it you will find concise, informative and fascinating descriptions of the lives of significant and representative persons in Australian history....The subjects come from all walks of life ... providing a cross-section of Australian society.....ADB prides itself on its blend of elitism and egalitarianism." [3] DGG ( talk ) 18:04, 26 May 2020 (UTC)
I've always thought that there are two good things we can do with articles on non-notable subjects (other than delete them) - one, as suggested above, is to put the content on a suitable aggregation page, always leaving a redirect as both a salt and a valid link. The other is to make an exception, where the article is one of a set where almost all are notable. It may be that the latter can always be transformed to a case of the former, but if not I think it is a useful and valid exception. All the best: Rich Farmbrough 22:52, 30 May 2020 (UTC).

@SportingFlyer: The articles are:

Downsize43 (talk) 01:13, 31 May 2020 (UTC)

  • @Downsize43: As an AfC reviewer, I think I'd decline both of those. Parr does not have an entry listed in the biography linked in the article, and the one article that is about him is a 404 - page not found. Singleton does, but he doesn't have any other sources that aren't the national biography. A quick search brought up nothing, which makes sense - I thought if I could add another two sources quickly they could be accepted. If having a biography means you're automatically notable, then the pages were declined in error, but still could be improved. I don't think they're all that far off. Hope that helps! SportingFlyer T·C 04:37, 31 May 2020 (UTC)
Well, I'm not a local librarian but certainly Google is better with more recent topics than with historical ones which are more likely to appear in offline sources. And I can see why people might be so-and-so on our current notability of the draft articles of Parr and Singleton. But when you are writing Australian history, you do find certain names popping up time and time again, not as the primary person, but they are constantly there in the background of many stories. In Australian history, we inherited a British class system and that brings a certain "lens" to our history, so the achievements of upper classes would be reported as the primary topic while the achievements of others involved of lesser birth would be mentioned in a secondary manner. So I think we do have people in Australian history who do not appear as primary topics (which GNG expects) yet have been part of many significant achievements/events and do have a story worth telling and the sources clearly exist to tell that story, albeit not as the primary topic in those sources. I think for historically under-represented groups, we do have to accept that they are less likely to appear as the primary topic but that frequent appearance as secondary topics should add up to an acceptable level of notability. Kerry (talk) 03:31, 3 June 2020 (UTC)

New template to make Wikipedians more aware of proposals for new WikiProjects

Latest comment: 4 years ago12 comments7 people in discussion

I have a proposal which is intended to make more people aware of new WikiProject proposals. At Wikipedia: WikiProject Council, I have made a proposal for a WikiProject Mysticism, and there is also a proposal for a WikiProject Justin Bieber. If one goes to the article on mysticism, one can see that information about the relevant WikiProject proposal is on the talk page, and the same goes for the article on Justin Bieber. My proposal is that, when there are proposals for new WikiProjects at Wikipedia: WikiProject Council, there is a template heading the main article (not just the talk page) on the relevant subject, saying something to the effect of "A proposal has been made at Wikipedia: WikiProject Council for a WikiProject on...."" This might help people to become more aware of new WikiProject proposals. Vorbee (talk) 17:28, 13 May 2020 (UTC) At Wikipedia: WikiProject Council there are proposals for a WikiProject Hausa and WikiProject Brass Bands. If one goes to the articles Hausa people and Brass band, one will see that information on the proposals for these WikiProjects is not even on the talk pages. This, I feel, strengthens the case for such a template. Vorbee (talk) 19:48, 13 May 2020 (UTC)

This is a very good idea and I am in support of it if we enlighten people about wikipedia project we will get 98% of the wikipedia undone project done so let do it. Very great idea.Tbiw (talk) 08:10, 17 May 2020 (UTC)
Articles should only have banners pertaining to the content of that article, not information about Wikipedia's background processes. By all means put such proposals at the talk page of course. Fram (talk) 08:18, 18 May 2020 (UTC)
I agree with Fram. Banners on the article should be exclusively related to content matters that affect that article - e.g. issues with sourcing, proposals to merge or split, current nominations for deletion, {{current}} and the like. WikiProjects, GA/FA discussions, old discussions, mentions at ITN, and other process or meta issues belong on the talk page. Thryduulf (talk) 10:06, 18 May 2020 (UTC)
  • Thank you for your feedback. I appreciate that Wikipedia may have a policy of only mentioning WikiProjects on the talk page, but does any one think that such a template could head the talk on the talk page of relevant articles? Vorbee (talk) 18:36, 18 May 2020 (UTC)
gibberish
Wiki project should be more advanced we on know that wikipedia project are grouped such as one for football is different and others. Article writing is about what you know,see and hear. Do when you send this template you gonna ask them I you willing to write an article then if yes choose which you wish to write. If may then leave it alone. When those who answered will be tagged voluteener of wiki project and the name or as we maintain a article grouply then let's write article groiply. To make more article archived. Tbiw (talk) 08:26, 19 May 2020 (UTC)

I had a look at the User Page of the User who left the last command, and see that English is that Wikipedian's native language - I did wonder about that, as the last comment was not written in very clear English. Vorbee (talk) 11:41, 22 May 2020 (UTC)

I guess what I am asking is how to make people aware of proposals for new WikiProjects at Wikipedia: WikiProject Council - there are probably many Wikipedians who have never seen that page on Wikipedia. Vorbee (talk) 11:41, 22 May 2020 (UTC)

Am very sorry for using not understandable language,errors and blunders,jargon which was tagged gibberish . Sorry all wikipedians for that mistake . It is a great mistake sorry for that . Tbiw (talk) 15:39, 23 May 2020 (UTC)
  • The talk page of the relevant parent wikiproject (e.g. WP:WPMU) would be a more appropriate place for a notice about a proposed new wikiproject (than the talk page of a specific article). DexDor (talk) 19:13, 24 May 2020 (UTC)
    • User:Vorbee, I don't think that you need a template. I think you should just leave a plain old message on the talk pages of highly relevant articles. Remember, too, that if you add a template, you will have to go back later to remove it, but if you just post a message, the normal archiving processes will handle it for you. WhatamIdoing (talk) 21:08, 1 June 2020 (UTC)
This is a great idea. It would be very helpful. Ludost Mlačani (talk) 17:36, 3 June 2020 (UTC)

Proposal: New Village Pump Page

Latest comment: 4 years ago44 comments27 people in discussion
There is clear consensus for a communication page with WMF to be created along the lines suggested by Alsee. I hope that the WMF will understand the thinking behind the page, and engage with it. Attempts I made last year to get WMF to engage with the idea that communication between en.wiki and WMF should happen here on en.wiki not in room 13 down in the basement of WMF's outpost in Timbuktu met with an enthusiastic response of how they are thinking of putting a light bulb in room 13 in order to assist the folks in en.wiki to read the notices they post there. If this proposal gets off the ground, and WMF does engage with it, and it's still going in 12 months time I will send Alsee a bottle of their favourite drink. SilkTork (talk) 14:28, 8 April 2020 (UTC)

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

There has been a long recognized need for improved communication and coordination between the community and the Wikimedia Foundation. Too often Foundation plans have come as an unexpected and unwelcome surprise to the community. Too often community concerns or objections have come as an unexpected surprise to staff members. Better communication and collaboration would reduce the rate of conflict and failed projects. Staff members are generally enthusiastic about our public service mission, have good intentions, and want to help us. However to be frank, most of them know about as much about what goes on over here as most of us know about what goes on inside the Foundation. They are employees in a conventional top-down authority structure. Most of them have no experience in the community, and our consensus system is alien concept. Sometimes they struggle to understand how we work, what we want, what we need, and even how to talk with us effectively. There is a communication and culture gap.

I have seen positive efforts from the Foundation over the last few years. However I believe both sides need to work to bridge the communication gap. I have some ideas, and it begins with this proposal to create a new village pump page. The current Draft Village Pump Page header reads as follows:

  • The WMF section of the village pump is a community managed page. Editors or Foundation staff may post and discuss any information, proposals, feedback requests, or any other issues of significance to both the community and the Wikimedia Foundation. It is intended to aid communication, understanding, and coordination between the community and the Foundation.

There is currently a Pump Proposal open above, asking WMF Legal to enforce the Terms of Use against an abusive company. That is a prime example of kind of topics I envision for the new page. The Central Notice template also currently lists an RFC for the Foundation's rebranding strategy to rename itself from Wikimedia to Wikipedia. As part of that project they evaluated the level of community support and produced a report, which I believe has been delivered to the Board of Trustees. The report states Measure community appetite for change: ✓ 0.6% of informed oppose. The 0.6% oppose figure is in rather stark contrast to the over 92% oppose on the RFC. I have several other examples of confirmation bias in Foundation's gathering or handling of data. I believe bad data has contributed to some of the tensions between the Foundation and Community. The RFC page also has a Statement by the Foundation. Given how the RFC is going, I believe it is clear that the staff handling the project do not grasp the significance of the RFC.

I have long been following Foundation projects, plans, and strategy. I have a small pile of similarly significant topics for the new page, including matters of past and future Foundation strategy. As some of you may be aware the Foundation has finally given up on the Flow project, and a Consultation resulted in a decision to keep and enhance existing Talk pages. I am concerned that the enhancement project is going off course. For example, like Flow, the project has a design flaw that can result in wikitext content corruption. The manager has indicated that he considers it an insignificant matter, not worth fixing. One of my priorities for the new Pump page will be to provide more detailed information on the new Talk Page Project. I hope to bring that team helpful information on our needs, concerns, and expectations for any major changes to Talk pages.

Over the years I have had discussions with several top managers, with the previous Executive Director, and with the current Executive Director. I believe the Executive Director would be receptive if we produce some consensus message regarding Foundation strategy and engagement. That is beyond the scope of the immediate proposal.

Proposed: Install Draft Village Pump Page. The page may of course evolve based on comments here or later. Alsee (talk) 12:04, 29 January 2020 (UTC)

Responses (NEW VP)

  • Support as proposer, per the rationale above. Alsee (talk) 12:04, 29 January 2020 (UTC)
  • Support Additional communication is a good thing! This makes hella sense! GenQuest "Talk to Me" 12:53, 29 January 2020 (UTC)
  • So another village pump page that most people won't watch? Much less WMF? Nah. --Izno (talk) 15:08, 29 January 2020 (UTC)
    Izno... Can you come up with a better suggestion? We do need SOME way to facilitate more communication with the WMF. Blueboar (talk) 15:20, 29 January 2020 (UTC)
  • Comment Previous discussion: Wikipedia:Village pump (proposals)/Archive 130#New Village Pump page?. Anomie⚔ 15:23, 29 January 2020 (UTC)
  • Support concept, but in practice, this will need buy-in from the WMF - if they don't use it, then there's no point. creffpublic a creffett franchise (talk to the boss) 15:32, 29 January 2020 (UTC)
  • In my opinion, such a thing is better placed on the Meta wiki; that's where the WMF does most of its work and it would make this venue usable for non-enwiki projects as well. Jo-Jo Eumerus (talk) 15:47, 29 January 2020 (UTC)
  • Support as beneficial, even a less active Village PUmp page would be seen more then the current set-up which is basically "meta pages only seen by a couple of keen souls. They panic and dump on CENT after a significant delay". The only other action that could provide a substantial assistance would be something akin to Tech News "WMF Newsletter". The issues with this are threefold: you'd need about 200 sign-ups to get reasonable awareness; you'd need several active people to run it reliably; some major WMF discussion areas would need much quicker response times than (a max) 30 days to give a chance for proper discussion. Nosebagbear (talk) 15:53, 29 January 2020 (UTC)
    Summoning @Whatamidoing (WMF):... — xaosflux Talk 16:13, 29 January 2020 (UTC)
    User:Nosebagbear, rather than creating Yet Another Newsletter that nobody reads, the English Wikipedia would probably find it easier to promote the WP:Wikipedia Signpost, which already has the subscribers, and which could be a reliable source of information that mattered to this particular community. Whatamidoing (WMF) (talk) 23:45, 30 January 2020 (UTC)
  • Support concept per Creffpublic's similar comment above, but Jo-Jo Eumerus has a good point too. Ivanvector (Talk/Edits) 16:57, 29 January 2020 (UTC)
  • Strong support Regarding Jo-Jo Emerus's comment; Meta is where the WMF does most of its work, but the problem with discussions on Meta is that members of the individual communities rarely go there and can easily miss important discussions. Having a page here to discuss things with the WMF makes it easier on the community. Such a page can house links to important discussions that are taking place on Meta, thereby driving traffic there. ~ ONUnicorn(Talk|Contribs)problem solving 17:05, 29 January 2020 (UTC)
  • Support Having a dedicated page for communication with the WMF seems like a no-lose proposition. I think it needs to be two-way; people should be able to post questions for, and expect answers from, Foundation personnel, and the Foundation should also be expected to make announcements for the community, using the page. I can't think of a downside to this proposal. --Jayron32 17:08, 29 January 2020 (UTC)
  • Support A direct way to see WMF related proposals, and for clear, one on one communication with them? Yes please! This would, hopefully, greatly help with places where the WMF clearly didn't get proper consensus, and would allow for us to bring proposals their way in a place everyone would see. --moonythedwarf (Braden N.) 17:24, 29 January 2020 (UTC)
  • Support in principle per Creffett. I would love to see this happen. Our best chances for greater two-way communication with the Foundation may be by raising it as an issue in the Board of Trustees election. EllenCT (talk) 19:13, 29 January 2020 (UTC)
  • Support - Having a centralized enwiki discussion forum for interacting with WMF would be beneficial. I hope that WMF agrees. - MrX 🖋 13:06, 30 January 2020 (UTC)
  • Oppose. On issues for which the WMF is completely non-responsive, I don't think having a dedicated board would make them willing to respond. On issues where they are willing to respond, they're frequently willing to participate anywhere, unless it's a cross-project issue, in which case they'll sometimes only interact on Meta. The WMF has given no indication that they'd be more willing to use a dedicated forum. The task of dragging the WMF into areas where we can have some level of mutual awareness is going to take a long time. The WMF has the ability to communicate things well, they even use a wiki internally to host things like every team's weekly report (which they won't let us see, or comment on), but as far as I can tell, they just don't want to allow that much WMF-community interaction, for reasons unknown to me. --Yair rand (talk) 01:08, 31 January 2020 (UTC) seems fine, but
  • Oppose, I wonder, why the enWP, who already is the center of the anglocentric WMF, is complaining, just go to Meta, unfortunately for the non-anglophone projects they seem to speak only english over there. This sounds to me more like a venue, whre the WMF can pretend to talk with the community, while they are talking just to a tiny peace of the community, bur one that conveniently speaks the only language they seem to know. Grüße vom Sänger ♫ (talk) 05:19, 31 January 2020 (UTC)
  • Support concept but different name and framing WMF communications happen in a decentralized way and there are regular disagreements about what WMF representatives communicated effectively and what was hidden in some out-of-the way area. I support the idea of centralized posting but think it should be either outside the village pump, or if listed with the village pump boards, then it should have a different name and branding. WMF communications are different because everything that organization does is entangled with money and someone's career, and consequently much of that organization's activity here is in a conflict of interest with some individual or team's financial livelihood. The interests of the Wikimedia Movement and the Wikimedia Foundation often diverge, and staff of the Wikimedia Foundation are not part of the Wikimedia community in that they each have a commitment to serve the interests of the Wikimedia Foundation as an organization and favor that organization in the case of any conflict between the Wikimedia Community and that organization. The reason why the village pump is not the place for WMF discussion is that the village pump is established as a community volunteer space. Instead, I think the right board for the WMF would be something like a Wikipedia:Local Embassy, where the WMF sends its diplomats and negotiators into English Wikipedia space to negotiate something. Maybe the WMF should set up embassies wherever it would log its efforts to establish agreements with a local Wikimedia community. The idea of a central space is great. We should distinguish ideas and proposals from the WMF from ideas and proposals from Wikimedia community volunteers, though. Blue Rasberry (talk) 19:57, 31 January 2020 (UTC)
  • Support concept. I am a little concerned that not all the messages that would be posted to such a board would actually be matters that require the attention of the WMF. There should be norms established that if inappropriate content is added, it can be moved to a different pump page. Sdkb (talk) 21:29, 2 February 2020 (UTC)
  • Support the concept... but I ain't holding my breath on this being useful if the WMF decides to have a rerun of the Fram and Flow Show. —A little blue Bori v^_^v Onward to 2020 23:43, 3 February 2020 (UTC)
  • Dont mind, but don't think it will approve communication of either the foundation or the community one bit. The problem is not the amount of locations to discuss, its that there are too many stakeholders with too many different opinions and too many thing happening to keep track of no matter what you do. —TheDJ (talk • contribs) 09:18, 6 February 2020 (UTC)
  • Support Concept per above, especially Creffet and EllenCT. Puddleglum 2.0 20:29, 7 February 2020 (UTC)
  • Support this idea for now. Anything to open constructive communications seems fine. I would like to suggest we review the actual results later. a channel to discuss things with WMF seems fine, but we should also hjave the option to look at other methods later, if this new idea doesn't have the full effect desired. --Sm8900 (talk) 04:28, 10 February 2020 (UTC)
  • Support the concept of constructive communications with "norms established": I am one of those that very rarely "go there" (Meta), and think comments to "just go to Meta" are out of touch, as I imagine many also don't "go there". I think there would be community benefits in this proposal and help others not "easily miss important discussions". We "advertise" to get involvement so why not have a local centralized place? Will the WMF get involved or "buy-in"? I don't know, but I will continually assume good faith that others will do the same. If true, the comments "WMF is completely non-responsive" might be a reason that a collaborative effort (and a fairly large show of support), will hopefully gain more involvement ("WMF-community interaction"), and "might" be a game changer, or not. We will never solve issues or find solutions by just complaining and not trying. I do not know anything about "anglocentric" concerns (Is this a real problem and how is it really relevant here?) the WMF "might" be complaining about. I assume enWiki is among the more active projects. I cannot help where I was born (demography of the editors), but this is where I am, and I imagine that is true for the many on this project. The WMF has to understand that it is not the fault of any considered anglocentric that broad community involvement somehow created some sort of bias. I want to see worldwide involvement but I only speak English so my endeavors, that consume most of my free volunteer time, would very logically be focused here, so I "favor this organization" for obvious reasons. The WMF and the other projects need to worry about their end. On this "end" I would like to see better communication (dedicated forum?) and support anything in that direction. Maybe a new tab here, or another supported location, but I don't see that Wikipedia:Local Embassy ("Wikipedia-related multilingual coordination") would be proper. If the WMF is picky about what involvement they wish to be involved in, then at the least, we can have a central location for discussions and potentially important news, as well as hopefully collaborative communication. Any thoughts that we possibly somehow shouldn't continually make attempts doesn't seem logical. Otr500 (talk) 17:41, 11 February 2020 (UTC)

Discussion (NEW VP)

Jayron32, you used the phrases 'expecting answers' and 'expecting announcements' from the Foundation. I want to emphasize that this is a community page, and creating a community page does not create any particular obligation on the Foundation. An appearance of imposing an obligation or responsibility onto the Foundation could raise objections and resistance. The new page is a workplace for us, and I wish us to extend an open invitation to the Foundation utilize the page. I hope and believe they will accept that invitation (likely with hesitation and fear, as conflicts have been painful for both sides). The only expectation on the Foundation is that they continue their existing efforts, and I have hope that we can help work towards improvement. Alsee (talk) 22:05, 29 January 2020 (UTC)

See, I still feel that is backwards. Wikipedia and the en.wikipedia community does not exist for the purpose of supporting the whims of the Foundation. The Foundation exists to support the work of the volunteers and the various communities of the Wikipedia movement, and increasing and improving communication between the Foundation and the communities it serves is what we should be focusing on. We should not be focused on being better foot soldiers blindly following whatever mission the Foundation has decided to set us upon, we should be expecting and receiving support from the Foundation for the purpose of building an encyclopedia. Where conflicts have been painful have been where the Foundation has acted unilaterally and in its own interest without regard for the interests of the Community. The expectation is, the Foundation should seek input and advice from the community on major issues, and that the Foundation should be willing to respond to legitimate concerns from the community. If they are not willing to do either of those things, the noticeboard is pointless. --Jayron32 12:40, 30 January 2020 (UTC)

I will pass along a link to this discussion, but I think I can predict some of the questions I'll get, so perhaps some of you would like to start answering them now, just in case:

  1. Why do we need a single, separate page? Why not have all of us talk on whichever pages are relevant? At least some of you have figured out how to ping me ;-) and if that's too hard, we could always create a generic {{ping the WMF}} template. Having a discussion half at one page and half at a "Village pump (WMF)" sounds like a WP:CENT problem. On the other side, imagine that the WMF is offering hackathon scholarships to bot operators. Why should that be announced at a special "WMF" page instead of at WP:BOTN? Have you thought about the signal-to-noise problems in the movement? The main problem isn't a lack of information. It's finding the thing you care about in the middle of all the things you don't care about.
  2. What's the specific purpose? Specifically, is it primarily one-way information from editors to the WMF, primarily one-way information from the WMF to (some) editors, primarily discussions to exchange views without trying to make decisions, or is it primarily a location for decision-making? I see comments above that seem to believe each of those four. Forums that try to do all of the above usually fail at achieving most of them.
  3. Why shouldn't this online community join all the other online communities in central locations (such as Meta)?
    • The Working Group volunteers for the 2030 Strategy discussions say that we should be integrating the movement across all the online and offline communities. This proposal is for more separation, elevating the status of one online community and one movement organization.
    • To give a concrete example, I see elsewhere on this page that the OP still thinks that the WMF is planning to cram the visual editor down our collective throats. Why shouldn't we be talking about which editing options to offer in a central place, so that people like User:Sänger, who has been asking the Editing team to enable the visual editor on talk pages for years now, can join the conversation and share his insights? (Sorry, Sänger, they're still saying no.)
  4. Do you really understand that it's not just the WMF that you need to deal with?
    • The Strategy folks are advocating for a smaller role for the WMF and decentralized action. This proposal seems to be focused on a single organization, when editors at the English Wikipedia need to be talking to many.
    • For example, WMDE is finishing up a project that will change the <ref name="Alice"> syntax to do something similar to the {{sfn}} templates. I'm not taking bets on how long it will take for someone to complain that "the WMF" did this "unwanted" work (which was democratically selected through a public, on-wiki voting process), but I do want to point out that if you're setting up a page for just the WMF, you are excluding all of the (multiple) organizations whose activities affect us here.
    • To give another example, see https://discuss-space.wmflabs.org/c/events/13 for a list of 300+ events that have been announced in the last few months. Many of these are editing events, which have a direct effect on New Page Patrollers and other editors. Very few of those announcements are from the WMF. This trend is going to continue: more events, and more articles about people, places, and things that the average English Wikipedian has never heard of. You might want to hear about them, and a WMF-focused page won't tell you about any of them, because the WMF isn't running those events.

There will probably be other questions, but perhaps these would be a good starting place. In terms of a response, I predict that the WMF's managers first thought will likely be that they're hiring someone to create something called a "strategic communications plan", so nobody should make any final decisions today. (My own personal thoughts sound a lot like https://xkcd.com/927/ – namely that it would be convenient for me if a single forum could replace all the others, and if people would actually pay attention to it [even though most of it would be irrelevant to them], but I do not expect that to happen.) Whatamidoing (WMF) (talk) 23:41, 30 January 2020 (UTC)

Whatamidoing (WMF) You mentioned above the global watchlist work; and here you list several items that can be summarized as, "people should use Meta". One thing I'm thinking this would be useful for is as a repository for links to important discussions happening on Meta. Because if there is a discussion happening on Meta, but people who would be interested aren't aware of it, they aren't going to participate. A global watchlist to remind you to check up on developments with discussions you are interested in on Meta is only useful in as much as you are aware of the discussion and have added it to your watchlist. People on en wiki are constantly surprised when action gets taken as a result of a discussion happening on Meta that affects 100% of the en wiki editing community, but less than 1% of the community was even aware the discussion was occurring. The end result is that the WMF looks like the Vogons in Hitchiker's Guide to the Galaxy.

“There’s no point in acting surprised about it. All the planning charts and demolition orders have been on display at your local planning department in Alpha Centauri for 50 of your Earth years, so you’ve had plenty of time to lodge any formal complaint and it’s far too late to start making a fuss about it now. … What do you mean you’ve never been to Alpha Centauri? Oh, for heaven’s sake, mankind, it’s only four light years away, you know. I’m sorry, but if you can’t be bothered to take an interest in local affairs, that’s your own lookout. Energize the demolition beams.”

My thought is that the board could be used to post announcements about discussions happening on Meta, with reminders to discuss this there. ~ ONUnicorn(Talk|Contribs)problem solving 14:57, 31 January 2020 (UTC)
ONUnicorn, a page for links to relevant discussions (more than fit in CENT) could be created by any interested person. It already happens in some other communities, and there's no reason why you couldn't do the same here if you wanted to (e.g., w:de:Wikipedia:Projektneuheiten, which is specific to technical changes, or w:fr:Wikipédia:Annonces, which is general news). Subject-specific pages might improve the perceived signal-to-noise ratio for readers. I recommend against making it WMF-specific, as this community is affected by far more organizations and individual-led projects than just the WMF. You might want to talk to the Signpost about this, as they have some experience with announcements, and they already have an audience.
It won't solve the problem that most people won't read it (or remember what they've read). I've manually posted messages to more than a hundred high-traffic pages, and run site-wide banners to 100% of logged-in editors for weeks, and still had editors say they never heard about it; I've seen a CENT-listed, month-long RFC here at VPPR, with 20+ editors supporting it and nobody opposing it, get overturned because some other editors didn't notice the RFC; I've even seen someone actively participate in a discussion on wiki, and then ask a month later why nobody ever discussed the subject. There is no way to make people read and remember everything that's relevant to them. But the fact that it won't be a total and perfect solution doesn't mean that it's not worth doing it at all. Whatamidoing (WMF) (talk) 20:45, 31 January 2020 (UTC)
Whatamidoing (WMF) I find it ironic that you come here opposing the new page and apparently blaming me regarding the WMF cramming the visual editor down our throats. It's ironic because, on exactly the issue of WMF's VE throat-cramming, you are responsible for letting us get to the brink of second Superprotect-level crisis. In case you don't recall you were liaison for the Single Edit Tab (SET) deployment. I told you that the manager explicitly assured me it would NOT be deployed as VE-default without a community consensus. I repeatedly asked you weather the the product was going to deploy with a VE-default. I presented a pattern of evidence that the product was about to deploy with a VE-default. Your responses and denials on the subject turned out be... unhelpful and untrue... that is the most generous way I can put it. Furthermore the manager on the project later asserted surprise at the issue... suggesting that either (1) you failed to ask or mention the issue with staff or (2) the manager was lying. I will not speculate between those options. In any case, the project for which you were liaison was in fact deployed with a VE-default. Exactly as I anticipated. Exactly as I repeatedly brought to you in advance. After deploying the VE-default the Foundation went non-responsive for well over a week, despite attempts to reach the Foundation in multiple places including the manager's personal talk page. We only got a response when I escalated the issue to the Executive Director's talk page! She had to summon the manager to give an answer. The manager gave us assurances that it was a bug and that he would fix it. More than a week went by with no action. We went back to the manager and he told us that VE-default was always his intention and he had absolutely no intention of fulfilling his promise to change it. At that point things went from ugly to obscene blatant bad faith. He was outright called a "liar", and ANI decided that "liar" was not uncivil given the diffs of his own words. A community member then wrote a hack for the sitewide javascript to change the default. The community members involved were acutely aware that hacking the sitewide javascript to explicitly override a manager was putting us on the threshhold of repeating the Superprotect incident. Note that the manager said it was a bug - so either the javascript hack was an undisputed bugfix or the manager was acting in deceitful bad faith. Either way the editors involved considered the javascript absolutely justified. At that point the manager finally agreed to fix the default-editor from his end, as he had promised to do a week earlier.
Whatamidoing, I respect your work and experience and expertise and dedication as a community member. However as a liaison your job was to prevent any of that from happening. I persistently attempted to ask you and warn you, attempting to head off the impeding problem. The reason I want this new Pump page is because you and other staff consistently ignore my accurate warnings that manure is about to hit the rotary air-mover. I am trying to tell you that there are a whole series of fans spinning right now. Maybe I'm overly optimistic, but I'm hoping the new page will help us sort out issues before they escalate to crisis. I hope the page will help us get moving in a common direction.
To minimize WallOfText I'll limit my reply to that one subject. Oh, and Spoiler Alert, the Foundation is about to release hard data on how badly a VE-default reduces edits. Alsee (talk) 18:36, 31 January 2020 (UTC)
Last I checked, I still hadn't been appointed queen of the wikiverse. (I'm sure it's just an oversight. ;-)) However, until that happens, I can't actually prevent everything that I'd like to prevent, any more than I can force someone to build the things that I want built (e.g., phab:T89970).
The movement might need a clearer understanding of which groups ultimately get to make which kinds of decisions, and specifically where the English Wikipedia's editors fall in a typical responsibility assignment matrix for different kinds of projects undertaken by outside communities. Are you supposed to be "informed" or "consulted" about projects that affect you, but the people responsible for the project get to make the decisions? Or do you see yourself as the ultimate "approver" or "decider", with veto power over everyone else? The volunteers in the Strategy Working Groups have proposed that a movement charter be written to clarify some of these points of contention. Perhaps having a document that explicitly says something like "An online community {can|can't} veto a project that affects that online community, but which was undertaken by another group" would forestall some of these disputes by preventing all sides of any dispute from thinking that their side has the ultimate decision-making authority. Whatamidoing (WMF) (talk) 21:24, 31 January 2020 (UTC)
But the Foundation did appoint you queen of Single Edit Tab liaising. You do an excellent job as liaison - until the Foundation agenda is questioned. At that point you tend to cease liaising. That doesn't serve the community or the Foundation. I can't decide whether it's better or worse than a liaison who lacks your community knowledge and understanding. The job should be to facilitate communication, understanding, and collaboration between the Foundation and the community. One of the most important things is to alert staff of any issues that may negatively impact their work, especially any potential or actual opposing consensus. Those staff then need your expertise and help to reach a viable resolution. Too often such situations go unacknowledged until too late. Most staff don't seem to have have the mandate or understanding to constructively engage that kind of situation. That leaves us with unconstructive approaches and bad outcomes. The Foundation and community need to work as partners.
Regarding Responsibility assignment matrix, I spent some time absorbing the page. The models generally seem to presume a context essentially internal to an organisation, generally everyone is an employee. It's a bit more complicated to apply the models here. I will try to summarize my view this way: Those models generally acknowledge approval may be needed from multiple parties to initiate a project and/or approve deployment. I acknowledge the Foundation has something approximating universal veto of every stage of anything affecting them or expending their money or labor. Wikis should get broad local decision-making on things affecting us, and I see cases where a global level consensus could apply. For example the Foundation sometimes cite the issue of a wiki unreasonably blocking some deployment - perhaps even one admin on a tinywiki. The community has the solution. It's documented in WP:CONLEVEL. If a wiki goes Nationalistic and violates NPOV and abuses admin tools, the global community can revoke the admins and reboot the wiki. If a wiki is unreasonably obstructing some deployment, global consensus can assert global deployment. Problem solved - if the Foundation engages consensus. Alsee (talk) 09:57, 1 February 2020 (UTC)
Liaison work, as any professional liaison officer could tell you, does not mean that you can always make two sides agree. It is possible to do excellent work as a liaison (i.e., as a person who carries information from one side to the other, and back again) and still end up with an intractable disagreement.
Before we could agree that things could be done by global consensus, we would have to have a consensus that consensus is the movement's method of making decisions. "The consensus of people who showed up" is mostly how we do it here at this wiki, but it is not how things happen in other communities. Some prefer straight-up majority votes or super-majority votes. There are also disagreements about what to do when there's no consensus. The Strategy volunteers favor the idea of a more integrated movement, but I think that will require us to spend time sorting out the details. For example, is it each human who gets a "vote", or each community or organization? And how do we respect devolution and local autonomy if we all get to vote on other group's affairs? (Surely we wouldn't want to say that the 99% of us who don't speak Swedish get to tell the relatively few Swedish speakers what they're supposed to be writing about.) And what do you do about intractable disagreements, e.g., that on the one hand, "the Foundation has something approximating universal veto of every stage of anything affecting them" but on the other hand, this community very much wants to have the opposite outcome, and sees itself as being the primary party affected by a WMF decision? Whatamidoing (WMF) (talk) 22:10, 3 February 2020 (UTC)

Sdkb, we'll collectively sort out how the page actually gets used. But for what it's worth, my concept for the page is "about WMF" rather than "to WMF". For example I picture anyone could post "The WMF is working on X", information which might be of interest here. That post might or might not spark a conversation. That conversation might or might not rise to a level where we want to actively talk to the WMF about it. Although I do anticipate a need for feedback-to or discussion-with the WMF for some initial topics that I want to post. Alsee (talk) 12:34, 3 February 2020 (UTC)

I support Alsee's proposal. and this new resource would be beneficial to WMF, and to Wikipedia. --Sm8900 (talk) 18:44, 9 February 2020 (UTC)
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.

Blacking out Wikipedia in Support of Black Lives Matter

Latest comment: 4 years ago177 comments66 people in discussion
WP:SNOW/kinda withdrawn (see here). RandomCanadian (talk / contribs) 14:05, 2 June 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.

Original proposal

  Moved from Wikipedia:Village pump (policy) § Blacking out Wikipedia in Support of Black Lives Matter
 – SoWhy 09:23, 2 June 2020 (UTC)

(This was originally posted to WP:AN but suggested to move here; I don't care where it is; I pasted this wholesale)

We should black out the site in support of Black Lives Matter. We've done it before. We can do it again. It simply requires moral courage to do the right thing.--Jorm (talk) 06:16, 2 June 2020 (UTC)

We are a force for good. We should do good things. We have, at our disposal, the largest information platform in the world. We should use it.
There is an idea that we are "neutral." We are not. The simple idea of "free knowledge" is, in and of itself, the most radically progressive idea that has ever existed in the minds of humankind. We are not neutral. We will never be. We are always, forever, a force of progress and progress is only ever good'.
 We should act like it. We should do good things.
I am not the smartest person in the world so I don't have all the ideas. We can black out the site in solidarity with the lives lost over time to police brutality. We can use our vast money collection engine to pay bail or medical expenses for those injured by the police state. We can use our money to buy legal advice. We can provide direct, powerful fact-checking for free to millions of people.
Let's do some good.

--Jorm (talk) 06:37, 2 June 2020 (UTC)

Comment: This is more of a "call to actually do something with our power" over a specific idea (blacking out, for instance). I thought I was clear about that above but maybe I'm shit at writing section titles.--Jorm (talk) 07:22, 2 June 2020 (UTC)

  • Support. --Deep fried okra User talk:Deepfriedokra 06:22, 2 June 2020 (UTC)
    To the opposes, let me say all that is needed for evil to triumph is for good people to do nothing. This is not too much for us to do. It is not nearly enough. --Deep fried okra (schalte ein) 07:11, 2 June 2020 (UTC)
  • Support. I'm usually one that says Wikipedia should not be used to make political statements, but is supporting human rights really a political statement? Human rights violations happen even in the developed world, and as citizens of Earth, we should do our part to stand up against human rights violations, wherever they happen and whomever they happen to. Levivich [dubious – discuss] 06:48, 2 June 2020 (UTC)
  • Absolutely not. This has nothing to do with Wikipedia. The site does not exist to push one side or another of your favorite local political issue of the moment. To quote the Arbitration Committee's single most-cited principle, "The purpose of Wikipedia is to create a high-quality, free-content encyclopedia in an atmosphere of camaraderie and mutual respect among contributors. Use of the site for other purposes, such as advocacy, propaganda, furtherance of outside conflicts, and political or ideological struggle, is prohibited." (Established 32 times over the past decade or so.) --Yair rand (talk) 06:56, 2 June 2020 (UTC)
    I was in the room when we did exactly the kind of thing I'm suggesting. There's video footage of it. So let's dispense with the idea that we don't make political statements.--Jorm (talk) 07:00, 2 June 2020 (UTC)
  • Oppose: As an encyclopedia, to support Black Lives Matter, we should continue to produce and promote encyclopedic content about Black Lives Matter and related topics. 71.234.210.113 (talk) 06:58, 2 June 2020 (UTC)
  • Oppose. Sorry, but as much as I would support Black Lives Matter, I'm sure 364 people could come up with 364 great causes worldwide that would be just as worthy of support and protest. If we start this, we could just as well keep Wikipedia blacked out 365 days of the year. Fut.Perf. ☼ 07:00, 2 June 2020 (UTC)
  • Leaning oppose but interested to hear more perspectives. Two points:
    1. Wikipedia's consistent availability, and consistent invitation to anyone to improve its contents, is at the core of its value. A time of pandemic and social unrest is especially a time when many people rely on Wikipedia for well-organized, accurate, and timely information about mattes of life and death. Blacking the site out at a time like this is a very extreme step to take.
    2. If the message is "Black Lives Matter," (a cause I support fully and without qualification), it's black voices that I would find most relevant. Is there a group of black Wikipedians, or black media experts, who is looking for this, and calling for this? I am not aware one way or another. As a white man, I feel that an essential part of being an effective ally is making space for those impacted to state their wishes, rather than making assumptions. So as I said, I'll be reading with interest as this discussion continues. -Pete Forsyth (talk) 07:01, 2 June 2020 (UTC)
    Don't be afraid to stand up for justice, Pete. You don't need anyone's permission to help. All you have to do is stand on the right side of the road. If you can't do that, just get out of the way.--Jorm (talk) 07:40, 2 June 2020 (UTC)
    I'm pretty sure I know which is the right side of the road, but I'm open to more useful info. (Grandstanding is not useful info.) -Pete Forsyth (talk) 07:44, 2 June 2020 (UTC)
  • Question How long of a blackout would it be? Can someone explain exactly what this entails? I'm guessing all pages displaying nothing but black for some period of time? Just article space? —DIYeditor (talk) 07:05, 2 June 2020 (UTC)
    Probably 24 hours. We did it once to protest stupid copyright laws. --Deep fried okra (schalte ein) 07:11, 2 June 2020 (UTC)
    Copyright law is directly related to the project though... I'll think about this and watch the comments. —DIYeditor (talk) 07:15, 2 June 2020 (UTC)
    well, there's no rules on that. We can make them up. It doesn't even have to be a black out. It can be a lot of things. It turns out we have a lot of power and one of those powers is "flexibility". --Jorm (talk) 07:39, 2 June 2020 (UTC)
  • Support Yes, this is needed for the USA. I would also like to see a project to support Wikipedians at the local level, either per city or per state. Thinking of practical tips for medical help, legal help, and food, especially where stores are looted and no busses are running due to COVID19. Jane (talk) 07:07, 2 June 2020 (UTC)
    • There are other organisations that do that sort of thing. They do it all the time, and it’s all they do, so they are experts at it, but we are not. It’s like how we are experts at building an encyclopedia, but they are not. The world works better when everyone sticks to what they are good at. Brianjd (talk) 09:29, 2 June 2020 (UTC)
  • Oppose I fully support the protests personally, but the best way this specific project can support any movement is to accurately report what has happened, i.e. remain a trusted and unbiased/unpartisan source of information. Blacking out of our site either in favour of the police, in favour of the protestors, or somewhere inbetween would obviously be seen as a partisan statement and jeopardise our status as a neutral source of truthful information. A reader perusing our site should be unable to tell if the majority of our editors personally support or oppose the police/protestors. I think the best thing we can do is rigorously document, and in my mind this documentation will do only thing: highlight the horrific abuses of protestors by the police. There'd also be the problem that this could increase the perception that our project is heavily US-centric. Acather96 (click here to contact me) 07:11, 2 June 2020 (UTC)
"A reader perusing our site should be unable to tell if the majority of our editors personally support or oppose the police/protestors." I agree wholeheartedly, and this applies to all matters. Commentators should not be able to characterize Wikipedia's leanings in any way. We should provide as little basis as possible to be able to convincingly say much of anything about Wikipedia other than that Wikipedia is a purveyor accurate information. If Wikipedia is seen as being "left-leaning" our credibility damaged Bus stop (talk) 13:45, 2 June 2020 (UTC)
  • Oppose The sole purpose of Wikipedia is to provide knowledge. Preventing people from reading the site obviously detracts from that purpose. Right now there is more interest in the subject than ever, and people will be turning to Wikipedia to help them understand what's going on. Wikipedia does more good by allowing readers to learn about the subject than it would by inconveniencing them as a sad and impotent form of protest. Red Rock Canyon (talk) 07:13, 2 June 2020 (UTC)
  • Oppose It would be much more productive for all of us to work together to improve the quality and depth of our coverage of the current George Floyd protest movement, and the long history of struggles of oppressed people all over the world, and also the horrific reality of how the coronavirus pandemic is playing out in vulnerable, powerless communities worldwide. Making our content unavailable or difficult to access in the midst of a deep and profound worldwide crisis, though well-intentioned, is the wrong step at this moment, in my opinion. I have deep respect for those who propose and support this. Cullen328 Let's discuss it 07:15, 2 June 2020 (UTC)
  • Oppose. Strong support from me for the "Black Lives Matter" movement. But it's treading on dangerous ground for Wikipedia when we engage directly in political activism, especially when it can be seen as partisan in a time approaching the US presidential election. And as Fut.Perf. suggests above, where would we stop? Wikipedia's correct role is to document the issues and events, according to the balance of reliable sources. Boing! said Zebedee (talk) 07:16, 2 June 2020 (UTC)
  • Racism, violence, and authoritarianism are fundamentally incompatible with the free culture movement's ideals and the foundational values of this encyclopedia. There is value in supporting kindred movements. Support — Wug·a·po·des​ 07:20, 2 June 2020 (UTC)
  • Oppose per Boing! said Zebedee essentially. Wikipedia's role is to document, not to influence. If we take sides on any political cause, we risk being seen as non-neutral when covering the same political topic. I understand such proposals when it's against something that threatens Wikipedia directly (like SOPA did) but even then we have to be very careful. Regards SoWhy 07:28, 2 June 2020 (UTC)
  • Oppose I think that any benefit of the blackout would be outweighed by it being used to discredit us. And I'm saying this as someone who spent the better part of the last two days with 40mms pointed at me. signed, Rosguill talk 07:30, 2 June 2020 (UTC)
  • Oppose We aren't "a force for good." We're an encyclopedia. That said, if there's evidence that George Floyd was a Wikipedian, I'm willing to reconsider. Iaritmioawp (talk) 08:04, 2 June 2020 (UTC)
    • There are many Wikipedians; I’m sure the are some (besides George Floyd) who have been mistreated by governments and others. Picking Wikipedians to advocate for above others is just as dangerous as picking movements to support above others. Brianjd (talk) 09:04, 2 June 2020 (UTC)
  • Oppose No site blackout. It is up to each one of us to decide if we want to do something else to improve this world rather than spend time on here. Morbidthoughts (talk) 08:05, 2 June 2020 (UTC)
  • Oppose counterproductive slacktivism for a cause I strongly oppose due to its Alinskyan roots. Elizium23 (talk) 08:16, 2 June 2020 (UTC)
  • Oppose There are many problems faced by “black people” (if we want to use that term, given that the movement is called Black Lives Matter), many problems with police conduct, etc. If we start trying to pick issues to campaign on, where do we stop? Campaigning on an issue just because it is fashionable is a very bad idea too. I also note that this isn’t even the top news story on the Main Page at the moment. And it doesn’t even stop there: without digressing too much, there are current political issues that actually affect Wikipedia, but I haven’t seen anyone propose that Wikipedia protest against those. Brianjd (talk) 08:52, 2 June 2020 (UTC)
    • You could look at it the other way too. If this movement is important enough for it to shut down Wikipedia, where does it stop? Do we shut down the whole world to support this movement? Brianjd (talk) 08:57, 2 June 2020 (UTC)
  • Comment From the proposal:
    We can provide direct, powerful fact-checking for free to millions of people.
We do this already, by maintaining a neutral, verifiable encyclopedia based on reliable sources.
More generally, none of the statements in the proposal or the “Support” responses even attempt to explain why we should support this movement to the exclusion of campaigning on other human rights issues. In light of this, I oppose not only the blacking out, but also a banner message or any other measure. Brianjd (talk) 09:49, 2 June 2020 (UTC)
  • Related question: was anyone calling for this before a country was crippled by protests? (Note: “a country”, not “the country”; my country is not crippled by protests. We have our own issues, which you certainly won’t be hearing about through Wikipedia banners.) Brianjd (talk) 09:55, 2 June 2020 (UTC)
  • Oppose: Our NPOV policy in just that. Not an NPOV (unless it suits me) policy. Do this and anyone can use us to lobby, demanding equal treatment. NO. Britmax (talk) 10:00, 2 June 2020 (UTC)
  • Oppose: This has nothing to do with Wikipedia, and people are turning to Wikipedia for knowledge on the riots and Black Lives Matter in general. Henry20090 (talk) 10:05, 2 June 2020 (UTC)
  • Oppose this would be fundamentally different than the SOPA blackout, since there is no direct connection between Black Lives Matter and freedom of information. {{u|Sdkb}} talk 10:38, 2 June 2020 (UTC)
  • Support: Freedom of information is only useful if you're alive to read it. Saying human lives are worth preserving is not a "political" issue. Judytuna (talk) 11:31, 2 June 2020 (UTC)
  • Oppose: Wikipedia is built on an egalitarian foundation and so a point can be made that the project should show solidarity with protest movements, but this should not come to the detriment of the information Wikipedia provides. The ongoing protests are multinational, but are US-centric and this should be considered as en.wiki's content is globally read - readers in Belize or India looking for COVID updates should not be deprived of Wikipedia's information, even if only for 24 hours. SamHolt6 (talk) 11:32, 2 June 2020 (UTC)
  • Oppose - Wikipedia is not a platform for social justice, it is an encyclopedia. The organization as a whole is already too involved with projects that have nothing to do with building a source of free information for the masses. There is already an intolerable amount of politics existing here, we don't need to make it worse. Dennis Brown - 2¢ 11:33, 2 June 2020 (UTC)
  • Oppose we shouldn't be compromising our reputation as a neutral platform by taking part in political protests like this. We did over SOPA because that was a direct threat to Wikipedia, this is fundamentally different. Hut 8.5 12:04, 2 June 2020 (UTC)
  • Oppose. It's worth looking at the well-intentioned blackout attempts on Instagram which have ended up preventing people from sharing important information and hearing black voices: [4] [5]. A Wikipedia blackout risks doing something similar. This is a time for people everywhere to learn: about police brutality, about the history of racism, about the right to protest, all of which we cover (even if inadequately) on Wikipedia. Not to mention COVID-19 which is still an ongoing situation. Just weeks ago we had banners on the site assuring our users that "our volunteers are working to bring you a trusted source of unbiased information. Throughout these challenging times, knowledge must and will remain open for all." A blackout would undermine all this. the wub "?!" 12:07, 2 June 2020 (UTC)
  • Oppose - While, as an Indian, I detest the actions of the police in Minneapolis, I cannot support a proposal that is in violation of Wikipedia's core principles, especially WP:NPOV. Further, blacking out Wikipedia for 24 hours is purely disruptive, something we cannot afford in today's situation. — Preceding unsigned comment added by JavaHurricane (talk • contribs)
  • I wholly support the message, but I have to unfortunately Oppose on long-standing principle that WP should not be used for political activitism unless it has to directly with free speech issues that would directly affect the existence of the project (SOPA/COPA), or that the WMF otherwise make the call. We're too international, and there's too many disperse voices here that even what probably should be a fairly safe message could be taken by some as something they can't support. (I was actually considering suggesting a message last night when I read about the Blackout Tuesday stuff but basically, political stuff like that for all purposes is a PEREN no-go) --Masem (t) 12:18, 2 June 2020 (UTC)
  • Oppose as others have observed, prior blackouts were for causes directly connected to our encyclopedic mission. LEPRICAVARK (talk) 12:20, 2 June 2020 (UTC)
  • Oppose As Dennis Brown and others have pointed out, we need to stay focused on our core mission. In any event, this is too US-centric and narrow. If supporters of this sort of idea are really concerned about injustice, they should perhaps be focused more on maldistribution rather than misrecognition, and consider expanding and improving our coverage accordingly. Nancy_Fraser#Research and Noam_Chomsky#Capitalism_and_socialism may be enlightening. Edwardx (talk) 12:22, 2 June 2020 (UTC)
  • Oppose - for this to be viable, it has to overturn the staunch consensus that we only campaign (if we campaign at all) on areas that directly affect our ability to function. It's not viable to say it's non-controversial, because if every single facet of anything to do with it was non-controversial, there wouldn't be a need. Where people view Wikipedia as involved in the story, they are less likely to trust in any neutrality in the coverage. Every time we choose to engage directly, we lose our ability to be trusted as an encyclopedia. We open the door then there's no reason why if this were accepted, dozens of others should not be. In fact, there are fewer reasons - the big thing a wiki blackout gives is awareness (legislators don't give in because they're actually worried about not accessing wikipedia), which this does not need. Nosebagbear (talk) 12:49, 2 June 2020 (UTC)
  • Oppose. We are not here to right great wrongs. Bus stop (talk) 13:17, 2 June 2020 (UTC)
  • Oppose We are an encyclopedia designed to provide knowledge to all for free. Going dark takes away that knowledge. Also, this is still a political issue, and we should as a site remain neutral. Staying live, showing the events as they happened, giving people information is more important. RickinBaltimore (talk) 13:25, 2 June 2020 (UTC)
  • Oppose this has nothing to do with Wikipedia. Headbomb {t · c · p · b} 13:40, 2 June 2020 (UTC)
  • Oppose. This goes against NPOV. Why is this one issue more important than the many other issues in the world like, say, the COVID-19 pandemic? epicgenius (talk) 13:40, 2 June 2020 (UTC)
  • I forecast snow, but perhaps it’s too early to make that call. Now, seriously, there’s more than 30 oppose votes, each of which has a rationale attached, none of which have been addressed by any supporters. If you are going to vote support, please actually address the issues already raised in the discussion. Brianjd (talk) 13:46, 2 June 2020 (UTC)
  • OPPOSE You should never block out Wikipedia for any reason. Dream Focus 13:53, 2 June 2020 (UTC)
  • Oppose per Wikipedia:Five pillars. Wikipedia is an encyclopedia, not a platform. There are many other suitable locations for such an action.--Paul McDonald (talk) 13:57, 2 June 2020 (UTC)

Alternative: Redirect all pages for 1 day

Similar to User:Jorm's proposal, in solidarity, I think we should redirect all pages on Wikipedia to articles on policy brutality, repression of minority groups, biographies of victims, and articles on civil rights for an entire day. We have precedent for doing this to oppose SOPA.--v/r - TP 13:00, 2 June 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.

Alternative 2: A BLM main page

Consensus is strongly against this. Thryduulf (talk) 18:10, 8 June 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.

As a compromise between keeping the encyclopedia active as it is (which I support), and doingsomething to support the BLM cause (which I support, even though Wikipedia normally isn't the place for this), how about creating a BLM main page, showing the best articles we have on the current situation, and nothing else (well, keep the Covid pointers, as these are of major importance as well)? Use Black Lives Matter in the FA spot (it is a GA), and things like Shooting of Breonna Taylor, Killing of George Floyd and George Floyd protests around or below it? We still function as an encyclopedia, but recognise the importance of this event and show people that we are providing (hopefully) balanced, factual coverage of it. Fram (talk) 14:03, 2 June 2020 (UTC)

  • Support: Something should be done, and this might be the best compromise. Henry20090 (talk) 14:06, 2 June 2020 (UTC)
  • Neutral: Yes, oppose !votes have raised concerns that have not been addressed. Moving to neutral due to the oppose !votes changing my mind.Henry20090 (talk) 14:15, 2 June 2020 (UTC)
  • Weak Strong Oppose: This is campaigning and promotional. While it does sound good on paper, BLM doesn't deserve more attention than COVID-19, even for 1 day. It also violates NPOV and is sort of spam. Henry20090 (talk) 15:07, 2 June 2020 (UTC)
  • Oppose Neutral Oppose This is a lot more than “something”. We already have a COVID-19 box at the top of the news section. But this proposal goes much further. Why should BLM get so much more attention than COVID-19 (especially given that dangerous misinformation regarding the latter is widespread)? Brianjd (talk) 14:08, 2 June 2020 (UTC)
    • Many of the oppose votes above raised similar concerns, which still haven’t been addressed. Brianjd (talk) 14:09, 2 June 2020 (UTC)
      • Covid19 has been (and will remain) on the main page for months now. The difference is one being constantly on the main page, but in one section, vs. another taking over the whole main page (minus the covid box, which should stay up) for one day. So I don't think it is fair to claim that this gets "much more attention" than Covid, it just would get it in a completely different way (more in-your-face, less continuously). Fram (talk) 14:15, 2 June 2020 (UTC)
        • Finally, someone directly addressed an oppose argument! Yay!!!!!
        Seriously: Your proposal was not clear that it would only be for one day. Changing my vote to neutral. Brianjd (talk) 14:19, 2 June 2020 (UTC)
        • With more time to reflect on it, changing my vote back to oppose. I think replacing the whole main page will get more attention than a little box, even if it’s just for one day. And on sites other than Wikipedia, it will definitely get way more attention, because it’s just for one day. Plenty of users (including some below) have argued this is a bad thing. These arguments still apply even if the encyclopedia is functioning normally; these arguments have not been addressed. Brianjd (talk) 14:58, 2 June 2020 (UTC)
  • I'm not sure how attention is bad. We are a source of information -- good, and yes neutral information -- on the exact topic the world is looking for right now. We have Covid on semi-permanently on the main page because it's affecting everyone's lives in the whole world, for months on end. Highlighting BLM & black people on the main page now is recognizing that this issue is affecting the entire US and much of the world (there were protests in 300 cities and a dozen+ international cities.) To NOT do this is a stronger statement - that we don't think this is particularly important, or anymore newsworthy than any of the other stuff on the main page (someone notable dying, a minor plane crash, whatever it is). -- phoebe / (talk to me) 19:07, 2 June 2020 (UTC)
  • OpposeNeutral This is already on the main page anyway, via "In the news". TFA and DYK are a great feature and I don't see any compelling reason to replace them with even more US-centric content, even were it for the noblest of causes. RandomCanadian (talk / contribs) 14:12, 2 June 2020 (UTC)
Ok, replacing it for one day only might be reasonable. @Brianjd: And although racism is not a US-only problem the current situation is indeed very much a US-centric one, as I haven't head of such protests anywhere else... RandomCanadian (talk / contribs) 14:24, 2 June 2020 (UTC)
  • @RandomCanadian: The article, which I linked to when I asked that question, has a picture of a protest in Germany in the last week. I also heard on TV news (in Australia) about protests in the UK and other parts of Europe, as well as Australia, all in the last week. So yeah, there are plenty of protests happening outside the US. Brianjd (talk) 15:08, 2 June 2020 (UTC)
None of those are 'bout racism or about the Black Lives Matter movement, they're (usually, far-right) groupies protesting against lockdown (much like what was also happening in the US before this escalated). RandomCanadian (talk / contribs) 15:11, 2 June 2020 (UTC)
  • The article clearly says that the protest is part of BLM, so if your comment is true, then we had better fix up the article before highlighting it on the Main Page.
Luckily, I think the article is correct. At least, the protesters shown in the picture seemed to think it was a BLM protest. You might want to read the signs they were holding up. Brianjd (talk) 15:17, 2 June 2020 (UTC)
@Brianjd: None of the international protests currently mentioned there seem to be about the current situation. In any case, BLM is a primarily (if not-overwhelmingly) US movement. RandomCanadian (talk / contribs) 15:22, 2 June 2020 (UTC)
These are the protests I was referring to, FYI. RandomCanadian (talk / contribs) 15:23, 2 June 2020 (UTC)
  • “Current”? The article you cited was published before George Floyd was killed. Yes, there were anti-lockdown protests. And before that there were climate protests. And before that there were protests about other things. That’s not relevant here. Brianjd (talk) 15:27, 2 June 2020 (UTC)
  • Neutral on whether moving to 1 day of BLM related stuff might be appropriate. As I said off-wiki, BLM isn't very well liked even in the US. We do have a precedent in the COVID box. epicgenius (talk) 14:50, 2 June 2020 (UTC)
  • I think there is a difference between the BLM as a group and the idea that black lives actually matter. I think most people can easily get behind the idea that black lives matter.--v/r - TP 15:30, 2 June 2020 (UTC)

  Comment: I think the original proposer meant editing the main page to support BLM, which is most likely against NPOV. Henry20090 (talk) 15:34, 2 June 2020 (UTC)

  • Oppose this seems to fall afoul of our NPOV stance. LEPRICAVARK (talk) 15:37, 2 June 2020 (UTC)
  • What is not NPOV about this? Can someone please explain to me what is not neutral? What other point of view is there? That extrajudicial killings are okay?--v/r - TP 15:40, 2 June 2020 (UTC)
    • The issue is not BLM itself (as far as I can tell, based on the comments here), but rather the attention given to BLM to the exclusion of other issues, including some with widespread support. Basically, if we are going to let BLM take over the Main Page today, why not let [insert your favourite cause here] take over the main page tomorrow? Brianjd (talk) 15:45, 2 June 2020 (UTC)
      • Once we go down that path, we will inevitably start to include more controversial issues. The only sure way to stop this is to not start to begin with. Brianjd (talk) 15:47, 2 June 2020 (UTC)
        • I would not be opposed to more topical main pages; I don't think that would be a bad thing (and could be a good one). Regardless, however, a slippery slope argument isn't a reason to discard this proposal. I disagree that the only sure way to avoid this is not to do it. We haven't tried. I was part of the SOPA arguments; people were worried about similar things, and yet we haven't started blacking out the site every week. I have faith in the ability of Wikipedians to discuss it! -- phoebe / (talk to me) 19:15, 2 June 2020 (UTC)
    • TParis you've grossly oversimplified the issue if you think this is really just a matter of either supporting BLM or being pro-murder. But if there's really no other point of view, why are you proposing a BLM main page? If there's only one way of seeing things, then presumably everyone already sees it that way. LEPRICAVARK (talk) 16:12, 2 June 2020 (UTC)
      • Because the issue isn't two opposing viewpoints. It's an issue of awareness.--v/r - TP 16:39, 2 June 2020 (UTC)
        • I don't believe that raising awareness of specific social issues is one of our functions. Furthermore, awareness is pretty high at the moment. Someone would almost have to be living under a rock to not be aware of what is going on right now. And if they are under a rock, they probably aren't using Wikipedia. LEPRICAVARK (talk) 16:55, 2 June 2020 (UTC)
          • Ah, most readers and editors here aren't from the United States, and are probably typically both unaware and uninterested. --Yair rand (talk) 17:49, 2 June 2020 (UTC)
            • I'm not sure this is true, given the number of protests in other, non-US cities; at any rate, it's difficult to speculate about what our readers may or may not be interested in. And a large number are in the US. -- 19:15, 2 June 2020 (UTC)
  • Oppose. Wikipedia may not deliberately support causes unrelated to its goals. --Yair rand (talk) 17:40, 2 June 2020 (UTC)
  • Oppose - bit late to discussion, but oppose for reasons noted in the previous two closed discussions. I'm sympathetic however the wider topic is highlighted as a news article, and there is no Wikipedia specific reason we should focus extra on this topic. It would be as others have commented a slippery slope. - Master Of Ninja (talk) 18:35, 2 June 2020 (UTC)
  • Strong support for this. Not the same but: a few prominent US tastemaker radio stations right now are only playing black artists. It's powerful & celebratory, and a reminder that you use the platform and medium you have. We can and should be highlighting BLM right now, plus good black biographies, accomplishments, etc. Plus, it's a practical step anyway -- this is the stuff readers are looking for right now, not whatever random thing we have queued up in today's featured article. -- phoebe / (talk to me) 19:03, 2 June 2020 (UTC)
  • Comment We already have processes and dedicated volunteers for determining what goes on the main page. As of right now, I see both George Floyd and the protests listed in "In the News." Yes, it might make sense to change the page to feature such content more prominently, but I don't think it requires a fundamental change. Maybe this discussion should take place at Talk:Main Page? I'll put a link there for now. -Pete Forsyth (talk) 19:25, 2 June 2020 (UTC)
  • Support. Might as well. Seems fitting. Guettarda (talk) 19:26, 2 June 2020 (UTC)
  • Oppose Too US-centric. Headbomb {t · c · p · b} 19:28, 2 June 2020 (UTC)
  • Oppose per WP:NPOV, including concerns about U.S.-centrism. If we can create featured content related to BLM, though, I will happily support it for TFA and TFP. {{u|Sdkb}} talk 20:03, 2 June 2020 (UTC)
  • Oppose not our mission. GenQuest "Talk to Me" 20:37, 2 June 2020 (UTC)
  • Oppose and instead, how about we build an encyclopedia. Dennis Brown - 2¢ 22:06, 2 June 2020 (UTC)
  • Oppose we cannot sacrifice our regular functions for political causes that have no direct relation to the function of our encyclopedia (for example, a protest action related to the censoring of Wikipedia by a government). Also would betray how American-centric we are; people from all over including the UK, Australia, Nigeria, South Africa, and India read enWikipedia. Nothing is stopping anyone from trying to make the BLM page an FA and then making it FAOTD, which is what editors trying to propose we do something should actually focus on. -Indy beetle (talk) 23:38, 2 June 2020 (UTC)
  • Oppose An encyclopedia should not be in the business of using its platform to advance worthy causes, as it then ceases to be just a source of knowledge and instead becomes a political campaigning tool. Although Wikipedia is already politicised, this would be a very public display of it. PaleCloudedWhite (talk) 05:28, 3 June 2020 (UTC)
  • Oppose US-centric activism. Write good coverage of the facts for long term value. · · · Peter Southwood (talk): 08:26, 3 June 2020 (UTC)
  • Oppose. Quite aside from the fact that this is a global project not Americapedia, we shouldn't be visibly taking sides on any given issue regardless of personal opinion; one of the hallmarks of Wikipedia is that even on "any right-thinking person would be on the same side" topics like Cultural Revolution, Cannibalism or Genocide of Yazidis by ISIL, a casual observer shouldn't be able to tell whether the authors were for or against it. I could just about accept the moon-themed main page on the 50th anniversary of the Apollo landings, as that genuinely was both apolitical and a unique moment in history, but the purpose of Wikipedia is to document, not to influence. ‑ Iridescent 08:42, 3 June 2020 (UTC)
  • Oppose per Iridescent, sums up my thoughts precisely. Cavalryman (talk) 01:19, 4 June 2020 (UTC).
  • Oppose Too US-centric, too political, too non-neutral. There is plenty that concerned editors can do - expand and improve our coverage of the events, and those of individual black lives, for starters. Edwardx (talk) 15:31, 4 June 2020 (UTC)
  • Oppose - pretty much everything Edwardx said. --Khajidha (talk) 19:32, 4 June 2020 (UTC)
  • Strong Oppose Wikipedia (despite the best efforts of people on all sides) is not and should never be a political tool or organ. Favoring and promoting one group over another is absolutely against even the most basic policy here. RandomGnome (talk) 21:29, 6 June 2020 (UTC)
The above discussion is preserved as an archive of the debate. Please do not modify it. Subsequent comments should be made on the appropriate discussion page.

Alternative 3: A BLM article improvement drive

See Wikipedia:WikiProject Black Lives Matter/June 2020 — Wug·a·po·des​ 00:00, 4 June 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.

We can always use an article improvement drive, so why not one in identifiable BLM-related subjects? Look at the sorry state of Race relations, to begin with! BD2412 T 16:02, 2 June 2020 (UTC)

  • Yes... finally we have a suggestion that is more than just pointless virtue signaling. And one that is within our mission. Thank you. Blueboar (talk) 16:10, 2 June 2020 (UTC)
  • I don't think you need community consensus for something like this. Just organize something and announce it at all the usual places. LEPRICAVARK (talk) 16:14, 2 June 2020 (UTC)
    • True, but a show of community support would signify a resolution of the "what is to be done about..." question inherent in this entire discussion. BD2412 T 16:16, 2 June 2020 (UTC)
  • The first Wikipedia:Meetup/NYC/Black Life Matters Editathon was in 2015 (the topic area is actually broader, though the name was inspired by BLM and a Schomburg Center for Research in Black Culture exhibition), and it's become a major annual edit-a-thon. Of course these topics should be improved continuously, and extra drives are always welcome.--Pharos (talk) 16:19, 2 June 2020 (UTC)
  • Yes, good, perfect. I'm happy both for the community to show support for it - and whether or not others disagree with that aspect, I'll happily get involved in such a drive. Nosebagbear (talk) 16:28, 2 June 2020 (UTC)
  • I like this idea. An article that has been on my mind as needing a great deal of work is African-American newspapers. (I'm working on a project that would make this, and relate, articles a priority, so it will likely get some attention regardless.) This approach seems like a natural fit; maybe it should start with a page to build a list of relevant articles, discuss the range of dates, develop some language to describe the campaign? -Pete Forsyth (talk) 16:54, 2 June 2020 (UTC)
  • 'Support Yes, this is well within the parameters of the encyclopedia and does not threaten its NPOV policy. Britmax (talk) 17:09, 2 June 2020 (UTC)
  • Certainly creating neutral, informative content on such topics would be productive, regardless of whether the editors are personally pro- or anti-BLM. Of course, this could not be used to push a particular viewpoint or promote any group. Whatever motivation one finds to edit is fine, so long as the edits themselves are unbiased. But as Lepricavark said, you don't need consensus for this. There should not be a collective community answer to "what is to be done about...", because the project is neutral. As individuals, and as self-organizing volunteers, many may give their own responses to events in the world, potentially involving neutrally improving content, and that benefits the project. --Yair rand (talk) 17:18, 2 June 2020 (UTC)
  • Support oooh, an excellent suggestion. Perhaps identifying WP:WikiProject African diaspora as a focus area would help direct new users? CaptainEek Edits Ho Cap'n!⚓ 17:23, 2 June 2020 (UTC)
As a combination of alternative 2 and 3, Juneteenth is two weeks away, and we still have some time to develop some content to mark that date.--Pharos (talk) 20:15, 2 June 2020 (UTC)
George Washington and slavery is the scheduled TFA for June 19.--Wehwalt (talk) 20:24, 2 June 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.

Edit notice proprosal

Latest comment: 4 years ago7 comments5 people in discussion
Please discuss at Wikipedia_talk:Help_Project#New editnotice to help fight WP:CREEP — Wug·a·po·des​ 21:33, 8 June 2020 (UTC)

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

There is a proposal to add a new edit notice to a bunch of pages in the project and Help namespace. If you have any comments about this please discuss at Wikipedia talk:Help Project — Martin (MSGJ · talk) 19:14, 7 June 2020 (UTC)
To clarify for anyone unfamiliar, edit notices do not appear on the normal page itself, but rather in the editing window when you're modifying a page. {{u|Sdkb}} talk 23:51, 7 June 2020 (UTC)
  • Support this a very good idea. We need this to avoid unnecessary talks and over-detailing. This a brilliant idea Tbiw (talk) 13:33, 8 June 2020 (UTC)
  • I'm neutral, but one concern is likely edit notice fatigue. Eventually people will start ignoring it, and maybe other more important edit notices. I don't really see the benefit of adding such generic advice to help page edit notices. — Wug·a·po·des​ 21:06, 8 June 2020 (UTC)
    @Wugapodes: Probs best to avoid a WP:TALKFORK and have the discussion at WT:Help Project, but for what it's worth, the intention is clarified over there to be that it would specifically be added to help pages that are explicitly designed for newcomers - not just all help pages, or even a significant number of them. Naypta ☺ | ✉ talk page | 21:10, 8 June 2020 (UTC)
    Thanks, I've closed this with a pointer to the discussion so that it's more obvious where to go. — Wug·a·po·des​ 21:33, 8 June 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.

Alternative to a Black Lives Matter blackout: Header for the BLM movement

Latest comment: 4 years ago5 comments5 people in discussion
Per responses. ―Mandruss ☎ 19:02, 9 June 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 feel like Wikipedia needs to help. A lot of the other options are too intrusive for something unrelated to Wikipedia. However, this wouldn't be intrusive and we could really make a difference --2601:197:800:C0D0:B521:2A1A:F47D:C0D3 (talk) 15:59, 9 June 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.

Prohibit blackouts and protests in the mainspace that support a political movement

Latest comment: 4 years ago4 comments3 people in discussion
IMPOSSIBLE
Non-admin closure of my own proposal. - ZLEA T\C 15:30, 10 June 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 realize that what I'm proposing is going to be controversial at best, but after learning about the various proposals to black out Wikipedia or change the main page to show support Black Lives Matter, I now know that I must speak my mind or risk watching Wikipedia lose its neutrality.

I propose that we prohibit blackouts and all forms of protest on the main page and in articles in support of a political cause that has nothing to do with Wikipedia or freedom of speech/information. Why do I propose this? Because once Wikipedia becomes a billboard for politics, it loses its neutrality. To quote WP:PROMOTION:

"Content hosted in Wikipedia is not for advocacy, propaganda, or recruitment of any kind: commercial, political, scientific, religious, national, sports-related, or otherwise. An article can report objectively about such things, as long as an attempt is made to describe the topic from a neutral point of view."

Wikipedia is an encyclopedia! There is no place for promotion of a political cause on Wikipedia. What makes Wikipedia great is that there are editors from all political backgrounds, which makes for an encyclopedia that covers politics in a neutral way. If the whole of Wikipedia starts protesting for a specific cause, people on the other side will become angry and many Wikipedians that don't support that cause will leave. Not only will we lose countless good editors of non-political topics, but we will also lose the balance of editors of political topics, allowing the other side to insert their own non-neutral POV into those articles without opposition.

While my proposal would prohibit any visible support for political causes on Wikipedia, there would still be many ways for Wikipedians to show their support for those causes through edit-a-thons, meet ups, drives, etc.

Of course, this proposal extends to all political causes that have nothing to do with Wikipedia or freedom of speech/information. However, if it does, like the Stop Online Piracy Act did, then, if there is consensus to do so, it would be exempt from this policy. I figure that if Wikipedians are contributing to Wikipedia in the first place, they would be all for freedom of speech/information, and promotion of those freedoms would not anger any contributors.

Once Wikipedia loses its neutrality, it won't be long before people begin to realize that they can no longer trust it. People will stop donating to the project, and many editors will leave, effectively killing it off. - ZLEA T\C 15:08, 10 June 2020 (UTC)

  • Impossible. Whatever consensus allows the protest would override whatever policy or guideline might be created as a result of this proposal, rendering the proposal useless. Jc3s5h (talk) 15:16, 10 June 2020 (UTC)
  • Impossible per Jc3s5h. Other than direct constraints forced upon us by the WMF or MediaWiki software, Wikipedia has no constitution, and there is no decision which cannot be overridden by later consensus. -- King of ♥ ♦ ♣ ♠ 15:23, 10 June 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.

Partial block – moving pages

Latest comment: 4 years ago25 comments18 people in discussion
Tracked in Phabricator
Task T194529

Special:Block allows administrators to block users from (1) Editing, (2) Account creation, (3) Sending email, and (4) Editing their own talk page. Should a fifth option, Moving pages, be added to the menu?

This would force the pagemove-blocked editor to request all moves at a venue such as WP:Requested moves, where at least one editor would review their request to ensure that it wasn't potentially controversial. Potentially controversial requests should be discussed, generally for at least one week, at WP:Requested moves, to ensure there is a consensus before implementation. Some editors seem unwilling or unable to recognize potentially controversial requests in advance, and have developed a track record for making controversial moves that often are reverted. The proposed pagemove-block would ensure anther set of eyes on their moves in order to minimize disruption. – wbm1058 (talk) 18:14, 24 May 2020 (UTC)

This allows blocking them from the area they are not productive in while potentially keeping helpful edits elsewhere. Cheers, RandomCanadian (talk / contribs) 16:49, 29 May 2020 (UTC)
  • Support, as long as it is reasonably practicable to implement. · · · Peter Southwood (talk): 17:45, 29 May 2020 (UTC)
  • Note Local "voting" on this is unlikely necessary, this is already a requested software update and I don't imagine it will only be made available to projects to vote for it. You can express support by commenting here: phab:T194529. The only thing we need locally would be guidance for admins on when to use or not use this feature, and local documentation. — xaosflux Talk 18:05, 29 May 2020 (UTC)
  • Comment I will note that this will probably only block the move action but the user can still perform workarounds like manual wikitext copy/paste under a new title. There's a deeper explanation about this limitation on the phabricator ticket. Thanks for opening up this discussion, Wbm1058. -- NKohli (WMF) (talk) 22:36, 29 May 2020 (UTC)
    Yes, I once did a cut-paste move as an IP before I knew any better, before I registered for an account. I'm one of the few admins active at WP:WikiProject History Merge. I envision the page-move block only being used on experienced editors who do know better, and if they are caught cut-pasting while under this block, that's tantamount to a request for stronger sanctions like a full block. We are gradually getting better at detecting cut-paste moves, but there is still a large backlog of needed cleanup in that area. – wbm1058 (talk) 16:50, 30 May 2020 (UTC)
  • Support. Honestly should've been a thing awhile ago. –MJL ‐Talk‐☖ 20:07, 1 June 2020 (UTC)
  • Strongly conditional support. Although I like this idea, I am opposed to any form of "authoritarianism creep" that allows user rights and privileges to be revoked in an increasingly pre-emptive manner and diminishes the level of trust afforded to average Wikipedia editors. I would only support this proposal if it was made clear in policy that move-parblocking was to be an alternative to full blocking of disruptive page-movers; in other words, the editors in question had committed enough page-move disruption to warrant a full block were the move-block feature not enabled. My biggest worry is that administrators might otherwise use this tool to pre-emptively revoke the move rights of users who have only made one or two disruptive moves without much in the way of warning, on the grounds that it "doesn't really harm their ability to edit the project" and is therefore "no big deal". Passengerpigeon (talk) 03:41, 6 June 2020 (UTC)
  • Support as an incremental tool, less drastic than a full block, for dealing with disruptive page movers. Levivich [dubious – discuss] 18:36, 10 June 2020 (UTC)

Partial block – editing rate

Latest comment: 4 years ago28 comments15 people in discussion

Special:Block allows administrators to block users from editing:

  Sitewide, or
  Partial (specific pages or namespaces).

Should a third option,   Editing rate (per minute) be added to the menu? This option would allow blocking administrators to specify a restricted, pedestrian edit rate (say between 1 and 6 edits per minute) to mitigate disruption caused by unapproved high-speed editing.

High-speed editing should get prior approval via the WP:Bots/Requests for approval (BRFA) process, where (semi-)automated editing projects are scrutinized by other editors before full implementation, for better quality control. Editors repeatedly failing in quality control of their high-speed editing could have their editing rates restricted until their BRFA was approved.

Technically this should be possible. The backend operators can already restrict bots' editing rates as needed to stop denial-of-service attacks. When this option is activated for a specific editor, the software would simply check the editor's recent history and deny the edit if more than the specified number of edits have already been made within the past minute. – wbm1058 (talk) 13:16, 25 May 2020 (UTC)

This can already be implemented using the Edit Filter, but it may still be a good idea to implement it less hackily using partial blocks. * Pppery * it has begun... 13:58, 25 May 2020 (UTC)
The notion of rate limiting a specific person kind of makes me feel 'meh'. Truly disruptive fast-editors can simply be blocked, which leaves the good faith more or less, whose attention can usually be caught with a "stop editing" 1minute/hour/day block. That leaves the outliers like the discussion I'm sure triggered this one, and for those this is still an edge case remedy. I wouldn't oppose a task hanging out in Phab for it, but I also don't think paid developer time should be spent on it. --Izno (talk) 17:06, 25 May 2020 (UTC)
Don't really see the point either. There aren't many people who run unapproved bots and blocking people who run them is a more reasonable response than just slowing down the bot's edit rate. And that's assuming the person is actually being constructive, anyone who's running a vandalbot should just be blocked indefinitely. Hut 8.5 18:11, 25 May 2020 (UTC)
@Hut 8.5: How big of a problem are "vandalbots" anyway? In all my years editing here I've never seen one in action; could you link to one as an example? Passengerpigeon (talk) 03:30, 6 June 2020 (UTC)
I can't point to any example I definitely know was caused by a vandalbot, but I have seen vandals get bot-like editing rates by what I suspect was opening lots of tabs and saving them all at once. It's not a big problem no and as I said we should just block them like other vandals. Hut 8.5 08:42, 6 June 2020 (UTC)

I feel it would be relatively useful if bursts were allowed and tailored to permission levels. I.e. something like

  • IP/Non-autoconfirmed, no more than 30 edits in 10 minutes [3EPM average].
  • Autoconfirmed, no more than 60 edits in 10 minutes [6 EPM average].
  • Extended-confirmed no more than 100 edits in 10 minutes [10 EPM average].
  • Highly-trusted users [Template editors, admins, bots] [∞ EPM / unrestricted]

Headbomb {t · c · p · b} 19:01, 26 May 2020 (UTC)

Setting edit restrictions to all user groups doesn't require the edit filter; it's a simple configuration change * Pppery * it has begun... 19:23, 26 May 2020 (UTC)
I don't see the point of this. Making a lot of edits rapidly can be the result of various things, good faith (anti-vandalism with some of the semi-automated tools, for example) or bad faith. As per User:Hut8.5, it's much simpler to simply ban vandalbots (especially since slowing them down doesn't stop the vandalism, blocking them is what does the trick)... RandomCanadian (talk / contribs) 21:26, 26 May 2020 (UTC)
  • Technically-unenforced rate limiting has been tried before as a remedy for users whose edits were problematic but not vandalism. Examples I am aware of are MZMcBride (ping) Betacommand (AKA user:Δ) and Rich Farmbrough (ping). Although in Rich's case no specific figure appears to have been set that I can find, 4 edits per minute was applied to Δ and 12 per minute to MZMcBride. All of these cases are years old though (2009-2012, although later actions/enforcement may have happened), I have a feeling it has been tried more recently but apparently not as an arbitration remedy and a more general search is swamped by bot requests. Thryduulf (talk) 08:32, 27 May 2020 (UTC)
    This is where myth comes from, but thanks for the ping. I have never been rate limited over and above the general guidelines (there's a back-off bit that's signalled to bot accounts for example, I don't remember the details). I think I was asked to slow down once, which I did. The now defunct ArbCom rulings were never related to speed (or accuracy), only to characteristics which are indeterminable. All the best: Rich Farmbrough 16:34, 27 May 2020 (UTC).
  • Why? We shouldn't be scared of using block if someone is causing disruption. I could only see this as possibly useful for IP's (i.e. a registered user that can't follow community standards can just be shut down until they can be constructive). As far as IP's go - how would you want to enforce this, during the attempt to get an edit token, during the save process (spoiling the edit), sending them to CAPTCHA, something else? — xaosflux Talk 14:24, 27 May 2020 (UTC)
  • @Headbomb: regarding your list above, being a template editor shouldn't mean you get to flood watchlists and recent changes. Bots have the ability to flag edits as bot to avoid this, and admins do for when they have a bulk rollback activity. — xaosflux Talk 14:27, 27 May 2020 (UTC)
There's many types of "watchlist flooding" that can be done with AWB that really isn't problematic (usually in category space, or various cleanup/checkwiki tasks). I'd trust template editors to be able to handle that sort of thing without needing to go through an RFA. Headbomb {t · c · p · b} 14:42, 27 May 2020 (UTC)
Maybe you don't consider it as such, by I consider flooding watchlists with minor cleanups to be problematic for sure. — xaosflux Talk 15:59, 27 May 2020 (UTC)
Depends on the details of the task. I know I never had any pushback on anything I did in category space, either because barely anyone watches these pages, or because I'm clueful, and probably a combination of both. Point is, template-editors are a small (~184) generally clueful bunch, and they aren't the ones causing issues with high edit rates. Imposing limits on them that they don't currently have would serve little purpose. Headbomb {t · c · p · b} 16:08, 27 May 2020 (UTC)
Clueful and lucky, I would say. And having "bomb" in your name probably stops people from trying to jump you in dark wiki-alley.   All the best: Rich Farmbrough 16:44, 27 May 2020 (UTC).
  • I can see why this is being suggested, but beware of the potential sideeffects. Aside from losing good edits of people improving the pedia, this would give editors an incentive to opt out of issuing optional warnings to other editors, or for example of maintaining a CSD noination log. Three CSD tags in one minute would be uncontentious if you just templated the three articles, but if you set your Twinkle options to inform the creator and log the tag it would be 9 edits in one minute. ϢereSpielChequers 14:32, 27 May 2020 (UTC)
Exactly my point... RandomCanadian (talk / contribs) 16:33, 27 May 2020 (UTC)
I'm not too sure about these tools. I get templated every week and 95% of the time the page is either kept or I {{g7}} it. So in 19 out of 20 cases an unnecessary discussion is started, where had they simply notified me and followed up if it wasn't deleted much community time could have been saved. Scale this up across the project, and there may be "more damage than harm". All the best: Rich Farmbrough 16:48, 27 May 2020 (UTC).
  • I can see this being useful in certain situations where a standard block is rejected by the community. Giving more options to the community to handle unique situations is a good thing as long as the community dictates how and when it is used. Nihlus 16:11, 27 May 2020 (UTC)
  • I can see some not-so-obvious benefits. For example rate limiting a blocked user to 1 edit per day would allow then to express themselves on their talk page, but require them to think carefully about what they write. Useful for the type that tends to spam unblock requests, for example. It might be useful to temporarily restrict nationality and genre warriors to give a period when they can edit, but not effectively edit war. I'm not sure if we have the skills as a community to use such a tool wisely, but you never know. All the best: Rich Farmbrough 16:40, 27 May 2020 (UTC).
In that case I am willing to reconsider what I said above. However, it should not be based on user permission levels, but rather used as other tools only with accounts which have proven to be problematic (much like partial blocks or topic bans). Cheers, RandomCanadian (talk / contribs) 02:03, 28 May 2020 (UTC)
Are you imagining a combination of partial blocks? For example, imagine that the editor is partial-blocked on the mainspace, plus is rate-limited to a small number of edits per day total. That could be useful things like someone who is being unblocked to participate in ANI, ArbCom, CCI, etc. discussions. WhatamIdoing (talk) 21:40, 1 June 2020 (UTC)
  • I think the possible use of this would be fairly limited unless we gained the ability to pair up rate limits and certain pages (which would allow nuanced restrictions usually refused due to difficulty in enforcement). However, that sounds like it would be significant Dev work, and I'm reticent to ask for that when it's not particularly needed. Nosebagbear (talk) 09:11, 28 May 2020 (UTC)
  • Rate limiting all editors (or all EC editors, etc.) is not a good idea, it would just hobble editors who are doing nothing wrong and don't need hobbling. Being able to rate limit specific individual editors as a partial block is a good idea. Another incremental tool. It would be even better if rate limits could be applied to certain editors only in certain namespaces. Rate limiting a bludgeoning editor from talk space pages, for example, could be very useful. Levivich [dubious – discuss] 18:39, 10 June 2020 (UTC)

Template:Contrib-hr1 and Template:Contrib-sr1

Latest comment: 4 years ago3 comments3 people in discussion

Nobody watches the talk pages of those templates so I ask here. These templates are Non-English user warning templates for users contributing in Croatian/Serbian and should be redirected to Wikipedia in those languages.

Given the very similar nature of these languages a user contributing in Croatian might be mistakenly thought as Serbian by English users and given Template:Contrib-sr1 (and vice versa, unless they write in Cyillic when only Contrib-sr1 is correct). Additionaly, the Serbo-Croatian (sh.wikipedia.org) and Bosian Wikipedias is not offered. It might be good to merge templates into Template:Contrib-sh1 when all four Wikipedias are offered so they can choose. — Preceding unsigned comment added by Ibicdlcod (talk • contribs) 09:13, 12 June 2020 (UTC)

@Ibicdlcod:, Yes, and the message should be given in both scripts. Mathglot (talk) 11:35, 12 June 2020 (UTC)
We should not redirect these to another project, as our rules don't necessarily apply to the other project, nor theirs to ours. — xaosflux Talk 16:17, 12 June 2020 (UTC)

Related things to a article that the subject that don't have one as subpages of that article

Latest comment: 4 years ago4 comments3 people in discussion
WITHDRAWN
Maybe this was a bad idea Another Wiki User the 2nd (talk) 20:57, 13 June 2020 (UTC)

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

The steps: 1. Re-enable subpages for articles 2. Make a link like this one 3. Write the article 4. Done

NOTE: Related subjects, not hierarchy

Another Wiki User the 2nd (talk) 15:40, 5 June 2020 (UTC)

Sorry but the above post is gibberish; what are you proposing? If you're suggesting we split the sections of long articles into subpages of the parent article, that wouldn't fit with Wikipedia's structure and would entail a massive redesign of the entire WMF ecosystem since Wikidata would also need to be recoded. Our system does allow (and encourage!) splitting of complex topics, but into independent standalone articles rather than subpages—this, Early life of Samuel Johnson rather than Samuel Johnson/Early life. ‑ Iridescent 15:49, 5 June 2020 (UTC)
I think this is about bringing back Wikipedia:Subpages#History of subpages. But both hierarchies and related subjects have the same problem: a topic may be under many hierarchies or related to many different subjects. – Finnusertop (talk ⋅ contribs) 16:00, 5 June 2020 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Proposal: Open watchlist display

Latest comment: 4 years ago8 comments3 people in discussion

I'd like to propose a feature that conditionally waives privacy on individual watchlist items, so others can see that they are following a given page. Reason behind this: I fairly often see repetitive comments in Talk pages, such as, "you don't need to ping me, I'm watching this page"; "please don't ping me, I watch all the pages related to Outer Slobovia"; and so on.

I can envision various ways for this to be functionally presented to the user. At first blush, most useful I think would be addition of two objects: 1) a checkbox, and 2) a link somewhere on the "watched" Talk pages. Checking the box would mean, "If I am watching this page, this is my okay to display my Username in a list of watchers of this article." (Possibly the box could be suppressed if they are not a watcher.) The link (or possibly a drop-down?) would provide a subset of the list of watchers of the page, who had previously ticked the box. (Sorted by most-recent update to the Talk page would be a nice option, to be chosen in Preferences.)

Other presentations are possible, such as some offshoot of the favoriting process, or on the Raw edit feature of watchlists.

If there were privacy concerns about outing or other issues, perhaps a two-step procedure, where a user would first have to tick a once-only opt-in box in User Preferences, "Allow watchlist waiver checkbox", only after having read a description of what the impact of ticking the box was, to make sure they understood it. Default would be "Do not allow". And, or, one could require they be auto-confirmed, and have minimum N pages in their watchlist, or some such.

Extra credit: have a magic word that could access this, so I could create a custom signature that could style my signature conditionally on pages that I'm an open-watcher of, to signal my status there; or perhaps just to use a default icon, (like eyeballs? 👀 ) that would indicate "I'm watching this page". Thanks, Mathglot (talk 👀) 23:43, 15 June 2020 (UTC)

This is intriguing, but the necessary privacy measures are likely to make its use fairly limited: having to check a box on each page you're watching is cumbersome enough for a marginal enough benefit that many people just won't bother, and searching for whether someone you're talking to is watching the page is more cumbersome than just seeing whether they add {{pping}} or {{pping|no}} to their messages. I like the idea of creating some way for whether or not you're watching a page to be built into your signature, but even for that, it's unclear how you'd suppress it in the instances where you might not want to disclose whether you are or not. {{u|Sdkb}} talk 00:09, 16 June 2020 (UTC)
Rather than expose individual watchlists, I would feel more comfortable with enhancing the configuration for echo notifications. There could be a global option to suppress notifications for all watched pages, or the option to specific specific pages. This would also take the onus off everyone else to check who to notify. isaacl (talk) 00:30, 16 June 2020 (UTC)
@Sdkb: I expect its use would be fairly limited; just as, say, custom signatures are, or the use of any number of options in User Preferences are. But that doesn't make it undesirable.
@Isaacl:, I am *not* in favor of exposing individual watchlists, and think that's a bad idea. Your proposal sounds like an additional one, that could be beneficial as well. Mathglot (talk 👀) 00:36, 16 June 2020 (UTC)
My apologies for eliding your proposal. I am not in favour of conditionally waiving privacy on individual watchlist items. isaacl (talk) 00:38, 16 June 2020 (UTC)
@Skdb: Also, I wouldn't tick the box for my whole watchlist, or even for all the discussions I took part in (since I usually want to be pinged); but only for a subset of them. Since I would already be on the page as a discussant, there would be little extra work to tick the box. But isaacl had an interesting alternative approach. As for, "it's unclear how you'd suppress it", that would be presumably be a parser conditional inside your signature on a new magicword, or maybe even a new Preferences opt-in checkbox, such as, "Add eyeballs to my sig on my open-watched pages" to make it easier for those who don't want to deal with parser code. Mathglot (talk 👀) 01:12, 16 June 2020 (UTC)
@Isaacl: I like that idea. I'm not sure I'd use it personally, but it seems like a useful feature for those annoyed by too many notifications. One other thing to consider is that, given the updates coming to how talk pages work, it may soon be a lot easier to @ people and there might be wikicultural changes as a result of that. {{u|Sdkb}} talk 01:57, 16 June 2020 (UTC)

There is one other useful aspect of this that I had considered, but I didn't want to overburden the original post with it. Namely, that opting in would create an accessible 'watch group' for a page, which could become a new criterion and useful addition to the notion of Appropriate notification for discussions about related topics. Mathglot (talk 👀) 01:02, 16 June 2020 (UTC)

Words matter, consider reframing the topic of lynching

Latest comment: 4 years ago3 comments2 people in discussion

I was reading an article published by Anti-Racism Daily and this excerpt prompted me to reach out to you:

(On Wikipedia, lynching is defined as a "practice" which sends chills down my spine). Although lynchings have happened to people of all races – it became a popular way for white people to show their outrage against new-found freedom of enslaved Black people in the late 19th century, particularly in the South.

In this day and age, when once again our countries lawmakers have failed to pass laws forbid lynching, it seems especially relevant to look at the ways in which language unintentionally perpetuate racism. I consider the many practices I study and adhere to: landscaping practices, farming practices, teaching practices, parenting practices, and so on. But “lynching practices”? No. We need to do better.

Journalism practices matter. Words matter. One has only to look at what happening in the streets of Bethel, OH, to understand that in some communities racism doesn’t even hide “under the surface”, therefore, it’s imperative to change the language we use to describe these atrocities, otherwise they are unintentionally perpetuated. I’m sure it causes trauma to people to read about “lynching practices” on Wikipedia.

Be a force of change. Review your articles and apply anti-bias practices in your writing. The world is quite literally watching.— Preceding unsigned comment added by 2600:8800:7B83:DA00:608E:DE9:EB7:4846 (talk • contribs)

This encyclopedia is not a force for change. It is a summary of the reliable sources elsewhere. And please sign your posts (4x ~).
PS extra judicial executions are not allowed in any country I know. Britmax (talk) 15:34, 17 June 2020 (UTC)
You can have good practices and bad practices. The word itself makes no value judgement. Phil Bridger (talk) 15:43, 17 June 2020 (UTC)
And in our article on lynching it is defined as "a premeditated extrajudicial killing by a group" and has been for a long time. Maybe you should check your facts before posting? Phil Bridger (talk) 15:49, 17 June 2020 (UTC)

Proposal to update the Outing procedure to allow for appeals

Latest comment: 4 years ago13 comments11 people in discussion

Proposal has been shortened upon request Should the Outing procedure be changed to allow for appeals? 01:52, 17 June 2020 (UTC)

Preamble (Proposal to update the Outing procedure to allow for appeals)

Currently, Wikipedia's policy on outing states that Posting another editor's personal information is harassment unless that person has voluntarily posted their own information, or links to such information, on Wikipedia. That same policy even states that posting information about an editor that they've posted on a different Wikipedia other than the one they're on could be considered a violation of the outing policy. Unfortunately, this policy is archaic, since everyone's information is on the internet in one way or another. I propose that the current policy be updated to match the realities of today's world. Also, our list members (Arbs / CU / Functionaries) are humans, and humans will invariably make mistakes. Therefore an appeal is a necessary step that currently doesn't exist in today's Wikipedia. While I agree that every editor deserves privacy and deserves to be known under whatever name they choose to be known on Wikipedia, I also agree that there should be some exceptions to this rule and that these exceptions would have to meet the stringent criteria already designed by Wikipedians to protect both Wikipedia and it's editors.

Proposal (Proposal to update the Outing procedure to allow for appeals)

I propose that the outing policy be updated to make it not harassment to post an editors information if it's already available on another Wikimedia site - IF AND ONLY IF this is done to prove that the named editor is in violation of COI or PAID. FURTHER this cannot be done UNTIL the reporting editor has already used the resolutions provided in the outing / C.O.I policy and in doing so, disagrees with the finding of the CU's, Functionaries or Arbitrators. This step would be used as an appeal and only as an appeal, it could never be used as a first step in any COI or PAID dispute. As it would be an appeal, it can only be posted on WP:AN or WP:ANI - nowhere else!

The user filing must indicate when they emailed the CU / Arbs / Functionaries.
The user filing must indicate which list they emailed (CU / Arbs / Functionaries).
The user filing must indicate who (by handle or name if it was given) responded to them.
The user filing must state why they're appealing this decision.
The user filing must then post a redacted version of the original letter sent to the CU / Arb / Functionary list .
Consensus must then be obtained for this appeal to be allowed to continue.
If Consensus is achieved - then the user filing will switch the redacted email with the non-redacted email and the appeal can begin.
Posting the non redacted email prior to getting consensus would still be considered outing and the user would risk sanctions, including blocking or banning for doing so.

Since all of these lists are mailed through Mediawiki's interface, a record of that email will exist on the system and will be date and time-stamped, which means they would be beyond anyone's remit to forge or alter. Anyone with sufficient access would be able to verify this was sent when the user said it sent. Additionally, because a list is indicated and a person's name or handle is indicated as the respondent, that person or anyone else on that list would be able to verify that the email was sent and responded to the way it's being indicated on the appeal. This would allow Wikipedia to operate in the way that it's always operated in with regard to COI and PAID, where the information is kept confidential and users have their information protected, but it also allows for an appeal, which under the current rules cannot be done without fear of outing. Further, it would also allow for the information shared in the appeal to be checked by two different independent sources to prove that the user really did email whichever list they state the emailed and that the original email was sent and responded to, thus reducing the possibility that someone would use this as an excuse to "dox" another user or use this as a form of harassment. Now it's your turn - do you agree, disagree, want to see changes in this potential procedure? Feel free to vote or comment. The floor's all yours!

Agree (Proposal to update the Outing procedure to allow for appeals)

* Agree - as proposer Necromonger...Arbs were wrong, Resysop BHG! 01:52, 17 June 2020 (UTC)

Disagree (Proposal to update the Outing procedure to allow for appeals)

  • The section of WP:Harassment called "archaic" in the proposal was the result of a 3 month long RfC ran last summer. If someone cannot convince a functionary---who we designate to deal with private data on the community's behalf---the evidence is probably just not that good. — Wug·a·po·des​ 05:58, 17 June 2020 (UTC)
  • I agree with Wugapodes; not only that, but citing WP:FRAMBAN as being of any relevance to functionaries' abilities to deal with COI seems... interesting? Either way, producing private information on-wiki, where the same information has already been judged by a number of people the community trusts as irrelevant, seems like a poor idea. Naypta ☺ | ✉ talk page | 08:38, 17 June 2020 (UTC)
  • (As a note, I have read everything here). This suggested change seems to be "we should always have an appeal route, and the only way to viably do that is to allow a slight reduction". I'm not necessarily against the first part (though not firmly for it), but the second seems incorrect. It brings unneeded negatives. Whereas a proposal to amend the advised resolution route so that admins or CUs who weren't arbs should be an individual's first port of call. If they disagreed with the decision, they could then send it to the arbs to consider. Alternatively an en banc setup would work. "Regular" CUs are by no means required to agree with arbs. Nosebagbear (talk) 10:02, 17 June 2020 (UTC)
  • Private information should be handled by people who are trusted to handle private information. There are plenty of routes for appeal if you disagree with a decision made by a functionary, not all functionaries are on ArbCom and even if the functionary who handled the original request is on ArbCom then they won't be the only one dealing with the appeal (indeed they should recuse themselves). The proposal is far too long winded and the proposed process seems very bureaucratic in any case. I also strongly disagree with the assertion that "everyone's information is on the internet in one way or another". Hut 8.5 12:34, 17 June 2020 (UTC)
  • I would suggest spending more time contributing to Wikipedia before proposing pages long sweeping changes to policy. I would also suggest that OP either change their signature, or file a request to usurp User:Necromonger. GMGtalk 12:48, 17 June 2020 (UTC)
  • Appeals which involve exposing personally-identifiable information should ALWAYS be in private, preferably via email to the Arbitration Committee. NEVER on a high-traffic, public noticeboard like the Admins' Noticeboards. —A little blue Bori v^_^v 2020's a bust; thanks SARS-CoV-2 20:43, 17 June 2020 (UTC)

Discussion (Proposal to update the Outing procedure to allow for appeals)

Can you sum this up in a short paragraph summary statement? I see that you intend to be thorough but I don't think most editors will want to devote the time to weigh all of the merits of your proposal. You're likely to get more feedback if it doesn't take people 10-15 minutes to read through your statement. Liz Read! Talk! 05:21, 17 June 2020 (UTC)

Seconded. I recognize that there is a lot of complexity/nuance to this issue, but conciseness is important. {{u|Sdkb}} talk 05:43, 17 June 2020 (UTC)
Thirded; the presentation of this does not follow WP:RFCBRIEF. The RfC isn't even signed, meaning that Legobot won't copy it across to the RfC category pages. Naypta ☺ | ✉ talk page | 08:40, 17 June 2020 (UTC)

I have read only the bolded words and can see already that I cannot support this. A proposal that contains the figure 99.999999% (i.e. all except one in a hundred million) obviously hasn't been thought through properly. I would advise its author to spend more time thinking and less time writing. Phil Bridger (talk) 08:53, 17 June 2020 (UTC)

Per Request I've shortened the proposal. I typically go for precision over brevity, but ok, three people asking is consensus enough that it needs to be done. Naypta actually I used Framban to show that sometimes the trusted users get it wrong, that's all. Necromonger...Arbs were wrong, Resysop BHG! 13:23, 17 June 2020 (UTC)
This is an invalid RfC. There is no opening statement whatsoever, and the first timestamp is in the "Agree" section. Please read WP:RFCST carefully, taking note of WP:RFCBRIEF, and try again. --Redrose64 🌹 (talk) 18:23, 17 June 2020 (UTC)

Dark theme

Latest comment: 4 years ago5 comments5 people in discussion

Is it too much to ask for a dark theme? — Preceding unsigned comment added by 78.141.126.88 (talk) 22:03, 15 June 2020 (UTC)

Please feel free to search around in village pump archives and on Phabricator. Short answer: It's being worked on. Long answer: It's hard. --Izno (talk) 22:37, 15 June 2020 (UTC)
Go to oreferences -> gadgets, scroll down to Appearance, and click the box for "Use a black background with green text". DuncanHill (talk) 22:45, 15 June 2020 (UTC)
Related: Wikipedia talk:Skin#Dark mode skin. --Redrose64 🌹 (talk) 18:26, 17 June 2020 (UTC)
There's also the awesome Nightpedia script by MusikAnimal. -- Niharika (talk) 02:05, 18 June 2020 (UTC)

Redirect-quality and List-class

Latest comment: 4 years ago7 comments7 people in discussion

A few months ago, on a WikiProject talk page, there was a discussion of getting rid of two unnecessary classes on the assessment scale: redirect-quality and list-class. This is a copy-paste of the discussion.

There are only 70-something redirect quality tropical cyclone articles, and there are probably 10,000+ tropical cyclone redirects that either don't have talk pages at all or have redirect talk pages. I personally think that that defeats the purpose of Redirect quality. I haven't been going around creating talk pages for redirects saying Redirect quality, NA importance since it's not even true (yet), but maybe this will cause you to start doing that. Additionally, I don't know how to become a member of WikiProject Tropical Cyclones and want to become one. Can someone show me? Chicdat (talk) 13:16, 15 March 2020 (UTC)

Not every redirect needs to have a talk page. It doesn't really help or add anything to the project. Most of the talk pages with redirect class can probably be deleted, unless there's some discussion going on. As for joining, all you have to do is add your name here! Welcome to the project, and good luck with your sandbox on List of Alabama hurricanes! ♫ Hurricanehink (talk) 15:06, 15 March 2020 (UTC)
I don't really see the support of redirect class. Or even stuff like list class if I'm being real. YE Pacific Hurricane 19:19, 15 March 2020 (UTC)
Would you propose using the assessment scale (Stub to B) instead of List class? Hurricanehink mobile (talk) 20:55, 15 March 2020 (UTC)
Yeah, I like that idea. (Stub-B.) Chicdat (talk) 22:09, 15 March 2020 (UTC)
That's more useful calculating the Wikiwork. Of course, what if we have an otherwise perfect list, but one storm is missing. Is it really stub-class? Is it only B-class if it has the entire historical record covered, with everything referenced? What makes a list a Start class vs stub? (references?) What about C-class? (largely comprehensive/referenced) ♫ Hurricanehink (talk) 01:12, 16 March 2020 (UTC)
I object to the rule whereby we say that all season are stub class if they are missing a system, as I know that the RSMCs have not always been brilliant at record keeping in public.Jason Rees (talk) 14:06, 17 March 2020 (UTC)
Let's see... maybe we can just split list class into Featured, A, "Good List" or something like that, B, C, Start and Stub. Stub would be things like a disorganized list with huge grammatical errors.Chicdat (talk) 10:07, 16 March 2020 (UTC)

The redirect class doesn't affect much in the long wrong. Classifying list-class as actual articles would affect the Wikiwork, or overall quality, so that should be discussed further. What if a list isn't disorganized or written poorly, but it's only a few items on what should be a much longer list? For example, you have 10 items listed in a list article, but it should be more like 50 or 100. Would that be stub if it's written well and is cited? What would a Start or C or A class list even look like? ♫ Hurricanehink (talk) 01:44, 17 March 2020 (UTC)

Two days ago I went around redirecting redirect-class tropical cyclone talks to the talks of the articles the redirects redirect to. (I'm sorry if that doesn't make any sense.) I personally think, that in the matter of redirect-quality, unlike the other qualities (except List), it doesn't say anything about the reason why we even have talks on Wikipedia in the first place: for the people on Wikipedia to see what's fine in the article, what needs improvement, how it can be improved, and how important the topic is. In redirects, the only thing it says is: #Redirect Some other article. What is fine in it? Ummm... it's hard to tell. What needs improvement? Ummm... it's also hard to tell. How can it be improved? Ummm... that's a hard one. And finally, how important is the topic? It isn't. Redirect quality is totally un-necessary! Chicdat (talk) 10:12, 18 March 2020 (UTC)
Agreed. I'm glad you went around and removed them/redirected them to other talk pages. For the talk pages of merged articles, you shouldn't redirect the talk pages, as we need to have the discussion for the merger; even those talk pages don't need the redirect class. It doesn't add anything for the assessment scale. ♫ Hurricanehink (talk) 13:09, 18 March 2020 (UTC)
Yes, go back to stub-A for list articles for WW purposes. YE Pacific Hurricane 22:57, 18 March 2020 (UTC)

And, about my article, List of Alabama hurricanes... I'm glad whoever put it at C-class instead of List-class did so. 🐔Chicdat (talk) 10:12, 21 March 2020 (UTC)

Why are we redirecting talk pages? YE Pacific Hurricane 19:39, 24 March 2020 (UTC)
Read the rest of the discussion. 🐔Chicdat (talk) 10:06, 25 March 2020 (UTC)
I did but that doesn't answer my question. What is wrong with this? YE Pacific Hurricane 16:09, 25 March 2020 (UTC)
This is why (from Hurricanehink): Redirect-quality doesn't add anything for the assessment. And he's right: it doesn't! 🐔Chicdat (talk) 17:41, 25 March 2020 (UTC)
I agree but why are we redirecting talk pages and in some cases explicitly removing discussion? The removal of redirect class has nothing to do with this. YE Pacific Hurricane 17:38, 26 March 2020 (UTC)
Actually nvm, you are getting it. Yeah just do not blank any talk pages and instead remove the WPTC project banner when there is a redirect. YE Pacific Hurricane 17:51, 26 March 2020 (UTC)
Okay, Yellow Evan, that's what I'm going to do. Now do you get it? 🐔Chicdat (talk) 10:06, 27 March 2020 (UTC)

Now, I'm looking for a sitewide removal of redirect-quality and list-class. Please read the original discussion for thoughts. 🐔 Chicdat ChickenDatabase 10:33, 8 June 2020 (UTC)

  • Oppose. WikiProject Tropical cyclones may not track a lot of redirects, but that doesn't mean other wikiprojects don't. I can think of several reasons why tagging them might be useful: using article alerts to draw attention to RfDs and other discussions relevant to a WikiProject; ensuring that {{R with possibilities}} are automatically tagged if they're ever turned into articles; preserving a link to project-related discussions on pages that were merged; probably more. And redirect pages tagged with a WikiProject are given the Redirect/NA class automatically so I'm struggling to see how this creates extra work for anybody who is not interested in using them. Given that there are thousands of WikiProjects and the WP1.0 assessment has been around in its current form for over a decade, making a change like this is bound to break somebody's workflow, with no obvious benefit to others. – Joe (talk) 11:59, 8 June 2020 (UTC)
  • Redirects: Non-starter.

    Lists: Eh, there might be value to categorizing lists the same as articles, or making it so that lists can be graded on quality as well. I don't particularly like that they are split as they are since all you have is "list" and "FL" classifications. but that's not what is being discussed here. --Izno (talk) 14:12, 8 June 2020 (UTC)

  • Oppose exactly per Joe. I like Izno's suggestion of making list classification more granular, but agree this is not the place to discuss that. Thryduulf (talk) 18:08, 8 June 2020 (UTC)
  • You can't remove Redirect class as it's got its occasional uses, but I wholeheartedly support abolishing it from most pages. Project tags on redirects talk pages serve no purpose at all while adding to the maintenance burden. What maintenace burden, you might ask? See, I occasionally do work on redirects, and in any given case before making changes to a redirect I would neeed to look at its talk page, in case there is a relevant discussion there. Of course, most redirects don't have talk pages and I can see that because the "Talk" link from the redirect is red; but when a talk page does exist the link is blue and I'll have to click through, most of the time only to find out that the talk page has nothing other than a project banner. It's this extra step, repeated for each of the dozen or so redirects for each average article, that is such a pain in the neck. And it's not that these talk page do anything: they're not needed for the article alerts (the bot is smart enough to use the project tags from the target article, so tagging individual redirects will only be needed in the unusual circumstances where a redirect is relevant to different projects that those of its target). Of course, tags on redirect talk pages that do have discussions, or any content at all, can actually be helpful, and there's also nothing wrong with preemptively tagging redirects with possibilites (as suggested by Joe). But such redirects are exceedingly rare (compared to the set of all redirects out there, tens of millions of them). So yeah, in very rare cases project tagging of redirects can be helpful, but otherwise it should very strongly be discouraged. – Uanfala (talk) 01:28, 19 June 2020 (UTC)

Flat Design

Latest comment: 4 years ago16 comments9 people in discussion
Withdrawn by original poster. Aasim 20:09, 20 June 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.

TL;DR: should we switch the icons used in meta-templates to flat icons? Aasim 18:26, 20 June 2020 (UTC) (More context below.)

Let's be honest. Many of our icons have not changed significantly since they were first uploaded in 2006-2009. In 2018, an RfC was held to determine whether the padlock icons should be modified to make them more accessible. Most people just liked the new padlock design, with little discussion about accessibility. With the web evolving, the need to move towards more modern design has become necessary.
A while back, and again now, I asked on Meta if there was a need to change the default skin. While there was not a big discussion as to whether the skin should be changed, one editor did agree with me and a WMF staff member linked me to a MediaWiki page where they are discussing making improvements to desktop. One of the concerns they are trying to address is that Wikimedia wikis do not match the expectations created by the modern web and our other platforms (the Android and iOS apps as well as the mobile website). I believe the icons on Wikipedia don't either. With some icons using designs from 2008, they have been in use for more than 10 years. But times have changed, and these designs need changing as well.

After doing a bit of investigation on MediaWiki's templates, including their versions of {{mbox}}, I see that their design uses modern, flat design. These designs make Wikipedia look cleaner overall and address issues such as dated gradients. I anticipate that the default skin for readers may change in the coming years or so. By making this change, we can be prepared for when the switch is made over.

I have made edits to template sandboxes and a major module page about how icons could be transitioned to address some of these issues. Plus, I think certain templates just don't... fit. For example, Template:Unblock reviewed shows a green or red clock, which has the same issues with accessibility as the padlocks. To address these problems, I made changes to some of these template's sandboxes using the flat design before starting this RfC (i.e. Template:Uw-block/sandbox, Template:Uw4/sandbox, Template:Uw3/sandbox, Template:Uw-disruptive2/sandbox, Template:Uw-disruptive1/sandbox, Template:Db-meta/sandbox, Template:Unblock/sandbox and Template:Unblock reviewed/sandbox). I want to see what the community thinks of these individual pages and whether these changes may be better.
This is a mix of concerns of both aesthetics and purpose. I could also picture the flat versions of each icons requiring less time to load (for example, a png rendering of the old information orange.svg file takes 20 kilobytes but the newer icon takes 4 kilobytes for some, which can speed up loading times on slower Internet connections by a little). This discussion is not about reuploading icons that are already in use, this is about replacing icons used in templates for future use. Because this can be a nominal change and take a long time to implement, I think it may be good to start an RfC about this first.

There are some icons I may have chosen when doing sandbox testing that may seem like they do not make sense, but then someone may design a flat icon that meets these needs.

My overall question is: should we switch over to using flat design from the old gradient designs? Aasim 18:44, 19 June 2020 (UTC)

  •  
  •  
  •  
  •  
    • Mostly opposed: Okay, I'm old. Rapidly approaching 70. But I also have a lot of old friends and it bugs the heck out of us to have to constantly keep relearning how to use programs and websites which are changed mostly just for esthetics and someone's notion of "usability" that doesn't keep existing users in mind. The shift from a traditional ribbon-menu based system and layout to a minimalist layout where all the links and buttons are hidden behind obscure unlabeled icons, which I presume is what you mean by "match the expectations created by the modern web and our other platforms the Android and iOS apps" is particularly frustrating. Yes, my copy of Firefox is modified with plugins and tweaks and kludges to look almost exactly as it did under Windows XP and I'm still using the MonoBook skin (and, I must admit, I modify my keyboard layout so I can still use key combinations from WordStar 4.0), but it's because that way I don't have to continually have to remember where to find stuff. I know that I'm probably on the wrong side of progress here, but if you're going to do this please provide and publicize a way that people who don't want to change don't have to change. Regards, "Mr. Okay Boomer" TransporterMan (TALK) 20:47, 19 June 2020 (UTC)
    Lets be honest, our skins are a compromise between the needs of editors and the assumed needs of readers. Both groups are important and we need to compromise between them - we know from the mobile skin what happens if we get the balance wrong. Currently we have a mobile skin that is so skewed towards readers that we have an editing community where mobile users are rare, and we have an overwhelmingly Computer based editing community writing for an audience where a large proportion are accessing us by mobile. There is an alternative perspective on this, that editors are tiny in number compared to our readers and therefore we should move to a "reader focussed" skin. Such proposals might make sense if we weren't dependent on the edit button converting readers into editors, as it is, such proposals need to be rejected unless they include an alternative way of recruiting new generations of editors. Hence our current situation, where people repeating the "Wikipedia has an out of date skin that needs renewal" mantra need to demonstrate that they are aware of that trope, and that their particular proposal doesn't repeat the customary mistake of neglecting our need to recruit editors. On the flipside, the community needs to be polite and clear when rejecting such flawed proposals, however frequently and repetitively they come. ϢereSpielChequers 21:32, 19 June 2020 (UTC)
    • Oppose because I never liked flat design in the first place. ^_^ Double sharp (talk) 08:59, 20 June 2020 (UTC)
    • @Awesome Aasim: what is your brief and neutral statement? At around 4,000 bytes, the statement above (from the {{rfc}} tag to the next timestamp) is far too long for Legobot (talk · contribs) to handle, and so it is not being shown correctly at Wikipedia:Requests for comment/Wikipedia proposals. The RfC may also not be publicised through WP:FRS until a shorter statement is provided. --Redrose64 🌹 (talk) 10:00, 20 June 2020 (UTC)
      TL;DR: should we switch the icons used in meta-templates to flat icons? I can update that in the intro statement and provide more context down here.  :) Aasim 17:35, 20 June 2020 (UTC)
      It needs to go at the top, in accordance with WP:RFCST, otherwise Legobot simply won't find it. --Redrose64 🌹 (talk) 17:48, 20 June 2020 (UTC)
      Updated. Thanks! :D Aasim 18:26, 20 June 2020 (UTC)
    • Oppose The long opening argument seems to use a lot of words to say: "We look old". Well, who's to say that the site does "look old" and who's to say that's a bad thing? Out of all the factors that positively or negatively impact on user experience, I would have to see some very persuasive and well-controlled surveys or studies to be convinced that the graphic style is anywhere near the top of the list. My intuition is that it may lurk around, say, number 325 out of 1,000. I recognize the OP obviously intuitively places it higher but that's the exact issue: it's all intuition and personal preference. There's no evidence that the graphic design of icons has any effect on site usage or editor retention or any other measurable metric. It's a solution in search of a problem. Eggishorn (talk) (contrib) 17:27, 20 June 2020 (UTC)
    • I do not think this question is ripe for an RFC. I see no recent discussion and I certainly see no major significant dispute needing resolution. I see a lot of "we should do this" but not a lot of "here's my solution". RFCs which are an up-down !vote with respect to styles and chrome are a lot easier (and some would un-qualify that statement); this is why the locks RFC last year went as well as it did. Go back to the drawing board, work out some suggested replacements (or maybe as many as you can identify), see who wants to change what rather than asking a generic "I think this should change" question. Go to the specific talk pages of the templates affected and ask the basic question of whether we should change some icons. --Izno (talk) 18:52, 20 June 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.
    • (after edit conflict) I have held off commenting here until now because there was no definite question set. There still isn't. Don't use phrases like "meta-templates" that are in techspeak rather than English. Just say which icons you want to replace, which you didn't show us even after you were asked for some pictures above, and by what. And I would add that I believe that there are many editors like me who see Wikipedia as a welcome relief from the corporate world where things are often done as busywork projects just because they are new and fashionable, so you need to show how this would actually improve Wikipedia. Phil Bridger (talk) 20:12, 20 June 2020 (UTC)

    Proposal to streamline the welcome template

    Latest comment: 4 years ago60 comments20 people in discussion
    I'm here following the AN/RFC request for closure. I note that there was another discussion about this RfC but it seems to have stalled out a couple weeks ago. Since there does seem to be a consensus here, it would be unfortunate to let it be pocket-vetoed by not being closed. Here's my closing statement:

    A great majority of the participants at this RfC supported the general concept of streamlining the welcome template in this general way. Some participants had different ideas about what the buttons should look like, what the first link should be, and similar matters. Other participants argued that, to paraphrase, we shouldn't let perfect be the enemy of the good and we should implement the changes now. Some participants argued for A/B testing, but there was insufficient participation on that question to find a consensus to do A/B testing as a condition of implementing these changes. Overall, there is a strong consensus in favor of the general changes proposed (reducing links, making the template more personal, and better visual design), and a rough consensus in favor of the specific proposed template. There is also consensus that the specifics of the proposed template could be improved (which specific links to use, etc.), but no definitive consensus as to what those specifics are.

    There seems to be a couple different ways we could go from here:

    • We could implement the proposed template now, and allow discussion and changes from there
    • We could open a new discussion to work out the details of the new template, leaving the current template in place until specifics are worked out
    Both of these options are valid ways to enact the consensus from this discussion, but I would personally suggest (without the closer hat on) in the spirit of incremental improvement that we implement the changes now and discuss and adopt further improvements to it over time. As always, questions about this closure are welcome. Best, Kevin (aka L235 · t · c) 20:36, 4 April 2020 (UTC)

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

    Template:Welcome (the standard welcome template) contains too many duplicate or unnecessary links and needs some streamlining so that new users aren't paralyzed by choice. For instance, it currently suggests four different places to go if you have a question[a] and four different tutorials[b]. Following a survey of Wikipedia's introductory materials, I drafted some changes to streamline the template that establish a clearer visual hierarchy to point new users to our best resources and remove more minor links to topics covered in Help:Introduction (such as the Manual of Style). After receiving some positive feedback at the Welcoming committee WikiProject, I'm bringing it here to establish a broader consensus for implementation. Here's the proposal:[c]


    Welcome!

    Hi [Username]! I noticed your contributions and wanted to welcome you to the Wikipedia community. I hope you like it here and decide to stay.

    As you get started, you may find this short tutorial helpful:

    Learn more about editing

    You may also want to complete the Wikipedia Adventure, an interactive tour that covers the same topics.

    If you have any questions, we have a friendly space where experienced editors can help you here:

    Get help at the Teahouse

    If you are not sure where to help out, you can find a task here:

    Volunteer at the Task Center

    Please remember to sign your messages on talk pages by typing four tildes (~~~~); this will automatically insert your username and the date.

    Happy editing! Sdkb (talk) 21:42, 11 February 2020 (UTC)


    The full code (which includes customization options) is at the template's sandbox. Please let me know what you think! Cheers, Sdkb (talk) 21:42, 11 February 2020 (UTC)

    1. ^ The Teahouse, WP:Questions, the welcomer's talk page, and the new user's own talk page
    2. ^ WP:Introduction, WP:Getting Started, WP:Contributing to Wikipedia, and the WP:Wikipedia Adventure
    3. ^ Note: Refactored 03:08, 27 February 2020 (UTC) by Sdkb (talk) to include Task Center button.


    Initial comments copied over from the Welcoming committee WikiProject:

    :I most often leave GF newcomers the {{Welcome!}} or {{Welcome-anon}} templates. I prefer the proposal by Sdkb as simplifying their choices to one of two, rather than a roster of policies and procedures. We may want to have a third choice for people who appear to be creating a draft article? - Bri.public (talk) 17:30, 27 January 2020 (UTC)

    @Bri.public: Yeah, as I was looking around the new user welcome pages, I noticed that the WP:Article Wizard and Help:Your first article (which has a big bold link to the wizard) are both well-designed and useful. Users that seem to be creating an article should definitely be pointed there. I'm not so sure about including it in the standard welcome message, though, since I think it's a bad idea to encourage newcomers to create an article right off the bat — they're very likely to try creating an inappropriate article for a topic with which they have a COI, and when it gets rejected they'll feel bitten. Do you have a sense of how many new users try creating an article as one of their first edits? If it's something they're going to do anyways, we may need to point them to our resources by default, whereas if most new editors can be steered initially toward other types of editing, I think we're better just leaving it out. The edit notice when you try creating a new article points there anyways (although perhaps not quite boldly enough). Sdkb (talk) 21:30, 27 January 2020 (UTC)
    Wow, this looks MUCH more approachable to me than any of the other welcome templates! I think it's very effective at directing new users to two main ways to learn more about the "hows" of editing Wikipedia. It's amazing how different it is vis-a-vis choice paralysis compared to the other options, especially the more "graphical" options, which tend to look overwhelming.
    Having just praised the simplicity and restraint of the links included..... I find myself wanting to add a link to the Five Pillars, because I think the one aspect that's missing right now is an approachable entry point to the core goals and norms of Wikipedia. Of the resources intended to introduce that information, I think the Five Pillars page does the best job of hitting the key points in a visually approachable way. I wonder if it can be slipped in as a sentence or phrase that doubles as a wikilink somewhere? So it's not an immediate "call to action" but it's present for a newbie to find early in their process of exploring. Or -- could it be added to the Introduction help page itself? I think that helping newbies feel like they have a handle on the core principles of the culture and norms is as important as technical knowledge.
    I'd be very happy to see this template in use, though, with further tweaking after it's entered the real works! Well done on the research and design work to build a compelling alternative. ~ oulfis 🌸(talk) 04:28, 30 January 2020 (UTC)
    Thanks for the praise, Oulfis! Regarding the pillars, the second module of the linked introduction is titled "Policies and guidelines", and while it doesn't explicitly list the pillars, it does mention that the project is "founded on five fundamental principles" and goes on to cover them. Sdkb (talk) 05:24, 30 January 2020 (UTC)
    This hasn't gotten enough discussion to reach too solid of a consensus, but since there's been some support and no strong opposition, I'm going to act boldly and go ask for it to be implemented. Sdkb (talk) 06:05, 11 February 2020 (UTC)
    • @Sdkb: Is there a reason one button is blue and the other is not? I'd prefer they be the same but it's not a huge deal; I like the general concept. — Wug·a·po·des​ 21:54, 11 February 2020 (UTC)
      You can see a little bit about the different types of buttons WP has at the template page here. The blue button is the "progressive" class, i.e. something that we think you ought to click. The white button is "neutral" class, i.e. something that you can click if you want. I classed them that way since the tutorial is something we strongly want to encourage new users to check out, so it makes sense to have a more prominent styling, whereas the Teahouse is something we want them to know about but don't need to push them toward. Per the rules of visual hierarchy, it's also better to have a single point of focus, i.e. if a new user is only willing to click on one link, we should let them know that it should be Help:Introduction. Now, all that said, I also thought it looked slightly odd, and if it also appears that way to others, I'd be fine with making them both blue. Sdkb (talk) 01:39, 12 February 2020 (UTC)
    • I like it. I remember being overwhelmed by the many links and options when I was welcomed. I've been using {{welcome-screen}} because some other editors in a discussion seemed to think it the best of the options at the time, but even simpler (like this) would be better. I think some way to set it off (a border, perhaps?) and make it stand out on a talk page would be helpful. Schazjmd (talk) 21:58, 11 February 2020 (UTC)
      A border would definitely be nice! I focused on changing the text/buttons since that's more what I know how to do, but feel free to tweak the sandbox if you're inclined, and we can consider it. One thing to keep in mind is that when the welcome template is used, it being it's own section provides a sort of natural border, so it doesn't appear as floaty as it does here when I put it in the middle of a conversation. Sdkb (talk) 01:39, 12 February 2020 (UTC)
      That's a good point (about the separate section). I know nothing about making templates, I just admire and appreciate them.   Schazjmd (talk) 01:43, 12 February 2020 (UTC)
      I use the Welcome template regularly, especially when I see a red Talk box in a history. Concistentcy in the wording would be a good change. Allowing an article name to go in from a box in more places would be good, too. Perhaps we could allow a choice of images, not just cookies, as we already have in some barnstars. There are too many ways to warn new users or IP users, and not enough ways to welcome a new user with many or especially good contributions. Good idea to post the revision here for us to see and comment on. Cheers!--Dthomsen8 (talk) 02:14, 12 February 2020 (UTC)
    Strong oppose choice of links "if only one page"...should be WP:Contributing to Wikipedia. .Not good feed back or good data for multi-page tutorials that are not formatted property for mobile view. Main problem I see above is the fact our main intro page is missing WP:Contributing to Wikipedia (the page with all the info, links to all the main help pages, and videos, brochures produced by this community and the Wikimedia Foundation). We have learned over the years the "Next page style" doesn't retain readers. Should not replace links to our help articles maintained by the community with mobile view format problem tutorials that lack basic info and our outdated. If trimming of links is required...tutorials should go and our 3 main help articles that have watchers to help should be retained. Don't send new editors on a goose chase trying to find information ...make it available on one page with a nice TOC for navigating to the section most relevant. Raw data Wikipedia:IntroductionDaily average:723....next page Daily average:85...page after that Daily average:44.....by page 50 only 6 virws. People dont want a list of link to another list of links.....they want serviceable info at a glance in a recognizable format.--Moxy 🍁 06:42, 12 February 2020 (UTC)
    Hi Moxy — I'm very much with you about reducing the lists of links, so hopefully we're at least in agreement about the overall need to streamline. Funneling users to a single intro when we currently have multiple is unfortunately going to have to involve stepping on someone's toes. I see that you're by far the top contributor to WP:Contributing to Wikipedia, so I apologize, but in its current state it just does not feel as modern and user-friendly as Help:Introduction. Essentially all other large websites (which, let's be honest, devote a lot more resources to user interface issues than we do) have onboarding processes for new users that use multiple short pages as Help:Intro does, rather than one really long one. I have to imagine they know what they're doing. Sdkb (talk) 21:49, 12 February 2020 (UTC)
    We will simply have to disagree. ..... I don't see how info separated out over 50 different pages that does not work properly in mobile view is more helpful ...run around setup.--Moxy 🍁 22:32, 12 February 2020 (UTC)
    We have lots of welcome pages, no objection to another being created. But changing the default this radically should not be done without first testing different welcomes and seeing which has the best result in terms of turning newbies into regulars. ϢereSpielChequers 08:02, 12 February 2020 (UTC)
    I see these changes as an improvement to the standard welcome template, not an alternative to it; they're substantial but build on what's currently there rather than replacing it from scratch. More to the point, since so many editors default to using the standard welcome, I think it's important we make that one as good as it can be; the old one could be renamed to something else if any editors really want to keep using it. I also don't think it's great to have too much welcome template proliferation — we need to keep our best resources centralized so they can be maintained/improved, not fork them every time there's a controversial upgrade.
    Regarding testing, I'm very much behind the idea of doing some A-B testing in theory, but when we previously discussed it, it didn't seem to be very practical. It would take a long time to build up a sample (since I don't know of any way to welcome newbies in bulk) and would take some programming to measure the results. If you or someone else has the expertise and time to conduct that sort of experiment, I'd be fascinated to see it, but barring that, we should act boldly and go with whatever we think will likely work best. We risk as much through inaction as through action, and there's a lot of room for improvement in converting readers to editors. Sdkb (talk) 22:23, 12 February 2020 (UTC)
    @Sdkb: off the top of my head, you could create two redirects, E.G. WP:TEST1 and WP:TEST2 that both go to the same page. Have the template randomly link to one of them on each transclusion. After a few days/weeks, compare the number of page views each redirect got with the number of back links to show which had the most best ratio of clicks to transclusions. — Wug·a·po·des​ 03:06, 14 February 2020 (UTC)
    A redirect could be used to measure the engagement of this template, but it wouldn't work with the current Template:Welcome as a control, since that template links to many intros, not one. And there's still the issue of building up a meaningfully sized sample. Sdkb (talk) 03:42, 14 February 2020 (UTC)
    • This welcome message doesn't work on an Android mobile device. In its current state it takes you through several pages of broken formatting. Until that is fixed, this is not an improvement and is more likely to drive many editors away. While I can see your good intentions here, simplicity is best when we have to consider mobile audiences. From Hill To Shore (talk) 00:22, 14 February 2020 (UTC)
      @From Hill To Shore: Can you share a screenshot of the issue you're encountering? It works alright on my Android device. And yes, simplicity is the whole goal here—that's what this template is doing. Sdkb (talk) 03:29, 14 February 2020 (UTC)
    A note regarding mobile formatting: I fully agree that ability to read on mobile is vital, and the {{intro to}} and {{intro to single}} templates both need to be updated to use flexbox css to make that smoother. Thet should be a relatively quick fix. The cause of the poor mobile formatting is that these are all currently in rigid divs, rahter than flexbox divs (main culprits are the handling and placement of {{Intro to tabs}} and the column implementation in {{intro to single}}). Sidenote: this is also a problem with a lot of templates that aim to implement multilpe tabs (compare Wikipedia:Tutorial vs v:WikiJournal_User_Group for a flexbox equivalent for tabs). T.Shafee(Evo&Evo)talk 05:31, 26 February 2020 (UTC)
    @Evolution and evolvability: Thanks for that info! I made a request for help at the technical pump since I don't know how to use flexbox divs myself, but I'm not sure if anyone will take me up on it. If you end up being inclined to make the fixes yourself, it might go a long way toward helping this proposal achieve consensus. Sdkb (talk) 09:37, 26 February 2020 (UTC)
    @Sdkb, From Hill To Shore, and ToxiBoi: I've updated the Template:Intro_to/sandbox to work pretty well on mobile I think (as well as making the window on a desktop narrow). I'd welcome any testing by others though! Formatting parameters now controlled through Template:Intro_to/styles.css. Side-by-side comparison to Wikipedia:Tutorial on others' devices also valuable. Just waiting for the sandbox version to be copied over to the main template before it's viewable as the default for all pages using that template. T.Shafee(Evo&Evo)talk 07:25, 1 March 2020 (UTC)
    @Evolution and evolvability: Good work, the problems I was seeing in Firefox on Android have now gone. From Hill To Shore (talk) 14:18, 1 March 2020 (UTC)
    We had talked about linking the main To-do page Wikipedia:Maintenance in the past but most seem to think that pointing new editors to what to do page off the bat would not be all that helpful. I personally think Wikipedia:Maintenance gives a good overview. PS was looking for this link for hours last week.... As it was one of the reason WP: contributing to Wikipedia was updated with Foundation brochures and added to the templates.--Moxy 🍁 00:02, 25 February 2020 (UTC)
    @Moxy: WP:Maintenance is certainly comprehensive, but I'm not sure it's accessible to new editors. It has too much detail on too many tasks — for instance, the very first item after the intro is a full section on copyvio, a complex area I'm not sure many new editors are going to want to dive into. I think the best approach for new editors is to provide a bunch of options of areas where help is needed, let them choose one, and then provide instructions for that area and clear examples of pages where they can apply what they've learned. The Task Center does this with a short intro followed by a concise list of tasks. I like how it plugs the benefits of participating in different areas. The open tasks list has the advantage of listing actual articles editors can click on and then help out with. Overall, I'm leaning toward including the task center. Sdkb (talk) 07:19, 25 February 2020 (UTC)
    Update: I've added a button for the Task Center to the sandbox. If there are no objections, I'll wait a day or so and then refactor the proposal here to include it. Sdkb (talk) 00:19, 26 February 2020 (UTC)
    • Comment: Research and testing It makes a lot of sense to actually assess how effective our welcome messages are, and to improve them where possible. Ensuring that not only the welcome messages, but also the pages they links to will display properly in mobile view seems almost as important as the effectiveness of the welcome template itself. Sadly, as Moxy has found, there seems to have been no serious research into the effectiveness of welcome messages and their impact on editor retention since around 2011/2012. (i.e. all pre Teahouse) All I could find is this, this and this, which was mentioned above.
    One 2011 study on German Wikipedia concluded that:

    Overall, these results support our findings from other tests: Welcome messages that are relatively short, to the point, and which contain only a few important links are more effective at encouraging new editors to get involved in the project. Our recommendation is to change the default German welcome template to the short version.

    Back at English Wikipedia, there is a study currently ongoing by WMF researchers into Teahouse invitation message effectiveness. (Summary: It is comparing the old automated invitee selection process against an ORES-based editor selection process for HostBot to send out invitations to new editors who've made their first few edits here. The research process unfortunately contained a small number of variables which rendered the results on editor retention inconclusive, and a second wave of research will hopefully go ahead soon. It did not look at the effectiveness of the Teahouse invitation wording, or timing, - only the criteria for the selection of good faith editors to send them to. See here for summary and feedback)
    Now, it strikes me that the A/B study methodology used to look at Teahouse HostBot invitations must be very similar to that needed with Welcome messages. Therefore, I am pinging @Jtmorgan, Maximilianklein, and Halfak (WMF): in the hope that one of them might be willing to offer ideas or insight on whether any research study is currently ongoing or planned, and whether there might be a possibility of encouraging, supporting or funding an investigation into this important and related area of editor welcome and retention. Nick Moyes (talk) 12:34, 25 February 2020 (UTC)
    @Nick Moyes: Maximilianklein is considering doing some more testing of AI-powered HostBot invites later this year, but no plans are finalized. If it looks like it's going forward, we'll notify on the Teahouse. Depending on the scale of the experiment, I could see experimenting with different welcome templates being a component of it. When it comes to what should be on the generic invite template, I'm definitely in the "less is more" camp. We can't, and shouldn't expect new editors to RTFM before they do anything. J-Mo 19:53, 27 February 2020 (UTC)
    Simply is best in my view as per this - thus I use Template:W-short alot. Years ago we created 2 types of "MAIN" help pages - one static article style WP:Contributing to Wikipedia and duplicated that at info at Wikipedia:Tutorial with tabs/next buttons (see what worked best). We can see and saw by the numbers most dont go beyond the first page of the tutorial. This is also what happens at the Wikipedia:Adventure - 50 percent drop in views by the second page....with a loss of 90 percent by page 3. I am all for making things easier ...not harder by making people click 50 times to get serviceable information....less is best and of course mobile view must be considered. -- Moxy 🍁 14:22, 25 February 2020 (UTC)
    @Moxy: those numbers are certainly concerning. To me, they potentially point to those resources not being as well-designed as they ought to be. (Do you have a link to the data, btw?) Some dropoff is natural, though, since we're never going to convince everyone to read a full tutorial, and for all we know, the dropoff rate on the pages that present it all together could be even higher. (The metric we'd need to measure that would be average time spent on page, and probably only the WMF knows that.) The benefit of splitting materials into multiple pages is that short chunks are more digestible, whereas sending readers to one long huge page will overwhelm many and make them give up. Sdkb (talk) 00:03, 26 February 2020 (UTC)
    Good day I phone user.....can you elaborate on your experience! I am assuming your our normal IP poster and get a lot of welcomes.....what template is used most in your case?--Moxy 🍁 23:35, 25 February 2020 (UTC)

    The blue-with-white-text button seems wrong to me. I believe (though I might be wrong) that blue buttons have a specific semantic meaning on Wikipedia. On my desktop interface, the "Publish changes" button is blue/white, and the "Search" button on the search page is blue/white, implying submission of a request, not just a link. – Jonesey95 (talk) 05:03, 26 February 2020 (UTC)

    @Jonesey95: I haven't been able to find any stylebook or documentation about when it's appropriate to use a blue vs. gray button. I gave my rationale for choosing blue to Wugapodes above, but similar to what I mentioned above, I'd be open to it being gray if it looks weird to others, too. Sdkb (talk) 03:39, 27 February 2020 (UTC)
    At the very least we should follow MOS:COLOUR "Links should clearly be identifiable as a link to our readers." Big changes here...removal of most links....replaced with a link to an intro with 50 sub-pages that is currently not viable for 60 percent of our readers.....and big buttons that may or may not look like links. Best create a new template see if it gets good feedback ...then ask for a whole scale change to the main welcome template.--Moxy 🍁 04:07, 27 February 2020 (UTC)
    This style guide was very difficult to find. I think it is current and accurate. Jon (WMF) may be able to give us some pointers or send us to the right resource or person. It would be useful to have some version of this UI style guide in a form comprehensible to regular editors. – Jonesey95 (talk) 05:26, 27 February 2020 (UTC)
    Interesting read.--Moxy 🍁 05:32, 27 February 2020 (UTC)
    @Jonesey95: Thanks; that's what I was looking for (without knowing it existed)! The key phrase seems to be this: Use progressive variant for actions which lead to a next step in the process. (progressive variant = the blue one) Whether that's applicable here is a little borderline; I think we could go either way. Courtesy pinging Wugapodes, as you had the same concern about the color. Sdkb (talk) 05:45, 27 February 2020 (UTC)
    Action.= ."If an action is to “navigate the user to a new resource, taking them away from current context, consider a link instead.". The norm as per all wikis. the most significant navigational symbol we have.--Moxy 🍁 06:08, 27 February 2020 (UTC)
    The major advantage of buttons over links here is that we can easily make a button fittingly prominent, whereas I'm not sure how to do that for a link. If you want to experiment, I'd be interested to see a design that uses a prominent link instead. Sdkb (talk) 07:03, 27 February 2020 (UTC)
    Sdkb You make a good point about experimentation. To that end please do not overwrite the old welcome template, but create a new one instead which will allow side by side comparison as to its effectiveness, as Moxy suggested above. I appreciate there is already an over-abundance of tweaked welcome templates, but this is a significant change and one well worth testing and tweaking alongside the older approach. Nick Moyes (talk) 10:31, 27 February 2020 (UTC)
    We can also consider the example and precedent of the Teahouse HostBot invitation template, which uses what looks like a custom-designed button. If we used that style of button here, it would display as this:
    Learn more about editing



    Sdkb (talk) 23:16, 27 February 2020 (UTC)
    • Support. I agree that the current Welcome template is in need of some streamlining. My only concern with the new design is with the buttons, it could trip up a new editor when they press one and get taken to a different page (that's what I think, though). Also can confirm it works fine on Mobile Web. –ToxiBoi! (contribs) 02:06, 28 February 2020 (UTC)
      If concerns are with the mobile app, I can see that happening. I won't be able to test that myself though. –ToxiBoi! (contribs) 02:07, 28 February 2020 (UTC)
    • I strongly support this new welcome template. Simply put, less is more. This new message feels more personal and less like automated spam, it's got a clear actionable goal you can take to learn the basics about the site (rather than a dump of a couple dozen links that don't feel like they have a cohesive narrative) and it's less prone to being bloated over time. (Brought here by a neutral message at Wikipedia talk:Wikipedia Signpost/2020-03-01/Opinion.) — Bilorv (talk) 22:16, 4 March 2020 (UTC)
    Less links would be better. Should keep link to standard page over an assembly of tutorial pages. If simplicity is the goal then multiple page tutorials is not the answer.--67.201.160.202 (talk) 23:10, 4 March 2020 (UTC)
    • Support generally as long as some of the other considerations above are taken into account, like making it mobile-friendly and reconsidering the first link. I personally would have loved to see the Teahouse link or the "Task Center" links earlier on when I first joined -- I only found out about them somewhat recently, but they both make Wikipedia way more approachable/simpler to new users. The simpler design of the template overall is also really approachable.
    My concern is that I don't think the first link is the most helpful introduction to editing. And I agree with some above that it should probably have either an option for or one extra link about drafting articles. - Whisperjanes (talk) 04:05, 17 March 2020 (UTC)
    @Whisperjanes: Thanks for the support! Regarding mobile-friendliness, to my understanding the issues above have been fully addressed at this point. Regarding WP:Your first article, I think editors really set on creating one will find their way there—it's linked from the Task Center and from the uncreated page edit notice, which we recently strengthened. For all others, we should direct them toward tasks less likely to bite them. Regarding the introduction link, what would you consider the most helpful intro? Having surveyed them all in some detail, I feel the blue button should go to Help:Introduction, but I'd have no problem modifying the line beneath it, perhaps to Alternately, the Contributing to Wikipedia page and interactive Wikipedia Adventure tour cover the same topics. It's worth noting that whatever we choose here will almost certainly be an improvement over the current version of the welcome template, which links first to WP:Introduction, an intro so bad it is likely to be converted to a redirect soon. Sdkb (talk) 06:37, 18 March 2020 (UTC)
    Only agreement here is for less links.....no agreement to change to an action button....or to link the 60+ page intro over our main help pages....So really all we have is the WP:Introduction that will change to Help:Introduction but if we drop links multiple page tutorials should be dropped...As mentioned above ...best test before trying to implement multiple changes.--Moxy 🍁 06:50, 18 March 2020 (UTC)
    I actually do think they should be changed to action buttons, because they stick out more and I think are easier to read and click (although that's just a personal opinion). Testing it might also be a helpful step in this process (although I'm not sure how that's usually done on Wikipedia, or if it's really feasible). Although, I assume you have to make it first anyways to test it. So possibly finding a way to collect data on the templates already used, as editors have been talking about above. Whisperjanes (talk) 16:44, 19 March 2020 (UTC)
    @Sdkb: Thanks for following up! Yeah, now that you mention it, I'd be fine with leaving "your first article" out -- especially since I think most new users get on to make an edit first (from my personal observation). And it's hard to say which alternative for the introduction link... I would like to say Wikipedia:Contributing to Wikipedia (because it's written in a similar style to most guidelines... although, to be honest, it's incredibly dense and I'm not sure how helpful/quick it is to use). I was actually going to suggest Wikipedia:Introduction, until I read the current discussion happening on it. I'm not sure all of which pages exist out there for intros, but the one thing I think is most important is that it gives information on the first page immediately after you click away from your user talk page. That's why I'm not as much a fan of Help: Introduction (because the first page gives you a directory of links, not info). I actually think I would prefer Help:Introduction to Wikipedia because it brings you immediately to information, but the only downside is that if you keep clicking, it automatically teaches you Wiki markup, not the visual editor. Obviously, I have a lot of thoughts but not many answers, so I'm more open to seeing what others think than my own opinions. Help: Introduction might end up being the best option, I just find it daunting (to have to choose what you're going to learn before you understand Wikipedia, including which editor you want to use) and have a problem with the fact that it draws your eyes first to the editing interfaces, rather than the intro tutorial. Whisperjanes (talk) 17:11, 19 March 2020 (UTC)
    I would be ok with....- -Moxy 🍁 07:02, 18 March 2020 (UTC)

    {{quotation | Hello, Example, and welcome to Wikipedia! Thank you for your contributions. I hope you like the place and decide to stay. Here are a few links to pages you might find helpful:

    You can visit The Teahouse to ask questions or seek help.

    Please remember to sign your messages on talk pages by typing four tildes (~~~~); this will automatically insert your username and the date. If you need help ask me on my talk page, or ask for help on your talk page, and a volunteer should respond shortly. Again, welcome!

    What happens when you turn your phone sideways? Anyways... queation is should we direct new editors to 60plus non standard pages that may or may not work properly for mobile readers (the majority of out readers). Not sure why accessibility for disabled people is being thrown to the wind here.--Moxy 🍁 23:21, 25 March 2020 (UTC)
    • Strong support for this new welcome template. Time for us to move forward with a good welcome template. Further improvements could be made after implementation right now.--Dthomsen8 (talk) 00:01, 26 March 2020 (UTC)
    • Note: A little discussion spilled onto my user page and can be found at this thread. Sdkb (talk) 01:09, 28 March 2020 (UTC)
    • Support - Admittedly I prefer the old one simply because it's what I'm used to however as Dthomsen8 says It is time for us to move forward and I agree with the nom that the old template had far too many links, Although the blue/white box is used for Publish changes I don't personally see that as a reason to oppose,
    The new template is a major improvement over the old one and so support it being the default one. –Davey2010Talk 10:58, 30 March 2020 (UTC)


    Strong support of the proposal on teaching code to newcomer. also the page https://en.wikipedia.org/wiki/Help:Wikitext is difficult to follow. I am proposing for a easier help page with limited number of necessary commands. Currently I have kept the draft in my sandbox https://en.wikipedia.org/wiki/User:RIT_RAJARSHI/sandbox Regards and thanks RIT RAJARSHI (talk) 09:31, 1 April 2020 (UTC)

    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.

    Events rather than announcements

    Latest comment: 4 years ago12 comments7 people in discussion

    A scourge (in my opinion) in a large proportion of articles, especially those prone to ongoing changes, is the frequent citation of announcements of events (births, deaths, changes of job, release of films/recordings, re-organisations etc). It gives the impression (and is almost certainly the result) of edits as soon as something is heard about and never subsequently edited, and therefore a very poor encyclopaedic standard, and gives undue emphasis to what was once recentism and has become outdated. With few exceptions, the announcement of anything happening is of far less relevance than the event itself, and is not of itself worth any mention in an encyclopaedia. The one defence I can imagine is that there may be uncertainty as to the exact date of the event that has been announced, but if the precise date is not featured in the announcement, and not forthcoming very soon after, then it is probably not important enough to be featured in an encyclopaedic article. I would very much like to see strong direction in the Manual of Style against the use of reporting of announcements. Kevin McE (talk) 17:29, 16 June 2020 (UTC)

    If a reliable secondary source that gives all the necessary information, that secondary source should be preferred. However, these secondary sources may omit some of the details, in which case supplementing the secondary source with a primary source, such as an announcement, may be useful.
    One example is the calendar in which the date is stated. The authors of a secondary source may ASSume that "everybody knows" what convention should be followed if an event occurred at a time and place where the Julian calendar was in effect, but I can tell you from a great deal of work correcting such problems, most Wikipedia and Wikidata editors don't even know the Julian calendar even existed. If and when you can get it into their heads that it was officially used for government purposes as recently as 1923, their jaws drag upon the ground.
    By citing a primary source written in the same city or region as the event, and close to the time of the event, you can be sure it used the calendar in force at that time and place, and in most cases, deduce which calendar was used.
    Some databases record events in Universal Time. (Wikidata purports to do this, but in practice doesn't.) To get the date correct, unless the event occurred in a place that observed Universal Time as the local civil time, it is necessary to take the time zone of the place into account. For this purpose, it is necessary to establish the time of day of the event. Sometimes the time of day is available in a primary source but not a secondary source. Jc3s5h (talk) 18:43, 16 June 2020 (UTC)
    Is that meant to b a reply to my suggestion: I'm not sure that you have recognised the main thrust of what I was saying if it is. Kevin McE (talk) 19:27, 16 June 2020 (UTC)
    Yes, editors - and usually those that are "flyby" in that they see something in the news and come by to drop one item on the page - will use proseline and drop the announcement with the date of the announcement as the seemingly key factor. Rarely is the date that important, its when the event is expected to happen or the like. Sometimes, if the announcement is tied to a make convention or similar event, then that can be incorporated, like a film being announced during San Diego Comic Con, but again, its not the specific date of the announcement, just that it was tied to the convention. Proseline is easy to write into but it doesn't work well in the long-term which is why we have WP:PROSELINE to guide editors from that. Also some editor do jump on announcements of events that are really non-events (announcements of planned announcements ....) which that we shouldn't do at all. --Masem (t) 19:39, 16 June 2020 (UTC)
    Kevin McE, yes, that is intended as a reply to your proposal. Since no exact wording is proposed yet, there is a danger that the wording ultimately adopted might not be confined to avoiding primary sources for recent events, and editors who never read the discussion of the proposal, only the final wording, might go around deleting useful details solely because they are from primary sources. Any wording must strike a balance between avoiding recentism and the deletion of details that are useful, but may not be recognized as useful by some editors. Jc3s5h (talk) 19:45, 16 June 2020 (UTC)
    It sounds to me like the proposal is to have fewer articles that say things like "On 15 June 2004, the hospital announced that they would build a new heart center next year." WhatamIdoing (talk) 03:12, 18 June 2020 (UTC)
    That would be understandable, and acceptable as a short term phrasing, especially is there were subsequent problems in the plan being fulfilled. The problem I refer to is epitomised by "On 14 March 2018, it was announced that the couple were expecting their first child; the birth of their daughter Orla was announced on 24 September 2018." when the encyclopaedically relevant fact (and new text on the page) is "their first child, Orla, was born in September 2018." So what if we don't know the exact date of the girl's birth (maybe the child was born a day or two before the announcement): anyone close enough to the family to be sending a card will have other ways of knowing it, and every birth is preceded by a pregnancy, so that part of the sentence is at best irrelevant, and worst intrusion on grief (had the pregnancy not been successful). Kevin McE (talk) 15:25, 18 June 2020 (UTC)
    • WP:PROSELINE is definitely a legitimate problem, and it'd be nice to improve that essay and link to it from more places. Since it's so subjective, though, I'm not sure it'd really be possible to come up with a definitive standard on it. It's just something to constantly keep an eye out for. {{u|Sdkb}} talk 20:44, 16 June 2020 (UTC)
    • There is an essay at WP:ANNOUNCED that discusses this exact sort of thing. It would behoove us to follow its advice more, I think. oknazevad (talk) 18:04, 18 June 2020 (UTC)
    Thanks for the heads up: that is precisely what I am talking about. It would be good to elevate that essay to MoS. Kevin McE (talk) 10:02, 21 June 2020 (UTC)
    • Oppose This is a waste of time per WP:CREEP. Consider the current pandemic. This is causing lots of announcements about the postponement or rescheduling of events such as the Olympics. Editors are likely to update Wikipedia accordingly and so the proposed guideline will be a dead letter. Andrew🐉(talk) 20:52, 19 June 2020 (UTC)
    Please explain how the announcement of a cancellation is in anyway more relevant than, or known about before, the cancellation itself. Kevin McE (talk) 10:02, 21 June 2020 (UTC)
    Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(proposals)/Archive_168&oldid=1119260158"
    pFad - Phonifier reborn

    Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

    Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


    Alternative Proxies:

    Alternative Proxy

    pFad Proxy

    pFad v3 Proxy

    pFad v4 Proxy